Everywhere I’ve worked, there’s a hidden (and sometimes not-so-hidden) expectation that code constantly get pushed out. Code not being pushed is a red flag. Make sure you take no longer than a week for a Jira ticket or a Github issue. Have you been taking longer than a week? Expect to get pinged on Slack:
your-friendly-project-manager: Hey, how’s it going with ABCD-123, need any help?
And, I get it: that’s the PM’s job. But I’m also trying to do my job: not just writing code, but writing good code.
An AGILE Trojan horse
If you bring up evaluating programmers based lines-of-code these days, most people agree it’s archaic and ineffective, but lines of code are back, you see: it’s called velocity. “Are you happy with your velocity?” an engineering lead might ask you. “We should work on our velocity…” a product manager might balk.
Velocity is another (more polite and trendy) way of essentially evaluating programmers on how much code they write. And this has all the implications you might imagine. “Velocity,” according to Scrum Inc., is:
Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totaling the Points for all fully completed User Stories. […] Velocity is a key feedback mechanism for the Team. It helps them measure whether process changes they make are improving their productivity or hurting it. While a Team’s velocity will oscillate from Sprint to Sprint, over time, a well-functioning Scrum Team’s velocity should steadily trend upward by roughly 10% each Sprint.
We can ignore the downright ridiculous idea that efficiency should trend +10% ad infinitum, but level of effort (and therefore the point mechanism) will often involve how much code — and implicitly how difficult — a particular feature might be. What velocity ignores is one key element of writing good code and building good products: thinking.
Using your brain
A lot of times, thinking about how to build something is harder and more time consuming than actually building it. This might seem like unnecessary meta-cognition, but it’s not: even before writing a paper, you might need to write up an outline. An outline might turn into a rough draft. After a few edits, the draft turns into the final product. Software is very similar, but that’s not how we build it.
Instead, we build features that are stuck to other features using duct tape and superglue. Sometimes, we have fancy names for shoddy software: we’re building microservices, guy! No one has time for refactoring or cleanup. Unit testing? We’ll throw those in the backlog; they’re not high priority. Inevitably something breaks, a customer complains, and we’re off to the races: who’s on call this week? Good luck.
After more than a decade working at software companies, I’ll be the first to admit that I’m part of the problem. I don’t push back anymore, and I’ve conceded more times that I can count. I know we’re building bad software, but everyone else is doing it, too.
How much is too much?
Why is this happening? It’s just too much darn code. Too much code to read over, too much code to review, too many pull requests. It takes time to mull over questions like:
- Is this the best way to do this?
- What are the trade-offs between doing it this way or that way?
- Should we re-architect part of the code to accommodate this new feature?
In fact, these questions tend to wax creative, and not technical. But I’ve never seen a Jira ticket entitled “Ponder over proposed architecture” or “Think about better ways one might implement this.” Do the tests look like they’re passing? LGTM, merging ✔️
Don’t just write code quickly; write code well. And please stop writing so much of it.