Software developers: don’t blame yourself

Are you a software developer? Do you agree with these statements?

  1. New code will have bugs.
  2. Old code also has bugs.  They’re just less obvious.
  3. It’s easy to make a mistake.
  4. No matter how much you learn, there will always be something you don’t know.
  5. A small change can have a big effect.

If these facts are true, those are all good reasons we shouldn’t blame ourselves when we make a software development mistake.  We live in a reality where most software systems are very complex, and far too complex for us to comprehend fully.  We should rely on automated tests, tooling, version control, QA, and other things to help us do the best job that we can do.  But, it is impossible to know all.

Perfection is not possible; nor is completion.  Successful software programs meet the desired goal; or, solve the desired problem; they create value.  Value is not determined by the number of open bug reports.  There will always be something wrong or incomplete.  Therefore, you should not base your self worth on how “good” your program is.  You are not your program.

Rather than feel bad about yourself, think about how it could have gone better.  Could you have tested better?  Could you have had a better plan for reverting if something went wrong?  Git revert is your friend, and not a sign of failure.  By reverting, you have learned something, or will learn something, and hopefully won’t make the same mistake twice.  Growth requires experience, and the only way to get experience is by doing.

There is a reason why software developers use version control.  Embrace that power.

A revert can feel like a public omission of making a mistake, but it could also be seen as the first step in fixing a mistake.  Taking action is better than inaction.

Forgive yourself and your co-workers for mistakes.  Let go of your ego.  There will always be a problem to solve.

I also like to say that “most people don’t know what they’re doing” but that’s a bit egotistic, because in my head, it is silently followed up with “…. but I know what I’m doing.”  But the truth is, I only know what I am doing to a certain point.  I may have mastered one aspect, but the unknowns are in a pool nearby, and I have to wade into the pool of the unknown on a regular basis, or else growth would not occur.  Every expert was an amateur first.

Put out the fire first.

Listening to some podcast which I’ve long since forgotten the name of, I heard a top executive talk about how there was always the fire of the day to put out.

Surprisingly, this small comment changed how I thought about my work.  It’s not just about putting out the fire of the day, but also about preventing the fire from starting.

We have a list of things to do — whether it’s in a notepad or in the sprint backlog, but despite what scrum purists would have you believe, the more important thing is to put out the fire — or stop one from starting.

And how do we do that?  It all comes back to the people you work for.  If they come into work with some burning issue on their mind, address it first.  Their fire is more important than anything on your to-do list.

Small fires are easy to put out.  Putting them out is one of my keys to happiness.

Let it grow big because you’re “too busy” and the fire will spread, and you may not be able to put it out.

Daily fires are a thing.  Put them out before they grow.

The Best Code is the Code you don’t write

Earlier in my software development career, I would get an assignment and eagerly jump into writing the code.  Hours later — after frustration and then the joys of success — I had the code done.

Writing the code was a learning experience for me — I got better at programming the more I practiced — and this was all ok.

Sometimes, the client was super happy and the task was done.   The computer did what it was supposed to do.  Assignment completed.  Yay!  I felt like a genius.

Other times, it turned out that my interpretation of the requirements was not the same interpretation that the client had in mind, or the business requirements had changed in the meantime, or for some other reason, the outcome was no longer the desired one.  So, I’d have to revise the code, change it to meet our new shared understanding of what we need to accomplish.

As a programmer who is learning, having to go back and write more code, is not necessarily bad.  It means more experience.  But, from a business perspective, this means wasted money, wasted time, and a longer route to getting to “done.”

At a certain level of expertise in any given programming domain, there is no longer a question of whether something can be done, but whether it is the right thing to do.

The vast majority of client requests are completely feasible.  It might take 2 hours or 30 hours, but a programming solution is possible.  There’s very few tasks that are “impossible.”  It’s more a matter of whether it makes business sense to spend the time on the task, when there may be other items that would derive more business value.

Since I work at an agency, I use the term “client”, but this applies to any programming endeavor.  Just because you can think up the programming solution, doesn’t mean it would be the best use of your time to implement it.

I love designing software systems.  In my mind, I can solve any problem.  But, I now do not actually write out the code until I am sure of the value it is going to provide.

“Value” can mean a lot of different things.

If you’re working for a client, it’s most often business value — maybe the code is going to provide a proof of concept, maybe it’s going to bring in additional revenue, or maybe it’s going to automate something.  In these cases, your job as a software developer is to ask the questions to make sure you understand the value you are delivering.  Don’t write the code first.  Instead, read and ask a lot of questions.  You will hopefully spend less hours programming the wrong solution.

There are times when the “value” is the learning experience.  Which is 1000% awesome.  But, don’t mistake that kind of value from business value.

But, if the code isn’t teaching you something, or isn’t generating money, I’d ask, why are you writing it?

So step back, imagine the systems in your head, and ask questions.  As a skilled WordPress plugin developer, I once imagined a whole plugin…. and I enjoyed thinking about the software I could build… But then I realized that it was completely unnecessary.  So I didn’t write it.

Just because you can, doesn’t mean you should.