Things I’ve learned about software development (so far)
About a year ago, I left the comfortable worlds of Customer Support and Product Management and joined a Test Automation team. After years of writing my own dinky scripts and tools for customers, I made the switch to being an honest-to-goodness professional programmer.
Having worked just about every role around development (QA, project manager, product manager, documentation, etc), I figured I had a pretty good idea what being a software developer would be liked. Turns out, there are a few more things that I didn’t know which smacked me in the face pretty quick. Here are a few of them, in no particular order…
Software gets really complex, really fast.
I started a rant on Facebook last week with the following:
Reasons why programming is somewhat frustrating:
Performing simple instructions such as:
(1) find the server
(2) connect to the server
(3) ask the server for the information
(1) Find the server
(2) handle the situation where we can’t find any server or we’ve found more servers than we expected
(4) figure out which server is the one we want to connect to
(5) check if the server is there and running and handle if it is not
(6) make a request to the server for the information
(7) handle the situation where we get an error
(8) verify that the information we got is somewhat close to what we were looking for (right format, structure, data type, etc) and handle if it isn’t.
And people wonder why software sometimes has bugs…
And that’s just a simplified example. We take a lot for granted as human beings… our brains fill in a lot of gaps, recognize patterns and optimize, and parse otherwise abstract concepts so that we can function. That becomes hauntingly and infuriatingly evident when you are dealing with something that doesn’t understand abstract concepts and need to be told precisely what to do.
You have to think not only about what you want to happen, but every tiny, blinking, little thing that could go wrong along the way. There’s a level of insanity that comes with that kind of thinking in all directions at all times.
Programming is more art than science.
For a long time, I used to see programming like accounting. There’s not a lot of creativity, there is simply the purity of numbers and the long laborious slog to reduce them to their summary information.
Programming on the other hand has a lot more in common with painting. As a programmer, I’m trying to express an idea, broken down into its literal logical parts, breaking and reusing everything around me. Sure, there is the science of understanding structure and design, knowing my language, toolsets, and APIs; but most of the real work… figuring out how best and most flexibly to solve an issue that has been given to me, is real creative work. That also means we have the same needs as creative types.
When the mood strikes, and I’m “in the zone” the code just flows. Roadblocks are stepped over effortlessly. The code written is usually high quality and does the job (and usually goes beyond it).
If I’m not in that mindset, then forcing it causes issues. Roadblocks stop me. Code is low quality, and feels like pulling teeth to get it to work. When I hit these moments, I try to take a walk, or work on something else, or worst-case stop working altogether and do something else more enjoyable; and re-approach it later.
For my managers that are developers, they get this. To non-developers, it looks like lollygagging.
Little things scale fast (or how I learned to love and hate logging)
“Yeah, add that to the log. C’mon, it only takes like, what, 0.002 seconds to write that?”
I used to say stuff like this. Here’s the thing… computer software is best when it takes care of boring repetitive tasks for us. The more it can repeat things that we don’t want to do, the less that we have to do that stuff. Now, imagine something that takes 0.002 seconds and repeat that 100,000 times… that’s 200 seconds. Add into that all of the things that can delay that experience, and you find that the little thing became a big thing pretty fast.
Estimates are the bane of your existence
“Yeah, you know that thing we want you to make that doesn’t exist yet? How long do you think it will take you to produce it?”
Estimates are hard, primarily because you don’t know what you don’t know, so there’s no telling how long it will take. You may start coding and find a million roadblocks that slow you down or outright stop you; or you may find that a task that looked daunting is actually far simpler than you thought. Because of that, what you estimate, and what happens may be two very different things.
If all of that wasn’t enough, you will say “estimate”, and often, others in power will hear “deadline”. They don’t care about “excuses”, they just want to know when it’s going to be done. It’s a lot like trying to predict where an arrow will land before you’ve even drawn the bow.
Those are just the ones so far. If you have some of your own, drop them in a response!