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.
guidebook for how to look down upon others
It is a general rule of human nature, you will do what you are incentivized to do.
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.
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.
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.
> 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.
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.
P.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?
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.
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...
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.
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.
Etc.
And that's just covering terrible CS graduates.
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.
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.
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.
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.
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).
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.
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.
1) Code
2) Ask people why their methods are broken
3) Code some more
4) Realise what they had worked perfectly and I suck
5) Repeat
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.
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.
I'd rather have a manager with just 10 years experience, than be a manager myself. I like working on products more than management.
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.
He can do this, but is terrible programmer?
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 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.
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.
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.
Hahaha, loved that!