This is the second part of the post on “things I learnt at my first software job”. Here I’m talking about work-life balance, managing technical debt and voicing different opinions in a company. You can read the first part here.
Conflicts ≠ differences of opinion
While straight-up personal conflicts are bad, different opinions are not. I won’t write a lot about the benefits of the environments that encourage different opinions - a lot is written already. But to reiterate - they are not the same as differences of opinion. Arguing about workflow or the product is good as long as people involved are not doing it for egocentric reasons - simply to push their opinion, arguing for the sake of arguing. On that latter point - I realised that falling into “arguing for the sake of arguing” trap is not just for few selected egoistic individuals - it’s very easy to develop this addicting habit (guilty)! So my advice to anyone engaging in frequent arguments and debates is to periodically ask yourself - am I just being a prick?
Refactoring and technical debt, like, in general
Apparently, it’s a cliche for a junior dev to want to refactor half of the codebase on their first day. I definitely was that guy. And I was wrong (or was I?). And then I stopped worrying about refactoring that much. And was wrong again (or was I?)
Here is how every conversation ever about refactoring went with my boss:
We need to dedicate some time to refactoring because clean code is easier to work with, which means less time building new features, easier testing, easier onboarding and perhaps better performance.
However,
we have to deliver a project by the end of the sprint, the existing code works well and people understand it enough to work with. It might take a little longer to develop a feature, but I feel that the time spent refactoring might not be worth that speed improvement. Moreover, it’s hard to measure the effectiveness of refactoring, hard to estimate and might take longer than thought with minimum benefit and no direct value to the customer.
However,
we need to dedicate some time to refactoring because clean code…
This is relevant not simply for refactoring but technical debt in general. The temptation here is to use some magical rules of thumb from the latest blog that will give you straight yes/no answers to whether refactor or not. Managing technical debt is more like balancing on a rope than following a workout routine - it takes experience and good product knowledge to know when and how much. There are many benefits to clean organised code, but sometimes there is nothing more important than time.
So, devs, before getting frustrated that you are not getting time to refactor old code, try to listen to team leads and understand that business goals are the priority in business. Team leads, listen to your devs and try to understand the benefits of putting aside time to clean up the code. Only through this dialogue, when all sides of the business are considered, the team will get better at managing the technical debt.
Work/life
Another junior dev cliche is the eagerness to prove themselves and willingness to work beyond working hours. IMO, that’s not bad. In fact, it’s close to necessary in the beginning, when the amount of new technology and codebase to learn is overwhelming. The question is how to handle it in the long term. Unless you are in that insane 1% of superhumans who seem to never be tired of anything, you will burn out if you are constantly overworking. Instead what I try to do is to make sure I’m doing my absolute best job during work hours. It gives me a sort of moral security - e.g., if the project looks like it’s going to be late, I won’t feel bad for not working overtime. I’ll know I did my best, and the fact that it’s late is now the fault of a project manager who overpromised. That doesn’t mean that I won’t work overtime - I can if I want to, and often will if it helps the team. But now I feel more confident making that choice and can go home at the end of the day without feeling guilty.
Another thing I realised is that it’s way more fun to work for the goal. Writing a particular javascript function might be boring, but if I focus on the fact that it’s going on a website and will help a customer do something cool - suddenly it becomes a little more exciting. I feel I do a better job when thinking of the product as a whole and have more fun because I feel more invested. I also tend to work more, which is fine as long as I regularly check with my brain that I’m doing it because I like it, not because of pride or even competitiveness.
In general, I feel like work/life balance is hard to write about because it’s pretty personal. I like to remind myself regularly that there are other things besides my job that I like, and spending time on them could well mean that I’ll do my work better when I’m back in the office. It’s different for some people who immerse themselves 100%, which is cool too. Whatever your jam is, just check with yourself that you are working for the right reasons.
Ta-da
So here it is, these are some of the things I learnt at my first ever software job. Two years at Taxi was a significant part of my professional development, and I was lucky that I landed my first gig with the good guys - fun, respectful and very human. I learnt a lot and wish them only the very best.
One of the aims was to draw a mental line under my experience at Taxi - I feel like I only managed to draw a fraction of it, but it’s a good feeling nonetheless. This post, (my first ever!), was surprisingly easy to write, the content corked up in my head has been asking to get out in one way or another for some time. Writing stuff down definitely helps to get your thoughts straight, and I’m sold on the whole blogging thing. If you read this far - thank you! I hope it’s been mildly useful or at least entertaining.