If you can't effectively communicate how the results (or lack of results) of your research will impact the outcome of a high-stakes space mission you have no business being in that room from the start.

But you are right, most engineers would consider that reasonable, while complaining about the "muggles" that just don't get it.

As a Software Architect, one of my main responsibilities has been to take information presented like above and turn it into something that non-technical people can digest.

Being able to express a complex concept in simple terms is an invaluable skill.

In most WebApps the first performance bottleneck people tend to hit is the DB: missing indexes, n+1 queries, etc.

If you drank to cloud kool-aid from the beginning you kind of get used to huge costs for simple services so it's easier for your brain to justify paying 10k a month for a simple web app deployed in kubernetes, using cosmos db and any other number of services.

I've seen many companies that started on the cloud and their core architecture is so interleaved with the cloud that it would a huge investment to reduce that dependency and switch.

People use search engines to find answers to questions. If ChatGPT can give an answer faster and in a more natural format then people will flock to it. Most won't care that the quality of the response is as low or lower than what a search engine returns.

Eg: I've seen many scrum teams transforming story ponts into days or vice versa missing the actual purpose.

But they are accountable to their stakeholders (clients, upper management, etc). They take your estimate and many others from other people in the team and work those into a delivery plan.

A good manager will know how to manage risks and remove blockers in a way that gives a developer the best chance to work within the estimate. A bad manager will usually have no plan and put all the blame on the developers if things go awry.

If I have a big project and I'm dealing with a plumbing company I might not be talking directly to the plumbers but to their manager. The manager will usually ask for time/complexity estimates from his plumbers before sending me a quote. The manager will usually factor into the quote any risks plus the company's profit margin.

There's a lot of talk about agile, scrum, no-estimates and so on, but a big part of the software industry still works with time estimates and budgets communicated up front.

The fact that restaurants or any business relying on the practice use it as a reason to underpay their employees just pisses me off.

1000 - the size of company when you’re at risk of losing accountability

From my own experience and other sources (https://news.ycombinator.com/item?id=35206141) those numbers seem too high. I've seen this happen 2 times in front of my eyes while both companies were in the 100-200 range.

One of them managed to go to the next level and adapt to the new reality the other is still struggling.

I started my career in a software agency, maybe I was unlucky, but in this particular agency I overheard the more senior employees staying after-hours and making fun of the the junior employees (in their absence) and the quality of the code they had wrote. There was no actual code review process but this memory had made me very defensive in regards to my code. I was always trying to push the perfect code in one shot, which led me to overthink solution, and if for whatever reason I had to push a rushed change I felt guilty and tried to find excuses preemptively.

At one time I had to onboard the client's new dev team to a project that I had built alone for about one year. The product had become successful so the client wanted to invest in rebuilding it on better foundations to prepare for accelerating its growth.

Working alone on the code for a year had subdued my fears of public shaming but, once I started going through it with a team of seniors looking over my shoulder, my anxiety went through the roof. For every new file I was opening I started my explanation with an apology about the quality of the code and tried to explain why I didn't have the time during implementation to write that code properly.

After the 2nd or 3rd explanation one of the new guys stopped me and said something like: "You don't have to explain yourself to us. This code is the result of the context it has been written in. We are only having this conversation because the product that you helped build by writing that code is successful. Because of this success we now have the chance to spend time and think about how we can improve the code".

I only realized later, but that was one of the most liberating things anyone has ever told me. It felt like a huge weight had just been lifted of my shoulders. People were looking at my code and discussing it not as a reflection of my quality as a person but as the output of different factors and priorities at a given point in time.

I worked with that team long enough to feel deconditioned from the previous toxic behavior.

My current hobby is to try and run monolithic apps like these on serverless services like cloud run. There's still some pain related to attaching persistent storage to a container but otherwise it feels like a great option.

Is time to market critical? Will you have daily traffic fluctuation between 10 to 10k users? Will you lose a ton of money/customers for any service interruption? By all means use the latest version of managed kubernetes combined with whatever other cloud service tickles those itches. But don't forget to always keep an eye on your bills and think how can you reduce them by simplifying your architecture.

But if you're just building a corporate intranet for a few dozen users who log in once a week I'm pretty sure a simple VM (even if managed in AWS) would make much more sense.

And if you really want to roll your own there are plenty of options to make your life much easier compared to sending a rocket into outer-space. Yes it's more work upfront but after you do the setup the first time there's little to do.

infra automation & templates: - ansible, docker, etc

log storage: - mount shared storage - ELK - use a paid LaaS or monitoring SaaS

certificate management (on LB machine only): - certbot

access controls: - linux user and groups management

patch management: - enable unattanded upgrades for security patches

health monitoring: - in terms of lb nginx has that built in. - for more advanced use cases use a paid service (new relic) or a free one (nagios)

remote administration: - ansible, etc.

Don't get me wrong I use cloud on a daily basis for work, I'm just sad because most teams don't know how to use it effectively without jumping the gun.

I know that in many cases simple != easy but I can't help feeling sad while reading this.

When I started my career cloud wasn't yet mainstream bu as a beginner I was able to deploy and configure a nginx proxy and loadbalance between 2-3 backend servers without too much effort. It wasn't some kind of rocket science.

I guess the current issue is that cloud has been marketed so much that nobody who's just starting out in the industry even has a second thought about using it by default. What can I say, great job from the cloud providers in capturing their customers as soon as they get in front of the store.

Fro my limited experience many engineers fall in the trap of adding accidental complexity to an otherwise simple architecture just by trying to use the latest/coolest cloud architecture trend.

Monolith in the cloud on kubernetes? Speak no such abomination. Of course we have to do microservices, the more the better. How can we scale otherwise?

SQL DB? What is this, 2010? Of course we're going to use Cosmos DB, how else could we get "single-digit millisecond response times, automatic and instant scalability, along with guarantee speed at any scale".

Of course I'm exaggerating for dramatic effect but I rarely see teams disciplined enough to keep cloud architectures simple and clean.