
Why Rockstar Developers Don't Ask for Help - fasterthinker
http://thinkfaster.co/2015/02/why-rockstar-developers-dont-ask-for-help
======
jquast
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.

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

~~~
Chlorus
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.

~~~
tracker1
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.

------
phillipuniverse
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...](https://blogs.akamai.com/2013/10/you-must-try-and-then-you-must-
ask.html)

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>?"

~~~
shubhamjain
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.

~~~
geoelectric
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.

------
jrochkind1
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.

~~~
current_call
_sometimes you realize that in formulating the question you 've solved it for
yourself anyway_

This has happened to me countless times.

------
wyc
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.

~~~
tashoecraft
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.

~~~
wyc
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".

------
ernestipark
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.

------
buckbova
> 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.

~~~
jquast
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.

------
bsdpython
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.

------
MaulingMonkey
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.

------
squozzer
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.

------
hangonhn
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.

------
olkuli
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.

------
davesque
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.

------
logn
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.

~~~
pekk
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.

------
O____________O
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".

------
tracker1
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.

------
rebeccaskinner
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.

------
LukeB_UK
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.

------
dubcanada
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.

------
outworlder
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.

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

------
wwweston
> 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).

------
namelezz
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.

------
z3t4
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.

------
scott_s
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".

------
brobdingnagian
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](http://en.wikipedia.org/wiki/Rubber_duck_debugging)

------
amelius
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?

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

------
pekk
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

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

Following sentence:

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

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

