The single largest factor in what is holding me back from being a stellar developer is my reliance on others. I feel like I ask too many questions because I fear the consequences of breaking everything and holding everyone back. So I'm overly cautious by asking so many questions that I basically get the answers after enough questioning. I've recognized that's bad but I want to stop it. Part of it comes that there are times where I simply don't know the code (either it's a branch I've never worked with or it's a brand new product), but I want to rely on others less. To preface, these kinds of questions are not the ones about generic patterns or languages: usually my questions revolve around how we do code at our company, and how we get things to work in our ecosystem. I want to be able to take specs and roll with them without having to feel like I need to get help every step of the way. Is this normal? Have you been through this, and if so, how did you get over it?

  • 1
    Maybe this is just a cultural / language thing ... but what makes you think that you will ever be a stellar developer? What makes you so much better than the 99% of other new developers? – Stephen C Apr 22 '11 at 5:26
  • 5
    I'm not one now, but I want to be. I always strive to learn and improve. Most people are afraid to even admit they have a problem. I want to find my problems, acknowledge them and tackle them. The best in any field strive for continuous improvement, and I aim to do the same. – acconrad Apr 22 '11 at 5:32

I see some new developers come into a job and immediately feel inadequate. I did the same early in my career. I think there's at least two major issues most smart guys need to overcome: time perception and their own natural ability.

Time Perception
Smart guys are used to solving problems relatively quickly. I remember being aghast when I had to spend an hour on a single calculus problem. Spending 60 minutes on a problem is nothing anymore. Those days are over...bury them and say goodbye. The complexity and size of most software today is outrageous. People don't understand all the tools they have to use to get things done any longer. One of the key men of the JavaScript language, Douglas Crockford said,

"Misapplication of standard tools...is the new standard."

There just isn't enough time in the world to learn all the dev tools.

Natural Ability
Your intelligence, problem solving ability and natural skills got you into the whole developer gig in the first place. There's just no room for anything less in this field. So what do you do with 100,000 lines of code, languages and frameworks you barely know, design patterns and paradigms people are pushing at you, guys who know most of it like the back of their hand, customers who want it yesterday, and a boss who expects the world of you? Freak out as your natural ability fails.

Yea, that's normal. I still freak out with some of the stuff that gets thrown my way.

What can be done?

Its time to improve those natural abilities with good old fashioned hard work. Work on breaking problems down into smaller parts. And realize that unlike a lot of things you may have done in the past, these problems do take a great deal of time to solve. So don't give up after just 15 minutes of examining a complex problem. Instead, break the problems down and stop watching the clock. After a while, 30 minutes of working with a problem really isn't what it used to be.

Self confidence plays a big role in ones ability to self-govern. So does the team, especially the more experienced seniors. It is good to be careful about not breaking things, but this doesn't mean you need to ask a constant stream of questions.

Instead, make use of the source control. As long as you don't checkin a change you can't break the main product and make other devs angry. Also, make changes that you can understand and test and be sure to test them well before checkin.

I even have a little test project that I use to write one-off, simple programs so I don't have to worry about all the goings-on in the main application.

Finally, remember that every decision comes with some level of give and take. There is no moving forward without making some kind of sacrifice at some level. Don't strive for perfection, strive for awesomeness and be mindful of your actions. Because you always need to be prepared to take criticism and explain your ideas and why you made them. Be proud of the decisions you make. Even when they are wrong there is much to be learned.

  • 2
    +1 work at it until you give up. I've sometimes spent 2-3 days solving a single problem. As for breaking: try TDD, or at least writing unit tests. – ashes999 Apr 22 '11 at 3:32

The first thing is don't be afraid of asking questions. I've seen even senior architects ask questions about code. They're not expected to know everything; they're expected to know enough to get the job done, and to be able to figure out the rest.

Probably the best tactics would be:

  • Learn how to research on Google. You can find answers to almost anything with a little investigative work. Stack Overflow works wonders for those hard-to-solve problems.
  • Learn how to debug. I've spent hours stepping into quirky, deep enterprise code, only to find variable X is 3 instead of 7. Being able to read code and debug is probably the single best way to become autonomous.
  • Not that I'm a special flower, but my problems are not on the languages. It's not on how to do things in my language. Most of my questions are very company-centric: it's on how to do things in the domain specific to our environment at our workplace. They are the things you can't Google, if you will. – acconrad Apr 22 '11 at 3:17
  • 3
    I understand completely; I was in the same situation for three years. Bullet point #2 is the answer: Learn to debug. People don't remember details often; debugging is the key. – ashes999 Apr 22 '11 at 3:19
  • 1
    I agree. Keep asking questions, until you know more answers than the people around you. GO down and talk to the QA team until you can discover bugs as well as fix them. Google is your expert buddy; use him extensively. Some day you'll find that you send a questioning e-mail and find the answer yourself before the reply comes back. – Andy Canfield Apr 22 '11 at 7:15

Don't be afraid to ask "big picture" questions

I used to try to find the tiniest question I could ask and still be able to proceed with my work, out of fear I would be considered incompetent if I asked broad questions that everyone else seems to know the answer to. I didn't understand the difference between ignorance and incompetence. Ignorance just means you haven't learned something yet, and is perfectly acceptable as long as it doesn't persist. Pretending not to be ignorant is much worse.

If you're finding that people's answers are only taking you so far, you need to ask them to teach you to fish instead of handing you another fish. Ask how your part fits in with the whole. If your question seems as basic as "what is SQL anyway" ask it sooner rather than later. You might look a little foolish now, but will look a lot more foolish later.

Give yourself a waiting period

Don't ask questions as soon as you have them. Depending on the complexity, give yourself anywhere from a half hour to a day to try to figure it out on your own. A lot of times you will solve it yourself. If not, you will be able to tell your colleague what didn't work, which can help him give you a better answer.

Also, if your colleague doesn't know an answer off the top of his head, pay attention to how he arrives at it. A lot of times you don't need as much help as you think. If I don't have time for a question, I will often point someone in a vague direction and tell them I will come follow up when I get a minute, and they have usually solved it by the time I get there.

Throw away some drafts

Sit down and put down everything that comes into your head and then you're a writer. But an author is one who can judge his own stuff's worth, without pity, and destroy most of it.
—Sidonie Gabrielle Colette

Don't be afraid to write code that will never make it into a release. The more experience you get, the sooner you will be able to tell you're going down the wrong path, but going down the wrong path still happens. A lot of times the value of a solution isn't apparent until you have seen it done the wrong way first.


Self-Sufficiency would come with

  • Increased experience and exposure in the domain.
  • Increased observation skills and analytical skills to comprehend existing systems and their behavior,dependencies.

Asking questions frequently would risk showing you lack both of these.

If you change your domain,technology,platform,language you are back to square one(Nearly, not counting for your increased ability to tackle similar issues and transferable knowledge)

Not asking questions when really needed would waste a lot of valuable production time.

It might work to your favor in dropping a word about your assumption on the extent of possible damage if you do it wrong. or what You Think might break to get an actual assessment of your assumptions.A lot of times it might let you uncover points and angle you have missed.

Being cautious is good.But its Best you start determining the Nature of your questions. Its best if you write it down on paper and examine its difficulty/worthiness.

  1. Is it something you can figure out with google/forums or by working on it for a longer time
  2. Is it something you can get away with or fix without much cost if you mess up?

I would say to look at the things you are working on and start making decisions by yourself (keeping within the application specs of course). By now, you should have a good feeling for what is a far reaching change and what is a simple change. Start with the simple ones. If you think what you are doing is right, do it.

You WILL make mistakes and those are invaluable. Learn everything you can from them when they happen as they are what will make you do a better job next time.

Once you are comfortable with the smaller decisions, start making the larger ones. You will need to decide how far to go with this based on your project/environment/team.

That's the decision making side. The other thing you need to do is to keep feeding your brain so that it can help guide your decisions. Follow sites that cover your technology. There are online tutorials of almost everything out there covering everything from the simple to the bizarrely complex. Don't be afraid to ask people why they make certain decisions - as an information seeker, not to be confrontational. Most people are more than happy to explain things and you can learn quite a bit from them.

Once you have the technical knowledge, the rest is wisdom and confidence and those come with experience.


When I was a newbie asking questions I would always try to get a partial answer to the thing myself, using the tools that were available; and when I got as far as I could, I'd figure out exactly how to phrase my question so as to be as clear and concise as possible, under the assumption that the person to whom I was going for help was busy. With this bit of prep, I don't think anyone ever minded me asking them questions, and in fact I got the impression that they enjoyed it. Later, when I became the domain expert, I also enjoyed helping people who made it clear that they respected my time.

The other thing I did was, every day, pick through the system's architecture. Other posters have commented on what a massive undertaking modern systems are, how hard to come to terms with. So I would go on tours of the code: start at some sensible entry point, then trace through it, jotting notes to myself about how it worked, asking questions that I would sometimes answer for myself, sometimes ask other people about. This kind of overarching familiarity and domain competence takes time, but you can speed it up; and the more you do, the sooner you'll be self-sufficient in the ways you want.

Not the answer you're looking for? Browse other questions tagged or ask your own question.