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?
|
|
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
There just isn't enough time in the world to learn all the dev tools. Natural Ability 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. |
|||||
|
|
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:
|
|||||||||||
|
|
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
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
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.
|
|||
|
|
|
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. |
|||
|
|
