2 Familiar Problems for Software Developers
I just passed my first year with the company I’m working for. I had about six months of development experience prior to this, but that was rudely interrupted by company-wide layoffs, so this is my first bit of consistency. At this point, I’m familiar with most of the code base, proficient in the tech stack, and able to do “Google-driven development” for the things I forget.
However, I’ve discovered two hard parts of this job. Interestingly, they’re very similar to the hard parts of other software jobs I’ve had before being in a dev role.
Discovering the Real Scope
I now have a pretty thorough understanding of why developers spend so much time in meetings: Words are hard. Customers have an idea of what they want, and they try to describe it to us through conversation and mock-ups. But a lot of understanding falls through the cracks.
A lot of my time is spent trying to discover what the real need is, and what software might help that. I developed some habits from years spent as a tester. I generally ask some questions right after reading what is in the work tracker, even if I was present in the initial planning meeting.
If the change is big, I’ll get feedback every few days while I’m writing code. If the change is small, I’ll try to get some feedback before it’s in a test environment.
The goal is to discover gaps in scope early and often, with the understanding that there are always gaps.
Skinning the Cat
Once the client and I have settled on what work actually needs to be done, there is another question of how I should do that work. I have a couple of constraints to work within, namely the technologies we are currently using and the patterns that have been established over the six years this product has existed. After that, it’s a question of what code I can put together to satisfy the customer’s needs.
A few weeks ago I was working on some code related to permissioning. I missed an important state on the first pass and discovered it by using a pen and paper to make a truth table. On the second pass I had all of the states covered, but there was a bug in one of them. After that, I read the code, and it just wasn’t aesthetically pleasing to look at. (Another way to say that is that if someone else were reading the code, they would wonder what the heck I was doing and have to read it a few more times.)
You can have code that works, or code that works that other people will understand. Usually we land on code that works, but the ideal is code other people understand, and there is no one right way to get there.
