In programming hell the keyboard layout changes every day. The Internet is laggy. The backlog is so long, it can’t even load. The control and shift keys only work half the time. You may only use pico as your editor. Tab completion never works. OS updates come out every day. OS updates occasionally don’t work. Sticky notes with highest priority cover every surface. There is a lack of natural light. Partly because of the line of people at your desk and the manager breathing down your neck. Long meetings full of powerpoint presentations occur twice daily. There is no way to mark an email as read! The servers are always down. Of course, since it is hell, the air conditioning was never installed… ahhhh!!!!
Given that, my goal is to end up in programmer heaven which I imagine to be:
An office with a comfortable sit stand desk and a big window that natural light pours into. My workstation comes with a giant set of screens and noise canceling headphones. The project has clear time lines and well written specs involving really cool technical puzzles. The code is solid and we are always ahead of schedule. The customers love us. The company is profitable too!
Unfortunately, there is hell on earth in the programming world.
Many of us have encountered a code base so screwed up that maintaining it can cause PTSD or other psychological disorders. I’m talking about the kind of system that makes programmers run and hide.
It stands to reason, whoever was responsible for writing that crap is probably going to programmer hell, right? Actually, I’m not sure if being associated with such a project is grounds for being eternally damned. I really hope it is impossible for one person to screw something up that bad.
It is more likely the blame goes to the overall systems put in place which allowed the bad code base to come into existence. Big code bases are not necessarily all bad. I’ve worked on huge systems with hidden gems buried in them. Maintenance can actually be really satisfying once you get your bearings.
There are a lot of companies that don’t value software, don’t understand it, and honestly don’t like being forced to invest in it. That is where the hellish environments originate from. They can be avoided, and in many cases improved.
How do we get to programmer heaven and avoid hell?
Aside from working at a good company, and not be a blackhat hacker, there is a lot the individual developer can do to control their destiny.
Code side of it:
- Name things so it is obvious what the thing is and or does.
- Comment code in the tricky / non-obvious sections and where the spec seems strange.
- Code defensively – distrust incoming parameters (null, wrong type, incomplete, etc) and do not take external resources for granted (database, file system, APIs, etc).
- Break up large methods into smaller chunks, and write unit tests if feasible.
- When an error occurs make sure to log everything about the current state.
- Use transactions whenever manipulating multiple records at once.
- Read your own code changes before committing.
- Read at least two books cover to cover on the main technologies you are working with so you don’t make the same noobie mistakes everyone else is making.
- Launch code you can live with, don’t worry about gold plating it (appropriate to the context you work in).
- Use a code linter and formatting rules common to the team.
- When designing features and architecting for the ‘future’, consider one of my favorite acronyms – YAGNI (you ain’t gonna need it).
- Make regular backups, especially before pushing changes live.
- Always work to make the code base a little better with each commit.
- Do not try and wall yourself off thinking it is ‘job security’ like a stupid barnacle.
Work side of it:
- Be honest about estimates (maximum padding 2-3x). In other words, if you think it will take 8 ideal hours, tell them 16-24 at the most, but don’t tell them 36, then deliver it after 80 hours. Also don’t tell them 4 and deliver it after 7 with a bug included.
- Try to beat your estimates, and pass the savings back to the organization.
- Share your knowledge, especially when asked, and sometimes by your own initiative (eg tune up the Readme file when it is out of date).
- Look for holes in the spec and ask questions. Ask as many questions as it takes until both sides completely agree on what it is that is being built.
- When incurring technical debt, be open about it and get approval first. Don’t create technical debt on your own without your manager being aware. Keep a list of all the technical debt that everyone can refer to.
- Understand the business first, then apply the technology to that. Being obsessed with technology for technology’s sake can lead to serious mistakes.