Lead Programmer: less programming, more humaning

The following article was made possible after a long year of development, where I was able to gather all my experience from previous works.

Having worked on different roles ranging from junior to senior programmer, I was able to make it to the lead position on Jake & Tess Finding Monsters Adventure Mobile version.

Now it's time to share that knowledge.

Being a Lead Programmer is often associated with pure critical thinking and decision-making, but too often the human part of the occupation is neglected. We often find leaders that know exactly what to do code wise, but not exactly what to do with the people working around them.

This article will touch mainly two aspects of the lead programmer:

First off, all human being are emotional. No matter how well centered someone is, emotions drive some of the decision making, the interactions done and the productivity.

If that wasn’t enough, the imposter syndrome is a well-documented problem that happens with people that work with code in a team. Their work/thinking process/solutions are all extremely exposed to their peers and are constantly reviewed.  This makes them feel less confident as a programmer compared to their fellow coworkers.

As a leader, the goal is to achieve a stable product, with highly optimized and well-organized code delivered on time.

All of that achieved in a radical, mutable environment that is the game development industry where features may change as well as schedules and shipping dates.

Finding Monsters Adventure Mobile

Leading people, not code.

Lead programmer might be the title of the job, but it is not a program which is being led. It is the people producing it. A couple of things might get unnoticed:

Every project that has more than 3 coders will face radically different skill levels with different style people working together trying to have a single coherent code base.

Keep in mind that they will most likely be suffering from the imposter syndrome, on edge of how well they are doing compared to other team members.

Keeping the drive to code up and keeping people motivated is a job that has to be constantly maintained during the entire length of the project at the same time that code quality, stability and optimization must be demanded from every team member, which will involve criticism.

Criticizing a coder’s work might be the most delicate part of leading programmers. The success on delivering that criticism is the difference between transforming an average coder into a great one, or throwing him into an unproductive pit where he will either leave the company or be fired.

Since programmers already have the tendency of comparing their work to their colleagues, delivering a criticism using code comparison might be one of the worst mistakes a Leader can do.

It must be crystal clear that every effort done by that person is appreciated, and that he will not be punished by the mistakes done in his code (never present them as mistakes!).Instead communicate what is expected from him is better results; not because the company demands it, but because the team believes he is capable of that.

Even though good results are indeed expected from a person doing a job, delivering that on a negative tone will put the entire person’s focus on how bad his situation is rather than in which way he can improve his performance and skills.

As a leader, you want to build a comfortable and safe environment for a person to grow, shielding that person from the pressure and the possibility of being fired if improvement is not achieved.

This must not be mistaken by “going soft” on someone.

This safe environment has to be set from day one in a project. Mentoring for better results must be a part of the daily activities of a Lead Programmer.

Getting to know your team

Making a profile of each programmer on what their strengths and weakness are, what is their style, and calling upon bad behaviors as soon as one is detected is essential.

Planning what areas each team member is most likely to fall short makes it easier for both mentor & mentee to have better programming habits and keeping a stable and coherent code base along the way.

Finding Monsters Adventure Mobile

Breaking the news

A Leader cannot leave as last resort measure to call upon bad habits and demand change. Doing so, will most likely lead to a series of bashes upon the code produced by that individual.

He will enter a defensive state of fear and shut down. What is most likely to happen is slower production covered with fear of doing new mistakes, often increasing the mistakes done by that programmer. It will also become harder to detect because he will tend to hide his work from other members or play the guilt game.

Instead, it must be done as soon as a bad habit is noticed and never delivered as “hey, you did it wrong”. It must be in a form of suggestions, explaining why and how it is better to do it in another way.

Sitting beside that person and letting him figure out a better way to do the same task will get him used to working better. Then always acknowledge his effort and congratulate him on the new solution he found.

When a problem is happening across the team because bad habits existed before and a new leader arrives, making a “tech talk” is the way to go. It should have a tone of a brown bag instead of a calling out on everyone.

Why so much babysitting?

One might think that people should be mature enough to figure this all out on their own, after all, they are technical people, critical thinkers and know how a good code should look like. However, humans are creature of habits. One can have a destructive behavior and not realize it.

Changing habits is hard. Being confronted by it triggers our self-defenses and shuts us down towards change.

A leader must understand this aspect of human nature and have a good skill set on bringing up conflict without triggering defenses.

Being blunt and sincerity might work for a particular individual, but it is most likely to drive a grudge between the leader and the developers rather than bringing people close together thus opening everyone up for better productivity.

A leader must not want to promote himself or dictate the “right way to do it”. Creating a game is not like hammering a nail. If people are not invested, driven and excited about making that game, they will not come up with creative solutions. Strive to improve and create an eager team hungry for challenge.

Finding Monsters Adventure Mobile

Dev Team vs Upper Management

Game Development is delicate. Not only the team has to bring life to the game itself, but they must also create tools for other projects, guaranteeing stability and delivery on time.

Bigger and more mature studios might have teams dedicated to each segment of development, but smaller ones must share resources.

 Moving programmers between projects is not like moving construct workers. It takes time to settle in a new project and get back to producing at 100%.

One major problem that developers face is the struggle for code quality when upper management wants to interfere on development directly. That creates turbulence, possibility of rework, new set of features and a lot of frustration to developers.

The lead programmer must have a voice against reckless changes. He must shield the team developers from these turbulences, letting through only the changes that must happen and will be as close as possible to final decisions.

This will involve strong conflicts and fear of losing the job when “no” starts to be said a lot.

The key here is reasonability.

The lead is the responsible for the project’s technical decisions. If something seems unreasonable, he cannot give in.

If the leader fails to do that, work will be done twice: one for the unreasonable change and another to correct that.

Time will be lost in the process and frustration will be generated among developers.

On top of that, developers will start to doubt the decisions done by the lead, since allowing nonsense to reach them will be seen as a decision made by him (it was indeed). Trust might be hurt resulting in future mentoring and requests being received with less enthusiasm by the team members.

Dev Team vs Other Areas

Every area wants something from code. Feature requests will always be endless. It all depends on how much the dev team can deliver.

A change often happens on game features along the development process. They evolve and become different things.

The code base will suffer as obsolete code starts to pile up.

In order to counter that, upkeep must be done whenever old systems have to go through too much change to include a new feature, meaning it must be reworked.

This will be met with high resistance by production, as they will not have factored in that extra time.

It is again the leader’s job to ensure that the next sprint effort will be placed into reworking that code.

This practice has more than one benefit.

The obviously one benefit is the stability. The code becomes more predictable, detached and reliable.

Additionally, programmers involved on those tasks will feel more comfortable about that segment of the code and they will work with less tension on new features involving that. The decision of solidifying code indicates that the project is now more mature; programming involving that part of the code will be easier and more flexible.

Be aware that when a leader recently joined a team that did not have that mindset, resistance will be felt from all areas.

Once the first project is done, the code stability and the ease of bug fix/polish will make it very clear that it has all been worth it, especially if any team members have previously worked on chaotic projects that crash all the time near the dead line. This might sound crazy for readers from bigger studios, but mobile studios that are only now starting to see bigger headcounts face this all the time.

Finding Monsters Adventure Mobile

Conclusion

Leading a team of programmers might at first seem like a very tech heavy position, but it might as well be even heavier on the human resources interaction.

It is essential that the leader has a strong technical background, but too often leaders with low social skills fill the position. When this happens he ends up doing most of the programming because he is unable to mentor people into producing better. That segregation further distance him from the team, creating almost a struggle between regular programmers and “the boss” that bashes them because of their bad code and expects them to get better under the pressure of being fired if they don’t follow the same standards of the best programmers.

Not only that, the leader must be mature enough to shield the dev team from outside storms, allowing a stable and fertile environment to exist in which every programmer can achieve better results.