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.
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.
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 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.
>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."
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.
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.
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.
> 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.
> 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
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).
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.
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.
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?
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.
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.
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.
> 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?”
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.
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 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."
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.
>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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
Your rant reads like "I'm a woman and want special treatment."
Tech is not touchy feely and I will never work for a company with female developers on the team, as women always try to be held at different standards than men.
Newbie bashing has been around since the dawn of the internet and harsh criticism is the only way for coders to improve.
Nothing is ever good enough, which is also the reason why technology improves.
Easily satisfied people tend to create sloppy work.
Criticism is not bad, but is "harsh" the "only way"? Is there no utility in constructive criticism that isn't harsh? Is there really no other way to improve? For example, if I review someone's code who is better than me, and I learn new techniques from that review, then I have improved, even though there was no criticism involved.
Also, be careful with "always". Pedantically, all it would take is one woman coder somewhere in the world who doesn't try to be held to a different standard to invalidate your premise. I've found that the women coders I work with do not appear to expect or behave any differently in terms of standards or quality compared to the men.
Until recently I've always worked in life-critical systems (bugs == death). Harshness was never required. Unceasing scrutiny was. As you say, criticism/analysis and harshness are different things. Probably some of the best leadership I ever witnessed was the lead engineer of a project walking around to each person and seriously asking "and what are you doing today to excel". You were expected to have an answer. It's never enough to just do your job, but it is enough to recognize your current limits, sometimes fail, and have a plan to improve. I try to apply that attitude every day, now over 20 years later (I'm guessing posting on HN does not go under that column, so back to work for me!!!)
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).
131 comments
[ 3.3 ms ] story [ 219 ms ] threadI'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.
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.
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.
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?
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.
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.
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."
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.
They are usually not your co-workers :)
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.
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".
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).
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."
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."
It's easy to criticize, but hard to create; critical responses are the low-hanging fruit of intellectual discourse.
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.
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.
Why are people so insecure in software? I have no idea. Outsourcing? Social backgrounds?
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.
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.)
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.
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.
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 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.
[1] https://news.ycombinator.com/item?id=8747260 [2] https://news.ycombinator.com/item?id=8747255 [3] https://news.ycombinator.com/item?id=8747247 [4] https://news.ycombinator.com/item?id=8747523 [5] https://news.ycombinator.com/item?id=8747278 [6] https://news.ycombinator.com/item?id=8747624 [7] https://news.ycombinator.com/item?id=8747248 [8] https://news.ycombinator.com/item?id=8747244 [9] https://news.ycombinator.com/item?id=8748571 [10] https://news.ycombinator.com/item?id=8751978 [11] https://news.ycombinator.com/item?id=8747364 [12] https://news.ycombinator.com/item?id=8747228 [13] https://news.ycombinator.com/item?id=8747712
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.
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.
Why do you think that is? (Sincere question)
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?
-----
How do you feel about goldfish?
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...
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.
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.
Bullying is not exclusive to jocks. I've always seen any kind of bullying, from anyone, as a sign of severe insecurity.
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.
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.
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."
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.
Great point, I had not considered that.
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.
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.
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 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.
I would like to hear more about that.
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.
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.
In the hyperbolic hypothetical in the article, "But it isn't responsive!" would be a pretty silly criticism, I think.
It all comes down to insecurity.
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.
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.
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.
Perhaps your success can be in spite of the critics.
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.
Sigh. Sigh.
Programming is no longer a science, it is a liberal art. You're just plumbers now.
Tech is not touchy feely and I will never work for a company with female developers on the team, as women always try to be held at different standards than men.
Newbie bashing has been around since the dawn of the internet and harsh criticism is the only way for coders to improve.
Nothing is ever good enough, which is also the reason why technology improves.
Easily satisfied people tend to create sloppy work.
Also, be careful with "always". Pedantically, all it would take is one woman coder somewhere in the world who doesn't try to be held to a different standard to invalidate your premise. I've found that the women coders I work with do not appear to expect or behave any differently in terms of standards or quality compared to the men.
Is that still going on?