How good engineers write bad code at big companies

I don't think it's that. It bothers me a lot too, and not because anyone else is judging me or anything. I think it's just that it's depressing... it sucks to be doing bad work, on top of other bad work, and unable to do good work instead. It is incredibly frustrating to care about quality but be surrounded by and constrained to work on crap. Just feels like everything went horribly wrong somewhere and you're powerless to do anything about it and your only option is to suck it up.

> “You’re a senior engineer - why did fixing this take so long?”

exactly!

If a senior engineer is responsible for the problem, but he wasn't given room to develop a proper solution in the first place, then he cannot be blamed for the outcome. And yet, this is exactly what happens.

If a system had been made well, and functions well, same senior engineer does not get the credit for not causing problems!

This is what happens when management/stakeholders don't understand what is going on, but have an expectation that is not well communicated to the engineers (and also inversely too, where engineers are not communicating the situation properly to management - or they refuse to hear it/ignore it).

> “You’re a senior engineer - why did fixing this take so long?” Because of the garbage I had to wade through to even find the problem. Because I wasn’t yet working here when this was written and I have to take time to get my head around the insanity.

The arguably unproductive part of my brain craves to reach a day where I can say literally everything straight - if this would be a true description of the circumstances, then say exactly that.

Unfortunately, in addition to not only not being a “team player” this would also be really mean to people that had different time and resource pressures when they wrote the original flawed implementation. So both burning bridges and being kind of a dick.

At the same time, there’s sometimes people that develop stuff in such a way that I will never agree with them and a few people like that are enough for me not to want at a particular team/org even if it’s maybe like just 5 to 10% (and even then often it’s about them being inherently mean/nitpicky/whatever, rather than purely technical stuff).

Obviously the irony of the above isn’t lost on me so I just bite my tongue, focus on being professional and fixing the things I can and let the rest be without picking fights that will lead nowhere - otherwise I’d be a hypocrite and the situation couldn’t be described as anything other than “a bad culture fit” from an outside perspective.

But I’ve seen a lot of really shit code and it baffles me that alarm bells don’t go off more often and people just trudge along.

Then again, you do see a lot of drama in plenty of open source projects, so maybe that’s just human nature.

Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it.

I got into this career because I like mucking about with this kind of work. Programming is sort of like building thought sculptures. Ok, maintaining them too. I spend a lot of my adult life working with these systems, so of course I care about their quality.

It is unpleasant to work on a hack-filled creaking monstrosity of a codebase. My skills, such as they are, don't help as much as it feels they should, because I rely heavily on understanding a system based on how it sort of has to work given what I know about the constraints, and hacky systems constantly confound my expectations. That means I have to spend way too much time and effort learning the idiosyncrasies and unpredictable corner cases, and so have less time to make the changes I want to make. It's like a carpenter working on a house where nothing is straight, nothing is level. Or a cook given flavorless or half-rotten ingredients to use. You spend more time picking out the bad (or picking out the good and discarding the rest) than actually cooking.

Any my scope is limited. Some changes are just not feasible to make, because there are too many hidden and/or unnecessary dependencies buried in the code. If you change one thing, everything falls apart. If you patch it together well enough to more or less work, you're faced with a long tail of subtle bugs that you'll be battling for a long time to come. There's no conceptual integrity.

Furthermore, working with a team that accepts a never-ending accumulation of creeping technical debt is also unpleasant. You can't trust that a positive review means anything. If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough. Who cares that it means less maintenance overhead in the future if nobody's planning on sticking around, or people are depending on things being constantly broken so that they can spend their days knocking off relatively easy whack-a-mole style bugs?

Bad code is actually fine. It happens. But I want to know why the code is bad, whether the reasons are defensible or not. If they aren't, I know that the codebase is going to be littered with similar crap, and that my job is going to suck. That's what bothers me so much. This is true even if I'm the author of the bad code. Why didn't the reviewer point it out? Is it like the article said, and there's nobody competent enough to spot glaring issues? That is also a component of a job that sucks.

Bad code bothers software engineers because it is often a reminder of their lack of agency in those companies.

There’s another side to this I see - and have been guilty of committing - where “it took so long because I found some code that felt wrong and while trying to fix that I found something else that felt wrong and while trying to fix that…” at some point you just have to settle for making one thing better and then getting the job done while leaving some other ugliness still in place.

The complaints in this thread seem to ignore cases like that and I’m not getting the sense that it’s because everyone is spectacular at avoiding rabbit holes.

Agree. I get accountability for code I had no control over. That's a setup.

"You’re a senior engineer - why did fixing this take so long?” This is also maddening: it's not a question arising from technical indight or a management strategy ala Drucker, ishikawa, or any other serious approach. It's a guilt trip: it's like saying why did you dress so bad at this party? It's manipulative. And nobody likes these smeer tactics.

> “You’re a senior engineer - why did fixing this take so long?”

Now add "Why can't you use/ask AI agents to fix it?" which is being shoved through your throat by management.

have you ever worked with pivotal Labs? One of my biggest faults I guess is that I worked with femme and they have such an incredibly high bar for understanding, design patterns and cyclomatic complexity and solid and test driven development principles and so forth that once you've worked with them, anywhere else you go is going to feel like a dumpster fire. so then you'll just pull your hair out thinking everyone's an idiot, even if it's really just a lot of bad incentives.

[dead]

there’s like 7 of these mastery-seekers worldwide

Fuck Jack Welch

I don't disagree that it's an accurate portrayal of reality. And of course, as I made clear in my post, I don't know if they're actually a burnt out nihilist.

My issue with the article is maybe more that the perspective and framing seem to want to lock out idealism from the conversation and encourage people to become ruthless, hard-nosed pragmatists in order to survive in this environment. Is that actually good, effective, or desirable? Again, lots of questions.

Having tried both I would rather be ground up again than just accepting my fate. I rather die fighting than the alternative.

My personal feeling is that there's a way to both agree with the underlying issues Sean writes about while being more optimistic and providing better alternatives. Something I feel I should start writing about more.

I've come to quite a specific definition of "bad code", at least the main form of bad code that infests corporate environments. It's overly complicated code, but people disagree on what that means too, and I have a concrete definition of that now.

Bad, over-complicated code is code that requires you to form an unnecessarily detailed mental model of it in order to answer a particular question you may have about it.

People rarely read code in its entirety, like a novel. There is almost always a specific question they want to answer. It might be "how will it behave in this use case?", "how will this change affect its behaviour?" or "what change should I make it to achieve this new behaviour?". Alternatively, it might be something more high level, but still specific, like "how does this fit together?" (i.e. there's a desire to understand the overall organisational principles of the code, rather than a specific detail).

Bad code typically:

* Requires you to read and understand large volumes of what should be irrelevant code in order to answer your question, often across multiple codebases.

* Requires you to do difficult detective work in order to identify what code needs to be read and understood to answer the question with confidence.

* Only provides an answer to your question with caveats/assumptions about human behaviour, such as "well unless someone has done X somewhere, but I doubt anyone would do that and would have to read the entire codebase to be sure".

Of course, this doesn't yield some number as to how "complicated the code is" and it depends on the question you're asking. A codebase might be quite good on some questions and bad on others. It can be a very useful exercise to think about what questions people are likely to seek answers for from a given codebase.

When you think about things this way, you come to realise a lot of supposedly good practices actually pessimise code in this sense, often for the sake of "reusability" of things that will never be reused. Dependency injection containers are a bête noire of mine for this reason. There's nothing wrong with dependency injection itself (giving things their dependencies rather than having them create them), but DI containers tend to end up being dependency obfuscators, and the worst ones import a huge amount of quirky, often poorly-documented behaviour into your system. They are probably the single biggest cause of having to spend an entire afternoon trawling through code, often including that of the blasted container itself (and runtime config!), to answer what should be a very simple and quick question about a corporate codebase.

big tech firms advantage is privileged access to public money, without focus on quality or cost. Good products start small.

True but this isn’t something big tech innovated. This is exactly how most large organizations work. For example, and specifically in the military, servicemembers are fungible and they are rotated every 2 years. The military even encourages attrition at certain ranks and points in people’s career.

Yep you just rediscovered alienation

https://en.wikipedia.org/wiki/Marx%27s_theory_of_alienation

I worked on compilers and tools starting in 1981. Proprietary compiler technology has disappeared over the decades and the development tools/language/process/compute have changed considerably. But the skills and role of a compiler developer seem similar, although maybe it just means this sub-field of software has matured.

That's one of the many many reasons I miss my dad so much. He went straight from MIT to GenRad circa 1970. I didn't start doing software till 1998, but we had some years of overlap -- and it was profoundly gratifying to connect w/ him on engineering topics. The learning was even bidirectional tho I'm sure I got more out of our pseudo-professional interactions than he did. Sigh. I really miss him.

if I learned anything in my (too) long career is that one should do everything possible to ensure that whoever pays you needs you more than you need the money they are paying you. it is not easy to get there right away but if you make this core thing in your career it is achievable and your career will be happy and prosperous

> this is a deliberate choice to make labor less powerful...

To be fair, though, I don't trust modern labor either if they can't figure out how to NOT vote for a rapist pedophile real-estate billionaire. Twice. Including a pandemic and a coup.

What a mess we find ourselves in.

We just went through a ton of layoffs, while those companies are making record profits.

> The problem I observe is the universal one: management doesn't care about good code, it cares about results. It's generally too hard for ANYONE to tell what's going on in a codebase unless you're experienced with it. Management can't evaluate the value of maintenance work, so it doesn't value it.

I think this is a very telling statement, but perhaps not in the way you intended. I would agree that management only cares about results, but I would posit that maybe that's a good thing. If you don't have ground-truth knowledge of a problem, you must rely on either the word of someone who does, or metrics that can be used as a yardstick.

When all a manager has to go on is someone's word, it can be really hard for them to gauge the depth, severity, and impact of the problem being expressed to them— and without any metrics, they have no way of tracking progress on resolution. In a modern codebase, you could spend YEARS on improving maintainability and still not "finish". The key (that I've found, personally) in this situation is to give the manager some form of metric to describe the problem. If you can establish a number to measure what you're advocating for, and quantify the consequences of not doing it into actual business impact, I've talked managers into taking my suggestion more often than not.

To be fair to management, it is the results that matter.

Management cares about what their management cares about. So this boils down to what the CEO cares about. The CEO cares about what the board cares about. The board cares about share prices going up.

I do believe that e.g. retaining engineers is something that helps the business. It's stupid that someone ramps up for 2 years and then goes to a different job just as they start becoming really effective. It costs companies a ton of money which they could instead just use to get people to stay. But I'm not on Google's board. It's only when Google board decides that fostering the right engineering culture is important enough for the business that something is going to change. And so far- they don't (s/Google/BigTech).

Re: Incentives- Obviously(?) the incentives are not right. So when you say "plenty of incentive" what it really means is incentive to ship sloppy code and get promoted. Or the incentive to go from Google to OpenAI and get a pay increase or whatnot.

I'd say it somewhat differently:

Management doesn't know how good the code is. So they can only look at results.

Like you say, this easily ends up rewarding people writing quick and dirty solutions.

This problem is easy to describe and hard to solve. Yet some teams do it much better than others. One solution is that management also writes code.

It's interesting that you talk that there's a lot of good management, followed by a list of things I'd call bad management: Forget about good vs bad code, of course that's unimportant. But insufficient maintenance that causes lower velocity on the next set of changes matters. Good engineering will tell you when the issue isn't just about code that is ugly, but code that slows changes down so much you'd be better off improving it.

If you set incentives that say that being sloppy and leaving landmines for the next group of people is the way to get promoted, guess what? the management is bad. Often because they are also looking at their own self interest, and expect to leave the consequences to whoever comes after them. This isn't new to big tech: You'll find this all described in books about corporate dysfunction written in the 90s.

It's all traditional principal agent problems, which just get worse and worse as you add layers of management, as the principal has agents upon agents underneath, all using the misaligned incentives. One either wants t avoid getting fired while doing the minimum, or sacrifice the health of what is around them for a good enough promotion packet/review. And since there's no reasonable way for individual objectives to align well with long term objectives, people leave landmines. When there's enough landmines everywhere, you are always better off in greenfield development. And at that point, doing any maintenance, or being stuck in a project that isn't getting fed a bunch of capital to grow it is career suicide. All about bad incentives, set by bad management.

> The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results.

The thing is, good code is a form of a good result. You need to solve the underlying problems (which manifest as impact) but if you used code to get there, that code if well designed is extensible, reusable, then you pay low maintenance on it and that same code can be used to solve other problems (ideally).

It's a difficult judgement call to make though. If your org doesn't have the right technical leadership and the performance management structure doesn't reward it then you get what you see.

It's a lesson that's always learned far too late when it becomes slow and costly to deliver something new because you've amassed so much tech debt so it's often cheaper to start from scratch (which is saying something).

I see this all fwiw in big tech myself and with my peers at peer companies.

"management doesn't care about good code, it cares about results."

And management is probably right: code is a mean, not an end

It is us, as software engineers, to make that better code brings better results

Some benefits of better code can be:

  - less infrastructure cost
  - more speed / efficiency / whatever metrics available from the users
  - easier to integrate new features
  - less issues, less time spent in maintenance etc

Very political stuff

I try to do good code. My team is rarely cited in that list of "bad players". Management does notice.

Corollary: our roadmap is not messed up. Product managements notices.

Also, good code must mean robust infrastructure. We have very few incident. Almost all our changes are successful. Incident and change managers notice.

Anyway, my point is : if good code brings no benefits to the outside world .. how is it good, exactly ?

The thing is shipping sloppy code is orders of magnitudes easier, because that's the default result. Any sufficiently determined hack-job can do it. On the other hand, steering a team of 5-10 engineers to deliver quality on (or before!) a deadline requires excessive amounts of coordination and skill. Now, is this trade-off "worth" the effort? I guess that's a matter of opinion, though I would argue in the long term quality wins out by a large margin.

There is also a lot of money, there is also good management, and there are also lots of incentives.

But management depends on your manager; at scale it becomes likely there are bad apples in every management tree. Incentives may not align with what you want or need, with work From Home policies getting shrunk. Even money sometimes is a point of contention.

So it's a problem of motivation you say

Just linking this here hoping to back you up: https://www.businessinsider.com/block-cto-code-quality-suces...

>Management can't evaluate the value of maintenance work, so it doesn't value it at all.

So it's the McNamara fallacy?

> 100% this. Stuff like database schemas gets comitted in the first sprint and never gets refactored, which completely locks you in to long term design decisions, then every subsequent PR will get held up for days in arguments around meaningless "code quality" arguments which ultimately affect nothing

I moved teams a few years ago, and the very first thing I did was push hard to re-structure the schema they (sorry, pals) slapped together without much thought. It took some fair amount of arguing, and maybe a PR that I had reviewed by only a single person and pushed through because it's easier to ask for forgiveness, but we got there in the end.

Luckily, we were able to do this before the code started hitting production traffic; it would have been significantly more difficult to fix once we started getting real data into the system.

ive never actually seen someone get fired for making some deep architectural software mistake. its alway for moving too slow, or "low code quality". i think people that were promoted for building systems that turned out bad, should be demoted

100% this. The architecture is what slows things down (or speeds them up), the code quality, variable naming, all that bs just does nothing.

In the context of reviews my experience has only been code review quality brought up as a negative thing for folks and the bar to not be a negative is low enough that folks slowly take less and less time to review code well because it isn't valued come review time.

>does the change actually make sense in the big picture"

Ideally by the time your at code review this is not a question. It sucks for everyone for it to come up.

I think people also avoid rejecting for this reason becasue of that

Eh, its either that, or the wrong people are getting promoted. Technical skills != business process modelling

100% yes. The most dangerous developers you’ll ever work with are the tactical tornadoes who crap out extraordinary amounts of code that mostly implements the exact feature that product asked them for with zero thought given to any other concerns.

AI makes these types of developers much more dangerous because they will accept anything the AI generates tha looks like it works, and they’re experienced at pushing nonsense through code reviews.

AI also provides more of a “productivity” boost to these types of developers because unlike everyone else they actually spend the majority of their time typing code.

> Are we automating this problem and going all-in on the long term costs?

I feel that is a very likely scenario.

Well obviously this is the same code the AIs were trained on.

It is possible that some projects like Oracle are beyond hope but in general cleaning up a messy code base is done piece by piece and by refusing to merge most patches which make things worse. Better than you found it is the main principle.

Just wanted to comment on the fact that I remember seeing that comment, and it left such an impression I remember it 7 years later. Thanks for the reminder, going to bookmark it this time.

Rewriting from scratch is also included in "take a few hours to ponder architecture" contained in your parent comment.

They wouldn’t have to fix the entire codebase to be doing the right thing. That approach would be more likely taken by a junior who would soon find they are fighting a losing battle. The senior engineer would accept the state of the world and consider how to make small, deliverable, manageable improvements one PR at a time, to improve the code over a longer period of time without breaking the system.

> I'd go further and say you're not a senior if your code isn't good you shouldn't be a senior.

You say that until you are tasked with doing impossible - three lines, all perpendicular, five green, two anti-green, seven in ten or more dimensions, any color; while customer only uses purple lines.

Last guy that worked on it committed seppuku. Rest of team is in mental ward. Your only team member is guy that programmed his entire life in PHP, and doesn't know backend's language. Just teach him.

Documentation, is spread between Jira, wiki, Markdown, ftp server and some napkins.

CI stands for continuous Indians. You send code to India, where a team will assemble it. It may take anywhere between a few minutes or few hours. But it beats GitHub actions. Make sure to inspect artifacts, the Indian team has a habit to add some of their ""bug fixes"" covertly.

But you gotta finish it by Thursday. Good luck.

100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clear requirements is what leads to bad code. I am fine with helping gather the requirements but if I get a list of unclear and shifting requirements and just is expected to fix it I obviously will fail.

Maybe, but then they are not "good engineers". A blog post about bad engineers writing bad code is not very exciting.

The bricklayer's building that falls over, or the cook that makes food that tastes bad and no one wants to eat and makes people sick isn't going to have a job for very long, however. And of course, the job of "cook" runs the gamut from minimum wage at a shitty diner, to being very well paid at a Michelin star restaurant. So shipping code > beautiful code, but three years from now, that one "quick and dirty hack" just to get the next version out the door has become three hundred hacks, and that tech debt is a liability preventing any movement, either fixing existing bugs or in shipping new features.

So maybe not every line of code needs to be even more beautiful than the last, but there's clearly a balance to be had. And yes, sometimes the business people are right. Sometimes they are wrong, however.

Your analogies don't work. Nobody pushes a cook or a bricklayer so hard that they cannot have a basic level of quality to their work. A meal that makes a customer sick or an entire floor of a building collapsing due to bad bricklaying is the limit the managers in those areas generally don't cross.

Not the case in commercial programming. If you manage to pull a heroic and still deliver something that does not fall over in a near-impossible deadline and with a lot of pressure then you are actually doing a huge disservice to yourself because the leadership will think "welp, obviously he can do it in those conditions" and next thing you know, next time around it will be even more difficult.

"Give them an inch, they will take a mile". Sadly this proverb very often applies to business people.

Most commercial programmers are extremely squeezed. I started daydreaming for another profession lately but yeah, ain't happening in my 40s with a very unstable financial situation.

I've read your sibling comments. It seems like you were on the other extreme and it does seem to me that now you are overcompensating by being too sympathetic with business and management. Whiplash effects are very understandable while one is still trying to find their balance. Still, don't give those people too much credit.

> A cook cannot spend time making every dish perfect.

That's too generalised. A fast food cook can't spend time to make things perfect. A tiny, fancy Japanese place will spend time to manually craft a perfect dish and you'll wait while watching the whole process.

I suspect that you can find something similar in every category you mentioned.

> Wherever you think is the right effort/benefit threshold, it will turn out to be different in a few weeks.

Very true. And experiencing this has absolutely been a useful lesson to me. I remember feeling pained over some code I wanted to write in a more robust and principled way in front of a big deadline, and after a bit of friendly push and pull with my manager, I agreed to console myself by throwing in some TODOs and FIXMEs in the comments instead of getting carried away overengineering or burning rubber just beautifying my style. I remember this ritual feeling painful at the time, though it helped me cross the finish line sooner. A few months later, it was clear that ~80% of that code would be good enough for the next year or so— by which time other parts of the application would have evolved as well. I even ended up glad I'd deferred a few of those changes just so the small refactors could be informed by things we'd learned in the meantime.

Sometimes it goes the other way, or course! Many times I've been glad for some extra care I put in early, or regretful about some I didn't. But you're right that that balance always seems to change in retrospect, one way or the other.

> I feel like I could polish any code to perfection forever.

Then you know what to work on to become an even better engineer. My recursive function for improving code has clear exit conditions. One of them indeed includes aggressive timeboxing, so on that point we're aligned.

I feel you are trying to make an argument against better code. I get it, there are very fussy programmers out there who can indeed polish stuff until the heat death of the Universe (and still be unhappy) but bringing up extremes is not very interesting in a discussion IMO.

> Is it still bad after 5min? After 30? After an hour? After a day?

Generally, time spent on code has near-zero correlation with the quality you'll get. That correlation only becomes stronger when you have a lot of trust in the person writing the code (including yourself).

As above, don't try to make managers look like the reasonable people. I've met some and I adored them but the 99% are egotistical snowflakes that will fire you the first time you say "no".

---

Nobody is saying "accommodate the insufferable nerds and give them two weeks to do what junior Joe will do in 2 hours and it'll be pretty good" here in this entire thread. People are saying "maybe we the programmers should have SOME power in some decision-making as well". I am OK with my influence being somewhere between 10-15%; that's expected, I am neither a manager nor a financial stakeholder. What I am not OK with is when that number is 0-1% and sadly that has been the norm during my consulting and contracting period. And it's the main reason due to which I am trying hard to end this period right now and settle somewhere).

Yep, you beat me to it. Arguing over good code is pointless. We should instead agree on various metrics on what a bad code is and try to avoid those.

I think we can agree on a version of bad code, specifically extremely bad code.

Just as we might agree on universally panned bad movies, but disagree on cult followings or one of us for a particular reason can't stand a popular movie.

That is to say we can all agree on extremes, but just because something isn't extremely bad doesn't make it good in everyone's eyes and that's where the contention is.

I feel like its just a reflection of people's minds. People organize their thoughts very different from one another and people often don't organize their thoughts at all when under certain constraints such as needing to ship NOW.

Especially with enterprise code you're hammering your thoughts into a shape roughly compatible with someone else's so its no wonder overtime with the constant revolving door of people that without careful shaping things can get nuts.

No one had the motivation to fix it, including management. Many of the developers saw the problem as job security.

"I love deadlines. I love the whooshing noise they make as they go by." ― Douglas Adams

Then you've been fortunate to work at places that respect engineering.

> paying people more in bonuses for goals

Then this leads to people setting tight deadlines. It's a vicious cycle.

What is there to get? Bull-headed egomaniacs on a power trip are the norm in most of the world -- on the executive positions, middle managers included.

Reasoning with unreasonable people is not impossible but drains too much time and energy... and you don't know if they will not come back to you next week and hit you with "You know what, I actually think that your idea is not as good. Let's get back to mine and...".

I have danced this dance. As much as it pains my younger idealistic self to say this, you'll know how well you'll work with somebody after the end of the first week. All the signs are there, we just choose to ignore them because you can't bail during your first month after all.

> I'm also dubious of your claim that compensation doesn't attract better talent.

Maybe higher compensation does work out for FAANG, but it does not at other larger employers, at least not for software developers. I am highly dubious about this at FAANG too though. My perspective is as a former 15 year JavaScript developer and a lot of what I saw coming out of FAANG in JavaScript land just wasn’t impressive.

I do see a lot of impressive things in the world of JavaScript but it’s almost always open source from small teams or single developers.

It's popular to mock aerospace engineering, but it's usually quite robust. Even if people still sometimes make bad decisions.

Well maybe you get hit with the gray arrows because you first make a sweeping generalization and then say "I have no sympathy for you". Food for thought?

I have communicated the business value in addressing tech debt, as in I have pointed out how many critical customer features got delayed by it and we churn customers we really can't afford to.

Still got overruled. The tech lead stepped in and threw his weight around with zero explanation to the CTO or the CEO. Who needs to hear what the engineers on the ground have to say, right? They cannot communicate!

Man, tearing down strawmen is easy. You should do better and see nuance. A lot of engineers communicate very well and are still ignored.

When all leadership is asking is "what is the short term business value?", it's pointless to make that case. It's much easier to measure "yet another feature" than "fix the root causes of what makes our product subpar and slows us down". Not only that, but an incompetent engineer's "tech debt grooming" may make things worse.

I think that this may eventually become better now that there isn't so much dumb money around (no ZIRP) and with AI assistants taking on some low-effort work (enabling companies to lay off incompetent engineers). But it will take many years for companies to adapt and the transition won't be pretty.

I work for some event ticketing business and I'd sign this. My bosses want features quickly. Does not matter to them if I need extra time to make stuff secure, doesn't matter to them if it wont scale. Its about short term revenue. Can always rebuild the software to fit the next short term goal...

Communication is not hard, it's very easy, but there are actors who's goal is to obfuscate communication and prevent others from participating.

At the end of the day it comes down to who the decision makers are and how they are incentivized to act. As a simple example - company X has product C, and they set a goal of increasing usage of feature F (of product C). Currently this feature F completely sucks and users don't want to use it - so the idea is to improve it and thus increase usage.

There are 2 ways of increasing usage:

1) Make the feature F more useful/better.

2) Force/push your users to use feature F, by aggressively marketing it, and pushing it within the product surfaces, making it non-optional, etc. and other dark patterns.

Option (1) is hard to do - it requires deep understanding of the product, user needs, the related tech, etc. It requires close tactical collaboration between product and engineering.

Option (2) is easy to do - it requires ~zero innovative thinking, very surface-level understanding of the problem, and relies purely on dark patterns and sketchy marketing tricks. You can almost completely ignore your engineers and any technical debt when following this approach.

If your decision makers are imposter PMs and marketing/sales people - they will almost always choose option 2. They will increase the 'apparent usage' of this feature in the short term, while reducing overall customer satisfaction increasing annoyance, and reducing the company's overall reputation. This is exactly how many 'growth' teams operate. Short term benefit/gaming of metrics for long term loss/reputational damage. Their success metrics are always short-term and linked directly to bonuses - long term effects of these kinds of strategies are ~always completely ignored.

The point of a business is to generate profit.

> I'd love to hear more about this!

He deployed our applications using Kubernetes and refused to implement libcluster. There was something else, too, but I can't recall what it was. It was seven years ago.

> Yeah, this is weird...

I kept telling this developer that you're supposed to test your private functions through your public interfaces, not expose your private functions and hope nobody uses them (which they did), but that fell on deaf ears. He was also a fan of defdeligate and used it EVERYWHERE. Working with that codebase was so annoying.

Not everyone wants to be a manager -- effective management and effective engineering are two very different and rarely overlapping skill sets. It honestly seems strange to me that transitioning into management is such a common career path for engineers.

I was last a Director of Engineering at a startup.

Everyone I hired is still there.

I'm fine with passing the baton, I enjoy mentoring.

I searched for "CQRS" in both the HN thread that I linked and the article that that linked, and the only mention I could find was this:

> Companies burned hundreds of thousands of engineer-hours migrating from monoliths to microservices, or from HTTP service calls to event-sourced architecture, or from event-sourced architecture to full CQRS, and so on.

Is that what you're talking about? imo this hardly counts as an attack on CQRS itself. The issue is rather with enterprise companies forcing the migration of large codebases based mostly on hype.

There's definitely some that hold CQRS, DDD, TDD, ... as _the_ way to design software and over-engineer around it, so I can understand some pushback.

Knowing those patterns is very helpful as a way to think about design problems, as long as you have the common sense to realize applying the pattern "by the book" is often overkill and you can just take some ideas out of it.

That article conflates as "Pure engineering" both reducing a software system to a small set of cohesive concepts, and architecture astronauts, when those are polar opposites.

Yeah that's true. As with most things it's a mix of factors.