It’s easy to have a bias of thinking that you and the company you work for have different interests, and there is a trade off between being selfish or doing what the company wants. With this mindset, self improvement feels like something that shouldn’t be done on the company’s dime, or should at least be regulated, so that the employee and the employer can both strike a compromise where both interests are met to some degree. In other words, you think of your role at work to be that of a “Feature Machine”.
This post is my reflections on a discussion I had at work, where I identified that I had this bias and was trying to self regulate time spent meeting what I considered my interests (doing what gives me the most value) and meeting what I felt were the company’s interests. I realised that I defined the “company’s interests” as solely outputting clean, maintainable code to enhance the system, and this meant that anything outside of that fell into the “my interests” category. This then included things like the more general discussions we had whilst pairing (e.g. the benefits and drawbacks of different levels of testing), me taking time out to learn and develop myself, even asking for code reviews to help me understand the system.
We were considering the following scenario:
- I come in in the morning and pair with a colleague
- At a certain point in the day, I decide I’d like to spend some time on my own reviewing my notes or learning something new. I consider doing this to be fulfilling solely my interests, and taking time away from the company’s interests.
- Meanwhile, my colleague continues to work on the story individually.
- After some time, I rejoin my colleague, and ask him/her to review what they have done in my absence.
- I see that s/he has gone down a certain path when writing the code, and feel that if I was there I might’ve suggested experimenting with a different path at that stage
I felt that the barrier to suggest change during a code review was much higher than during pairing, and so I thought I’d only make a suggestion if I was 100% convinced it would be a better solution. I would feel guilty suggesting an experiment, in other words, that had the potential to result in some valuable learning for both of us.
It’s a theme that has cropped up a few times since I started working here, from making comments about “slowing people down”, to holding back from asking for code reviews as I thought I’d be “wasting” other people’s time. I’m realising more and more that this bias that I hold, of feature completion being our ultimate goal, is a negative one, and can hinder learning both for me and those around me.
I’m writing this because I believe this bias is not that uncommon, and recognising that you (or in fact your company!) holds it can be the first step towards a growth mindset.
When working on a feature, there are 5 different angles to be looking at. These are (in no particular order):
- Feature completion – obviously we do need to get the thing done!
- Writing a maintainable system – this means refactoring to make code cleaner/more readable/maintainable is a part of developing the feature, not something to be done afterwards “if we have time”
- Sharing context with others on your team – this reduces our “bus factor” and makes our work sustainable going forward – we are not reliant on any one individual or pair.
- Self learning and self development – whichever angle this is from. This one’s especially pertinent to me as a less experienced developer – I’m not slowing people down by us working at a slightly reduced pace; I’m learning more about my profession and my skill, so that eventually I’ll be at the same level as others around me.
- Developing your culture as a team.
Looking too much at one of the axes could cause us to lose out on some of the other benefits. Feature completion IS important, but not at the cost of the other 4 axes of development. And perhaps most importantly, the value that I add to the company as an employee is along ALL of these axes. If I spend time learning and developing myself, I can grow into an individual who can make better suggestions, write better code, and have a wider positive impact in the company. Staying stagnant at my current level of skill will not benefit either me or the company in the long run.
My plan of action: Monitor when I’m making the assumption of wasting someone’s time, and test whether they believe it to be a waste or not. I imagine the majority of cases will prove that the assumption is invalid and actually people are more than happy spending time having positive experiences that aren’t directly feature related!