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
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.
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 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.
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.
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!"
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).
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.
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. (:
> 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.
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.
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.
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.
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.
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 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.
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!"
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'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.
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 :)
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.
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.
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.
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.
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.
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 ;)
"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.
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.
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.
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."
134 comments
[ 3.3 ms ] story [ 195 ms ] threadP.S. Fixed the typo.
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
Homophones?
The middle way is the path to enlightenment. Few of these are bad because of their spirit, they are bad because of their extremism.
Argument to moderation. "The truth lies in the middle" is a false axiom. Sometimes it's either in the black or the white.
Your reply strikes me as a fallacy fallacy. It's not a logical fallacy if it's not used to support an assertion. In this case, it is the assertion.
http://lesswrong.com/lw/mm/the_fallacy_of_gray/
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 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.
My own personal favorite language -- Lua -- is also really easy to write readable code.
It also happens to run 3-100x faster than the equivalent Python, and has real coroutines. And easier C bindings.
There are other goals in programming language design than "make it pretty."
You may have a point.
I was definitely an Island as recently as a few years ago, and I've been an Artist before too. It's part of the learning process.
Apparently, I'm a melting pot of neuroses.
It's great to be a human, isn't it?
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.
I think regardless of our ability to do so, often times figuring out someone else's code feels like a horrible pit of unproductivity.
> Human Robots often tend to be conference organizers (see PyCon 2013) and moderators on StackExchange.
That literally made my day.
Having run conventions for a decade or so now, I'll buy it, we have many of that type.
By the way, "Software is a team sport and does not suffer those who do not play by its rules." I hope his team/company isn't an English speaking one.
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.
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 remember the first time I encountered this, and thinking the guy had to be on crack.
His quote: "A changed comment in code could possibly cause a problem, if the file were to become corrupted as its uploaded"
The tension probably arises from disagreement over what is critical.
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.
This is a fine discussion.
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.
And yet every place I've worked has had 1-3 programmers who wrote >90% of the code...
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.
At most, this piece is just a literary exercise that provides no solutions for the imaginary problems it suggests.
I would definitely change my opinion if facts were pointed to of actual projects and persons.
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.
[NSFHN] http://www.flamewarriorsguide.com/
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.
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.
"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.
E.g.: I'm sorry, I refuse to name variables after animals that are on the verge of extinction.
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.
Please consider revising your definition so that you stop excluding people with your close-minded 'cis' stereotypes.
There you go again.
It is a general rule of human nature, you will do what you are incentivized to do.
Hahaha, loved that!