Iyfjky

Question

This question already has an answer here:

When asked about a completion date, what is the best way to say â€œit will be done when it is doneâ€?

11 answers

After all my subtle attempts to evade project completion time estimate requests ("when will this be done?"), I would like to directly communicate to my boss that I cannot and do not want to be estimating my project time completions. I was hoping that she was going to get the hint because all of my estimates have always been extremely inaccurate, either overdelivering or underdelivering but pretty much never on target, it doesn't make sense to ask me that as I cannot estimate my work, which always gets something in the way of completion along the way to make the original estimate meaningless.

Essentially, I am asking if there is a way, in the modern workplace dynamic, to tell my boss that I will be done when I am done and to stop beating a dead horse asking me for estimates that we both should know mean nothing.

I work as a Sr. Software Developer, I get my job done but I never know ahead of time how long it will take me to complete it. Does this make me an incompetent worker? Should I ask for a demotion or change jobs that will accommodate my commitment preference? Is giving time estimates a critical duty in project oriented work?

The business needs to be able to plan. For a small task might be 2 day or 2 weeks. Tell them in 2 days you will have it done or at least a better estimate. If it is a longer project then you need to give them a better estimate. Always do the high risk hard stuff up front. Get to proof of concept and the you can better estimate the time to fill in the details. — Jul 8 '15 at 19:24
I'm very much in the same boat (Not being able to accurately estimate the time it takes to complete my work). I'm very junior in my department and field. I aproached my supervisor, asking how I should handle this, and he recommended that I attempt not to give estimates in the same meeting I am asked to do something. He suggested a rule he uses when estimating time; He charts how much time he needs to think about something from A to B then multiplies planning time by N for work time. N should be adjusted as you learn to plan, but he suggested starting at 10 hours of work time per planning hour — Jul 8 '15 at 19:27
"state your assumptions clearly in your estimate... As soon as you realize an assumption is violated, immediately inform your client..." FWIW in all of my jobs prefix "Sr." in front of "developer" meant that they are expected to provide sensible (not necessarily precise) estimates — Jul 8 '15 at 20:36
"subtle attempts to evade [estimates]" "cannot and do not want to be estimating" - that's not incompetence (for which I would have sympathy), that's a passive-aggressive attempt to avoid doing what is actually part of the job (for which I don't). — Jul 9 '15 at 8:55
"I will be done when I am done" - I knew I had read that before. — Jul 9 '15 at 14:43

Alex 3,3561130 · Answer 1 · 2015-07-08 19:31:39Z

Does this make me an incompetent worker? Should I ask for a demotion or change jobs that will accommodate my commitment preference? Is giving time estimates a critical duty in project oriented work?

Since most senior developer positions require at least five years experience, one is left wondering how you are a senior developer, but don't understand working by deadlines and progress reports. That's a general given, especially in the role of a junior developer. As you go up, deadlines, resources, and planning become the mainstay. As a senior software developer, estimating completion dates and time project duration's should come natural given your level of experience. If companies just give a blank check for dev time then nothing would get done. Deadlines are a necessary part of life. Even if your projects drastically differ without continuity, you should be able to give accurate estimates for boiler plate portions of the application and reserve conservative estimates for project elements more R&D in nature where the path to the outcome is less certain in nature.

Regardless of whether you work in a company as a developer or for a client, everyone wants certainty for the expected outcome. If working by deadlines is such an issue for you, then maybe you need to consider switching to an occupation which assigns rather menial tasks without much consideration for time lines and measurable progress.

I highly disagree - best companies and most efficient companies I have ever worked for don't use estimates, they are essentially meaningless especially for someone that can manage themselves. You must work with some lazy people to think "nothing would get done" as if time estimates is what motivates people, it isn't — user37925, Jul 9 '15 at 16:13
If they didn't use estimates how did they price the contracts? As a developer you are part of a chain and others need to have some idea of when software or resource will be available. — Jul 9 '15 at 16:47
@MattP You don't need estimates to know that, companies I've worked in we released every 2 weeks without any estimate and any of the hire ups can be confident in saying 'every 2 weeks'. You see the product progressing, you see things being produced and changing - that IS your estimate, the managers should be competent enough to figure that out — user37925, Jul 9 '15 at 17:49
But what if a client asks for a new feature and wants a fixed price. Or a coworker is dependant on your progress, or some equipment needs to be purchased at a specific timing. Furthermore, working in an agile environment with two week sprints also requires estimates of how long things take to be able to plan the amount of work for the coming sprint. Providing estimates can be hard, but one does get better at it over time. Stating that estimates cannot be made and that managers should accept that is a gross simplification. — Jul 10 '15 at 17:49

Kevin 24127 · Answer 2 · 2015-07-08 19:35:29Z

In software development, giving accurate time estimates is incredibly difficult, and good managers should be able to understand that estimates vary from the actual goal.

However, this is also a skill that you need to practice. Track your estimates and find out what made them late. Are you running into more difficulties then expected? Build that time in. Are you getting projects done sooner than expected? Bear that in mind for the future.

This is part of software development, like it or not. Your boss needs to be able to plan around these estimates, and it's important that your "two days" estimate doesn't devolve into "two months".

user8365 · Answer 3 · 2015-07-08 19:35:10Z

They're called estimates because they're not exact. There is a disconnect between the level of accuracy expected by your boss and what you think. If your boss wants more accuracy, you would know it. For many people and situations, any estimate is better than nothing. You have to start somewhere.

You also mentioned about unknown things getting in the way. This happens all the time. Tasks get reprioritized because of unexpected events.

Keep better track of your tasks to see how long it takes while you're actually working on it. There's not point in saying something will take two days, but if you're sick for a day, obviously it will now take at least 3 days from the time you estimated. Maybe your boss is not aware of all the distractions that are part of your job: meetings, trouble-shooting, debugging, email, phone calls, etc.

Set goals to get better at estimating without the stress of thinking you'll be perfect. Work with your boss if you think she can help remove some of the other interupters if you're not getting things done fast enough.

It's not going to go away. Wanting to just put an unlimited time-frame on every task is unrealistic, so don't even try. Work on the things you can control.

score 7 · Answer 4 · 2015-09-21 00:51:38Z

After all my subtle attempts to evade project completion time estimate
requests ("when will this be done?"), I would like to directly
communicate to my boss that I cannot and do not want to be estimating
my project time completions.

Everyone can give estimates, although many would prefer not to do so.

I suspect you would be better off indicating that you don't feel confident giving estimates, and asking how you might learn to get better at it.

Essentially, I am asking if there is a way, in the modern workplace
dynamic, to tell my boss that I will be done when I am done and to
stop beating a dead horse asking me for estimates that we both should
know mean nothing.

In most shops where I have worked, estimates are an essential portion of the SDLC. If your shop is like that, then there would be no way for you to decline to provide estimates when asked.

I work as a Sr. Software Developer, I get my job done but I never know
ahead of time how long it will take me to complete it. Does this make
me an incompetent worker?

I wouldn't use the term "incompetent" here. But most Senior Developers I know are willing to provide an estimate when asked. And most folks can come up with some very rough idea of how long a task might take. Never being able to do so does make you seem a bit out of the norm.

Should I ask for a demotion or change jobs that will accommodate my
commitment preference?

In many companies, a demotion wouldn't help. Even less-than-Senior Developers are required to provide estimates in many shops.

Is giving time estimates a critical duty in project oriented work?

I've worked in many companies where it was indeed a critical part of the job for the software folks to provide estimates on a regular basis.

I've worked at a few that didn't typically require much estimation, but they seem to be rare, and with Agile methodologies seem to be disappearing.

Under the theory of "You never know until you ask" you could just directly ask your boss "Are estimates required here? Can I do my work without providing estimates?" and see what kind of reaction you get. (I don't suggest using phrases like "I will be done when I am done" or "stop beating a dead horse" though, Those wouldn't be received well by the managers I know).

My suggestion is to learn how to estimate better, so that your attempts won't be so inaccurate, or feel so meaningless. One place to start is to keep close track of your actual hours, to provide a historical basis on which you can draw your future estimates. That's how I learned. You should also ask if there is company-provided training that would help with this and other parts of your company's SDLC.

You might find that you are unnecessarily worried about accuracy. Or you might find that better requirements might make you feel more confident in your estimates.

gnasher729 71k31131222 · Answer 5 · 2015-07-09 08:34:00Z

I think it is very unlikely that any boss will let you get away with "I can't do estimates, I don't want to do estimates". On the other hand, estimates are difficult, and some bosses take estimates as promised deadlines, which causes more problems.

So first you must be able to estimate how long a job takes (we come to that later). You then need to decide what number you tell your boss. If you estimate that a job takes four weeks, and you know yourself that you are notoriously bad at estimating and therefore the job is expected to take 8 weeks, or one or two weeks more or less, and your boss takes estimates as a deadline that you promised him, then the answer is 11 weeks. If your boss takes estimates as a best estimate and expects it to be longer or shorter, you say 8 weeks.

There is a simple technique to improve your estimates, which has worked perfectly for me. Get yourself a spreadsheet program. In that spreadsheet, you enter all the things you need to do to perform the task, and assign days to each item. Go over it several times to make sure you haven't left out anything. At the end, you add up the days and get an estimate. Put in holidays and bank holidays.

As you progress through the job, and finish tasks, write down for every task how long it actually took, compared to your estimate. And here comes the use of the spreadsheet: Calculate how much the estimates add up to for all completed tasks, and what the actual times add up to for each completed task, and with that you calculate how long the other tasks should take, assuming they are all delayed or speeded up by the same factor, and now you have an improved estimate how long it takes.

Now you can do two things: First, you can go to your boss and tell him what you are doing. You tell him "I made this estimate and it says four weeks, but you know how bad I am with estimates, so don't believe this number. I use this new method and in a week I'll tell you an estimate that should be a lot better". That demonstrates that you are willing and on your way to improve your estimates; obviously it takes a while, but within a week you should deliver much more accurate numbers.

And you can collect the data, and on your next job you collect your old, bad numbers, and the spreadsheet automatically takes into account how bad you are with estimates and corrects it. So the next time, you go to your boss with a much better estimate.

score 0 · Answer 6 · 2015-07-09 18:31:25Z

Honestly, I agree with you - best and most efficient companies I've worked for don't use estimates. Estimates are a terrible micro-managing tool and people need to move on from that crap.

However, giving them is extremely easy, you just need to think about it in terms of days and give it a day or two buffer if you are not confident in your estimate. The fact is if your estimate is poor they will ask how far off you are to completing it and you should be able to give some response, say you've found the issue and just need to implement some system to fix it and should be able to give a pretty solid estimate from that point - any Sr. level developer will be able to do that.

EDIT: I realized I wasn't very helpful with my last comment so I edited it.

If you're stuck on 'getting out of estimates' just appease them, come to common ground - say things like "No I was to busy to give the estimate but I did complete this task and it took me X hours/days". They may just need 'something' from you so find a way (in your way, that your comfortable and willing to do) to give that to them. One company wanted me to log the hours I worked on a dev task in JIRA and since I would complete like 10-12 a day just closing them like crazy I stopped logging the hours after day 1 - they never cared because of how effective I was at improving the software, and they were pertinent on day 1 that I logged my hours but they never mentioned it after I stopped, not even once - and were very happy with the way I did things. That's why I find it hard to believe if you are doing the job well that they are pin-point concerned you're not giving them estimates, I wonder, do you just say 'No' to them? Do you also get frustrated when they ask you? Cause if so those could be the main problem, sometimes they just need you to communicate to them better - they may get pushy but they may also just not truly understand. I would calmly and professionally talk to them about it, explain that you get all this stuff done and your really efficient in 'the way you work', see if they will make a compromise with you (such as keeping track of the time you do work on things after they are completed, or giving them a 'current amount worked on' type deal, or etc...).

@Joe interesting really? I'm curious - what does your company value so much in the estimates? I'm not saying say 'No' by any means, you can simply say things like 'I was too busy, sorry I couldn't get you an estimate, however I did get this and this done and they took this long'. My main point is that there are ways to appease them - come to common ground sort of speak — user37925, Jul 9 '15 at 18:23
@Joe Yeah, I can believe it. I've been at places that just seem to want to do things a certain way whether it's actually better or not - there is a lot going on at the top, sometimes they just need numbers for political reasons etc.. but like you pretty much stated, it is their ship. It's always better to get off at the next port if you don't want to run it their way then it is to cause mutiny. — user37925, Jul 9 '15 at 18:33
@KillianDS Yes, but even with that the managers should be able to figure that out without the micro-managed time estimates for every task from every dev. Running things you see the flow and progress and production rate yourself - should be able to put that into an estimate after being there for so long. I think part of it might come to 'relieving responsibility down the chain' so if something does go wrong all the fingers don't just point to the manager, the point to the process so it's harder to blame any one person thus relieving pressure from everyone. — user37925, Jul 9 '15 at 18:37
Just adding to the conversation... In businesses where software development is an "overhead" function (internal IT shops, for example), estimates may be less important (but not unimportant as all businesses have budget constraints). But in a business where the software is the product, the estimates become more meaningful. And in businesses where your company is hired to do the work for someone else, estimates are your life blood, and getting good at estimating is your key to staying in business. — Jul 9 '15 at 18:43
@Kent good point, I've never worked for an outsourcer but I'm sure if I did the time and estimations of time for tasks would def. be of high concern. — user37925, Jul 9 '15 at 18:44

Alex 3,3561130 · Answer 7 · 2015-07-08 19:31:39Z

Does this make me an incompetent worker? Should I ask for a demotion or change jobs that will accommodate my commitment preference? Is giving time estimates a critical duty in project oriented work?

Since most senior developer positions require at least five years experience, one is left wondering how you are a senior developer, but don't understand working by deadlines and progress reports. That's a general given, especially in the role of a junior developer. As you go up, deadlines, resources, and planning become the mainstay. As a senior software developer, estimating completion dates and time project duration's should come natural given your level of experience. If companies just give a blank check for dev time then nothing would get done. Deadlines are a necessary part of life. Even if your projects drastically differ without continuity, you should be able to give accurate estimates for boiler plate portions of the application and reserve conservative estimates for project elements more R&D in nature where the path to the outcome is less certain in nature.

Regardless of whether you work in a company as a developer or for a client, everyone wants certainty for the expected outcome. If working by deadlines is such an issue for you, then maybe you need to consider switching to an occupation which assigns rather menial tasks without much consideration for time lines and measurable progress.

I highly disagree - best companies and most efficient companies I have ever worked for don't use estimates, they are essentially meaningless especially for someone that can manage themselves. You must work with some lazy people to think "nothing would get done" as if time estimates is what motivates people, it isn't — user37925, Jul 9 '15 at 16:13
If they didn't use estimates how did they price the contracts? As a developer you are part of a chain and others need to have some idea of when software or resource will be available. — Jul 9 '15 at 16:47
@MattP You don't need estimates to know that, companies I've worked in we released every 2 weeks without any estimate and any of the hire ups can be confident in saying 'every 2 weeks'. You see the product progressing, you see things being produced and changing - that IS your estimate, the managers should be competent enough to figure that out — user37925, Jul 9 '15 at 17:49
But what if a client asks for a new feature and wants a fixed price. Or a coworker is dependant on your progress, or some equipment needs to be purchased at a specific timing. Furthermore, working in an agile environment with two week sprints also requires estimates of how long things take to be able to plan the amount of work for the coming sprint. Providing estimates can be hard, but one does get better at it over time. Stating that estimates cannot be made and that managers should accept that is a gross simplification. — Jul 10 '15 at 17:49

Kevin 24127 · Answer 8 · 2015-07-08 19:35:29Z

In software development, giving accurate time estimates is incredibly difficult, and good managers should be able to understand that estimates vary from the actual goal.

However, this is also a skill that you need to practice. Track your estimates and find out what made them late. Are you running into more difficulties then expected? Build that time in. Are you getting projects done sooner than expected? Bear that in mind for the future.

This is part of software development, like it or not. Your boss needs to be able to plan around these estimates, and it's important that your "two days" estimate doesn't devolve into "two months".

user8365 · Answer 9 · 2015-07-08 19:35:10Z

They're called estimates because they're not exact. There is a disconnect between the level of accuracy expected by your boss and what you think. If your boss wants more accuracy, you would know it. For many people and situations, any estimate is better than nothing. You have to start somewhere.

You also mentioned about unknown things getting in the way. This happens all the time. Tasks get reprioritized because of unexpected events.

Keep better track of your tasks to see how long it takes while you're actually working on it. There's not point in saying something will take two days, but if you're sick for a day, obviously it will now take at least 3 days from the time you estimated. Maybe your boss is not aware of all the distractions that are part of your job: meetings, trouble-shooting, debugging, email, phone calls, etc.

Set goals to get better at estimating without the stress of thinking you'll be perfect. Work with your boss if you think she can help remove some of the other interupters if you're not getting things done fast enough.

It's not going to go away. Wanting to just put an unlimited time-frame on every task is unrealistic, so don't even try. Work on the things you can control.

score 7 · Answer 10 · 2015-09-21 00:51:38Z

After all my subtle attempts to evade project completion time estimate
requests ("when will this be done?"), I would like to directly
communicate to my boss that I cannot and do not want to be estimating
my project time completions.

Everyone can give estimates, although many would prefer not to do so.

I suspect you would be better off indicating that you don't feel confident giving estimates, and asking how you might learn to get better at it.

Essentially, I am asking if there is a way, in the modern workplace
dynamic, to tell my boss that I will be done when I am done and to
stop beating a dead horse asking me for estimates that we both should
know mean nothing.

In most shops where I have worked, estimates are an essential portion of the SDLC. If your shop is like that, then there would be no way for you to decline to provide estimates when asked.

I work as a Sr. Software Developer, I get my job done but I never know
ahead of time how long it will take me to complete it. Does this make
me an incompetent worker?

I wouldn't use the term "incompetent" here. But most Senior Developers I know are willing to provide an estimate when asked. And most folks can come up with some very rough idea of how long a task might take. Never being able to do so does make you seem a bit out of the norm.

Should I ask for a demotion or change jobs that will accommodate my
commitment preference?

In many companies, a demotion wouldn't help. Even less-than-Senior Developers are required to provide estimates in many shops.

Is giving time estimates a critical duty in project oriented work?

I've worked in many companies where it was indeed a critical part of the job for the software folks to provide estimates on a regular basis.

I've worked at a few that didn't typically require much estimation, but they seem to be rare, and with Agile methodologies seem to be disappearing.

Under the theory of "You never know until you ask" you could just directly ask your boss "Are estimates required here? Can I do my work without providing estimates?" and see what kind of reaction you get. (I don't suggest using phrases like "I will be done when I am done" or "stop beating a dead horse" though, Those wouldn't be received well by the managers I know).

My suggestion is to learn how to estimate better, so that your attempts won't be so inaccurate, or feel so meaningless. One place to start is to keep close track of your actual hours, to provide a historical basis on which you can draw your future estimates. That's how I learned. You should also ask if there is company-provided training that would help with this and other parts of your company's SDLC.

You might find that you are unnecessarily worried about accuracy. Or you might find that better requirements might make you feel more confident in your estimates.

gnasher729 71k31131222 · Answer 11 · 2015-07-09 08:34:00Z

I think it is very unlikely that any boss will let you get away with "I can't do estimates, I don't want to do estimates". On the other hand, estimates are difficult, and some bosses take estimates as promised deadlines, which causes more problems.

So first you must be able to estimate how long a job takes (we come to that later). You then need to decide what number you tell your boss. If you estimate that a job takes four weeks, and you know yourself that you are notoriously bad at estimating and therefore the job is expected to take 8 weeks, or one or two weeks more or less, and your boss takes estimates as a deadline that you promised him, then the answer is 11 weeks. If your boss takes estimates as a best estimate and expects it to be longer or shorter, you say 8 weeks.

There is a simple technique to improve your estimates, which has worked perfectly for me. Get yourself a spreadsheet program. In that spreadsheet, you enter all the things you need to do to perform the task, and assign days to each item. Go over it several times to make sure you haven't left out anything. At the end, you add up the days and get an estimate. Put in holidays and bank holidays.

As you progress through the job, and finish tasks, write down for every task how long it actually took, compared to your estimate. And here comes the use of the spreadsheet: Calculate how much the estimates add up to for all completed tasks, and what the actual times add up to for each completed task, and with that you calculate how long the other tasks should take, assuming they are all delayed or speeded up by the same factor, and now you have an improved estimate how long it takes.

Now you can do two things: First, you can go to your boss and tell him what you are doing. You tell him "I made this estimate and it says four weeks, but you know how bad I am with estimates, so don't believe this number. I use this new method and in a week I'll tell you an estimate that should be a lot better". That demonstrates that you are willing and on your way to improve your estimates; obviously it takes a while, but within a week you should deliver much more accurate numbers.

And you can collect the data, and on your next job you collect your old, bad numbers, and the spreadsheet automatically takes into account how bad you are with estimates and corrects it. So the next time, you go to your boss with a much better estimate.

score 0 · Answer 12 · 2015-07-09 18:31:25Z

Honestly, I agree with you - best and most efficient companies I've worked for don't use estimates. Estimates are a terrible micro-managing tool and people need to move on from that crap.

However, giving them is extremely easy, you just need to think about it in terms of days and give it a day or two buffer if you are not confident in your estimate. The fact is if your estimate is poor they will ask how far off you are to completing it and you should be able to give some response, say you've found the issue and just need to implement some system to fix it and should be able to give a pretty solid estimate from that point - any Sr. level developer will be able to do that.

EDIT: I realized I wasn't very helpful with my last comment so I edited it.

If you're stuck on 'getting out of estimates' just appease them, come to common ground - say things like "No I was to busy to give the estimate but I did complete this task and it took me X hours/days". They may just need 'something' from you so find a way (in your way, that your comfortable and willing to do) to give that to them. One company wanted me to log the hours I worked on a dev task in JIRA and since I would complete like 10-12 a day just closing them like crazy I stopped logging the hours after day 1 - they never cared because of how effective I was at improving the software, and they were pertinent on day 1 that I logged my hours but they never mentioned it after I stopped, not even once - and were very happy with the way I did things. That's why I find it hard to believe if you are doing the job well that they are pin-point concerned you're not giving them estimates, I wonder, do you just say 'No' to them? Do you also get frustrated when they ask you? Cause if so those could be the main problem, sometimes they just need you to communicate to them better - they may get pushy but they may also just not truly understand. I would calmly and professionally talk to them about it, explain that you get all this stuff done and your really efficient in 'the way you work', see if they will make a compromise with you (such as keeping track of the time you do work on things after they are completed, or giving them a 'current amount worked on' type deal, or etc...).

@Joe interesting really? I'm curious - what does your company value so much in the estimates? I'm not saying say 'No' by any means, you can simply say things like 'I was too busy, sorry I couldn't get you an estimate, however I did get this and this done and they took this long'. My main point is that there are ways to appease them - come to common ground sort of speak — user37925, Jul 9 '15 at 18:23
@Joe Yeah, I can believe it. I've been at places that just seem to want to do things a certain way whether it's actually better or not - there is a lot going on at the top, sometimes they just need numbers for political reasons etc.. but like you pretty much stated, it is their ship. It's always better to get off at the next port if you don't want to run it their way then it is to cause mutiny. — user37925, Jul 9 '15 at 18:33
@KillianDS Yes, but even with that the managers should be able to figure that out without the micro-managed time estimates for every task from every dev. Running things you see the flow and progress and production rate yourself - should be able to put that into an estimate after being there for so long. I think part of it might come to 'relieving responsibility down the chain' so if something does go wrong all the fingers don't just point to the manager, the point to the process so it's harder to blame any one person thus relieving pressure from everyone. — user37925, Jul 9 '15 at 18:37
Just adding to the conversation... In businesses where software development is an "overhead" function (internal IT shops, for example), estimates may be less important (but not unimportant as all businesses have budget constraints). But in a business where the software is the product, the estimates become more meaningful. And in businesses where your company is hired to do the work for someone else, estimates are your life blood, and getting good at estimating is your key to staying in business. — Jul 9 '15 at 18:43
@Kent good point, I've never worked for an outsourcer but I'm sure if I did the time and estimations of time for tasks would def. be of high concern. — user37925, Jul 9 '15 at 18:44

Search This Blog

Iyfjky

How to exempt oneself from giving project completion time estimates? [duplicate]

marked as duplicate by Dukeling, DarkCygnus, gnat, scaaahu, Draken Nov 8 '17 at 8:32

marked as duplicate by Dukeling, DarkCygnus, gnat, scaaahu, Draken Nov 8 '17 at 8:32

marked as duplicate by Dukeling, DarkCygnus, gnat, scaaahu, Draken Nov 8 '17 at 8:32

marked as duplicate by Dukeling, DarkCygnus, gnat, scaaahu, Draken Nov 8 '17 at 8:32

6 Answers
6

6 Answers
6

6 Answers
6

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

Category

Random preview

How to exempt oneself from giving project completion time estimates? [duplicate]

marked as duplicate by Dukeling, DarkCygnus, gnat, scaaahu, Draken Nov 8 '17 at 8:32

marked as duplicate by Dukeling, DarkCygnus, gnat, scaaahu, Draken Nov 8 '17 at 8:32

marked as duplicate by Dukeling, DarkCygnus, gnat, scaaahu, Draken Nov 8 '17 at 8:32

marked as duplicate by Dukeling, DarkCygnus, gnat, scaaahu, Draken Nov 8 '17 at 8:32

6 Answers 6

6 Answers 6

6 Answers 6

Comments

Post a Comment

Popular posts from this blog

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor

Is the Concept of Multiple Fantasy Races Scientifically Flawed? [closed]

Confectionery

6 Answers
6

6 Answers
6

6 Answers
6

Long meetings (6-7 hours a day): Being â€œbabysatâ€ by supervisor