“And there came a day, a day unlike any other… when Earth’s mightiest heroes found themselves united against a common threat… to fight the foes no single superhero could withstand… on that day, The Avengers were born.”
As you probably know, we’re developing with Sybil a way to capture what makes a developer, at least from the technical point of view. In that context, Martin and I are addressing several related questions such as which skills does the developer need to master.
This is not an easy question as the job of developer is a dense and variate job. Moreover, there are many developer jobs: the specs, the quality, the management of the project and the team, the design, the support, the interaction with the user, the collaboration with other developers, and so on. It’s very reductive to think there is only one job. As there are multiple jobs, there are multiple types of developers.
At a certain point, certain moment, developing a software is a daunting task. It couldn’t be supported by only one lone developer because he’s alone, because he doesn’t have all the skills. It’s necessary to form a team constituted by developers with complementary classes. Alone they can’t, together they’ll do.
Natalia, The Jack-Of-All-Trades
It’s probably one of the most common developer class. She implements features, fixes bugs, reports them, coaches coworkers, documents her code, refactor others’ code, helps for devops, etc. She may be the best at nothing, but can do everything. Her asset is her average skills in anything.
“Don’t think I’m helpless, just because I’m soft and cuddly!”
Due to her wide set of skills, she’s flexible, and she can replace and interact with any other team member. She has good learning and social aptitude. For that reason, she’s a necessary backbone of a development team. She’s probably not the one who will fix a very complex problem that needs very sharp skills, but she’s certainly the one who will help that guy. She can become a very good team leader.
Logan, The Expert
He is the master in a certain technical language such as C++ meta-programming, advanced algorithmic, concurrent programming, distributed programming and network, etc. in that domain, he’s THE reference in his team, very productive and sharp, he reviews the code of others, his opinion is strong and weighs, and nobody can do better than him in that domain.
“I’m the best there is at what I do, but what I do best isn’t very nice”
He’s a member of the team because a few technical points of the product are critical. Due to his level of skill, he’s usually the only one to work on that critical parts. But as important and critical is his presence, he’s a single point of failure. For the team, it’s very important that he chooses and trains a padawan to assist him.
Edwin, The Maintainer
He’s there since long. He has maintained the project for long years, with some random guy like you showing up with crazy new ideas each three years. He’s still there, the project is still running. He can remind old decisions made before you arrived and helps everybody to understand the reasons behind that design choice or that technology choice.
“As soon as my rehabilitation is finished, I should like to report back to work. You should know better than most, sir. Things really can’t go on without me, now can they?”
He may be advert to new ideas, but not from an ideological point of view: he just wants to know what are the real gains and how complicated it will be to maintain when you’ll be left. He’ll bore you, but with the voice of reason.
Bruce, the Tester
He makes any perfectly working application crashes, can reproduces it, and documents it. He do think the same way as most people, he has a weird approach to torture the software. He has a very good understanding of how the things that do not work help him to use the software in unexpected cases. He has also good skills to build benchmark and tests in order to automate those use cases and avoid future regression.
He’s one of the most important user of the issue tracking system. He reports, he answers, he supports the developers and challenge them. Quality is a useless word without him.
Jonas, The Documentalist
Maybe he knows it is useful, maybe he likes to write things down, maybe he’s just sort of maniac, but he gets every aspect of his work nicely written down. From code documentation to wiki pages, from detailed design to user manual, without forgetting issue conversations.
“Unlike most humans, I prefer not to speak unless I have something to say!”
He takes time to make things, but you’ll appreciate in one day, when a search will show of a very old manuscript or a code comment revealing the reason of that wretched design you are fighting with. Without him, the project will be full of cruft.
Tony, The Architect
He is the one who thinks globally. He sees the design needed to make a better product and he sees the wheels behind the clock. He has usually a good previous experience of software development that gives him a good taste of common issues. He has the vision of what the product could be. Sometimes, he sees too far and loses himself in an abstract world.
“Yeah, I can fly.”
He watches the work of the team to detect synergies and possible needs of tools. He fights the technical debt. He extracts the knowledge of the work and produces the technical documentation. He’s the evangelist.
Matt, The User Voice
Whether self appointed or not, he makes his own crusade to speak for those that cannot: the users. When confronted with a new feature or even worse, a refactor, he simply asks “What is the ROI there? How will this make the life of the users easier?”. He’s be on your back, but his message is basically the good one.
“Just doing my duty”
Steve, the Team Leader
He supports the team and gives it direction. He supports collaboration and prioritizes work. He listens, follows, and decides. He’s the captain: ready to sacrifices if he can save the team and the project.
“Captain America is not here to lead the country. I’m here to serve it. If I’m a captain, then I’m a soldier.”
He has very good human skills because his main job is to guarantee that the team works together. He wants that each team member progresses and the work is done. He’s usually the one contact point with the team and, the most important point, he avoids that his team is interrupted/annoyed by others.
The team power
There are certainly other classes and most of us are multi-classed. Depending on the team, the context, our experience, and our taste, we are not of one caricature class.
Defining those classes is important. It underlines that the team needs those roles. If the team leader doesn’t know the weakness and the strength of each team member, he cannot correctly decide. As with the Avengers, there is a day a threat cannot be addressed by one of the Earth’s mightiest heroes, but together, the Avengers can.
And you, what’s your team?
You can also discuss this post on Hacker News.
We are developing an Automated code reviews for Ruby developers using Github, discover how you can become a better Ruby developer.