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 we're 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 back-end 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 of she has never done?

Basic research

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.

Cut yourself a break

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, or say that they never ask for help or do searches, are just lying.

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

Redefine the problem

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 percent 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, the 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.

Find more answers or leave your own at the original post. See more Q&A like this at Programmers, a question and answer site for professional programmers interested in conceptual questions about software development. If you've got your own programming problem that requires a solution, login to Programmers and ask a question (it's free).

As a web developer, I am constantly tasked with figuring out ways of doing things I have never done before. One of the things I have found is that you can't be afraid to try and fail. Sometimes when working on a problem I will have to try three, four or more different solutions before I find one that will work. Some people would give up after their first try, but you can't, because sometimes only with multiple tries will you find the solution you are looking for.

Also, asking your team for help if you get stuck is always an option as well. Someone else may have had to solve the same problem you are working on in another project.

Speaking of other projects, one thing I like to do when struggling to find a solution to a problem is do a search on my company's SVN repo to see if anyone else committed code for another project that does something similar to what I need to do. Sometimes this will turn up a result and will give me a head start or at least a point in the right direction.

On essential skill is being able to break down a problem into a number of smaller steps. Diagrams are helpful for a high level overview of what you want to do. Pseudo-code is another good technique to help you flesh out methods. With .NET and Java you can doc methods, if you write these before actually writing the methods themselves it will makes you think about what that method should actually be doing.

As for the third answer, I have to agree with the comments about anything that is termed Generic. There should be a clear set of requirements about how error handling is done. I fear what will happen in this example is something similar to the "inner-platform-effect".

As an indie game dev starting essentially from knowledge scratch, this is basically my whole life. The biggest takeaway I've found so far is the fact that nobody is an island, especially in 2014. There's a good chance that somebody, somewhere has done something similar to what you're working on. And it's usually just a Google away. Don't be afraid to ask smart questions, but like what was mentioned above, try not to ask the same thing twice. You have the benefit of working in a company around presumably smart people that could give you a hand here and there.

And like a lot of people have already said, figure out the best way for you to solve each problem individually. Diagram it, break it down. Difficult problems become much more manageable when broken down into actionable sections.

Last and probably most important, forget the attitude of "I don't know if I can do this." I know its cliche, but stop being negative and start asking yourself "what do I need to do to finish this?" If you admit defeat at the start, you aren't going to ever make it to the finish line.

I would (almost) begin a "generic error handling mechanism" task with a conversation with team members, either individually, or together. What do we all want to see this "thing" do? In this particular case, especially, your team, and your wider IT department, are the "customers" of your product. You need to collect requirements.

But before I did that I would arm myself with some preliminary studies. Research if there are any "tutorials" or "examples" already out there, perhaps on CodeProject. I'd also try to find some "luminaries" opinions floating around. Then, I'd look at some larger open source projects that would have error handling, to see how they're doing it, and also try to dig up complaints about existing error handling.

That last point is a good one. Research the common problems with error handling and see if any apply to the particular situation, so that they can be avoided up front.

Research then Discussion. That's how I usually start.

EDIT: Cleared up what exactly I would begin with...

EDIT2: I agree about that word "generic". What needs to be "generic" here? The task is to handle errors. I would say "consistent" is probably better than "generic". With error handling it's almost as much convention as "library" or whatever. The team has to agree how they're all going to be handling errors - so that everyone isn't doing their own thing. "Generic" would seem to apply if multiple teams would be using this "error handling mechanism" across multiple projects.

Your first task should be to start to model your requirements. No, you don't need to bust out the UML diagrams but you do need to ask questions to determine what the problem space looks like and how things fit together.

Asking yourself and others: who is involved, what is involved, and how do these fit together is the first stage in building a high level requirements model. This will structure the problem space into smaller chunks which you can then use to look for potential solutions.

Once you have the model it is then a good idea to look for established solution patterns - eg MS enterprise blocks - but you should hold off on that until you have your requirements model clear to avoid jumping to a great solution to a different problem!

Easiest way of programming something you have not done before - is to break it down into smaller parts. It is likely that even if you don't know how to do the main task - you do know how to solve the smaller ones.

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

That's a pretty important piece of the application... one that should probably be handled by one of the "old hands" at the company.

If you get it wrong you will screw up the workflow of all your colleagues. Is it actually assigned to you or are you just giving it an example of one of the tasks the entire team has to complete?

The best way to face a task you've never done before is to re-assign it to someone who has tons of experience in that task.

When that isn't an option, you should spend ~6 days discussing the problem among your colleagues and searching google (more discussions than google searches). Then spend 3 days actually working on the task.

If it needs 6 days of work, then you need to increase the discussion part to 12 days, and so on.

In my opinion new employees should not be taking on new projects. They should be fixing bugs/maintaining old projects. Then once they understand how things work, they can start working on new projects.

I've heard that inexperienced coders at Apple aren't even allowed to write any code. Their first role is just to manage the bug tracker, taking bug reports filed by other people and figuring out how to reproduce the bug and writing additional details so that someone else can actually fix it. As they get better, they might start writing in a suggestion of how it should be fixed, and this is around the time when they're likely to be assigned to a role at the company. I would love to try implementing this system where I work one day, it sounds like a great way to make sure your new employees really understand the codebase before they start working on it.

In this case the basic MSDN search didn't find much. The Bing search returned the Patterns and Practices's Exception Handling Block as the second link.

See it might have actually been a trick question, no one really wanted you to develop it on your own, and if they did they wanted you to adapt it from the P&P library. Maybe a light version of it as the Exception Handling Block may have been overkill. Either way you'd have practical source code and you'd know how to solve the problem.

On the good side, your manager probably realized that error handling, because it happens everywhere, is probably not tightly coupled to any other part of the project. In this way, it is easier to give to a young developer who isn't seeing the big picture very clearly yet.

On the rather more difficult side, error handling is a topic for mature coders. I know my own thinking about error handling has gone through several phases in a long career. Questions like return codes vs exceptions, localization of error messages, error recovery strategies, are all very sophisticated topics that a new developer has no hope of mastering.

You may discover that your boss really meant something vastly simpler than you think, like "Write a set of functions for copying error message text to a log file," or "Set up a couple of header files with ranges of error constants for different classes of errors." This you can probably do easily. If your boss really meant develop a whole strategy for handling errors, they get credit for thinking of the idea, but no credit for handing this important task to a new guy.

But bosses want what they want, and there's maybe nothing you can do but try to give it to them. In that case, google is your friend. You can google "error handling", "error reporting", "error reporting in C#", "error printer", and related terms and find out what packages other people have put together. Looking at the list of features of several error logging packages and asking yourself why this feature was choses will allow you to reverse-engineer a list of requirements. Seeing how different people solved the same problem might give you a sense of which implementation ideas were best, so you can recommend or code up a specific solution. This is going to get you about halfway to your goal, providing an error printing or logging facility. Having produced *something*, you may be able to fall back on "Well, I've only been doing this for three months, what did you expect?" Otherwise, I think that defining overall how the whole app will handle and recover from errors is a discussion that the whole team will have to participate in. It's extremely naive to think one person can define it. (Nevertheless, I once had a boss who was angry at me because I could not poof this problem out of existence for him.)

Analysis paralysis is common with all new engineers regardless of discipline. Try not to over think your problem. Take a chunk and get started - be it a diagram or pseudo code or something. That will get your brain in the right gear so you can ask intelligent questions of Google, your coworkers, etc.

Analysis paralysis is common with all new engineers regardless of discipline. Try not to over think your problem. Take a chunk and get started - be it a diagram or pseudo code or something. That will get your brain in the right gear so you can ask intelligent questions of Google, your coworkers, etc.

Sure... but he's talking about handling exceptions, which is one of the most difficult subjects any programmer will ever tackle.

There's an exception to every rule and this is one where serious analysis is needed.

Prototyping on something like Ruby on Rails is a great way to get from zero to complete product in a day or so. For example we wanted to add 2-factor auth onto our site, so I made a quick rails project, made a trivial login, and then added 2fa. It was a great way to show the feature off and get real feedback.

An important aspect of prototyping is getting something up fast, and figuring out if it is a good idea or not.

Rubber ducking works too. Just get another person from the team and start talking about it. The more you try to explain the better your ideas formulate. A good rubber duck will also help point out strengths in your ideas to help steer you.

Drawing diagrams falls into the rubber ducking category.

I also like the "stupid impl" -- a implementation that gets the job done as fast as possible with terrible names. Then start thinking abstractions, etc. but a terrible first version usually morphs into a great 2nd or 3rd version.

I mean, if I have an exception, I probably want a few discrete things in place:1 - Error catching, since I don't want to exit the process altogether, just switch to a different logic flow2 - Logging. Duh.3 - Event handling - I may want to fire off an event somewhere to clean up or something when time permits (in a separate thread, while this thread goes on to the next task or whatever)

Unless these are new technologies to the company, I'd hope that this has already been done on prior projects, which should give you a starting point. If you're breaking new ground, what mechanism was used on the stack that they were using? What was good? What was bad, what's desired now? Go from there.

Oh god, I'm so tired of the belief that everything starts with excessive planning and research.

MANY projects, absolutely, yes. You'd waste so much time designing a game engine without some plan of its structure. BUT, the same is simply not true at all for the article title: Something "you've never done before".

If you're entering new concepts, you're going to need at least a little bit of trial and error. I think some more experienced coders simply assume that some concepts, or even designs, will make perfect sense to someone after just reading about it in a textbook, and that you can move on to UML diagrams. But no good physics professor will simply describe the concepts of static coefficient of friction without also showing you the concept at work, and then having you try it out yourself with blocks on a ramp.

I've read all sorts of books on the graphics pipeline of DirectX, and some part of me thinks that I understand it. But, if I were ever making an engine from scratch, I'd absolutely need to do a "trial run" that does nothing but load and render sets of models; because getting the structure of that wrong could end up meaning redesigning my engine. ("Well, shoot! THAT part needs to be loaded first...? And it will SOMETIMES finish AFTER that other part?")

This is just for your own learning though, and some code will need to be written with the knowledge that you're going to throw it away; starting again thinking "Okay! I know what I was doing wrong on that last attempt, and I'm going to design the real thing a bit differently". Don't get so far that someone looks over your shoulder and says "L0K GRATE! SH1P IT111"

"Fail often, fail fast" is a good way to go. Say you are working with a binary tree. Do you start at the bottom or the top of the tree? Do I use a for loop, or do I use a recursive call?

You have to pick one, and usually only one is going to get you the best results with the cleanest, simplest code. You might get lucky and it works either way, you may get lucky and choose the right direction. But there is no sense overthinking it so you can get it right the first time, knowing a certain approach isn't going to work is more valuable than analyzing a problem to death and not writing any code. Even if you are wrong, you at least get your unit tests out of the way, which will also provide insight. Or in terms of an proof by induction you will also gain plenty of insights just working out a few base cases.

Gather requirements. Find out exactly what the team is looking for. Spend an hour reading up on the topic.

Look to see if there's an open source solution to the problem with a compatible license.

If not, figure out the simplest system that solves part of the problem. For exception handling, this could be a single try-catch around your entire program that logs the exception and restarts the program. Congratulations, you've now avoided failing the task! In my experience, it's much better to present a simplistic solution that barely addresses the problem then a well designed solution that doesn't work.

Now that you've made sure you won't get to the deadline with nothing, iterate. Make the logging configurable. Add some inner exception handling for cases that can be gracefully recovered from. Read more on the topic to see what other people have built.

Again, try to get each iteration working as quickly as possible. When you're in territory you've never dealt with before, you want to work in short sprints. A few days of coding and testing, and the system runs and is slightly better than before. Repeat.

I really like the second answer. When I graduated with my BS in CS two years ago my first job was consulting and every time I rolled onto a project I was nervous and didn't know if I could do it. A lack of confidence in my skill and abilities is something I actually recognized during my undergrad work, so it's something I have been able to identify and work on. Now I'm working in R&D with people who have PhDs and people who have have 20-30 years of industry experience and it's easy to feel dumb or unqualified. But they hired me knowing my experience, I'm learning things constantly, and it's tough, but it's basically my dream job for where I'm at in my career. If I'm unclear on something it's just a matter of asking for an explanation, and it slowly is all coming together (and changes constantly so I have to figure it out again). Your manager knows your experience and it is their job to match that with tasks that you are capable of completing, while also learning and becoming more familiar with the tools and best practices (but this also doesn't absolve you from pushing hard if they assign you a difficult task).

I also really rely on getting small things working at a time (like prototyping) and integrating that with the rest as it slowly comes together then adding robustness, error checking, better/proper memory management, etc. But just cause that works for me doesn't mean it will work for everyone, get a methodology and approach that works for you and makes sense for you.

If you're entering new concepts, you're going to need at least a little bit of trial and error.

Nobody has said it's not an iterative process, but to suggest you do not need research or planning (I would love to hear what you call 'excessive') before getting into it is a sign of shoot-from-the-hip development that leads inevitably to spaghetti code nobody understands 3 weeks after it's written.

I've read all sorts of books on the graphics pipeline of DirectX, and some part of me thinks that I understand it. But, if I were ever making an engine from scratch, I'd absolutely need to do a "trial run" that does nothing but load and render sets of models;

Sometimes little scratch programs are useful but they are by no means required. If you're smart, you'll even write those with classes/functions that you can copy/paste verbatim into the real engine when you're done testing. There is no reason to get lazy just because you're writing test code, even if the code is strictly to educate yourself.

the key is to educate yourself. Research the topics, identify two or three different approaches and learn them. Then take what you are doing and pick the approach that fits best. Be prepared to perform re-work. Work on a software design strategy before you start coding. Look for feedback on your design from more experienced developers and take their input. Then start coding.

Seems pretty easy, but much depends on what your manager actually wants.

Most important, error reporting is not the same as error handling. If the manager asks for a strategy to handle errors, they may be asking how to structure the whole program so that execution can (optionally) continue after an error. The error must be disposed of, which means you need to know what the error implies. Is this an unrecoverable fatal error? Is this an error in the program's main event loop that might in principle be handled just by swallowing it and getting the next event? Does this error imply an entire subsystem is unavailable, but other subsystems may still be functioning? Is this error the cascading failure from a previous error, so that execution should be terminated even though in other circumstances, the error might be non-fatal? Can this program be divided into major sections (e.g. run/stop or startup/main loop/shutdown) where the response to an error may be different?

The basic choice of how error information propogates through the system is important. If every error can be defined by an integer code, then returning an error code may be the most appropriate method. If you want to have contextual information, like a filename or URL, then maybe you'd rather return boolean pass/fail and fill in an error structure that is an out-parameter of every function, or (gasp) a global errno variable.

Some people like exceptions, and other people hate 'em. Google, for instance, has decreed that no exceptions be thrown in C++ code. But this is difficult because C++ is defined to throw for out-of-memory errors, and for bad dynamic cast to non-pointer. Windows also throws "structured exceptions", which you have to handle and convert to return codes if you want your program to do anything but halt suddenly. And you almost always want that. Some people think exceptions reduce the complexity of the code, because they count only visible execution paths. Others think exceptions increase the complexity of the code, because they count all possible paths. Some languages and some libraries are defined to throw exceptions, which means if you want to return error codes, you must remember to wrap all such calls or your program will terminate abruptly.

If you really want your program to remain available, you have to account for all possible errors. In Windows, some library functions call a function called abort(), which mostly does just waht it says. You can take control of abort() to prevent it terminating your code. Runtime checks in Windows call a different function that behaves like abort() but is literally different. There's signals, like control-C that will stop your program inelegantly if you don't handle it.

A complete error handling strategy is so complex that even experienced developers can easily miss something unless they've spent a lot of time thinking about errors. It's something that sounds easy, but has layers of complexity and tomes of arcane lore buried inside.