What options does a disciplined developer have when joining a team of undisciplined developers as a regular member, not a lead? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

What options does a disciplined developer have when joining a team of undisciplined developers?

Based on an environment of bad developers and a lack of software development infrastructure to guide quality software development, what are the odds that hiring a really good developer to join a team of bad developers will enhance the team's environment versus causing more problems based on a conflict of interest?

Suppose the new hire was not a rock-star, but rather an apprentice to software craftsmanship. Thus, suppose they were hired to be a team member and not a team lead.

Also, suppose "bad developers" are people that call themselves developers but have no desire to continuously improve their practice and instead treat their routine as a job and not as a profession.

Answer 1

Without being in a position of team lead, the options are somewhat limited. There are different bases of power. The individual in your question won't have legitimate power, as they are not the lead or manager and they don't have the position to drive change. However, depending on their personality, they may be able to develop a position of referent power or expert power, but that will take time. Using coercive power likely won't be helpful in enacting changes.

If there is management support for implementing these good practices in the team, then having someone familiar with the practices, the team, and the technical components of the project would be extremely valuable. However, they would need to work closely with the manager to enact any changes. The individual would need to be in it for the long-haul, and understand their role in facilitating management's vision.

If neither management nor the senior members of the team want to change things, though, I think it's very unlikely that anything will change. Change needs to come from somewhere, either top-down from management or bottom-up from the team. If neither side is willing to support change, then change won't happen.

I would be concerned with the ability of the developer to leave. Working in the conditions that you describe - other developers who do not continually improve or mature their skills, lack of good software engineering practices, and not being in a position to drive changes to make the working conditions better - could lead the developer to leave the team or the organization to find a better fit. If the developer continues to work through it, they could see higher levels of stress, anxiety, and even burnout.

Alternatively, driving changes top-down could alienate members of the team. If you have people with very specific, business critical knowledge and you made changes that they see as difficult, they could become disgruntled and leave the organization as well. Management needs to be careful when rolling out changes to begin a transformative process, but not disrupt individuals or business activities.

Answer 2

Most developers are confronted with either creating crappy/less manageable/unscalable/not quite so perfect software in order to meet an arbitrary deadline or they get fired. One reason good programmers are considered good is because they're able to stand up to this because of their reputation, influence, persuasive skills, threatening to leave, etc.

Being a "rockstar" is relative and shouldn't be too hard for someone to shine in this group. Create just as much and better software in half the time. Then you get to leave in the middle of the day. They'll all want to know how you're able to do it. Or more likely, get things done and they'll assign you the tough tasks. Set an example.

Observe what everyone is doing. Ask questions. You may discover that it's not the developers who are not disciplined. Help them fix the things they see as being problems. You can't change everything at once. Few people want to be a bad programmer, but that doesn't mean they're willing to do what it takes to improve. The influence of a good programmer will be accepted by some. A good company can usually weed-out the non-hackers. Don't be surprised if this takes a few years.