It's like an all-inclusive guidebook for how to look down upon others and discredit them internally without any of the messy business of actually communicating with them about "their" issues. Why improve when you can label, isolate, mock, and ostracize?
I totally agree that this guide would be much more useful with each time a paragraph 'how can you help these people improve themselves'.
But I think that as it stands now most people would understand that these are just clichés. In fact, using this as a guide to look down on other people would be the behavior of an 'Agitator'.
One piece of feedback I really liked from this comment thread was providing some guidance on how to get better at reading someone else's code. I've made an issue out of that (code illiteracy) in a few blog posts before and I think that HN commenter is right.
I think I'd like to do a few posts on how to overcome some of these traits - beginning with reading code.
This is great. I can pretty much put a timestamp on each of these of "when I started acting like this", "when I realized I was acting like this", and "when I made a conscious effort to stop acting like this."
I'd add the Doomsayer: The programmer who is constantly pointing out the ways in which any design could fail, no matter how likely or relevant to the task at hand such failure scenarios might be.
Healthy skepticism is beneficial, but I've seen teams paralyzed because one member has perfected the technique of raising unanswerable or irrelevant objections, often seemingly to present the appearance of being the smartest guy in the room.
You can usually turn these people into productive versions of themselves:
First, teach them how to do informed estimates for the probabilities of these negative factors coming into play.
Then, ask them to point out the probability-estimate below which they won't even bother to bring something up.
Finally, explain that your bar for this is higher than theirs, and request that they only bring things up if they meet your higher bar; for things that meet their bar but not yours, you'll just be discarding what they say anyway, so they'll just be wasting their breath.
I'm always torn about this one. As a manager, I hate this guy. They can completely undermine a team's motivation.
As someone who's been in this business for 30 years I've come to recognize that "unlikely failures" is just a synonym for "pretty sure it's going to happen at some point".
Also, there are way too many programmers around that are the exact opposite, and don't see any of the obvious ways in which a design will fail, so I tend to be kind of protective of those that do.
I like working with them and having at least one on the team, because they're a great addition to the "naive optimist" or the "carefree hacker-fixer" who always see the solution around the corner - in a couple of minutes of course. ;)
And: There's a lot of tech scenarios where being overly careful and actually seeing the impending technical doom in every corner is an advantage.
Similar to the pedantry you get by the human robot, Cassandras have their place - and good management and coworkers know exactly where and how to take them.
Maybe I'm just That Guy, and maybe your example is from a non-critical system, but if you are dealing with a highly available mission critical system, any change carries a risk, even the act of deployment.
The tension probably arises from disagreement over what is critical.
I wonder if I am one of these people. I have been trained by now-countless instances of things happening that I was told would never happen. I'm not "what-if-a-SHA1-collision-is-found" though.
These guys drive me nuts, but they are sometimes useful for identifying worst case scenarios that no one in their right mind would think of, but sometimes should.
Oh yes I so agree! These guys are a key mechanism for how a simple program that used to read a csv file ended up depending on a multi-site replicated database managed by an external team of DBAs, burdened with a 6 month release cycle. Rallying cry: "but that's not fault tolerant!"
Technically meteors are small objects that do not impact the earth (the ones that do are called meteorites), and meteor showers are completely harmless to both people and datacenters.
> When a Human Robot is confronted about an issue with his or her work on the product, they will respond with the following sentence every time: “your requirement was not found in the specification for this project. We require additional pylons.”
> Human Robots often tend to be conference organizers (see PyCon 2013) and moderators on StackExchange.
The "moderators on StackExchange" shot was good, but I really take offense to the "PyCon 2013" one. The reason stuff went wrong at that conference was because of the actions of one attendee, who specifically did not go through the process the conference organizers set up for dealing with reports of harassment.
The ability to read other people's code and understand the intent behind it is one of the highest attainments for a professional programmer. It requires two difficult, but important and related capabilities: first, that one be dispassionate enough about one's own views to even accept that other views exist, and second, that one be capable of understanding how code works from reading it (and perhaps interacting with it with a debugger or logging statements).
So, rather than lambast people for not being able to read code, perhaps we'd do better to praise those who are particularly good at it, and encourage them to share their insights, if they have them.
This was the one that made me uncomfortable too -- I tend to think reading code is just generally hard, but it occurs to me that if I am The Illiterate, that's exactly what I'd think.
Indeed, I could pinpoint at least 4 or 5 that apply to me (not at the same time, more depending on mood). How I pity my colleagues. I wish there was a "does this apply to you? Here is how to get out of it!" part to this taxonomy.
Reread yourself next time. There's many typos and places where you used the wrong h̶o̶m̶o̶n̶y̶m̶s̶ homophones. It's hard to take you seriously when you write "left in piece"...
Some speculate that Coinbase's problems may stem from their use of MongoDB (e.g. https://news.ycombinator.com/item?id=5428382). I wouldn't be surprised to hear that someone tried to implement an EMR system in MongoDB either
I've noticed a lot of Python coders to be pet technologists. They simply can't let go of their beloved Python, no matter what. It's as if to mask their incompetence.
I don't really see why the "Illiterate" is necessarily a terrible programmer, though. Code is the very opposite of literature: hard to read, easy to write.
I downvoted you because that was a trollish comment that added nothing to the discussion and seemed designed to encourage vitriol. The fact is you could substitute pretty much any mainstream language in that statement and it would still be true and still be a troll. People don't want to abandon skills they worked hard to learn just because someone else learned something different. This is true whether that person is a partisan of java, ruby, javascript, python or StandardML.
>I don't really see why the "Illiterate" is necessarily a terrible programmer, though. Code is the very opposite of literature: hard to read, easy to write.
Hmm...if you're writing in Perl or PHP, maybe. Though even then a good developer can write clean code even in those languages.
I'm very much NOT a fan of Python, but one advantage of Python is it's easier to write readable code.
As to the Illiterate: It's absolutely essential to be able to read other peoples' code if you're programming on a team. It would be nice if most developers documented their code better, but since 99% of them don't document well, it's critical to be able to dive in and figure out what the other developers have done.
Are you referring to "Python programmers? Some people specialize, you know, not to mention that a reader could read between the lines of your post and think that you might be fighting for more platform spread in a Python shop. "You dummies don't understand, Rust would be so good for this!"
I would add that I think that, a favorite of this board, the mythical "(top) 10% or (top) 1% programmer" is not so much a real thing as just an average programmer who happens to avoid each of these (and related) pitfalls in the particular job he or she is working on - well, and stays reasonably education in current tech and intermediate to advanced math and cs.
And the nice, the reasonable thing, about these description is that they make it clear these people are the product of particular environments.
Shoot, too bad non-gendered pronouns in English can be awkward. At about the 5th example, when imagining the roles, I was wishing for some women! Some variety would be appreciated probably :)
Nah, I got a handle on that a while ago. I know my skills and I know myself, it's just sobering to see so many of my motivations and behaviours described accurately. If I was convinced these programmer aspects were entirely negative, I would've succumbed to the debilitating effects of impostor syndrome years ago.
IMO, the island archetype is probably the most productive. At least in my experience, IM/Outlook/Thunderbird really kills what I can get done. And the corporate emails...
Nice post. I have traits of an Island and a Pet (Python) Technologist but you omitted listing my top archetype: The OCD Refactorist. I can't stand copypasta code, I have to make it DRY asap (plus many more refactorings, typically resulting in shorter, minimalistic code).
Seems to me like none of these descriptions is an actual terrible programmer (well maybe the "illiterate" or "stream of consciousness").
Actual terrible programmers write incredibly bad code. Their motivations are generally not the problem. I'd probably come up with a taxonomy like this:
The approximationist -- writes code that kind of does what was intended, and then writes more code to get closer to the intention, and then more code to get closer to the intention, and then more...
The design patternist -- writes implementations of design patterns instead of implementations of the specification.
The classicist -- related to the overnormalizing database designer, breaks EVERYTHING down into classes.
Really? I'd love to have people that focus on design patterns and nice classes. Sure, it'd suck to go overboard, but I've too frequently been stuck with people who use single letter variable names and 10 level deep for loops.
I love code that does what it's supposed to and can be understood and maintained. If design patterns contribute to that, great. But a lot of the programming I see is makework that lets mediocre programmers feel productive while at best not contributing to the project, and at worst (and more commonly) burying needed but poorly implemented functionality in a writhing mass of crap.
In general, I find people who use crappy variable names also write code that doesn't actually work.
The classicist and patternist use insanely long variable names (index or iterator or myForLoopIterator instead of i, say) that convey no information and write code that doesn't actually work and, frequently, fails in convoluted ways that separate cause from effect by splitting implementations of simple features across multiple functions, classes, and/or source files.
Basically my entire philosophy of life. The year I spent studying Buddhism in my last year of school rub off on me, and I still try and practice that every day, 8 years later.
Exactly - a great programmer would put his/her ego aside and become any one of these stereotypes if the situation demanded it.
Sometimes it may be prudent to keep some old tech running. Other times it may be better to push the boundaries of new tech. A strict methodology might work great in one situation, whereas a lone wolf might be better in another.
Really the only that that is consistently bad is if you just don't care or you don't put in the effort.
I should point out - using an old legacy technology is not the same thing as being an Arcanist. These archetypes all have one thing in common: taking a normal, routine thing that programmers encounter in their careers and take it to an extreme.
This can be re-written almost as "the development of the young programmer" where the external forces exert themselves and you get forced into some of the roles...
- sometimes the pressure is speed of project completion
- sometimes the pressure is production quality
- sometimes the pressure is code quality / reusability
- sometimes the pressure is following specs
- sometimes the pressure is "looking modern"
- sometimes the culture is whack and needs to be changed
- sometimes the pressure is team communication
- sometimes your tech stack only includes an AS400
Whatever the pressure you can seemingly get pidgeon-holed. I think this is where experience comes in and can guide you to the happy medium where external pressures are ignored and you balance the best you can.
"The Futurist cares not for quaint, passing concerns about stability, maintainability, or teachability – it doesn’t matter to him if it’s impossible to hire Erlang developers. New is everything."
Really? Lol. You chose a language that's stable, maintainable, and easily taught. Not only that, it's not a new language either. At least go with something that fits the description, like Rust or something (N.B. I like rust, where it's going anyways).
I don't understand your argument. You will have problems finding Erlang devs, especially if you are not located in the SV. You will find it difficult and/or prohibitively expensive to even get Erlang training for your devs. And yes, Erlang is pretty new in terms of having made the jump from total obscurity to near total obscurity less than ten years ago.
If you are lucky to have a team with the skills by any means go for it. But introducing Erlang to an average project with average requirements, staffed by average developers is a recipe for disaster.
No I didn't. I implemented the core of the backed at my last job in Erlang. Training newbies and hiring was not difficult. I interviewed the candidates coming in when I needed to pass the baton too.
And no, Erlang is not new. It is stable. The interface changes once a decade, and usually for the better. Stop making these wildly unsubstantiated claims based on little to no evidence. Even if you had a direct experience, it's certainly contrary to mine, and definitely not enough to warrant your sweeping assumptions.
An excellent example of the Hacker News subtype, Too Good To Enjoy Anything.
This specimen can usually be found three or four comments below top comment expressing extreme negativity or pessimism at any kind of good announcement, or as we see here, latching on to an irrelevant pedantic argument as reasoning for why a particular submission cannot be enjoyed. A deeply cynical creature, the TGTEA, or tigtea as it is sometimes called, generally shuns from new stimuli for fear of the feeling of pure enjoyment. For instance, even though this comment provides examples the OP asks for, it's unlikely this particular specimen will enjoy this comment.
The Arcanist is probably the closest to what I can see in myself. I tend to be protective over the systems I design in order to preserve them. This comes from years of geeking out about things like memory allocators and networking stacks, so when I catch a whiff of someone talking about introducing a terrible inefficiency or unreliability into the system I helped put together I put up the defenses. This post is a good satirical look at this aspect of my work, and probably a bit of a wake-up call.
I was feeling pretty good that I wasn't a stereotype, until I got to the Agitator.
I'm just really tired of people putting junior devs as team lead over me. I'd really like a lead that has tried different tech stacks, project management methods, and programming language paradigms. It's hard to respect someone making a novice decision based on their limited experience.
I don't think I am curable. I don't see how telling my manager and team lead why they are wrong, is something I should change.
You can't be a good leader if you can't follow. Thats the bottom line. I can't give you a group of people and expect you to listen to them and not alienate them when you don't seem capable of doing that when you have only one person to focus on.
I do what I'm told, and I get it done on time. But I also explain why I think it's the wrong decision, and I usually provide links to articles backing me up. I even try to include links to counter-examples. I have little patience for people that don't listening to experts. If you don't listen to me, then listen to these other engineers that are better than me. If you don't listen to them, then it's going to be really hard for me to respect your decisions.
I'd rather have a manager with just 10 years experience, than be a manager myself. I like working on products more than management.
I guess it's the threshold of when complaining is justified.
The things I complain about aren't CamelCase. It's more on the scale of, using MongoDB as the main store for transactional financial information. (Not a real example.)
And in that case, I feel justified at not only letting people know I think its a bad idea, but also telling his manager I don't think he should be the lead.
When I first read this, it stung a bit as I know I've fallen into these roles at some point or another in the past. I came to the comments here expecting to feel even worse about myself, but I was pleasantly surprised to see other people noting that they too have fallen prey to these bad habits. In the end, this has actually made me feel a bit more comfortable with my skillset as a programmer, and I now have some goals to strive towards moving forward with my career.
Context plays a part. The last company I worked at was so arcanist that the majority of new developers were relative agitators or futurists. They wouldn't have been elsewhere. They never stuck around beyond a year, and as the second longest serving, 2.5 years was all I could stand. Interviewing after working in an arcanist environment is depressing.
I wonder what other conclusions I can get from people that are more of a type?
For example a Arcanist is probable to also be faithful and a Futurist a cheater.
I'm just giving examples, I don't really know anything, that's why I'm asking for someone that knows more than me. (:
This is great. As I develop as an engineer I feel more and more confident about my abilities; great to read something like this blast away the Dunning-Kruger effect and help me recognize I still have a lot to learn. And not just about particular technologies. Very humbling.
Into which group would the person who is genuinely very technically smart, but thinks they're too smart comprehensively to even be bothered checking in with the actual users to see if their vision meshes with the actual requirements fall in this analysis?
There are many kinds of programmer, but apparently they're all men.
Edit: upon re-reading the post I see a smattering of "he or she" references at the beginning. They quickly give way to nothing but male nouns and pronouns. I wrote my comment after finishing the article, at which point I'd forgotten about the brief nod to the existence of female software developers at the beginning of the post.
"Social Justice-Driven Developer" - Spends most of his/her/their/xis/xer day trolling through the documentation, commit logs, code comments, and e-mails trying to find latent gender bias (when not doing so on discussion boards like HN.) Occasionally makes passive aggressive one-line commits to correct gender pronouns, spurring long internal e-mail chains that ultimately call more attention to the gender of the female/trans/nongendered developers on the team than otherwise. Sometimes causes people to get fired or become the target of widespread Internet outrage.
I don't think you were specifically accusing me of it, but I didn't set out looking for anything. I read the text, and I found their wording to be jarring. I don't think anyone is trying to push an agenda with their wording — they probably didn't even notice it. I slip up sometimes too, and I appreciate a helpful reminder when it happens.
You know what I find far, far more offensive than someone using gendered pronouns? The kind of smug, pandering post that deliberately strives for gender neutrality through tortuous 'he/she' verbosity.
I happen to think that most women are probably clever enough to work out that just because a writer has used a particular gendered pronoun, it doesn't mean that the writer's point applies specifically to that gender. Furthermore, literally none of the women I've known have ever complained about gender pronouns; such nitpicking seems to be the exclusive domain of gender-political activists and HN commenters.
I don't think it's an unreasonable thing to point out. Let's not pretend that there are no problems with sexism in tech. While this may or may not be a good example, literature normalizing that programming is a "boy's club" contributes to the problem that programming is perceived as exactly that - a boy's club.
I agree--- if any author were to use `he/she' consistently, I'd probably find their writing quite annoying. Still, that hardly means they'd have no other ways of being gender-neutral ;)
If one of these negative stereotypes had been female, "agile girl", say, can you imagine the ensuing shitstorm? When people set out actively looking for "OMG sexism!!" they will find it no matter what.
On a totally unrelated comment, the article is missing the White Knight: Someone that's more worried about the overall problems of justice and fairness than from the job he's suppossed to do.
E.g.: I'm sorry, I refuse to name variables after animals that are on the verge of extinction.
White knight? Why are you assuming I'm not a woman?
I think people can simultaneously have two goals. You might as well argue that school bus drivers are more worried about getting into an accident than the job they were hired to do; transporting children to and from school. Any competent driver should be able to manage both, just as any competent developer should be able to write good code while also not alienating people without reason.
I'm sorry, but now I'm confused. White Knight does have a gender undertone, at least in gender discussions. It wouldn't make sense to apply it to women, since the goal is painting the person as the stereotypical knight in shiny armor that comes to save the damsel in distress.
I'm sorry but in my world a White Knight is an amorphous (and obviously genderless) entity that bears any kind of armor (not just the shiny ones!) and saves other amorphous entities in distress.
Please consider revising your definition so that you stop excluding people with your close-minded 'cis' stereotypes.
