It's quite ridiculous for a number of reasons, well documented by research and experience: software engineers can't estimate how long something will take with any kind of accuracy.
That sounds a bit extreme? True, estimation is hard, but surely we can differentiate between 1-2 day work, 1-2 week work and a big scary project with a lot of risk. That's what T-shirt sizes are for.
And if a bug in a library stops you from completing your work so you have to develop a workaround, and adds several days to your “1-2 day task”? The estimate is wrong.
There are simply too many unknowns in other libraries and systems to be accurate.
I've always felt this is because estimation never gets treated as an exercise which might involve actual software engineering. You get handed a task you've never seen before, for a system you've never seen before, and asked "how long would implementing this take?" You never get handed a task which is "write as much of a prototype of a system which would do this, so we can estimate how much more work we think is invol…
It's not just that, but also we tend to estimate in the context of "if I were sitting at a computer working on just this problem, this is how long it would take." The reality is that there are meetings, high priority bugs for unrelated systems, interruptions from the business, coworkers and life, code reviews for other team members, rediscovering what you were doing before being interrupted, etc. Using time tracking,…
My friend's advisor in grad school (Physics, not CS) used to ask his students for various project estimates, and then he would double it and increase the units: 2 hours = 4 days; 1 day = 2 weeks; 2 weeks = 4 months; 2 to 3 months = 4 to 6 years = thesis project. My friend's estimated 3 month project turned into his 4 to 5 year thesis project. I mean, hey, it was experimental physics and his project ended up using a shipping container-sized faraday cage, scanning tunnelling microscopes, a clean room wearing a bunny suit, building stuff himself in the machine shop, writing software. All this for something that literally had not been done before and no one was sure it would work or what exactly would need to be done to get there (which starts to sound similar to some aspects of software projects). Plus the usual overhead like teaching ungrateful engineering undergrads (guilty!), hosting movie night at the lab and making liquid nitrogen ice cream, etc.
Isn't it possible to just go looking for another fast-growing small company when your current employer reaches that stage?
I just think that they wrote "fast-growing" as a positive attribute, when the logic of the comment would make it a negative attribute. Of course you can go looking again. But why not look for a slow-growing or not-growing small company, so you don't need to go looking so often?
Slow growth and no growth companies tend to be under a lot of pressure for cost-optimization (which makes sense in a lot of ways, but is grueling to live through…)
There is a talk 'Programming With Hand Tools' by Tim Ewald, where the author explains why he uses hand tools (as opposed to electric tools) in his woodworking hobby and how this might be reflected back to programming.
Doing the boring job at all is a waste of 50+% of your waking hours? By all means, do it if it makes the remaining 50% more enjoyable, but I think it’s possible to have both. I want to have my cake and eat it too.
But you know, at the end there should be someone who is cleaning the toilets and taking out garbage. You eating the cake and having it is a bit selfish.
Just because someone's cleaning the toilet doesn't mean that everyone must struggle. Yes, life's not fair to everyone, some people starve right now, while other throw away kilograms of food. Some people clean toilets while other people were born with gold spoon in their mouth and will enjoy whatever they want for the rest of their lives.
Daring to work at place that does not suck is not the worst offender to the world fairness, I think.
It's not just that, but also we tend to estimate in the context of "if I were sitting at a computer working on just this problem, this is how long it would take." The reality is that there are meetings, high priority bugs for unrelated systems, interruptions from the business, coworkers and life, code reviews for other team members, rediscovering what you were doing before being interrupted, etc. Using time tracking,…
My friend's advisor in grad school (Physics, not CS) used to ask his students for various project estimates, and then he would double it and increase the units: 2 hours = 4 days; 1 day = 2 weeks; 2 weeks = 4 months; 2 to 3 months = 4 to 6 years = thesis project. My friend's estimated 3 month project turned into his 4 to 5 year thesis project. I mean, hey, it was experimental physics and his project ended up using a s…
I’m in the wrong industry. That sounds way more fun than writing software.
The absurdity I see most is based in culture. Technology development is awesome the business plans and machinations are the absurdities. Any job that does not have a manager with a business plan or an org chart is a breath of fresh air.
Replace woodworking with "any hobby you want to pursue".
I find that a lot of people go to work thinking they enjoy it, and wake up later and realize it is just "work". This leads them to go off and figure out what they really enjoy, and they start doing that (they call it a hobby). Some of them ruin their hobby, by turning it into a full time job, where once again, it just becomes "work".
Most of the people I know who pursue creative/crafting hobbies alongside a software development job have chosen to work for well-known big companies, for prestige and safety, and ended up unfulfilled in their jobs. Most big companies are not good if you want to solve problems and build stuff. Especially "the enterprise", where software is seen as a cost center so the less of it the better. The effort of managing up e…
What's wrong with doing a boring job for a lot of money and then getting all the fun elsewhere? This actually seems to be the best way to do it to me
Because it’s soul destroying knowing your talents are wasted for 40+ hours a week
> Even my last team leader sent me a message out of the blue saying “I think I’ll run a bar. I want to be a bartender and listen to other people’s stories, not figure out why protobuf doesn’t deserialize data that worked JUST FINE for the past three years”. I worked at a bar when I was young, listened to the stories; the most annoying protobuf deserialization issues or 'Agile meetings' are freaking fun compared to th…
> Programming is fun, that is why you started doing it.
For some. I certainly started that way. But many of my friends at Uni started from a different point. I heard many describing how they choose computer engineering because it is perceived as a good career or because they heard it pays a lot. I'm not sure if those people have the same "Programming is fun, that is why you started doing it." to fall back to.