Why Rockstar Developers Don't Ask for Help | Hacker News Reader

Why Rockstar Developers Don't Ask for Help

thinkfaster.co

82 pointsfasterthinker60 comments

It's also important to ask questions well: "here's what I did and what I expected, but this happened instead. Here's what else I've tried and researched before asking you, and these are the things I'm not sure about".

Forming a good question often leads to the answer in of itself. By writing it down and emailing it instead, the person can answer it at their own leisure, and the response can be easily shared with the whole team to learn from.

Even better, if that fails, you now have a copy you can easily post to a github issue or mailing list (or stack overflow, if you prefer).

When I have trouble with something, instead of reaching for colleagues, google, or stack overflow, I just read the manual(s) top to bottom, multiple times if necessary, or the source code, or write prototyping test cases.

Even if it doesn't always solve my problem, the things I learned in the meantime always pays back later. The downside is I inevitably become the person to ask for help, and I'm always told "How do you know so much?", and I tell them exactly that, but they don't seem to get the hint, I'll see them again in the near future. I've even been previously termed as a kind of "real life stack overflow".

I suspect it may be a generational issue -- those of us who were left to solve difficult problems without the help of the internet have developed methods that do not include google and stack overflow.

Anyway, I do ask for help. I've studied destructive forces in software development teams, my current hypothesis is that ego is behind them all.

I second this.

When you frame the question to ask so someone for help sometimes you tend to get the answer yourself. I've been practicing rubber duck debugging for a while and it has proved quite successful.

http://en.wikipedia.org/wiki/Rubber_duck_debugging

1) Asking good questions is important, the process of forming a good question will often lead you to your solution.

2) Giving good answers is also important. You could show the person asking the question how to solve their problem, or you could show the person how to find the solution to that problem.

3) Even if you are asking good questions and getting good answers, there is still value in having to force your way past a problem to a solution. Not only does it teach resilience, but the struggle to find the solution can teach you many things that are tangential to the problem

1) Absolutely 2) Teaching is ideal. Except... 3) Too many people today don't care about anything but the answer. They are lazy and/or uninterested in learning and growing. Take for example one of my In-Laws and their dishwasher, they a) never knew about rinse aid and b) stack the dishes too full and/or on the wrong rack resulting in half the dishes coming out still dirty. They think they are saving time and "winning". They can't be bothered nor have they ever considered reading the owners manual that came with the thing. If more people would RTFM that people have taken time to compile... It only takes 5 or 10 minutes.

You sound like you have a deep psychic wound from this.

"Too many people everywhere, all the time don't care about anything but the answer." FTFY

Cannot believe this site has devolved to someone bitching about an incorrectly loaded dishwasher.

This comment would be better without that first and third sentence.

Interresting, how to you handle the time pressure that stopping and reading the whole documentation generates? (Pick Spring documentation for example)

Documentation is cheating; you'll never become a rockstar developer that way! Most writers will try to answer the most common questions that a dev will have about their code; this is just as bad, if not worse, than asking them questions yourself. You need to read the source code to truly understand.

I shudder at all the young minds that have been warped by the 'USAGE' statements in man pages; back in my day, we used to have to either guess at which arguments did what, or stare at the devs' custom, mangled argument parsing functions to figure out how to use a program.

LOL, that seems to be the case with node projects today... there are plenty of modules that work great, and have some documentation, but when you want to use something in a different way, you have to dig into it.

If it were related to my job: that is my title was "Sr. Java Programmer", I would read it all, and/or maybe some books depending on my current level of familiarity. Given the size of Spring documentation, I would shortcut to my answer as necessary, but make a recurring appointment with myself to spend at least an hour each week reading the rest of the documentation.

If it were not, that is my title was "Web Administrator", I wouldn't read it at all -- it is not important for me to know Spring. I would ask the java developers for help and move on with my day, instead reading the documentation for jBoss or WebSphere or whatever is relevant.

Chosing what to spend your time learning is a critical function of your career. Imagine if you had spent time learning Flash, Delphi, VMS/VAX, Novell Networking, or any other now-legacy languages or technologies. It's a bit of a betting game, really.

Use your intuition.

I came across this a while back and is what I tell all the newer people that I mentor: https://blogs.akamai.com/2013/10/you-must-try-and-then-you-m...

Some people tend to miss the "You MUST try" part. I am more than happy to take a million questions of the "I tried x, y, z and saw a, b, and c; what's up?" variety. Where it gets frustrating are questions like "I haven't really tried to hunt this down yet, but how do I do <thing>?"

I was just thinking about that article having read this blog. It's a much better rule of thumb than what is being advocated in the title post

Came here thinking exactly this. Lot of us are in situations where time matters quite a bit. After trying some solutions, it is best to ask someone.

People asking how to do something when they haven't tried can get irritating sometimes.

The Akamai post you shared is interesting. Thanks for sharing.

Although, I agree that trying a lot before putting up your problem is an important aspect of a good developer, sometimes, after building up something, an experienced developer might suggest you a solution that makes you wonder if you should have asked for it before.

Like, a game developer, might be able to suggest "Object Pooling", "Dirty Bit" to optimize the game's performance, that a novice might not have much idea about.

IME, you're only really going to immediately get why it's a good idea if you've tried or built the less optimal way first. Otherwise they have to explain the bad way too in order to make their point.

Plus, honestly, you shouldn't be taking their advice as a given. Best practices are always contextual. They're -probably- going to be right, but knowing enough to be critical (even if just quietly, to yourself) is a huge plus.

That's a great article that I hadn't seen. It's a good way of looking at it.

The original post is very wrong because he sees it as an absolute. The trick, as with many things, is that it's a balance to be struck. You'll never learn anything if you ask someone else every small question, and you miss out on the full benefit of everyone else's skills and experience if you never ask anything.

Yeah, exactly. This seems to be what the criticism was, but seemingly the OP morphed that into "never ask for help". No, you should ask for help after you've spent a reasonable amount of time and effort going down the obvious solution paths first.

The power of the human species is that we're able to share knowledge. The undisputed best way to learn is through human collaboration. There's a reason why we've designed our education system with teachers/instructors etc. instead of locking students in an empty room with a text book.

The idea that you learn better if you bang your head against a wall for days is just flat out wrong. Perhaps if the person you're learning from is in competition with you, or is a terrible teacher, or doesn't like you, or is in a company culture that is against collaboration, but if you have a competent instructor, learning via collaboration is the undisputed best way to learn. That teacher can (and should) explain to you all the dead-end paths that you would have banged your head against yourself, in a matter of minutes, and you'll get all the same benefits out of it as if you had done it yourself.

Woah woah woah.

Moderation?

Are you mad?!

Fortunately, unlike the original suggestion, I think this article is actually a bit more fair, even if the headline is still click-baity.

Is resilience good? Of course!

Should you go for help every time you encounter a challenge? No, that'd be silly.

But never ever asking for help is still terrible advice.

Fortunately I don't think that's what the author is actually advocating, instead advising the obvious: don't use your co-workers as a crutch, but certainly use them as a support group when you're truly stymied.

But, of course, that's just common sense, and common sense doesn't a click-baity blog post make. ;)

I think "never ask for help" is bad advice -- it's actually about asking good questions, not never asking for help.

What makes a "good question" is a topic unto itself. But if you make sure you have a good question first -- sometimes you realize that in formulating the question you've solved it for yourself anyway (rubber ducky), or know how to get the answer from documentation (or... google) without bothering a co-worker. (And yeah, part of a good question is being able to say "I tried X and Y first, and they didn't work because Z")

I think "learn how to ask good questions" is way better advice than "don't ask for help", with some of the same outcomes in terms of your own learning and resilience as well as reducing frequency of asking for help.

And I think nobody should ever use the phrase 'rockstar developer' ever again.

sometimes you realize that in formulating the question you've solved it for yourself anyway

This has happened to me countless times.

I think there's a lesson here, but it's not "Don't ask for help, even all the time."

To the contrary, I'd say something like: Ask yourself for help, first. If that didn't work, you might have a worthwhile question. This also requires you to be open to other people asking for help, and my greatest worry about this rule of thumb is that it makes people disinclined to help _each_ _other_. We're not cogs, human teams have value for good reason, and it's not just design or architecture decisions.

Sometimes we need to be "sounding boards" for each other.

Years ago, I'd get pulled into ridiculous flamewars on open-source mailing lists when I had run into a relatively simple issue. I was annoyed that each time I asked for help - the type of help I often provided myself - that inevitably whomever was paying attention to the list at that time of day would jump all over me and treat me like a n00b. I didn't want to come out restating my entire experience with a project before answering a question, but these flamewars aside, I found that often people would help anyway, but that sometimes the answers made me feel dumb.

This came down to asking well-informed questions. I would try to predict the clarifying questions that I would have, esp at my most cynical or annoyed time of the day, for someone else. I would end up with a page and a half describing my question, something some people might TL;DR, but probably wouldn't solicit a bunch of one-liner insults.

Ninety percent of the time, in composing such a message, I was able to answer my own questions. Unfortunately, that means that my presence in mailing list archives has my worst work, and that much of these messages never saw the light of day. I would just have an "ah-HA!" moment, along the lines of:

-- "And then even though I already tuned the kernel settings as recommended in [2], and installed the proper dependencies from the PP --- OH SHIT! I'm using the default packages and not the ones from the PPA."

Discard Draft Problem solved. ;) --

In these situations, I actually avoided asking other people for help by asking myself a question, but if I had been able to complete explaining my problem and my confusion to my satisfaction, I'd simply hit 'send'.

Dealing with people in-person is a little different, that's where the 'sounding board' comes in. If you respect your teammates, you can just kind of spitball a little about, "Hum this is really frustrating, are you kidding, Feature X in Package Y is implemented with a Dorner-Lannister sort? The Fuck? How stupid is.." And an intrepid teammate may say something like:

-- "Yeah. I mean. I'm not sure that's the decision I would have made, but I spent a good two days fighting with this exact problem a couple of months back, let me find you a mailing list thread. It will make you furious, then you can go outside and have a walk. Then come back inside and do it that way, so that you can get on with life." --

Or such conversations may be less existential:

-- SMASH SMASH SMASH keyboard "What in the actual fuck?! I can't stand cut! How has civilization progressed so far without a better way to grab output separated by variable lengths of spaces?"

"Bro, do you /even/ awk?" --

:-P

I think this is a dangerous and terrible rule of thumb that will definitely damage culture. It's such an egotistical view that you're so smart, you don't need anyone to help you ever. I would rather work with a bunch of "non-rockstars" than a bunch of assholes. IMO, this deification destroys values like modesty and is generally counterproductive.

If you're really looking to save everyone time, a good balance may be the optimal way. I've seen success with better mantras such as "if you can't find the solution within 10-15 minutes, ask someone". This prevents you from bothering people with Google-able questions, and it saves you from wasting half the day because you were too reluctant to ask the person next to you thanks to your fragile ego.

Not asking for help / debugging yourself helps you make a leap to a better understanding of the language. You will certainly remember the next time you see that bug and over time, you build up your own knowledge so you have ask for help less. Asking for help is just short-term greedy: solves things now but doesn't help you (or your company) in the long-term.

Not asking for help / debugging yourself helps you make a leap to a better understanding of the language

Or it'll mean that you repeat the same mistake over and over because you wrongly believe that you understand something.

If you don't check with a third party you have no way to know if you're doing things the best possible way. Or even the right way.

*If you don't check with a third party you have no way to know if you're doing things the best possible way. Or even the right way.

Wrong. How do you verify that the third party is correct?

I consider that to be asking for feedback, not help.

I feel that when he makes the claim of "never" is where you are having a problem. You really should try to figure things out on your own because that is the only way to are going to permanently attach the solution to the problem. When others help you, the solution doesn't always stick and you are left coming back when you run into something similar months down the line.

Now if you are banging your head into the desk for multiple hours, then maybe you should have asked for help. But as he points out, there are situations where (as a tech lead for a startup) you aren't going to be able to ask for help.

You are taking what he says as "I'm so smart I don't need help" instead of seeing it as "I may not know how to fix this now, but I am determined to figure out a way". You are attaching a very negative view instead of seeing it as resilience in the face of a problem.

The argument that not asking for help results in resilience and therefore debugging prowess sounds like an X/Y problem to me. If the real goal is to have better debugging skills, then more direct advice might be "understand fully why your solution didn't work" instead of "don't ask for help".

However, it's good advice if we think about just being competent instead of being a smart deified rockstar.

If you are handed a spec and documentation for all the APIs you will need to use, and instead of reading or thinking about anything you just demand that I walk you through it one step at a time, all day, there is a plain old competence issue and it is wasting time.

Often it really is better for someone to just try to figure it out for a while, even if it takes them a lot longer. You don't learn with people telling you every single little detail.

I think others have touched on how ridiculous this advice is already.

What stood out more to me though is that this person didn't get feedback until they applied for a promotion. Knowing how and when to ask for help should be one of the first things you learn at a new job or company, or as an engineer in general.

> Spend more time trying to figure things out for yourself before asking for help.

Isn't this obvious and don't most developers want to do this?

I work with someone who basically refuses to figure things out for himself and goes from person to person trying to get us to tell him how to develop something. Eventually he throws so much cruft at a project until it works.

It's been years and he asks the same questions. I've told the others I work with to stop helping him. Grow or die.

http://thecodelesscode.com/case/100

There's a difference between not asking for help and asking for too much help though. Frequently a team member can save you hours by giving you a few minutes of help e.g. maybe they know about a useful library for something when you were about to implement your own one. That's not the same as asking for help every time within minutes of encountering a tiny problem like your example though. I agree that's not a good thing to do.

You are correct, and this is a pervasive problem. When I was a tutor, I learned to answer their questions not directly, but showing them how the material they already have can supply it. "Well, let's start with the index, <turns to back of book>, ok, let's read chapter four from the top, together ..."

So the same thing could be applied, "Lets go to your desk, let's look at the manual together, why don't we google together" etc.

The lesson to the student is, "I could do this faster myself", and they'll stop asking you unless they really need it.

I was told early in my career that I could use to ask for help more often. I think that was actually good advice for me since the other team members all had 10+ years experience so I obviously didn't know everything at 23. To each his own I guess. And I can't believe that developers self reference themselves or others in the field as "rockstars" - I honestly thought that was a layman's term.

Neither extreme - asking for help with everything, nor asking for help with nothing - is good.

You don't want to distract your coworkers to the point that they can't be productive. But I've been in the situation where the right question can take 15 seconds of my time and save you days, judging by how long it took me to figure out when I ran into the same problem. All because of some arcane, poorly documented bit of domain specific trivia. And that's when I had the advantage of being the resident expert in the domain!

Should it be documented? Maybe. It might be! But it's missing the keywords you'd look for, it's out of date because the domain is a moving target, and at the top it says "poke MaulingMonkey to see if these docs are up to date" - so you'll be checking with me anyways, right? The docs are there to save me the trouble of re-explaining everything from scratch - I'll update them (again) and let you work through them. For the simpler stuff, it may be easier to just explain.

For bonus points, you can ask questions while minimizing disruption. Asking questions asynchronously (e.g. via irc/email) and letting them respond asynchronously (no 'did you get my email' 5 minutes later at their desk) is a great way to do this. I can respond when I'm compiling, when the 15 seconds to respond "the answer is 42" / "dunno, I can swing by in a bit if you need a second set of eyes" / "dunno, ask <relevant domain programmer>" isn't going to make me forget what I was working on.

I do not consider myself a rockstar anything. But I like to figure things out, sometimes by reading the man pages (what a concept!), or consulting the Google, or a modest amount of trial and error, er, iteration. If none of these work, then I will ask.

As much as I like teamwork, my team is entitled to a certain level of effort by me to strengthen my skills, which seems best satisfied by a little non-intrusive research on my part.

This is such a bad piece of advice and his story just frames it to make it look sensible.

As "buckbloa" mentioned, "> Spend more time trying to figure things out for yourself before asking for help. Isn't this obvious and don't most developers want to do this?"

The author paints it as if it is a categorical thing but it really isn't. You need to spend time understanding your problem and trying to figure things out. When you go to ask someone for help, it is important to demonstrate that you've at least put some effort into understanding the issues involved. It saves the other person time and effort when you do that and make you not look like a total slacker.

"wyc"'s mantra is good rule of thumb. I'm totally with him on not wanting to work with "rockstars" and other egotistical people. People work in teams for good reasons. This isn't elementary school where they make you work on a team just for the sake for being on a team.

Ironically, at my yearly review at MS I've got negative response from my manager that I'm not asking for help. If I remember remember correctly he used the word "silo". Second negative response was that at meetings I give solution to the problems, instead of collaborating with team members and help them to come up to solution as well.

I agree with the underlying message of this article -- that there's tremendous value in being persistent when debugging issues you're having. However, trying to present it as some kind of mantra ("never ask for help") and using loaded terms like "rockstar" is misleading and foolish. When developers begin to think of themselves as "rockstars", or when they adopt mantras like "never ask for help", this only encourages them to develop an unhealthy attitude about themselves. As jquast touched on below, there's nothing that will undermine a team's collective productivity quicker than ego problems.

I reject this terminology. Anyhow junior developers should ask for help. And senior developers should ask for help too when they're actually stumped. Let's not suffer in silence and make a mess to clean up later.

This can be overdone too. It depends on whether the junior developer has even tried or thought about it before asking for help. If the rule is to ask first and always, the junior developer might as well not be there because the senior developer is doing all the work awkwardly via the junior developer, and the junior developer is not learning how to do anything except say "what now" to the senior developer all day.

I distinctly remember the day at my first job out of college when my boss realized that I didn't know how to effectively use a debugger. He proceeded to sit down with me and demonstrate proper use of breakpoints, conditional breakpoints, etc. I didn't know how much I didn't know. There were many other interactions with coworkers along these lines. I was great at what I'd done, but had no idea how much existed outside my narrow range of experience.

For the next click-baity title, I suggest something along the lines of "Rockstar Developers Collaborate More Than They Question".

The only thing I would add to the article would be to read about your craft... Working around problems is part of the solution. Being able to think around more complicated composition, or design issues is a bigger thing. The former will get you working code that may be horrible to try and maintain, the latter will get you working code that is easier to maintain.

A great read, and kind of follows the direction I'm usually driven in myself. I may have to push a link to this as a comment in some classes of questions on stack overflow.

I think it's much better to say "Don't ask for solutions". There is enormous benefit in figuring out a solution, and flexing those mental muscles is really important, but I think that it's also very reasonable to talk with a mentor or co-worker about a problem and be given some tools (mental, software, or otherwise) to help work through a solution. I think that good mentors and senior developers default to this approach even when they are asked for solutions, at least those who are invested in growing the capabilities of their teams.

Looking at my personal experience, I'm one of the two senior developers on our 10-person team, and I'm typically the person that our junior and mid-level developers approach with any questions they might have. We have two developers on our team who started about a year apart, both of them have networking backgrounds and had no personal or professional development experience before joining our team. Our newest developer who is very motivated to grow and learn and wants to figure everything out for himself- give him a problem and he'll run off and you won't hear from him again until he has a solution and a war story about the three other approaches he tried before he arrived at this best of all solutions. The other developer did and still does ask for a lot of help, but the question is always "how do I learn about this".

The first developer is still awful. He constantly falls victim to the problem of unknown-unknowns, and while his solutions are frequently clever they often are completely obviated by a small bit of knowledge about computer science, or of a common tool, or of a common development practice. Eventually when you see what he's come up with you can point out how something that already exists could have solved the problem, and there's even a bit of benefit to his understanding why things may be done in a certain way, having run into some of the problems they solve himself during his implementation- but the overall rate of progress is incredibly slow and as often as not after investing so much effort into his solution he fails to see why another approach would be better. The second developer has grown into a very skilled developer remarkably quickly, and I think it's because while they both have the tendency to shave yaks and crawl down rabbit holes in search of knowledge, the second developer has been willing to ask what the most profitable yaks to shave would be, how to best crawl down the deepest rabbit holes, and where to find the obscure bits of knowledge that you might not run into without the arcane search phrase incantations that seem to only come about with a lot of experience and a bit of luck.

I actively encourage people to ask me questions. I never directly tell them how to solve it though, I give them helpful nudges towards the answer so that they can learn it and solve it themselves. Seeing the moment when someone figures it out is great.

If someone asks me a question looking for a discussion on how something should be done, I'll gladly have a discussion as long as it's not simply me telling them how to do it.

As other commenters have said here. Asking questions is good, asking good questions is even better.

You didn't get a promotion because one guy said something bad?

That doesn't sound right... I mean sure not everyone is going to like you at a large company like Google.

Ignoring that fact, this article is actually really good.

This is not always correct. if you are stuck on something, you should always ask people even if it is just describing the problem to them and then you usually have a solution before you finish the description, but if you don't. They may be able to lead you in the right direction.

I believe the title is misleading. And contains the childish 'rockstar' moniker.

Other than that, it's actually pretty good. People underestimate the value of spinning your wheels at a problem. Usually, you end up figuring out a lot more than you initially though. Even if you do end up having to ask for help - at least you know what NOT to ask.

The thing about wheel spinning is that you'll eventually bury yourself if left unchecked.

If you do it often enough, you should also learn where the point of burial is so you can avoid it.

> I was stuck in the public forums along with everyone else.

So... still asking for help. :b

I think the best phrasing of the applicable advice might still be in the original feedback:

"Spend more time trying to figure things out for yourself before asking for help."

This isn't the same thing as the title (though, as the author may well know, the chosen title has certain properties that probably make it superior along other axes than how well articulated the advice is).

I also got my first job out of school as a junior developer at a local company that promised they would provide great mentorship. I was so excited and asked a lot of questions while there. Unfortunately, I soon realized my team members did not that :D.

In school, professors encourage us to ask questions. In the working world, I guess you are supposed to figure out answers to your questions.

I learned coding without books or the Internet and none to ask questions. I did have Internet at school though, where I printed tutorials and source code.

Not being able to find answers forced me to think by myself and do trial and error. I believe that made me a batter coder.

I actually feel a bit lazy now when I look up stuff on the Internet without even trying for myself first.

This essay follows the format of "Title Phrased in Absolutes", followed by an essay that tempers the absolutes greatly, advocating for a reasonable middle ground.

Please don't do this. A much better title for this essay would be "Good Developers Know When to Ask For Help".

The mere act of asking for help can help you realize the answer. It's called rubber duck debugging. http://en.wikipedia.org/wiki/Rubber_duck_debugging

This makes me wonder: is it also considered a bad thing for rockstar developers to look on the internet (stackoverflow etc.) for hints or solutions?

Of course it is. Rockstar developers invent the solutions that lesser developers have to look up later.

Not unless you make a new question.

Can we please drop the "rockstar" crap? You are writing code, not performing live in makeup and snorting lines off of adoring groupies. I don't care how great you think your Node module is, you are not the Jimi Hendrix of 2050.

And this kind of thinking affects your values. You are supposed to do a good solid job that results in something useful, not impress people with your riffs or your artistic vision. Nobody is impressed except you. Make the tests pass and fix shit when it blows up and GET OVER YOURSELF

"I hope I’m not narcissistic, or self-centered"

Following sentence:

"I wasn’t always a decent software developer."

Like in football, teams don't run to win, then run when they're winning.

Reply on news.ycombinator.com