Nerds, we need to have a talk (2011) - <AUTHOR> http://www.thingist.com/item/4372/ <comment><USER2> Seriously, America is going to drown in shoulder-patting and hooray cheering. This taboo on negative opinions is ridiculous. We're teaching entire generations that we cannot fail as long as we try hard enough, and that it's the attempt that counts. Seriously, screw that.

It is a vital skill to be able to filter through feedback, take the useful parts to heart, and shrug about low, nasty, useless comments. To learn from mistakes and do better next time. Why is that bad?

Sure, we should attempt to stop the low/nasty/useless feedback, but that's not so clear cut as we'd like it to be. Until we figure out a clear line, I'd prefer honest (and sometimes nasty) feedback over a culture of non-stop shoulder patting.

<comment><USER3> This isn't the sort of thing author is talking about.

We're talking about the nasty, mean-spirited, no-holds-barred evisceration of each other by hiding behind the guise of criticism.

Take a few days ago:

"GitHub Gracious Helps Female Programmers Cower in Fear"[1]

Nobody is saying you have to agree with everything GitHub does re: sexism, or that they are above criticism. Nobody is saying you should be patting everyone on the back and giving gold stars for effort.

But what is that, really? You couldn't just say "this is wrong and doesn't help" or "your solution makes the problem worse"? No, author in this case had to go with the most needlessly inflammatory, mean-spirited, and downright _asshole-ish_ comment possible.

Presentation matters. Criticism wrapped in vitriol becomes just vitriol, and vitriol wrapped in criticism still doesn't become good criticism.

Disagree away, but the way the geek community behaves it's clear many members take a perverse _glee_ in eviscerating each other via "criticism". We _revel_ in others being wrong, and we positively wet ourselves at the opportunity to point out this wrongness with gusto and vitriol. This perversity is what the author was railing against, not your ability to disagree in general.

[1] [http://www.thepowerbase.com/2013/04/github-graciously- helps-...](http://www.thepowerbase.com/2013/04/github-graciously-helps-female- programmers-cower-in-fear/)

<comment><USER4> > Presentation matters. Criticism wrapped in vitriol becomes just vitriol, and > vitriol wrapped in criticism still doesn't become good criticism.

As if it would help you prove your point, that's completely braindead. What you describe is just a different form of shooting the messenger; you don't like the way they said it so you ignore what they said. For example if I point out your solution is N^2 and you're an idiot for doing it that way instead of N log N you may not be an idiot, but the solution is still a bad one.

If vitriol is the motive for the criticism then by banning the vitriol you've also lost the criticism. This is really a huge problem for Hacker News; by banning unkind critics they've lost a lot of actual criticism. The result is HN exists in a bubble of trends and fads because the people who take glee in deflating them get banned.

> [GitHub Gracious Helps Female Programmers Cower in Fear]... author in this > case had to go with the most needlessly inflammatory, mean-spirited, and > downright asshole-ish comment possible.

This is a good example, but not of what you think. The content of the blog is reasonably and calmly presented, but if you throw that away because of the flame title then you've lost that.

<comment><USER3> > _"but if you throw that away because of the flame title then you've lost > that"_

Yes, and rightfully so. I have no problems with the author's views, I have every problem with people being assholes and douchebags with each other.

I have _zero_ qualms about missing the thoughts of people who haven't the least modicum of respect for their fellow man. I don't care how smart you are, at the end of the day intelligence, or being right, is not the measure of a human being.

> _"you don't like the way they said it so you ignore what they said"_

Yes. Like I said, presentation matters.

The antisocial, the arrogant, the whatevers of the world who cannot massage their thoughts into something worth communicating will rage impotently at the fact that no one is listening to them. Us nerds have a bad habit of letting this turn into a superiority complex, but no matter how superior you might feel, still no one is listening.

At the end of the day, we're each only on this lonely rock for a short amount of time. Many of us have figured out that we'd much rather be good to one another with our time than to spend it stroking our egos by seething with rage about everything.

<comment><USER4> > Yes, and rightfully so.

I think you meant _righteously_ so. You are saying to discount facts and logic because the person saying them offended your sensibilities. You're just building a bubble of ignorance around yourself by discounting everything unseemly.

The reason why you find 'geek culture' hostile is because geeks tend to value merit more than you value morality. The computer does not care if the n log n algorithm was created by an evil genius or Ned Flanders, and neither do geeks.

There is tons of creative and worthwhile content on 4chan than you'll ever know and will deny exists (or has a right to exist). At the end of the day, there's more humanity on display at 4chan than HN.

</comment></comment></comment></comment></comment><comment><USER5> The worst thing that can happen to a Show HN post is people totally ignoring it. When I post something of my own here, I expect a certain amount of honesty and criticism, as long as it is constructive.

Being "constructive" does not mean being congratulatory, shoulder-patting, praising, or anything like that. It means that the feedback itself should provide some kind of value, preferably for the benefit of the project creator.

" _What's the points of this? I've been doing the same thing since the 80s by piping four shell commands together?!?_ " - is not really constructive.

I think using the slightly formulaic " _What I liked: X; What could be improved: Y_ " has a high chance of being constructive feedback.

Meta discussions can also be OK.

The infamous " _does the world really need another X_ ", almost invariably deserves the answer " _yes, why not?_ ".

Letting people know you are unlikely to use the code/product/gizmo is also constructive, especially if you can manage to tell why.

As the article stated, comments in the form of " _Y U MD5 STOOPID_ " is never OK and generally don't do anything to raise the level of the discourse. As a general guideline, comments designed to make the commenter look good or smart or superior do not usually improve the quality of the discussion, even though mods sometimes tend to reward this behavior for some reason. They shouldn't.

<comment><USER6> > "What's the points of this? I've been doing the same thing since the 80s by > piping four shell commands together?!?" - is not really constructive.

> Letting people know you are unlikely to use the code/product/gizmo is also > constructive, especially if you can manage to tell why.

By my reading, these two statements contradict each other. The quote you claim is not constructive seems to me to be saying the author sees no value in the hypothetical contribution, as it offers no additional power and less convenience than what he already uses, and therefore he won't be using it. Isn't that exactly what say is constructive in the second statement I quoted? If I'm misunderstanding you here, can you explain what I'm missing?

<comment><USER5> That first example was from a specific thread that actually happened when someone made a command-line tool, and the whole discussion was incredibly unproductive and full of "look at me, I solved this eons ago, this developer sucks" messages. You're probably right there is a fine line between those two, but they are not identical. It's the difference between saying why you wouldn't necessarily use something on the one hand, and showing off while berating someone on the other.

Asserting that a project's existence is unjustified is a bold and unfriendly claim. Saying that it's simly not for you is another matter entirely.

</comment></comment></comment><comment><USER7> I agree. I think the worst of HN comes out whenever anyone submits a personal blog post.

If you read the comments for ANY blog post submitted, you will see how it has become a giant game to discredit everything the author says. I think it's good to be skeptical, and as nerds we have plenty of skepticism to go around, but there are ways to be do it with a little more taste and respect.

I've been looking at some of the profiles of the main cynics I see time and time again and they have like 6000 karma, but only 3 submissions in their entire lives. Crazy to think they just get all of that karma from tearing down other people's work while not creating anything themselves.

<comment><USER8> So perhaps, the design of Hacker news itself (or point-based systems) reinforces the cynicism that exists in most of the posts you are referring to.

</comment></comment><comment><USER9> I'm glad the OP brought this up and I think its an important topic for the HN 'community'. Innovation loves support. When innovation is supported, you get more innovation.

On several occasions, I've seen a poor soul post a project on here that represents a lot of blood, sweat, and tears. There will be enthusiastic support, constructive criticism, and often too many haters. I'd love it if the haters left -- maybe all head off to hate picnic or something where they can spit pickles at each other.

Perhaps a basic issue is that people say things in online commentary that they wouldn't say face to face. I think that's fundamentally wrong and mostly accidental -- a result of people's cognitive models not catching up to what's actually happening. Thanks for listening :)

<comment><USER10> >Innovation loves support. When innovation is supported, you get more innovation.

The same thing can be said for mediocrity and outright regressions.

>people say things in online commentary that they wouldn't say face to face.

This is definitely often true, but not usually. I'm nicer online than I am in person, because in person I can smile, apologize, and make goofy faces to blunt honest criticism. Online, all I have is smileys and exclamation points, which make you read like a wide-eyed idiot, but don't always make you read like a nice wide-eyed idiot:)

</comment></comment><comment><USER11> It's interesting to me that the Hacker School "rules" post, that essentially boiled down to the same thing (Don't Be a Jerk), is filled with positive comments:

<https://news.ycombinator.com/item?id=5639430>

While this one is full of people attacking the guy, basically proving his point.

</comment><comment><USER12> The appropriateness of this showing up on Hacker News, the Internet's favorite dream killer in Show HN threads and perpetual contest to see who can be most correct in comments, should be lost upon no one.

If you participate here -- myself included -- this is a message to heed.

</comment><comment><USER13> Honestly I can't relate to this at all.

Most of the people I work with (professionally and personally) are perpetually self-critical despite being very intelligent and more than capable. The humility comes from growth over time and being able to remember doing work they'd consider terribly flawed today. If you're working with arrogant people, they're probably not growing and it'll make it harder for you to as well.

<comment><USER14> I took it to be more about nerds online. I haven't met too many people face to face that are even a tenth as rude as 90% of the people I see online. Of course, I arbitrarily picked those numbers. I'm going to point that out before I get flamed.

<comment><USER15> Louis CK touched upon this in his "Oh MY God" show on HBO. Empirically speaking, people tend to act with less accountability when they're inside of cars, behind protective barriers, including the internet.

<comment><USER16> "No Such Thing as Elevator Rage"

NOSTER. Coined and minted - because nerds are overly acronym-shy, I think

</comment></comment></comment></comment><comment><USER17> I totally agree, there is always room for constructive criticism, but it should be tempered with a soft hand and helpful suggestions. As a person who was picked on most of my life, it's pretty disheartening to endure the same thing inside a group I consider my community.

</comment><comment> at-fates-hands The first place I worked at had this same issue of developers discrediting other people's code. It was an incredible "alpha-male" syndrome to witness. Then this same group of developers would brag about all the stuff they were working on outside of work. The ongoing pissing contest almost made me quit my job as a developer.

Don't kid yourself, Nerds and Geeks are just as competitive and nasty as jocks are.

</comment><comment><USER18> From reading How to Win Friends and Influence People, I think it boils down to self importance. We like to put others down because it makes us feel more important. If you recognize and let go of that desire as the book tells you to do, you can use the phenomenon to your advantage instead, and you learn that making others feel important makes you win them over.

</comment><comment><USER19> This post is extremely stupid. What is this, the first grade? If you can't take honest criticism, you suck. If you think computer technology is full of mean people, try working in finance. My peers don't hesitate to give me honest criticism and that's one of the things I like most about CS. Maybe you should start your own company called "we should be super nice to each other all the time" and have your product be an email subscription service where your clients receive affirmations like "you are a skilled person with value and you have a cute chin" along with some heart graphics and sound effects.

<comment><USER20> Can't we give honest feedback without going into an epic fit of nerd rage over it?

Besides, the worst fights I see among programmers are over trivial matters of opinion anyway. Ever seen people fight over indentation styles, or the proper way to merge upstream changes into a local git repository, or whether functional or object-oriented programming is the One True Way?

The anger in these debates isn't teaching anyone a damn thing, except that the color of someone else's bike shed is really, really important to some people.

<comment><USER21> Honest feedback:

1) "I really didn't like the way you did X. It broke Y on my browser, $Browser."

2) "Oh god, why did you chose to do this like this? It's broken and stupid"

I hope that people don't nerd rage after (1). I guess they might, and if they do that's a problem.

</comment></comment></comment><comment><USER22> I think the hacker community, just like any creative community, suffers from a bit too much evangelism and misdirected nerd rage. It's important that we understand our common goals and keep those in mind as we interact with each other. What are these goals?

For me... \- learning how to solve real-world problems using software \- sharing ideas and reflecting my perspective in the conversation \- understanding how others think about SW topics, more learning \- criticizing decisions in order to improve my critical thinking skills and knowledge \- getting feedback from my own ideas to see how well they stand up

I realize that some of these are somewhat redundant, but I feel they differ in nuance. In general it is about _improvement_.

Also, some people are just way too sensitive and need to realize that an attack on one's idea is not an attack on oneself. I have general respect for all people, but I might think your idea is stupid.

The best thing we can do is make sure we do our best to absorb hostility and respond with objectivity.

</comment><comment><USER23> "If there spelling or grammar is off, just let it go."

On purpose? :)

<comment><USER24> You failed the test.

</comment></comment><comment><USER25> Nerds generally aren't any more mature than jocks. We just don't fight as well, so we (wisely) keep quiet in situations where the risk of eating a knuckle sammich is high.

</comment><comment><USER26> I agree with the premise of not being gratuitously nasty. But I wish he hadn't made it sound like all programming is as consequence-free as skateboarding.

If you're programming as a hobby, it doesn't affect anyone but yourself. I totally support your using Arduinos until you figure out you can build one yourself in 5 minutes on a breadboard.

If you're programming professionally, the rules change. It's not all about supporting your personal learning experience. If you use simple hashing instead of bcrypt, and you have real users, you are potentially hurting people. It is literally true that if you don't know better than that, you should not programming a computer (well, programming an authentication system, anyway).

So yeah, don't be nasty. But also don't think your self-esteem is more important than doing a good job.

<comment><USER27> Nobody is saying "don't do a good job" or even "accept sub-standard work". They're saying act more like a mentor than a critic. Mentors don't tear their pupils down, because you can't teach in that environment. Help people become better; don't stroke your ego at others' expense.

</comment></comment><comment><USER28> I like it to a degree, the 'geek' culture (how I hate typing that) cuts through bullshit faster than others.

I don't mind being insulted if it comes with a helpful suggestion. I LOVE IRC channels where you get the answers: "You're shit for asking that question, but the answer is X".

<comment><USER9> In general, I find that if the conversation stays civil, the topic retains the spotlight and is not overshadowed by personalities and hurt feelings.

In other words, IME, you can 'cut through the bullshit' w/o being a dick and you'll achieve better outcomes. Plus, you won't be a dick.

<comment><USER29> Yeah, I don't mind some heavy criticism at all when it's deserved-- but not everyone can take critism as well.

I don't know if this is true, but the stereotype of geeks is that they lack "emotional intelligence". I think it's important to recognize the people we talk to on irc, news lists, etc. are people too and it's important to be truthful & helpful, not just needlessly hurtful.

</comment></comment></comment><comment><USER30> Previous discussion:

<https://news.ycombinator.com/item?id=2322696>

(I feel older now to realize I've been on here for two years, long enough to remember the previous submission)

<comment><USER16> Care to comment on whether internet nerds have gotten nicer or meaner since 2011?

<comment><USER30> Not a clue.

</comment></comment></comment><comment><USER31> In other news, nerds are human, and posture and bully and jockey for recognition like all humans do.

<comment><USER32> My sentiments exactly. I've met plenty of condescending assholes at Google but them being geeks was not the reason why they behaved like jerks.

</comment></comment><comment><USER33> "(And yes, I realize that this post is super-critical. How meta)"

Protip: just because you realize the irony of your post doesn't excuse you from being part of the problem as well.

</comment><comment><USER34> Honestly I think this is just the impression one gets because nerds do more of _everything_ online combined with the fact that they tend to know a lot about specific things.

Look, there are absolutely a lot of asshole nerds out there. A lot of guys who went through hell in high school and turned into comic book guy as a defense mechanism and just never grew up (a lot of people from all walks of life never grow up). Okay, but I don't think those people are representative of geek communities. I think by and large criticism is constructive and nerds are supportive of beginners. Maybe we don't sugarcoat things as much as would be to some people's taste, but that's not an asshole quality in and of itself. Rather I think the impression comes from the fact that it's hard to ignore assholes, and there are always going to be a number of them in any large community. People say HN is overly critical, but I think if you look carefully most of critical posts are actually fairly even-handed and not overtly mean; but if you have 20 of them all coming from different angles, and you sprinkle it with a few true asshole remarks, the resulting impression can be quite harsh.

</comment><comment><USER35> I have a german blog who totally pushes this attitude forwards. It's called 1337core.de. A self-irony netculture blog. It is much about hacking, script kiddies, anonymous, fail netpolitics. Kind of stupid but my stupid thing.

But seriously i think this problem comes from the lag, that we don't see the people we are talking about in front of us. It's just a device. No feelings. We hate in this machine and get no direct feedback. We have to learn that the people we are flaming about are living in this world and can propably read it. I have made this mistake a couple of times but i learned and use it alone for joking.

If you want to understand this problem you have to understand psychology, the interface-feedback-problem and group dynamic.

</comment><comment><USER36> This isn't a "nerd" issue. And it is a fallacy to believe nerds should act better because we are nerds and live in a vacuum of only dealing with other nerds. The idea should be that we are the only ones acting this way (and no one else does), or that we are better than everyone else.

The negative behavior is actually TAUGHT, and taught early on. This is how everyone in the western world is taught to debate opinions. Look at any high school debate club, political debates, and any other televised debate. The behavior starts there. As a society, people are not taught to be civil when dealing with disagreements. There is just an inherent "You are completely with me and my friend, or we are enemies".

</comment><comment><USER37> There is a lot of stupid out there. It needs to be called out. On the other hand, things can _appear_ stupid due to internal logic and constraints not obvious to the uninitiated.

It's good to bear that in mind when reading things.

</comment><comment><USER38> Ironically, I actually found his entire post to be a bit on the abrasive side.

</comment><comment><USER39> You can't really compare skate-boarding critics to 'nerds' behind a screen.

For 1, the reason we have so much of this is because of the anonymity of it all. It's quite easy to criticise others in an abusive manner when nobody/barely anybody knows who you are. In real life that wouldn't happen to such a degree.

<comment><USER40> but why this is happening? why people have that trait of behaving like this when they are confident about anonymity? probably it's consequence of problems in teenage-hood, or something. and adding to this topic, i'm also curious about reasons why people are 'trolling', especially when their 'trolling' is offensive, angry. and i have no clue what causes that behavior..

<comment><USER41> Is it anonymity, or is it the venue? As I type this I do not particularly feel like I am talking directly to you, rather leaving a mark for future readers to stumble upon, so to speak, under the context you have set.

I am thinking about what other people would want to read, not how you personally might feel about what I say. I expect that leads to things said that would not be said if I were speaking directly to you, such as in an email, for instance.

I don't know if that fully explains offensive and angry posts, but that could simply be a matter of someone having a bad day and wanting the world to know it.

</comment></comment></comment><comment><USER42> Totally agree. Makes me think of this blog post I read recently where the writer basically generalizes an entire culture of people into a whiny group of people that spend too much of their time complaining about and criticizing other members of that group.

</comment><comment><USER43> "...somebody has sed..."

What an idiot! You should give up on blogging if you don't know the right word is "said"!

</comment><comment><USER44> What do you think about stackoverflow.com?

<comment><USER45> As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion.

Though in all seriousness, I've seen closed questions provide a lot of good information on something in their answers despite people feeling the question wasn't a good fit. In some ways it's like closing a question is a form of what the article is talking about, though I do understand the need for those rules on there.

</comment></comment><comment><USER46> my favorite example of this is asking a question that outs you as a total noob in #C++ on freenode.

</comment><comment><USER47> First of all, I don't think constructive criticism and frank incivility belong in the same bucket. One is a good thing about us. The other is a negative.

However, if we want to restore our tribal integrity, we can't let management play us against each other so easily. There are so many conflicts that look technical but are actually cases where management deliberately played tech people against each other (usually, to create a sense of competition on work hours, dedication, et al). Most engineers lack the social skills to perceive when this is happening.

One thing about business people: they constantly talk each other up. Even if they don't like each other, they say good things about one another. It's game theory. They know the difference between luke-warm and real praise, but everyone else thinks The Manager is in good standing (and therefore stays in line). They get themselves to a state where _not_ saying something positive about someone is a damnation. They can dog-whistle by criticizing a member of their tribe within it, but in a way that outsiders don't recognize, allowing them to keep a unified front.

On our over-honesty, there's one case I know about where an engineer was leapfrog promoted to top management and had a lot of non-engineering reports. They had a performance review system where 5 (out of 9) was nominally average, but everyone came in between 7.5 and 9.0. He gave a lot of 6's and 7's thinking he was giving honest ratings (because no one looked at the perf numbers for IT, reviews he'd written in the past had no effect) but it ended up making a huge mess when HR wanted to put two-thirds of his team on PIPs. He reacted by changing everyone's rating to a 9.0 and giving honest feedback verbally, which is how it should be done.

I feel like we need a similar "understanding" with each other. To other engineers and technologists, we give blunt and honest feedback. But we need to stop the cannibalism. To management and HR, we take a strict attitude of praising other engineers (whether we think they deserve it or not). We should never narc each other out.

<comment><USER12> When you use specific terms like PIPs and perf, we know who you're talking about. I interviewed at Google recently and asked my interviewers about you, Michael, based on the threads you start here that talk about the management vs. engineers culture at Google. Rather than go "oh, Michael, you're so wrong," I gave you a chance and brought it up as a valid concern to each of my five interviewers. The resounding sentiment from every single engineer who interviewed me (two of them with more than 8 years at Google) was how badly you misrepresent and malign Google and how half of engineering wishes they could correct you, but legality and common sense prevents them from doing so. (It goes without saying that it's _really_ interesting that all five knew who you were, since I interviewed on the warm coast and you worked in NY.)

I didn't just get that from people putting on a game face to interview me. I know five current Googlers from all walks of life and corporate structure, including someone who worked near you during your tenure, and they all hate what you do in public. It's an effective technique, really, because you know that you win if they go toe to toe with you.

Given that you're discussing slitting throats for more equity in other parts of this thread, and previously you've compared Google management to the terrorists that brought down the World Trade Center, I implore you to seek help. Please. Way too many people feed in to your reality distortion who haven't been around the block in the valley and Hacker News, and it's disgusting to watch.

<comment><USER47> _When you use specific terms like PIPs and perf, we know who you're talking about._

I wasn't talking about Google. Not for that specific case. That happened at another company, where I didn't work, but I know the story. Lots of companies use PIPs and performance reviews.

 _The resounding sentiment from every single engineer who interviewed me (two of them with more than 8 years at Google) was how badly you misrepresent and malign Google and how half of engineering wishes they could correct you, but legality and common sense prevents them from doing so._

If they want to defend their company's practices, they should. Who knows? Perhaps the company improved massively after I left. Perhaps calibration scores were abolished last year. I'd have no way of knowing and, if that's the case, the public should know.

I'm better known for that than I'd like to be. However, I'd say that my support is about 25/25/50. 50 percent of Googlers see me as Emmanuel Goldstein and would probably never want to talk to me, that's true. I don't like that I have potentially thousands of enemies, but sometimes a person like me has to do the right thing, even at the cost of unpopularity. 25 percent are just completely indifferent. 25 percent view me positively because they want to see Google improve and think it takes someone like me to draw executive attention to problems.

Oddly enough, I'm probably doing more good for Google engineers than anyone realizes, because upper management is now aware of abuses in the middle and, at least, has a chance to correct them. I haven't probed (I don't care) but the company could be fixing itself, thanks to something I started. Of course, the perverse irony is that _if_ Google management fixes their culture, I'll probably still be the villain (as a guy who worked there at the nadir and gave it a negative reputation) rather than the catalyst.

The best thing for my personal reputation is for Google not to improve itself, because then I'm still right. Still, it's better for the world for Google to heed my advice and fix itself in order to make all the things I've said wrong.

 _I know five current Googlers from all walks of life and corporate structure, including someone who worked near you during your tenure, and they all hate what you do in public._

I've said a lot of positive things about Google. They have great engineers. I've also criticized the place. Whoever came up with "calibration scores" needs to stop using his employer as a nursing home and start using an actual nursing home as a nursing home.

If Google's upper management indicates will to resolve its cultural problems (and hell, I'll work with them on this, and at a cut rate) then I will shut up.

I am already willing to admit that my information is a year and a half out of date. So there.

<comment><USER48> I'm sorry, Michael, but it is not true that 25% of Googlers view you positively. The vast majority of Googlers view you as a nutter, especially following your revelation a few days ago that you are thinking about killing people who ostensibly gave you bad references.

You need to get over this delusion that Google is wrong and and you are right, and that eventually Google will somehow come to its senses and beg for your forgiveness and guidance. It is never going to happen. Ever.

I really think that you should seek professional help. You're not just going to wind up an unemployed pariah at the rate you're going; you're going to wind up in a padded cell.

<comment><USER47> _The vast majority of Googlers view you as a nutter, especially following your revelation a few days ago that you are thinking about killing people who ostensibly gave you bad references._

I don't know what you're talking about.

 _You need to get over this delusion that Google is wrong and and you are right_

Not delusion. All I have said is that they're badly run and that most of the corrosion is in the middle-management layer.

 _and that eventually Google will somehow come to its senses and beg for your forgiveness and guidance. It is never going to happen. Ever._

You are almost certainly right on that one, although I find it pretty obvious. People rarely backtrack on mistakes, and organizations are even more prone to foolish consistency.

Also, how in the fuck am I the crazy one? I don't attack a person I've never met just to uphold the reputation of a gigantic company.

It's actually a bit sickening. Yes, I have taken aim at Google's _management_. If you are an engineer, you aren't in this fight and you should stay out, because I never did have any problem with you.

<comment><USER49> " _The vast majority of Googlers view you as a nutter, especially following your revelation a few days ago that you are thinking about killing people who ostensibly gave you bad references._

I don't know what you're talking about."

He's talking about this:

<https://news.ycombinator.com/item?id=5625659>

"Yes, I have taken aim at Google's management. If you are an engineer, you aren't in this fight and you should stay out, because I never did have any problem with you."

I think the reason many Googlers speak up against you is because of basic empathy: we see a group of people being unfairly maligned, and it's not right or ethical to keep secret and let that happen. It's somewhat unfortunate that the response of many of them has been to malign _you_ , but you have to understand that your perception of the company is very different from many other insiders' perception of the company. Yes, it's quite possible you drew a bad manager; they do exist, even at Google. But you paint with an awfully broad brush, making grandiose proclamations about how the company is rotten to the core and run by sociopaths that should be shot, and I and many other Googlers just don't see it.

My manager(s) worked his ass off so that I and his other reports could have an environment where we're free to innovate, free to work on things that interest us, and free to accomplish things. A lot of mid-level managers burn out because of it, eventually getting fed up with having to reconcile so many different constraints and getting zero credit for it. My VPs also seem to usually make good decisions: I disagree with them sometimes (okay, often), but I can usually see the rationale behind them and the market realities that are driving them to those decisions.

Those decisions don't always go my way - I had 3 projects canceled within a span of 6 months in late 2010, and I just had my year-long research project canceled when 2 weeks before I'd been led to believe it was a long-term investment - but when I take a step back and look at the organizational forces, I can usually see how those really were the best decisions for the organization. Sometimes you can have a technically awesome solution that when you try to scale up to a team and bring to the real world, just doesn't work.

<comment><USER47> It sounds like you have a good manager, so we have different experiences.

Let me explain my Google manager. His MO was, about 1-2 months in, to use fake performance problems to get people to disclose health problems, then use knowledge of their health issues to toy with them. I have tons of evidence for a pattern of this with him. I also have (verbally) that HR knows it to be a long-standing problem, but does nothing because if a manager has a reputation for "delivering", that's _carte blanche_ to treat reports however one wishes.

HR's job is to step in and right things when managers fail, and at Google, they refuse to do that. They see their job as to protect _managers_. I know that most companies are this way, but it's disgusting.

There are a lot of abuses of power by management at Google, and HR does _nothing_ about it. The going ideology is that if a manager is "delivering", his word is gold. Combine this with a Kafkaesque nightmare of closed allocation, and you get a lot of ugliness.

I have nothing but respect for the vast majority of the engineers I met at Google. But I cannot respect a management structure that thinks closed allocation is appropriate for a tech company, or that making political-success reviews part of the transfer process is morally acceptable. Google's performance review system is a play-for-play copy of Enron's. This has completely fucked up what should otherwise be an awesome technology company.

I would actually support a class-action suit by Google's shareholders against the managers who instituted closed allocation and calibration scores (breach of fiduciary duty). Those assholes are guilty of destroying several billion dollars worth of value, and justice should be sought against them. Employees who were burned by that horrible system should also be plaintiffs in this suit, because that shit fucks up peoples' careers, too. It's just all-around wrong.

<comment><USER50> _HR's job is to step in and right things when managers fail, and at Google, they refuse to do that._

No, that's a labor union's job. HR's job is to protect the company by mitigating risk from L&I related lawsuits. Period.

Programming can be considered a trade, and I think 99% of the shit you complain about could be solved by programmers unionizing. But of course, that would bring its own new set of problems.

<comment><USER51> michaelochurch has blogged on this matter: [http://michaelochurch.wordpress.com/2012/11/18/programmers-d...](http://michaelochurch.wordpress.com/2012/11/18/programmers- dont-need-a-union-we-need-a-profession/)

<comment><USER50> Sure, a strong professional association might be better than a labor union then. Point is, though, if you're looking to HR to represent your rights and interests, you're barking up the wrong tree.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER52> In my day, the internet was for porn. Now it's for porn AND self-righteous lectures about how many hugs everyone deserves because they're an 'innovator' or 'female' or 'lgbt' or 'autistic.'

<comment><USER12> Welcome to HN. I'd rate that troll 2/10, as it was a pretty obvious troll for a community of smart people. Hopefully nobody here would bite on something so obvious; that might have worked better on Reddit.

(You should go back.)</comment></comment>


PHP for android - <AUTHOR> http://phpforandroid.net/ PHP for Android project (PFA) aims to make PHP development in Android not only possible but also feasible providing tools and documentation. <comment><USER2> I'll start this off disclaiming that I've used PHP for a long time now and I like it. However, I don't understand why PHP should be beaten into a form it was never meant to be in.

I do like the logo though.

<comment><USER3> Using X the way it wasn't meant for is the definition of hacking.

<comment><USER4> Yes, but there has to be a certain elegance to it I can't quite see here.

Hammering screws is not hacking.

</comment></comment></comment><comment><USER5> Disturbing yet wonderful logo...

<comment><USER6> It puts the lotion on its skin or else it gets the hose again.

<comment><USER7> and of course Leatherface from the Texas Chainsaw Massacre who wore the skin masks of his victims to help take on their personality.

</comment></comment></comment><comment><USER8> PHP pinups of elephants on scantily clad women is not a great way to promote this. Really do not want.

<comment><USER9> The pinups have nothing to do with the PHP Android project. I was just explaining where the elephant came from. Vincent happens to also like drawing scantily clad women, but the PHP Android project is just using the elephant.

</comment></comment><comment><USER10> why?

<comment><USER11> Not sure why you were voted down here. I have the same question. And I looked around their website and couldn't find anything.

There isn't even a statement of who or how one would benefit from something like this.

Their homepage badly needs a mission statement, or a "Welcome, PHP for Android is for those who...... something"

That being said, I think I may understand a little as to the "why" by looking at the scripts that are on the site.

It appears that this is for people who just like coding in PHP and would like to use that language when coding for Android..... I think. It's about the language.

I am probably going to test it out. I'm wondering if the apps written using this exist entirely inside an embedded browser. That might be interesting.

<comment><USER12> When someone asks "why?" to something, I almost always think "Why not?" Is there a good reason you shouldn't play with Ruby, Scala or Python on Android? If so, why not PHP?

<comment><USER13> Because php isn't a general purpose language. It's a rather clunky hammer outside of the web.

<comment><USER12> Your answer sounds a lot like "Because $language is better" and there are no winners of holy wars.

<comment><USER4> Wake me up when you finish writing a payroll system in awk...

<comment><USER12> Wake me up when you finish writing one in any language.

<comment><USER4> There is a non-trivial chance I had already written one before you were born.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Yikes...property values are going down. PHP has moved in.</comment>


Don't be so sure you know what a lowercase G looks like (2018) - <AUTHOR> https://www.theverge.com/2018/4/3/17192518/lowercase-g-letters-reading-writing-comprehension-penmanship <comment><USER2> Did many people ever write looptail g to begin with? (EDIT: in recent times) They try to make the connection to people handwriting less, but I've only ever seen the looptail g in fonts (such as in the HN comment input box) to begin with.

I really don't think it's surprising at all that people can't actively reproduce an archaic version of a letter that is as far as I know not really taught anywhere.

<comment><USER3> To my knowledge the looptail basically only exists in print, so why anyone ought to be able to write it is a mystery to me.

</comment></comment><comment><USER4> Neat. It reminds me of the study that asked people to draw bicycles:

[https://road.cc/content/blog/90885-science-cycology-can- you-...](https://road.cc/content/blog/90885-science-cycology-can-you-draw- bicycle)

</comment><comment><USER5> Hm, odd, I'd have expected it to be drawn roughly analogously to the cursive g but the bottom loop is connected to the other side of the top loop with respect to a cursive g. I wonder what the origin of that discrepancy is.</comment>


Great developers are raised, not hired - <AUTHOR> https://sizovs.net/2019/04/10/the-best-developers-are-raised-not-hired/ <comment><USER2> I officially mentored someone at my previous company and helped him move from a support tech role into a software dev position. It was incredibly rewarding.

But to play devil's advocate for a moment, isn't there something of a natural disincentive to level up one's employees in such a tight labor market? To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted. One might argue that if _everyone_ put more fish in the pond, then we'd all be better off (true), but we have a standard collective action problem where the free riders benefit at the expense of the fish growers.

I see two (partial) ways out of this trap.

1\. Pay more than everyone around you. (Obviously, not generally viable.)

2\. Make the culture of your company so awesome that people will want to stay, even if you can't pay the most. Make mentoring/growth a central strategy _at every level_ so people will see a path to grow.

I'd be curious to hear other possibilities.

<comment><USER3> >To follow the author's analogy, by mentoring someone, we're effectively "adding a fish" to the pond, and if someone else "catches" the fish, that effort is largely wasted.

Even more curious is that IT culture is basically that if you want to get paid what you're worth, you have to quit and go to another company.

So these companies put all this effort into raising a better developer, and then refuse to pay them what they're now worth and basically force them to go elsewhere.

It's not "what if they go elsewhere" under that situation, it's "when".

I'd argue that you don't even have to "pay more than everyone around you". Simply coming close to parity is enough to stop most people from going through the pain of a job search. But these companies don't even get that close.

The last time I switched jobs, I got a 40% pay increase. That's ridiculous. I even told the company I was underpaid and they asked if I could wait a year for a raise. I didn't even answer the question. I just walked away and started looking for a job.

They weren't surprised when I found one and quit.

And a couple weeks before I left, they put in a job ad for _7_ developers, offering what I was making at my new job for each of them. I've been at this new job as a senior developer for 8 years now.

Could I make more? Almost certainly. But they gave me decent raises and have a good culture (almost zero overtime in 8 years) and benefits, and I don't feel like leaving.

<comment><USER4> Currently switching jobs for a personal record 57% increase in total compensation.

And I was NOT poorly compensated before. I was already in the 99th percentile for individual income.

The harder I push on comp the more I get each time.

I am not going to lie and say that it didn't take years to build to this point in terms of skill, work record, professional network, and interview ability. It took three FAANG companies bidding against each other.

Meanwhile I get offered nothing in terms of growth from every employer I have ever worked for ever. Literally never happened my entire career. Just this time after I already had an undisclosed offer in hand I got a promotion with no meaningful compensation increase. It was the first promotion of my 15 year career!

Sure they were willing to match, but who wants to try and soak blood from a stone.

<comment><USER5> Off topic - but your username and the vast majority of your commenting history is primarily on salaries. Curious - is there some backstory to it? Feel you got severely underpaid?

To each and his own, but bay area engineers pissing about making ONLY 300K has always come off as being a bunch of spoilt brats - especially considering the vast majority just gem/npm/pip install this and that and glue all the code together. Of course the market deserves to pay accordingly but I think it's just a big bubble that's going to crash soon - since there is a huge mismatch between demand and supply of CRUD glue programmers (which most programmers are).

My guess is that once Lambda School, Make School, ISAs all become mainstream and the pool of CRUD glue programmers matches the demand all salaries will come crashing down. I think overall it's a good thing for society in general (and especially the tech towns).

ps: Pardon my tone. I work in the space industry. Maybe I have an axe to grind ;)

<comment><USER4> This is an alt specifically for discussing compensation because I know it elicits that reaction and I don't want that associated with my professional identity.

I think discussing compensation frankly and openly is very important. People have no idea what is possible. Two people on the same team at the same company can have wildly different compensation. My goal with this alt is to get people to take the biggest slice of the pie they can for themselves and avoid wasting their precious time doing lousy work for lousy money.

I have wasted a lot of time and life opportunities working for less then what I am capable of getting. I wish my future self had been around to tell me to push harder and be more mindful and efficient with my time.

I don't think CRUD glue programmers are at the top of the market right now. You could flood the market with them and it might not move compensation for people in my space. Even so, that is just another argument for pushing hard right now. Strike while the iron is hot. No one knows how long this will last.

<comment><USER6> Any advice on learning your true worth? Assume for a minute that Glassdoor is useless, as the "salary range" it displays shows that the maximum is 2-2.5x the minimum.

<comment><USER7> There is no "true worth" that you can look up on a website. Your salary is your cost in the labor market. And like any market, worth is determined by what people are willing to pay. Go out and interview, get some offer sand see who is willing to compete for you. That's how you get your true worth.

<comment><USER8> Right, the entire point of the question is to find out what people are willing to pay.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> > Your mentees will support you and promote you for the rest of your life.

The problem I've seen is that this is rarely true. We've had a big set of grads we've trained that quit for a 20% pay rise, or a project that they happen to like better. Many regretted it but it didnt stop the next guys from doing the same. I'm really burnt out over teaching green newbies again and again.

<comment><USER10> Why don't you match their pay rise?

Or give them projects they're more keen to work on?

<comment><USER11> Usually, the teaching/mentoring is not free either.

So you can a) hire someone who needs training and then train them, or you can b) hire someone who is productive since day 1.

The people in a) cannot expect the same salary as b). Otherwise, there would be no point in incurring the costs of training them.

Unfortunately, once you train them, someone can snatch them as people in b). You incur the loss, someone else benefits.

<comment><USER12> This is simple - pay people by the value they bring to the company upon every annual compensation review.

Yes, it costs money to train people. Consequently they get paid less during that period. But once they can fly on their own, treat them as if you hired them like that.

<comment><USER11> > Consequently they get paid less during that period. But once they can fly on > their own, treat them as if you hired them like that.

That's too early. You made an investment, that investment has to break even. With your suggestion, it would never break even.

<comment><USER12> With all due respect, if hiring an entry level dev is a _loss_ for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level.

You pay them market when they need to be trained, you pay them market when they move up the skill food chain.

<comment><USER13> And as such, junior developers don't get hired, because the first 2-3 months of their career, a junior developer is at negative productivity, considering the work the team is doing to start getting them up to speed.

Some of HN works in areas that are harder than the bog-standard CRUD app. So, do you give up on hiring junior developers at all? I believe our whole industry suffers if we come to that conclusion.

<comment><USER12> This whole CRUD app crap is a cop-out - please don't insinuate it's my lack of experience that has me making this assertion. I've been an engineer for 23 years and spent the first 16 years largely working on large enterprise systems in C/C++, then C#, primarily in the health care space often with some hardware component. Regardless, the work I've done over the past 7 years with modern web tooling is some of the most difficult I've done in my career.

It's a failure of the organization to not utilize entry levels from the first week. At any company. After all, the FAANGs of the world have a different bar of entry.

People keep talking about this like you're literally training people how to program. That's BS. Every org has refactor work, tests to write, processes to improve, tasks to research, low hanging fruit bugs to tackle, systems to blueprint, all sorts of stuff that's a strain on the more sr. staff that's been pushed aside but needs to be addressed. You can strategically bring entry levels up in a way that's a net gain in any environment.

<comment><USER13> The truth, however, is that a senior developer is $140,000 and a junior developer is $80,000, and that same junior developer will be $100,000 in two years. (This is assuming salaries in one market.) That junior developer will take 3-4x the time to handle the same task as a senior engineer, and will take some of the senior engineer's time to guide the solution, provide feedback, and mentor.

That doesn't mean that we shouldn't hire junior developers - in fact, it's our duty as an industry to hire and mentor. However, it is with open eyes knowing that junior developers are not cost efficient in many areas for the first year.

But we go back to the original statement: "With all due respect, if hiring an entry level dev is a loss for your business then perhaps don't hire them? A dev should be a net gain regardless of skill level."

If you have $320,000, and can have 3 junior developers or two senior developers with the same budget, the 3 junior developers will be a net loss for the first year. They can be productive, but you have to compare on budget.

___

But I find that as a bizarre set of work that you call out.

* Refactor work is often the largest need from senior developers. Learning how to refactor safely is a separate skill that is not a skill junior developers have without instruction and feedback.

* My senior developers write tests as they develop. If there is test debt, it means sitting down with a copy of Michael Feathers and that is definitely not an introductory text. Trying to write tests for code that wasn't written with unit tests in mind requires a set of skills that many senior developers don't have, much less junior developers.

* I'm curious what processes you see that junior developers can improve.

* Researching tasks can be something useful, but what are these tasks that aren't done while a senior developer needs a break?

* Low hanging fruit bugs are likely the most obvious thing for junior developers, but a highly cohesive team that is writing tests has fewer bugs that are low hanging fruit.

* What systems can a junior developer blueprint? A senior developer understands patterns and quickly solves the problem.

<comment><USER12> Pretty much all the things you call out as bizarre I've seen some better interns slice right though.

* Refactor - Sitting down with a jr. dev for 15-30 minutes at a time going over the scope for something that is about a day or two of work. Done this many times. We're not talking high-level architecture work, just tech debt the team has let slip away.

* Great. I've never been in a situation where there wasn't lack of coverage though. Focus on things that are somewhat repeatable in nature. The point is doing tests is a great way to learn how the system operates, and basic unit tests cornering edge cases are easily repeatable patterns. Validate w/ PRs, you don't need to hand hold the entire way. No books needed, tons of other tests in your suite serve as guidance.

* Build/deploy system issues. 3rd party integrations. Better approaches to update dependencies. A better approach to documenting an API, automating code documentation, etc. Some particular lack that isn't crucial to operations but is fine letting a cheaper resource tackle as a research task.

* Can blueprint anything that lacks proper documentation. If they can do research for their CS degree they can research and document your system. Yes, you will be giving them little tidbits along the way on how to properly debug or set things up.

AFA 2 seniors vs. 3 juniors, totally dependent on your team structure and the work that needs to be done. If you run as tight a ship as you imply the sr. devs will be a better bet every time from a value basis - but that's rarely the real world. I wouldn't add more than 1 junior at a time to a team of < 6 devs.

Lastly, addressing "that junior developer will take 3-4x the time to handle the same task as a senior engineer". Well duh, don't give juniors the same work as your seniors. The whole point of hiring lower level staff is you have work that is better suited for lower level staff, or rather, work that is too costly to give your sr. staff. This whole it's our duty to train the next generation... you're running a business, not a charity. And then you get caught up in this cancerous notion of people being in debt to you because you don't know how to properly utilize them.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> The distinction here is between a hunter-gatherer mentality and an agricultural one.

Are you picking and choosing or are you farming?

Currently we _grow_ engineering skill in (often) high cost institutions with limited capacity such as traditional universities. Moocs and bootcamps are alternatives which try to address the scalability, cost, and time commitment barriers of traditional education.

The question is should there continue to be a strong dichotomy between organizations who consume the output of these growth channels and the growth organizations, or should software development companies create programs of structured education and growth that have a low barrier to entry?

As others have mentioned startups who can hunt/find/pick people with relevant, high quality skills have the advantage of not paying the time and organizational cost of training.

Personally I think that large organizations should be taking more hands-on approaches that take all, or nearly all comers, and then provide training for the kinds of skills they need.

If you look at military funding for medical educations (for example) you'll see that the organization can be very generous in terms of time and training cost as long as a candidate ends up with the skillset they need. You might not go in wanting to be a urologist, but you can end up highly skilled and very well paid if you're willing to meet the needs of the organization.

</comment><comment><USER15> I have, to some degree, given up trying to hire senior developers. Instead, I'm doubling down on the internal training programme (and have hired extra juniors).

5% of time is set aside for training. Works out a little over a half-day every fortnight - every fortnight, after lunch on Friday, drop the code and hit the books, pet projects, videos, experiments, whatever clearly makes you a better software engineer. If you _don 't_ spend that time on your own training, questions are asked. Nobody has been fired for not training yet, but if we get someone who simply refuses to, I could see it going that way; when we hire someone, we're not just hiring that person today - we're hiring that person next year, and we're banking on that person next year being better at this.

There is CapEx for books. We have PluralSight licences. New starters' agreed objectives include reading and thence using "Effective C++"; I _will_ come by your desk every so often to chat about parts of it. We have short presentations every fortnight (the time of which doesn't even come out of the 5% training time) on technical topics. Once you've covered the basics, the company starts contributing towards conference attending.

The last senior dev who got internally promoted currently has an allowance of 50% of his time for helping more junior devs understand things. Fifty percent! The intention is to get his senior dev knowledge and experience out of his head and into the heads of five other people; growing ourselves five more senior devs.

I got all this by asking for it. Grow your own. Everyone wins. The company wins, the employees win. Just had to ask; if you ask, and your company isn't interested in improving, isn't interested in producing better products, faster and cheaper... well, is that really the company for you? :)

<comment><USER16> Maybe I'm just a grump, but: 5% is pretty low number for training people up. Perhaps that's just the "hit the books on your own, but during work time" portion? If it includes other things (talking people though a project that's on the edge of their capabilities, discussing the architecture of important project from an educational perspective, ...) then it seems pretty low.

EDIT: non-phone spelling

<comment><USER17> 5% is pretty low to basically nothing. I agree.

<comment><USER15> It's very low and, from my own experience, significantly higher than average.

My experiences are almost entirely UK based, outside big name or hip companies.

<comment><USER17> True. Usually training is 0%.

</comment></comment></comment></comment></comment><comment><USER18> We're in a labor market in which CS students are focused on drilling for the FAANG-style whiteboard tests. And many will tell you their strategy is to go to Google for 2 years of experience and resume-building, and then leaving rather than grind away and play the promotion game there. And everyone has known for 20 years that you have to job-hop to grow your salary in this industry. And most employees would be naive to think that their employer would take care of them long-term.

In this mercenary environment, loyalty doesn't go very far, so, for retention after mentoring, I assume one would have to pair mentoring/training with substantial growth in compensation. Besides all the non-monetary attractions.

<comment><USER19> My last company would insist that they couldn't give promotions or significant raises. Until you came in with an outside offer, then they'd roll out the red carpet and bend over backwards to keep you.

It breeds distrust, discontent, and disloyalty.

The best people don't like this and leave. They company is left with people who can't land outside offers. And the company ends up needing to pay market rate anyway to replace the good people who left.

Idiotic.

<comment><USER20> This works for the company because most people don't bother interviewing and coming up with a counter offer. In my previous company the best of the best would leave because company had this blanket policy that they would never do a counter offer. But in overall it was good for the company because they were able to retain most of engineers with raises as little as 1% and no stock refreshers.

<comment><USER19> I actually prefer that policy. At least they stuck to their guns.

We had an inexperienced junior dev come in with an "amazing offer." This signaled to management that he must be amazing, so they offered a promotion to team lead to keep him. Half the team quit within a month, then he proceeded to run everything into the ground.

There was a certain amount of shadenfreude watching that play out.

</comment></comment></comment></comment><comment><USER21> I love the point the author raised in this article. Companies are spending a ton of money on recruiting and paying commissions to recruiters. If some of that money and effort is channelized toward mentoring, a company can notice a significant change in quality in its workforce. That said, this article fails to address 2 major issues or provide any solutions for that:

1) Every decent size company spends for providing resources like books, learning portals etc. for their employee to grow their skills. There is an entire industry running which caters to provide companies learning tools, for example - safari online books etc. Mentoring is also used a buzzword in these companies. There is a difference between providing tools & books vs creating an environment where people can grow. Mentoring is very inter-personal. Unless companies create incentives for senior engineers to help mentor other engineers there won't be any real change to the way things are now.

2) If your teams or Orgs are always battling to meet the next deadline, how will mentorship happen? You can't expect people to put more than 40 hours of work and expect them to personally mentor other engineers(They still do btw).

</comment><comment><USER22> This article assumes that the person you are mentoring is open to being mentored. I've worked with some engineers who were definitely junior despite having years of experience and very opposed to even a slight suggestion on how to improve their thinking process or implementation process.

<comment><USER23> On the other side of spectrum there are those people who "really want to learn real programming" but you have to do all the work for them. You point them at the resources, contribute ideas and it turns out person is not following through even though when they talk they are enthusiastic.

So basically you have to somehow spot right person to spend time with, and it is hard. At least guys that don't want to be mentored are not time sinks.

<comment><USER22> This too, I've also worked with people like this, it is extremely frustrating to teach someone who wants to be mentored not take your mentorship advice and continue to make the same mistakes.

The counter argument here can be that I possibly may not have mentored the person in the right way using the right motivation, but methods I tried were (ranked in succession):

1.) Showing by example but asking to come up with own examples 2.) Templating examples 3.) Listing out steps 4.) Finally just directly asking to do x, y, and z

Utilizing data patience time boxing.

This is definitely a difficult problem I don't particularly have an efficient solution to, my best answer is just find someone to mentor who will execute

</comment></comment></comment><comment><USER24> This sounds like a wonderful idea in a business culture _not_ obsessed with burning tomorrow to a crisp for more return today. Not to mention this requires trust and loyalty, both rendered cruel jokes by the all-against-all knife fight that our (in the US) labor market is.

</comment><comment><USER25> At what size of company does this pay off? My experience of hiring juniors is generally that they are net negatives to productivity for quite a while, and the smaller the company, the more significant the impact of that is. How do people here go about mitigating that?

<comment><USER26> Don't have proven techniques, but have been toying with an idea I'd like to try the next time I have the chance.

Have been thinking of starting a "farm team" to develop green programmers. Have a meetup once or twice a week, work on a focused project together, do mutual code review. Read the classics (e.g. the MMM) as homework.

Perhaps give out some Amazon gift cards for good work. When a participant levels up, move them to a paid role.

<comment><USER27> What is the MMM?

<comment><USER28> _The Mythical Man-Month_ , by Fred Brooks

[https://en.m.wikipedia.org/wiki/The_Mythical_Man- Month](https://en.m.wikipedia.org/wiki/The_Mythical_Man-Month)

</comment></comment></comment></comment><comment><USER29> This seems to strike a chicken and egg problem. Who will grow the talent? It seems you'll need to hire the mentors for that. And what's the level of growth possible? Isn't that capped by the level of your senior devs?

As far as I know, most interview processes are designed to hire potential. For example, if you can't learn fundamental algorithms in a reasonable amount of prep time to prepare for the interview, but someone else could... Which talent has the most likely potential?

I'd even go and claim that the current interview processes are biased against senior talent. Someone who already knows they are qualified won't be motivated to go and practice fundamental algos that they haven't needed for real work in years. They'll expect their own track record and knowledge to be recognized on it's own. But, the interviews won't care about that. And they might instead hire a junior with more time and motivation on their hand, which decided to spend all evenings for the last two months doing leet code questions.

Similarly, many companies seem to favor new grads, which they can quickly brain wash into their existing engineering culture. They think, these new grads really strive, instead of challenging the status quo, they internalize our processes and work hard to deliver, even if we're being unreasonable. Eventually, this creates a lack of perspective in the entire company. Hiring more external senior talent would help get more perspectives, and prevent this silo of opinion that hurts innovation over time.

<comment><USER30> > And what's the level of growth possible? Isn't that capped by the level of > your senior devs?

Senior devs who are good at mentoring also ought to be good at learning new stuff. They'll also be learning some things from the mentees, at least some of them will know stuff they don't know because our field is so vast.

Once the mentees catch up? If you've inculcated a learning culture, these new senior devs will be learning new things right along with the old ones.

</comment></comment><comment><USER31> I have never seen a single company/startup place a job posting for a junior position, (lucky if they even say training)

Last time I checked, everyone wants to look for a senior developer with 5+ years of experience. It's some sort of hidden bonus if you're from a FAANG company as well.

I'm guessing everyone wants to be the next Google, Facebook, Amazon, Netflix or Uber.

<comment><USER32> so they do want junior developers. They're just giving them the "senior" title ridiculously early in their careers.

What no one REALLY wants are ENTRY LEVEL developers, who tend to be a net negative to productivity for roughly the first year or two.

<comment><USER33> Every new grad, intern I've worked with has done an amazing job hitting the ground running. They're not ready for "here's a big problem, please dream up a solution and get it out the door", but with reasonably laid out tasks they do a fantastic job working out the code and improving their technical chops along the way.

Juniors who are eager to learn are my favorite employees

<comment><USER34> >Every new grad, intern I've worked with has done an amazing job hitting the ground running.

You've been incredibly lucky. It's great when it happens, but it's certainly not the norm (speaking from experience at a well-known organization that hires a _lot_ of interns).

</comment></comment></comment></comment><comment><USER35> The article is not only on point but it reflects a big problem in the tech companies.

Businesses loose millions and they just burn cash because of toxic and arrogant developments teams.

I can quadruple the sales of the company that I work for but you cannot push any change through the arrogant development team who don't give a chance to other people, it is so pathetic.

<comment><USER36> The problem in tech companies is arrogant and clueless management that treats developers like dirt and blames them for everything.

<comment><USER37> Trust me, there are arrogant developers out there and they suck to work with. They treat code and design reviews as chest beating exercises. They refuse to work on anything remotely legacy. If their idea or design gets questioned in _any_ way they get loud and obnoxious. You can't mentor these devs at all.

<comment><USER38> >They refuse to work on anything remotely legacy.

You have to be careful what you're good at. If senior devs/management sees you're good at legacy, they might task you with that as a majority of your time. Then your career plans get sidetracked because you won't have as much time working on the stuff that you want to work on.

Some developers are okay with legacy, but if they aren't, it's not surprising. Some legacy stuff is absolutely horrible to work with - it devolves into "get- in-get-out" fix mentality (and security issues usually get swept under the rug). Some legacy products are good though and require minimal tribal knowledge to actually work on.

This has happened to me twice at two separate positions: bait-and-switches about what I'll be working on because more senior members wanted to offload the legacy work themselves.

The general arrogance is really a separate trait from willingness to work on legacy IMHO and I agree on those points.

</comment></comment></comment></comment><comment><USER39> The best developer thing is really frustrating and ultimately a failure. Companies always claim to want the best during hiring, but once hired that completely goes away. What they really want are a couple good developers and rest somewhere between mediocre to brand new.

To really see the paradox ask extremely controversial questions during the interview. As a frontend developer ask about process efficiency or interacting with the DOM without a bunch of framework bullshit.

</comment><comment><USER40> So many developers here downright scared to mentor others. The problem with the current job market on full display.

<comment><USER30> We have to live in the world as it is, rather than what we'd like it to be. The well reported in this discussion patterns of your boss trying to replace you with your mentee, getting dinged for not getting "real work" done, and mentees not staying in the company for very long should give anyone pause.

<comment><USER40> That seems like a good way to keep the world the way it is, and not how we'd like it to be.

Thankfully, not everyone thinks as you do.

</comment></comment></comment><comment><USER41> Ok, so the guy is in the training and conference business. That would seem to skew his perspective.

Usually the people who talk loudest about mentoring are clueless or are in the teaching business.

In the real world, there is zero reward for mentoring. Moreover, if you do it, you might get fired and be replaced by the now cheaper mentee.

<comment><AUTHOR> How can you mentor people if you are afraid of being fired or replaced by a "cheaper" mentee? To mentor people, you have to be a professional developer, at the first place.

Professional developers achieve job security by doing great work and making themselves replaceable. Mediocre developers – by building knowledge silos.

<comment><USER30> > Professional developers achieve job security by doing great work and making > themselves replaceable.

Wouldn't that be "achieve _career_ security"? Because as I attest upstream in this subthread, in my most notable example of being a mentor, I was indeed fired as soon as my non-technical salesman background CEO decided I was replaceable. Although he didn't realize that wasn't quite yet true, and the mentee decided to leave instead of working in such a place.

I don't know about Estonia, but in the US conventional careers as a software developer start ending when you're in your 30s, with 40 being a hard limit in finding a new conventional job because that's when our national age discrimination law kicks in.

That fresh out of college except for one short job mentee? The only reason he's still a programmer a quarter century later is that within a decade he got a high level security clearance, which is sufficiently onerous for the company that pushes through that process, they have to "bench" or otherwise have the employee work on non-classified stuff for many months, that after getting it you're in a small pool that companies vastly prefer to recruit from.

This is intimately connected to being a good mentor since a fair amount of experience is required to do a good job of it.

<comment><USER42> > I don't know about Estonia, but in the US conventional careers as a software > developer start ending when you're in your 30s, with 40 being a hard limit > in finding a new conventional job because that's when our national age > discrimination law kicks in.

In the US, I found a new developer job at 43, and another at 47. Haven't looked in a decade, so I don't know how it goes at 57.

Caveat: I'm in embedded systems, which is a much more senior-friendly world than web apps.

<comment><USER30> As you say, you're in embedded systems, that's well known to be the other US employment domain that's friendly to developers with grey hairs. Not a "conventional" field.

<comment><USER43> I'm a bog standard "Enterprise Development". I found jobs within less than a month at 34,38,42 and 44.

</comment></comment></comment></comment></comment></comment><comment><USER44> I have found the premise of the title to be completely false in real life. Not much else to say to this - I haven't seen too many people grow, and when we hire someone great, they are great.

<comment><USER37> > I haven't seen too many people grow...

Are they allowed to? Are they mentored? It's not just one sided.

<comment><USER45> In my experience, as a mentor:

Quite a lot of people are certainly capable of growing, but many (most?) aren't. Either they aren't capable, or they don't feel like it.

Luckily you can almost always tell from the get-go who will grow and who will stagnate.

<comment><USER46> Are they given time during normal work hours to grow? Are they given adequate assistance and resources? Is training a priority?

I've run into two different situations in my work life: a) You should learn new tech and keep up, but it's all on you, your own time and discretion (outside of work). It was expected to do project work 100% of the time on the job. b) It's expected for you to learn and grow and we will help you get there. $ for training/conferences. It's expected that you will spend a decent amount of time out of your 40 hr work week improving yourself and learning new tech.

In situation A, I would have been (I was!) labelled as someone who lacked the will. It was hard to put in a full day and do more at home, learning new stuff. I still did it, but it was difficult. I was burnt out by the time I left that job.

In situation B, I feel like I can live a normal life. I can learn, do my projects (I'm more productive), and go home at night and enjoy my time off and weekends. I feel like a normal person living their life.

Work/life balance is highly underrated.

<comment><USER45> >Are they given time during normal work hours to grow?

Yes! Absolutely!

>Are they given adequate assistance and resources?

Yes! 100%!

>Is training a priority?

Its our #1 priority (for new devs).

Still got people refusing to grow. Ive been a very successful mentor to some people, but I've gotten some real duds too.

I agree with the sibling comment that says 4 weeks is the sweet spot.

>You should learn new tech and keep up, but it's all on you, your own time and discretion (outside of work).

That's ridiculous. I've never worked anywhere where you are expected to work outside of work and, frankly, I just wouldn't.

</comment></comment></comment></comment></comment><comment><USER47> Yes! This is something that is not just about developers and seems to be a huge gap in hiring.

Go look at any big company job listings. There are many positions that have no "entry level" roles. The lowest level of experience will say "5 years of {x}".

If you're a company that does not take people without experience, where do you think they're getting the experience? You're relying on other companies to train your employees, and naturally you're not getting a chance to create the exact employee you need.

Hire people that are intelligent, humble, and willing to learn. Ignore credentials, and promote from within. In most situations, you'll get the right result.

Aside: The weirdest part is there are some positions that seem to not have entry-level jobs anywhere in the industry, you have to sneak into them. For example my girlfriend is a "Brand Strategist" at a web design agency. This is what she always wanted to be, but when she was applying it seemed that every Brand Strategist job required 2-3 years of Brand Strategy experience. So she applied to her company in a role she didn't really want and then basically talked her way into the new role. Obviously she's doing well and she will never face this barrier again. But that was a stroke of good fortune.

<comment><USER48> this is exactly what global investment banks do ... they hire a fresh crop of a few dozen smart motivated young perspective programmers and put them through 9 months of intensive work study multitasking classroom lessons in software problem solving together with IT operations experience where everyone gets a very broad exposure to the technological landscape ... these banks repeat this every 3 months with yet another new crop so there are three such sets of new recruits on an ongoing basis ... after the 9 months these ~graduates~ are assigned into programming roles and just boot themselves into their new positions ... key here is they start with razor sharp people from any field ( philosophy, science, humanities ) who have exhibited problem solving potential ... also key is the business can afford to offer this in-house training while the new hires are getting paid ... baked into this equation is the nurturing of loyalty and admiration toward their employer - deservedly so I might add

</comment></comment><comment><USER49> I don't think a general discussion on this topic can really be had.

In my experience of working for shitty enterprise software, good and bad consulting firms (and seeing how their non-tech clients work), and silicon valley startups. The company financials, work culture, job market are all vastly different, impacting all the trade-offs of different hiring method.

i.e. some firms simply cannot afford top-of-the-market pay for senior engineers they want to hire, so they hire more junior ones and train them, who eventually leave after they're trained, but people don't immediately jump to next ship paying a little more, so you end up getting good work out of them for a period of time while underpaying them.

Some companies compete on non-momentary means.

Some pay top of the market rate, but only hire seniors.

Some pay top of the market rate, and hire from all levels; some of the juniors rise up through promotions, and some didn't get recognition despite growing, so they leave for other companies.

Some companies simply don't care about engineering quality, or does not have the ability/DNA to differentiate between good and bad work.

Also in silicon valley, networking and mentoring good engineers is much more professionally rewarding than in smaller markets.

</comment><comment><USER50> I guess the cynic in me would ask what the point is in polishing a rough gem in your organization into a diamond, if you're thus turning them into a target for other people to poach.

<comment><USER51> You get the first dibs, don't you? If you need a diamond level dev, you must provide diamond level compensation. The article just points out that it is simpler to get that level from other sources than filtering what is on the market.

<comment><USER52> > If you need a diamond level dev, you must provide diamond level > compensation.

It is baffling when companies resist against giving great developers a good raise.

If they leave, the lost productivity and onboarding will cost them more. Sometimes, they end up having to hire 2 people to replace that 1 person.

<comment><USER53> Companies want talent for cheap. Every time I see in the news companies complaining that they can't find employees, I think to myself, why don't you pay more?

Add to that, if you start at a company and become a rockstar developer, admin, or QA guy chances are they will not value you as much as if you came in as the rockstar developer, admin, or QA guy.

</comment></comment></comment></comment><comment><USER54> That's roughly what they do at my company. Many people in the company have some form of Computer Science certificate/degree, so shouldn't be that hard to make them develop...but you hit the Peter Principle much faster in this line of work. The CTO loves the hanging on by the seat of your pants optics. "Look at him go. He doesn't have any idea what he's doing, but he's getting it done. That's what we want." The rock stars puff up and grouse about the recent QA to senior DEV promotion, then ridicule them, then you find out the rock star has been working until past one every morning since part of their responsibility as a lead is to make sure the QA-cum-Senior Engineer's work is code complete. Then they leave. And yes, then a great developer is hired...but they never tell us where they're going...

</comment><comment><USER55> I agree with the headline and not much else.

Okay. I'm fine with agreeing with the notion that good, productive engineers can result from good environments.

But that doesn't mean hiring 'broken toys' is a good idea. This article's message is 'Can't find anyone good? That's okay! Hire someone anyway and mentor them!'

Turn this stone into a diamond!' Okay. Some stones don't turn into diamonds. Gee...if only there was some sort of process that can help determine which people are capable of being a good engineer. Maybe companies can do something like asking some basic questions about a candidate's ability. Something like a filtering process.

'The pond is empty.' Pfff. No it's not. If no one's biting at the rod, it's because of shitty bait.

</comment><comment><USER56> I recently asked a question where this answer would fit - [https://news.ycombinator.com/item?id=19627404](https://news.ycombinator.com/item?id=19627404)

We have tried this with 3 different candidates: 1\. No experience last year in university 2\. No experience with BS 3\. 1 year working experience

My experience with this approach is that it is a far more expensive investment that takes long time to pay off. The safe ratio that I can recommend is 5 seniors to 1 junior

</comment><comment><USER26> This discussion reminds me of the fixed vs. growth mindset, in the book Mindsets:

"In a fixed mindset, people believe their basic qualities, like their intelligence or talent, are simply fixed traits. They spend their time documenting their intelligence or talent instead of developing them. They also believe that talent alone creates success—without effort. They're wrong.

In a growth mindset, people believe that their most basic abilities can be developed through dedication and hard work—brains and talent are just the starting point. This view creates a love of learning and a resilience that is essential for great accomplishment. Virtually all great people have had these qualities."

[https://mindsetonline.com/whatisit/about/index.html](https://mindsetonline.com/whatisit/about/index.html)

<comment><USER57> I started in IT. I very quickly realized I could do a lot of tasks the other support staff weren't willing/able to do, like learning regex and database normalization. Kept getting more dev related tasks since my boss was the only software engineer at the small startup.

Rather than get rewarded or hired as a developer by the company, as the support team grew I was headed toward being promoted to the support manager. They brought on someone else as a dev and that really made me realize I'd never be a dev in the CEO's eyes. Bosses daughter did an internship so she got the coding tasks I would have gotten before. I was taking more phone calls with idiots from places like The Federal Reserve who didn't know how to Google "hoe to format a hard drive". So I left and doubled my pay.

Some managers just believe what you know is set in stone and you can't progress or learn anything new. It's a really bizarre mindset to have when a devs most important skill needs to be the ability to learn. Didn't all these same people go to school?

<comment><USER30> > Bosses daughter did an internship so she got the coding tasks I would have > gotten before.

In my experience at a couple of places, the moment you learn its a nepotistic environment you should leave as soon as you reasonably manage. As you saw, it's a sign of very bad management, the sort that can easily kill a company, see Wang Laboratories for perhaps the most famous example in the US.

</comment></comment></comment><comment><USER58> Great developers can be hired. For example, you raise the developer, I double his salary and hire him away from you. Not saying that I advocate this practice, but this is what happens in SV.

</comment><comment><USER59> I can agree with hiring novices and then giving them what they need to learn. We hired two women from Fullstack Academy (NYC) and they turned out to be amazing. They were novices, but incredibly motivated and talented. Both of them had had other interesting careers, and for both of them they were changing careers to get into computer programming.

Now we are expanding the team so we are hiring another of their classmates, who they have strongly recommended to me.

</comment><comment><USER60> from my experience the only way you get better salary is to jump around, not too often, but if you stay with one company for two long(say, 5+ years), you become the lowest paid at your level in general.

only if you're on the management ladder you want to stay longer, for tech and engineering roles, the old employer does not really appreciate that much after you're loyal for too long as far as compensation goes, very ironic but it's the way it is.

</comment><comment> rooam-dev No, great developers are the result of ones hard work, long nights, dedication and passion, hence hiring part.

Mentoring is Uni's job, since you pay them money.

</comment><comment><USER61> A "self-confident rockstar" is just a developer who has been through this process of self-development and no longer requires the mentoring and extra effort to get them there.

I appreciate that some companies value experienced developers and aren't trying to nickel and dime by finding "broken toys" so to speak that they can force into their own moulds on the cheap

<comment><USER62> What do you mean by "broken toys"?

<comment><USER63> "broken toys" is referenced in the article.

</comment></comment></comment><comment><USER64> I would be really-really happy if the IT industry would just forgot about the phrase, rock star. I just cannot read anything after I see that word.

</comment><comment><USER65> Mentoring is the way to go, although the 18 month average stay in a job in silicon valley increase the cost of training someone.

</comment><comment><USER66> I've always thought that great developers were cloned.....from Github ;-)

</comment><comment><USER67> Great article.

</comment><comment><USER68> As a developer, I want to work with people who are at least as knowledgeable as me, and preferably much more so. I want to spend my time learning what I do not know, not teaching what I do.

<comment><USER69> You must be a junior with a few years of experience. Even so, you should discover that teaching will boost your knowledge a lot. Being surrounded by more experienced people may give you a short term boost, but teaching what you already know will deepen your knowledge in what you only think you know, which is way more important to improve.

<comment><USER68> > You must be a junior with a few years of experience.

You may say that, although that would stretch the word junior to the point where it is hardly meaningful anymore. Judging by Twitter threads and Medium posts that have become so very inclusive and protective of juniors, a junior (usually discussed as applied to web development) is someone who has hard time configuring build tools, is still uncertain about syntax of their primary programming language, and is easily scared by a smidgen of functional programming (such as the reduce function). I wonder where they would fit in your classification :-)</comment></comment></comment>


Fun with Python bytecode – Generate and modify it using evolutionary algorithms - <AUTHOR> http://multigrad.blogspot.com/2014/06/fun-with-python-bytecode.html

<comment><USER2> >You have probably already heard that Python, unlike Fortran, C++ or Go, was an interpreted language. While not completely wrong, it is not entirely true either.

Interpreted byte-code is still interpreted (and is a norm among interpreted languages: VB (pcode), PHP, Perl, some Pascal, Java (until the JIT gets to it) all interpreted byte-code.)

I really dislike it when people change the definitions of well established things because they don't like their own, or others, connotations of the term.

>Thereafter, these instructions are actually interpreted by a virtual machine.

Indeed like most other mainstream interpreters do...

<comment><USER3> CPython is both compiled and interpreted. His point was that the Python source code does not get interpreted, it gets compiled to bytecode that gets interpreted by a bytecode interpreter (a VM).

He was dispelling the common misconception is that Python is an "interpreted language" and Java is a "compiled language," when the reality is that (in their most common implementations) both of these languages are compiled to bytecode that is then interpreted by a VM.

This is in contrast to both languages that are purely interpreted (like toy Lisp implementations are and I think Ruby MRI used to be) as well as languages that are purely compiled to native binaries (like C/C++, Haskell, Go).

<comment><USER2> >His point was that the Python source code does not get interpreted, it gets compiled to bytecode that gets interpreted by a bytecode interpreter (a VM).

My point was almost every mainstream interpreter does this (and has been for decades). So him saying "Python... was an interpreted language. While not completely wrong, it is not entirely true either." is confusing and inaccurate. It is _completely true_ that Python is interpreted (and like almost every other interpreted language its the bytecode that is interpreted not the source code).

When I was doing my undergrad we had an assignment to write an interpreter, at the end of class our new assignment was to make it 10x faster. So we did this by converting the parse tree to bytecode rather than directly executing it as it parsed. It wasn't hard or advanced work.

<comment><USER4> While I'm with you on the definition point (it _is_ interpreted) I fail to see the relevance of that last paragraph??

<comment><USER5> User voidlogic was pointing out that converting to bytecode before interpreting was so mainstream (and relatively simple) that even undergraduate students do it for an assignment.

<comment><USER2> Yes, this exactly. I should have been more direct.</comment></comment></comment></comment></comment></comment>