I was asked recently by a friend of mine about what does my “standard” day of work consist of at Netflix. I had to explain to him that it’s hard to talk about a “standard” day as each day sees me looking at different pieces of our infrastructure and requires different challenges to be solved. Still though, I explained that there are a few common denominators throughout a day in Netflix — and in fact throughout a day of work for anyone who works in software development. And one major such common denominator, as I explained to him, is the fact that we, software engineers (“coders” as we are often labelled), spend lots of ours a day looking at lines of code and producing lines of such code. Then testing it, checking if it works, tweaking it a bit, trying it again and so on until we reach perfection or code nirvana 🙂 At this point we are happy with our work and ready to move onto the next task. (Which more often than not is to deploy that code onto servers, but perhaps I’ll talk about that bit in a separate blog post. For now, I will just concentrate on the fact that we spend a lot of our time in front of countless lines of code — written by us or someone else.)
“Do you guys not get bored?” asked my friend, having listened to my talking about this.
I was sort of puzzled at first: “Why would we get bored?”
“Well — my friend continued (and I have to add here that my friend is not technical at all and as such his view upon this matter is totally through un-biased eyes) — seems to me like all you do is spend 8+ hours a day in front of a monitor just looking at some text which you say is code. I love reading he said but I couldn’t read for 8 hours flat if my life depended on it!”
So I sat down and thought about this a bit more: it is a valid question after all, because a lot of the things we do when writing or reading code are quite repetitive. Starting at the simple scrolling of the screen, to always clicking the same buttons, using the same keyboard shortcuts and looking at screens with results which look very similar to each other. (Think for instance about all the
JUnit tests you ran in your lifetime: the actual screen with results looks the same, whether you are testing a database connection pool, or a simple string concatenation!)
Even more so, when writing code, once we choose a language we always use the same constructs of the language — after all each language is limited in keywords, operators and constructs! We use
for() loops all the time, we use design patterns all the time (and again, there’s only a few of them so we keep repeating them), we even use the same libraries and invoke these libraries using the same code all the time! So why do we actually like doing this?
The reason behind it, when I think about it, is very simple in fact: dopamine! Every single method we write, once we crafted it beautifully, it gives us that feeling of achieving something — and that’s dopamine. Every unit test we pass, gives us the same feeling — and same dopamine! Every bug we fix or feature we introduce in our code shoots dopamine through our brain. It is our reward — and it’s a very similar mechanism you would encounter on social media sites where users are looking for instant gratification (be it “likes”, or shares or comments etc.) — all for the much-needed dopamine!
We, coders, are the same: it’s all about the small battles when you start working on software projects. You keep your eyes on the finishing line, but to get there you need to win all the small battles along the way. And each such win supplies us with dopamine — which keeps us motivated to attack the next small battle, be it a bug which is crashing the project, a new piece of functionality waiting to be designed. And the sum of all these battles sees us finally crossing the finish line, all charged up on dopamine and ready to take on the next project.
Corollary: if you want to keep your engineering team motivated, make sure the tasks you set for them allows them to take this much needed dosage of dopamine daily or even more often. Bury your team into a never-ending project, with no clear milestones and your team morale will hit the ground.
Corollary 2: I’m not an agile methodology fanatic — I like agile approaches, but I think all the time the right tool for the right job, and in some cases agile might perform not as good as say waterfall. Nevertheless, if you have the luxury of choosing in between agile and something else, in the light of the above, think about the fact that an agile approach, with a short sprint, allows your team an injection of dopamine every time the sprint is finished and tasks are done!
To end on a positive (and funny!) note, when I explained this to my friend he said this: “So to sum it up, for you guys [the engineers that is], coding is like crack: the more you do it the more you want to do it.” And I guess that’s probably true: coding is
crack dopamine for us developers 🙂