This reminds me of my game development job I had years back.
I was new to the field (but not new to software development) and there was this small software team doing programming tasks for the game.
The lead developer was concerned on my performance after a few months I was there.
I remember him drawing an image excatcly like the second picture in this article (an arrow going from A to B). He said that my performance was very poor, and then he drew another picture that was like the circle in the article.
The way I worked was searching for a solution, going wrong direction a few times, asking designers for more information and then eventually landing on a solution (that worked, and users like it).
But I was told this is wrong way of doing software. I was not supposed to ask advice from the users (because the team "knew better").
He also told me that a good software developer takes a task, solves it (goes from A to B), and then takes another task.
After a few weeks I was fired from that job.
To this day I'm still baffled by this. The company was really succesfull and everyone knew how to make software. It seemed like a very harsh environment. Is it like this in the top software companies everywhere? Like the super-pro-developers really just take a task and solve it without issues?
I've noticed that there are some managers that want their underlings to be just "meat robots" that do as they told without question. Other managers value independent thinkers that can be given an abstract task and find a solution, even if that solution ends up being very different to what was originally envisaged.
The strange thing is that both approaches can be successful!
However, they are not compatible. At most, it's possible to have an out-of-the-box thinker above a team of robots, but that's about the maximum extent of mixing that works.
For example, in the robot-based team, managers generally don't explain any of the inputs and constraints that went into a decision to their underlings. This saves time, allowing them to manage more people to get more done. However, the creative types question everything, which irritates and frustrates them. In an all-creative team, managers will explain the backstory to the junior staff, giving them the information they require to seek alternative but compatible solutions. This takes longer, but then they can offload a lot of the decision making to the juniors.
Don't feel bad that you didn't fit in, it just means that you need to find a place with a corporate culture that suits you better.
In my own experience (and opinion), your style of development often results in better quality code, less bugs, and cleaner UX. The tradeoff, as you experienced, is time.
I can also tell you that maximum code quality is not always the priority. This is especially true in games, where you ship and then move onto the next project. Even online games nowadays often shut down after not long, and so they don't need quite as much maintenance as a successful SAAS.
Again in my experience, the super-pro devs I know are particularly good at knowing when to be fast and reckless, and when to be slow and calculating.
You most likely ran into a bad lead. His/her role was to coach & mentor you to help you become a better engineer, not just to draw diagrams on a white board.
"everyone knew how to make software" -> if that was the case, you should have found help and support around you organically.
I hope you're in a better situation now. Don't let this kind of experience hurt your self-esteem. You deserved a better place.
The straight line from point a -> b can only be drawn backwards, i.e. from hindsight. When you zoom out, we all goes in circle/iteration. It is true that in some domains some engineers might have better insight than their users, but not all domains. It is important to keep the humility or be conscious that there exist an unknown world to us.
If your former team lead went from a -> b with no problem, maybe he is part of the circle. Afterall, when you zoom in the circle close enough, it appears a straight line. Or he could be a visionary, I can't tell.
An organization is like a shark, it needs to move forward. That organization can be an one-man team, where thinking overlaps with doing. In larger org, specialization is inevitable. The "no question ask, get things done" way that your former team lead adopted is desirable to certain degree, some of the time. But it is important to be aware of the duality. "Disagree but commit" is a virtue.
A fish can teach you swim, but it probably doesn't know it is in water
There are tasks you are experienced with that you can pretty much jump on and just do them, but there's also the other 90%.
What's weirdest about your story is that you were laid off a few weeks into your job. People usually get more time to get the hang of it even if they are senior, so I would mostly assume that it was a cultural fit rather than performance.
Some outsourcing/service (billed by the hour — which explains it for the most part) companies would look for very strict delivery cadence with focus on exactly the process you describe, but you'd be unlikely to have contact with the user in that case (just the customer).
Most importantly, if you ever get fired, be sure to ask for the explanation so you don't end up being baffled.
This is a great question! When I was a developer I used to develop software the way you were told not to. I did it that way because the requirements were always very vague and a lot of gaps needed to be filled. But when I was a project manager I thought that way of development is wasteful and would rather developers didn't do what I did.
So I suppose the real answer depends on the environment you're in. If the project is meant to be agile then you probably need a bit of interaction with the user to get the job done. If the project is not agile and all the requirements could be known up-front then you're probably wasting effort having programmers determine what those requirements are. IMHO.
I worked at an "agency" that could be described exactly like that, though they were not as successful and additionally have a bad reputation amongst recruiters and the local tech scene as a result of the gaslighting, unreasonable expectations, and deliberately moving goal posts in order to fluster people and have "reason" to fire them.
It seems that these toxic environments thrive when the top level of the management encourages this behaviour.
You showed them you're paying attention. That usually scares the crap out of people who have something to hide. The lesson here is that you were working in a den of vipers, and you're better off elsewhere.
I've met similar thinking. In one company I was working for some time in a senior role, while being new there, I got scoffed for asking the non-senior developers of the team for information on some parts of how the software worked.
Maybe you went over somebodys head, or maybe rank played a part in this. Some people also want you to follor their way or the highway, unfortunately I've seen this many times in different software companies.
Probably in this kind of teams execution is what matters, not thinking for yourself.
I work in Google and it's nothing like this (as long as by "the users" you mean the two-four teams you interface with, not the one-two billion humans using the end product). Your approach to problems would fit right in and the described manager wouldn't keep managing for long.
On the other hand, I once mentored a person working in another company. I've been giving advice that I would give to a junior Googler. They got fired :(
Nope, this ticks for me all signs of a bad/incompetent team lead. I’ve seen lots of teams in my career. I certainly wouldn’t promote or hire someone for team lead if answered the question like this guy about what makes a good software developer. This is a sign for management by metrics which works short-term but ultimately leads to demise of the product.
For predicting the daily schedules on a film set I always "ran a simulation" of what would be done that day and just summed the predicted minutes. The simulation ran in my head of course, but it included things like: Actors drinking coffee and chatting, costumes getting ready, Camera department forgot memory card in the car, lunch breaks, someone arrives late, etc.
Obviously the major chunk were always scenes and they are usually also the major contributor to the insecurity of the prediction. E.g. working with people who you don't know, weather, technical problems (broken, missing stuff), stuff that just won't work (animals, certain scenes with actors).
But in the end what always mattered was that there was a time plan for each day and at the end of a day we would know wheter we are A) faster as predicted, B) on time or C) slower than predicted. The next day would then be restructured accordingly by the production and usually you'd be back on time by the end of that.
I was usually spot on with my predictions and we never had any issue with getting the planned stuff done.
With programming the whole thing is harder, because it can be even more unpredictable. But what definitly always helps is when you have a feeling for whether you are too slow, on time or you managed to build a time buffer for future doom.
Tom DeMarco talks about modelling-based estimates in Waltzing With Bears, mainly to break people out of the error they fall into of treating the soonest possible time something could be done as a realistic estimate of when something will actually be finished. There are also approaches like Function Point Analysis which provide an explicit model that you can calibrate your team against.
It's doable, but what people tend to forget is that it's work. If you want an estimate, I need to be able to expend effort providing it. It's an engineering activity that needs organisational support to do it at all well, but often you find an expectation that people will be able to pull an estimate out of a hat just having heard the faintest description of the problem, and there can often be a tacit belief (usually but not entirely from non-technical folks) that not being able to do so makes one incompetent.
dang, software planning is harder than herding hundreds of entertainment people? Not what I would have expected! I always assumed the 'unknown unknowns' were much larger in real life enterprises than in software ones, and that'd make planning harder. A lot of advantages come from software being made out of formal systems.
[my honest best estimate thinking off all I can think of] * X
+1 on the factor for any of these:
- always +1 right away (so it's x2)
- tech is new for you
- other teams involved
- you don't have a clear idea of what tasks are involved (it's not yet another X)
- you see additional risks
So if it's making a yet another micro marketing website based on an pixel perfect photoshop design: x2
If the design is not pixel perfect or missing responsive: the customer is involved: x3
If you refactor stuff in to new tech and it changes apis to other teams: new tech, other people, risks, no clear tasks: x5
The research on this stuff says that time estimates are extremely inaccurate and to be avoided. If you manage to stay inaccurate by ONLY a factor of 3.14, that is unusually high accuracy.
Much more accurate are estimates of difficulty or complexity (small medium large, weighted numbers, whatever). The manager can then make an average conversion rate to time (with error bars), and use that for medium/long term forecasting. This is demonstrated extremely accurate compared to time estimation (but it is useless and breaks if you apply time/points pressure to your team, or even let them think in terms of a time conversion rate).
This is not new research. Kahneman's Nobel prize about decisions under uncertainty was in 2002. Put away the superstitions and stop estimating with time!
Two points to elaborate, already mentioned in the neighbour thread on estimation.
Firstly, programmers are notoriously and famously bad at estimation, so it's highly likely that you do need to find the multiplier for yourself. This illustration is something like fifteen years old by now: https://pbs.twimg.com/media/EyNRiYQXMAIshEj.jpg
Secondly, wise managers know to expect this, and do the multiplication themselves. But if you have managers who do the opposite and always scale the estimation back, expecting the results earlier that promised, then you need to use a second multiplier—which the manager will unknowingly annul, getting closer back to your actual figure. Probably something around 1.5 to 2.
However, if you need the second multiplier then you also gotta ask yourself why you're staying in that company.
I've found this "story" by Michael Wolfe [1] (warning: Quora link that you may need to open in an incognito window) to be a fun way to explain why accurate software estimation is so difficult.
This is good advice but forgets that people are part of how long time something will take as well. If it's one engineer, it'll probably take $estimation * π, but if it's two engineers, you probably need to double that. If it's three, triple it. New calculation should be something like "($estimation * π) * $peopleWorkingOnSameThing". Communication overhead and mistakes should not be underestimated.
I agree that communication overhead exists but I think you’re ignoring the benefit from having 2 people working through a problem vs one person. I’ve seen much faster results because people don’t tend less to get stuck if pairing with someone.
People tend to want to hear or give the shortest estimate that seemingly sounds feasible.
I don't do that anymore. I try to push estimates as high as possible and then collaboratively cut down on requirements/promises/features to match an expected (time) budget.
This often leads to more pragmatic work items and sensible prioritization from the start. And it is an opportunity for general communication and understanding the value of things.
I will sometimes give an estimate in multiple ways -- "This takes about four weeks for the engineering work, but unless we remove all other priorities it will take about 3 months to complete."
A lot of the time when you are working the delays aren't just the uncertainty of an individual task; it's that you're working on several projects at once, you're attending meetings, etc, so that you might only average 2 hours / day working on a particular task or you might not be able to start a task for several weeks (depending on whether you work sequentially or in parallel).
You still need a realistic, achievable estimate for that first time, in case management calls your bluff, but distinguishing between "the amount of effort this will take" and "how long it will be before it is complete" can help set realistic expectations while making it harder for management to mistakenly think you need two months to complete a task that could be done in two weeks.
You always see rookies make the mistake of just adding up the individual time of all the tasks - and engineers are famously bad at making horribly under-scoped estimates - so projects estimated this way have typically went over time by a factor of three or so as I've come to learn...
This seems to follow my experience, although I attributed it to the Pareto principle.
80% of the feature will take 20% of the time. The last 20% will take 80% of the time once you factor in all the other things like:
- getting the feature working correctly to all specifications.
- thinking about larger scale impact of your code and how your team might react to it, and deciding on which implementation to take.
- resolving missing edge cases.
- previously undescribed features the design team overlooked, but is now obviously wrong now that they can see it in action.
- time it takes to roundtrip the review process.
- resolving unrelated bugs that code changes may have created.
- writing tests.
- manual testing.
- fixing bugs found in regression tests.
- deployment and deployment related errors (happens rarely, but you have to average it out).
Just getting to "I got this feature working!", seems to only be a small part of the whole process.
My problem with multiplying my estimates by Pi, or any n > 1+epsilon, is that one's boss often looks at such estimates and asks "How can it take you so long to do just XYZ?" and they would rather, in effect, be given a shorter estimate initially and settle on delays than be given a more conservative/inflated estimate, even if in the latter case there is rarely a delay.
The most important thing I’ve learned about estimation is that, especially in larger/more established companies, it really only matters in two basic scenarios:
- Order of magnitude differences
- hard deadlines (like a public event you are supporting)
Usually estimations between two things don’t matter as much as prioritizing those two things. Work on the thing that matters the most. If it takes 2 days or 5 days, in most cases it won’t matter - it’s still what you would work on, so functionally estimation wasn’t needed.
If it is a difference of 2 days vs 2 weeks (or some meaningful magnitude to you) then you start having opportunity cost that factors into prioritizing.
Estimation is more often used as a tool for “control and prediction” - how many times have you had incredible success because you controlled or predicted an outcome?
A good project manager helps flatten the curve. The most important thing they can do is prevent engineers from having to be 'specification detectives', where the engineer has to search other business groups for the actual details of the deliverables.
I've always been happiest working in places where I focused my efforts diving into the technology rather than interviewing salespeople to find out exactly what they promised the customer.
One method of estimating projects is using the old method Activity Based Costing. This can be used to estimate time-related activities as well. The key is figuring out your total utilization of time cost estimates and per unit of time cost drivers.
I have broader issues with estimates and deadlines but when pushed i follow a general rule.
If the problem is not some trivial configuration or otherwise mundane change I measure it in weekly units. With weekly units it's unlikely for you to have a blow out of more than 50% with out clearly seeing it coming whereas when you say it'll take a day or two you can so easily have a blow out of 100-200%.
At a former job when I had some organizational influence, we started doing this and called them “team weeks.” My goal was to sell the week x team model to avoid constant streaming of tiny straggling tasks. (It was an agency.)
I think the model works, but didn’t totally match that agency. It’s a good theory though
There was a claim I saw somewhere that the actual time required fits an exponential distribution with the estimate as the scale factor. Does anybody know the actual source, or a pointer thereto? This is assuming that the study actually exists and it isn't a "just so" story...
[+] [-] kornakar|4 years ago|reply
I was new to the field (but not new to software development) and there was this small software team doing programming tasks for the game. The lead developer was concerned on my performance after a few months I was there.
I remember him drawing an image excatcly like the second picture in this article (an arrow going from A to B). He said that my performance was very poor, and then he drew another picture that was like the circle in the article.
The way I worked was searching for a solution, going wrong direction a few times, asking designers for more information and then eventually landing on a solution (that worked, and users like it).
But I was told this is wrong way of doing software. I was not supposed to ask advice from the users (because the team "knew better").
He also told me that a good software developer takes a task, solves it (goes from A to B), and then takes another task.
After a few weeks I was fired from that job.
To this day I'm still baffled by this. The company was really succesfull and everyone knew how to make software. It seemed like a very harsh environment. Is it like this in the top software companies everywhere? Like the super-pro-developers really just take a task and solve it without issues?
[+] [-] jiggawatts|4 years ago|reply
The strange thing is that both approaches can be successful!
However, they are not compatible. At most, it's possible to have an out-of-the-box thinker above a team of robots, but that's about the maximum extent of mixing that works.
For example, in the robot-based team, managers generally don't explain any of the inputs and constraints that went into a decision to their underlings. This saves time, allowing them to manage more people to get more done. However, the creative types question everything, which irritates and frustrates them. In an all-creative team, managers will explain the backstory to the junior staff, giving them the information they require to seek alternative but compatible solutions. This takes longer, but then they can offload a lot of the decision making to the juniors.
Don't feel bad that you didn't fit in, it just means that you need to find a place with a corporate culture that suits you better.
[+] [-] resonious|4 years ago|reply
I can also tell you that maximum code quality is not always the priority. This is especially true in games, where you ship and then move onto the next project. Even online games nowadays often shut down after not long, and so they don't need quite as much maintenance as a successful SAAS.
Again in my experience, the super-pro devs I know are particularly good at knowing when to be fast and reckless, and when to be slow and calculating.
[+] [-] oakfr|4 years ago|reply
"everyone knew how to make software" -> if that was the case, you should have found help and support around you organically.
I hope you're in a better situation now. Don't let this kind of experience hurt your self-esteem. You deserved a better place.
[+] [-] a_c|4 years ago|reply
If your former team lead went from a -> b with no problem, maybe he is part of the circle. Afterall, when you zoom in the circle close enough, it appears a straight line. Or he could be a visionary, I can't tell.
An organization is like a shark, it needs to move forward. That organization can be an one-man team, where thinking overlaps with doing. In larger org, specialization is inevitable. The "no question ask, get things done" way that your former team lead adopted is desirable to certain degree, some of the time. But it is important to be aware of the duality. "Disagree but commit" is a virtue.
A fish can teach you swim, but it probably doesn't know it is in water
[+] [-] necovek|4 years ago|reply
What's weirdest about your story is that you were laid off a few weeks into your job. People usually get more time to get the hang of it even if they are senior, so I would mostly assume that it was a cultural fit rather than performance.
Some outsourcing/service (billed by the hour — which explains it for the most part) companies would look for very strict delivery cadence with focus on exactly the process you describe, but you'd be unlikely to have contact with the user in that case (just the customer).
Most importantly, if you ever get fired, be sure to ask for the explanation so you don't end up being baffled.
[+] [-] stkni|4 years ago|reply
So I suppose the real answer depends on the environment you're in. If the project is meant to be agile then you probably need a bit of interaction with the user to get the job done. If the project is not agile and all the requirements could be known up-front then you're probably wasting effort having programmers determine what those requirements are. IMHO.
[+] [-] lloydatkinson|4 years ago|reply
It seems that these toxic environments thrive when the top level of the management encourages this behaviour.
[+] [-] xupybd|4 years ago|reply
[+] [-] Igelau|4 years ago|reply
[+] [-] inDigiNeous|4 years ago|reply
Maybe you went over somebodys head, or maybe rank played a part in this. Some people also want you to follor their way or the highway, unfortunately I've seen this many times in different software companies.
Probably in this kind of teams execution is what matters, not thinking for yourself.
[+] [-] lrem|4 years ago|reply
On the other hand, I once mentored a person working in another company. I've been giving advice that I would give to a junior Googler. They got fired :(
[+] [-] siva7|4 years ago|reply
[+] [-] atoav|4 years ago|reply
Obviously the major chunk were always scenes and they are usually also the major contributor to the insecurity of the prediction. E.g. working with people who you don't know, weather, technical problems (broken, missing stuff), stuff that just won't work (animals, certain scenes with actors).
But in the end what always mattered was that there was a time plan for each day and at the end of a day we would know wheter we are A) faster as predicted, B) on time or C) slower than predicted. The next day would then be restructured accordingly by the production and usually you'd be back on time by the end of that.
I was usually spot on with my predictions and we never had any issue with getting the planned stuff done.
With programming the whole thing is harder, because it can be even more unpredictable. But what definitly always helps is when you have a feeling for whether you are too slow, on time or you managed to build a time buffer for future doom.
[+] [-] regularfry|4 years ago|reply
It's doable, but what people tend to forget is that it's work. If you want an estimate, I need to be able to expend effort providing it. It's an engineering activity that needs organisational support to do it at all well, but often you find an expectation that people will be able to pull an estimate out of a hat just having heard the faintest description of the problem, and there can often be a tacit belief (usually but not entirely from non-technical folks) that not being able to do so makes one incompetent.
[+] [-] frazbin|4 years ago|reply
[+] [-] anotheryou|4 years ago|reply
[my honest best estimate thinking off all I can think of] * X
So if it's making a yet another micro marketing website based on an pixel perfect photoshop design: x2If the design is not pixel perfect or missing responsive: the customer is involved: x3
If you refactor stuff in to new tech and it changes apis to other teams: new tech, other people, risks, no clear tasks: x5
[+] [-] ohthehugemanate|4 years ago|reply
Much more accurate are estimates of difficulty or complexity (small medium large, weighted numbers, whatever). The manager can then make an average conversion rate to time (with error bars), and use that for medium/long term forecasting. This is demonstrated extremely accurate compared to time estimation (but it is useless and breaks if you apply time/points pressure to your team, or even let them think in terms of a time conversion rate).
This is not new research. Kahneman's Nobel prize about decisions under uncertainty was in 2002. Put away the superstitions and stop estimating with time!
[+] [-] spacemark|4 years ago|reply
[+] [-] aasasd|4 years ago|reply
Firstly, programmers are notoriously and famously bad at estimation, so it's highly likely that you do need to find the multiplier for yourself. This illustration is something like fifteen years old by now: https://pbs.twimg.com/media/EyNRiYQXMAIshEj.jpg
Secondly, wise managers know to expect this, and do the multiplication themselves. But if you have managers who do the opposite and always scale the estimation back, expecting the results earlier that promised, then you need to use a second multiplier—which the manager will unknowingly annul, getting closer back to your actual figure. Probably something around 1.5 to 2.
However, if you need the second multiplier then you also gotta ask yourself why you're staying in that company.
[+] [-] KingOfCoders|4 years ago|reply
[+] [-] redler|4 years ago|reply
[1] https://www.quora.com/Why-are-software-development-task-esti...
[+] [-] capableweb|4 years ago|reply
[+] [-] notimetorelax|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] Aeolun|4 years ago|reply
[+] [-] RedBeetDeadpool|4 years ago|reply
[+] [-] dgb23|4 years ago|reply
I don't do that anymore. I try to push estimates as high as possible and then collaboratively cut down on requirements/promises/features to match an expected (time) budget.
This often leads to more pragmatic work items and sensible prioritization from the start. And it is an opportunity for general communication and understanding the value of things.
[+] [-] saalweachter|4 years ago|reply
A lot of the time when you are working the delays aren't just the uncertainty of an individual task; it's that you're working on several projects at once, you're attending meetings, etc, so that you might only average 2 hours / day working on a particular task or you might not be able to start a task for several weeks (depending on whether you work sequentially or in parallel).
You still need a realistic, achievable estimate for that first time, in case management calls your bluff, but distinguishing between "the amount of effort this will take" and "how long it will be before it is complete" can help set realistic expectations while making it harder for management to mistakenly think you need two months to complete a task that could be done in two weeks.
[+] [-] kilroy123|4 years ago|reply
Last potential customer I spoke with I did this. They were insulted by my estimate and practically hung up the phone on me.
[+] [-] jcutrell|4 years ago|reply
Tell people a short number now = immediate praise, long term pain.
Tell people a higher estimate, immediate negative; finish in time = delayed gratification.
[+] [-] mrzool|4 years ago|reply
He nailed that one for sure.
[+] [-] mattbillenstein|4 years ago|reply
You always see rookies make the mistake of just adding up the individual time of all the tasks - and engineers are famously bad at making horribly under-scoped estimates - so projects estimated this way have typically went over time by a factor of three or so as I've come to learn...
[+] [-] telotortium|4 years ago|reply
[+] [-] RedBeetDeadpool|4 years ago|reply
80% of the feature will take 20% of the time. The last 20% will take 80% of the time once you factor in all the other things like:
Just getting to "I got this feature working!", seems to only be a small part of the whole process.[+] [-] einpoklum|4 years ago|reply
[+] [-] jcutrell|4 years ago|reply
- Order of magnitude differences - hard deadlines (like a public event you are supporting)
Usually estimations between two things don’t matter as much as prioritizing those two things. Work on the thing that matters the most. If it takes 2 days or 5 days, in most cases it won’t matter - it’s still what you would work on, so functionally estimation wasn’t needed.
If it is a difference of 2 days vs 2 weeks (or some meaningful magnitude to you) then you start having opportunity cost that factors into prioritizing.
Estimation is more often used as a tool for “control and prediction” - how many times have you had incredible success because you controlled or predicted an outcome?
[+] [-] SkipperCat|4 years ago|reply
I've always been happiest working in places where I focused my efforts diving into the technology rather than interviewing salespeople to find out exactly what they promised the customer.
[+] [-] larrydag|4 years ago|reply
https://hbr.org/2004/11/time-driven-activity-based-costing
[+] [-] janto|4 years ago|reply
[+] [-] Guthur|4 years ago|reply
If the problem is not some trivial configuration or otherwise mundane change I measure it in weekly units. With weekly units it's unlikely for you to have a blow out of more than 50% with out clearly seeing it coming whereas when you say it'll take a day or two you can so easily have a blow out of 100-200%.
[+] [-] jcutrell|4 years ago|reply
I think the model works, but didn’t totally match that agency. It’s a good theory though
[+] [-] jmnicolas|4 years ago|reply
[+] [-] jyriand|4 years ago|reply
[+] [-] Ahan515|4 years ago|reply
[+] [-] andreareina|4 years ago|reply
[+] [-] jrh206|4 years ago|reply