Every once in a while my brain would get into this weird mode where it starts analyzing my latest thoughts and experiences. And then it would come up with some revolutionary insight. The kind of insight that makes you go “whoa, how come I never knew that” and your whole life is different. You start looking at things differently.
But then immediately after, it goes into “Yeah but that’s obvious, everyone knows that. As always I’m the last one at the table”. With that “so what” attitude I carry on with my life. Up to the point when in a conversation with someone there is a hint that maybe actually the person I am talking to didn’t have that realization yet. “Could that be true? Maybe I’m not the last one after all”.
What you are about to read is one of those things. There is a high chance that you have already been there. And that’s awesome. But if you didn’t, well maybe you will learn something.
Where it all started
To give you a little bit of context, first, I would like to tell you a little bit of my life story. Or just part of it. Or to be exact, the part where I am a software engineer. Don’t worry, I promise it’s gonna be short.
So my career originate as me being a Java Developer. Whenever I tell this part to anyone that knows me at least a little bit, there is usually some chuckling involved. The mischiefs of a young adept before he found his way as Ruby Dev. (Or lost his way depending on who I am talking to).
This job was at a very small company. Just me and 2 other guys. I think my official title was Junior Java Developer. But I was more like an intern, at least in the beginning. Long story short I was clueless.
My job was pretty straightforward. I would get told “hey we need this and that part to work in the following way”. And then, with a lot of questions from my side and with varying level of success I would translate that into code. So that is what I did. I translated what I have been told to do into code. Piece of cake.
When the shockwave of global financial crisis finally reached Scandinavia (where I have been working at the time) there were few things that happened. One of them was that the project I was working on was put on hold. The eternal hold. So I had to move on.
That’s how I ended up in my next stop of the journey. It involved finding (losing) my way as Ruby Developer. In a little bit bigger company – it was me and 3 other guys (or actually cofounders) this time. And I was the only software-development-savvy person in that group. So I was the only developer. The Lead Developer, you might say (though there was no one to lead).
Except from one additional person and a little bit more of self-reliance, the job in its essence was similar. The co-founders had ideas for how their business should work and my task was to translate that into code.
Next stop was Applicake – a software house, and if you are ever a participant in a startup trivia quiz you may find it useful to know that it was run by more-or-less the same people that started Base.
As it was a software house, this time I was building software for our clients. Usually those clients were early-stage startups so we were building prototype, MVP, initial-stage apps for them. The team working for a particular client was usually fairly small, which meant not much communication overhead.
If I were to sum up my job there, again not surprisingly, it was mostly translating ideas (this time from our clients) into code. I am a coder after all.
And then I came to Base. And when I came here I started doing what I knew best – what I was doing since the inception of my career – I started writing code. That was what I felt I should be doing. And why I was hired. If you want to get a glimpse of how I felt about code, just watch this video:
It was working in the beginning. I was closing my tasks. I was producing my lines. I was adding features. Everything was as expected.
However, at some point our team got just a little bit bigger. And our projects would get just a little bit more complex. The next thing I knew was that we needed to schedule a meeting with another team to discuss how we want a given feature to be done. Get ideas, share ideas and discuss. Every time I would go for a meeting of that sort I was thinking “ok, let’s just get it over with and I can go back to my real job”. Then we would make some decisions and we would need to have them written down somewhere, so that we can fall back on them if needed. But it was a middle of the day. And I had a lot of energy. I didn’t want to “waste” it on writing ideas. I wanted to do my real job – which was writing code of course. So I would postpone that task. “I will do it when I am tired and I am about to go home”.
“Second Order” Jobs
So the thing is that if the organization you are working for is getting to a particular scale you can’t “just code”. There is a lot of things around the code that have to be done. Sometimes you need to talk and discuss, share your point of view and learn points of view of others. You have to gather information and make decisions. And then you need to share those decisions with the rest of the team. Preferably have them in written form so that when asked in few months you can get back to them.
The problem I had was that every time I would need to do one of such things, I would always postpone it. After all it is not why I am here. When working on those tasks I didn’t feel like I am doing my job. It’s not why they got me here. Or so I thought. All of those tasks were second order jobs for me. Not a real thing. Just a distraction.
With time I started noticing something interesting. The people that had the biggest impact on the company would seem to have a different approach. Instead of shunning those tasks they embraced them. Actually, they put as much work into them as into the code they were producing. At first that would seem ridiculous to me. We have deadlines. We need to ship stuff. Why would you waste your time and energy on those tasks?
This has been on my mind for quite a while. Up to the point when I started questioning myself. Why am I here? Is code really why they got me here? At some point one of the answers I gave myself was – I am not here for code. I am here to move things forward. To ship the product we build. Code is just one of the tools. It’s the tool I feel most comfortable with, for sure, but it’s not the only one. And maybe not the most important one.
So what are you saying?
A few weeks ago, after a finished project, we had a retrospective meeting. We talked what went well and what should be improved. One of the items we had in the “Problems” category was: we had a lot of open Pull Requests and not reviewed for substantial periods of time. From the first look it does not seem like a big deal. But it was slowing us down. Other team members would need those not-yet-merge parts for their code. They would either have to wait or branch out of that PR. As a result we would get a lot of cognitive overhead, code conflicts and so on.
Now, why wouldn’t we review those Pull Requests? One thing for sure is that reviewing other people’s code is pretty hard. Especially when you know you would do something differently, but you can’t really verbalize what exactly and – especially – why.
But I think, our main problem was different. So I looked at myself and how I approached that. When I got a PR assigned, I didn’t think of it as my main task. Something that I was accounting for when planning my day. It was not my “real job”. Instead it was something that would happen “in between”. I would finish one task and then, whilst having some “free-time”, I would glance over the Pull Request. Seems that I saw this kind of behavior before. Remember those meetings and writing documentation?
Why wouldn’t I think about it as something that I had to really focus on? Well, for one thing, it was not writing my own code. And as I have said before, if some task didn’t involve me writing code I would put it on the “irrelevant” shelf in my mind. The fact that it really hurt the progress of the team… that was lost in translation.
It turned out that I was not the only one to feel that way.
Where do we go now.
Probably this may differ from company to company. Sometimes it may be actually true that your only task is writing code. I was there during my career. But there is a chance that maybe you need to switch your mindset a little bit. It may turn out that among some of those task that you think of as garbage there is quite a bit of treasure. Something that really pushes everyone and everything forward.
And yes, if you focus on your code, probably you will ship your parts sooner. Moreover, thinking about other tasks may be treacherous – it is easier to fall into “being busy” but not “being productive” trap. So it’s safer to just stick to your code.
You shipped your part. Your little raft is afloat now. But does it really matter if the real reason you were brought to the company was to build a cruise liner?