Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Rockstar Developers Don't Ask for Help

thinkfaster.co

Post reply on HN
Print view View original

51–60 of 65 posts

Re: Why Rockstar Developers Don't Ask for Help

#51

Post by Chlorus »

cfontes wrote: post #43
jquast wrote: post #26

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…

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.

Re: Why Rockstar Developers Don't Ask for Help

#53

Post by 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.

Re: Why Rockstar Developers Don't Ask for Help

#54

Post by geoelectric »

shubhamjain wrote: post #24
phillipuniverse wrote: post #4

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…

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…

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.

Re: Why Rockstar Developers Don't Ask for Help

#55

Post by jquast »

cfontes wrote: post #43
jquast wrote: post #26

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…

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

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.

Re: Why Rockstar Developers Don't Ask for Help

#56

Post by jrs235 »

shkkmo wrote: post #40
jquast wrote: post #26

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…

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 p…

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.

Re: Why Rockstar Developers Don't Ask for Help

#57

Post by 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 " isn't going to make me forget what I was working on.

Re: Why Rockstar Developers Don't Ask for Help

#58

Post by [deleted] »

wyc wrote: post #3

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 t…

[deleted]

Re: Why Rockstar Developers Don't Ask for Help

#59

Post by zzalpha »

phillipuniverse wrote: post #4

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…

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

Re: Why Rockstar Developers Don't Ask for Help

#60

Post by 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.

Post reply on HN