Recently I got a new colleague. A young guy, now working as a developer in my project. In my first review of one of his changes I saw the flaws again we just managed to widely eliminate in our team.
In this case it was about mutability. Seeking immutability wherever possible is one of my favorite best practices. I cannot live with unnecessary setters in our code. So, I could not help but play the dog in the manger. His argumentation was that he likes to always have a default constructor to allow for "easy mocking" of every object. And, when you force to caller to provide every parameter during construction of a tree of related objects, this accumulates to a bigger problem. I think in the end I could made him aware of the advantages of unchangeable elements in the code, but I don't want to dive into this specific topic here.
My realization was that the young crowd that comes from college is still in the same necessity to get the practical finishing it ever needed. I think this has not changed in the last decade.
Besides my view as a senior to the early stage of knowledge of these junior developers, I am at the same time aware of the fact that there is also potential to learn new, fresh ideas from them.
Sometimes a beloved best practice got a bit long in the tooth. I am actually thankful for that, nothing could be worse than ever working in the ivory tower and, slowly but surely, getting obsolete!
Furthermore you learn that it will always be necessary to build software with people in every stage of development. The process and the software architecture should compensate that. If it breaks, not the poor junior is to blame, but the framework!
Keine Kommentare:
Kommentar veröffentlichen