This Developer's Life Advice

The title is an ode to an amazing podcast, This Developer’s Life (from 5 years ago about the rest of being a developer besides the coding and I wish they’d bring it back for more episodes!). That podcast is itself a nod to This American Life.

I wish I'd been given this advice when I started out as a software developer. It has helped me with my career and I hope it helps you as well. It isn’t developer advice so much as career advice.

1. We’re paid to solve problems, not write code

I think Andrew Hunt relayed this story in The Pragmatic Programmer, though I’m struggling to find the reference. At any rate, the story appears here. Apple had started tracking developers by lines of code written. Bill Atkinson, author of Quickdraw and an amazing developer, had spent the week refactoring to greatly simplify their code. He filled out the weekly report for how many lines of code he’d added that week with “-2000”. That was the start of the end of the "lines of code" measurement.

Nobody cares about how much code you add (unless it’s too much), but EVERYONE cares that the problem gets solved. If you can do it without writing code, that’s the best scenario. The code you never wrote doesn’t have any bugs in it and won’t fail under load. Figure out the best solution, don't just write code.

2. Write it down!

Write down all the decisions made and get agreement on them. This means spending an additional 5 to 10 minutes after every meeting doing that. Why would anyone want to spend more time dealing with meetings? Let me give you an example.

You just had a meeting and it was a little contentious but everyone ended up coming to an agreement at the end. You saw them all nodding along and offering their affirmation in the meeting. Everyone’s finally on the same page, right? 

Write down that decision and make sure everyone agrees to it. Chances are good that some of it was a little vague in the meeting and writing it down forces an extra couple assumptions to be added and… that wasn’t everyone’s understanding. More importantly, nobody will remember this meeting in 3 months and that’s when you’ll have this new feature working - that nobody asked for.

Write down notes after every meeting and share them out. It WILL be worthwhile. It gets everyone to the same understanding. If needed, it can also help settle disputes later on. You’ll build the feature that was actually wanted on your first try!

3. Be a lifelong learner

Almost a decade ago, I went to a developer conference and met a consultant developer that seemed to know EVERYTHING. I eventually asked a question amounting to “How are you able to do this? How do you keep up?” He gave a very simple answer: “I dedicate 10 hours every week to improving my craft”. He spent 10 hours in addition to his job scouring the internet, reading magazines, books, listening to podcasts, and doing anything he could think of to gain more knowledge in our field.

10 hours sure seemed like a lot. Of course, I was doing very little additional learning at the time. I’d occasionally read a book and I liked listening to certain related podcasts, but never with an intentional habit of lifelong learning on a weekly basis.

I’d love to say that I received that advice and immediately started the habit of focused learning on a regular schedule, but… I’m too dense for that.

I then later read a book, Soft Skills: The software developer’s life manual that had 2 related and obvious ways to be better. Note that he has a 10 step process in that book instead of this simplified version.

Do your homework

Spend time every day getting better. This is exactly what that consultant talked about! Learn more every single day. Spend time going deeper on the new concepts you want to understand. Otherwise, focus on where you want to be and what you need to learn to get there.

I have young children and time is hard to come by. Despite that, I set a 30 minute timer every night and make sure that I at LEAST get that much time dedicated to learning. I’m usually reading a book related to what I’m looking into at work, but it gives me time to delve into the details.

Don’t know it? Look it up!

When you come across a concept you don’t know, do a quick search on it. Spend 5 minutes figuring out the broad idea via a quick Google search or wiki lookup. You’ll be surprised how much you just let breeze over you without understanding once you start diligently researching the concepts you don’t know.

Conclusion

That's it. Follow these 3 simple bits of advice and you'll be amazed how quickly you get better at your craft, regardless of what it is. I can certainly attest to it working for software development.