Ways to annoy your senior engineer

I like your style

https://en.wikipedia.org/wiki/The_Dice_Man

>The Dice Man is a 1971 novel by American novelist George Cockcroft, writing under the pen name "Luke Rhinehart".[1] The book tells the story of a psychiatrist who makes daily decisions based on the casting of a die.[2] Cockcroft describes the origin of the title idea variously in interviews, once recalling a college "quirk" he and friends used to decide "what they were going to do that night" based on a die-roll, or sometimes to decide between mildly mischievous pranks.

https://www.reddit.com/r/Teachers/comments/15c3yd4/every_yea...

>The newest thing here is a flock of self-proclaimed “coin boys” who carry a quarter on hand at all times and constantly flip it. They have their entire personality revolve around coins, coin flips, and chance. When we went around doing an ice breaker, 4 or 5 of the kids said some variation of “I live by the coin and die by the coin” as their fact.

>Just about an hour ago, when I assigned the first assignment of the school year, one of the coin boys was bold enough to say “heads I do it, tails I don’t.” I told him if he flipped the coin he would be getting a call home on the first week of HS. He flipped it anyway and it came up heads (thank god for that at least).

>But then the other coin boy in that class flipped his coin and it came up tails. He said the coin has spoken and he’s not doing it. I say very well, enjoy your 0 and your call home— what a great way to start off the school year and your high school career.

When I'm told "I don't like that estimate" I take it as an invitation to negotiate (same as when you don't like a quote from a tradesman) and so counter with "OK, we may be able to shave x off of it if you give us y and z in addition to what we have now or if we cut w out of the scope".

As a dev who has now gone into management, I fully feel the frustration that you feel about estimate. I was on the "estimates are stupid and pointless" train for a decade and I've made the same arguments you've made here to my managers countless times over the years.

Being on the other side of it now though, I really take issue with sentences like "Estimates are useful to managers and executives to pretend they're in some type of control, but they're otherwise useless". In the places I've worked as a manager, with the managers, directors, and VPs I've worked with, I've never gotten the impression from anyone that it's about control. It's about resource and risk management as well as ROI.

Developer time is a limited and incredibly expensive resource at most companies and managers need to make sure it's used in the most impactful way that it can be. A project may make sense to do if it's going to take a month, but it may not make sense to do if it's going to take a year. Without some sort of estimate on the time a project will take, you can't properly prioritize work. There are absolutely projects where it's just like, we need to get this done no matter how long it takes, but most projects aren't like that.

Again, I totally get your frustrations, but the thing I always tell my teams is let's say you wanted to build a house from scratch. You call a contractor and tell them everything you want done and then ask for an estimate and they tell you, "I don't know. It'll cost what it costs. Every project is different and I won't know until I'm done."

I doubt you would hire them, right?

You need more information than that to be able to truly make a decision because at a certain dollar value it's just not worth it anymore. You don't need an exact dollar amount, but knowing whether it's going to cost $100k or $500k will completely change the value proposition.

Again, I totally feel where you're coming from with pushing back on estimates, but I don't think you're ever going to get away from them. With that in mind, one of the things I've started asking my teams to do where they're really pushing back on estimating is to take a day and think on it and then come back and give me two numbers. Give me an estimate that you're 90% sure is too high and a second estimate that you're 90% sure is too low. I've feel like that takes some of the pressure off because there's no exact number that they can be held to and it gives me enough info to make a decision.

You can tell they aren’t proper because if they were you’d finish half the stories ahead of the estimate and half after.

The moment you get judged on your estimates they lose all value.

> OK, those ones about shifting priorities? That’s startup life.

I've seen it at pretty much all scales. I think it's usually worse in bigger corps actually. Great point though - it behoves us to remember where the money for our technical airs and graces comes from.

I have worked at places that prioritized the wrong customer and ended up with a product that was tuned to work only for the ones who won’t pay more than what we originally offered the product for. Even inflation adjusted I’m sure it was less than $12M. You have to watch what your costs per year end up being for that check you got three years ago. The VCs will notice when they look at your books.

If you're following the bullshit that is SAFe/"Agile" at a startup, you're going to fail.

Capital-A Agile is project management for dummies that won't learn about things like GANTT charts, what "slack" means in links between dependent tasks, what a "critical path" is or how to analyze it, let alone things like S-curves and earned value.

> The only correct estimation is actually doing the work and looking at how long it took.

You seem to be missing the point of 'estimation' (as in, it is an approximate prediction, not an accurate measure). Admittedly management also tends to miss this same point, and that fact puts a lot of us on the defensive - but the answer can't be to throw estimation out entirely.

If you ask a civil engineer to estimate the cost and timeline of building a bridge, they'll get you an estimate. It'll likely be within 1-2 orders of magnitude of the actual cost/time, due to a bunch of unknown-unknowns that are hard to factor in (things like: how long the legislature will take to permit the build). But it'll still give you useful data about the differences between building a $million foot bridge, and a $100 billion highway bridge...

I don't think you read the article, or understand engineering if you discard the author's opinions with "taking yourself too seriously".

For example, reread the following paragraph:

> Few things are more disruptive to engineering than constant priority shifts. They make it impossible for engineers to plan or finish meaningful work.

Again, reread it and try to understand why the author stated that, instead of accusing them of taking themselves too seriously.

The problem is, if a leader asks for 3 weeks of work, and then every week asks for a different 3 weeks of work, nothing will ever get done. It belittles the engineer because that engineer isn't able to make positive contribution.

I suspect that you believe that engineers are merely pawns in a political game. Ultimately, companies that operate this way fail.

I disagree. I think it's pretty clear that they are saying that getting help from an anyone (in this particular case, an engineer) is a two-way street. Nobody likes being interrupted, especially when the interruptor has not made even the slightest effort themselves.

"Double it and raise it to the next time unit" still works.

A 1 hour job will take 2 days.

A 1 day job will take 2 weeks.

etc.

And since everybody knows that this is how management deals with estimates, there is no incentive to improve upon their own.

> The best way to handle situations like this is to leave, quickly!

If you find these situations frustrating, I agree. There is little hope of changing how software development is done in these companies.

> Companies that operate like this don't last long, because someone else will come and out compete them.

I take it that you haven't worked in many corporate environments. This is how software development is done in many, if not most, large companies. Their only competition are other companies with the same processes. Smaller companies can operate more quickly, and sometimes this can be a variable that helps with disrupting established behemoths, but it's usually not the primary one, and it takes many years to do so.

Sought after but many don’t know that is what they are searching for.

Getting the real senior devs in the enables and protects the process. Whether that process is winning depends on the total culture of humans segueing over things they want.

We make great layoff candidates because most of our code is something other people can take over maintaining. They keep the jackass who makes things nobody else understands.

> Or is it expected that good senior engineers skip recruiting and rely on networking alone?

Pretty much, yeah. I don't know anyone at a senior-or-above level who spends much effort sending resumes through the front door.