> The load time improvements had destroyed their company culture. Instead of everyone coming into the office, turning on their computers, and spending the next 10min chatting and drinking coffee

One of my early tasks as a junior engineer involved some automation work in a warehouse. It got assigned to me, the junior, because it involved a lot of time working in the warehouse instead of at a comfortable desk.

I assumed I’d be welcomed and appreciated for helping make their work more efficient, but the reality was not that simple. The more efficient I made the technical part of the job, the more time they had to spend doing the manual labor part of the job to keep up. So the more I reduced cycle times, the less time they had to sit around and chat.

Mind you, the original process was extremely slow and non-parallel so they had a lot of time to wait. The job was still very easy. I spent weeks doing it myself to test and optimize and to this day it’s the easiest manual labor job I’ve ever worked. Yet I as the anti-hero for ruining the good thing they had going.

This was well talked about in Hyrums Law, which came from a Googler as well.

https://www.hyrumslaw.com/

> With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

Worked on public transport ticketing (think rail gates and stuff) with contactless last 30 years, when guys would tell me that the software was "ready", I'd ask:

> Is it "stand next to the gates at Central Station during peak time and everything works" ready?

We were working on the project from a different city/country, but we managed to cycle our developers through the actual deployments so they got to see what they were building, made a hell of a difference to attitude and "polish".

Plus they also got to learn "People travel on public transport to get somewhere, not to interact with the ticketing system."

Meant that they understood the difference just 200ms can make to the passenger experience as well as the passenger management in the stations.

For close to a decade my business revolved around a common bug in both Microsoft and Netscape, the dominant browsers of the day. With every release we were thinking 'this time they'll fix it' and that would have caused us some serious headaches. But they never did!

> Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

Very important with this, is that not every work place sees your job as that, and you might get hired for the former while you believe it to be the latter. Navigating what is actually expected of you is probably good to try to figure out during the interview, or worst case scenario, on the first day as a new hire.

Lehman talked about the developer-software-user triad. Each of the three have a different understanding of the problem to be solved.

Developers misunderstand what the users want, and then aren't able to accurately implement their own misunderstanding either. Users, in turn, don't understand what the software is capable of, nor what developers can do.

> Good intentions, hopes of correctness, wishful thinking, even managerial edict cannot change the semantics of the code as written or its effect when executed. Nor can they after the fact affect the relationship between the desires, needs, and requirements of users and the program […] implementation; nor between any of these and operational circumstances – the real world.

https://entropicthoughts.com/laws-of-software-evolution

> This makes it critically important that you, the software engineer, understand the purpose and real world usage of your software. Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

You actually described the job that Product Managers _should_ be doing: "understand the purpose and real world usage of your software".

I worked on some software that provided results to some calculations to general web users, not experts. The calcs were done in miliseconds.

We had to introduce an artificial delay of ~30 seconds to make it seem like it was taking a while to calculate, because users were complaining that it was too fast. They either didn't believe we really did the calcs, or they thought the system must have broken so they didn't trust the results.

Yes nice but also very naive. Most developers do not have that level of ownership, nor know how their users interact with the software. Their job is precisely to complete tickets from the product manager. The product manager is the one who should be in charge of UX research and “build a software that solves users problems.” Sure, in abstract that is the mission of the developers too, but in any structured (and hopefully functional) team, product strategy is not what the software engineer should be concerned with.

> The negative responses from clients were instant.

Back when I was designing TTL circuits, the TTL specifications gave a min and max time for the delay between the inputs and the outputs. I was instructed to never rely on the min delay, as the chips kept getting faster and the older, slower replacement parts will not be available anymore.

The IBM PC was frustrating to many hardware engineers, as too much software relied on timing loops and delays in the original design, which made it difficult to make the hardware go faster.

Craziest I got was users complaining their laptops were getting too hot / too noisey because I correctly parallelized a task and it became too efficient. They liked the speed but hated the fans going on at full speed and the CPU (and hence the whole laptop) getting really warn (talking circa 2010). So I had to artificially slow down processing a bit as to not make the fans go brrrrr and CPU go too hot.

This is a perfect example of a "bug" actually being a requirement. The travel industry faced a similar paradox known as the Labor Illusion: users didn't trust results that returned too quickly. Companies intentionally faked the "loading" phase because A/B tests showed that artificial latency increased conversion. The "inefficiency" was the only way to convince users the software was working hard. Millions of collective hours were spent staring at placebo progress bars until Google Flights finally leveraged their search-engine trust to shift the industry to instant results.

Absolutely - one of my favorite bug with users was an application we had made in which the loading of a filtered view was so slow, that results would come in one-at-a-time, such that clicking 'select all' would only select those ones. When this was removed, users complained until we added shift-clicking to select groups of items

Before I got into software development, I worked at a company doing technology-adjacent things. Nothing too fancy, but I got to improve a lot of things just by knowing a little powershell.

One day, a senior developer there - a guy very fond of music - was showing me his process for converting a text file into SML. His process consisted of opening two notepads: one with an SML template block, and one with the text file to be converted. He then proceeded to convert each line into SML by copying the prefix tags and postfix tags and pasting them around each line.

I wrote a powershell script in front of him to automatically do that and save an entire days worth of work, and he just stared at me. I had removed the one really mindless part of his job that he could use as an excuse to listen to a TON of music. Needless to say, he never used the script.

Reflecting on this, I feel fortunate to have had this experience early on - it really helps put things into perspective - perceived improvements to anything depend entirely on the workflow of the people impacted.

> Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

The main benefit of understanding the purpose and real world usage of your software is that you can ask the right questions while planning and implementing the software/feature/bug-fix and that you don't make any wrong assumptions.

In a situation where you have conflicting requirements or concerns regarding the change, you'll eventually be hit with "PM knows the product & customer better" or the explicit "your job is to deliver what is asked".

Rightly said.

I spent good amount of time cleaning up 15 year old codebase and removed almost 10MB of source code files which was being part of production build and it was never used. This helped reduce the build time.

I thought I'd get appreciated from everyone in the team, but it was never acknowledged. In fact my PM was warried and raised an alarm for regression. Even though I was 100% confident that there would not be any regression, the QA and PM got annoyed that I touched a working software and they had to do extra work.

I then posted on LinkedIn about this achievement to get my share of appreciation. :)

This list really stands out because it treats engineering as more than just producing correct code. It focuses on producing clarity that others can build on. The idea that clarity matters more than cleverness isn’t about style. It’s about reducing risk when someone else has to fix or extend the code at an odd hour. That’s often the difference between technical efficiency and the contribution a team can reliably depend on.

>Your job isn’t to complete tickets that fulfill a list of asks from your product manager. Your job is to build software that solves users problems.

While I agree in spirit, when you reach a certain amount of people working on a project it's impossible. The product manager's job is to understand real user problems and communicate them efficiently to the engineering team so the engineering team can focus on engineering.

I was told at university that every software system is a socio-technical system. Keeping a mental note of that fact has helped me throughout my career.

So what is the correct solution to that specific problem then, adjust loading time per customer?

https://xkcd.com/1172/

I optimised out some redundant processes on a unix system and sped up boot time.

But I had to release dummy processes which just printed out the same logs, as management didn't want to retrain operators or reprint the documentation.

Mid 90s. All training and operations manuals were hard copy.

That is https://xkcd.com/1172/

Please stop abusing co-opting and denigrating the title of engineer.

Nothing can remove complexity other than simplifying requirements. It can only be shuffled around and distributed to other areas of the system (or library, or vendor functionality etc)

I think most people don't really claim, that complexity is gone when properly abstracted, but claim that you don't have to deal with it every single time. That's the purpose of abstracting something.

Simple example: You are not dealing with the complexity of process management of the OS, every time you start any application. Sometimes you might need to, if you are developing software. Or if your application hangs and you need to kill it via some task manager. Most users however, never deal with that, because it is abstracted "away". That's the whole point. Nevertheless, the actual complex work is always done. Behind the scenes.

> I first learned about the "innovation tokens" idea in "Novelty is a loan you repay in outages, hiring, and cognitive overhead" from this, still one of my favorite essays on software architecture: https://boringtechnology.club/

I don't think this is consistently true - in particular, I think that a lot of current well-known practices around writing code result in code that implicitly relies on assumptions in another part of the system that can change without warning; and novelty is necessary in order to make those assumptions more solid and ultimately result in software that is less likely to break unexpectedly.

My former boss had a rule of “One novel thing per project”. This was both an upper and lower limit, which ensured that he was “always learning”.

I’ve followed that rule for decades and always regretted it when I couldn’t: projects were either too boring or too stressful except at the magic level of novelty.

Like most of the things Spolsky says in that article it’s pretty dubious. Following it to its logical conclusion, presumably on-call debugging work be even easier if the software had been handwritten in assembler.

    So teach your kids to kiss ass and play poltiics.

This is OP's lesson 20: Eventually, time becomes worth more than money. Act accordingly.

I’ve watched senior engineers burn out chasing the next promo level, optimizing for a few more percentage points of compensation. Some of them got it. Most of them wondered, afterward, if it was worth what they gave up.

we are human being interacting with other human beings. what you call "kissing ass" is just learning to influence and work with other humans. It is by far the most useful skill to have in workplace. But don't worry. continue your disdain of it, includeing calling it negative names, and watch your career stagnate.

I think this is what leads a lot of people to want to run their own business. Of course, a lot of those people end up needing to (or falling into the trap of) kissing the asses of investors.

> So teach your kids to kiss ass and play poltiics.

Teach your kids to kick ass, and to distrust politicians.

I agree -- the career advancement bent of this article is the most off putting aspect.

> The top people are all who kissed each others ass and looked out only for their cohort (e.g. people who were in same positions as them in early 2013). So teach your kids to kiss ass and play poltiics.

After more than 20 years in big tech, I agree, this is basically it. Your work can only get you so far. If it makes you feel any better, you can reframe politics as 'people systems' and work on optimizing the relationships in the system. Or whatever. But the gist of it is to find a powerful group and try to become a member of that group.

>b/c they didn’t know how to play politics

Or they refuse to play that bs game

"Teach your kids to kiss ass and play poltiics"(sic) ?

Does one have any significant quality time to spend with the children during the formative and developmental stages in their early lives, while engaging in major corporation sociopathetic ass-kissery?

TLDR; being an excellent (or sociopathic) ass-kisser is one way to the top; if alone at the top on your way to alone at the rest-home with kids, exes, and former employees who hate you is the desired outcome.

Are the techniques one must be adept at to manage an extensive cohort of subjects|employees|associates appropriate means of influencing the developmental progress of children, such that they can be actually happy and a beneficial influence on their own partners, progeny, and greater society?

Otherwise, does it only matter that they then have the capacity and rapacity to remain in a position to become or remain rampant over-consumers in pursuit of the most expensive visages of "happiness."

How about using the accumulated wealth in the betterment of those childrens' lives by teaching them to cooperate in meaningful adventures, to build strong and lasting relationships of kindness, to consume with regards to the full scope of the externalized costs of that consumption, to enjoy the act of creation and production of meaningful insight in art and science ?

If one's actual goal is the qualitatively and quantitatively better long term outcomes in the lives of those children; isn't a more stable and harmonious life with the reward of success measured by the reduction in suffering both within and around them by finding their own unique and innate power to imagine, cooperate, discover, and grow, all while contributing to the knowledge base and capability of humanity?

If the goal is: a widening clan of bickering, profit seeking, materialistic, continually dissatisfied workaholics with a series of divorces, early cirrhosis of the liver, to end their days spending down the accumulated wealth in a lonely senior-dementia-warehouse, well sir or madam, carry on.

The Longer part - a.k.a. "what the hell do I know about anything?":

FWIW, I am quite grateful that the fortune500 CEO/COO vater meins was principally unavailable or unable to instill most of his 'techniques' for success in my own early years. He was somewhat more present and it is debatable, malignantly, involved during more of the developmentally significant stages of my younger siblings. The results have been a mixed bag of world class success in the some arenas of life with world class catastrophic outcomes for the other arenas for at least 2/5 to 4/5 of his admitted progeny, depending on how one measures those arenas.

My own, albeit limited, advantage from milder exposure to his 'capabilities' has informed a strong aversion to the quest for infinite collateral resources and externalized risks through manipulation and deceit with and among others.

I wouldn't have it any other way, and have lived a life of immeasurable richness; having years spent with the freedom to ponder, opportunity to discover novelty, create opportunities for many to learn and participate in the arts and sciences. With the freedom to chose vainglorious poverty, indulging in a selfish amount of free time; nine years in total, doing nothing more than looking after goats and gardens in some of the wildest tropical jungle at the princely cost of less than $300 USD per month, all-in. Surviving on wild boar, feral oxen, gamefowl, marine and river fishing, all while living as prehistorically as we could imagine with my spouse and best friend. (Same person) No hot running water, barely any electricity, no petrochemical fuels, and the scarcest of rain shelter in one of the wettest places on earth. It was a kingdom unto itself, and we answered to no one for our daily needs.

Barter and trade of the product of our own two hands among the other, more civilized, inhabitants provided everything we could not make and do without. Occasional travel, by road, by air, and by sail were accomplished without needing a bank account or a land-line. We needed little, and wanted for nothing more than the continued opportunity to live among the tree frogs and roaring streams.

Tell me you're richer, without the ability to live and make lifelong friends through no hidden agenda beyond helping a community of your own choosing to do what is agreed by that community to be best for everyone; and I'll call you a fool with pockets full of money, wasting breath on children who will neither grow wise nor kind by your words and example.

Also, this isn't a sour grapes POV. I have managed a 30B PE fund, nominally in control of several hundred B worth of assets that produce significant percentages of US and global consumption of at least three commodities with properties and operations on 5 continents, and which holds patents in carbon negative and renewable power technologies and which controls some of the operations utilizing those patents. I have contributed personally to the concepts enabling bare-metal layer of hypervisor development, over 20 years ago when hardware and in-kernel virtualization were the dreams of a glorious future. I do know the difference between money and wealth, first hand. I'll take freedom over never-ending consumerism, all my live-long days.

Thats sociopathy in corporate world. Big companies have often 20-40% of such individuals, ie finance has way more (as I see daily) and concentration rises as you rise up in ranks.

The thing is - you don't have to play that game. Sure, you will miss some promotions to largely meaningless titles, much more stress and pressure in such work, and a bit of money but in most companies the money is not worth it (ie work 50% more to get 20% more compensation, in net income rather 10% more since extra income will be hit with high marginal tax bracket in most countries).

But main reason is - what you do 40+ hours weekly for decades (and especially how you do it) seeps back in into you even if you actively try to prevent that. Is it really worth tainting your personality permanently with more sociopathic behavior and thinking, with subsequent negative effect on all personal relationships and even things like personal happiness? I am old enough to see these trends among peers, they are very gradual but once you know what to look for, rather obvious.

When poor such a deal is easy to rationalize since poverty can be crippling, but once beyond that quality of life should be top priority, we are here for rather short time. Otherwise most probably regrets happen later, just listen well to old folks what they are proud of and what not so much.

I agree with you re: abstraction - one of the author's only points where I didn't totally agree.

But also worth noting that whenever you make an abstraction you run the risk that it's NOT going to turn out increase clarity and precision, either due to human limitation or due to changes in the problem. The author's caution is warranted because in practice this happens really a lot. I would rather work with code that has insufficient abstraction than inappropriate abstraction.

All abstractions drop some details. If you're unlucky, you removed details that actually matter in some context. You can only make educated guesses.

Another aspect is that some abstractions are too... abstract. The concept they represent is not immediately obvious. Maybe it's a useful concept, but if it's new, it takes time to be internalized by someone for the first time.

I've found that clarity is likely the most important aspect of success in general. Clarity in communication, for example, makes people feel invovled, heard, aligned. Cleverness is lots of acronyms and fancy phrases like vis-a-vis instead of just writing out what you mean so everyone can easily understand.

Thinking back, there really should be some lessions that send students off to solve user problems after having learned a programming language, where there is a much easier solution without having to program something. Some refinement sessions that teach them how to understand the problems.

The problem with point 3 is that once you start with a bad draft and everyone starts working on it you're kind of locked in to its trajectory, even when it'd be a lot better if you were to do it another way. You can't start from scratch even if you're feasibly within the window to do so, because now the work has started.

I know it's sometimes considered not very nice to suggest this but I felt the exactly same thing, about exactly those phrases.

I wonder if we're going to get to a different singularity, where, regardless of whether it prose was AI assisted it (1) leaks into people's way of speaking, (2) is out there frequently enough that people are skeptical even of normal prose.

At the very least, we're long past due for a word to describe the "it isn't just X, it's Y" formulation. In my opinion it's worse and more rampant than the em dash (and I like the em dash when used responsibly).

Yep. I too felt that. The insights seem genuine. But probably fell into the temptation to use LLM to structure. I feel increased cognitive load with numbered lists, thanks to LLM.

I've repeatedly told ChatGPT to stop talking like this (it isn't X, it's Y) every other sentence

I love Addy's work, and enjoyed this article -- and I completely agree that it felt very LLM-y. I'm not sure what's scarier; that we know some of this didn't come from the author (and maybe that's okay?) or that one day soon, we'll get to a point where we won't be able to tell anymore.

That pattern in particular is grating when it keeps repeating. But I don't think that LLM writing necessarily needs to have that pattern if you give it instructions to not do it and/or have a small review and edit workflow.

I’m stunned at the reception this is receiving, it’s LinkedIn-tier slop.

Even if it is AI assisted, the points are still valid and written in a way that is easy to understand.

I got the same feeling. The writing is too punchy.

oh shit. actually, yea

I liked that one, too, but for an additional reason.

Typing that first character on the page reveals the problems you didn't even know existed. You don't have a keyboard. You do, but it's not plugged in, and you have to move an unexpectedly heavy bookcase to reach the USB port. You need to learn Dvorak. You don't have page-creation privileges and need to open a ticket that will take a week to resolve. You can create the page, but nobody else is able to read it because their machines aren't allowed to install the version of the PageReader™ plugin that your page requires (and you'd need a VP exception to downgrade your PageGenerator™ toolchain to their version). And so on.

All these are silent schedule killers that reveal themselves only once you've shipped one full development (and deployment!) cycle. And as ridiculous as these example problems seem, they're not far from reality at a place as big and intricate as Google.

I wish Google would be biased a little more towards quality and performance. Their user-facing products tend to be full of jank, although Gmail is quite good to be fair.

In general I think the "ship fast and break things" mentality assumes a false dilemma, as if the alternative to shipping broken software is to not ship at all. If thats the mentality no wonder software sucks today. I'd rather teams shipped working, correct, and performant software even if it meant delaying additional features or shipping a constrained version of their vision. The minimalism of the software would probably end up being a net benefit instead of stuffing it full of half baked features anyways.

The problem is I've worked at at least 5 companies that professed a strong "bias for action" and it nearly always meant working nights and weekends to ship broken things that ultimately hurt the user and then moving on to the next big leadership project to do the same thing again, never looking back. The exception of course would be when leadership finds it's broken in 5 months and complains about poor engineering practices and asking why engineers can never get things right.

I've heard all the truisms listed in that post in my 14+ years at many companies that aren't Google and in all cases there's a major gap between the ideal and the reality.

This entire list reads to me as "I got paid 10s of millions of dollars to drink the Kool Aid, and I must say, the Kool Aid tastes great!"

Disagree. There's levels to this. Not all bad pages are better than blank ones. Ones that harms user data or worst is worst than blank pages.

Sounds a bit like a rephrasing of the old "it is better to ask forgiveness than to ask permission".

I’m a big fan of Amazon’s leadership principles. One of them is bias for action. I worked at AWS for a few years and I’d be in a meeting and someone would say bias for action and we’d all know what we needed to do.

Same. Mine is: existence is the most important feature.

It is good only if the whole team believes it.

If the team mates have a different mindset, they see it as half baked or hacky. And if there is ever some bad feedback, they just use it as a "I told you so" and throw you under the bus.

The problem with this approach is that once you've started with a "bad" draft and enough people have signed on, you're locked in to its trajectory and can't do foundational rewrites even if you were within the feasible window. It'll just end up being a bad product overall.

Starting right is important.

Similar to Hyrum 's Law for APIs

I say that in most of my past experiences I learned how to NOT do something, so when facing a similar scenario, I’d do them differently.

> If the Google culture was at all obsessed about helping users, I wonder why Google UX always sucked so much and in particularly in the recent years seem to be getting even worse.

There was no beancounter takeover and it never was so obsessed. I worked there from 2006-2014 in engineering roles and found this statement was particularly jarring: "User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock"

When I worked on user facing stuff (Maps, Gmail, Accounts) I regularly read the public user support forums and ticket queues looking for complaints, sometimes I even took part in user threads to get more information. What I learned was:

• Almost nobody else in engineering did this.

• I was considered weird for doing it.

• It was viewed negatively by managers and promo committees.

• An engineer talking directly to users was considered especially weird and problematic.

• The products did always have serious bugs that had escaped QA and monitoring.

In theory there were staff paid to monitor these forums, but in practice the eng managers paid little attention to them - think "user voice" reports once a quarter, that sort of thing. Partly that's because they weren't technical and often struggled to work out whether a user complaint was just noise or due to a genuine bug in the product, something often obvious to an engineer, so stuff didn't get escalated properly.

This general disconnection from the outside world was pervasive. When I joined the abuse team in 2010 I was surprised to discover that despite it having existed for many years, only one engineer was bothering to read spammer forums where they talked to each other, and he was also brand new to the team. He gave me his logins and we quickly discovered spammers had found bugs in the accounts web servers they were using to blow past the antispam controls, without this being visible from any monitoring on our side. We learned many other useful things by doing this kind of "abuser research". But it was, again, very unusual. The team until that point had been dominated by ML-heads who just wanted to use it as a testing ground for model training.