You will profit more from good soft skills than from good technical skills.
He summarizes the statement like this:
Technical skills are the ones you can learn easily. … It’s just a matter of practice.
On the other hand, soft skills are much harder to improve. … You must do things you are not comfortable with.
This is something I think is absolutely worth talking about within our industry especially given we’re not just responsible for solving a given problem.
We should be able to articulate the solution to our team or stakeholders, field questions from them, and garner and manage feedback from them to adjust or improve our work (or, in some cases, ourselves).
It will be almost impossible to disconnect from your job
If you’re someone new to the industry – be it someone who’s up and coming from high school or university or if you’re someone who’s switched careers – comments like this can make it seem daunting.
Note, however, he also states:
So I publicly admit, that I have a hard time disconnecting from work.
This is good because it doesn’t have to be difficult to disconnect from your job. In fact, it shouldn’t be difficult to disconnect from your job.
At the very least, perhaps these things will be something to keep in mind if you’re looking to enter the industry or even for who have been working in the industry. At most, that article is something that provides a solid perspective from one person’s experience (which likely echo many others, too).
And I’ve been slowly working through each point since. In this post, I’m looking at one that states: Uncertainty will be your toxic friend.
The Relationship of Software Development
Originally, I planned only to go through the list of things provided in the post and comment on them, but the idea of relating “uncertainty” and “toxic friend” piqued my curiosity a bit.
On Toxic Friendships
That dude and his toxic friendship with the computer.
To that end, I decided to dive into the various corners of the Internet to see how “toxic friend” is defined.
[A toxic friend] is usually someone who brings elements of dysfunction and unhealthiness into the relationship dynamic or group. Psychology Today.
Toxic friendships can take different forms, but they generally drain you mentally and have a way of bringing you down instead of building you up. Healthline.
[Toxic friends] often backstab, gossip, lie, act selfish, use, belittle and even manipulate and are taking more than giving back to the friendship. Urban Dictionary.
A toxic friend is someone who consistently exhibits harmful behavior, such as manipulation, negativity, or betrayal, causing emotional distress and negatively impacting the well-being of the relationship. ChatGPT (and all of the sources who trained the underlying model).
This isn’t meant to be completely facetious as there is validity in what’s said, but I generally consider “uncertainty as part of the job” and nothing more. But personifying it as a toxic friend? Maybe that makes sense. Maybe not.
Uncertainty in Software Development
The existential threat of uncertainty.
Here’s my experience, point by point.
Third-Party APIs
[Implementing] something in your project you never worked with, eg. 3rd party API – how are you going to implement something you aren’t familiar with?
This is true.
Whenever we’re tasked with having whatever application we’re working on interface with a third-party, there’s almost always a learning curve. (I can’t think of a time where there wasn’t but I can’t speak for everyone so I don’t want to speak in absolutes.)
Sometimes, the learning curve is steeper. It depends on, say,
authentication to access the API,
the arguments for the API,
and how to process what it returns.
Further, if the documentation for the API is wrong then it’s a matter of looking at what’s returned and trying to figure out how best to work with it, or it’s a matter of hoping whoever supports the API is willing to look it, offer guidance, or perhaps even update the endpoints.
Regardless, learning how to integrate with a new API is one thing. Hoping the documentation provides exactly what’s needed or finding a resolution if it doesn’t is another level of complexity for which we ought to plan.
Learning a New Technology
[Transfer] to a new project, with new technologies – you will think about how you are going to be efficient and productive with something you need to learn?
I’d go as far to say that this is something that may still be challenging even working within the same segment of the industry.
For example, if you’re working with one organization and they have certain:
coding conventions,
branching and merging strategies,
continuous deployment set ups,
testing methodologies,
and so on,
And then you move to another organization that differ, even if it’s just in one area, then it’s something new to learn.
Lay all of that on top of moving from one stack to a completely new stack and you’ve got a handful of new tools, technology, and methodologies with which you need to work.
Again, this isn’t just one level of uncertainty. It’s multifaceted.
Moving To a New Company
[Move] to a new company – you are unsure how you are going to settle in and vibe with new people.
I don’t think this is something that’s deserving of much more commentary than I’ve already offered especially in the previous section.
It’s worth noting, though, that in our field it’s far more likely you’ll be changing jobs than not. This isn’t to say that you can’t – or won’t – stay at a place for a very long time, but the statistic for programmers changing jobs used to be something like every three-to-five years or so (CodeMotion). I’ve also read statistics that it can be as frequently as every two years (Invene).
I’m not arguing for or against this. (Personally, I think each person needs to do what’s best for himself or herself.) But it’s worth noting this will obviously require having to learn new things especially if you’re expecting to move to a new company.
Bug Reports and Deadlines
[Bug] report on the day you need to finish the work – you fear that you are gonna break the deadline
If I was to give a TL;DR to this section, it would be something like this: Yes, I agree. But I also contend that, if given you opportunity, as how project management works at the organization in question. Because they can make or break this particular level of uncertainty.
I have a longer take on this, too.
Yes, this happens from time-to-time but there are safeguards that can – or maybe should? – be placed around any given sprint of work to account for this. And if you have a good project manager, then it shouldn’t be a problem.
For example, let’s say you have a sprint and you and your team have completed all of the necessary work to ship the sprint to QA or whoever will receive the work. But just before you’re tagging the release, a bug report comes in from the prior sprint that affects the work in this sprint.
As frustrating as it can be, it’s also something that should be expected. It’s one of those “hope for the best, plan for the worst” situations.
That is, each time a new sprint has started, there can (read: should) be time built into the new sprint such that it accounts time for bug reports to be introduced so they can be addressed.
No, you can’t anticipate how many nor reports you’ll receive nor can you anticipate how said bugs will be to resolve so there’s always a level of uncertainty in the planning, but if you’re adding time to your sprint to account for this then there should be less stress in missing the deadline because you’ve accounted for the uncertainty.
Then, you’ve got a best case/worst case scenario: Either you’re going to ship everything you planned earlier than expected or you’re going to ship what you’ve planned in addition to fixes.
On certain teams, perhaps you’ll even be able to grab another task from the next sprint and bring it into this sprint. That’s a positive outlook on uncertainty.
On Job Security
[Job Security] – economic situations, pandemics, wars, and other factors heavily affect this industry which results in layoffs
There’s really not much to contribute to this. Few parts of the economy are immune to factors that may negatively impact employment.
I don’t find this unique to working in tech. This, above all other criteria, is something for which we should always plan.
The only commentary I have on this is that if you have the ability to save for three-to-six months of your expenses, then that can sometimes help offset when these things happen.
New Technology (Tools and AI)
[The] evolution of technology – you are never sure if tomorrow you are gonna be replaced by some new technologies like AI
This point is the one I’ve had to consider the most because, for the 15+ years I’ve been working in this field, I’ve never truly been worried about a new piece of technology – be it software or hardware – replacing anything I or any of my colleagues jobs.
NEW TOOLS
If anything, as new tools have come – and some have gone – they were things that we were expected to learn and sometimes incorporate into our day-to-day work. They weren’t advanced enough to replace anything we were doing. They accelerated what we were doing, sure, but only after successfully learning said tool.
And even though we’re in a surge of tools being built with AI, it’s still not something about which I’m worried taking my job. If anything, it’s helping me get more work done quicker and it’s helping us to build tools that enhance our software if anything else.
AI
That said, I can only really speak as to how AI is affecting or impacting my job as a software engineer. I can’t speak to how it may affect someone in this industry that’s engineering-adjacent but I still don’t yet see how it’s going to truly replace a given job.
Even the tools that promise to help plan schedules based on, say, the backlog of tasks and the availability in each person’s calendar, it also makes the assumption that the data it’s being handed is up tot date and we’re assuming it can correctly estimate based on the data it’s given.
AI’s impressive, to be sure, but there’s a lot of assumptions happening based on the solutions it provides and those assumptions can cost a lot of money without the proper safeguards in place.
If anything, AI is enhancing the way we get things done and it’s allowing us to build tools that we couldn’t do so two years ago. But there still has to be someone able to interface the software being built with the AI to which its communicating. And there has to be someone to make sure the models are returning data that’s relevant to what’s being asked.
There’s still much to be explored within the field of AI and it’s something I think all technologists should be following. This isn’t because we should be looking over our shoulder for what’s coming for us, but look at how we can use this to help us in our day-to-day.
Certainly Uncertain
I’m not certain this is how we should be doing our jobs.
Though I largely agree with all of this, the biggest difference I have is treating uncertainty in and of itself as anything different than something that comes with this job. I don’t think the original article was disputing this fact. If anything, it explains what to expect so you’re not surprised.
But if I’m sticking with the analogy, is uncertainty something that “brings elements of dysfunction and unhealthiness into the relationship?” I don’t know if I’d go that far. Learning something new, how to interface with a third-party service, or working with some other technology isn’t necessarily dysfunctional nor is it unhealthy.
It can be exhausting, it can be challenging, it can be frustrating, it can be exciting, but it can be expected.
So as much as I agree with the article and as much as I think uncertainty is something we all should expect, I generically don’t consider it toxic.
Obviously, this is hyperbole but if your primary job as a programmer is to ship functioning code and bugs prevent said code from working or it results the program yielding unexpected behaviors then, yes, you will forever be fighting them.
Bugs Are Part of the Job
Before writing this article, I thought about the various different projects I’ve worked on during my career and how bugs have affected each of them (including ones I’ve introduced).
Some of these projects include enterprise grade web applications with various data center used throughout the United States.
Others are small utilities that have maybe a dozen users.
And then there’s a variety of everything in between.
There’s no succinct way to talk about how bugs are introduced, grow, change, are squashed, and are reintroduced into a software system.
Just another day in the life. Write code and deal with bugs.
The original article has a pretty good statement:
So the truth is you should assume that everything has bugs. That’s why experienced devs never trust their code if it runs successfully on the first try. Even if the QA engineer reports a bug, assume that the bug ticket has a “bug” and check for everything.
And I really like the idea that “you should assume that everything has bugs.” That’s the bottom line, full stop.
I Choose Software Over Hardware Any Day
Software is a broad term to encompass all types of products we use:
iOS apps
Android Apps
TV apps (regardless of the vendor)
Web apps
Extensions
Plugins
Utilities
Operating systems
Components
And on and on it goes.
It’s amazing human beings can collaborate to produce such things (regardless of the environment) and that these things continue to work despite the high potential and likelihood for error that exists.
He’s astounded as much as I am that any of this works.
Sure, we can put in place all types of automated testing around the code, we can hire QA engineers to test all sorts of edge cases, and we can have entire support departments dedicated to handling user feedback, requests, bug reports, and so on.
And still they persist.
Rather see them as an enemy that has to be defeated, overcome, or reduced into nothing as if there are two sides two a war, I prefer to see them as just as part of the job.
Yes, they are frustrated, yes fixing one can lead to another, and yes sometimes an improper merge can end up bringing a previously squashed bug back into the codebase.
But it happens.
For what it’s worth, one of the things that I’ve told myself over the years is that I’d much rather be working on software rather than hardware because the former affords us, among many other things, the ability to ship fixes, patches, and updates in a far easier manner than a physical product.
Though I think coming up with estimates for completing a task may be a close third (or at least somewhere pretty high on the list).
A computer programmer, stressed, as she tries to come up with a clever name for a variable.
Having worked as a contractor, in an agency, and in product work, I can say though there may be small variations on how estimates are handled, the basics are the same such that it goes something like this:
A task is a unit of work to be completed as part of a larger project,
Each task has a start date,
Developers are asked to estimate how long it will take to complete said task.
Here’s the thing: There’s usually an ideal goal in mind for when the task should be a completed. If it can be completed in the ideal range, great; if not, then it has to be scoped so that it fits within a reasonable range. Any work left over moves into another phase of work.
So from the outset of the task, we’re expected to estimate how long it will take to complete the the work even though it’s the period in which we know the least amount the problem domain.
This is why estimates are hard.
There are a few caveats to this that I’ll get to in just a moment, but I want to point out that this is simply part of the software development process. I’d say that it’s almost law at this point (but there are plenty of shops and developers that always surprise us, so I perhaps it’s just an unwritten rule that can be broken).
Suffice it to say, estimating tasks is an inevitable part of the job of a developer. As such, it helps to know what it actually entails and it helps to have some suggestions on how accurately estimate a task.
How to Estimate Writing Code
Yet another programmer staring at a kanban boarding trying to figure out if the next task can fit in the sprint.
Depending on which type of software development lifecycle you and/or your team use, the way tasks are estimated may be different but they are different nonetheless.
The Waterfall Method usually has phases each with its own plan that cascade down into the next phase.
An Agile Method will use something like sprints that then will use some type of measurement (perhaps story points or days or hours) to estimate how long a task will take and then a sprint will only consist of a set number of story points. If a task exceeds that maximum amount of points, it’s either re-scoped or moved to the next sprint.
The Iterative Model works something like creating an MVP and then slowly working to improve upon the base (though how long each team wants to spend on working up from the MVP varies).
And so on.
There are many models that exist within software development but the one thing they all have in common is this:
Everything that needs to be built can be reduced to a task and a task can be measured in a unit relative to the project.
Whoever your stakeholders may be have an ideal number for the units they think are reasonable and they will often vary from what you, as a developer, think is reasonable.
Business revolves around numbers. Every project has its cost, and to calculate the cost, management needs to estimate how long it will take to build a certain feature
Your boss counting his money from all of the time spent by properly estimating taxes.
So, as far as this article is concerned, this leaves two questions:
What are the caveats mentioned earlier in the article?
How do we accurately determine estimates?
Caveats
Whenever I think of someone responsible for building software, I think of people who are working with a consistent set of tools and a tech stack with which they know well.
For some, this may be the Microsoft stack of SQL Server, .NET, and whatever frontend tooling they are using (perhaps its a native GUI or a webpage). For others, this may be MySQL, PHP, and something to render user interface components within a browser.
And even each of those have their own subset of technologies they use. My point, though, is that developers usually have a set of technologies they use to build the solutions for which they are tasked. These technologies are used day-to-day in their job and are primarily how they build their solutions. (This is why we hear if someone is a “Microsoft shop” or a “Laravel shop” or whatever term you want to use.)
This is a software development shop that looks exactly like where we all work, right?
The point of discussing estimates is not to get bogged down into what’s used to build the solution at hand; instead, it’s something more along the lines of “given the tools we typically use, how long will it take to build this solution.”
So the primary caveat is that I’m assuming you consistently work with the same technology stack. This matters because the longer you work with it, the easier certain problems can be solved.
But if it was consistently consist, we wouldn’t be discussing estimates, would we?
Determining Estimates
As I mentioned earlier, we know the least about the problem space from the outset of the project. Yet this is when we’re tasked with estimating how long it’s going to take to complete a task.
Since we don’t know what we don’t know when we don’t know, we absolutely have to be generous when estimating our tasks.
Later, when you start to work on that feature, you encounter many problems that you weren’t aware of when you gave time estimates. Then you need to compensate for the wasted and hope not to break the deadline.
Three scenarios can play out from this. In no particular order:
You may not finish the task within the allotted time.
You finish the task exactly with what time was estimated.
You finish ahead of schedule.
In each of these cases, there’s always more than can be done. But a good rule of them, as written in the linked article:
If I need to deliver some feature, and I think it will take 2 days, I add roughly 40% more time to it, just to be safe. So, in this case, the estimate will be 3 days. Later, if I am done in 2 days, I can just deliver it earlier.
In other words, don’t over estimate yourself and even when you fill confident, estimate more than you think you will need. This will help build out confidence both for you, your team (as well as your project manager, if you have one), and the business.
Your manager terrified of the estimates you’ve given.
If you don’t estimate properly every now and then, that’s okay; but always err on the side of liberal estimates. You absolutely need to account for the things for which you aren’t even aware yet.
Conclusion
I’d be remiss if I didn’t clarify what happens in the three points above for how three scenarios of estimation play out so I’ll do that here (and recap them, too).
If you don’t finish the task in the allotted time, it may be punted to the next unit of work, you may have the ability to ship part of the work while creating a new task in the next phase of work.
If you finish the task exactly with what time was estimated then you’ve estimated well (was it a fluke?) and the feature can ship when expected.
You finish ahead of schedule then you’re getting good at estimating (assuming it wasn’t also a fluke :) and you’ll be able to pick up another task to work on even if it can’t ship in this phase of work.
Ultimately, the longer I’ve been in the industry and using generally the same tech stack, the more I continue believe in the idea of overestimating my tasks. This allows for exploration of the problem domain and the ability to develop a full, working solution within the phase. In other words, if I was to give my past self advice, this is what I would’ve liked to have had on hand.
Parkinson’s law is the observation that the duration of public administration, bureaucracy and officialdom expands to fill its allotted time span, regardless of the amount of work to be done.
This is something you may occasionally hear in software development circles. And though it didn’t originally apply to it, it sometimes happens that way. Thus, part of our job is to make sure that we don’t fall to trap to this and that we properly estimate writing code and stick to it.
This part is oftentimes more of an aspect of self discipline than anything else.
If you’re a veteran – regardless of what technologies you use – you probably already have a strategy in place to help with estimates.
But if not or if you’re new to the field, perhaps this will help.
Kinsta offers premium managed WordPress hosting for everyone, small or large. Powered by Google Platform and strengthened by Cloudflare, they take performance to the next level. All hosting plans include 24/7/365 support from their team of WordPress engineers. Get startedwith a free migration today.
If you are looking for WordPress guides and unbiased reviews, I recommend checking out WPKube. They also have an exclusive deals section.
Just Getting Started with WordPress? I write a lot about WordPress development but if you're just getting started, I recommend checking out WPBeginner. They have free training videos, glossary, and more.
