0

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
Scott Nimrod
  • 121
  • 5
  • 2
    I would tend to think that it is mostly the business of the team manager, and it is surely depending on social and human factors. – Basile Starynkevitch Apr 29 '15 at 12:31
  • 5
    Are you this "rockstar" developer or are you trying to hire one? Are you planning on advertising this as a development role or a software lead / technical management role? If you're doing the hiring, are you going to be assessing the candidates based on their experience in development or management and process improvement? – Thomas Owens Apr 29 '15 at 12:34
  • 4
    This would totally depend on so many details. Bad developers? Why are they bad? Incompetent and don't care or just new and lack of experience? If they don't want to learn a rock star won't do much about it. Also the project may make a difference. If you can put your 'rockstar' to work rather independently on some core feature and let the others do simpler work this may do. Also management and so many more things that would matter. – thorsten müller Apr 29 '15 at 12:39
  • @Thomas - 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. – Scott Nimrod Apr 29 '15 at 12:39
  • 3
    That changes the whole context of the question. But I think I can provide an answer if you edit these details, plus answers to Thorsten's questions (especially what makes them "bad" - incompetence, inexperience, lack of care, etc.) into the question. – Thomas Owens Apr 29 '15 at 12:42
  • @ Thorsten - 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. – Scott Nimrod Apr 29 '15 at 12:42
  • @ScottNimrod "continual improvement of practice" is not necessarily anything bad. Try going to a bank's COBOL dev and saying "why are you stuck in the mud and not refactoring and updating this old code". Bad dev means writing poor quality, unmaintainable code. If they are writing good quality code, then I'd rather have them than any number of 'continually improving' developers. – gbjbaanb Apr 29 '15 at 13:04
  • @ gbjbaanb - Then I would call those developers "disciplined". I would also say that good code is "proven" / "testable" code. Hence, writing good code as you defined, is not enough. What would you rather take with you when escaping a burning building? 500,000 lines of perfect source code without the backing unit tests... or all the unit tests without the source code? – Scott Nimrod Apr 29 '15 at 13:18
  • @ScottNimrod sure, which is my point but your question equates bad with undisciplined, and lack of improvement with bad (developers)!. I would say a heavy refactoring of your question is in order! – gbjbaanb Apr 29 '15 at 14:08
  • 1
    From The Past: [Getting Things Done When You're Only a Grunt](http://www.joelonsoftware.com/articles/fog0000000332.html) – AakashM Apr 29 '15 at 14:54
  • 1
    @ScottNimrod - If I have to release tomorrow, I'm taking the source code. – JeffO Apr 29 '15 at 14:58
  • @ AakashM - Thank you! That article really resonated with me. – Scott Nimrod Apr 29 '15 at 15:12
  • I said that wrong... What would you rather take with you when escaping a burning building? 500,000 lines of unmaintainable code but working software with no unit tests... or all the unit tests without the source code? – Scott Nimrod Apr 29 '15 at 16:43

2 Answers2

6

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.

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
  • Thank you for this answer. To encourage other viewpoints / answers, I will let your answer brew until the end of today. – Scott Nimrod Apr 29 '15 at 12:53
1

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124