How do you help your fellow programmers to grow?

Question

As a team lead, how can you help your programmers to grow?

The reason I ask this is because there are a few programmers working with me, and I really want to "turn them on the loose", to realize their maximum potential, and to keep them happy.

But I don't quite know how to do this, do I have to

1. Interact with them frequently, or give them quiet time, leave them undisturbed?
2. Ask them to follow coding guidelines, such as enforcing unit tests, coding styles, or let them do whatever they see fit?
3. Be lenient with them. Such as don't really care whether they really come into office for 8 hours or 4 hours, or need to enforce some "disciplines" in the work place?

Guess what, each positions have their own points, and different people would argue for different things. Such confusions make managing people indefinitely harder.

What do you think?

Answer 1

It's a very fine line you have to walk.

In the end, any technical decisions you make are decisions that you won't have to live with. So make as few of them as possible, let the people who do have to live with them make their own choices. But do guide them if you think they're going down a bad road.

On the other hand, process choices are yours. In those decisions, let the team guide you but ultimately you need to make them. At least at first.

Have a read of Roy Osherove's Three Maturity Stages of a Software Team and see if you can figure out what stage your team is currently at. This should affect the way you act. The more chaotic, the more you have to put controls in place. eg. In an extremely chaotic team, you need to start by reviewing all code committed. But while you're doing that, take the time to teach them to review each others' code.

And if you manage to pull a team from Chaos to Midlife, change your behaviour at that point, otherwise they won't move any further (this last from personal experience).

Answer 2

Yes, managing people is indefinitely harder than managing computers or software, precisely because every person is different, and we may change even day by day. So there is no universal answer. I believe you just need to communicate a lot with your developers to get to know them and understand their individual strengths/weaknesses, their attitude to work and to learning, etc. You can thus learn about each of them, whether (s)he prefers lots of communication and workshops, or learning on his/her own in a quiet corner.

IMHO developers under normal circumstances have a natural urge to learn (unless they have been burnt out or jaded by a previous bad job experience). So all you need to do is understand what and how they would like to learn, and provide them the tools and time to do it (within reasonable limits of course).

E.g. in our team, we can freely define learning tasks for ourselves, as long as these are somehow (directly or indirectly) related to the project. These tasks are typically a few hours to one day per sprint (not in every sprint though). (A recent example: I got a task to learn and experiment with Scala accepted, on the basis that this - and a functional approach in general - might help simplifying a complex part of our Java code.) These then get prioritised and scheduled into a Sprint, just like regular tasks. It is also encouraged and expected to perform demos / lectures about what we learnt, to transfer knowledge to other team members (and potentially even to developers in different teams).

Ask them to follow coding guidelines, such as enforcing unit tests, coding styles, or let them do whatever they see fit?

When working in a team, following the same development process is a must. Of course, that process should be the simplest thing which could possibly work, not something described in a 600-page manual. And the process should be defined and continuously adapted to the situation by the team themselves. So if the team has agreed to a coding standard, and TDD, they are to follow it.

Be lenient with them. Such as don't really care whether they really come into office for 8 hours or 4 hours, or need to enforce some "disciplines" in the work place?

If you don't know a developer, it is normal to follow more closely what (s)he is doing, her deliveries, her work rhythm etc. It is also OK to review her code (either yourself, or an experienced and trusted team member). Once she has earned trust, she can gradually get more freedom. But that trust must be earned first. About working hours, in my experience flexible hours is great up to a limit, i.e. it is good to have a common agreed minimum, like daily between 11AM and 2PM, when developers are (usually) to be found in their workplace, so that they can be approached with questions, or invited to meetings. But other than that, there is no point being strict.

Answer 3

OK as a lead it is your job to get the projects out the door. So you have to be the one who enforces standards, code reviews, asks for progress reports and all those things when the developers would rather you left them alone. These things are just requirements of management and except for the code reviews don't really grow the employees' skills.

However, you want to help them grow which is a great attribute in a leader.

Code reviews are certainly a first step, they will help you see who has less than stellar skils and needs improvement to even have satsifactory performance. They willl help the developers see other ways to do things and to understand different parts of the code base than the ones they personally worked on. In my opinion, code reviews are best done in person in a conference room with the developer and the reviewer (who should be another developer when possible not always the lead, reviewing other's code is also a skill that needs to be developed) and you as a moderator. You should keep notes on what needed to be changed to identify trends. What you really are looking for isn't mistakes or changes (everyone's code can be improved), but consistent failure to learn from mistakes. Do not tell upper management you are keeping these notes or you will find yourself forced to use them as measurements in the performance review process which frankly defeats the purpose. If several developers are making the same mistakes, a training session or a wiki entry on how to do X may be in order.

Now on to growing vice getting to the minimal level. First, you need to know what skill sets the developers have and what skill sets it would be useful that they had and what they might be interested in getting knowldge in. You need to talk to them and review their resumes and understand what they liek and don't like to do.

Don't give all the interesting assignments only to the most skilled. That doesn't help the others get up to speed on new problems and technologies. You can't move from being the most junior guy getting only the smallest and least important tasks to the senior guy unless someone takes a chance and assigns more difficult work to you. That said, the less experienced may need to be assigned first to pair program with a senior to get more advanced skills. Including the juniors in code reviews will also expose them to more advanced techniques.

First give them a chance to figure out the issue themselves. But sometimes people are stuck and don't know where to start (a skill that you also needs developing especially in new programmers) or what to do to solve a problem.

If you give them a couple of days to research something and they still don't have a direction for how they are going to do something, then you may need to intervene with some suggestions. If you are technical yourself, you may give them some ideas for how to solve the problem. If not, a meeting with several people where you brainstorm ideas can help if the person is stuck. Or asking a more experienced person to give some suggestions. What you don't want to do is take the problem away from them and solve it yourself. But you have to balance getting the project done with the programmer's ego and at times you need to send them in a specific direction. If he has a bad solution and it needs to be fixed, the worst thing you can do is give it to someone else unless you intend to fire the programmer. Making people fix their own mistakes is how they learn not to make them.

I've seen bad programmers coddled, where someone else has to fix almost everything they do. The other programmers resent this and just want the person out of their lives. Coddling a bad programmer leads to the good programmers leaving. You have to find the line between coddling and devloping skills. If you give someone several chances and he or she never gets better, then cut him or her loose.

For the seniors who are already competent in their current skill sets, things are easier. Usually you just need to give them the opportunity to do something new and they jump in and learn it. Just make sure the interesting opportunities get spread around and don't all go to Joe the Wonder Programmer who can fix anything. You want to end up with ten Joes not just one.

Another way to develop skills is to have a weekly 1-hour training session. Make each devloper responsible for a particular topic. This will help them get better at communicating, will make them research something in depth and will give everyone the benefit of their research. Some topics should be assigned to people who are not familair with the topic to force them to grow some knowledge in that are and some should be assigned to people you know are the local experts on that topic. Topics should be a combination fo things you need people to be good at inthe near furture or right now and some coverage of new upcoming technologies that you don't use right now but peoplea re intersted in learning about to see if they could be useful. But everyone including the most junior must be assigned a topic. Doing the training is as much a growth opportunity as listening to the training.

Depending on how your developers' time is billed (this is harder in a customer billing situation), it is usually worth it for developers to have 4-8 hours a week to work on personal projects. They will be excited to do this. The best people will want to work there and they will learn alot that will become useful for the future. It's hard for the bean counters to understand the need for this, but this time will be paid back many times over in employee satisfaction, new features or software that nobody required (or which will help automate some of the drudgery) and faster development due to new techniques learned. Some developers will use this time strictly for personal projects not related to what you do (and that's good, they will still be gaining skills and happy for the opportunity), but many others will use it to solve persistent problmes that, due to the nature of how projects are managed, ndbody had time to fix beforehand. So you may get refactorings that benefit everyone; some people might write tests to improve test coverage to make it easier to refactor; some others might explore some new features that might make your software more useful to it's customers. In general, if you can persuade the bean counters, there is no way to lose by allowing them this freedom.

You have to learn how to balance letting people have some stretch for their skills and keeping the project on track. The less experienced the developer is, the more someone needs to check on progress especially in the early stages when changing direction is easier. The inexperienced may struggle and be afraid to speak up. These people tend to leave just before launch and you find their part of the project isn't anywhere close to being done. Be especially careful to check progress on anyone you have who has changed jobs frequently (unless they were a contractor as that is the nature of contracting).

The more experienced can generally be trusted to tell you when they are having trouble finding the solution and need some assistance from someone with more knowledge in the area or they will go seek out that person and get the knowledge transfer. So they don't need to be monitored as closely in the intial phases of learning a new skill set for a project. They will find a way to deliver the project. Those who have a track record of delivering can usually be left alone except for minimal progress reports (you usually have to report to your management too and thus need some information).

Answer 4

1. Give your team challenging work and the tools to solve them. Even if you see your work as mundane because you're just supporting a legacy system, push everyone to make it better.
2. Your team should develop coding standards. Your job is to help them enforce and adapt the standards.
3. Work with your team to develop an estimating system. Your job is to help coordinate this effort with the team and provide enforcement. Outside forces expect quality code in a timely fashion and they don't always have reasonable or provide any logic for their requests. You can't escape this, but you have to manage both sides. Once your team has built a reputation for getting things done, everyone will be more accepting of your time estimates. They need to know you will support them if they are making the effort.

When I say your job is to enforce, I don't mean to take on some sort of Draconian leadership style. When a group of capable individuals have input on how they are going to behave, they also must agree to consequences for not following the rules. Someone is ultimately in charge and since you're that team leader, that's you.

Answer 5

Interact with them frequently, or give them quiet time, leave them undisturbed?

Interact with them frequently. Obviously not the point of bugging them but as their manager you should be having regular conversations with them about how things are going and more genral chit chat. Roughly once every few hours sounds the right frequency but play it by ear.

Ask them to follow coding guidelines, such as enforcing unit tests, coding styles, or let them do whatever they see fit?

You should expect them to be working to exactly the same standards you do. If you do unit tests and follow guidlines then they should. They need to learn how to code well and its your responsibility to teach them that.

Be lenient with them. Such as don't really care whether they really come into office for 8 hours or 4 hours, or need to enforce some "disciplines" in the work place?

I would be more diciplined at first but ease up when they prove they can be trusted. Giving people the trust to work a 4h day right from the off is asking for trouble however letting a valued employee who regularly works late have some slack between projects is fine.

Answer 6

Related to your three points:

Interact with them frequently, or give them quiet time, leave them undisturbed?

I'll say that it really depends on the type of person you work with. Some prefer discussing at fixed coffee time (around 10am say) and otherwise working alone, undisturbed. With them (OK, I'll admit, I am exactly like that), I generally send emails (even when they are near me, like 2-3 meters away) so that you may leave them the choice on when they read your information. And by the way, don't ask them if they "got your memo" :-) And of course, some "need" more guidance, more interaction.

Ask them to follow coding guidelines, such as enforcing unit tests, coding styles, or let them do whatever they see fit?

As for following guidelines, it is pretty clear to me. If you set guidelines related to the coding style, always-provide-test-case rule, etc then you have to enforce them if you are the lead developer. For the project you are managing, every developer should follow your guidelines, no exception, even for "superstars".

Be lenient with them. Such as don't really care whether they really come into office for 8 hours or 4 hours, or need to enforce some "disciplines" in the work place?

If you already know how people work and are confident than they will not break your confidence you can relax the discipline. But I think that for this point the rule (or no-rule) you define should apply to everybody. The important thing is that there should be no exception. I'm currently very happy to work for a project manager that simply says "as long as you do your 40 works per week and the job is done, it's ok". That way you may come late one morning, work only 6 hours and the next two days work for 9 hours. It does not matter "as long as the job is done". I like that rule.

Answer 7

I'd say that the amount of experience (not just programming, but also in business environments) your developers have is a key element in how much time you spend with them. I'm currently working with some developers who are just out of school, and I'm finding that they need more guidance in how to work with others, not just in documenting/testing/standards ways, but also in interpersonal ways (when to call on the phone or meet in person, instead of just sending emails). Knowledge of our business is also a key thing to learn about, as many of the same words are used very differently in our business context than in a software development context. And this is before we get to the acronyms...

Answer 8

But I don't quite know how to do this, do I have to

1. Interact with them frequently, or give them quiet time, leave them undisturbed?
2. Ask them to follow coding guidelines, such as enforcing unit tests, coding styles, or let them do whatever they see fit?
3. Be lenient with them. Such as don't really care whether they really come into office for 8 hours or 4 hours, or need to enforce some "disciplines" in the work place?

My suggestion is to have some conversations about what style works best for that individual and fine tune over time. Some people may want to meet once a day to review how things are going while others may find once a quarter to be excessive. Some people may want a formal written out performance review every month and others may just want a chat about performance. The key is getting the relationship to the stage where you can get honest about what works and doesn't work for someone.

The flip side to this would be to study personal development philosophies though this can be a tricky road if someone gets analyzed incorrectly. If you want a few examples of such philosophies you could look at Myers-Briggs, Enneagram, and Strengths Finder 2.0 for a few examples.

Answer 9

You ask them how they would prefer to work.
What they'd like to change and so on.

Not all at once. Just... as things show up.
Stay natural. (or they'll smell fear)

And then... you may even learn stuff from them. If you don't think that would ever be the case, (too much distance in education and experience) don't really bother trying to make them grow up, it would only confuse them.

(In that special case, give it up and rule with an iron fist, it's more honest than faking interest you don't have in them)

Establish a democratic process, vote things up, discuss issues.

Like every president out there, you keep the final word: the veto.
The rest is up to the group.

Answer 10

One way to help your people grow is to let them do what they do best.

If you are lucky, you will have one or two programmers whose personal "testing" standards are stricter than those of the department as a whole. In that case, you can put them on the "honor system" for those issues, or even adopt their methods.

With "flex time," you can afford more leeway to your more productive workers. As long as they are getting the job done, I'd worry less about their hours. Some people come in, put in 5-6 "nonstop" hours, and achieve more than others who put in 10 slow-paced hours.

But one of your jobs as a manager is to correct WEAKNESSES. That is, you will have to BEAR DOWn on sloppy programmers whose test standards are inadequate, or people who aren't productive enough--because they aren't putting down the time.