Learning to Code with Others

If you get on whatever given job search site of preference, you’re going to see any kind of coding job interspersed with terms like “rock star” or “ninja”. Aside from this being part of the quest to complete buzzword bingo, these are misguided attempts to find the “right fit” to bring an organization’s coding level up. The quickest, most efficient way to get better results at an organizational level, assuming the individuals are qualified in the first place, is to focus on making them work together.

Any person is going to have a natural limit to how much work they can do. The highest level genius may do substantially more than someone who is just okay, but you don’t need a genius to be efficient at every task. Imagine you have to move a bunch of bulky, fragile bricks from point A to point B without a wheelbarrow. The strongest man in the world may be able to carry a little bit extra each trip, but not much more than a normal person. Most tasks in coding don’t require a genius, they just require a basic amount of competence (though there are tasks which require more intellect to get past).

A mediocre programmer who plays well with others may not invent the next blockchain, but they also won’t ever want for a job. They also grow faster than a lone wolf coder. Being able to work with others doesn’t just mean being a peer, it means being able to cooperate with those who are more knowledgeable too.

Soft Skills

Soft skills are portable skills that are applicable almost anywhere. No matter how you slice it, being able to work with others is going to make your job easier at any place and leave a better impression, especially in an interview. There are countless great articles about fostering soft skills, but few dive into the implementation of soft skills in a given industry. There are some basic things which can be inferred but are rarely directly addressed.

Basic soft skills are great, but they take a lot of time to develop to where they’re intuitive and easily applicable. Certain skills are more valuable than others, especially if nothing else is on the table. Some of these skills affect code, others affect process.

When coding with a team, you have to be able to establish a baseline for the people involved. If you don’t know what people excel at, how can you employ them properly? You also have to settle on a coding standard. A lack of standards leads to chaos. If you’re on a team, you need to be able to understand what and why the standards exist.

One of the common issues I see with coding in teams is a lack of conflict resolution. Another common issue is an inability to properly delegate tasks (which also stems from a lack of conflict resolution). These issues compound and can turn a great team on paper into a dysfunctional mess.

Establish a Baseline

Any project or team is going to have certain skill requirements and certain process bottlenecks. You can’t develop the backend without the database schema implemented at some functional level. You can’t finalize the frontend without the backend planned. Everything has its due order.

What does your team know? What are each of them good at? Is anything missing? Who can learn fastest? If you can’t answer all of these as a project manager, you’re almost certainly misallocating resources. If you can’t answer this about your teammates, you are almost certainly not working as efficiently together as you could be. A team needs to be cohesive to be truly efficient. Not even knowing the basic nature of your own team means that you may be going to the wrong person for direction when you’re stuck, or interfacing with the wrong person to make decisions.

Establishing Your Baseline

All of this applies to each individual too. You have to know your strengths and your weaknesses to work efficiently. What are you good at? Write it down. What are you lacking on which is involved in the project? Write it down.

The act of writing it down objectively solidifies it. Don’t lie to yourself, be honest. What do you not do well? What do you struggle with? Rank your skills on paper. Commit to it. This will also help you shore up your own issues and force you to improve as a programmer. You can’t avoid your weaknesses by hand-waving them away as “a matter of practice” anymore.

This sort of exercise seems pointless, but if you’re honest, you help yourself and everyone involved. I can do frontend design and work with HTML and CSS, but if its time critical and I’m not applied better elsewhere, you should pick someone else. If someone tasks me with frontend work, I’m going to nicely ask them why. It works out better for everyone in the long run.

Standardization of Code

Once you can rank who does what and how well, you need to make it easy for each person to work with each other. Computer scientists and coders in general are not well known for their social skills or humility. Make it easy for everyone, use a standard. It doesn’t matter if a given standard is less efficient than another, as long as everyone will follow it. 100% of 80% is better than 50% of 100%. Learning to compromise on this front is an extremely important skill. I don’t care what standard a project uses, as long as it’s consistent.

Standardize casing for variables, functions, etc. Are you using camel case or snake case? Is there a difference between variables and functions? How do you handle spacing and indentation? These all affect the efficiency and portability of your code.

Comments

How do you handle commenting? Do you expect self-documenting code or do you expect explanations for every block? I like to combine the two because it makes it easiest to maintain (especially if you expect churn on the team).

Which of these is easier to read (in Lua)?

function divide ( a, b )
	a = a + 0
	b = b + 0
	if b == 0 then return nil end
	
	return math.floor( ( a / b ) + 0.5 )
end

Or:

--function divide_comment
--takes scalar a, b
--expects a is a number, b is a number
--casts a and b as floats, defaults to 0 for a bad value
--returns a / b as an int
--returns nil if b == 0
function divide ( a, b )
	a = a + 0
	b = b + 0
	if b == 0 then return nil end
	
	return math.floor( ( a / b ) + 0.5 )
end

The first is probably much easier for trivial examples, but assuming we have non-trivial code, the second will be a lot easier to understand. We know what our function takes, what is expected from our scalar (Lua is a weakly typed language), and what we return. We also know what happens if we pass in the wrong type for b or pass a nonsensical value for division, we get nil. Obviously, this example is completely trivial so it’s a complete waste, but what about for a function which isn’t?

Churn

You’re going to lose people, you’re going to gain other people. The new people are going to be different than the old people. The sooner you accept it the better.

I operate under bus theory. There may be a day some indispensable member of my team gets hit by a bus. If there isn[‘t someone ready to pick up the slack, it’s game over for the team and the company. It doesn’t have to be a bus, it can just be a better offer. If you work in most places, you’ll never replace an average employee in two weeks (if you even get that much). Standardization doesn’t completely eliminate the harm churn causes, but it reduces it to where it’s manageable.

Conflict Resolution

Getting the code in order is only one of many steps to truly leverage every team member’s skills and apply them. You have to have process as well. Code revision and quality control are obvious steps in this process, but they follow primarily from the code improvement side. What do you do when you hit a human obstacle in the process?

Conflict resolution is one of the most important soft skills. It can prevent a team from falling apart and salvage an otherwise ruined project. With so many moving parts, you’re inevitably going to hit a snag at some point. It doesn’t have to be a deal breaker, you just have to know how to roll with the punches.

What do you do when you have conflict? Do you have a specific process to move forward, or do you just work it out organically? Both are valid, but depend on team composition for how well they’ll work. How do you weigh each side of the conflict? There’s bound to be merit in any side if you are employing capable people, but how you resolve the conflict affects morale and future interactions. Your process must be rooted in the team’s composition.

Resolving Conflicts

Each idea a team member suggests is going to be something they genuinely think is a good or practical idea. You have to keep this in mind when resolving conflicts. Some ideas are going to just plain sound stupid, and they may be, but there’s a real life human pushing it. People are human and mistakes happen. If your team member makes a stupid suggestion, focus on the problem and not the person.

Empathy plays an important role. Any idea which is totally out there has the chance to miss the mark entirely. What have you suggested which has missed the mark completely? Unless you’re quite blessed or just don’t venture out of your comfort zone, you’re bound to have messed up too. Do you remember what it feels like when someone tells you you’re an idiot? I know I do.

Make the process focus on the idea and not the individual. Mistakes happen, let them die with the idea which is thrown out. Make sure the person presenting the idea doesn’t feel that their idea is stupid, just that it isn’t suitable. Once you mix the person in with the idea, you polarize the entire process and the team.

Delegating Tasks

Coding can be a very meritocratic craft, but the problem is in where the merit is placed. Code is key, everything else is auxiliary in most shops. Some people are better at planning than implementation, some people can’t plan five minutes in the future. You need to find a balance for most positions.

This is where soft skills really come into play. You need team leaders to focus on dispatching tasks rather than actively taking them. With any luck, you grow your most competent into leaders, but keep in mind, some people just want to keep doing what they’re doing. You can’t necessarily change a person’s nature, but you can empower them for what they’re good at.

If your frontend developer is awesome at their job but also knows SQL, why would you put them on SQL when there’s still frontend work to be done (unless they really want to, but that’s another topic to discuss)? Many places task teams with specific jobs and encourage them to “do more”. Get the product stable before letting people run rampant between tasks unless it’s the only way to hold on to stability. If that’s the case however, you’re living in a false vacuum.

Encouraging Delegation

Proper organization and skill assessment leads to better delegation. Make sure teams are organized on the basis of both technical functions as well as personalities. A control freak at the head of a carefree team is going to end in frustration on all sides. When teams get along, it is much easier to properly dispatch and delegate tasks.

Give team leads a direction and let them implement it as necessary. This applies to both managers and team members. With proper planning and proper code standards, the task of building the parts becomes much easier. The military functions efficiently because they provide units with a function rather than a rote list of tasks (unless rote tasks are most efficient). The function fulfills the overall goal without the individuals needing to know the exact purpose.

Give a definition of what is required (unless knowing more is necessary), and let the team delegate it as necessary. As long as the input, action, and output is scoped correctly, the actual implementation is unimportant. This allows a more efficient division of resources and delegation of work. There also needs to also exist a process to push work back to the general queue if a team hits an unexpected snag.

Putting It All Together

You don’t need a strongman to build a pyramid, you just need a lot of people working together as a team. Coding is no different, except it’s harder to weigh what each member brings to the team without looking deeper due to the sheer number and abstraction of skills involved. Coders who can work with each other end up making a team which is worth more than a similar number of “rock star” “ninja” “hacker” buzzword bingo geniuses thrown in a room. The sum is worth more than the parts when you apply these basic soft skills.

Make sure each member of the team is accounted for. What are they good at? What are they lacking? Where do they stand for each task the team is involved with?

Standardize the process and make sure the code is consistent. People won’t stay forever, so be ready in case you lose your rock star. The code should be commented and documented consistently. Theoretically, the code should be able to be packed up and tossed to any competent team and work continued.

Soft skills are still important, but focus on conflict resolution and task delegation. Make sure teams aren’t mismatched. Teams need to be able to resolve conflict and delegate tasks. This applies at both a team and project level. There has to be process at each level to ensure efficiency.

Being able to resolve conflicts means being able to resolve the most emotional of interactions in the coding process. Delegation means allowing a task to flow naturally without being restricted, and a team lead or manager should make sure that tasks can be delegated as efficiently as possible. Otherwise, the bottlenecks compromise the whole process.

When all of these elements come together, your team becomes stronger than its parts. Your teams are able to work together transparently and each unit fulfills its function. These basic skills get you most of the way there.

Featured image by Rebekka D from Pixabay