So you’re trying to write that awesome new feature you’ve been chomping
at the bit for, right? Your gonna get it done and it’s gonna have so
many bells and whistles! Let’s say you give yourself two weeks to get it
done, but at the end of one week you realize you just can’t finish it in
one more week, right?
Been there, done that.
Here are a few things that I’ve found that really help keep me on track
and keep code flowing even when a feature seems so far away.
Keep it simple (commit)
So I have this tendency to go off and work, work, work. Code changes
pile up until I finish a feature or a ticket and then I try to sort it
all out in the end with git diff and git add -p. This is bad, I wouldn’t
advise working this way. If you practice BDD, you should setup a
describe block with some tests, make them pass and then do a commit. In
the end, it will help you feel you are accomplishing things while making
things like a rebase much smoother. Be atomic.
With so many distractions around today, it is a wonder people still get
work done. You know what I am talking about: email, IM, and twitter!
Maybe it is YouTube, gaming, or Huffington Post? Either way, I find I
work best when I have a focus time. I set aside 1 to 2 hours a couple
times a day in which I shutdown all distracting programs (ichat,
campfire, irc, email, twitter, etc) and make sure I really focus on the
tasks I need to do.
This focus time has really helped me increase the flow of code, and I
would recommend something similar, maybe even the pomordoro technique if
that is your thing. Focus on coding.
Don’t work in a vacuum
I work on a team of four developers and it is very important that we
review each other’s code, discuss how to approach problems, and help out
with pair programming. We have a 2.5 week iteration cycle, and then
production is branched off from master, so that we can keep working on
master. It is important that we push code daily to ensure we can easily
work with each other.
The added benefit is that your topic branches will stay up to date with
master and you will minimize git conflicts. Pushing at least once a day
also adds to that snowball “accomplishment” effect as well. Feature or
bug not completely fixed? That’s ok, push what you have with passing
tests - then go back to being heads down for a few more hours. Share
Spec, spec, spec
I know this might sound goofy, but BDD really does work. Write your
failing spec and make it green. Writing your specs force you to think
about how your code works and what the interaction interfaces look like
- this means you have clear goals when you start to write actual code.
I had a friend IM me to ask how to write a non-database model and he
laughed when I told him to write specs for it. Don’t get me wrong, he
tests sometimes, but he wanted to spike this. I told him to start with
the tests, the DSL would write itself as he put tests together.
BDD is important because it makes you think about the code you write,
but it is also important as a bug finding tool. I found myself writing a
simple MVC stack the other day and I wrote the model specs to handle
some special update methods, lo and behold the specs uncovered a bug I
accounting for in my code. I wasn’t testing for that bug in particular,
nor was I coding to make sure it worked, but I still found it by having
This one is really important. Spec, spec, spec.
Thanks for the mem…
I know some of this may seem like common sense, but this stuff kind of
emerged when I started changing my patterns and habits to be more BDD
and more team oriented as a coder. This is new for me because despite
having worked in teams before, we always seemed to work separately.
If you glean nothing else from this article, please consider this:
Spec first, it works. Commit early, commit often.