bits-and-pieces developer

Some time back there was a discussion in the cricketing community regarding bits-and-pieces players vs specialist players. The commentator felt that specialist players add more value to the team than bits-and-pieces players. The underlying assumption is that the so called bits-and-pieces players don’t have enough expertise in any of the departments. The quote “Jack of all trades, master of none” is more popular in the software industry.

My point of view is that junior developers should optimize for breadth rather than depth. This will give the better perspective of software development at later stages of their careers.

Breadth opens up more opportunities early in career, chance building border networks. New technologies are popping up everyday, no one can keep track of every new hot tech that is released. It is difficult to predict when the job market becomes dull for a given tech, more breadth makes it easier to switch the careers path. It also recommended to understand the concepts underlying the tools.

Breadth allows you to see common patterns in software building. For example map,filter,reduce pattern is very common in data pipelines, but is implemented in different ways in different languages. But the underlying idea is the same, you perform a set of transformations on data (map), then filter data and produce the result.

One example I can draw from my own career is that I was able to design better/additional APIs (ergonomic for frontend engineers) that make frontend engineers’ jobs much easier because I had some experience building apps (both Web and mobile) early in my career.  Some APIs might not fit into regular design patterns (Standard CRUD/Pagination) and may look odd or unnecessary. But may reduce a lot of complexity in frontend code. In this case it might be best to avoid complexity and implement that odd API, this becomes easy if one has some grasp how a particular API will be consumed by the frontend. 

I also think engineers will become specialized in particular technology as they work on the same project/tech stack for a few years. Of course this requires conscious effort from engineers to improve their craft. Even people who think they are not specialized in any tech stack might be above average in a few areas. This is assuming that they worked on a project/stack long enough.  

So my suggestion is that early in your careers if you find an opportunity to jump between technologies, take them and explore the new technologies. This is not to say that you should not switch between technologies at later stages of your career, if you like to explore different technologies you can try them at any stage of your career.