Tagged with

Reading time: 3 min

Programming starts before any code is written. Being a more efficient developer is more about the ability to plan and execute than raw coding ability. I’ve tried a lot of different techniques to get massive amounts done, and I’ve found the simplest approach is best. I set a goal, have a structure to work towards that goal, and then ensure a solid hand off when finished. Most importantly, I always take a moment to setup a next-step for myself.

Set a Goal

Picking a goal is pretty easy. Usually there is some kind of business or project requirement to start from. The first thing I do is set my goal by deciding how those requirements apply to my codebase. Then I write some basic specs around those requirements. Sure, I turn the specs into tests later, but that is merely coincidental. The real point of those specs for me is that I use them to refine my thinking. I make a lot of decisions about how my code should be structured during this writing phase. As I start to implement, using those specs as tests keeps me on target and reinforces the goal. I’ve found that much of the bad code I have written over the years is due to a lack of direction. Going from spec to test with TDD gives me a structure to quickly write good code.

Structure Your Time

While I’m actually coding, I use the pomodoro technique to structure my time. I typically work in two hour blocks, structured like this:

  • work 20
  • break 5
  • work 20
  • break 5
  • work 20
  • break 5
  • work 20
  • break 25

This isn’t the traditional Pomodoro, but I’ve found this pattern works for me. During the short breaks I typically get a cup of coffee, check slack, or skim my newsfeeds. This is just a mental break to allow my brain to refocus. For the longer breaks, I’ve found doing something physical helps. Often I go for a brisk walk while making calls. The physical activity helps me stay focussed longer, and I’ve found that doing longer sitting tasks, like checking my email, during this time actually lowers productivity.

Hand It Off

As I complete a series of Pomodoros and my goal is nearing completion, I spend some time looking at how I can best hand off the code I’ve been working on. Often, the difference between functional and good code is how well a developer communicates intent. A big part of that communication comes during these handoffs so I work extra hard on writing good commit messages and making solid pull requests for whomever is reviewing my code. Knowing that I’ll need to do this makes me write better code in the first place!

For commit messages, I lead the message with either the ticket number (when available) or a one word description of what I’m working on -- often a model or controller name. I then follow that up with a brief description of what I changed in each section or file. I love doing lots of small commits, even staging parts of a file at a time. A typical commit message may look like: [USERS] added email preference to User model, validated that preference is valid, schema changes to support this. If this is to granular, I’ll roll them up into a single coherent paragraph with a rebase during my pull request. Again, I’m writing my commit messages as a method of keeping myself focussed on my goal, and making it easy to communicate my intent with the changes I’ve made.

Great commit messages make an eventual PR easier to write. It is very easy to roll those commit messages up into a single package. When I make a PR, I also try to include ticket numbers, and relevant screen shots (or gifs) if there are major UX changes. Finally, I make sure I’ve pulled or rebased off the latest HEAD branch so that merging is easy.

Then I go through that final PR checklist in my head. I want to make it easy on the reviewer by giving them a road to follow. Are there tests and are they passing? Does this match the goal I began with? Did I base the PR on the correct branch? Did I flag the reviewer in the comments and ask for feedback? This last part is especially important if you are blocked. It’s always OK to ask for more clarification or help. If I’m stuck for more than 20 min or so, I reach out for help.

Figure Out What’s Next

That original goal you set should inform you about what’s next. Maybe there is a follow up ticket, or it’s time to set your next goal. Either way you should always figure out that next step before stopping -- and document it. This reduces friction to starting back later. Maybe you’re stopping for a Pomodoro break, or you got interrupted by a bigger problem. I always try to finish my thought and throw in a comment on what I was doing before hitting git stash and addressing fires. Fires happen, but context switching is expensive and should be avoided whenever possible.

I treat my development workflow as a system, and constantly evolve little pieces of it. Following these steps has dropped my stress levels and upped my development speed which has made it a great system for me. I don’t think everyone should adopt this workflow, but you should find one that works for you. Constantly play with something new and see what works and what doesn’t.

The real reason for this post is I’d love to try out some new stuff, so leave a comment about what works for you.


C69b05d12e2e59023ccd2cd030fef830?s=184&d=mm

Adam Dill Adam has over 19 years of software development experience, and has spent a good part of that educating new developers. He was previously CTO at inside.com and Development Director at Maxmedia . When Adam isn't coding, he is off hiking in Colorado mountains, or practicing some pretty fly martial arts. He thinks swords are cool.