What to do when you are faced with programming task that you have never done?

Question

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.

I have never done any of the created tasks and I do not know how should I proceed.

For example one of tasks created is creating a generic error handling mechanism for the entire application.

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

Answer 1

There are several things you can and should do to prepare for the task:

• Think about the problem and draw some diagrams. Make sure that you know what the problem is that you are trying to solve.
• 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.
• Lastly, and this might the most important, talk the other people on your team to get more clarification and direction on what to do. I always want to see new engineers come ask for guidance on projects.

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.

This is why I am an engineer; I love to figure out new stuff.

Never stop learning new things. Learning is what makes you better.

Answer 2

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 just to get momentum going. Some folks prefer the hardest task so the 'hard work' is out of the way. I have found that 'simplest task' generally works better as you are just looking to get some momentum going and I have seen 'hardest first' lead to projects stalling before they get any real momentum.

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

Answer 3

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.

Personally, I would push back on this notion. Writing "generic" anything before implementing actual user requirements is almost always a waste of time. And since it's generic, by definition it is not specific to your company or application, so there is probably something already available that will meet about 95% of your needs.

But since you are the junior member, pushing back may not be a great idea. So you need to talk to the people who think they need a "generic error mechanism" and find out what services they are expecting this mechanism to provide. Then search the net to see if something already written will suffice. If you find something, propose simply using it. They probably won't agree, because anyone who asks for a "generic error mechanism" is likely suffering from a bad case of not-invented-here.

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.

Answer 4

I think you're suffering more from anxiety than a skill deficit. At some point, wasn't everything new? Have you ever been given a task and not been able to solve it to some extent? You're paid to figure things out.

Utilize Your Team - If you're on a good team, you should be able to ask for help. There are things you'll know that even the most senior won't know. Asking for help isn't a sign of weakness (no more than running to some question site.).

Search - A web search on generic error handling came up with nothing? You may not find an entire solution. You're going to have to work on it and make it fit in your app anyway.

Prototype - Change your perspective on the task from production to prototype. Just get something to work and build from there. When you get it to the point you can use it, then start thinking of it as production. Now you won't see the task as something you don't even know where to start.

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.

It's the old joke about doctors still "practicing" medicine; they don't have all the answers either.

Answer 5

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.