It Only Took Me Eight Hours to Write Two Lines of Code
I’m not one to talk about productivity. Sometimes my days go by without any progress at all, and I need to make up something for standup the next day. That’s sometimes because I haven’t slept well the proceding night, it’s sometimes because the team doesn’t have any work to do.
There are other times where I just…can’t. I suspect that’s the case most people reading this blog can sympathize with.
Not Even a Cat Video
I’m six hours into my workday. I haven’t typed a single character. Nothing. I haven’t scrolled through a “social media” feed in all this time (check my Twitter for confirmation). We’ve just had sprint planning, and there’s nothing on my board.
I’m sitting. I’m trying to figure out where to put the two lines of code in architecturally. I’m trying to do so without the ghostly reassurance of AI, which would tell me the solution in a second.
If I searched Stack Overflow the difficulty of this would be somewhere between “hello world” and “in which module do you put Hello, world”.
I blame the codebase, you’ll think I’m procrastinating. It’s my stubbornness trying to figure things out for myself since during interviews you are assumed to know syntax and shortcuts without looking things up. If you are unable to reel off code at speed, there will be question marks over your application.
So here we are. Not enough skills to pay the bills, and an unwillingness to do what is needed to simply get the job done. If I push some code that makes no sense, my reputation will take a further dive. What to do?
The Legacy Maze
It isn’t completely my fault. The project is an architectural disaster, and not something you usually want to dive into right before lunch. Finding my way around the code, digging in and suddenly … realising I need to use that analytics module nobody maintains and is unavailable from my service.
Somewhere, deep within this digital Escher sketch, was the appropriate place to add two lines.
But to add these two lines would take a refactoring the size of a week’s worth of tickets. Nothing was obvious. Each function sprawled across functionality, with outdated and contradictory comments. I’ve written on this blog before how asking for help has backfired on me previously, so I’m not doing that. I search through Slack in vain. I look to the sky. I think about crying.
Social Combat
I know if I place these few lines in the wrong spot I’ll invite the full wrath of the code review.
The cherry on top? If I placed those lines in the wrong spot, it wouldn’t just break functionality. It would invite the wrath of those who want to prove that they are the chosen ones when it comes to unwritten rules (because they think them up, but don’t need to follow them).
I’m no longer naive. Even if code is flawless, documented, tested, beautiful, I’ll still be roasted because it has been decided I didn’t document my work adequately. It was decided before I worked for the company, the irony that their rules about documentation are undocumented completely escapes them but nevermind. I’m sorry, I’ll do better next time.
Sometimes I wonder if my team cares more about power games and making sure it looks like you’ve worked than actually working.
The Myth of Time Spent Coding
People assume developers spend most of their day… well, developing. Writing code. But if you think that, you haven’t done this job long.
My day was a greatest-hits compilation of:
• Reading unreadable code
• Untangling business logic wrapped in three layers of abstraction
• Decrypting commit messages like “minor fix”
• Trying to predict which teammate would be most offended by a refactor
Eventually, after hours of archaeology, I placed the two lines.
And do you know what happened?
The code worked. But the PR sat unreviewed for six hours.
About The Author
Professional Software Developer “The Secret Developer” can be found on Twitter @TheSDeveloper.
The Secret Developer writes solutions in 15 minutes, and it takes all day to be allowed to push them into production.