Notes from The Developer’s Code book

Start from the most interesting task first. We’re allowed to do that as developers, a more realistic timeline can be established once we have practical experience in doing. Only then will we know how much time is accurately required to finish off the remaining tasks.

As Parkinson’s law states, “Work expands so as to fill the
time available for its completion.” When I was able to be “at
work” any hour of the day, there was a whole lot of time to
fill up. Suddenly, my 40-hour work week turned into a 168-
hour mush of work, sleep, and kinda-being-around-work.
Working from home is a luxury. Most people would trade
a two-hour commute for a fall-out-of-bed commute. But if
you have that luxury, don’t code in your bedroom. Or your
living room, for that matter. Find a confined area to work,
preferably a second room, where you can physically leave
from after your workday is over. Shut the door at the end
of the day, hang up the “Closed” sign, and get on with the
rest of your life until tomorrow.
That’s how you really live The Life.

Set in stone a 2 hour no-distraction block for everyone in the team to be isolated. Specify delegated responsibilities to ignore the team white-noise; there is no “We”, there are just unique tasks to be done.

Most programmers I know don’t even care that much about
what it is they build or who they’re building it for. So long
as they are solving an interesting problem and so long as
there is an opportunity to build something elegantly, they
are content. The exercise of dissecting a problem and solving
it masterfully is the mental drug that keeps programmers
We build and design software because, whether found near
the surface or buried deep into our souls, we actually love
doing it. The best programmers I know toil over every small,
sometimes insignificant, development decision. Like those
construction workers, it isn’t just about writing code; it’s
about writing code well.
Those who love this job aren’t in it just for the money. There
are easier ways to make money. This vocation is completely
of our own choosing.


Now read this

Test Driven Development in Ruby tuts+ course - Stubs and Mocks notes

Stubbing - A technique used in TDD/BDD allowing you to simulate using third party dependencies for your own code. Example, retrieving data from a database, you pass a “splat” = dummy data to a stub. We have no control over what our data... Continue →