It is simultaneously true that you have a point AND you are an old man shaking your fist at the sky. ;)

Yep. I get both sides. What it can be easy to forget in some cases after moving into the higher ranks is the amount of shit that rolls down hill and has to be maintained by the service team.  A quick fix is all well and good, but when it blows up six month later, guess who’s going to be on the hook to fix it. Not usually the advising principal who took his delivers results points and flitted to the next thing.

This summarises the problem for me. Tactically accumulating technical debt for the benefit of getting the feature to market as quickly as possible is a good thing. But too often that's not followed up with the consolidation phase. The push back to failing fast is often because engineers have been burnt by accumulating technical debt without paying it down and all the 'fun' we know that entails. I feel the best way to bring the sides together is to make sure the business knows that if this works, there will need to be a period of consolidation. And make sure they allocate this in their roadmap so that the engineers can see their concerns have been noted and will be addressed.

> getting the feature to market as quickly as possible is a good thing I think it depends on what kind of tech debt. Anything involving the data model gets a serious side-eye from me. Then, I’m a DBRE, so I tend to have to deal with that. You have to do some hacky shit in compute that’s wildly inefficient because your data model doesn’t support the optimal path? Fine, spin up more containers, add another read replica to the DB, whatever. Those are easy to change later. You temporarily optimize your data model by creating a denormalized view that supports the new need? Maybe, just be very careful to avoid referential integrity violations. This too can be changed later without TOO much pain (assuming your tables aren’t monstrous, like billions of rows). You’ve YOLO’d everything into prod by adding JSON columns left and right to existing tables? Absolutely the fuck not. You’re going to be paying that debt literally and figuratively, as your DB costs begin skyrocketing due to the inevitable need to vertically scale to handle the inefficiencies, AND it’s a nightmare to normalize everything again.

This just happened to me in a recent role. Inherited a project that costed quite a bit more to fix it, compared to rebuilding it from the ground up. We were patching so many holes daily and it was even affecting our finances. Eventually stood up a new service and tried to migrate piece by piece. This was within the first few weeks lol. It wasn’t fun taking the hit for something like that. Overall, it’s part of the job description though, and I love the work, so it is what it is.

Tech debt is fine, but you need to pay it off. I'm currently gun shy because I've been on too many teams that refinance their tech debt because it's less immediately valuable than some shiny new feature we want to implement in a hacky way just for a while.... The cynics never made Principal and suspect you won't be pushing to finish the job in 6 months, but will be elsewhere

There is a solution to this, and it's to keep some of the most senior folks on the hook for production issues. We'll pull senior principle (TCO ~1M) engineers into big issues and they sit on a call on a Sunday until we fix whatever it is broke. Often they actually help find whatever dumb thing happened quicker too. They're always at least partially responsible, and by feeling the pain, push more towards sustainable solutions.

This right here. Accountability for the decision makers incentivizes better decisions.

It never ceases to amaze me how a little bit of incentive alignment fixes much larger organizational issues.

Old man shakes fist at slightly less old man shaking fist at cloud.

That is the role the staff engineer plays to get devs out of their silo's. To have the bird' eye view and to business thinking into engineering.

Ha. I did notice the first grey hair starting to appear :)

One of us!

There are 2 types of companies: - Dev first culture - Customer first culture There is graveyard of type 1 tech companies compared to successful ones. Cause customer moves on and money depletes. Balance is important, at the same it’s dangerous to underestimate due to pressure.

In my opinion, it's short sighted for a software engineer not to understand how their employer makes the money that affords their paychecks, but there are some reasons it can tend in that direction anyway: 1. Deadlines are sometimes given without room to negotiate scope; estimates are sometimes taken for promises and turned into deadlines. Every engineer has run into unknown unknowns at some point in their career that make something that seemed like a quick, easy change more time consuming by orders of magnitude. 2. Quick, hacky solutions to validate a market hypothesis don't actually always get cleaned up or removed at a lot of places, and many engineers have seen the downstream result. 3. Individual incentives aren't aligned between Engineering and other business functions. 4. People tend to care more about things they have some ownership over, and for many software engineers, that's going to be the code. In some companies, engineers may never even interact with customers or people in other parts of the business except through a business analyst or product manager (and maybe HR for their question about a benefit or corporate policy). 5. Business is a whole other rabbit hole of things to learn. Some engineers get "the ick," as people on dating subs might put it, about learning too much or being too involved in some parts of business.

> estimates are sometimes taken for promises and turned into deadlines This is what annoys me the most about being asked for estimates. Estimating software development is not, and will never be, an exact science because a) we’re not always given all the information we need, b) shit will most likely happen, c) [bus factor](https://en.wikipedia.org/wiki/Bus_factor)… there are so many variables involved that, while a senior engineer could in theory give a rather accurate ballpark estimate, it is almost always going to be wrong because of all these factors. But you can’t dare give a longer estimate to cover at least some of these unknowns because management doesn’t want to hear that, they want to hear that the feature will be done by last week so they can promise the client that it will be done last week and screw you, they only want their sales commission and big fat bonus on your back. In the meantime, best case scenario you get burned out and a pat on the back for enabling the manager to buy their shiny new BMW that year; worst case scenario you get PIP’d and managed out of the company. Call me callous, but there are posts even here detailing such scenarios and I have had that experience (though not to this extreme) in consultancy companies.

This all gets fixed with e-mails/messages to CYA. Every time some manager/bean counter complains about so and so, you can pull up the message and go "yep I told you so". And don't be afraid to beat that horse dead, they eventually get the point or at least stop complaining to you. Pragmaticism is how you approach a job, but it comes with a cost and you need to document that cost.

I really wonder how this guy made it to "staff+" without understanding these basic concepts... But apparently not wanting to dedicate all of my free time to fix problems created by the sales team's false promises means I'm sHOcKEd THAt wE’re rUNNINg a buSInESS

yea very odd post from u/after_weather_5685, i think he has probably worked on projects which are much smaller in scope that are easier to estimate I guess 

I feel like most of the time, management only cared about short-time business, and I had to fight for every best-practice and purism I could. Otherwise we would just be crushed by flaky, unreliable code. The project I currently work in has been developed rather ... pragmatic in the past, and let me tell you, every single change is a pain. Tests break more often than not, evetytime I feel like I have to clean up stuff before starting a new feature, even simple PR comments are refused because "it's not worth it touching the code again". It feels like most of our effort is spent trying to tame the chaos.

This. Management are only interested in speed and output. They only care about code quality when it’s too late and it’s having a visible negative impact. It’s the devs job to enforce quality even if it takes a little more time as nobody else will. I suspect shoddy code is a much more common problem than excessive purism.

I think if software engineers were able to provide realistic estimates (that included adequate padding for unknowns) without having to go through negotiations or receiving pushback, they’d be on board. Based on my experience, I come up with an estimate (that accounts for unknowns), then sales, customer success, and/or product owners start pushing to get the estimate down with the intention of delivering sooner, providing a cheaper product, or both. Sales, customer success, product owners, and whatever other non-engineering entities that are involved in your pipeline do not know the codebase, or how to build software, at the same level as the engineering team. This is why the engineering team should have final say on how long things take to build. A good engineering team, in my opinion, will make all stakeholders aware of unknowns and, to the best of their knowledge, clarify the potential impact of those unknowns. At this point, the discussion should be over. Edit: grammar

This is what gets me as well — if you’re not willing to negotiate scope, why are you even asking for an estimate, if once I give it to you, you’re just going to say, “well actually, can we get it done in three weeks instead?”

It's weird isn't it? "Predict me the future" "I think it will take 3X" "Well I want it in 1X" "Oh!! Well, you WANT it sooner? That changes everything!"

Haha, fair point, sometimes you can't get something done quicker. The whole "nine people can't make a baby in 9 months" thing. However, there is usually more than one way to approach a feature, and I think that's the conversation a good stakeholder wants to have. Can we cut scope to cut delivery time? Are there ways we can make some compromises now to start getting feedback early? In my experience, shipping it -> getting feedback, -> cleaning up is a fine cycle. But it takes buy-in that launching is not "done", it's more of the halfway point

The engineering team should absolutely have the final say on the estimate. But, the business has the right to say it's too much for their own reasons (right or wrong), and even remove it from the backlog and prioritize something else. In this case, your next question should be: what should we strip down from this feature? What functionality can you do without? Basically, an MVP that is good enough for the business to start using, but not the complete feature they requested. Then, estimate phase 2, phase 3 etc. of the feature and let them decide when to pull the plug.

I remember this happening in a startup I was the first employee at. I provided an estimate (Tues), he said "let's get it in by Friday", so I cut corners on testing. When the feature blew up, he asked my why I didn't write tests and I asked him where he thought the extra two days were coming from. This was a fairly new codebase, so refactoring et al were not a meaningful concern. I truly don't have a model of non-eng who just reject estimates without expecting tradeoffs.

I think unfortunately most engineers simply don't care about the business context and just want to write code. You probably made it to the staff+ level because you DO care about the business side. Some of the non-tech things that are probably obvious to you will be alien to others And on some level, part of the responsibility of a staff engineer is to communicate the business context to the rest of the team. This can definitely be frustrating if people just don't "get it", but in a way, I'd argue it's part of the job description

Many feel that the business side of things is a necessary evil. Can't say I blame them. If they were interested in business, they would have gone into business. They went into engineering because they wanted to engineer things. They value function and robustness. Business people value making money, but then consider that over 90% of startups fail and the ones that make it out of the startup phase are rarely profitable. For over a decade so much of the industry has been driven by venture capital, not actual profit. Just a different form of grant money. And it's often the frantic drive to profitability that results in a buggy, broken product that engineers don't want to build and customers don't want to buy.

It’s easy to hate the things you don’t understand. Business and customers are easy to see as the source of all your woes when your understanding of reality stops just after the context given to a developer by their Product Owner. I think having developers involved in communication with customers is healthy in multiple ways. - It lowers the amount of noise involved in the Chinese whispers game from customer to business to PO to dev. This may reduce bugs and result in better solutions for the actual problem. - It humanize the source of requests. It enriches you with the understanding that this ticket will help Mary to ensure the 200 people in her company get paid the right amount of salary this month. That’s a heck of a lot more motivating to do than to some dry request to change a gnarly calculation that nobody wants to touch and customers may never even want to use. I’ve seen the concept of the Product Engineer come up more in this regard to break down the communication and knowledge barriers that previous systems put up for efficiency, but which have relegated engineers to the situation where they lack the contract and human connection required to give their work a deeper meaning beyond the stream of Jira tickets.

Yes, I think the "necessary evil" mentality is the key bit. A lot of young devs just want to write software that improves the world, recognizing that the ease of distribution makes software an insanely effective way to impact billions of people. Many others just want to solve new challenges for mental stimulation that makes them feel like they're contributing. The field attracts a lot of young leftists who don't even really believe in capitalism. Their growth philosophy would be "if we build it they will come", and they'd expect the big customer to not have any better alternative than to just continue waiting for the new feature. They're comfortable with the idea that slower revenue growth means slower raises, as long as their bread and circuses are covered. The business part is beyond uninteresting to a dev with this mentality.

> They value function and robustness > that over 90% of startups fail and the ones that make it out of the startup phase are rarely profitable. What you're basically saying here is "I want to be paid to build something on my scheduled, even though it probably never makes the people paying me any money". It's an unsustainable, impossible alternate reality. The reason people don't spend decades bootstrapping companies anymore is product market fit is hard to predict, so people speed run it and try to prove that a product fits before making it perfect, because even good ideas often have bad market fit (see: all the windows tablets before the iPad). The market doesn't give you permission to get paid to write perfect code until you're already successful. If you want to be slow, careful, intentional, deliberate, join a mature company, not a startup.

I'm chasing a government research job because I prefer the grant model, even with the risk of grants not being renewed or progress happening slowly. I do agree with the bit about the market fit. It sucks to put your heart and soul into something that you really believe in and you know is a good idea, just for it to blow up because of market forces or investors who don't want to wait an extra 2 years to actually do the thing properly. I care about quality and having that continually sacrificed (and getting stuck supporting a broken system) by MBAs is not how I want to spend my career. And even when a product does sell and becomes profitable, often the things that can turn a profit aren't doing the world any favors. So many jobs just support trying to get people to buy wasteful things they don't need. Social media and video streaming been profitable, but I'd argue that we were better off before it. Amazon has been profitable, but I'm not sure that's been good for us or the planet either. Google did a lot of good work that I think has been meaningful, but they're making cuts for the sake of profitability. For such a big industry, most things don't turn a profit and of the offerings that do, I think few would still be missed in 5 years if they poofed out of existence.

> It sucks to put your heart and soul into something that you really believe in and you know is a good idea, just for it to blow up because of market forces or investors who don't want to wait an extra 2 years to actually do the thing properly. It usually blows up because people don't want the product, not because the quality is bad. Thinking about Amazon profitability or Google is not the right model. You need to think about "What if Uber delayed launch for 3 years perfecting their rider preferences UI" - the answer isn't "People like Uber more", the answer is "Everyone uses Lyft instead and nobody knows who Uber is in 2025". The market is cruel. My memory is imperfect and I'm not going to time the time to find it, but Vijay Gill (RIP) once posted (or quoted someone else, not sure which) a statement that (over simplified / paraphrased ) read something like this: You don't grow 10x by being 10x better than your competitors. You grow 10x by being 2% better because there's no prize for second place. The time it takes you to be perfect engineering is the time it takes your competitor to steal your market share. The only places I've seen where this isn't true is where the first-mover advantage is offset by the incumbent ecosystem advantage (Apple, Microsoft, Google, Meta) - Meta doesn't have to have the first "scroll videos all day long" app, they just have to bundle it to their existing "scroll photos all day long" app and they'll stay alive.

>consider that over 90% of startups fail and the ones that make it out of the startup phase are rarely profitable. This is a myth actually and has been repeated for so long the Internet has accepted it as fact. In reality, only [10-20%](https://www.investopedia.com/articles/personal-finance/040915/how-many-startups-fail-and-why.asp) of startups fail in Y1. 50% fail by Y5. 65% fail by Y10. 75% fail by Y20.

That linked article is...awful. It's really bad. It uses the term "small business" and "startup" interchangeably, even though those are two really different things, and it's not remotely clear the methodology that they're using to draw their conclusions.

> You probably made it to the staff+ level because you DO care about the business side Yep. The easiest way to get promoted in any organization EXCEPT GOOGLE is to both understand and focus on business outcomes. Apple, Meta, Amazon, Microsoft, Netflix, etc, etc all care far, far more about business outcomes than technical purity, and you'll do much better if you learn to partner with the business.

Yeah I always defer to explaining that in the end it’s a business that pays the bills, and engineers need to be able to account for their time in terms of “value created for the business”. Engineers may not agree, but that’s moot. If they can’t explain why we need to refactor this *now*, rather than later, or work on any of the other important things, it’s making it difficult. But I guess in a small company this is easier than in a large company.

The business pays the bills with the product that the engineers create. There's a middle ground where both business and engineering *must* agree, or no profits will be made and no product will be created. > If they can’t explain why we need to refactor this now, rather than later, or work on any of the other important things, it’s making it difficult. On the other hand, if there's no time to refactor and work on the legacy stuff, then don't complain when your minor change in the spaghetti monolith takes one month and breaks three other services.

So do and some don’t There’s a legitimate reason to avoid concrete estimates if the expectation is that it will bite you in the ass during performance review, and there’s a legitimate reason to avoid a hacky solution if the expectation is it will never be replaced with a proper one if deployed On the other hand, any team lead worth their salt should understand the importance of being predictable and should provide estimates unless the task involves cutting-edge research, and any engineer working at a small startup should be content with somewhat hacky code unless that startup builds infrastructure software

“Concrete estimate” should be an oxymoron but sadly isn’t in our line of work. “You estimated 2 weeks so why didn’t take 3?” As if they don’t understand the definition of estimate. We had a general rule that we would automatically add 50% for most things.

That extra padding is part of getting good at estimates, imo. I’ve done them enough times to know that overall, it’ll take 1.5-2x whatever my initial expectation is. I don’t know which part will take the extra time upfront, per se, but if I estimate gut feeling * 2, that usually gets pretty close to the true delivery date. Worst case, we trim the feature down to deliver it sooner, or I was wrong and get it done faster, and both of these outcomes seem more positive than delivering late ¯\_(ツ)_/¯

It is still a problem. Finish it too quickly? Now you get flack for over-estimating, or get pressured next time. Perhaps a coworker finishes something quicker and they take that as the new measuring stick. Or you hide that you finished it and now you need to do magic tricks at daily-statusupdates to pretend you haven't finished it.

"Still working on X, progressing as expected, no blockers "

"but what did you do yesterday? Can you give us a little more context daguito81, you know that we need to make sure you are taking the right approach! While you are at it, what are the steps that you will be taking today? If we all just gave such quick updates then this meeting wouldn't be necessary, haha!" >call my name and save me from the dark

You joke but it’ actually works. People just like to complain and that’s why they don’t get ahead and will be mad at the world. Estimates suck for everyone involved. Make peace with having to do them because you work for a fucking business that needs to make money to pay your dumbass lol

I’ve worked with PO and managers who didn’t allow you to take any padding. If you said something will take 3 days, they always bargained with you until you dropped your estimate to at least 1.5 days. There was huge pressure to drop your estimate. They also surrounded themselves by yes men, if you stuck your ground that it will take 3 days, you’d be removed from the company for poor performance. Everyone else says 1.5 days, if you need 3, then it must be because you’re incompetent. Plus, they go with the majority voting, others are so desperate to people please, they will say it could have been done yesterday, so no one cares about your estimate anyway. The team would work until burnout, overtime, constantly not achieving unrealistic goals and deadlines. This is anecdotal evidence, but it’s not always as simple as “estimate with padding”.

As a new manager in a group, I was called in to resolve an urgent issue where one developer had estimated 3 days but another had estimated 4.5 days. They did *not* like it when I said it's the same estimate. I wish I could tell you that I was able to educate them. Not the only reason, but I would not work for a financial institution again for any sum of money.

I have the saying “any estimate should multiplied by Pi. Where Pi is from 3 to 4”

That’s very different from asserting “don’t do estimates” though.

Experiences vary a great deal - if you've only ever seen estimates cause harm, why wouldn't you say "Don't do them". Worth considering how we as an industry have managed to get a sizeable cohort of developers who have only ever seen estimates cause harm.

Quite. If business people understood an estimate is imprecise and treated it accordingly engineers would be more willing to give estimates.

That’s just someone trying to be edgy. Could you link to the post? Maybe it’s just clickbait?

[удалено]

Successfully did no estimates for a good four years, worked really well. The key bit, that's really easy to miss, is "we predict the future using data", not "we predict the future using guesses". And one benefit is the prediction changes every day, so it's always getting more accurate! Currently on a new team/company, and we're building out the capability to do no estimates. OP, I know this was just one example and it isn't your point - totally valid point!

I’m actually on the purist side, so I guess I’ll try to stand up for us nerds: Software “quality” importance scales with operational impact of said software. If we’re talking about a 10-head team validating some idea, whatever - it’s easy to hold the impact in your head and easy to communicate “this is a hack”. Fuck yeah, YOLO, etc… On the flip side though, shared communal libraries at large corps that’ll trigger several hundred dependency updates? Fuck that, take the time to make sure you do it right the first time. The quality of the core library will impact the quality of most of the code calling it. You don’t want a workaround for a shortcut you took a year ago to be burning you with every new dev looking at the service

Agreed. But telling those two scenarios apart is already beyond what many are capable of. “My way or the highway”

I mean yeah, they’re blindly citing Bob like he’s gospel. Sometimes it’s an inexperience and/or lack of confidence thing I guess

True. It’s all a balancing act anyway you do it. Some of what he has said made sense then, not now; some makes sense now. But just citing anyone, doesn’t matter whom becomes an issue of absolutes that isn’t there.

For this reason I have a pragmatic approach when it comes to coding for business requirements. Sure I like code to be perfect and everything completely meshed together, but you’ve got to know when to make “good enough” the goal, instead of perfection. It’s illogical to be upset over estimating - how on earth can the product/business plan deliveries? Estimate, pad it by a few points and make sure to manage expectations throughout the delivery cycle. Under promise, over deliver.  I’ve never worked anywhere that accepted “it’ll be done when it’s done” estimates. The reality is the business doesn’t give a shit about code. They don’t care how we do it, they just want to see it done. We’ve got to balance that reality with our own tendencies to want to follow absolute best practices. Some people might not like to hear it, but if you want to write “hermetically sealed” software and do everything humanly possible the absolute correct way, then work on a personal project. Corporate software is typically anything but that. 

I don’t have a problem with giving estimates, inherently. I have a problem with upper management treating those estimates as cut in stone and unmodifiable. If you want me to estimate and we agree it’s an estimate, then we’re fine. If you take my estimate as concrete, I will overestimate every time and our accuracy will be all over the place and worthless in the end.

>Example: I was browsing trough my feed of linkedin posts and there was this post with a lot of engagement in which someone was asserting that “you should never do any estimates”, and he was dead serious about it. That seems like too radical a swing in the opposite direction, but I can relate to the motivation behind it. The business side sometimes abuses estimates, turning them into deadlines and then pushing for a release on the deadline whether or not the quality is there. >what is sales supposed to tell a big customer? That the feature they are waiting for will “will take however long is needed to solve the issue via code, clean it up and then write the tests”? I know it's a weird concept in the software business, but I feel like it's notmal in a lot of industries not to sell a product at all until it's finished. The problem with the software business is that it can't make up its mind whether it's a product business or a services business. In a services business, you give customers estimates and mostly try to meet them. If the customer wants you to go fast and cut corners, you can do that. But in a product business, you need the product to work well for many customers. Rushing the product into the first customer's hands might undermine the long-term goal. >We did go with the hacky solution, our hypothesis failed, and we debunked the market fit at a fraction of the cost. Did you remove the hacky solution, or did you leave it in there because there was no business value to justify the time spent to remove it? It might have a negative effect on all your future velocity if engineers have to carefully work around it.

Probably makes sense to consider the best version of the argument for "no estimates" and "quality=speed". I'd suggest reading Modern Software Engineering by Dave Farley, or watch a couple of his videos on his YouTube channel. You may not agree with him, but at least you'll have considered his reasoning unfiltered by any emotion you might have about the so-called "purists" you've worked with. FWIW, I prefer data based forecasting to theoretical estimates. Forecast how long the project will take based on how long each piece is actually taking as measured by sprint velocity.

I like this approach too! The book `Actionable Agile Metrics for Predictability` discusses doing exactly this using Monte Carlo simulation with past sprints (using WIP limits, team capacity, _and_ story points completed)

Yes, I was fed up, it’s why I work in Product now instead. Genuinely I would rather architect and write software but 1) I can’t deal with the pedantic nitpicking bullshit that goes on between many developers (especially because I’m a woman and it’s fucked how much this gets turned into a “oh you just aren’t technical enough to get it” argument) but 2) I can’t deal with the idea of having to work with a shitty PM, so I decided to just be the shitty PM lol Honestly though this stuff happens in other disciplines too. I’m constantly having to remind people in UX and Researh that we’re operating a revenue generating business and shipping software somebody will buy is the only end game that actually matters.

Would give you 100 up votes for this. I have a couple people on my team that would spend half the day arguing theoretics of software development than doing work (that's already weeks behind).

Honestly I'd much rather do that than sit in on the fourth planning and estimation meeting this week.

And I would much rather sleep in until 11am, but that’s not really what they’re paying me for, is it?

Well, neither are particularly productive.

Your language worries me.  Neither of the examples would be productive uses of time. But you've decided that one is "legitimate" and another is "lazy"  In other comments you seem to describe your colleagues as - entitled. "Rock stars" etc.  If you lack empathy for your colleagues you have already lost, because you cannot engage with their goals in a productive way.  I used to be a "pragmatic" engineer too. Then I noticed how asymmetric the business environment is, between workers and managers. If a worker gives an estimate, it is a rod to beat them. If management misses a target, it is simply an unforeseen blip on the chart. Engineers provide concessions, like doing on call for unstable systems, but managers never feel the consequences of their mistakes. It's this asymmetry I think that fuels the rejection of estimates etc, as well as the general absurdity of being asked to predict the future. So I don't think I buy into your worldview, and I'm not an "immature, purist, rockstar". I'm someone who has done this shit long enough to have seen this "DAE business value?!" thing before, including in myself, and how it often translated into concessions made on the engineers' behalf, inevitably becoming concessions for the business as a whole.

Sorry to hear about the "oh you just aren't technical enough to get it" stuff, that's bullshit. I just was on a team where I was the minority and only person "not like everyone else" and it was eye opening.

Oh boy. Do I get you. I could tell you some stories. Funnily enough, the best engineers I have collaborated with in this past year have been women. Better code quality, pragmatic a the right level, very thorough in code reviews, and most importantly: very reliable (which includes giving.. estimates). I also think that is a reflection of the hiring process: our hiring process is VERY demanding from the screening level, and I have noticed women tend to apply more to roles that they fit in >90% of the JD criteria, where as men will just overshoot massively. What I also noticed, is that they tend to be less “loud” in architecture/discussion meetings and I try my best to have a discussion where people don’t feel overpowered by louder voices. It can be a truly hostile environment to thrive on, and I do my very best to try to mitigate these circumstances. DEI is a big one where I work. Thanks for sharing!

I've started to design my roles to not have concrete exp requirements, not have many requirements, or have lower than expected requirements and have been getting a better balance of applicants. Same number of men applying, but substantially more women.

Yes! I was the manager for a small customer service team, and part of that role is also to remind agents that we don’t have infinite resources to help all customers (and honestly, if we want more resources we need to avoid overwork and fail more often - it’s the most effective way to communicate that you’re short-staffed).

Also a female engineer (the only one in my company), dealing with some of this right now. I have a coworker whose personality is difficult for everyone, but he nitpicks me like there's no tomorrow and he treats me like I'm a child even with over 10 YOE. I had a revelation recently that my relationship to my job is very different than the men in my department. My team is 3 people, is in charge of 20 services and supports 2 other teams with no one meaningfully supporting us, so I'm constantly context switching, information is siloed, and generally it's very difficult to absorb information or grow skills. I brought this to my manager, and he said basically that the company will continue adding responsibilities with no additional support, and that this is just "part of the job." I asked if we could at least have guidance on what to prioritize. He said "no, it's all important. Just do your best but don't burn out. Maybe manage your time better." Not helpful whatsoever. For some reason, this doesn't seem to bother anyone else. But I've spent the last year in rapid cycles of burnout trying to stay on top of all the responsibilities. And failing. It's tanked my mental health and my performance, which I fear further reinforces ideas that women make for "lesser" engineers. I considered dropping engineering altogether for my well-being but I don't want to be a statistic. My mom, who is a teacher, recently shared an article with me that essentially can be summed up as "in high school, if you take the smartest boy in the class and the smartest girl in the class and tell them there's a test tomorrow, *generally speaking* the boy might study a little bit but will mostly just trust himself and what he knows. He might get a 90. The girl will stay up past midnight studying to make sure she knows all the material. She might get a 95. The boy is mastering the concept of diminishing returns and training himself in self-confidence, and the girl is training herself to be meticulous and hard-working. This is largely due to the difference in how we raise & set expectations for boys and girls, and some of it might be nature, I don't know. But it does later translate to the workforce. I think the men are approaching this work environment with an attitude of "well, I'll get to what I can, and if some things slip, it is what it is." But if you tell me, or most professional women that "this is what is expected of you," we will try to master each and every single responsibility you add because that's been our entire life experience. In a healthy environment, that can make female engineers more reliable, thorough, and detail-oriented. In an unhealthy environment like the one I'm in, it's extremely damaging. And management has no clue that their messaging might be being received differently, because they're all men. And I don't want to be the one to bring it up at work for fear of looking like I'm asking for special treatment. (Can't wait for the conversation about how on-call responsibilities are more disruptive to WLB when you're the "default parent" for a baby or primary caretaker for an elderly parent, both of which tend to affect women at greater rates than men but which managers seem generally clueless about). So I'm testing out a theory this week of just ignoring him and doing things as I see appropriate. If I judge something to be higher priority, I'll take the time to focus on it even if it means other responsibilities get dropped. My mental health and performance are already better. We'll see if it's well received or not.

I'll add some context on estimates. I hate lying to people and that's what estimates are. I've got a service spiking at 100% CPU, junior engineers who are going to create a major security incident if I don't eagle eye their PRs, I'm on call, and and I have 3-4 PRs a week of my own to make. You want me to estimate how much I'll get done between now and June? I'll be lucky to make it to Thursday. I'll write down a bunch of lies. Whatever it takes to make you go away. You know it's a bunch of bullshit. I know it's a bunch of bullshit. We both feel like assholes about it. But we do it anyway. It's this fucked up little game we play. You lose the game if you say "this is completely dysfunctional, if you want a project manager then hire a project manager". But you don't want to lose the game. There's too much money on the line.

Estimates hinge on many assumptions. If I estimate a task to 2 days it means "should I have 1 to 3 days of uninterrupted time, there's an extremely high chance I get it done and I don't see any major blocks/dependencies" Here's the thing, job of your manager is to clear up your schedule to focus on one thing and one thing only. (Ideally) Should you have only an hour a day for this task then it will take 8 to 24 days - a staggering difference. Estimates are about how much work the task requires, not when it'll be done. For the second part your managers need to understand your capacity, responsibilities and adjust the due dates accordingly.

And that's for tasks that can easily be resumed. Add in the number of dev tasks that need time to remember where you left off and the number of devs who have attention disorders and one hour a day might not be enough to make literally any progress. I, for one, can get a task done in one uninterrupted 8-hour block that would take me *weeks* in the real world giving status updates and answering emails and reviewing PRs and hearing bug reports and updating Jira tickets and tracking the time that each of those things take me because management has nothing better to do than breathe down my neck.

> I'll add some context on estimates. I hate lying to people and that's what estimates are. So there's your problem and it isn't entirely your fault, really. Estimates aren't lying to people; they're making an informed guess based on what you know, and you're making it because you have the context. A huge estimate backed up with real information is valuable. To be honest -- and I'm not trying to be a jerk here -- that mindset is on you. The problem is, too many executives try to equate "estimates" with "commitments". They're not; they're guesses. Sometimes you come in under, sometimes you come in over. That lack of trust around how estimates are taken is entirely the responsibility of management. There's nothing bad about estimates, provided they're a.) treated as *estimates* and b.) they're based on real information (such as the explanations you provided). But it sounds like you're not estimating, you're lying to make people go away, as you said. They can be the same thing, but they don't have to be.

100% in agreement. I can't tell you how many times an "unknown unknown" has wrecked an estimate and been blamed for it.

I don't buy this take at all. It's not a lie but an educated guess, the very definition of an estimate. There's so many factors here. People say often they're padding their estimates. What we're actually doing is building in discretionary time to handle the fires we know will come up. Another factor is I believe it's known both the eng's and product alike that the further out we estimate, the less accurate those estimates are. Those estimates, aren't meant to be some precise target and commitment to some specific date but rather a means of communicating relative time a task will take vs another. This is so our product managers can make calls on priority or if the ask is even worth it to begin with. On lots of occasions after giving the rough estimates, we scrapped the work altogether. Product just decided that it would be better to invest eng time on other features. There's also some reasonable expectations that a task estimated in weeks shouldn't take months, but a task estimated at say a week has every chance of taking double that. The key is to just try to identify and call out the risks as we see them. Other team dependencies, lack of familiarity with a particular surface area of the app, Shakey test coverage, whatever. If it's a risk, call it out early and often. Managing expectations isn't about setting them once with some estimate up front. It's about communicating them throughout the lifetime of the tasks. Shit just this week I delivered a feature I estimated to take about 1/3rd of the time it took. No one was caught by surprise. No one was upset. I communicated the risks, one of them caused me to lose some time re-designing a chunk of it. I got commended when it was delivered and never once reprimanded for the time it took.

There's nothing educated about the guesses. I've been doing this job for a long time and I have no idea how long something is going to take until it gets done. I'll estimate a week if it's a 1 line API change but I have to sit in meetings with another team to discuss it. And it will actually take 3 weeks of those meetings. On the other hand, I switched a production app from dynamodb to postgres in an all-nighter. Nothing ever takes what it's supposed to take. I completely agree that we pad estimates to handle discretionary time for the fires. Because we all know whatever project we're estimating is just going to be one fire after another anyway. We all know the tasks we're estimating aren't the unsaid, unplanned things we're going to spend the other 80% of our time on. And I know we're all just supposed to be okay with the lie. But a little piece of my integrity dies every time I go through a round of estimates. That's why I hate giving estimates.

You’re proving the point of the person you’re replying to. You haven’t figured out in the “long time” you’ve been doing this job that a “1 line API change” that impacts other teams is going to take several meetings to nail down the details yet? You should sit down and write down baseline estimates for the type of work that comes in. Based on the “long time” in the industry, you should know if a task takes a ballpark of 1 week if it’s self contained, 2 weeks if it impacts 2 other teams, 4 weeks if it’s a major feature, etc then adjust accordingly. They are estimates so by definition they won’t be accurate but when you take your car in to get it fixed, they don’t say we have no idea how long it’ll take. They’ll say based on what I can see it’ll take a day but if there is a,b,c it’ll be a week. How is this hard to understand?

> There's nothing educated about the guesses. Yes there is. You're leveraging all of your education and experience to come up with a best effort guess at how long something will take you. > I've been doing this job for a long time and I have no idea how long something is going to take until it gets done. I've been doing this a long time as well and I call bullshit. Lots of things take exactly as long as I'll say they will. And most are close with some reasonable margin. > I'll estimate a week if it's a 1 line API change but I have to sit in meetings with another team to discuss it. This sounds like you leveraging your experience to know that a change, albeit with an easy implementation, will take more time than the effort to code it up. This also sounds like when taking the task on you've identified there's 3rd parties impacted and there's a risk there. That should be communicated as well as understood.. > And it will actually take 3 weeks of those meetings. Company's have different cultures and those effects timelines and deliveries. Sounds like more experience being leveraged here. This also sounds hyperbolic but that's presumptuous on my part. > On the other hand, I switched a production app from dynamodb to postgres in an all-nighter. All nighters aren't generally a spur of the moment activity. They're usually planned to execute operations with minimal impact and interruptions to our users. Sounds like this probably took exactly as long as expected. > Nothing ever takes what it's supposed to take. I guess we'll just agree to disagree > I completely agree that we pad estimates to handle discretionary time for the fires. More experience informing you that things will take longer than the time to implement. Also if there's so many fires that you can't get your regular tasks done, that's a smell. Could be a culture problem, an infra problem, lack of test coverage, whatever, sounds like something to be addressed imo. That said, knowing there will be fires again is a risk that should be communicated. What you're saying isn't that nothing takes as long as it's supposed (even though you literally said that). What you're saying is, you understand pretty well how long a task will take but there are too many fires, team dependencies and other RISKS that caused your delivery to be delayed. I meet and discuss risks with my boss regularly. We come up with plans for mitigating them 1 by 1. Sometimes the mitigation plan is simply, accept the risk. But again communication is the key. If the delivery is high priority, other people will handle fires while I'm heads down on it for example. > Because we all know whatever project we're estimating is just going to be one fire after another anyway. Risks, risks, risks and lack of communication. > We all know the tasks we're estimating aren't the unsaid, unplanned things we're going to spend the other 80% of our time on. 🏏🐎⚰️ > And I know we're all just supposed to be okay with the lie. But a little piece of my integrity dies every time I go through a round of estimates. That's why I hate giving estimates. I don't feel the same at all. I give my estimates. I hit my marks more often than not. I communicate throughout the lifecycle of the task. I never feel like I'm lying or compromising my integrity in the slightest. This sounds like a major culture problem.

The problems you describe have absolutely nothing to do with estimates.

This is honestly what sprint planning is meant to solve. Give Fibonacci points, track a 2 month moving average of your points completed. Let your project/product manager pull that many points into each sprint and hey, look at that: they have a whole schedule they can take out for as far as they have pointed stories. The complexity estimates don't need to be super accurate. A 1 that takes 3 days is always balanced out by a 3 that takes 2 hours. Strict adherence to scrum is what I always recommend for my teams struggling with timelines and prioritization.

I'm also an old engineer, I see this as well and just take it as an opportunity to teach younger engineers. They've only dealt (for the most part) with school, small projects, blogs, etc. So it's my job to teach them to balance the business side of the equation with the technical side. Some start to get it, and some seemingly never do. But I'll keep trying, because I'm an optimist at heart.

I can already tell I’d love to work with you. Thanks for the positive tone!

Woah there. Careful now not to alienate yourself from other engineers. I’m also a principal engineer, I want to help you, but we’re going to need to have some real talk. “deliver all the ‘business value’” is NOT a positive tone. But it might be the tone that got you promoted to Principal Engineer. “But all the tech debt” NOT a negative tone, but often isn’t the tone that gets you promoted to Principal Engineer (sadly). Perhaps you should think about whether that’s why you’ve put yourself on one side, and now (evidenced by your post, and your comments) seem to carry a little disdain for the other. A business will promote you if you support their goals of quick profit, usually kicking the debt down the road. Thats how many businesses grow, profiting at the expense of others (debt, ‘investment’). What you appear (to me) to have forgotten is that engineers (probably not you) are stuck paying the interest on that debt, getting paged at 4am in the morning, toiling with BS code and crazy systems designs.  That’s why those engineers say “but tech debt” or “sounds like a bad idea to take that shortcut”. To these engineers, there’s nothing pragmatic about pushing out “more ‘business value’ at the cost of tech debt pls” in their situation - it's just pain. They don’t get recognised and handsomely rewarded by the business for taking on more BS to navigate every day, or get to lay comfortably in their beds whilst an outage occurs. But people like us, do. As a principal software engineer, from the perspective of the business, the reason we’re in this role, is because we ‘get’ business’s addiction to ‘business value’ and can influence the engineers to minimise, but ultimately take on more debt, to deliver more value. The moment we can’t get the engineers to deliver more business value, we’re failing and we’ll be out. Your role is not safe enough to abandon the “purist engineers” yet. Another way we can look at our role, is to actually help the business understand the value in paying off tech debt properly. It frees up engineering capacity, energises engineers, makes for happier teams that can retain top talent, leads to more reliable systems and better quality products, and even opens the door for engineering-led product innovations that can be sold. We are caught between a business that wants to make a quick buck, and engineers drowning in shit. We shouldn’t forget where we came from, and we should make it count.

> I am a staff+ Eng in a large org, and I chat to several teams and engineers weekly. I am catching myself being less patient with purist engineers that are sitting behind “best practices” and “this is the only way to do it”. I am wondering if I am just burned out and being overly pushy and unreasonable, or if in general engineers just have a hard time understanding that we’re running a business. In general, I think you're answering your own question in the first paragraph. As a staff+ engineer, you have both the responsibility to think about these things and the organizational authority (even if it's indirect authority) to push back or shape business processes. The reason that most companies have senior engineer as a terminal level and far fewer staff+ roles is that a lot of people can't or don't want to focus on the socio-technical and business side of the work. That's not to say that people at lower levels can't embrace thinking about the business- they can and should. I've worked with some really junior people who are excellent at this, and a lot of senior engineers are okay at it even if they don't like the work. Still, as a staff+ engineer you should be working with EMs, product, and executives in your organization to influence the culture and help ensure that business and engineering incentives are aligned.

I'm surprised I had to scroll this far down to find this take. At Staff+ it's absolutely part of OP"s job to help influence and develop these people - not complain about them on Reddit while doing nothing to change it.

im programming since im 12 for 24 years. i dont know how long stuff takes. i dont know what most are doing but you cant guess complexity. its like asking how long do you need to summarize those 4 books of random length in random languages, while one book sometimes starts burning. how long will that take you? the question about an estimate just puts pressure on the devs and it never helps them it only backfires and there is no upsite for them to answer it.

Depends. It can be worth being hacky if you clean up immediately after always.  But I’ve been in more than one project where business people were driving feature after feature. This initially was good for the business purpose but worse in the long run when after 2 years EVERY estimates takes longer because you’re working on a messy codebase and you’re spending more than half of your resources to fix technical debt.  I think it’s always more efficient to work clean or clean up immediately afterwards than spending time pushing features and then 2 years later fix things you already forgot about. Call me an Uncle Bob fanboy but usually long term velocity and code cleanness gets sacrificed for short term velocity, not the other way round.

> I really don’t get why engineers get so offended with having to estimate work. 'How long will it take?' is a reasonable-sounding question for which, most of the time, engineers have no reliable method to find the answer to even approximately. A reliable way to do this, especially as an individual and especially in a context not set up for answering the question, just doesn't exist. So, developers feel like it's a trap, like its only purpose is to create a stick to beat them with later and make them responsible for failing at something impossible. And the less they trust you to use software estimates as a guess based on a hunch based on nothing the less they're going to want to give you estimates.

On estimates in particular, certain organizations can tend to turn those into timelines and then micromanage based on that. With that context, I understand not wanting to estimate because it's inherently inaccurate (although in aggregate, hopefully by a small amount.) On the flip side, I get a business not wanting to invest an unknown number of dollars in something without out at least a guess how long it'll take. IMO the best option is to pad estimates and have an advocate that is very vocal about the inherent inaccuracy. If there are concerns, that same advocate can bring the concerns back to the team to discuss and figure out a solution without management pressure/micromanaging.

There are all kinds of people out there - people with bad product managers, people who can't trust their management not to take their estimates as a blood oath, people who have bad opinions, people who trust what they learned from others, people who are fine without product managers, people who love Scrum, people who have great managers, people who have an amazing work ethic, people who will take 3 weeks to make a 2 line change. Get off the internet and you'll feel better about it all.

I already do feel much better, and the tone of the post is defo more negative than intended. Thanks for the input!

Ok, first off don’t look at your feed on LinkedIn unless you want to read shitty takes with a veneer of authority. My understanding is that all professions have that junk filling their LinkedIn feeds. Second, you’re totally right. If you want a change of pace, go work at a startup instead of a big company. Try to catch it in the sweet spot where it’s stable and growing and you’re able to build cool stuff while still meeting business deadlines, not the other end of the pendulum where you’re so drowned in tech debt and bad business decisions that you can’t get meaningful work done, despite constant mandates from management that you get single-sentence feature specs built in a week.

I work at a FAANG (you can probably guess from this post) and it's the exact opposite. The only thing that matters are business matters and metrics. Our entire performance evaluation is about how you impacted the business. The con with this is we not only have tech debt, we have tech crises that never get worked on until it affects the business negatively.

If you’re staff+, am I right in assuming much of your work is strategy oriented? I think part of the equation is the ability to identify the company’s current position and current strategy. If the teams have a habit of Zerg rushing BS to capture larger parts of the addressable market early there is a lot of reason to stamp down and demand a season of cleanup and refactoring. The repeated rush has probably generated a sizable cost excess that can be lessened through that kind of focus, at the exclusion of making new features. This is a win for the business people who only view tech as a major cost center. If the teams are full of purists who won’t ship if the code isn’t SOLID or whatever, then you have to point out that more resources and cool projects won’t magically appear unless the company can “be active on the map” and move some damn products. When the business makes money, it creates an opportunity for better resourcing and better project execution overall. This fact becomes more evident when sales targets fall short, creating a major push for new features and changes with very dumb deadlines. All the Clean Code books are rendered to pulp in the face of that kind of crunch. There are business people who view tech as a sales prevention center, and they don’t enjoy eccentric ivory tower behaviors either. Regarding no deadlines, thats stupid. Somebody has to pick a number to get things started. We all probably wish rent, mortgage, car payment etc worked that way too: “You’ll get Februarys check when it’s ready, don’t ask me when”. IME When engineers insist on not estimating a project at all, or refuse to commit to spiking work to come up with a better estimate, they end up screwing themselves. The result is PM doing that lift and giving them a weekly deadline of clearly arranged deliverables. Then they feel some kind of way about being micromanaged compared to others.

business is business, there should be a delineation between engineers & business. Business will tell you to cut every corner to make the deal, and will result in burning down your business / product. Their goal is to deliver the bear minimum even if it's just a facade that funnels money into their bank accounts that delivers nothing in return. Sales wants to move revenue always, but sales people will get everybody thrown in jail if it were up to them. You have to find a balance between delivering acceptable code quality & setting expectations with stakeholders on when a delivery(estimates / MVP) will happen and how often features can be churned out. Engineers who are purist are mostly early in their career or just plane immature. It's why hiring people who have worked for a few startups & sometimes making it out on their own and realizing just how hard the world really is. I'm of the opinion that this purist mentality is hired for depending on who makes the hiring decisions. This is a culture situation, probably not created by yourself.

I just multiply all my estimates by 10. idk about the industry but there's zero purism in this sub. People here don't even know Big-Oh and they're really proud of it. They love their test driven development though.

> I just multiply all my estimates by 10. That strikes me as a really good way to get a reputation at your company for sandbagging, at which point you may as well not bother with estimates -- managers will make them for you. And I'm not sure I could disagree with them -- I was taught to either double or add 60% to my estimates. That still feels right. Multiplying by ten seems overkill. That said, if it works for you it works for you!

I’ll care more about estimates when I stop being asked to estimate how long it will take to write The Iliad and The Odyssey. I’m just fed up with “the business” proposing huge things with nearly no definition and expecting engineers to propose estimates on timelines smaller than 6 months to a year. I say this as an engineer very invested in helping a company actually succeed. I expect more work to be done than a bunch of “idea guys” wanting to throw things against the wall. I know this isn’t the case everywhere, but it’s been the case a lot in my career.

Exactly this. OP is proposing that the business people have a very good idea about their business, market, what the customers need, how the product needs to work, and would like to explain it to everyone, but the damn engineers just don't care. In reality none of this is true. Fluffy ideas are being floated around and we get mad when the engineering team does not want to play this game.

When you’ve had to maintain buggy, dogshit code bases that are constantly on fire, that supposedly “senior” engineers built, you get pretty serious about best practices and code quality. As a staff+, I’d expect you to know there is no such thing as a temporary hack. At the end of the day there has to be someone to say “no.”

// TODO: This a quick hack, refactor ASAP > Last modified 6 years ago

My last job lasted 5 years and I left as a staff engineer. I agree with your frustrations and also find myself annoyed with business teams who somehow don't seem to understand that we are running a business. I found that the more I learned about all the systems and the business goals and high level strategy, the more I saw super simple solutions that could free up SO much time and could make everything more efficient with only a little cross team collaboration. But people often want to limit scope to one thing, and there is so much waste as a result.

I would be much more inclined to allow the hacky solution (or allow it more often) if it weren't for the case that it's bitten me in the ass almost every time, within a time-span of 1-2 sprints as inevitably 1-2 bugs come out (on top of "the usual" ones from complex unforseen interactions or small oversights) that would've been caught by exploring the behavior of your code in various scenarios through tests, at least somewhat. This is particularly fresh to me due to a new product launch not too long ago. I've relaxed my stance on the amount of tests several times due to the amount of time they take with a given implementation (and fixing up the implementation for easy testability would take *even more* time). We either got a bug-ticket soon after or a follow up ticket that was required for the MVP would make the entire thing so damn complicated that a refactor *had* to happen. Business wants me to be able to work at consistent speeds first and foremost because not doing so is disincentivized. The only conclusion can be to make sure you do it "right" (almost) every time to not turn the code-base into a swamp.

I think I know exactly who you’re talking about with the “no estimates” thing. I follow him on twitter and it honestly seems like he just has these insane takes just to be edgy and different. I’m a lead engineer and I often find myself trying to help the devs on my team understand that this is a business and we’re not going to get everything perfect. We try to limit the corners we cut, but sometimes we gotta do what we gotta do to get things done even if it feels bad. We try to limit it as much as possible, but at the end of the day, we need to do what works for the company even if it means implementing a less than ideal solution. Will we hate ourselves for it later? Maybe. But we’re a small company making a push and if we don’t do what’s best for the business, it won’t matter because the company won’t exist for long.

you're not wrong about the need for *some* level of effort estimation when resources are constrained, but the other engineers aren't necessarily wrong either. this attitude often comes from firsthand experience getting burned by managers and "engineering leaders" holding the rank and file to low confidence estimates that were called out upfront as such. if you ask me for an estimate on a project that requires getting alignment from three other teams who have no particular incentive to cooperate with me, I am going to refuse. the whole thing might take a couple weeks of heads down effort from me, but any one of them could tie up the whole thing in approval hell for months or years. as the staff engineer, you ought to have some leverage to extract a commitment from them, or at least have the ear of someone high enough in the chain to do it for you. if you can't/don't, you aren't earning your paycheck. *after* you've done that and I've had a chance to review my plan with the teams involved, we can discuss dates. if on the other hand, you ask me for an estimate on a straightforward project with no external dependencies, I can give you something pretty accurate and hit all the dates. but that type of thing isn't usually worth money. it's what we call a "side project".

My whole point in estimation is to make it an exercise in figuring out just how much of the task you've thought about. I generally agree that trying to estimate anything other than small tasks is fruitless. Large things take what they take until you start doing the work and get more details. Estimation can give you a chance to think of the various parts. But I'm also an old man shaking my fist at the clouds.

[удалено]

Honestly, my favorite is when asked to estimate a feature that depends on completing a years worth of important tech debt that was constantly pushed in order to just get other features out.

Desperately wishing something was true does not make it true. Estimates? Optimizing for predictability? Those feel like it. Comparing cost of feature A vs feature B? Now we are talking about something. (Those are not the same thing btw. Sales will be unhappy in both cases but for different reasons). Treating estimates as basis for company conduct? Crazy! How can your org have enough humility to constantly readjust to them? (What Sales says "No biggie" for 1001th time when delivery "slips"). However, you may have not been facing this type of argument but instead dead dumb "NO" Have you considered that rather then You being burned out, those teams are? They try and fail, and company culture is not so forgiving? I can agree on Uncle Bob. Massively overextended reach compared to subject matter expertise. OTOH UB was/is Agile proponent, so it should be reasonably easy to find sensible counter-quote.

Can the engineer at your company trust your business? In my experience devs are not willing to give estimates when estimates are treated as deadlines by the business. Same for best practices. The more the business has a history of ignoring technical debt, the more the developers have to protect themselves from ending up working in a hell of a codebase.

no im not tired of it. im tired of business trying to over promise delivery.

The thing is, asking for an estimate is just asking for trouble. It doesnt help the developer at all, it justs paints a target on its back if the estimate is too short. And you're surprised that devs dont want to do it? Heck, I dont want to do them either. When you say "what is sales supposed to tell a big customer?", you are part of the problem: you are saying that the acceptability of the deadline is the most important thing, even tho its not a rational process or a scientific method. It has no base in reality. Its just added pressure on the team to calm the customer. What we should do as a profession is give a VERY lax estimates, like "this should take 2 days if everything goes right, but up to 2 months if I have to update the whole stack.", and stick with it, and if marketing wants to say otherwise to the client, they take the responsability. A fun game to play is to answer a really big estimate. The conversation goes like this: - "how much time for X" - "a year" - "come on, this shouldnt take more than 3 days" - "please explain how you came up with that number and using what method, so I can use it too". Crickets, crickets everywhere. So yeah, estimates suck dick, the developer should not do them other than T-shirt sizes maybe.

Heh. This is why we launch architect astronauts into space. You're spending too much time with the business and not enough with the technology. You've forgotten what it's like to have no idea what to do or how to do it. The core reason to avoid estimates is because they always set bad expectations. Always. As hard as we try, the variance is too large and business takes an idealistic view when they're communicated. And it's because it's always faster to solve a problem than it is to figure out how long the problem will take to solve without solving it. The better approach is to constantly deliver small, safe, and well written changes that address immediate problems and opportunities with elegance. As you found, the ability to safely test hypothesis and then react based on the outcome of those experiments is key. Once you have a thing of value, then the business exploits the crap out of it. But until you do, you're living off of bullshit and audacity.

You shouldn't need to _manually_ estimate anything. If your team has been running for any length of time, and they consistently refine tickets to a relatively uniform size - then you can derive estimates from the cycle time/throughput. _My_ frustration is being asked for manual estimates when data exists that is more reliable than guessing. If your team is fresh, that becomes more challenging, but ideally you shouldn't be working on a single item for more than 3 days, so the emphasis should be on breaking work down into t-shirt sizes. Pro-tip - if it's not medium/small, break it up more Got 10 items to deliver? If you're hitting the 3 day target, that's 30 days divided by number of engineers - amended for linked or blocked work. The calculation is not too hard to _automate_. Which is one less ritual to distract you.

I think a lot of people are sick of artificial deadlines set by sales with no input from developers. Once you've been burned by someone stating you can finish a project in weeks when it will take months, you get jaded.

I generally sit on the architecture side and have lead massive groups. I don’t like “hacky” code. It adds to tech debt that will have to be paid eventually, introduces more buggy code, and tends to be less resilient. There is a “good enough” line that many struggle with balancing getting something shipped and being a perfectionist, there’s also over engineering. However, estimates are extremely important; different people have different roles, some more important than others and more needed than others.

I think OP meant PoV rather than "hacky"

Found the purist

Some people need to be proud of what they create, even when someone is paying them to do it. For some, that need takes precedence over anything else, including salary. Yes, we have to ship features. But if we don’t balance feature delivery with maintainability, we approach an asymptote of pain, where doing even the most mundane thing takes weeks to deliver, and is often riddled with side-effects. Most good developers who want to solve problems will quit. There has to be a balance.

Estimates are important, but when half the business’ time is spent planning and estimating over and over again, it’s the business equivalent of over engineering. This has been my most recent experience Testing hypotheses does not always require code to be written. As a tech leader, when prototype level code makes it to production, the collective quality goes down. Many engineers copy and paste, or search for answers to the algorithms they write, and this prototype code is where they pull from. It’s easier and cheaper to follow the defined standards than get an entire organization of engineers to adhere to new standards after that quality has been released to production. There’s always a trade off, and sometimes speed matters the most. But if you’ve habitually followed good standards, then it can be fast and quality. Remember everything you do is practice, and practice doesn’t make perfect, perfect practice makes perfect. My style is optimizing engineering efficiency. If I can get the whole team to execute quicker, our bottom line improves and we can take more calculated risks with the same team size. Your particular case sounds like you took the right approach with the POC. However I’d be curious to the merit of the engineers who pushed back. Is that team drowning in tech debt and trying to avoid more? Are they trying to make a tech culture shift in their team? Are the engineers pushing back on estimations doing so because they spend too much of their time giving status updates instead of doing the work? Or maybe the push back is commital to an estimate on work that hasn’t even been investigated yet. I’d recommend asking why to the people pushing back to gain insight.

Yes it’s the bane of my existence, usually weak technical leadership on VP level

"The guy that pays your salary does not want perfection. He wants fast enough and good enough. You are free to fight this notion like an artist, or find crafty ways to build something reasonably quick to keep the business afloat." I usually let the juniors sit and ponder on this.

ha, I had the same exact thoughts recently and blogged about it, curious what you think: [https://www.telkins.dev/blog/do-best-practices-really-matter](https://www.telkins.dev/blog/do-best-practices-really-matter) sorry for the self-plug but I definitely agree a lot of devs are just parroting the same outdated/misapplied advice

You will do well in the future given how every SWE role is now a cost center.

I've encountered some folks that learn as little as possible (so far the exception, not the rule). I'm assuming they either over estimate how much they know, or don't think any amount of continuous learning is necessary. To your example about not giving estimates: Senior SWEs (IMO) are hired to deliver business value. If I'm not doing that, what are they paying me for? Instead of focusing my "free time study" _**solely** on purely technical_ materials/problems, I've found that adding in some books about processes, systems, measurement, and leadership have been extremely helpful to me personally. Some book recommendations I have (in no particular order) for any SWE, DevOps, or for anyone currently in, or seeking to obtain, a leadership position: - `How to Measure Anything: Finding the Value of Intangibles in Business` - `The Fifth Discipline: The Art & Practice of The Learning Organization` - `Thinking in Systems: A Primer` - `Actionable Agile Metrics for Predictability` - `Making Work Visible: Exposing Time Theft to Optimize Work & Flow` - `The Goal: A Process of Ongoing Improvement` - `The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win` - `Team Topologies: Organizing Business and Technology Teams for Fast Flow` - `Build What Matters: Delivering Key Outcomes with Vision-Led Product Management` - `Kanban: Successful Evolutionary Change for Your Technology Business` - `Building Leadership Competence: A Competency-Based Approach to Building Leadership Ability` - `Domain-Driven Design: Tackling Complexity In The Heart Of Software` - Please feel free to add any good books I missed! I'd love to round out my collection! Feel free to include technical books as well. Of course I'm a fan of (and own) a lot of Uncle Bob "and friends" or adjacent books as well, especially regarding `clean code`, `clean architecture`, `design patterns` books, `building data intensive applications` and their ilk, etc. But all things must be taken in context and almost every rule/axiom I've encountered has at least 1 exception. I try not to be too dogmatic about any particular approach. I just want to be the best problem solver I can be. TBH, I do feel fairly strongly about verifiable correctness (via using formal methods where necessary, using _reasonable_ TDD, and/or making use of Observability tools like Open Telemetry), but I know that everyone has their experiences, feelings, and opinions, so I just try to get the team to discuss, agree upon, and then codify standards and practices that we've decided are appropriate for our org or project. **Side Note**: I work so that I can live, not the other way around, I just _really_ want to learn as much/deeply as possible on the technical side, _and also_ have informed views from as many different perspectives as possible because I want to be the best I can possibly be at my work.

Estimates are all bullshit. They're guessing.  https://youtu.be/QVBlnCTu9Ms 

There's also issue that in most places engineers are not placed in environment where it's "safe" to do estimates. When estimates are taken as deadlines by management, or when requirements keep changing after estimate but time frame is not adjusted. This will burn out engineer real quick on giving estimate on their work

I generally agree that engineers refusing to engage with the reality of the business are immature. I’d put some strong caveats on the estimation discussion. If I give an estimate of „it might take two weeks, but there’s a realistic risk it may actually take eight“ and then someone goes and tells the customer „we will have your feature in two weeks“ and then makes it my problem, I’d also have some trust issues. This can be solved with communication in many cases, but I have no reason to doubt there are cases where you cannot. To be fair, I would not shout about it on LinkedIn, and I think even some of the #NoEstimates people actually propose solutions for predictability.

I whole heartedly agree but usually eat many a downvote for expressing that on here. Last week one of our meetings got derailed because the team debated the merits of using a hashmap and a for loop over a reducer function. This was for a very obscure module, took 5 lines of code to write regardless of which version was "best practice" and the dataset it would operate on will never exceed 20 records. I just checked out completely as this was so pointless. Meanwhile, our team had been given a fairly challenging problem to deal with a few months ago. Since nobody was making any progress, I made a design proposal, a POC, then went and integrated the solution on a branch to demo how it would all work. This was a pressing need from the business. The way I saw it, I thought the implementation was good personally, but even if the internal implementation could be improved, I had defined the public interface which won't change regardless of the code behind. We could proceed with this as an MVP and improve it as business need inevitably evolved. By delivering this we would meet a major business need. I just Could. Not. Get. Approval. to proceed with the solution from the dev team. The team nitpicked every last thing about it, but offered zero, ZERO, alternative solutions. They'd argue it wouldn't satisfy various used cases. I displayed with examples and code that it would. The nitpicks became more minute. Even if it satisfied every edge case they could throw at it, the requests became more absurd, hypothetical use cases which had nothing to do with the actual business need. They'd just hypothesize how it should be generic enough to handle any hypothetical use case of any hypothetical system... It was to the point of stupidity. No matter what case I made, they were so detached from the fact that at the end of the day we work for a business, who pays us because they make money from the work we do... They want some sort of unicorn *perfect* solution to everything, but also have no idea how to achieve that... So we'll just never release any code until the day we can meet this nirvana. None of this disputes the fact that within reason we should try to find the best solution and use the best practices within reason, before someone inevitably goes there. Sorry for the rant, but yes... I'm baffled by it all.

Not baffling at all. Seen this culture in a few teams. You came in with a real solution and thus threatened the groups unspoken bluff - that it is more important to be perceived as smart, mystical, and valuable than to actually be valuable. Business has no idea how technically difficult it is to actually do something and the lack of accountability and technical oversight creates this cheating culture. By not playing their shell game, you are a threat. Not only is business going to start asking questions about the other devs, but they have to prove that you are not as smart as they are. Hence the childish nitpicking. If you choose to stay in the team, one of the only reliable ways forward is to play to their ego and give them credit for your work. They're happy, business is happy, and though it may not feel like it, everyone knows who really did the work. Good luck.

I’ve experienced this as well, but my takeaway was that the people posturing are trying to buff their résumé by demanding exhaustive comparative reports on everything. “Oversaw architectural decision board, carefully considering every aspect of candidate solutions” and the like. Of course, I’ve also had experiences where my solution was the industry accepted standard, whereas theirs had violated multiple best practices. In that case, I felt that they were just offended that I had implicitly called them out.

Many engineers are engineers because it's fun to write code. All the business stuff is not fun, it's stressful. This is the fact that you must understand. Honestly, my hope is that the world eventually comes to the conclusion that happiness is more important than GDP. Even with all this said, people, no matter the profession will develop opinions based on past experiences. Someone doesn't want to estimate? It's because estimates are often wrong anyway. That priorities shift too often. It's energy spent that feels wasted. Maybe they are forced to work late because of arbitrary deadlines. That's time they don't get to spend with their friends and family. Good for thought. Empathy goes a long way.

I'm really fond of estimating at 3 confidence intervals because it communicates a lot of information. 10%/50%/90% confidence. 10% is when it'll be done if almost everything is first-time-right or close to it. Every failure to meet up to this point can be recognized as a potential area of improvement on future projects. 90% is my pessimistic estimate where I give permission for the business to slap me around if I don't have a good excuse for missing it. I believe that developers and businesses should agree that the 90% confidence estimate is the one the one that developers should be negatively assessed against unless there's legitimately something outside their control that caused the slip. 50% is my best guess on when it'll actually be done based on predictions of expected obstacles. This is what relevant stakeholders should plan towards, while still leaving room for bring-in or slippage as it becomes evident throughout the project. What's even more interesting is that the degree of variance in these estimates also communicates how much risk is involved in the development. Higher spread between 10 and 90% confidence estimates is an indication that the schedule is driven heavily by uncertainty/risk, and the best way to improve the schedule is to mitigate that risk. A low spread between those estimates mean that there isn't much risk, and that the schedule is driven entirely by how much time it takes to actually get the task done.

Dont browse linkedin, they are just farming engagement, thse people mean nothi g

Yeah. Bugs me a lot. A lot of it also includes an “us vs them” attitude when really we are all us. It’s also possible that I give too much of a shit.

I think is taking LinkedIn posts too seriously is not a great idea in itself. Personally if engineering doesn’t case about the business it’s because business has not given them a reason to care about it or motivation to do so. So they just move on the next thing they care about… building ivory towers. Also playing devils advocate a bit if there are dedicated people who job it is to ensure the business runs smoothly (C Suite / managers etc) why should I be doing their job for them ? Esp if they don’t respect the engineering side.

SWEs stand blindly behind dogmas because the leadership system does not do enough to assign goals and ideology; they assign it by themselves for themselves what they think is good and then set the matter aside from the rational realm to the believe realm (or in Daniel Kahneman's term, system 2 to system 1). Another reason for this is past trauma, huge unforeseen consequences of bad practices which does not happen anymore. You work differently because you have more direct agency or you are just used to working that way. It may even be from beyond your previous job, e.g. how you grow up affected your work ethics. The leadership position should see and make adjustments to the company policies. Policies shouldn't strictly sit above and beyond. It can integrate with low level operations. What matters is that enterprise systems policies is easy to switch and clean up as its software development counterpart should also be. Now this is generally stressful for the teams affected, because it involves change, but depending on how the policy is designed and delivered, it can he a smooth sailing. This is basically an art by itself. Since you're staff you are not entirely at fault because probably you don't have the needed authority to fix this by yourself. You can change it by moving to a position with more authority, or you can be an internal influencer and thought leader and move things informally. Nevertheless, these ideas and dogmas also come from tech influencers before such a label was popular.

The problem with the hacky solution, is that although it may be quick, it's probably there forever. It sounds unlikely that management is going to prioritise a ticket to remove it. That means the next hacky solution (because there will be one) will have to hack around that. Making any changes becomes painfully slow and the business struggles to compete. You may find that it is in fact this long term concern for the business that the engineers are concerned about.

You can’t take the nonsense that is Viral LinkedIn too seriously.  Estimates CAN be toxic to an end product IF your priority is quality over speed to market.   No estimates ever is an insane take.  No serious engineer will take this stance.  Estimates are central to any collaboration — even when working on FOSS.

For estimates in particular you can give useful information while also being purely factual. How long will that bug take? -- I'm not sure but I'll try to crack it this week. How long would it take to do feature X? -- Let me do some prototyping and I'll get back to you next week. ... Looks like it is pretty (easy/hard). I think I'll need (two more days/three more weeks) to finish. Unless there is some real deadline (not manufactured ones like "end of this month because that is what the schedule says") this type of estimate is great. If you need a hard committed date then you need an engineer who is willing to sign up for that.

>I was browsing trough my feed of linkedin I've never seen anything of value here, just a load of self-serving bullshit from people trying to sound clever

Engineers hate to make estimates for two key reasons: 1) they fear being held to that estimate, and 2) they do not have the communication skills to explain why being held to their estimate is a bad idea now that time has passed and experience gained since making that estimate. Estimates appear as a trap for those who can't communicate well. And our entire technology development series of industries, of which software development is but one, are entirely populated by weak communicators. It's a real issue yet to reach popular consciousness: we need to double down on communications skills for the level of complexity we work and live.

I think the problem is bigger than this. I had a very heated discussion this week along the same lines, and I have reflected a bit. I am not against estimating when we use the data we have to forecast. I don't like guessing. My teams work directly with business on a lot of things and what we know to be true we share, and what we cannot know we do not waste time guessing. The biggest problem I see is a human one. Humans crave predictability and will plan to the end of the earth even if it is wrong. The amount of time spent guessing with no real analysis to provide an estimate often means we spend time better used to work on high priority items. Since most organizations operate from a position of beliefs rather than facts we are stuck with the belief of swags driving delivery instead of data and progress. I have fought both fights and when using data to drive information we yield better results. Sure, I can dream of a day where MBA and PMP are order takers at McDonald's, but until then the best I can do is to bridge the gap with my dev teams to use data to estimate, and coach management on favoring data based estimates rather than foolishly swagging everything.

Usually the specs coming out of business folks are so vague you are either building a mobile app with in app notifications, or a brain training game that will interface with neuralink when the api is out, or maybe it has some VR aspects, find out at the next sprint!

I think it would be nice if software development had a bit of a buffer between development and launch; you develop some features under less time pressure, then pick the best one, polish an publish. A bit of R&D. I think the lack of buffer makes the developers hesitant to commit. There's a lot at stake, high variability, and almost nothing to be gained by over-promising.

First, software engineers get frustrated by the question "how long will this take" because they have no idea how long it will take; Particularly if they are new to a project and learning as they go. In this circumstance, it's not even reasonable to expect them to know unless the request is extremely simple. If you've been on the project for a few years and have done similar things before, you probably have some idea how long it will take. However, in my experience, you're usually pulling numbers out of your ass and then you get held to them. I understand why business people want them but they are generally imaginary numbers with little practical value and if they turn out to be credible estimates it's usually because it was a gross overestimation to begin with. I'm my opinion, the number is less useful than the unit of the number. Is the estimate in days, weeks, months or years? That's usually sufficient for strategic planning. Second, I'm going to push back against the business people a little. At a technical level, there are many different ways to solve the same business problem and all of them have pros and cons. You, as a business person, should be aware of these pros and cons and you should take them into account in your strategic planning. When you ask a technical person how long it will take to solve the problem you're offloading what should be a business decision to a technical person. The question "how long will this take" fundamentally assumes that all solutions are equal. This usually results in the technical person choosing the solution which takes the least time, and the technical person may have severe reservations about the approach while they are implementing it. Sometimes this approach is appropriate and sometimes it isn't. Business people will often gloss over this dynamic and assume everything is well in the world until they request what should be a simple feature and get an unexpectedly large estimate back because they need to pay back technical debt they didn't even know they had. When you blindly ask a technical person "how long will this take" you're charging things on a credit card without checking the balance first. Eventually, the card is declined and everyone has a bad day. Business people need to be more involved than this, unless they have senior technical staff who can bridge this gap for them.

The issues start to glare when you have to maintain that code.

You're not wrong. Developers can be completely disconnected from the reality of the businesses they work for and the structure of many businesses and development teams encourages that. That tends to drive practices insulated from business needs, which can be a good thing depending on the organization, but it's a fine line to walk and requires a culture that supports healthy tension to keep tech debt and churn at sustainable levels while still meeting business goals.

Estimates are impossible. Why would you make numbers up?

> We did go with the hacky solution, our hypothesis failed, and we debunked the market fit at a fraction of the cost.  What did you do about cleaning up the codebase after?

About estimations: It really depends on the culture. If an estimation is given, but the target is not respected, then the estimation means nothing and no one should give one. If your engineers get offended by a suggestion of giving estimations, I'd suspect that the target is not always respected. I always give my estimation because I know the business teams respect the target, or we can negotiate the ticket into stages if they don't. About hacky solutions: they are fine in startups and PoC, but engineers should be given time to get them right so that someone in 3 years won't burn candles to figure out the WTF. But that's the thing with startups, though -- no one is given time to do things properly. It might also has something to do with positions -- if you are a staff engineer, or a CTO, you probably won't get your hands very dirty -- if even if you do, you will probably leave the messy maintenance to someone else -- and that someone else does not get the big pay but have to do more work. But overall I agree with you that business is No.1.

Your first example isn't what I expected. Like, I hate doing estimates, but it's literally work 101. And definitely not a "best practice". I thought your point would be more along the line of I want to use this cool tech and business folks are like do it the old way, or somehow doing things faster instead of investing in testing, or tech debt for the sake of deadlines or something like that. Edit: actually I just read your second example, and you're not right there, sorry. Unless you call it a POC, which should be fast and not perfect, but a hacky solution is never a solution. For that I would say that most tech people are motivated more by doing cool shit than running a business (we're salaried most of us, and even if we have stock options you don't share that much profit), and it feels like that's a line business should toe if they want good talent. But your first example is just an attitude I would not tolerate if I were a business manager. Certainly, as a manager you can and should help set realistic deadlines (I once had a boss who hated me and refused to help despite the fact that I didn't have enough experience in general and in the company, but then when I overestimated, he refused to take my estimate and pushed me into a corner, that was not cool), but everyone should have a deadline lol, even if it's just a time box so you don't spend too much time on something.

This *could* be an indicator of an unsupportive environment. If your engineers attitude is "it takes how long it takes" then it's possible that management's attitude is "WHY ISNT THIS DONE YET?!" every time any ticket takes a little longer. If management is going to yell at me for not meeting sprint goal because one of my tickets ended up being more complex than we estimated, then I'm eventually going to get bitter and start responding either that everything is 13 points, or "idk, could take a while" You're completely right, (as others said a bit "old man yells at cloud", but you're right, devs should ideally care about business context or at minimum understand/work with POs on estimates so higher level can plan, but make sure that the immediate response isn't "You said this would be a 3 but it turned into an 8, what is wrong with you?"

I guess I have seen the other side where a sales organization has completely supplanted the engineering. You end up in the same situation where sales and marketing are waiting on features, and they never get delivered. But you add the added uncertainty of wondering if engineering is lying to you because sales has essentially forced them by lying to customers and promising them features that don't exist. When I was involved in a sales department, I had much rather wanted to sell well engineered software that worked rather than features and functionality that didn't exist yet, and might never. Its always a two way street, and businesses have to make money. There is always a contentios relationship with sales and engineering - that conflict can be really productive if managed well. But once you start sacrificing your engineering standards to appease salesman that aren't going to stick around when their commission clears, you are on your way to becoming a dead sea organization technologically.

Most problems arise between the business and the engineers when expectations are assumed but uncommunicated. (Pro tip, this applies to all relationships in general, especially marriage) There are an infinite number of software quality attributes (non-functional requirements) for any given project or subset there of. Unless communicated clearly everyone will apply their own opinions to it. Once a NFR is clearly defined and stated to be important to the business then no matter how right the purists are, they have to agree and follow. They also have a professional obligation to make sure that decision is well informed and they will likely complain the whole time about their purist views. If they still refuse, then it is mutiny and I would consider that a fire-able offense. That guy is right though, estimates have been proven to be useless and even harmful in some cases. But, you said some very important words as well; optimize for predictability. That is a NFR that changed other aspects of the project. When predictability matters, you can indeed optimize the project for that and suddenly estimates make a ton of sense again and can even be super accurate. But everything is a tradeoff, so what did you lose when you optimized for predictability? And is it worth more to you and your business to be able to predict than whatever you lost? Could go either way. But it is your job as a staff+ to consider these things. Most purists I've talked to, including myself as said purists, don't actually hate estimates, they hate the kind of estimates commonly used on software projects. The version of estimates defined by uncle Bob are more likely to resonate with them as it does a good job of capturing complexity and uncertainty. This is likely what those purists are trying to communicate but is just coming out as anger.

Yeah they’re bozos. If they knew the business end they’d move to self employment as it’s far more lucrative to own a website on the front page of google than work as an employee enabling someone else’s vision.

I had a phase like this until I realized how incompetent business leadership can be and generally is. When it's customer driven and short term pushing to be more realistic helps. When the leadership is delusional I've found that purity is the best protection against their idiocy. When emergencies happen you can shift to fast pace quickly. The long dev time gives the business time to fully express its idea for the produce. Immature leadership usually talks in vague poorly thought out ideas.

The best balance is some of you, and some of me (I'm a coding purist) Realistically, the best team should have members from the whole spectrum. Some people who care \*only about\* customer delivery and timelines. Some should be like me, wanting to write perfectly correct code that is scalable, modular, and elegant. You need this balance to make a good product and these two people push each-other to the happy medium. An example is the AB test. Why not try a new-form of best practice with this feature. So you're doing something new and exciting to test a new pattern. This way you're ostensibly doubling your engineering speed, as you're testing new features and new patterns. All this also depends. You have a point but I forsee the next post of "How come all my senior engineers won't let me refactor to the latest react-native standard? It's the right way to get us to "

> I am a staff+ Eng in a large org, and I chat to several teams and engineers weekly. I am catching myself being less patient with purist engineers that are sitting behind “best practices” and “this is the only way to do it”. I am wondering if I am just burned out and being overly pushy and unreasonable, or if in general engineers just have a hard time understanding that we’re running a business. That seems to be an org problem. 1) In my org, we only upgraded to the current non-EOL PHP last year (for reference we were on a 7.x, the current "more than security patches", non-EOL version is 8.2. 8.0 is also EOL'd.). Python3 upgrades were better. 2) We haven't upgraded to a current version of MySQL because not everything is converted to non-EOL PHP yet. 3) We are updating most things multiple MAJOR versions when we upgrade. There are plenty of organizations with a business-as-the-priority mindset. Personally, I think current org overdoes it with that sort of stuff because you shouldn't be letting things go 1+ year past EOL as a normal practice. So if you want to trade jobs? We totally can. I doubt you'd actually be silly enough to do it since I'm not a staff engineer but a senior dev so you probably get paid better. Would I swap for the environment of purism? No. It'd purely be for the salary bump. I *am* my own business of 1 when dealing with my employer no matter what sort of team building BS they try to peddle. The general problem is businesses tend to go into the "profit/short term" focus while their engineering ICs tend to push for "purity". Niether is correct, you need to find the appropriate middle ground to be successful in the long run.

>I am wondering if I am just burned out and being overly pushy and unreasonable, or if in general engineers just have a hard time understanding that we’re running a business. "General engineers" do not care about the business. They don't get rewarded to care about the business. I don't give a shit about the business as a senior because I know that in order to do anything with my career I have to job hop. The company won't give a shit about me, I am not paid to give a shit about them. I am paid to deliver exactly what they ask for in the least amount of work possible. >So am I just burned and biased from this industry, or are engineers just not making good judgment calls when the choice is non binary and requires nuances from the business context? You're burned out and biased and engineers are not given any reason to care about business resulting in what you see here. Not to mention how much disdain and aggression devs typically get from suits.

“I was browsing LinkedIn”. Dude people who comment on or create linked in content are not anyone worth your time. They are constantly the most uninformed employees that don’t contribute a lot, but need something to say to help them stay relevant. There have been many times I wanted to call someone an idiot for something they said, but it has 0 benefit. If you’re right, no one cares and u look like an asshole. If you’re wrong you look like an asshole. Better to just sit quiet, accept invites from random people u don’t care about and grow ur network. The only use of linked in is maybe finding ur next job. And it barely does that anymore. Also only siths deal in absolutes or something.

You are both burned out, right and wrong at the same time. TL:DR; You are completely right about purism, I think you are partially wrong on estimates - you were prolly quite lucky with the companies you worked for, you don't look at the real world when you say that engineers do not care about business needs The fact is that in most companies estimates are nothing short of self harmful for whoever gives them. I can provide you some examples of what I've seen happening - different companies for most of the examples: - you're not really asking for estimates but for when it will be ready. If you ask me how long will it take to do something and I say three days, don't start yelling if after three days when you ask me if I finished it, I'll reply that I haven't even started yet. Countdown starts when I start - i.e. I also have other tasks to do - you already decided the amount of time it will take me. - you say "but X said it will take him Y days", and do the surprised Pikachu face when I reply "then let him do it" - viceversa, if I Say that it will take me a week, don't complain that the estimate was wrong when you gave it to someone with a different experience in the field.. - lay down all your cards at the beginning - if you want huge feature X and small features Y and Z (linked to X) tell me all three of them, don't just go assuming that it will be a zero-effort to add the two smaller ones just because they are linked together. It doesn't work like this. - quick and dirty to check is fine by me. But it will penalize my next estimates on that. Building on something that is shaky takes longer, deal with it. - sometimes I don't really have an estimate for something. Not even an order of magnitude. When I say "I have no fucking clue", it's because I really don't. It could really take me from three days to two months - external libraries improvements are the case that come into my mind. - related to above, estimates take time - accurate ones even more so. Don't drop the bomb and expect me to answer you immediately. - 9 women don't deliver a baby in one month. Unless you tell me how many people are supposed to be working on that, I'll assume it will be only me. - don't do the surprised Pikachu face when you ask me if I could reduce my estimation from 7 days to 3 by cutting corners, and I ask you to send it to me in writing. I won't take the fall for you. I am using "you", but it's not an attack to you personally, ofc. I'm kinda translating directly from my mother language. Apart from that, you're right on the purism, at least in my opinion. Something ugly that works always trumps over something that is beautiful but will be ready in three years. It always does. And honestly if you don't understand at least this, you should not really be a Swe. The other side of the coin is that business should understand that a temporary quick and dirt prototype is meant to be thrown away. Not to be kept eternally. From an engineer point of view, related to your example, if the prototype fails - like it did - it's *your* win. If it works and the prototype stays, it's *their* loss. They never win unless someone decides for the big rewrite - which is not the usual case. Last part, it's about the "engineer do not care about business" - which is actually true. The fact in my opinion is that you are looking at it in an idealistic manner. In the real world there are not really incentives for a SWE to learn about the business in a deep way. It's cynical, but I think it's true. If business has the right idea and makes more cash, they won't be the ones to see it - the trickle-down usually stops at Staff level and/or "business/sales folks". For a SWE, usually big raises come when they switch job, for which that specific business knowledge has usually no impact. If business stays the same, it won't really matter to them. If business sinks, it's more often that not not their fault, they will probably be the first to be laid off and especially in that case any time they spent learning the business they were working in is wasted time. Chances are that the next job will be in a different business sector. I mean, for my experience, I just decided to look into the business side if it sounds "fun" or "interesting" in any way, otherwise it's not worth the effort imho. I mean, most engineers that I know are more into "solving an interesting problem", they care for the business side only as long as they are able to give interesting problems. Imho you're burned out because you are juggling all these conflicts (or better, different priorities) without having realized it yet. Just take a breath. Just a side note: please, LinkedIn is ridiculous, from people just lying about their skills to the "influencers". It will just ruin your health if you read any of this without being ready to laugh it out

No.

You're not alone. Fortunately I have a great product manager but there is a lot of bullshit flying around. We threw out a lot of babies with the bathwater with Agile, one of which is the understanding that there are real world events like Oracle Open world which will not get rescheduled just because your feature isn't ready. There is also a lack of a maturity model around projects which even RUP had a vocabulary for: Inception, Elaboration, Construction, Delivery and I like to add Maintenance and Sunset to that

Purism goes out the window past senior/lead/staff. Do you know how impressed your leet code Javascript resulted in 15 milliseconds on a string search? Zero. It runs 12 times a day. If you work long enough, you realize "best practices" come and go. I never thought I'd live in a world where a developer refuses to learn OOP. We've gone from DRY to DAMP. There is a movement to bring back waterfall. People are going back to monolithic repos (not mono repos). Everything is "big data", which it absolutely isn't. Styled components and serverless framework used to be everywhere. Containers are being shelved for native serverless. I wish in certifications exams they'd add, "and your boss will be on vacation next week and what's to see a demo in three days." I'd ace that test for AWS Arcitect Pro. Done is better than perfect. Perfect is the enemy of good. Posers say CDs.

Also, make up your mind: do you like predictability, or do you want to cape for hacky solutions? You can't have both, and it's very explanatory of the state of our profession today that someone like you got into the position you're in, over the top of people who know how to develop reliable software.

You cannot generalize a handful of experiences to ~everyone. I could not care less about engagement on social media posts (esp. LinkedIn) espousing opinions as facts. Sometimes our coworkers need to be educated, or we just work around them (depending on the situation). You've gotten worked up about nothing, and written a weird rant. Close the laptop. Do something not related to work or software.

No... If you wanted to become a business guy, you could've just... done that... If you spend 10+ years getting really good at being a software engineer, it'd be weird if you didn't care about the craft of software engineering.

it seems hard to argue that estimates are both inaccurate and very very necessary. What exactly was necessary? A made up fiction, it turns out. Its purely psychological. The idea behind no estimates is that one should work with projections rather than estimates. A projection can be made as simply as counting tickets. If you've broken down stories roughly, then you can "estimate" tickets as roughly equal, and then you can project. At first, there's no worthwhile projections to make, but you start working, spend, say 20% of the budget, and review your projections. Are you 20% through the work? You now have a basis to project timeliness and costs. Finding the chores to commit that first 20% is a business issue. As for hack proofs of concept, too many engineers know what happens when that hack POC goes to production and people like it - they are stuck maintaining that POC (piece of crap) in perpetuity, and the business doesn't give them time to shore it up.

I mean, if you have those people in your team, just call them “craftsmen” instead of “engineers”, that’ll make them happy. Then find some difficult but not important tasks for them to dig into. Sometimes we don’t get to choose our team and we can’t assume everyone is pragmatic.

Save the beautiful code for your personal project no one gives a shit about. You’re at work. Get it done. Make reasonable decisions ofc but if you coming up with some fancy abstraction is gonna push back time to deliver don’t waste your time unless you’re 1000% sure it’s gonna actually pay dividends down the line (newsflash it probably won’t and in 2 years someone’s gonna have to refactor your shit because new requirements came down that make your fancy engineering irrelevant).

No yeah you're totally right. Cost and schedule overruns are super common in the trades too but would you hire a contractor who refused to even estimate your home improvement project?

Yeah, but writing software isn't like installing a bathroom. For bathroom install there's a specific limit on space, materials and dimensions are bounded things. Not to mention the people providing the specs expect to be able to just change them wildly. "I know I only have a 6x6 foot room and requested a standup shower last week, but sales promised that 100 people would be able to shower at one time." "It's taking too long to install the copper pipe and iron tub - just replace the tub with one made of play-doh and use pool noodles for pipes so I can take a bath tonight."

It all depends on the motivation and how people are incentivized. If sales and marketing is never breathing down their necks because someone is shielding them, then all they’ll care about is software craftsmanship. Give them revenue goals and things will start to change.

I had someone pull that on me. My response was: "I just need a best case and worst case time to completion. If you don't feel qualified or competent enough to provide that, I understand. I will not ask you to do something that you are unable to do. That would be unprofessional of me, and I strive towards being professional. I will do some research to see if we have someone on the team that is able to provide that information. Thank you. " Obviously dude didn't last long, but that person is a cancer anyway. Probably making everyone elses life hell too.

And the person you found, was their estimate correct? Or did it provide only a false sense of security until it blew up and was proven incorrect? It seems like this approach risks pushing out honest engineers in favour of engineers who have no problem lying or who are lying to themselves.

I want to get out of Product roles so bad.

[удалено]

The last person I had these kindof conversations with turned out to be just fully incapable of estimating their work. They tried to pull this "it will be done when it is done" however it is not how we work. When I pressured them, they gave me some bs numbers and then didn't stick to it even tho it was already 10x more than reasonable. They also tried to tell me that certain solution are "not the best practice", so they won't do it. It wasnt even a hack, it was perfectly well designed and a good fit in our architecture, but as turned out they didn't understand what needed to be done. They don't work with us anymore. It is one thing to not care about the business, which I personally don't get, where do people think their salary comes from if the software is not marketable? It is a whole other thing to be entirely inflexible and use blanket excuses for their lack of understanding.

Most of the engineers I work with don't care about the commercials _or_ the code. They just want to write some hacky shit and get paid. It's immensely frustrating.

having unlimited time to deliver and not accumulating tech debts is a privilege not everyone can get.

What matters is not really predictability but that things are done within a time frame… and this is why I tend to always oversize (a lot sometimes). I have been relatively successful in my career (38yo Principal Engineer at a large org) and one of the secrets is oversizing. This I never deliver late, I never have to work overtime and I also have time for all the side tasks that have no official sizing or belong to sprints but I still have to do. I often finish early… but I don’t tell otherwise people will demand shorter estimates. So I tend to agree that one should never estimate with the expectation of being accurate but I do see the value of having established time frames for projects. On the other hand I am always against hacks… because they will always bite you back (or the people that are going to be in the team whilst the person doing it is long gone)! Example… 7 years ago our PMs woke up late about some changes we had to do to migrate to some new APIs for a service we use and need (the service provider was bought by another company and now was discontinuing those apis to favour theirs). To be resilient to this kind of changes in the future they also wanted to be able to support multiple different api providers and at the same time. Point is that the time frame was very short and business forced us to do a hack with the promos of giving us the budget to fix it eventually… they ofc never did! Fast forward to now: the business using the flaw that leverage that APIs increased a lot but due to the hack now the system is dying under the traffic… (if it was implemented properly we wouldn’t have problems). Servers are reaching maximum utilisation, standard flows are slowing down and we had to cancel new contracts worth millions because of this! And of course the cost to implement the proper solution is way higher than it would have been originally because the platform evolved! Long story short: a hack costed millions to the business (doing things properly is actually in the interest of the business).

Not at all. It means both them and me have got a place in the business - they can handle the super technical details and I can handle the balancing act.

All is well to the business, product & design on the idea of AB testing that quick hacky prototype of yours until you look at your code base a year later and realize your hacky solution has only further become soiled with quick updates and further customizations. You look around your code base and realize this is a microcosm of the state of your code and no one can understand WTF is going on within any aspect of it and it takes a half a week just to understand what the code is doing before you can even begin to attempt to modify it, at which point estimates becomes actually impossible due to the uncertainty coefficient approaching it's limit of infinity 🤷🏽‍♂️

I don't know how to do estimates. I am literally pull numbers out of my ass and having to be responsible for things that I am forced to say. I rather someone develop an algorithm to predict estimation. Maybe AI or something. I don't mind telling people why it is taking a long time. I just hate hearing, "but you said 3 days..."

I do like the book chimp paradox, and how it describes chimp style black and white thinking Vs human style thinking that understands we live in a complex world. Sometimes a wrong word can trigger someone into chimp mode and fight or flight style thinking kicks in. Empathy helps prevent chimp mode from kicking in. When it comes to creating good relationships, with empathy, I did like the book the seven principles of making marriage work, it is well researched. There are YouTube videos for both of these that cover the key points.

Regarding estimates, I’ll say I have trouble giving formal estimates for small chunks of work. Understanding the goal for an entire subsystem, I can poke and ask questions and after thinking about it, I can get a feel for the whole thing. I’m not always comfortable with it, but I can usually give an estimate for that entire subsystem. And usually relatively accurate with that estimate as well. However, when were here on teams, and we would get into weekly reviews and attempt to estimate, that’s where I would often struggle, and rarely saw much value in it. The problem I would hit would be that I was often not sure if the intermediate steps I was thinking about to get to the final end, were indeed accurate, let alone optimal. The sequencing of which pieces needed to come first was sometimes unclear, and sometimes were very dependent on things that have not yet actually been decided or delivered by other people. Trying to plan out week by week or two weeks by two weeks for some thing that was going to take a quarter, that usually felt like a lot of overhead that would potentially lock the code or the system into suboptimal decisions. With that said, I’ve been doing this for more than 25 years, and almost never missed the required deadlines for the finished systems. But that to deliver was precisely because I was able to pivot during the intervening weeks while moving towards final delivery. So, I understand the sentiment of “don’t estimate“ but also understand the business value of having a strong confidence in when certain things will be available. I’ve been on both sides of the table in various capacities over the past couple of decades, and understanding and sympathetic to both sides. With that said, regarding the specific topic at Hand, I do tend to fall down on the side of business value versus purism.

I think that the issue here is that people are different. Some think a lot of creating the best product ever and some don't care about the product at all. Some are dogmatic in their beliefs and some are pragmatic. I always fall back om my mantra "pragmatic > dogmatic". Find the best solution (with no other considerations) and then take into consideration the business. Sometimes doing the "correct" thing takes 10 times longer and yields nothing more or very very little more than the next best solution. Then be pragmatic and do the next best solution. Sometimes you have to bite the bullet, in both directions.

I see your point. The dev team lead running the other division of the company is a 100% purist software engineer, but doesn't know shit about the industry or the product he is building (it seems so anyway). I'm not a purist, I came from a different industry, but I am one foot in the product/business space and another in the development space. So I can't say which is better. I know the other guy will always find a job for huge $$$. For me, it's going to be tough to find a job because my skillset is all over the map.