loading...

re: You dont believe in clean code VIEW POST

FULL DISCUSSION
 

A good manager should be able to either provide technical guidance or at least ensure that it's coming from somewhere.

I've seen teams complain that management rushed them. So management stopped rushing them. The quality of the code didn't change at all. Not even a little bit. The developers had no idea what to change, and neither did management.

 

From my experience teams achieve better results when they have complete responsibility over the piece which they produce, from gathering requirements to post-go-live maintenance, an can make decisions on their own. With all respect for managers, very often I saw ones who do more harm than good for the projects through micromanagement. Team also work better knowing the long-term vision and plan and don't jump from project to project every quarter but have enough time to learn the project. I know companies which work in silos where no team really owns the product, one team works on features, other work on bugfixing yet another do deployment. When work is spread like that no one really feels the impact of doing good work from the very beginning till the end and no one feels responsible for failures. In most cases like that I saw a poorly designed solution, discouraged employees and high turnover. Personally I prefer to work in small self-organizing independent teams but this works when at least a few members have experience, I definitely would not risk it with all junior devs in a team, even though I saw some excellent junior teams in action, but general experience is that juniors have too much fantasy to experiment with technologies and tools ;) while seniors tend to find a good balance and prefer battle tested solutions.

Code of Conduct Report abuse