“Nothing you can do impresses me” | Hacker News Reader

“Nothing you can do impresses me”

ginnabaker.wordpress.com

168 pointsluu124 comments

When I first came to Silicon Valley, I had a couple of senior engineers as my mentors. The most important lesson I learned from them is that they were extremely supportive. I had a couple of ideas for new features, and instead of shooting them down and telling me why it wouldn't work, their responses were always "Hmmm, sounds interesting. Why don't you spend some time on it and let's see how it works out." When I did something dumb, they would point out the mistakes after implementation, but never in a "I'm smarter than you" way.

Of course, since then I've had many jobs where the other engineers were always hypercritical as this article points out. In this industry there certainly is an undercurrent of everyone trying to prove how smart they are by showing why everyone else is dumber than them.

However, I'll never forget my first mentors and I try to respond exactly as they did, which is be supportive to any of the junior engineers that I mentor. I always try to not say "no", even if I feel they are wrong, and I always engage in a conversation. Even if I disagree with what they want to do, I'll try give them the opportunity to prove me wrong (within reason) as opposed to simply shutting them down with a curt "you're wrong, no."

When I was a newbie engineer (ha!) I remember talking to senior engineers, and having a bit of trouble keeping up with the conversations. It didn't seem to flow right. I would try to agree or provide supporting/counter evidence and just couldn't keep tack of what direction we were heading.

Now, I realize they were just thoughtful. While I was rushing to a destination, they were feeling out the problem. They knew how to handle the middle stage where sides haven't been chosen yet and bias is still settling. At first I took the phrase "well, let's think about that for a moment" as a trigger, but I've caught myself saying it a lot. They weren't implying that I hadn't already thought about it, but rather their way of slowing down and smelling the roses, in a technical way.

And I can remember every time this led to a long discussion. Easily some of my favorite times working involved a senior engineer looking off and asking "well, let's take a closer look at this."

Your point is spot on for a good senior level person in any field. Being supportive and letting people fail or succeed with positive reinforcement helps move a working environment in a better direction. When that environment is better then you will attract and retain better quality employees. Win-win all around but just depends on how the senior level people and management act and create that environment in the beginning.

I try to address this by asking a lot of questions about why they're choosing to do something in a particular way. Don't go at it with trying to poke holes in it (which is the point of the original post), but rather to understand what they are doing and why. Ultimately, the job of the senior person/manager is to set the vision/direction and ultimately trust the person to do what's right. This is hard with junior people, but you were allowed to screw up (and succeed) when younger, so allow them to do the same thing :-)

It's not just 'this industry.' You'll find people in all professions who try to make themselves look and feel smart by throwing stones at other ideas. Frankly, it can be effective. Non-expert outside observers (sometimes this means managers) can be impressed by such cheap-shot artists.

It's easy to criticize, but hard to create; critical responses are the low-hanging fruit of intellectual discourse.

Your comment made me remember a documentary titled "The Trouble with Experts" which I found interesting. It can be found in youtube atm.

Yes, it's hard to create. But after 35+ years writing software, I haven't just seen it all, I've done it all.

This topic is surprisingly well timed for me; just the other day I was reflecting on the fact that most times I'm moved to comment on something, it's sharp criticism. I was wondering if I've just got a massive negative attitude; I would prefer to be more positive in my approach to life. But this is the reality - most of what I'm criticizing really is stupid crap. And when something comes along that's actually praiseworthy, I acknowledge that accordingly too. It's just that those events are few and far between.

As for ideas presented by newbies, my initial reaction depends a lot on presentation. If it's an overly excited, enthusiastic "hey guys, look at this amazing new thing I've created" I'm more inclined to judge it harshly. If it's a more measured, "I think this could be interesting" I'll be more inclined to study it and evaluate it supportively. The message defines the messenger, and sometimes the messenger deserves to be shot.

Someone above commented about negative critique reflecting arrogance and ignorance from the critiquer. I think the case I just described is the opposite - it is arrogant and ignorant of the newbie to believe they've discovered something that no one has thought of before. Most of the time you can point them to previous solutions with no more than a few seconds' thought. Most of the time their approach demonstrates that they don't understand the system they're working with, and don't even understand the problem they think they've solved. A cautious presentation indicates that they've thought it through and are aware of their own limitations - I always encourage thoughtfulness. An over-excited presentation generally means the opposite, and I will discourage them strongly and harshly. There's no excuse for ignorance, not in this age of ubiquitous access to information.

This isn't kindergarten. Not everybody deserves a gold star.

Well, I'm not sure the argument applies if you are dealing with fools. Sharp criticism and dismissal is not an unexpected response.

Another common trait of the 'troll' to which I refer is that they often have some lame excuse for not getting their contribution to the project in good order on time- yet they are perfectly willing to stand in harsh judgement of others. The most startling cases I observed were as a faculty member. Professors couldn't be bothered completing their department work on time- but accepted nothing late from students.

The pattern seems to be that these folks are not good at finishing. Big ideas? Sure. But the devil is in the details, and they tend to shoot down others in the details, while if they had to climb the same path they would have never made it themselves.

I don't know much about psychology, but if there is a false arrogance bred from insecurity, then that's what I think I am trying to relate.

In my experience in my areas of interest (be it music, cycling, or software development) that it’s the knowledgable, confident members of these communities who are encouraging and happy to share what they know, and it’s the inexperienced, insecure ones who are standoffish and quick to dismiss others’ abilities.

You're absolutely correct. The problem with software development is for some reason, there's an environment that makes a hell of a lot of people insecure, and then it feeds on itself (more insecure people criticizing, creating more insecurity).

Why are people so insecure in software? I have no idea. Outsourcing? Social backgrounds?

I commented on the story, but I'll reiterate a point I made here.

Coding is all mental. When you question how or why a developer wrote a bit of code, it's like you're questioning their intelligence. Some developers find this hard to take and they build up a defensive posture because of it.

It seems like being supportive is something everyone agrees is a great thing, but few people actually do. Being supportive is just so much work, after all. Much easier to think of ten ways to tear something down.

For evidence of how supportive tech communities are, take a look at what happens when someone tries to show off their early projects: https://news.ycombinator.com/item?id=8747053

Comments include "They're probably lying," "This is like a parent posting their kindergartener's first crayon house-and-trees-and-sun drawings out into blogs," etc. And most of those comments were heavily endorsed by this community, judging by their overall position relative to sibling comments. So if HN is a thermometer for how friendly tech is, apparently nice people are rare.

Hopefully the culture will change, but that will take a lot of time.

(Now that I've posted this comment, I realize that it's not very supportive, which is a little ironic. Maybe a post-it note on my monitor that says "Be supportive!" would be a good reminder.)

The internet phenomenon of simultaneously granting voice with anonymity has definitely given rise to much more critical, negative discussion, which is ultimately fruitless and detracts from community value.

Like you said, it takes work to be supportive, and if your voice isn't tied to your reputation, many will forgo even attempting it.

That's not to say the workplace is the same though. Some people have figured out that support begets support, and put forth the effort. Online though, it's almost the tragedy of the commons, where users will take only what they want out of a community without even thinking about contributing to it's value or future.

True enough, but it may be one reason there are comparatively few women in tech. People choose a career for themselves when they're years of work away from being in any workplace. Hacker News is the closest thing that people will get to knowing what it's like to work in tech.

Which is unfortunate, since HN is nothing like working in tech. Remember the brogrammer phenomenon? At the time, it almost seemed like that was the direction the industry might be headed. Luckily not.

>Which is unfortunate, since HN is nothing like working in tech.

Working with SV firms full of men in the 20s is exactly like this. My colleagues are pretty much brogrammers, or overseas contractors (who are similarly young, callous, arrogant, and emotionally...young).

And looking at other sectors of tech, things look pretty similar. What area of tech do you work in that is nothing like HN in terms of this attitude?

(disclaimer: I actually really appreciate HN as a source of information, and there's an impressive amount of expertise here, but as a social network, it's depressing).

I don't think this is new, just more visible. Exactly this same culture is documented in Kidder's "Soul of a New Machine", and if you read biographies of Oppenheimer, Feynmann etc the same was going on back in the 40s. Academic math is filled with stories of famous crotchedy 'X' launching a withering attack during seminars.

I agree with your latter points; I think social media is making it possible to change this behavior. I.e. I view recent developments positively, not negatively.

    Comments include "They're probably lying," "This is
    like a parent posting their kindergartener's first
    crayon house-and-trees-and-sun drawings out into
    blogs," etc. And most of those comments were heavily
    endorsed by this community

Hmm; I remember that thread as much more positive. Let's look back over top level comments and look at ratios?

     [1] supportive: I did this kind of thing too!
     [2] dismissive: this sound suspicious
     [3] supportive: nostalgic
     [4] supportive: modern stuff shouldn't be harder to use
     [5] supportive: I did something similar
     [6] supportive: astonishing story
     [7] dismissive: nitpicking remembered memory sizes
     [8] supportive: fascinating story
     [9] supportive: we should be talking about the op, not ourselves
    [10] supportive: I did similar stuff too
    [11] dismissive: win2x > win98
    [12] supportive: similar experience; would love to talk
    [13] dismissive: not an os, it's a shell
    ...

Seems largely positive? And I'm not seeing either of the two quotes you reference.

The dismissive criticism was not only present, but in a large proportion of messages; and those criticisms were supported by upvotes. These facts make a very clear statement about HN. I'm not sure what you are trying to prove with your ratios, do you think that the only issue is whether the ratio is better or worse than 1:1?

The second toplevel comment ("this sounds suspicious") and its replies were mostly what I was referring to. The original author had to show up and defend himself, something that would rightly terrify many newbies. Comments near the top are exponentially more representative, both because of upvotes and because of the number of replies they engender.

Although it's interesting that a toplevel-only view results in a much more positive outlook. I wonder if I could write an extension to hide all replies by default to see what various threads would look like.

This goes both ways. I've tried to be a helpful force in a few coder's lives, but something prevents them from taking the advice to heart, and instead of getting better, they just stop coming to me. I then only run into their code during code reviews, and when I point out the issues, they take it as me saying, "you're no good", and never fix the issues, preferring to slink away into the night.

What's a guy supposed to do? I can't accept the code they write, and if/when I point out why I can't, they won't bother updating the code, and prefer to instead just disengage entirely from the process to go work on something else.

>I've tried to be a helpful force in a few coder's lives, but something prevents them from taking the advice to heart, and instead of getting better, they just stop coming to me.

Why do you think that is? (Sincere question)

There's a surprisingly large number of coders who believe themselves much better than they are. Giving them useful feedback, no matter how supportive or positive, is extremely difficult.

How did you determine that you are not one of the coders who believe themselves better than they are? Because if you are misled about your own ability, you might also be misled about which feedback is useful.

Is it possible that there is a surprisingly large number of coders who believe their feedback more useful than it is?

If coder feedback tends to be useful, then isn't it likely that meta-feedback on the usefulness of feedback is useful?

Then suddenly it becomes impossible to offer any feedback. Or discuss offering feedback. Or discuss even the possibility of feedback.

-----

How do you feel about goldfish?

Most people ignore the advice they are given, that's just how people are. They have to come to a conclusion under their own power, or else it just won't stick.

There are exceptions that should be studied to understand the phenomenon. One thing I know there are people who will diligently take and address feedback, but only of one particular kind. For example, where I worked at Microsoft code review feedback was sacred - you never complained about it unless it was demonstrably, factually wrong, and you did as you were told. There probably were people who didn't follow these rules, but if so they did not last very long. Another example is master/apprentice relationship, where apprentice relegates his creative autonomy to the master for certain duration. This is largely imaginary at this point, as I've never seen this happen myself, but it's worth looking into. Yet another example is people's reliance on authority status - when an authority says something, many people are inclined to believe it just because.

You will note these are all exceptions to the rule however. Outside of these narrowly defined areas, people largely ignore any advice they are given. It is for that reason many people who have something to say keep it to themselves - they don't want to waste their time. Sometimes I bump into someone misguided and I just look at them smiling politely without saying much. Sometimes I also see people smiling politely at me, when that happens I try to unwind last few minutes of my words to see what could have gone wrong...

This might seem like a strange comparison, but this reminds me of how positive reinforcement is related to training animals and small children. When you use positive reinforcement as a learning tool, the individual is more predisposed to behave properly and will want to follow your cues more. It could be the reason they're no longer coming to you is you're not giving them enough encouragement and positive feedback. You can also try to engage more, like go to them and offer to help explain what is is you'd like them to do, or answer questions. (It could also be the opposite and you may need to back off from engaging... people are complex)

It's a great comparison, and related to the folk wisdom of "you catch more flies with honey." Using punishment on animals often causes avoidance and aggression, which isn't usually the overt objective.

So maybe we shouldn't be surprised when punishing coworkers causes avoidance and aggression (especially when we are not being genuinely constructive or don't have solid reasoning). And maybe we should recognize that this isn't usually what we want for an institution primarily oriented toward building useful products.

Then a big question is why people keep repeating abusive cycles even when they manifestly doesn't work. Maybe they think these things work despite abundant disconfirming evidence. But I think a more common answer is that making things work in that sense isn't a real objective. The real objective is to exercise their own aggression and show dominance because that's what works for them. The bad dog owner doesn't really kick the dog for pooping on the carpet to make it stop, but because it's gratifying to kick the dog and have it be afraid. If the poop is not an undesired outcome, but only a sign of insufficient submission, then it is a sufficient correction to convincingly reassert dominance (and no dog wants to be kicked).

If our response to punishment-induced avoidance, as in much of this HN thread, is then to tear the avoiders down socially for not heeding our manifestly expert criticisms, I think what's going on is probably more about entitlement to aggression and reinforcement of dominance than productivity of the relationship. We might believe or state that we are offering helpful but unpleasant medicine, but if our response to the patient not taking it is some kind of social aggression rather than anything effective, that suggests our unstated emotional reasons are not as we would have others believe.

This attitude fits with the tech idea that the social structure, the company, etc. are actually meritocracies. Actual meritocracy sounds fine, but the ideology that we are IN a meritocracy has other uses. If I am in a position to abuse you, I will naturally tend to believe that this is because I am actually better than you and I am entitled to abuse you. In turn, I may accept this system because eventually seniority will allow me to become the abuser. Like dedovshchina and institutions at many boys' schools and fraternities, and exactly like tech hiring as well.

I'm of two minds about this. I like supporting new ideas, but I've found that the quickest way to build the confidence of a new engineer is for them to have something succeed. So I do think there's a balance that has to be struck between supporting whatever they want to try and guiding them towards things that will give them their first taste of success.

Shipping is better for the confidence. And if you build a prototype that makes it into the product, boy does that raise the confidence level.

This is true in every sector of work. People are motivated by success. As a marketer who manages a team of 8 (including myself), I've been trying to learn to a) give context into why I might be poo-pooing something and b) a few ideas for other directions we could go.

Part of the job of being a mentor and manager is to guide them in a helpful way to greatness. Allowing them to work on whatever they want to work on is no way to build someone's confidence and skills, let alone a business.

> since then I've had many jobs where the other engineers were always hypercritical

Bullying is not exclusive to jocks. I've always seen any kind of bullying, from anyone, as a sign of severe insecurity.

The culture must've changed... I've recently had people in Silicon Valley tell me "this would never work" when they were staring at a working prototype. I generally avoid the south bay now.

This blog reminds me of something I heard in an interview with Dr. Roy Baumeister. He pointed out that when he works with grad students he has to actively criticize and knock down most of the ideas that his male students have because they are full of testosterone and hubris and he has to actively draw out his female students to build their confidence. He told some of his grad students this years ago and they thought he was being sexist, but years later when they (both male and female) got their own grad students they noticed the same thing.

Baumeister is a psychologist who has done research in evolutionary psychology, culture, and gender. His point is that, as taboo as the subject is today, there are differences (statistically) between men and women: how they learn and how they interact socially, and what they like. Right now, we are doing a lot of work to make STEM a better environment for women, but we probably also need to understand that the style of interaction that the poster is criticizing is not bad per se, it’s just a male style, and it does work - it’s what young men use to push themselves further. Women, on average, seem to need/want a different style. It’s going to be hard to figure out how to accommodate both needs without systematically favoring one.

We may not be at the right stage culturally to have a serious conversation about this. I think this is one of Paul Graham’s “Things You Can’t Say” http://www.paulgraham.com/say.html

It's not just women who prefer this communication style, by the way. As a male, I find the constant jockying for position among other men to be tiresome and stressful. It's particularly acute among other coders. To be honest, it's also one of the main reasons I don't maintain many friendships with men.

There are others still who are often excluded in this kind of environment: minorities, LGBTs, and people who are shy by nature.

I feel the same way, but I think it is wrong to consider that style bad. We shouldn't have to contain our natural exuberance and energy all the time. A true diversity would provide some place for it.

Fair point, and I don't consider it "bad" in the workplace. I've worked in places where there was an abundance of different styles (in academia), and it worked great. I'm actually kind of trying to return to academia (as staff, probably) for that reason.

My main hiring qualification has been "Will this person continue to write code that will make me get up in the middle of the night?" or "Will this person contribute to me only working 40 hours and having no emergencies?". I try not to hire the former and hire the later. The culture thing in the second paragraph is bull. A bunch of clones is no fun at all and doesn't give the proper vision.

That being said, the "Nothing a newb can do impresses me, because I can find a hole in it.” is a bit overblown. Learning means that you are going to get comments. Some good, some bad. This isn't grade school and I don't remember anyone handing out gold stars. This is the same crap attitude that leads directly to ageism since experience is not valued.

> This is the same crap attitude that leads directly to ageism since experience is not valued.

Great point, I had not considered that.

>A bunch of clones is no fun at all and doesn't give the proper vision.

Can you explain what this sentence means? Frankly, your English is crap and your vocabulary confused (particularly your articles), so I have a hard time understanding you. I'm telling you straight up in the hope that you'll learn and benefit from my criticism, since I am a very experienced native-English speaker. I hate wasting my time reading incomprehensible sentences. I'm sure you understand.

>This is the same crap attitude that leads directly to ageism since experience is not valued.

No, I think it's mostly been VCs and big Silicon Valley companies looking for people willing and able to work 60-100 hour weeks that has lead to ageism. And everyone wants to be the next Google or Apple, so a lot of smaller companies have aped this culture, including the ageism.

Congratulations on your English proficiency; it's very impressive.

Giving the benefit of the doubt, I think wereabout was trying to see how I handle criticism, but it is really not a good experiment since we are talking about coding and not English skills. Truthfully, I've had to deal with too many psychologists and social workers in the early part of my career to be rattled by that foolishness. I am long past the worrying about a education on a reservation has affected my English grammar or writing. Particularly when we are talking about messages on a forum scribbled off in haste. Also, that is not the language or tone to express a critique unless you get paid by the media to be outrageous.

So, detouring back to the full explanation. The dictionary definition for the meaning of clone I was referring to is "a person or thing regarded as identical to another". Hiring people that are basically the same is boring and doesn't lead to a diversity of though or experience. Its fine having similar friends and you will grow with them, but a business shouldn't operate that way. You owe it to yourself and your investors to cover as much ground in experience and knowledge as possible.

>A bunch of clones is no fun at all and doesn't give the proper vision.

I'm also a native English speaker, and had no problem parsing the sentence.

The implication is that hiring a bunch of people very similar to each other in opinions and skills results in an echo chamber mentality, and makes it harder for anyone on the team to identify with differing opinions that could improve the product but are contrary to the team's default position.

I sympathize with the general sentiment but did not like the piece itself. I am open to considering the possibility that I am in fact part of the problem. Nonetheless, I will share my thoughts.

> But because of the urgent need for new blood / ideas in the tech world, our lack of ability to reward new developers is a particularly profound example of shooting oneself in the foot.

Slow down. You're fresh out of coding bootcamp, so it seems a bit presumptuous to be pontificating about "our" problem as if you don't have a vested interest in being "rewarded".

> Or, put another way, what if a friend had spent a month perfecting his roast veal, cooked you some, and was eager for your opinion. Do you really want your first reaction, before tasting it, to be, “I hope the wine in the veal sauce is authentic French Merlot!”

This is a deeply flawed analogy. Do you expect potential colleagues and employers to treat you as a friend would? Do you think a professional chef would be uncritical of this hypothetical veal if someone came in off the street with it looking for a job?

> Seriously, is “Is it responsive?” really the first words you want to come out of your mouth, before you’ve even seen the product?

In my opinion this sounds like a contrived straw man. At a minimum, it's not generally representative.

> In the last two months, I built an app with a friend. It’s not rocket science. It’s not perfect. But it was a lot of work, and it’s beautiful, and it’s mine, and I am so proud of it.

> [from the landing page] : "Free, Easy, Secure"

I could not help but be taken aback. Coming from a group of novice developers, declaring an app "secure" is a bold claim.

I had a similar feeling. You start out doing grunt work when you're new in a career, it isn't glamorous and you have to prove yourself through actions. Coworkers are not friends first, they are coworkers. I'm not sure, but I think this post has a feeling of entitlement.

I think this thread demonstrates (at least part of) the issue. If you've been hired then you're already past the first hurdle. The attitude that you somehow have to 'pay your dues' is part of the overall problem and is akin in spirit to 'hazing'. There are may ways to give encouraging feedback (I'm sure there are plenty of books on it), so it's more of an attitude thing.

The comparison with the professional chef is amusing considering the TV chef shows I've seen. They're regularly abusive, cantankerous and create terrible environments to work in (imho). Not something that the developer community should aspire to.

> The attitude that you somehow have to 'pay your dues' is part of the overall problem and is akin in spirit to 'hazing'.

> There are may ways to give encouraging feedback

You seem to be implying that these two concepts are mutually exclusive. They're in fact completely independent of one another.

> The comparison with the professional chef is amusing considering the TV chef shows I've seen. They're regularly abusive, cantankerous and create terrible environments to work in (imho). Not something that the developer community should aspire to.

That actually wasn't lost on me. TV shows aggrandize it, but the culinary world is not a polite one.

If anything, this should help serve as a point of reference. The "tech industry" is not harsh. It is in fact exceedingly gentle.

> You seem to be implying that these two concepts are mutually exclusive. They're in fact completely independent of one another.

My point here (perhaps poorly made) is that people behave as though they're mutually exclusive. e.g. that you're not really paying your dues unless people are shitting on your work (and when you've progressed, you'll shit on those below you).

> The "tech industry" is not harsh. It is in fact exceedingly gentle.

Picking an extreme example and then saying tech is gentle by comparison is somewhat ridiculous. The tech industry is certainly more relaxed in a number of ways (e.g dress code) but that doesn't mean it's 'gentle' in every respect. As the OP tries to point out.

> My point here (perhaps poorly made) is that people behave as though they're mutually exclusive. e.g. that you're not really paying your dues unless people are shitting on your work (and when you've progressed, you'll shit on those below you).

You're jumping to the unreasonable conclusion that the only possible interpretation of "paying ones dues" is to be "shit on".

That is, quite correctly, the view held by certain occupations (e.g. the military), but it is not the only way to parse the term.

A more charitable way of interpreting it would be as shorthand for "demonstrating commitment and competence". This is a fairly ubiquitous concept across virtually all professions.

> Picking an extreme example and then saying tech is gentle by comparison is somewhat ridiculous. The tech industry is certainly more relaxed in a number of ways (e.g dress code) but that doesn't mean it's 'gentle' in every respect.

Did you expect me to enumerate every industry that I consider less forgiving and more emotionally demanding than tech? Fine.

    academia
    finance
    military & law enforcement
    law
    medicine
    management consulting

Those are just the industries I could name off the top of my head and which I have enough familiarity with to pass judgment.

This. Exactly this. I would hate to work with such people. Taken aback? Bold claim? As a novice developer if someone is declaring their app to be "secure" then there is nothing wrong with it. There are two possible scenarios.

1. They've actually made the app really secure. -> Appreciate it.

2. They've probably left a lot of loop holes. They've made it "secure" based on their understanding of security. -> Appreciate it. The feedback be given in a much more positive way by acknowledging their existing work and then giving them few pointers of making the app more secure. If you were taken aback then you're just being cocky.

You're not expected to be friendly with anyone. At the same time, there is no need to be condescending. You, as a senior dev, are expected to give positive feedback and mentor the group of new developers.

> They've probably left a lot of loop holes. They've made it "secure" based on their understanding of security. -> Appreciate it. The feedback be given in a much more positive way by acknowledging their existing work and then giving them few pointers of making the app more secure. If you were taken aback then you're just being cocky.

You're injecting my comment into a manufactured scenario.

I'm not performing a code review, vulnerability assessment or pen test nor am I the OP's supervisor. I'm sharing my reaction to a web product as a potential consumer.

An invalid claim of security causes me to lose trust in the product and its creators. It's as simple as that.

Being in the senior position I have had both attitudes (critical AND supportive), and I can tell you it has to do with how the ideas are presented to me.

Sometimes the new developer will come in and talk about how his new thing is better than everything else, and everything written before him was garbage. You can bet he will get a lot of criticism. This is not some ego thing (although I am sure that does have an effect), but because it's clearly what he needs in order to gain perspective. I mean, unless he really did create something that awesome, but so far that has not occurred.

On the other hand, I have had people show me things that are not very good, but the idea is good and she just wants to show me. In those cases I have a lot of praise for her and encourage her to develop it further

Likewise, if the person is just looking for input, I will usually focus on the positive.

While it may not always be true, if you find you get a lot of criticism it may be because you are overly promoting your own work.

This is a totally fair attitude. To be honest, there have been a few times when I've been going on and on about something I've accomplished (not even necessarily in software) and I've been cut down by a more experienced person. After I finish fuming, I usually stop and think, and that's been a good thing.

The problem I've run into in software is that I've also been slammed when I've very humbly and timidly introduced a project or some code, in an area I'm new in. It's a problem, more so than in other professions/hobbies I've spent time in.

That's really a shame. I know a lot of my success has been due to the patience and instructions given by my seniors when I started.

Perhaps your success can be in spite of the critics.

I have learned a similar lesson over the past few months - I was thrust into a leadership position by part circumstance, and when it came to working with junior developers, it clicked that I needed to be building them up & increase their confidence in the correct approaches to engineering, not be hyper critical. I am indeed hypercritical of my own work, always striving for self-improvement, but I recognize that different people are at different stages of their lives, and it does no good to expect that everyone is the same as me.

There is a lack of empathy in the industry at large for people attempting to enter as a software engineer, and on a human level, it is an awful thing - many of them are people like us trying to make their way in the world and live a better life. It is a forgotten point, and I wish more would contribute towards the future.

In addition, those junior devs could also be hypercritical of their own work. However, they may not have the same experience or context of a senior developer and could simply be unaware of the scope of improvement. That's where mentoring and teaching should come in!

Yes, you want your people to be productive, if they're afraid to come to with questions for fear of criticism, chances are greater they will sit spinning their wheels for longer, accomplishing less.

The kernel of the argument in this post is hiring. The discussion about "coder culture"† is germane because it drives the gatekeeping function of in-group coders in hiring.

I don't have a problem with people discussing what is or isn't productive about how a stereotypical programmer behaves in groups.

But the real issue here is that the stereotypical programmer is given entirely too much authority in the hiring process; a ludicrous amount of authority once you see the alternatives available.

Only a tiny minority of tech companies hire against any kind of formal assessment rubric. A majority will make direct hire/fire decisions based entirely on face-to-face unscripted interviews --- no matter what kind of information has been collected in the hiring process, which is usually slipshod anyways.

If I'm right about why this person's argument is important, it's the hiring process that most urgently needs to change. Which suits me fine, because there's a lot more wrong with hiring in tech than bias.

† A concept I reject, but understand.

There's hiring, and then there's culture. Regardless of influence into the hiring process, the culture will perpetuate no matter who was hired or why. The industry's hiring processes in general do need improvement. But the industry also needs to refocus on a mature, professional, compassionate culture. Thing is, how the hell do you impose that on a post-collegiate boys club full of nerdy egomaniacs? (I'm massively generalizing here, but so does this article/thread)

> † A concept I reject, but understand.

I would like to hear more about that.

From what I heard the other day from a Google employee involved in hiring, Google people also hire off of informal methods, and they don't have a well-lubed statistical machine for hiring/firing and managing people.

I guess that means everything I learned in school doesn't work at Google-scale? Unfortunately the conversation didn't get to that point, but I was very curious about why a giant organization with the resources to set up a self-aware HR process didn't do so.

> Only a tiny minority of tech companies hire against any kind of formal assessment rubric.

Is there any evidence of how well this works? From what I've read these "formal" hiring strategies don't seem to lead to good results. In fact, the typical critique of tech hiring is that "HR" people have too much influence on the hiring process over technical experts.

I don't know how to solve hiring, but I'm confident that it's not been solved yet, and it's a very difficult problem.

Nothing I said had anything to do with "HR" people.

Something I said had something to do with "HR" people.

HR tends to be the implementation of a formal rubric applied to job candidates, filtering candidates out before resumes wind up on the desk of the person performing a less rigidly defined consideration.

Yes. Don't do that either.

> Let me give an example — say a new coder had somehow, impossibly, in their first month of coding, created an app that would save the planet, plunging us into a permanent state of world peace and 100% clean energy. What’s the first thing that you as a senior developer would say to that person before seeing or testing their project? Let me guess — you’re thinking, “Is it responsive?”

You built an email visualizer and are comparing it to some sort of utopian omnisavior.exe

This reads as an incredibly defensive diatribe about someone who didn't get a job because she interviewed poorly in her space.

You don't need validation at every turn, and providing that kind of false validation only cheapens actual accolades.

I thoughtt "Oh, cool".

> You built an email visualizer and are comparing it to some sort of utopian omnisavior.exe

It's a valid point.

I've seen CS grads who struggle getting HTML/CSS/JS+any backend of their choice up and running. Getting a minimal, shitty app up and running is no small feat for a junior developer, and it shows perseverance, adaptability and willingness to learn (whether they're willing to be taught remains to be seen).

I understand what she is saying, and actually mostly agree. However...

Teaching and mentoring are not software development. More teaching and mentoring need to be done, but it's not the business I'm in. I'm in the business of making software.

If I have a critical project that must be done right and done on time, I will not hire junior developers for the team. It's nothing against the jr. dev., but in these scenarios I just need the A-Team showing up and I don't have time to setup a training regimen.

Yes, it would be great if there were a good means to train and bring up new developers. Most of the universities in the world are failing to train people to be good developers. Maybe we need a master's of engineering in software development, with a real engineering certification at the end (and not the IEEE bullshit one that has nothing to do with software development). Sure, the top-tier engineering schools like MIT and CMU are putting out good, jr. devs., but most people in the market didn't get to go to one of those schools. Most people went to your run of the mill state school, where nobody cared enough to buck the status quo and fail them out of their classes if they couldn't hack it. That any good developers come out of such a system is despite the system. The pressure to keep graduation rates up has done a monumental disservice to everyone involved.

Sports teams have farm leagues they can run and groom out excellent players. Microsoft and Google and Apple have people throwing themselves at their doorsteps and can cherry pick the best of the best. I'm a freelance consultant trying to make a go of being more than just a freelance consultant. I don't have that kind of time on my projects.

Speaking of which, if you're an excellent developer with experience in .NET, GIS, javascript, and relational databases--and can devote up to 20 hours a week to a project--please contact me through my profile here.

I'm used to this?

I'll be leaving my job here in a few weeks for what I consider my dream gig. I expect to be criticized on nearly every project, because that makes me a better coder.

I'm not sure if it's just adapting to the environment or if I actually like the general cynicism. A pat on the back is nice, but I strongly believe in the "this is always shit" mantra of software dev. There is always something that can be improved, and beating around the bush with flowery language doesn't really help to fix it.

> but it’s pretty tough to come back from, “I don’t know” on your first interview question.

Argh, don't ever answer a question with just "I don't know". At least speak to how you would figure it out.

Humans in general have a serious problem saying "I don't know." Someone who is able to admit that they don't know something deserves your respect, at the very least.

The exact phrase you're looking for is "I don't know, but ..."

Saying "I don't know" is often a defense mechanism. It saves you from having to know. If you don't know, and you wash your hands of it, whatever happens isn't really your fault is it? And you're not going to know either.

But if you say "I don't know, but" and try to figure it out, or find out more, etc. ... that does take guts. That is actually admitting you're fallible AND it gives you a chance to improve and get to know.

Those are the people you want to hire.

You need people who recognise their ignorance and do somethign about it. Not people who use their ignorance as an excuse.

I agree.

But this is exactly the point of the article: There is an entire world in between "only interested in finding holes to poke" and "a pat on the back". It's a wonderful place, full of bridges and people working together that DOESN'T imply "I assume this is already perfect or else you wouldn't be wasting my time telling me about it."

When I feel like I'm doing good work, I'm a lot more productive, and I care more about doing things right vs just getting them done. Obviously constructive criticism needs to happen -- the author isn't disputing that. In fact, she says "it's been tough to get useful feedback" because people care more about cutting the other person down than actually evaluating the work.

It's very easy to couch constructive criticism in a few words of sincere praise/recognition of their work, and it generally results in them doing better work in the future. In fact, they'll be much more likely to listen to your criticism if you haven't immediately put them on the defensive. Once either side gets at all defensive, it's extremely difficult to have any kind meaningful conversation. If you always say "this is crap", then you're literally asking them to defend themselves.

If you haven't already, I would recommend reading "How to Win Friends and Influence People" by Dale Carnegie.

> When I feel like I'm doing good work, I'm a lot more productive, and I care more about doing things right vs just getting them done.

What you're really saying is that you have the rewards system of a child. The application the author wrote is very simple and has no use - what kind of feedback is she looking for?

I believe what pcmonk is trying to say is that you are stupid and arrogant, and that is a poor combination.

I suspect even "I can think of no use case for this app" would be more appreciated than "is it fully buzzword-compliant?"

Additionally, phrases like "What you're really saying is that you have the rewards system of a child" are exactly what I'm talking about. That statement is intentionally worded as an attack, so I have to make a conscious effort to not get defensive. If you want an actual discussion about how rewards systems may change as people grow up, we can talk about that. That was an extremely ineffective way of starting the conversation, though.

Different people are at different levels on the needs hierarchy.

>I care more about doing things right vs just getting them done.

In an ideal world...

Justifying the statement "this is crap" with hard evidence as to why, and then congratulating the individual on what they might have done best is all you need to make good criticism. I don't see a need to get around the fact that their work is crap with flowery language.

"I expect to be criticized on nearly every project, because that makes me a better coder."

A great deal of the criticism is not intended to make you a better coder, and it probably won't do so. It's intended to make the critic appear superior or at lest feel superior.

Yeah, I've done that. It's a bad habit to get into, and a hard one to get out of.

"There is always something that can be improved, and beating around the bush with flowery language doesn't really help to fix it."

"Great. Now tell me something I don't know."

What’s the first thing that you as a senior developer would say to that person before seeing or testing their project? Let me guess — you’re thinking, “Is it responsive?”

Does it reflect poorly on me if this sounds like a rather convoluted hypothetical? Then again, I'm not involved in web development, for what it's worth. Maybe there are people who actually think like this.

It sounded silly to me as well. I do work with web technologies, albeit in research and not industry. Maybe it's a web startup thing.

It is slightly convoluted. The author also references a completed project with that being the first question, but if it ISN'T responsive, one could argue that it's not completed :P

The phrase that came to my mind was "wildly disproportionate straw man", but, yeah.

I'm mildly sympathetic to the author's point -- there certainly exists a subset of developers who are more interested in bashing other peoples' code because it's not properly buzzword-compliant / in the wrong language / the wrong framework / uses the wrong whitespace formatting / does or does not include semicolons, than in evaluating it on the actual merits. (Though I suspect other industries also have their fair share of pedants and egotists.)

Maybe I'm misreading but it seems the criticism the author cites was in the context of job interviews, which isn't exactly the right place to be looking for mentorship or supportive "A for effort" type feedback.

It also seems like she isn't differentiating between critique of the code and critique of the coder. (To be fair plenty of people have a hard time keeping these separate, whether on the giving or on the receiving end.) The point of asking "is it responsive?" is -- or at least should be -- "responsive is important, maybe you should do something about that", not "I am unimpressed and you are a bad person who should feel bad."

I've certainly heard that said in jest, sarcasm and wit are things many programmers hold dear and believe they are best in.

If you want to see real delight in your work, do it for someone who needs it!

They are usually not your co-workers :)

This comment holds more truth than is evident.

The fact is, people who hire you don't actually want you to be better than them. This, I think, contributes largely to the criticism culture of programming.

Of course, many interviewers have good intentions. Unfortunately, malign developers (dare I say, jealous?) are prone to setting a trend for the type of questions that are asked.

I agree. This applies to the startup world as well. Ask someone who isn't in your target audience for feedback, and they'll say X and Y is bad. Ask someone who actually needs it, and they'll say they love it.

I think some times it can be your co-workers. Write a script for the service team to automate some manual task, talk to QA about something they always have to manually setup - skunk work projects are a great way of delighting your co-workers.

1. A lot of developers are missing something in the brain that allows them to feel empathy.

2. Coding is all mental (don't tell that to your hands). So, when you question a developer's code, it's kinda personal. Some take this hard. Too hard. So they build up a defensive barrier.

3. Developers are treated as a commodity by people with business degrees. This feeds the notion that they need to be perceived as the best (or at least towards the top). If that means not letting a newb show them up, well, so be it.

It should be remembered that feeling empathy is not the same as being controlled by empathy. Just because I feel empathy for a newbie's struggles does not mean I am going to push sub-standard code live so they can get that feeling of success.

As the article notes, a ruthlessly critical attitude towards your own work is very important. I'd argue that it's one of the most important traits that helps an engineer develop. If we don't teach that, we will collectively become a community of warm, emotionally supportive, technically worthless people.

Exactly true. One should not be controlled by empathy. Being empathetic allows one to choose one's words wisely. The goal is not to allow sub-standard code to pass. The goal is to correct and educate, but do it in a positive way. Empathy allows one to put oneself in another's shoes and ask, "How would I want my mentor to correct me?" Don't get me wrong, I am not advocating the "even losers get a trophy" mentality. But I've been in code reviews that have turned into blood baths. That's just not appropriate at all. Ever.

I've never been able to find a way to be warm/positive/supportive/encouraging/empathic while also impressing on someone that their screwup might have cost the company six+ figures. Or worse - in some contexts, consequences can be kinetic.

Blood baths are not acceptable, but positivity is not always capable of effectively communicating consequences. Positivity works best when very little explaining of mistakes is required.

Sometimes an empathetic explanation that something should be better will suffice. Sometimes you encounter "It works, it's fine", and something more than empathy is required.

If code has gotten out into the wild and has cost a company six+ figures, that developer is _not_ the company's biggest problem and it's not all his/her fault.

You'd be surprised. Some companies give individual devs a lot of autonomy.

My point is that positivity and empathy works best when people already know they've screwed up. Otherwise, you have to explain how they erred, what the consequences were/are, and how to fix it. The first two are more difficult to do in a positive way.

This is a depressingly perceptive comment. Is there anyway to counter or discourage these tendencies in other coders, do you think?

Normally, that would be management's job, or that of senior devs. But the former seem to encourage, or at least tolerate hypercritical responses, and the latter often actively engage in them.

Good question. I don't really know the answer. I worked at a company where the developers were very negative. Conversations just dripped with sarcasm. I think it's infectious. If the mentors are negative and overly critical, I think people become like them at some point, if only because that's the only way to communicate with them. I think you have to be self-aware and just know when it's time to exit.

This touches on a problem I see with some new programmers. They focus too much on learning and programming for attention from other programmers and not enough on in-depth mastery for its own sake and building things that help people. If you want some recognition after you finish something, then show it to someone who cares about you (family/friends).

That said, the current senior programming culture has forced this situation upon us by overvaluing the importance of blogs and toy projects.

The critical question posed in the interview seemed fine. That's the last place I'd expect to hear positive feedback: the goal is to find out quickly how qualified a person is and that means asking hard questions.

There are lots of intermingled problems in education, hiring, and culture that are irking the author but I don't think anyone's been able to concisely explain the problem and solution yet. Edit to add: we really need a Joel Spolsky 2.0 to enlighten us.

Different strokes for different folks.

I've been through the newb->novice->competent->proficient process a few times, and the thing that's kept me going was the goal of reaching proficiency. During the process, I'd always be my own harshest critic, because I'd be acutely aware of all of my weaknesses.

Any praise I'd receive would be rejected, because in my own head the person would be ignoring all of the obvious issues with what I was doing.

I understand that not everyone responds in this way, but personally I think it's easier to succeed when the motivation comes from within, rather than relying on an encouraging environment which ultimately you can't really control.

Not like I think there is no truth to TFA, but it's pretty much "You think newbs are dumb, but it is actually you who are dumb." Well, OK, I already spend a lot of time considering that. And, for what it's worth I think the senior ones are mostly not so hot either.

There is that fear that you are always replaceable and your job will be outsourced. Because of that there is constant belittling and critique.

It all comes down to insecurity.

If a candidate feels "about an inch tall" because of inane criticism, perhaps it is the candidate that needs to put things in perspective.

Is criticism in a job interview "inane criticism"?

Not always, but sometimes.

In the hyperbolic hypothetical in the article, "But it isn't responsive!" would be a pretty silly criticism, I think.

We can't all be randian supermen impervious to the prattling of the lesser beings here.

One cause of this seems to me to be that most things that people would want to show off (and then possible get smacked down for) have a high enough level of complexity that they can be hard to quickly and constructively criticize by someone outside of the process of making the thing.

Rather than try to seek out the good work that someone has done many levels deep in their code - a time consuming process that might depend on an intimate knowledge of the application, its requirements and the processes of those who made it - it's way easier to find a flaw (usually a flaw that you know is flaw because you've made the same mistake) and point that out. Or, rather than a real discussion of what assumptions the creator made and how they may have led to a less-than-ideal solution to a problem it's way easier to say 'wrong, next.'

Really serious review and criticism is great but it depends on a lot of effort in building context to make it useful for all the people involved.

I'm a bit confused how the interview came in at the end? Did the author use their project in a job application?

Probably? Do you think that's strange? Pretty standard if you ask me.

One of the best ways to grow as a developer is to build something, destroy it, and build it again. We all have the thought "what other ways can I build this?" in our heads as we're building a project. Most times I have seven different ways to do something, and the hardest part is just picking one. So, in my opinion, a great interview question would be "how else could you have built this?". It shows that the developer weighed the choices that we all inevitably have.

This article conflates programming and making a product. The example of creating 'an app that would save the planet' most likely has little to do with who programmed it, and more to do with what it is, and how it is applied in the world.

I think the real root of the problem is that we are much better at evaluating how to make something better than accepting and truly appreciating it for what it is. It's the same as when someone asks for feedback after reading you an article they just wrote, unconsciously we're biased towards giving feedback to improve the product being shown, not giving them praise on everything they did right. That being said, it is possible to train yourself to be better at giving positive reinforcement and that's what I took from the article.

Cynical people grossly over-estimate the value of their criticism. People either take pride in their work, and are self-critical, or they aren't, but if someone worked hard developing something, you complaining about the features you don't like just lowers their opinion of you. Focus on the positive, let them see the negatives on their own (everyone does).

Developing open-source software is an instant cure for cynicism. Having your software torn apart from strangers who've contributed nothing is a quick fix for criticizing others.

This is one reason I've had fun on the tilde club I joined a while back. There's a culture of curiosity (and curiosities) with a non-critical culture and a mutually agreed upon "NO DRAMA" rule. I've worked on some silly scripts and web pages just for the sheer joy of it and I've been able to share my work with others without fear of the usual hyper-critical community (which I also love in its own way).

>This is one reason I've had fun on the tilde club I joined a while back.

Is that still going on?

This confuses programming culture with "the tech world", which might or might not mean silicon valley, but at least something similar.

One of my very favourite comment on hacker news was about Notch (Minecraft's creator) just coding toy games and not attempting anything big: "I think pg might have overlooked this side of hackerdom." I feel the comment can apply much more broadly.

"But because of the urgent need for new blood / ideas in the tech world" lol what?

it seems like the so called creative coding community is less about poking holes and more about cool stuff they made

There are few different focuses in the post. It bounces around so I may not be responding correctly. As someone else said the attitude of the approach matters.

The first example of a junior developer making an application. They are full of pride, having taught themselves one technology stack to produce one application. Unfortunately she leaves out the approach. With assumptions, this junior developer is looking for validation of their achievement from a senior developer working at the same company. They are not peers, they are not friends.

If the first thing out of the senior developers mouth was a straight faced "is it responsive" with no sign of sarcasm then they don't want to be your friend, mentor, and only care about the number of bugs you create or fix. Great, you've learned as a junior developer that this senior developer is not on your side, and you should seek validation else where. From other junior developers perhaps, or ask another senior developer for feedback while first informing them you put a lot of work into it and what kind of feedback you want.

The senior developer taught themselves that same stack, and a dozen other stacks. They did it for free, it doesn't matter that you did, you've made 60 pages of code they've wrote several libraries of congress's worth of bugs. Your success doesn't mean anything to them because there is nothing special in it, and they are not your friend. There are other junior developers on the team that also taught themselves a stack, maybe two. You won't find admiration for your achievements from within the group. If you want a mentor then approach the senior developers with that, say you want to learn more, want to shadow them, peer program perhaps. However don't expect it from them, no one is entitled to it so you're asking them to put in care and effort. Even asking someone to review your project has a cost, it takes time, caring, and effort to do it right.

------

The interviewer asking a question like that was attempting to engage you in a critical problem solving thought process. You don't know, that doesn't matter, how would you find out, what steps would you take, why would there be alternatives.

------

The feedback the junior developer received isn't skeptical it is dismissive. Being dismissive isn't nice. It isn't snobbery, you get to be senior developer by being a better programmer, by being better at just that stack, by being there first, by luck or by time.

------

If you worked at a Michelin star restaurant as a sous chef, and on the side you worked for a month perfecting a veal dish, then presented it to your head chef. You bet your ass they would be critical of it. If you presented it to your friend, they would shower you in praise and enjoy eating it with you.

------

On hiring, yes there are problems, there are cliques, existing developers might feel threatened, but those don't just apply to junior developers.

------

All that being said I love a developer who takes the initiative to teach themselves a stack on their own time. That is awesome, keep doing it, don't stop, find other sources of camaraderie and mentorship.

Can we please stop using the word "coder", for the love of god.

Competition heats up as programming languages get easier... and people obsess over being accepted by their peers? We learned from punch cards, through flame wars, and when being a nerd was actually a bad thing to your social status.

Sigh. Sigh.

Programming is no longer a science, it is a liberal art. You're just plumbers now.

Reply on news.ycombinator.com