Take the 2-minute tour ×

I started my career as a .NET developer 3 months ago and after a long training plan on diverse technologies, patterns and concepts the developers who were supervising me have decided that I am ready to join one of the many projects the company handles.

I am very excited to finally be able to start coding. The team I have joined is rather small for now because were starting with a new project, which is great because I get to be involved in the entire life cycle of the project. It is a web based SPA project with a backed that uses ASP.NET MVC/ASP.NET Web API and in front-end the Durandal framework and related libraries.

My problem is that after having a meeting with my colleagues and establishing the tasks and estimations for the next month I find myself in a position that I do not know if I am capable of taking on any of the tasks.



How does one usually proceed when faced with tasks that he has never done?

share|improve this question
This may feel unique to programming, but all of the first couple jobs that most people do, feel this way to them. They didn't hire you because you knew the answers -- it's an entry-level job! -- they hired you because you would be able to figure them out. –  Marco May 21 '13 at 20:35
+1 for asking the right questions and willing to learn! –  oɔɯǝɹ Feb 7 at 20:16
add comment

5 Answers

up vote 52 down vote accepted


  • Do research on what you are trying to do. The internet is a valuable source of information. I am not saying ask Stack Overflow -- I am saying do research on how other people have already solved a problem like yours or approached it. This what google came up with: "Exception Handling as a System Wide Concern". Personally, I always try to learn from others.

Not knowing how to do something will never really end. Every day I run into problems that I have never tackled before. Having the ability to figure out how to solve new problems is extremely important. Even old problems are never totally old -- in programming, there is almost always a new twist or a request for your solution to work in a new or different way.



share|improve this answer
add comment

There is no perfect solution, but some things that might help:

  • Break tasks down into the smallest possible units -- break them down until you have things you can do.

  • Restate the immediate task or problem at hand to make sure you really understand it. Then do some analysis and repeat.

  • Pick the simplest task first, even if it seems too simple.

  • Ask for help in selecting the right task and approach to get started.

  • Seek out a mentor that can give you constant (ideally daily) feedback for a week or two.

  • Ask a lot of questions but focus on being polite to your teammates. Always ask if they have time, and pay attention to the usual verbal and non-verbal signs that they don't have time right then.

  • Keep a running list of issues you are encountering and then either in daily scrum or at a regular time of your choosing, go through them with others.

  • Don't be afraid of asking the most basic questions. Assumptions by others can be hard to challenge but if you can't proceed with what you're given you have to question again.

  • If you know the objective, do as much as you can until you get stuck and then post the progress and question on Stack Overflow.

share|improve this answer
I mostly agree, apart from "pick the simplest task first". From a project risk perspective, it may be better to do the hardest essential tasks first. It is better to learn early on if the hard parts are actually too hard. Then you can (maybe) backtrack to a simpler design ... or renegotiate the requirements. –  Stephen C May 19 '13 at 3:09
I find that the main issue at the beginning is just getting starting with something, anything and check it off just to start some momentum. Tackling the hardest part first has a much bigger risk of not getting started at all has been my experience. –  Michael Durrant May 19 '13 at 10:50
add comment

Of course you have no idea how to write a "generic error mechanism". No one knows how to write a "generic error mechanism" until some requirements are defined. It sounds like all you have is someone's notion that a "generic error mechanism" is somehow required to start this project.



If that fails, he next step is to define an interface for the error mechanism and get it approved by the stakeholders. After that, implementation will probably be trivial.


P.S. There are some programmers who think that the way to start any project is by writing a "platform" to provide all the common services that will be needed by the application modules. This usually devolves into months of trivial work reinventing stuff already readily available for free. Until you hit the performance limits of the available solutions, there is no reason to write "platform" services. Nor is there any reason to write wrappers around existing APIs. If you refactor continuously, the exact wrapper required by your application will magically appear.

share|improve this answer
I think I spend possibly even a majority of my time removing functionality people thought they needed, when in fact it turns out it was only mildly handy and problematic when it comes to quickly adapting to new needs. Your warning is spot on! –  Eamon Nerbonne Feb 9 at 13:48
add comment





Get Over It - Only doing things you know how to do will get boring. It also leads you into a trap of just brute forcing some solutions by repeating the same things over and over (If you like repeating things, go work on an assembly line.). Be prepared to make mistakes. Those that tell you they know everything, never ask for help or do searches, is just lying.


share|improve this answer
I agree with utilizing your team. Would they be open to paired programming for a time to get you up to speed? –  neontapir Feb 7 at 21:28
Not all teams/devs are into the idea of pair-programming, but that doesn't mean you can't sit down and look over their shoulder or vise versa. –  JeffO Feb 8 at 20:20
add comment

Rejoice in that you aren't doing something you've done a hundred times before. You've found the joy of software development (for me, anyway, YMMV) - learning how to drive while you hurtle down the freeway at extraordinary speeds. This is the kind of thing a great developer lives for and excels at.

My personal process is something like this:

  • Research. Find out if and how this problem, or a similar problem, has been solved before. Even if you can only find information on solutions for different languages or platforms, it can still be extremely informative.
  • Prototype. The absolute best way to do something right is to do it wrong first. Build a solution, making everything up as you go, based on your research. Try to make it conform to the major requirements, giving consideration to ancillary requirements. Don't bother making it pretty or perfect or extensible or flexible or performant, just make it work. Take notes of lessons learned - what worked, what didn't, potential roadblocks, etc. Then throw the code away. If you're worried about looking a fool for taking too long, do this on your own time. It benefits you personally, in terms of knowledge.
  • Design. Combine your outside knowledge (research) with personal knowledge (prototype lessons learned) and formulate a design of what you think would be the Right Way to do it.
  • Cooperate. Find a senior team member, show them your proposed design, get feedback. Show it to someone else, get their feedback. Refine your design.
  • Iterate. If you're still unsure of your solution, make sure peer reviews are part of your iteration cycle. Bring your implementation to a senior team member regularly for feedback.
  • Be happy - you've advanced your knowledge, and your career, and you got to do something new and interesting instead of something old and boring you've done a thousand times before. Try to make your next project an even greater challenge.

And lastly, don't worry too much about appearances. As a dev team manager, I'd rather have someone who can prove they can learn whatever they need to learn as they need it, than someone who can prove they already know the one thing we're trying to do right now. The former will be more useful for whatever we end up doing tomorrow, or next month, or next year.

share|improve this answer
add comment

protected by GlenH7 Feb 7 at 19:16


Would you like to answer one of these unanswered questions instead?
