This is pure speculation, but I’m currently thinking about patterns in programmer habits I’ve seen on teams I’ve worked on. After doing some research on the ole interwebs, I’m realizing there’s a lot of damage that needs to be repaired.
What This isn’t
Let’s get some clutter out fo the way. There’s a whole bunch written on archetypical programmers and nearly all of it – that I could find – was political, misogynistic, misguided, and wrong.
The “Two Types”
Let’s start with the “two types of programmers“. In this theory, there are only two types, the 80% who apparently hack on ten-year-old Java systems, and then the 20% who download Haskell on the weekends and actually do all the work.
There’s a logical flaw in the ‘two types’ approach. It’s all based on the Pareto distribution – the common adage as applied to, say, productivity, is that’s 20% of the people produce 80% of the work. I don’t have a problem with the Pareto distribution, just in other’s misunderstanding of it. There are two key misunderstandings that lead to the “two types”.
First Key Misunderstanding: False Equivocation
First, the thrust of the two programmers argument is that there are 20% of programmers out there who make all the posts, who use all the technology, who contribute to open source, who care about quality, and who do all the work. This is not what the Pareto principle says at all.
The Pareto principle (technically) says there is some small percent of programmers who make all the posts. There is another small percent of programmers who use all the technology. And so on – there’s nothing magical about 20% but more importantly, nothing necessarily correlated between any of these groups. It’s an assumption that if you’re in one subgroup – say the bloggers, you must be in the others – quality, productivity, interest in technology, and so on.
There’s no reason to think that. The argument falsely equivocates bloggers, or more appropriately, those who read blogs, with the productive few using the concept of ‘alpha’ programmers.
Critical damage to engine 1 of alpha programmer! Falling back to engine 2!
Second Key Misunderstanding: Context is Everything
The second misunderstanding here is similar to the first.
“Austinwiltshire”, you say “I get that maybe the groups of people who read blogs and who are productive aren’t the same. But certainly, you can’t argue with the fact that 20% of the team does 80% of the work. In one of those subgroups, like productivity, there are still alpha programmers.”
Kind of. Not really. Not usefully anyway.
The same situation occurs inside productivity as did between productivity and blog posting, except now it’s project-oriented. The top 20% of people on project A? Not at all the same people that are top 20% on project B. And so on. If you take a top performer out of his or her context, you have no reason to believe they’ll continue to be a top performer. This has actually been shown in studies that I have no idea how to find or link to.
Charles Duhigg points this out in his book, Smarter, Faster, Better. When looking at personal productivity, the only factor that consistently showed up across groups was: were you there when the early decisions were made? This is more or less arbitrary, on average, but gives a model to understand the 20% on any one project. They’re usually the people who were there at the beginning, or as early as possible, and so tend to have the whole system ‘in their head’, whereas latecomers are always trying to catch up to them.
Does this have anything to do with innate talent? No. It has everything to do with being in a certain place at a certain time.
Engine 2 critical! Brace for impact!
The Alpha Programmer Myth
This 20% bullshit is the same stuff that’s been spread about by neckbeards at the top – and I mean that term (neckbeards) literally – for years. Some people “have it” and some people “don’t”. Some people are good programmers, and the rest are just lucky to be able to call on good programmers.
On a certain type of team, you probably have noticed, there’s always one guy (and it’s always a guy) who pulls all of the weight. The master firefighter, the master designer, the sharpest coder, the best peer reviewer. If they didn’t have him, the team would be sunk. What certain type of team is this?
A dysfunctional one. What you actually have is a bully that you’re enabling.
The alpha programmer idea comes from a misunderstanding of early studies into programmer productivity which “showed” that:
The best programmers can be 10x more productive than average programmers
AustinWilsthire, “Quotes I made up for Rhetorical Effect“
I’ve gone into what’s wrong with the ‘common’ view of this adage in other posts. We’ll just sum up here and say that it’s a complete misunderstanding of the science, and it’s an intentional misunderstanding on another mission.
This mission is ultimately what underlies the “two teams” mentality, alpha programmers, 10x productivity and all the other bullshit that’s infected our culture.
Machismo – Or It’s Been Alpha Males The Whole Time
Very few people are 10x more productive than others, and you’re one of them.
That’s what this is all about, right? We read blogs to stoke our egos, we’re irritated that other guys at our company or school or whatever don’t ‘get’ us, and if only they saw how brilliant we are. We know we’re 10x’ers, and one day we’ll get our due.
All this talk of productivity has been a dick measuring contest this whole fucking time.
We want to believe that there’s a ‘certain type’ of person who can program, who really ‘gets’ it, we want to believe it’s magical, that only ‘some’ people can do it, and you can either do it or you can’t. We want to wipe away all of our past arguments with others over coding style or language choice or something else with a clear determination that everyone else was wrong – they were 80%’ers, and sometimes they win by sheer numbers, but we 20%ers, we have to stick together.
And all this time, we’re all pretty sure – though no one’s so politically incorrect to say – but we’re all pretty sure that the guys who are the 10xers are all white males. Because I’m a white male, and I’m a 10xer, and the people I think are also 10xers are white males. QED.
Let’s play a thought experiment. You’re studying violin. The violin is hard. Every day you show up, and your teacher, Mr. Yamamoto, berates you. He explains you must not be practicing hard enough, you must not really want it because you’re terrible. His other students – all Asian – seem to play violin better than you. Sometimes, more paternalistically – he takes you under his wing. He explains it’s really not your fault – some people have it and some people don’t. You don’t have to feel bad. He’ll keep trying to teach you violin, but you might also consider something he thinks you might be better at, like hockey.
Do you quit violin?
You sure as shit do.
And so, the few brave women and/or nonwhites who enter computer science programs, or code academies, and they look around and they see a caucasian sausage factory – they struggle. They struggle because everyone struggles a little. But they read it differently – you look around and see your friends.
You see people similar to you, and they seem to get it. You can too, just try hard enough and fight through adversity.
They see people different from them. And don’t think for a second they’re unaware of the 10x myth. They’re worried – they’re worried they’re the bad programmer. Why fight through it if it’s innate, why try if you’ve hit your limit and ultimately you’re a born 80%er?
Needless to say, I’m pretty sick of this dick measuring contest, and I’m really frustrated with the chilling effect its had on our industry. Because we’re all complicit – every time a minority drops out, we get more white and more male. And eventually, we begin believing the stereotype ourselves – we may have gone into programming thinking anyone could do it. But then why did all those black women drop out? I mean, there’s gotta be something there, right?
There isn’t. They dropped out because their professors failed them, our culture failed them, and our curriculum failed them. The dropped out because all of our systems are designed by and for white men, and we didn’t think of how to adjust them for others.
When you read a blog, and it says there are 10xers, and they read the blog you’re reading – or they say there are 20%ers, and they read the blog you’re reading – you’re just playing your role in trying to ad hoc reason your way into why our field is predominantly white and male. Because you’re either a 10xer or it’s all bullshit designed to make you feel better that there’s not more diversity and you’re benefitting from that.
You’re not at 10xer.
The “Three Types”
There’s another system out there, supposedly put together by human usability and marketing types at Microsoft.
Let’s break this down.
Mort wants things to work right the first time, out of the box, and he doesn’t want anything to be too complex. He gets frustrated easily and just wants to do his little bit of rote work and get home in time to watch his reality TV programs. Mort is dumb.
Einstein is always thinking. He wants to know the ins and outs of everything, think it through, he seems to always be leaning back in his chair, ‘thinking’. He seems to know a lot – seems smart.But he never seems to be working. He gets some stuff done, I guess. But ultimately, Einstein never seems to get everything done.
Elvis is a rock star. He’s pragmatic, he does exactly the amount of engineering needed. He’ll put in the hours to knock out stellar code. Women want to sleep with him, men want to be him. Gay men don’t belong in computer science, duh.
Smart, and Gets Things Done(TM)
This is all dancing around the point originally invented by Joel Spolsky. You remember? That guy who ran Fogzbugz into the ground? Yeah, peopled used to take him real seriously.
Anyway, he claimed that the key to hiring was to find people who both were smart and could also get things done. This was a euphemism, of course – Joel, also a big believer in the Mort/Einstein/Elvis break down wanted to hire smart people but got sick of hiring people who were smart enough not to do things the way he wanted. So he also wanted people to get things done. “Just fucking do it”
This kind of thinking still hits the culture – it’s a combination of the 10x myth and the ‘passion’ myth, that you should find that weird autistic programmer who will work 80 hours a week for you without equity. Those are the only men who deserve jobs, after all, cause they’re smart and get things done.
Why This May Matter
So what I’m proposing is none of those things. I’m not going to give you a system where you fit into a box that says “I’m the best!”. I’m not going to give you ammunition to dismiss your peers. I’m certainly not going to come up with stereotypes that make everyone who doesn’t understand what a monad feel idiotic, and everyone who doesn’t work 80 hours a week feel lazy.
We should aim for forty hour weeks. And no one knows what a monad is. Jesus Christ, you know people are talking out of their ass when their metaphor is a burrito.
Why make categories at all? Why not just let each programmer be who he or she is and who he or she wants to be? Because that’s actually really hard. Imagine you have a new junior hire come under your wing. You want to find out what drives them so that you can keep them motivated. You want to know what their strengths and weaknesses are, so you can hone their strengths and shore up their weaknesses. More importantly, when you have more than just one junior hire, you need to know how to make the team more than the parts.
It’s said good managers play checkers, great managers play chess. You want to play chess – use everyone for what they’re passionate about and good at. When you have one or two people, usually you can spend enough time with them to figure these things out. But when you have much more, you need heuristics. You need tools and models to help you simplify the problem. Let’s say you have two people on your team you both consider your “Goat” programmers. Putting them in the category goat makes it easy to figure out how they’re different from your “Fish” programmers – it’s primarily the differences between the categories.
Fitting It All In Your Head
Let’s say you have two people on your team you both consider your “Goat” programmers. Putting them in the category goat makes it easy to figure out how they’re different from your “Fish” programmers – it’s primarily the differences between the categories. It also allows you to go into that “Goat” category and say – well Bob and Alice are both goats, how are they different? Becuase once you have a category, you can start to put your powers of soft skills towards teasing out the remaining difference.
Trying to figure out how Bob is different from everyone else at the company is hard. Trying to tell how he’s different from Alice is much easier. Using a model like this, you may be able to get people closer to the work they value and are more productive at.
Secondly, you need to analyze your work – what kind of projects are we anticipating in the next six months, what kinds of problems are we facing? Different people get thrills in different parts of the development process. If you have to hire, rather than hire only for overall company ‘fit’ or team ‘fit’ don’t you want someone who might hit the ground running gobbling up all the work that’s coming their way and asking for more?
It also shrinks the amount of time it takes for you to understand what they need and what they want to be happy. If you already prescreened for Goats, and you know Goats like grazing, then you can make sure their desk is near a nice plot of lush green grass. Nothing frustrates a newly hired goat more than trying to squeeze into that fish tank.
As described below, the four types of programmers I’m envisioning here end up filling very different roles as they grow and mature in their careers. It’s mostly these drastically different career paths that you can see a major difference – and it’s an argument backward to more or less saying “Well if some people are better Head Goats and others are better Head Fish, maybe they start out naturally as Goats and Fish too.” Along with coaching people to keep the team gelled, coaching people in their careers towards parts of the projects they naturally get something out of makes the most out of their potential and keeps people happy.
The Bushman Hunting Tribe
Finally, this isn’t about reducing people. It’s a heuristic, a model, it cheats. It makes little boxes because it’s easier to think about boxes than it is people, and allows you more time to, ironically, think about people.
People can often play multiple roles on a team – they may prefer to be a Goat, but they are a reasonably good Fish. So if work changes and you need more Fish, you can coach them in that direction.
This corresponds to an archetypical theory that groups of males all tend to form the hunting tribe – the funny one, the smart one, the strong one and the leader. Likewise, teams that are lacking a Goat are going to naturally have people with Goat like tendencies shifting their work habits. So no one is stuck being a Goat, they may be happy doing multiple things. But often, a stream of work comes in, and it’s chewing grass (but not too close to the soil!) and guess what, you need a Goat.
What This Is
So… 2200 words or so in, we finally get to the system.
It asks two fundamental questions, and based on those answers, that’s where you get your categories.
What is valuable about code to you?
The first question takes what we do – we code – and asks what’s valuable in it. There are two answers here that I’ve seen. The first answer, and most common in my experience, is that code is valuable for what it does. This is the ‘as-a-means’ group. They write code primarily for what it does, for effect.
The second answer I’ve heard is that some people find code valuable without appeals to what it does. This is the ‘in-itself‘ group. They see code like any other means of human expression – and while you can certainly use literature to communicate, often literature isn’t having to justify itself to others.
Who is code valuable to?
This is the second dimension of our 4 part matrix. Both are questions about why a person codes and they ask the same question in different ways. The first asked why it was valuable as an activity, to begin with, the second clarifies valuable to whom? And yes, I used ‘whom’ right.
Unlike the first question, I usually see people evenly split on this answer. Some people believe that code is valuable for others. They write code so that others can enjoy it – either its effects or the code itself.
The second group tends to write code for themselves. They’re perfectly happy if others use it, but ultimately, they aren’t going to necessarily do something just to help someone else. They want to get something out of it too.
Everything’s a Continuum
Keep in mind, even though these questions tend to have two answers, most people are going to answer both answers, to varying degrees. No one isn’t at least somewhat happy when they see their work reused by others, and no one’s happy creating a system that does nothing either. We’re all ultimately coding for effect, for ourselves and others, and we also have opinions on the code itself.
The 4 Types
In traditional methodological style, I’ve given a hip and snazzy name to each quadrant of the matrix described above.
The Hacker wants to make features for people. Code, to her, is a means to an end. Ultimately she wants to see working features, and she wants to see them making people happy. This means they’re ultimately happy with things in their wheelhouse – do I know how to make this or fix this? If not, they’re willing to investigate. But too large of projects can exhaust them. They need that kick – they need to be able to say to someone – that thing that was bugging you? Yeah, I fixed it.
They love debugging and small problems that they can knock out in a day or so. They like racking up momentum, and moving things to the right on the kanban board. At times, they may be less than interested in new technologies or quality techniques like testing, unless these things can be sold and trained in such a way that it appeals to the hacker’s natural need to get shit out the door (for others), fast.
Contrasted with the Hacker is the Engineer. The engineer wants the code for its effects, they’re an ‘as-a-means-to‘ group just like the Hacker. But they’re primarily coding for themselves – they want to save themselves headaches later on down the line.
Engineers can take on large projects because they end up being methodical. They get a thrill out of being disciplined, following things step by step, and marking things off their list. They build the lists, methods, tools and everything else to make their own job easier. Changing requirements or design needs isn’t going to bother a Hacker, but it will bother an Engineer, because not sticking with their plan – which they put together – frustrates the hell out of them.
Engineers are happiest avoiding future work. They’ll test. They’ll peer review. They’ll have a disciplined coding style. They may or may not be sold on new technologies, depending on whether it makes their lives easier or more complex. They’re reasonably good debuggers due to their methodical nature, but they don’t really like doing it. The fact is, engineers don’t see debugging as helping someone else. They see it as fixing their mistakes. So it’s rough on their egos to have to do it.
In the smaller half of the matrix, we have the two types of coders who value the code itself more than what it does. And in the quadrant of people who value code in itself, for others, is the Artist.
The artist wants elegance, she wants readability, she isn’t afraid of new features of complexity if they ultimately shrink the problem space into a more elegant one. She’s an expert in most new technology and libraries because code is for others. She’ll write code, intending for it to be read – even celebrated as good work. And she’ll read others code, including libraries, APIs, and other tools.
She’ll be great at emphasizing reuse – to the artist, coding is an intrinsically social activity. That means GitHub comments, it means peer reviews, it means design reviews, it means learning about other people’s projects and seeing if you can use them. It means sharing your own work with others.
Artists most want the respect of their peers, and they most want to make their peers happy with the code they produce. Artists, like the type below, Builders, may have a tendency to exhaust themselves trying to build the most elegant system. But unlike Builders, Artists are going to be unhappy on any team where they and their work isn’t valued by others. An artist who brings an open source library up in a meeting only to be shot down by someone else who’d rather build it in-house is going to believe they aren’t adding value.
Artists enjoy refactoring, collaborative design, and peer review.
Because it’s there
Builders value code in itself, and they program ultimately for themselves. They see the problem that code solves as challenges to their own ability and talent to see if they can devise a solution. The solution to them isn’t merely – can it do the thing. That way lies hackers – no, the solution, to the builder – is everything. It’s doing the thing, and how you did it.
Ironically, while the Builder is happy to use off the shelf components in building their master system, if that off the shelf component solves a problem the builder finds ‘interesting’, they’re probably going to reimplement it themselves.
Builders can solve big problems. Compared to Engineers, builders may even solve big problems for which there’s no good solution. Big familiar projects are Engineer’s wheelhouse, while big unfamiliar projects are the Builders.
Builders will not shy away from scope or challenge. They can get bound up in it, and it’s something to worry about. And, unlike other developers who may get bound up and need help – the real challenge of a Builder getting bound up is no one can help them. If they’re stuck, you’re stuck. The project is stuck. They’re often going to be your best expert on a domain – that’s why they’re doing their work. And if they don’t know, you’re fucked. You’re stranded on Mount Everest.
Builder’s aren’t the biggest fans of debugging, as, like Engineers, they take bugs as a personal affront to their ability to solve the problem. But nearly every other activity they’re happy doing – design, testing, review – so long as they see a challenge in it. If it’s not interesting to them, they’re going to lose energy, fast.
Categorizing developers is tricky. Often, in the past, it’s done nothing but reinforce biases that keep our field predominantly white and male.
My categories are not that. They’re speculative – I may be wrong. But they’re also each bringing something to the party. They have strengths and weaknesses, they’re best in a team with other people. I’m not about hiring Elvis and being done with it. You have to hire them all – and more importantly, as they grow, you’ll definitely see their strengths and weaknesses grow.
Hackers, Engineers, Artists, and Builders – they all do the same thing, Code. But for different reasons, and for different people. Those reasons can help figure out what motivates someone to do their work, and help you tailor the workflow to them so that they get out of it what they want and they’re most productive.
My sister and I had a debate a while ago. I mentioned that I had seen some requisitions that specifically mentioned “Comfortable in ambiguous situations”. I felt like this was a cop out – I argued that it was management’s job to remove ambiguity. Ambiguity is, of course, a common occurrence in the workplace, but management is out there to make decisions and remove it.
She disagreed. Some people need to be comfortable with ambiguity, she argued, as it’s just how life is. Management has nothing to do with it.
I’ve found that we were both right.
Good management seeks out, finds, and removes some ambiguity. To do that effectively, the manager herself needs to be very comfortable with the rest of the ambiguity.
Small foray into quantum computing. A traditional computer has on or off states, and it uses a clock to cycle through those states many millions of times a second. A quantum computer, on the other hand, can be both on or off. It’s only when you measure it that it ‘collapses’ to a single state. If you feed it a problem that’s amenable to quantum computing, it can solve it exponentially faster than a traditional computer.
The kind of ambiguity you remove
To work effectively, as a manager, your team members need to have a clear idea of what it is they need to do. In terms of keeping your team gelled and your team members engaged, they need over communication. People want to know what’s going on at all times, otherwise, they’re going to be preoccupied with figuring it out. And team members need especially to know how their actions are coordinated to get the most effect.
So a manager needs to root out the ambiguity in that situation, dissolve it, and make sure everyone knows the game plan. This is not micromanagement, very few real decisions need to be made. Often, when everyone knows everything they can, the right course of action is obvious. Nothing is so persuasive as a clear chance at success.
To set a quantum computer in action, you must entangle it’s ‘qubits’. That means they must each share state with each other at the get-go so that they can begin computing. If each qubit itself was just a fuzzball of 1 or 0, you’d get a pretty shitty random number generator. Instead, each qubit is a fuzzball of probability, and they’re all highly correlated. They’re on the same page.
The kind of ambiguity you keep
Another part of working effectively as a team member is being able to focus, and also being trusted to make the right decisions, even if it means you go down a rabbit hole every now and then. That means an effective manager needs to be comfortable with the ambiguity of herself not always knowing exactly what’s going on.
Get that? The team needs to know everything, you do not. Well, in a less hyperbolic way, there are contexts in which the team working as a single unit is very important, either during complex tasks or during emergencies. It’s an effective manager’s job to make sure that communication is loud enough that everyone feels comfortable and on the same page.
If you check a quantum computer – its state collapses. It’s now a traditional computer, with a state that’s now known. You might have to do that periodically to get the answer you’re looking for, but the longer a quantum computer can stay entangled, the more powerful it is as it explores more and more of the ‘solution’ space, or in our team’s case, the ‘decision’ space.
There are rarely times when the manager herself needs to know everything. Did someone use an OO style strategy pattern, or just pass a first class function? Are we going to use Redis here or Mongo? The more you meddle here, the less your teammates feel trusted. You need to be comfortable with the ambiguity that the choice of Redis or Mongo may be an unknown. You especially need to be comfortable with the fact that you might not know, and you may still be asked by your management what cache was chosen.
My boss is going to find out I’m a fraud
Don’t get me wrong – if your own management meddles and asks for details they don’t really need, it’s not like I’m saying that’s a good thing. An effective manager, even yours, ought not to ask what cache was chosen. But you go to war with the army you have, not the army you want, and if we all quit whenever our managers made mistakes, everyone would be unemployed.
There are times when your own management might meddle, and that’s the worst. Because you’ve put effort into not keeping up with every detail of your team, which means you don’t know what to tell them.
The cost of ‘checking in’
Let me put it this way. You could try and stay in the loop and know the nook and cranny of every decision your teammates face. Ultimately what we do in knowledge work is just make decision after decision, and most of them are noisy. If you have a team of two or three people, or if they’re particularly junior a few more, you may be able to do this. But this doesn’t scale. An effective, large team can make decisions faster than you can understand them. You can become the bottleneck and double check everything. This is the exponential speed up of the quantum computer – the quantum team.
The more you check, the more all you’re capable of is traditional computing. You lose the exponential speed up that’s found in quantum computing. You collapse the system too often, and it’s no faster than the processor in your laptop. It may, in fact, be slower. You let it hum, and only check it periodically, and it will hum.
You start to let most of those decisions smear together. You can gather the large details when it’s low effort for your team members to provide them, and trust that even though the actual state of the project is ambiguous to you, your team is going to take care of it.
Let them entangle.
BUT AUSTINWILTSHIRE, WHAT DO I SAY TO MY BOSS?!
It’s surprisingly easy to respond to a manager asking for details they really have no benefit asking – let them know that you:
- Don’t know and
- You’ll look into it
Take an action to get the answer to their question in a timely manner. It’s not that hard.
What you’re really afraid of, here, is that you’re going to look stupid in front of your boss and colleagues, or that you’re going to look inept that some bad decision is taking place that you don’t know about.
What’s actually going to happen
No one is really going to give a shit what you say, they’re all more worried about looking dumb themselves. And for the most part, your boss just wants the answer, she doesn’t care if you have it right now. This isn’t a pop quiz.
Moreover, the chances that the decision is going to turn out ‘bad’ are slim to none – a trusted and gelled team makes the best decisions, on average. So, sure, maybe you do some digging and you find out something’s wrong. But 99 times out of 100, you’re not going to find anything. You’re like, the least qualified person to do so.
I followed your advice and now I think I’m going to be fired
What if you have a boss who actually ridicules you for not knowing? Well, you can attempt to convince them of the wisdom of this. They clearly aren’t comfortable with ambiguity, and maybe if they opened their eyes and learned that knowing every little detail of the organization doesn’t make it run faster or better.
Most likely they have a managerial “philosophy” (if you want to call it that, really they’re just bad at management) that’s going to clash with yours. In this case, I would probably consider updating your resume. Your boss is actively trying to slow down the engine of the organization, either because their ego is so big that no decision ought to be made without them, or so small that they’re panicked they’re going to be found out by their boss. Poison either way, really.
Embrace ambiguity. Wait until there’s a question until you find an answer. Let the quantum computer churn. It’s capable of way more than you are.
We’ve all heard of the “No Asshole Rule”, which applies to individual contributors as well as management staff. Assholes notoriously treat their subordinates differently than their superiors, and so can be wrecking havoc but be unnoticed in the organization since the people who can coach or dismiss them are unaware.
There are other anti-patterns of management, and specifically, anti-patterns of manager as well.
The one that I’d like to mention today is The Cynic.
In WW1, during the last German push into France before their lines collapsed, the Germans rounded up their most crack soldiers and least cynical officers to create shock troops at the front of this push. I found this interesting that they’d be so interested in rooting out cynicism, especially in a war that rebirthed the whole cynical movement, and in particular, rooting it out in their officers.
A cynical infantrymen who also happens to be a crack shot and know to keep his head down, he might still be asked to be in this shock troop. But a cynical officer, no matter how veteran, was asked to stay in the reserve. Why is this?
Cynicism, especially in a managing role, is corrupting and contagious. When individual contributors see managers who are cynical, they quickly become cynical too. And often, they become more loyal to their cynical manager – who “gets” it – than to the cause or organization they ultimately work for. When people become cynical about their project, it’s not mere disengagement, it’s philosophically rooted disengagement.
In reverse order, the disengagement you see in cynicism isn’t simply remedied. They no longer want to work on the project because they no longer believe the project is worth while, and are intrinsically skeptical of any attempts to persuade them otherwise. Compare this to disengagement caused by over work, or some set backs, or stress at home. These can all be solved. Cynicism is far harder to pull back from.
Secondly, loyalty to a front line manager is not necessarily a bad thing. But this loyalty comes at the expense of the organization. There are techniques which would endear loyalty from an individual contributor to a front line manager and ultimately to the organization as a whole. These techniques don’t draw a dividing line between the organization and the manager, who is ultimately always the representative thereof in the individual contributor’s eyes.
Cynicism, however, drives loyalty to a manager by drawing a line between the manager and the organization. “Us versus Them” grows, with the front line manager trying her best to make sure she’s on the “us” side. A non-cynical manager would not draw this line, and try to fight us-versus-them mentality by ensuring people on either ‘side’ talk to each other and understand each other’s perspective. By talking repeatedly about the shared goals, and shared hardships. Cynical managers do not do this.
Cynics can actively drive away good people. They’ll advocate to folks under their spell hat they should leave, that things really are that bad. They’ll chase away new hires by airing dirty laundry. They’ll attempt to convert other managers to their cynical viewpoint. They’ll be difficult to work with for their superiors, but drive the loyalty of their subordinates.
I am not arguing that a slip of cynicism or sarcasm here or there is going to ruin your career and poison people you’re supposed to be serving. That’d be impossible, and moreover, a sarcastic comment now and then helps people remember you’re human like them. It’s just important not to make a habit of it. There are more effective ways of seeming human like being a good listener that doesn’t require you to bad mouth anyone.
Also take note, I’m not arguing against cynicism in individual contributors. Indeed, a negative attitude can often spot risks early, combat group think, and keep others challenged to improve – so long as it doesn’t become contagious. A little cynicism, especially in the front line workers, can help keep negative information flowing upward, and let difficult news out rather than trying to hide it.
Anyway, I don’t have any answers – try not to hire them. But they’re about as hard as Assholes to detect. And try to coach them out of it – I know early on, I got some key advice to be less sarcastic because people were going to take me too seriously. But there are some die hard cynics out there who may not respond to coaching.
Jakob Heuser is refusing to do the code challenge, and because of that, he’s a no hire.
We use code challenges at my job because measuring technical ability is notoriously difficult, and an at-home code challenge is by far the best way to measure it.
The take-home aspect gives candidates the time and breathing room they need to think through the problem, a rough downside of in-person code challenges. Additionally, the extra time means the challenge’s difficulty can be ramped up. Seeing whether or not you can code Fizz Buzz isn’t going to be as good of a judge of ability as actually taking a small feature from requirements to testing.
Most of the people who’ve refused our code challenge have been candidates that we were already on the fence about technically. I’ve always taken a refusal to do a code challenge as a sign that the candidate was uncomfortable with its difficulty, and a self selection out.
Additionally, many others who aren’t necessarily looking but will avoid jobs that have code challenges as ‘beneath them’ are typically people who haven’t been able to develop for years and are afraid of being found out. Thus, in addition to the challenge helping us judge technical ability, it also helps us screen out developers so arrogant as to believe that position on our team is their birthright and shouldn’t be verified by any objective tools.
While Jakob worries a code challenge might cause strong candidates to walk away to other companies who don’t offer them, that has rarely been the case here. We have had only one candidate walk away who we believed was strong but didn’t complete the challenge. In this case, better selling of the company up front usually can keep most developers interested enough in the company to complete the challenge.
What about other approaches like Github repos? Jakob seems to argue that code challenges require too much time from candidates, time they’d rather spend on their hobbies or families, but then claims candidates should be graded on their open source contributions? Who has time to contribute to open source but can’t find a few hours to work through a code challenge?
Finally, what about candidates who game the system, especially for larger companies, and get an immaculate downloaded version of the challenge? Plagiarism is incredibly easy to detect these days – try googling a few lines from the candidate’s solution and see if stack overflow comes up. Moreover, try a live code review and see how well the candidate can describe their solution – but you really should have been doing that anyway.
To sum up, code challenges are probably the best tool we have in finding and hiring great technical talent, but if you aren’t that technically talented – or think having to produce actual proof of your skills is beneath you – by all means, go apply at LinkedIn.
I’ll often find myself muttering that the code I am having to fix lacks documentation. I can’t figure out what does what – it’s overly complex. To boot, it’s probably unreadable.
I take away from this experience that I should write more readable code. That I should write documentation, and keep things from getting too complex. But this may actually be a confirmation bias causing me to make the wrong decisions, or at best, a case of correlation does not equal causation.
What happened here was something broke, and I had to go into that code and fix what broke. When I get into the broken code, I find it poorly documented, hard to read, and overly complex. Since I don’t want to feel those pains in the future, I resolve to change my behaviors so that the next time something breaks, it’s easier for me to debug.
The next time something breaks…
Instead of focusing on writing code that’s well documented, simple and readable, why don’t I instead focus first and foremost on code that doesn’t break in the first place? No one complains about the code they don’t have to fix, no matter how unreadable, complex or poorly documented it is.
Indeed, if I adopt the habits of readable code, simple designs, and thorough documentation and find my life getting better, it’s far more likely that those practices didn’t just make debugging easier, they made debugging more rare. Code built with those habits tends to be less defect prone in the first place.
The amount of effort we put into our designs is not limitless, and ultimately, time spent doing one thing can often cost us time spent doing another thing. Some practices, like writing readable code, are relatively cheap whereas others, like effusive documentation, can be expensive.
It often makes more sense to spend time you might have spent documenting on making the thing you’re documenting less error prone to begin with. If it never breaks, the documents you slave over may never get read. Likewise, if a certain software technique – such as functional programming in a strictly procedural shop – gets your work flagged as unreadable, it may still be worth it due to the lower defect density.