Maniero

Personal blog, mostly about software engineering.

Teach More, Abstract Less

As developers progress in their careers, they are driven to improve their team's productivity. Senior developers starts to observe where their teams are struggling technically and help their colleagues to grow, however sometimes such help comes as a white elephant.

Three white elephants

Consider this: your colleagues are struggling to work with a new tool that you all decided to use. You drove this decision because you have some affinity with it, and during your team's learning curve, you saw the team's productivity drastically going down.

You then have a brilliant idea! To create an abstraction on top of that tool. You spend a few days, maybe some weeks implementing such abstraction. You had your team's approval, your colleagues gave you the feedback that it is easier for them now, even the team's productivity is back at the previous state.

There was one or two cases where the abstraction needed to be extended, your teammates were not comfortable performing such changes because they don't know the tool very well, and to prevent them to spend too much time on it you made these changes.

But you went off on vacation a few weeks, during that time some change on the abstraction needed to be made, the team had such a bad time doing so. At that point, they had to lean both - the abstraction and the tool. When you returned to work with the aid of a sunburn, you figure out that the once beautiful abstraction don't seems so great anymore.

You could blame the labor rights, after all, who needs more than two or three days of vacation?

Abstraction are something that need to be performed in a very cautious way, you need to understand if your team is able to support such abstraction. To create an abstraction to solve an knowledge issue is never a good idea.

Actually, creating abstraction to help junior developers to perform is the most perverse solution for their careers. You took them the opportunity to learn and their autonomy. These abstractions are usually not well documented and they will have no search engine to turn to.

So, before abstracting it, help people to learn. Teach your colleagues, pair with team. So, if you all decide to abstract something everyone will have the knowledge base required to do so.


Thank you Johnny Richard for reviewing and for the feedbacks.