What I did on my summer holiday

in code


I finished with one programming job on Friday and I start my next Monday. That means it’s time for some good ol’ retrospection.

I used to think I was a special snowflake because I fell into coding, but Stack Overflow says otherwise. I wrote a great sob story about my hard-luck, self-taught career, but I could it out because it wasn’t special.

My job was awesome. Yeah, I gripe about parts of it down below, but my experience was positive. I can be negative at the best of times, but it’s true that my work environment was fantastic. My team lead gave me the room and respect to get my job done. He worked to keep us isolated from politics and drama so that we could focus on code. It allowed me to go in, write code, and leave my job at work at the end of the day.

The office was positive-my team welcomed discussion and sharing. My crazy ideas were at least mooted.

1. Don’t be a Negative

Stop here and read Beware of Developers Who Do Negative Work by @PBeekums. His article is a perfect description of my last job. Last year, we lost months figuring out legacy code well enough that for us to feel safe replacing it. While our application was a Ruby on Rails application, the original developer at our company had two problems:

  1. He was paranoid about his job security.
  2. He had a bent for premature optimisation.

These resulted in pithy, undocumented, interleaved code founded on on raw SQL queries. We sunk whole months into puzzling out his code so we could replace it. That situation grew into a personal frustration:

  • We could not add new features because of immense technical debt. We were unable to make progress until we had a solid understanding of the codebase.
  • We were afraid to touch some pieces of code in case we broke the application. Case in point: he used 600 lines of custom SQL queries to simulate a has_many :through relationship. This was instead of the ~10 lines you need with ActiveRecord.
  • We perpetuated our non-conformity with Ruby and Rails’ best practices. This was because there was too much inertia in the current architecture.
  • Technical debt stymied my desire to work with new features and apply best practices.

Don’t be That Guy.

2. Everyone’s Code is Bad (Even Mine)

I used to bitch at length about the last guy’s code, so I’m sure the next will bitch about mine. As much as I gave out about his spaghetti mess, he had still optimized it to fuck. Hand-in-hand with the fact that replacing the old code made out job easier, was that our replacement code was slower. Sometimes it was a little slower, but sometime the application ground screaming to a halt.

Between that and the fact that his code worked, and sometimes worked well, I came to respect his intelligence. I’m sure the next dev in line will what-the-fuck about my functional approach to UI state (and get an itch to replace it).

All code is transient. All code is cursive hand-writing. Everyone else’s handwriting is awful and unreadable.

That's a paddlin'

3. Document, Document, Document

The total lack of documentation why it was so hard to clear our technical debt. It’s a 100-line function of dense SQL statements, which is great except that the function’s name doesn’t reflect its use. I what-the-fuck about the code I wrote last week, let alone six months ago. What’s that, your code is self-documenting? Don’t lie; nobody likes a liar. Do you write JavaScript? JSDoc. Ruby? YARD. Learn to love them.

Two simple simple:

  1. Make it easy for your team to document.
    • Offer up editor macros that insert block comment templates.
    • Show the benefits of documentation through features such as IDE prompts (RubyMine at least reads JSDoc and YARD blocks).
    • Don’t bother with a wiki. Axiom: The best documentation lives and grows alongside your code.
  2. Make it hard for your team to not document.
    • Make comments part of the standard.
    • Reject uncommented code.

4. Be Humble

Like, fuck, sometimes I’m smart. Other time, I tell myself “Well I know better,” but the truth is that nobody can know eventing. I sure don’t_know everything:

  • I don’t know the totality of business requirements.
  • I am mindblind, which means that other people exist at a surface level to me. It takes focused, conscious effort to figure out what is in your head, and a great deal of communication to bridge the gap.
  • I know a lot about JavaScript and Ruby, but only in comparison to my team. What I know is itself incomplete, and limited to what I make an effort to learn. Which means I don’t know it all, not by a long shot.

At least once a week I used bad information to come to the wrong conclusion. One mistake leads to the next leads to me stepping through my code to find the reversion. Be humble and accept that you aren’t always right. Don’t be too proud to listen and learn.

5. Be Arrogant

Lack of knowledge goes both ways: If intelligence and experiences are a cliff, then we went up it different ways. I know what you don’t. My experiences weren’t yours. This is okay.



Replace Odd Numbers of Spaces Only

in code


Your email address will not be published. Required fields are marked *