
Lessons learned from 14 years of engineering at Google, focusing on what truly matters beyond just writing great code.
When I joined Google ~14 years ago, I thought the job was about writing great code. I was partly right. But the longer I’ve stayed, the more I’ve realized that the engineers who thrive aren’t necessarily the best programmers - they’re the ones who’ve figured out how to navigate everything around the code: the people, the politics, the alignment, the ambiguity.
These lessons are what I wish I’d known earlier. Some would have saved me months of frustration. Others took years to fully understand. None of them are about specific technologies - those change too fast to matter. They’re about the patterns that keep showing up, project after project, team after team.
I’m sharing them because I’ve benefited enormously from engineers who did the same for me. Consider this my attempt to pay it forward.
It’s seductive to fall in love with a technology and go looking for places to apply it. I’ve done it. Everyone has. But the engineers who create the most value work backwards: they become obsessed with understanding user problems deeply, and let solutions emerge from that understanding.
User obsession means spending time in support tickets, talking to users, watching users struggle, asking “why” until you hit bedrock. The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected.
The engineer who starts with a solution tends to build complexity in search of a justification.
You can win every technical argument and lose the project. I’ve watched brilliant engineers accrue silent resentment by always being the smartest person in the room. The cost shows up later as “mysterious execution issues” and “strange resistance.”
The skill isn’t being right. It’s entering discussions to align on the problem, creating space for others, and remaining skeptical of your own certainty.
Strong opinions, weakly held - not because you lack conviction, but because decisions made under uncertainty shouldn’t be welded to identity.
The quest for perfection is paralyzing. I’ve watched engineers spend weeks debating the ideal architecture for something they’ve never built. The perfect solution rarely emerges from thought alone - it emerges from contact with reality. AI can in many ways help here.
First do it, then do it right, then do it better. Get the ugly prototype in front of users. Write the messy first draft of the design doc. Ship the MVP that embarrasses you slightly. You’ll learn more from one week of real feedback than a month of theoretical debate.
Momentum creates clarity. Analysis paralysis creates nothing.
The instinct to write clever code is almost universal among engineers. It feels like proof of competence.
But software engineering is what happens when you add time and other programmers. In that environment, clarity isn’t a style preference - it’s operational risk reduction.
Your code is a strategy memo to strangers who will maintain it at 2am during an outage. Optimize for their comprehension, not your elegance. The senior engineers I respect most have learned to trade cleverness for clarity, every time.
Treat your technology choices like an organization with a small “innovation token” budget. Spend one each time you adopt something materially non-standard. You can’t afford many.
The punchline isn’t “never innovate.” It’s “innovate only where you’re uniquely paid to innovate.” Everything else should default to boring, because boring has known failure modes.
The “best tool for the job” is often the “least-worst tool across many jobs”-because operating a zoo becomes the real tax.
Early in my career, I believed great work would speak for itself. I was wrong. Code sits silently in a repository. Your manager mentions you in a meeting, or they don’t. A peer recommends you for a project, or someone else.
In large organizations, decisions get made in meetings you’re not invited to, using summaries you didn’t write, by people who have five minutes and twelve priorities. If no one can articulate your impact when you’re not in the room, your impact is effectively optional.
This isn’t strictly about self-promotion. It’s about making the value chain legible to everyone- including yourself.
We celebrate creation in engineering culture. Nobody gets promoted for deleting code, even though deletion often improves a system more than addition. Every line of code you don’t write is a line you never have to debug, maintain, or explain.
Before you build, exhaust the question: “What would happen if we just… didn’t?” Sometimes the answer is “nothing bad,” and that’s your solution.
The problem isn’t that engineers can’t write code or use AI to do so. It’s that we’re so good at writing it that we forget to ask whether we should.
With enough users, every observable behavior becomes a dependency - regardless of what you promised. Someone is scraping your API, automating your quirks, caching your bugs.
This creates a career-level insight: you can’t treat compatibility work as “maintenance” and new features as “real work.” Compatibility is product.
Design your deprecations as migrations with time, tooling, and empathy. Most “API design” is actually “API retirement.”
When a project drags, the instinct is to blame execution: people aren’t working hard enough, the technology is wrong, there aren’t enough engineers. Usually none of that is the real problem.
In large companies, teams are your unit of concurrency, but coordination costs grow geometrically as teams multiply. Most slowness is actually alignment failure - people building the wrong things, or the right things in incompatible ways.
Senior engineers spend more time clarifying direction, interfaces, and priorities than “writing code faster” because that’s where the actual bottleneck lives.
In a large company, countless variables are outside your control - organizational changes, management decisions, market shifts, product pivots. Dwelling on these creates anxiety without agency.
The engineers who stay sane and effective zero in on their sphere of influence. You can’t control whether a reorg happens. You can control the quality of your work, how you respond, and what you learn. When faced with uncertainty, break problems into pieces and identify the specific actions available to you.
This isn’t passive acceptance but it is strategic focus. Energy spent on what you can’t change is energy stolen from what you can.
Every abstraction is a bet that you won’t need to understand what’s underneath. Sometimes you win that bet. But something always leaks, and when it does, you need to know what you’re standing on.
Senior engineers keep learning “lower level” things even as stacks get higher. Not out of nostalgia, but out of respect for the moment when the abstraction fails and you’re alone with the system at 3am. Use your stack.
But keep a working model of its underlying failure modes.
Writing forces clarity. When I explain a concept to others - in a doc, a talk, a code review comment, even just chatting with AI - I discover the gaps in my own understanding. The act of making something legible to someone else makes it more legible to me.
This doesn’t mean that you’re going to learn how to be a surgeon by teaching it, but the premise still holds largely true in the software engineering domain.
This isn’t just about being generous with knowledge. It’s a selfish learning hack. If you think you understand something, try to explain it simply. The places where you stumble are the places where your understanding is shallow.
Teaching is debugging your own mental models.
Glue work - documentation, onboarding, cross-team coordination, process improvement - is vital. But if you do it unconsciously, it can stall your technical trajectory and burn you out. The trap is doing it as “helpfulness” rather than treating it as deliberate, bounded, visible impact.
Timebox it. Rotate it. Turn it into artifacts: docs, templates, automation. And make it legible as impact, not as personality trait.
Priceless and invisible is a dangerous combination for your career.
I’ve learned to be suspicious of my own certainty. When I “win” too easily, something is usually wrong. People stop fighting you not because you’ve convinced them, but because they’ve given up trying - and they’ll express that disagreement in execution, not meetings.
Real alignment takes longer. You have to actually understand other perspectives, incorporate feedback, and sometimes change your mind publicly.
The short-term feeling of being right is worth much less than the long-term reality of building things with willing collaborators.
Every metric you expose to management will eventually be gamed. Not through malice, but because humans optimize for what’s measured.
If you track lines of code, you’ll get more lines. If you track velocity, you’ll get inflated estimates.
The senior move: respond to every metric request with a pair. One for speed. One for quality or risk. Then insist on interpreting trends, not worshiping thresholds. The goal is insight, not surveillance.
Senior engineers who say “I don’t know” aren’t showing weakness - they’re creating permission. When a leader admits uncertainty, it signals that the room is safe for others to do the same. The alternative is a culture where everyone pretends to understand and problems stay hidden until they explode.
I’ve seen teams where the most senior person never admitted confusion, and I’ve seen the damage. Questions don’t get asked. Assumptions don’t get challenged. Junior engineers stay silent because they assume everyone else gets it.
Model curiosity, and you get a team that actually learns.
Early in my career, I focused on the work and neglected networking. In hindsight, this was a mistake. Colleagues who invested in relationships - inside and outside the company - reaped benefits for decades.
They heard about opportunities first, could build bridges faster, got recommended for roles, and co-founded ventures with people they’d built trust with over years.
Your job isn’t forever, but your network is. Approach it with curiosity and generosity, not transactional hustle.
When the time comes to move on, it’s often relationships that open the door.
When systems get slow, the instinct is to add: caching layers, parallel processing, smarter algorithms. Sometimes that’s right. But I’ve seen more performance wins from asking “what are we computing that we don’t need?”
Deleting unnecessary work is almost always more impactful than doing necessary work faster. The fastest code is code that never runs.
Before you optimize, question whether the work should exist at all.
The best process makes coordination easier and failures cheaper. The worst process is bureaucratic theater - it exists not to help but to assign blame when things go wrong.
If you can’t explain how a process reduces risk or increases clarity, it’s probably just overhead.
And if people are spending more time documenting their work than doing it, something has gone deeply wrong.
Early in your career, you trade time for money - and that’s fine. But at some point, the calculus inverts. You start to realize that time is the non-renewable resource.
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.
The answer isn’t “don’t work hard.” It’s “know what you’re trading, and make the trade deliberately.”
Expertise comes from deliberate practice - pushing slightly beyond your current skill, reflecting, repeating. For years. There’s no condensed version.
But here’s the hopeful part: learning compounds when it creates new options, not just new trivia. Write - not for engagement, but for clarity. Build reusable primitives. Collect scar tissue into playbooks.
The engineer who treats their career as compound interest, not lottery tickets, tends to end up much further ahead.
Twenty-one lessons sounds like a lot, but they really come down to a few core ideas: stay curious, stay humble, and remember that the work is always about people - the users you’re building for and the teammates you’re building with.
A career in engineering is long enough to make plenty of mistakes and still come out ahead. The engineers I admire most aren’t the ones who got everything right - they’re the ones who learned from what went wrong, shared what they discovered, and kept showing up.
If you’re early in your journey, know that it gets richer with time. If you’re deep into it, I hope some of these resonate.
> At scale, even your bugs have users.
First place I worked right out of college had a big training seminar for new hires. One day we were told the story of how they’d improved load times from around 5min to 30seconds, this improvement was in the mid 90s. The negative responses from clients were instant. 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 the software was ready before they’d even stood up from their desk!
The moral of the story, and the quote, isn’t that you shouldn’t improve things. Instead it’s a reminder that the software you’re building doesn’t exist in a PRD or a test suite. It’s a system that people will interact with out there in the world. Habits with form, workarounds will be developed, bugs will be leaned for actual use cases.
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.
> 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.
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.
Imagine you like writing code, and someone automates that part of the job so you have to spend more of your time reviewing PRs and writing specs...What a great comparison; I've never thought of it this way. It's obviously not perfect since the automation is so temperamental shall we say, but this does give me more empathy for the countless workers whose jobs have been re-natured by technology.
From their prospective, the efficiency increases and more gets done, but the hours and wage stay the same and the number of co-workers may decrease.
I don’t even have to imagine it, you just described my job now that we have LLMs.
Reading it back now it does seem pretty obvious. That’s what I get for commenting right after waking up!
All good, it's a Monday morning
efficiency is the enemy of employment, no?
The amount of work expands to fill the available labour. All other things being equal, at least. Which they aren't, but it's a usefully wrong model.
There’s many praises to sing about efficiency, (and I don’t take your 1 liner as a position against it). That said, efficiency, job creation, and underemployment overlap quite a bit.
There’s far more scientists, programmers, and doctors today than farmers and stablehands.
At the same time, people who lost manufacturing jobs to automation and outsourcing, did not get jobs with equivalent pay and growth.
Human brains do not get retrained very easily, and so every technological revolution is a boon to those who grasp it, and a challenge for those who invested their time in skills no longer in demand.
One of my work involved automating some process which was very manual and tedious, took a lot of time and there was dedicated employee for that process. After I did the project, it turned out that this job wasn't necessary anymore and that employee was fired. I felt uneasy about the whole situation.
In Norway there's laws for that, but other places do it even without them. You just retrain the person to do something else. He might take a job of a temp that was hoping to get a fast contract (instead of a few weeks at a time during trial period). Other than that, it's good for the person (not losing job) but also for the company - you get a tried person with good work ethics that comes on time. It's not zero cost to find somebody like that.
A lot of places in the US are not, in my experience, that intelligent about hiring people.
Or, say rather, the externalities of the cost of hiring are not imposed on the people choosing to fire, directly, so they can say they "improved efficiency" by firing someone, and then the people trying to find reliable labor do not experience any improvement that might have been available by migrating the person.
agreed. the "lump of labour" fallacy is a thing -- the idea that there are always more bodies and that it's trivially easy to hire, train / get up to speed, and work them.
in practice hiring and firing is expensive and often very risky. Bjorn the office worker may now be redundant and have a room temperature IQ but he's shown he'll show up on time, sober, and is liked by his coworkers enough, so throwing $5k to retrain him may be a far, far smarter investment then blowing $7k to hire a rando for another position...
Yeah the bar for competent is surprising hard to hit. A human being that shows up on time and it's reliable, doesn't have a problem with drugs or alcohol, or has a sick family member and just needs an advance. Good help is hard to find!
If you're only getting those kind of candidates, then your job offer isn't attractive enough.
then the pendulum swings the other way and now I have ruthless mercenaries chasing $$$ who will jump at the first opportunity
and not every job needs to be top-shelf.
Betty in Accounts-Payable just sorta needs to be there and not screw up too often. I don't need a super-star, and if we have to move her to another part of Accounting that's fine; I'll save my money for a solid CPA or two, etc.
I understand the rest, but an otherwise capable person with a sick family member does not clear the bar for competent? Saddening if that’s where we are as a society.
I think the key part of that sentence was "...and just needs an advance", implying that they're going to take the job, ask for a cash advance for a (possibly fictional) sick family member, and immediately quit.
It’s hard for some people to understand that situation until they are in it. Unfortunately.
Totally agree with you.
Why do the laws exist if its better for (almost) everyone involved? Without the laws why would people not do it that way if its the better approach?
Many laws solve the problem of high initial cost dissuading globally good actions. Laws forcing everyone to buy insurance, for example. It's very easy to see that where such laws don't exist, almost no one buys insurance, making everyone worse off.
This is also an example of the same kind of law.
Insurance is an interesting example, I would have expected one that causes more direct harm to others like drunk driving.
How are we all worse off when fewer people have insurance?
Healthy young people are less likely to buy insurance than sick older people. But if only sick older people buy insurance the payouts per insured are going to be higher. That in turn causes high premiums. Insurance works if everyone buys in, pays while they are young and relatively healthy, and gets paid healthcare when they are older and sicker.
If you “game” it, it breaks the whole system.
Now some of you might be thinking “why should a young and healthy guy like myself subsidize the old sick people?” The answer is that you will also get old.
What you are describing isn't really private insurance though, its a privately run socialized healthcare system. There's nothing wrong with that, it simply isn't insurance.
You're right. However, all insurance needs to get more in premiums than it pays out in claims in order to be viable. The details will differ about whether there is some kind of bias for certain people to pay more and claim less. With socialized healthcare, the coverage is just much broader and there is less room for "gaming" the system.
Think of something like home owner insurance. Your insurance rates depend on exactly how your home is built, what type of heating system it has, where it is, etc. The rates, carefully calculated by actuaries, act as a signal to you as to how dangerous your house is to yourself, but also to others. If you set your house on fire due to negligence and cause the next house to burn, you might be liable for damages there as well.
Forcing everyone to buy such insurance forces everyone to fully pay for the expected cost of the danger inherent in their house. Over time, this causes houses to be constructed in a safer manner. If people are not forced to buy insurance, they don't buy it, and so this evolution over time does not happen. Also see [1].
Some financial tools are amazingly clever - whether they are morally good or bad. Bits about Money is a great blog to build insight into some of these constructions [2].
Another example for your initial question is car seats for kids. If you don't force em, nobody buys em. Then their kids die.
For the insurance example, you're describing insurance as a forcing function for better made, safer buildings. That's what building codes are for though, we shouldn't need to have both and building codes are a more efficient and direct way of ensuring safe buildings.
For car seats, I'm not sure how we could know that people wouldn't buy them. I don't expect anyone would propose dropping the requirement to see how the market responds, and probably rightfully so. If car seats are much safer though (and I'm obviously not disputing that), people that can afford one would buy it anyway.
> ... building codes...
I agree that in an ideal world that would be sufficient. But in practice, governments rarely deploy trained actuarial to make decisions, rather relying on politics and shoddy studies. Government codes also change very slowly. Insurance companies (whether private or public), under the financial incentive, are constantly changing their policies and rates in response to new data and calculations. I would be open to looking at studies that resolve this question one way or another.
> ... car seats...
I grew up in a poor global south country. Rich people, who clearly can afford them, don't buy car seats. Many people who live in countries where they are forced to buy car seats, when they come back on vacation don't use car seats for their kids. People can be very irrational.
I'd love to see this argument used to get rid of legal authority to create building codes. You make a great point, and you're effectively pointing to the fact that, at least for that specific problem, the market is much more efficient and solving the problem than government regulations.
The car seats one is tough. If you've seen first hand examples of people actively choosing to forgo car seats, I'm not sure if that's a problem governments should solve. Unless the state directly claims "ownership" as it were in the child, the parent is their legal guardian and if the parent makes a terrible choice they have to live with the repercussions. We don't regulate all decisions that can harm a child, that's a tough line to draw.
Norway has very strict pro-workers laws in general, it's just one facet of them. One Norwegian explained it to me like that: in the late '60 when Norwegian oil industry started developing, workers realized that they can incur great losses on the companies if they organize/unionize and strike together. They used that as a leverage to both change their contracts (to include paid sick leave and such) and also get better working conditions (Norwegian platforms have both better safety and on platform to on land ratio).
And later other trades did the same. Some of the things in contracts trickled down to the law. But still some laws apply only to companies where at least a certain % (is it 50%?) are unionized.
The general picture is more or less like that, but please verify the details.
And they will have to go find another job instead. It feels weird but this is how we raise living standards - removing human labor from production (or, in other words, increasing the amount produced per human)
Automation is a game of diffuse societal benefit at the expense of a few workers. Well, I guess owners also benefit but in the long term that extra profit is competed away.
That's a highly idealized view that I hope we can agree doesn't completely jive with what we see in society today. If a small number of shareholders reap all the profits, the vast majority of the benefit from automation flows to them, and it's even possible for the lives of average people to get worse as automation increases, as average people then have less leverage over those who own the companies.
Inflation adjusted incomes are up in the US across the board. The affordability problem is largely the price of housing because it's illegal to build.
Incomes are up, but the expenses are up as well, especially with the upcoming changes in healthcare for people on the ACA.
Also any comparison of wage growth vs corporate profit growth over the last 30 years shows that wages have not kept pace with the increase in productivity.
So incomes are only just barely keeping up, when they should be booming.
How can inflation adjusted income be up and there still be an affordability crisis?
Housing is not part of the inflation calculation. There IS a housing inflation crisis.
Household income is more than just wages. Household income can go up while wages remain stagnant or shrinking because other pieces of the pie are increasing (e.g. work benefits, investments, money from the government). https://fredblog.stlouisfed.org/2016/09/sources-of-household...
The price of housing can rise even faster than incomes.
Housing is only a part of the basket used to measure inflation. Housing's price rose faster than the weighted basket average, some other goods and services rose slower or even fell.
Accommodation costs are the first part of any sensible measure of inflation. If you're not factoring in housing then you're fudging the figures.
Many people don’t see housing inflation - if you bought a house in 2020 and house prices were up 80% since then it doesn’t affect your housing costs, especially in the US where mortgage rates are fixed for length of term even if interest rates sky rocket.
Yes? Who says otherwise?
As long as accommodation isn't 100% of your basket of goods and services you use to measure inflation, accommodation can rise in price faster (or slower) than the basket. This ain't exactly rocket science.
If the mandatory basket item expense raises, it should also become a larger portion of basket, as the basket is supposed to measure the cost of living. So either CPI is not properly measuring the cost of living, or there isn't an affordability crisis.
You cannot have rising inflation adjusted wages and worse spending power, unless the inflation is not being measured meaningfully.
Housing, schooling, healthcare, daycare, food.
Samsung TV purchasing power has skyrocketed, though, so there's that.
Inflation also corrodes your savings and investments.
Yet more and more people are struggling to afford even basic necessities and one can only dream of the luxury of the 50's when a single working class person was able to pay and cover for housing, car, family and even have enough for leisure. Where has all the economic surplus gone? Right...to the bourgeois, the capital owning class that exceedingly extract more and more of the wealth generated by the society.
because the developing world is producing a lot of things except the housing.
They also don't produce haircuts.
On average, most large cap stocks (MSFT, GOOG, AAPL, etc) are owned by millions of retail investors through 401Ks, mutual funds, ETFs, and direct ownership.
Median net worth at 40 years old in the US is less than 150k. Most Americans benefit very little from share prices rising, at least directly.
Of the US stock market half is owned by 1%.
Actually I believe this graph is half of US-owned equities and mutual funds is owned by the top 1% of Americans right? This doesn't include other extremely large holders such as sovreign wealth funds like norway/singapore or very large pension funds like the ontario teachers fund etc....
The USA is rather unique in its low pensions compared to countries in the EU or Australia (notable for its high contribution rates).
Tech founders (part of the 1%) own about 2% of the stock market.
About 18% is owned by foreign entities.
> If a small number of shareholders reap all the profits
It's not greater profits but lower costs (and prices) that matter here.
Lower costs only translate into lower prices if sufficient competition is there. That is not true for many markets
That’s the big difference in China. When there is competition for everything —> prices are low. Not a lot of profits for investors, though…
Which markets do you have in mind?
I'm all in favour of lowering barriers to entry, too. We need more competition.
Be that from startups, from foreign companies (like from China), or from companies in other sectors branching out (eg Walmart letting you open bank accounts).
Untrue, most of the time. Even with a monopoly, there's still a demand curve.
Would you rather sell one widget for $1000 or 1000 widgets for $10? Does the answer depend on costs?
The ROI for a large corporation tends to be around 10%.
Everybody can be a shareholder in a publicly traded company. It's pretty easy.
If you want to spin up some conspiracy theory about elites snatching up productivity gains, you should focus on top managers.
(Though honestly, it's mostly just land. The share of GDP going to capital has been roughly steady over the decade. The share going to land has increased slightly at the cost of the labour share.
The labour share itself has seen some shake up in its distribution. But that doesn't involve shareholders.)
Everyone with excess disposable income can be a shareholder in a publicly traded company.
The oligarchy of the CxOs and boards and cross-pollination has led to concentration of the rewards of companies into the their hands, compared to 40 years ago.
All the productivity gains have not gone to labor, its predominately gone to equity and then extracted via options and buy backs to avoid tax which means public service and investment has gone down.
The craziness of the USG borrowing to fund tax cuts is the ultimate example.
> All the productivity gains have not gone to labor, its predominately gone to equity [...]
What your evidence for that? See https://www.brookings.edu/wp-content/uploads/2016/07/2015a_r... for a good account.
> [...] and then extracted via options and buy backs to avoid tax which means public service and investment has gone down.
You seem very confused about how capital markets work. Are you also suggesting buy backs are morally different from dividends?
In any case, the whole point of investing (at least to the investor) is to eventually get more money back than you put in. Returning money to investor is not a bug, it's the point.
> The craziness of the USG borrowing to fund tax cuts is the ultimate example.
Blame voters.
There have been times historically where that was true but all productivity gains have been captured by the .1% for the past few decades.
And someone don't need to look further than this quite interesting report by the Rand Corp: https://www.rand.org/pubs/working_papers/WRA516-1.html
We document the cumulative effect of four decades of income growth below the growth of per capita gross national income and estimate that aggregate income for the population below the 90th percentile over this time period would have been $2.5 trillion (67 percent) higher in 2018 had income growth since 1975 remained as equitable as it was in the first two post-War decades. From 1975 to 2018, the difference between the aggregate taxable income for those below the 90th percentile and the equitable growth counterfactual totals $47 trillion.
Income is the wrong measurement. Total employee compensation is the more accurate one, and averages around 145% of salaries.
Total employee compensation includes things like the value of employer provided health insurance.
What's your evidence for that?
It's narrow vs wide views. Wide views, automation and the like has improved the economies massively. But narrow views, people have lost their jobs, had to retrain and basically restart their career, and some never found another job.
This isn't just automation btw, but also just business decisions, like merging companies, outsourcing, or moving production elsewhere - e.g. a lot of western European manufacturing has moved eastwards (eastern Europe, Asia, etc). People who have a 30+ years career in that industry found themselves on the proverbial street with another 10+ years until their retirement, and due to trickery (= letting their employer go bankrupt) they didn't even get paid a decent severance fee.
I've not seen a correlation between automation and wealth, though there is an extremely string correlation between energy use and wealth.
I don't think its automation that increases living standards. We increase living standards by consuming more energy, and that often comes along with increasing the amount of costs we externalize to someone else (like pollution or deforestation, for example).
> It feels weird but this is how we raise living standards
yeah but it's clear that we're not doing that, and are arguably going the other direction as hard as possible
> removing human labor from production
Karl Marx would argue this evil because this take away the value and job satisfaction from the labour.
You might notice that Karl Marx isn't exactly the pinnacle of economics.
Quoting Marx is a bit like quoting Aristotle or Ptolemy.
"Laid off" may be more appropriate than "fired", but in essence, removing the need for costly labor is often the main "value" of any technology. Society as a whole comes out ahead from it, I mean for all the ice transporters and merchants put out of a job by electric refrigeration, and all the sailors put out of a job by modern cargo ships I think we're better off for it. But at the individual level it does make one uneasy about the prospects of individuals affected by it. My personal conclusion is that people have a personal duty to anticipate and adapt to change, society might give them some help along the way but it doesn't owe them that their way of life will be maintained forever.
This is putting the apple cart before the horse.
Economy should be a tool for the society and to benefit everyone. Instead it's becoming more and more a playground for the rich to extract wealth and the proletariats have only purpose to serve the bourgeois lest they be discarded to the outskirts of the economy and often to the literal slums of the society while their peers shout "you're just not working hard enough".
Very true. We waste alot of valuable labor on “software engineering” that is grossly inefficient. Capital gets allocated to these so called startups that are incredibly inefficient.
This says a lot as relating to the rise of AI and the fear of job loss. There's going to be displacement in areas we can't predict, but overall it might very well just lead to leveling up the entire workforce.
> it might very well just lead to leveling up the entire workforce.
How could that possibly work?
At some point I could see white collar work trending down fast, in a way that radically increased the value of blue color work. Software gets cheaper much faster than hardware.
But then the innovation and investments go into smart hardware, and robotics effectiveness/cost goes up.
If you can see a path where AI isn't a one-generational transition to most human (economic) obsolescence, I would certainly be interested in the principle or mechanism you see.
Craftsmen will have a resurgence, that's probably a 'leveling up' in terms of resilience against AI takeover. There's just no way of automating quite a few of the physically effective crafts.
So the rich who can afford craftsmen will get richer, spend more on their multiple houses, perhaps. But that's literal crumbs, one or two jobs out of tens of thousands. There's no significant "leveling up" there at the societal levels of job destruction we're talking about.
I agree. I was brought on as an intern to do automation for a business team. The company had built this gargantuan complex "programming tool" to help the boomers who'd been there for 30 years adjust to the new world (a noble endeavor for mortgage holders without college degrees, i believe). I was brought in to basically fuck around and find little things to optimize. In 2 months I wrote a python script to do about 50% of the teams work near instantly.
They had layoffs every year and i remember when the "boss's boss" came to town and sat at our table of desks. She asked me and i excitedly told her about my progress. She prompted how i felt about it and i nearly said "its very easy as long as you can program". But mid sentence i saw the intense fear in the eyes of the team and changed subject. It really hit home to me that these people actually were doing a useless job, but they all had children who need insurance, and mortgages that need paying. And they will all be cast out into a job market that will never hire them because they came on at the very end of not needing a college degree. The company was then bought by a ruthless and racist "big man investor" who destroyed it and sold it for parts. But my manager did somewhat derogatorily refer to the only programmer near them as "the asian".
> refer to the only programmer near them as "the asian"
If they ever hired a second one, they’d have to learn actual names. Or maybe it would be “the asian” and “the new asian”!
How do you feel about the whole thing years later?
Back in the day one company had a dedicated copier operator who was very unhappy after a Xerox service tech did away with the job by enabling the network printing and scan to email functions. The customer had upgraded their old copier out of necessity but had never changed their workflow.
This will not be unusual for any kind of software engineering work to be honest. A big chunk of work in B2C companies has to do with customer support, for example; building websites, apps, writing content, chatbots, etc with the objective being that people do not call customer support, because people on phones don't scale very well. And the other part is that when they do call, that the CS agent can address the issue quickly and has minimal administrative overhead.
But it's a weird one, because it costs millions to build features like that.
I had that on my very first project. I couldn’t understand why the people on site were so hostile to me. Afterwards I was talking to the salesman about this and he told me they were all fired when the project went live.
> So the more I reduced cycle times, the less time they had to sit around and chat.
Couldn't help but imagining Darryl getting mad at you.
Thanks for the story!
Yup same story here, also warehouse optimization. I was the reason the employees got new scanners and oh my... the scanners didn't have a physical keyboard. Now all the 50yo+ would have to aim on a touch display which is apparently impossible.
Also we had to introduce some fixed locations and storage placement recommendations. Our storage workers almost revolted. After a few months it settled though.
Yous story is not about optimization: it is about change imposed to people who did not request it, nor felt the need of it.
It 100% was about optimization. Introducing new devices, with more capabilities (storage place recommendations for example), that weren't 10 years old and broke every 2 weeks is optimizing.
> 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.
The faster the LLM spits out garbage code, the more time I get to spend reviewing slop and dealing with it gaslighting me, and the less time I get to spend on doing the parts of the job I actually enjoy.
Mandatory reference: https://thedailywtf.com/articles/Classic-WTF-The-Indexer
insane mindset. This kind of thing is why there is no industry left in anglosphere outside US
Insane mindset that people should work modestly, get paid modestly and live in the fruits of a wealthy society? As opposed to breaking their backs to make a boss even wealthier?
The efficiencies are always to the benefit of the wealthy, the wage gap grows. You work hard, you still get fired.
Cap top wages to 5x the lowest, companies can't own housing except socially beneficial housing, individuals get 2 house maximum.
This was well talked about in Hyrums Law, which came from a Googler as well.
> 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.
I believe it.
I also believe an off the shelf example of how to use the library correctly will save everyone a lot of pain later.
I always strongly suggest sample code to people designing new APIs. Can be a very revealing exercise.
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!
I was curious what the commenter's business was, and found this post about HTTP protocol latency: https://jacquesmattheij.com/the-several-million-dollar-bug/
What a cool guy https://jacquesmattheij.com/domains-for-sale/
>FREEDRUPALWEBSITEHOSTING.COM
Yeah that's not gonna work nowadays.
>DOWNLOADWEBCAM.COM
Is that like Download More RAM?
>BROWSEHN.COM
Hey, I'm browsing that place right now!
>MUZICBRAINZ.COM
This sounds 100% legit no virus softpedia guaranteed.
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.
> "People travel on public transport to get somewhere, not to interact with the ticketing system."
I really like this line because it applies to so many things we build.
Public transport is an interesting one because it applies to so many things. If you need to use it but can't depend on it, it's a huge stress creator and time waster. Suddenly you need to pad times by hours to ensure you don't miss your appointment.
Notice the words there, "miss appointment" and not "miss bus or train". The outcome is what matters, not the transport mechanism.
Or, maybe you're traveling in a foreign country. Having every car in the metro display the line in a digital way showing the previous stops, current location and next stops in English is huge for eliminating doubt. Having the audio in multiple languages and clear is important too because maybe you're sitting down and everyone is standing in front of you so you can't see the display clearly. Having a non-digital map as a backup on the wall in case there's a hardware failure is a good idea too.
Thinking "no one needs any of that waste because they can just use their phone" is the wrong mode of thinking. Maybe there's no service because you're underground or maybe that person's eSIM isn't hooked up yet or isn't working. These are real problems.
The travel experience outcome in the grand scheme of things matters a lot. It could mean having a smooth trip or a questionable experience. It could be the difference between recommending the country to your friends and family or not. Suddenly it affects tourism rates at a global scale. Maybe not a lot, but it has an impact.
Thales?
> 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.
This is huge advice for people who want to climb a given career ladder.
The overwhelming majority of organizations will say they want you focused on real user problems, but actually want you to make your boss (and their boss) look good. This usually looks more like clearing tasks from a list than creating new goals.
At Google there are both kinds of teams.
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.
> 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".
Everyone in the team should have that.
Obviously at different levels of focus and completeness, but the Product Manager is supposed to be communicating in both directions and they rarely do, they just take the feature list and tick them off.
Telling the customer that they can't have something or it needs to be different and having their trust that you aren't doing it just to cut corners is what good Product Managers do.
As a developer of new things, if you allow someone else to capture this value from you, you become fungible; additionally, for your group, having technology designed to solve problems without grounded but expansive ideas of how much is possible, limits your team's ability to the mundane rather than the customer delighting. Some product folks have internalized the possibilities but some haven't.
Ideally its a mix, a good PM should understand the customer/market more than the developer has time to do, and then they can have conversations with devs about how to most effectively fill needs. In reality, these PMs seem more like unicorns rather than expected table stakes, but hey.
[dead]
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.
This is one reason UIs have animations added, the kind that technical users like to complain about or remove. By making things feel more physically grounded they prevent users from getting lost and confused and give them more intuition about things.
In your case you could show more intermediate values, graph things, etc.
I often chuckle when (our) animations may have more complex math that consume more resources than the awaited logic/call that they gate.
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.
Good software engineers are concerned with product strategy. They might not be able to decide things but they can help inform product about options because they're closer to actually building things.
If you just implement product tickets you'll probably get replaced by LLMs.
You need to be a product-minded engineer.
It’s crazy how fast the tables turned on SWE being barely required to do anything to SWE being required to do everything. I quite like the 2026 culture of SWE but it’s so much more demanding and competitive than it was 5 or 10 years ago
Developers shouldn't test, they should throw it over to QA who will test it precisely to meet the defined requirements.
The Product Manager's job is to communicate the customers needs to the developers/designers and the developers/designers constraints back to the customers.
It's up to the developers and designers to understand those constraints and make sure they are communicated back.
Ive observed a modern trend of little to no QA. Managers and CTOs insist developers can test their own systems. Maybe this makes more sense in the early phases of product development where I find myself lately? Seems to capture a lot of dev's time.
I have never seen a pure ticket based / zero ownership approach ever work.
Tell us you've never worked in a faang without telling us.
It doesnt work in faang either, which is why they are wildly slow to produce software. They can just print money when running at 10% efficiency.
It's wild to me that a lot of people consider that SWE need to be knowledgeable in business requirements and interact with clients all day.
Just try to imagine construction workers doing the same thing when building a skyscraper. Instead of laying bricks, mortar and beams, now every worker loses 1-2 hours each day asking each stakeholder separately what they want, if they like how it's going so far etc. And then make changes to the layout when the clients ask! What kind of monstruous building will emerge at the end?
Edit: if you downvote, at least provide a counter argument. Or is etiquette dead?
Construction worker is a spectacularly bad analogy for software engineer.
The architect and structural engineers design the building well in advance. Construction workers are mainly arranging materials according to a prewritten design.
Software engineers are not given specs that are equivalent to blueprints. They are given requirements or user stories. Then they have to flesh out the final real specification in place.
And then from the specification, decide how to implement it, which is not decided at all ahead of time.
Also, what software engineers are building is almost always somewhat novel, at least dramatically more novel than a typical building. It very often involves some type of research task, even if that is just sifting through components and configuring them.
There is much more room in software engineering for 1) miscommunication or poor communication of users needs, 2) substantive tradeoffs discovered based on technical details or 3) subtle contradictions in requirements from different stakeholders discovered during implementations, 4) better understanding of requirements by users discovered during prototyping, etc.
They should have a general idea of what they are building and why, in exactly the same way as a construction worker.
That doesn't mean they spend all day asking stakeholders what they want. It means that when there is a choice and the stakeholder has to make a decision, the developer should be able to understand some of what the stakeholder is looking for so that they can recommend a direction.
Sure, a carpenter is just putting up a wall, but if they're experienced and they see that there's going to be a joist that is going to block some feature, they should be able to point that out to the architect or builder or client.
Absolutely agree, but in practice this means devs are expected to sit in meetings with clients multiple times a week just to make sure everyone is on the same page. This also means that either all the devs on the team are required to be present, wasting time, OR that devs meet with stakeholders individually and knowledge ends up decentralized.
And secondly, I think that devs are expected to know WHY "all frobs are percurators" instead of just knowing that they are. Besides keeping up to date with all the tech stack, you are now expected to keep up with all the business details of your client (client which might change in a year or two).
The other argument about this is whether or not an SWE is a fungible resource.
When you're doing a construction schedule, you might have a pool of carpenters, pool of electricians etc. They can be assigned to the different jobs as a fungible resource, a different carpenter can take over a task just like one power drill can take over another.
We all know that no matter how much ceremony and process, SWEs are not equal, so you can't just move them around randomly.
If upvoting doesn’t require justification neither should downvoting.
But let me try to express why people disagree. Change is software compared to physical systems is comparatively incredibly cheap. Unlike in building something known, design at the start of a software project is unlikely to be the one the client actually wanted nor would be the one that is one going to be build. Or at least it shouldn’t be.
The “brick-laying” part of software isn’t the hard part. Depending on want to analogise as “brick-laying” in software, that part could automated. Push to main and the deployment pipeline runs tests, makes sure things are working and voila! You have a new “house”. If its ugly or falls apart in software, easy , just revert to the previous version and its like nothing happened. Client wants a try different layout, it can be done affordably.
Most of the time in software engineering you don’t know exactly how to do something, there is always a degree of discovery, experimentation and learning involved. Heck the client probably isn’t expressing what they want clearly enough, and probably will at some point change their mind. Thus interacting with clients and customers is valuable.
I appreciate the reply.
> If upvoting doesn’t require justification neither should downvoting.
I disagree, since downvoting is not equal to upvoting. First off, not everyone has the ability downvote (at least on hackernews). Second, upvoting usually means you agree with something, while not agreeing should be reserved to the action of NOT upvoting. This is how most social media works. Downvoting should be reserved for something that should not belong on the thread.
Regarding the topic of the discussion, I agree that "builders" should be proactive and knowledgeable about the system that they are building, but the "chief architect"/project manager should be the intermediary between them and the clients, if for nothing other than being a single source of truth.
> 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.
On older cars, like my '72 Dodge, the system voltage varied between 12 and 18 volts. But the dash instruments needed 5 volts. This was achieved with a clever "buzzer" circuit using an electromagnet and contacts. The circuit would open when it was above 5 volts and close when it was below. This created 5V, but was a noisy 5V.
Many people decided to improve this with a semiconductor voltage regulator, which would nail the output at 5V. But the instruments wouldn't work! The problem turned out to be the instruments relied on the noisy 5V to "unstick" the needles on the instruments.
So the electronics guys had to add a "noise" circuit to the voltage regulator circuit.
P.S. Watch an old aviation movie, where the pilot getting ready to fly would tap the instruments to unstick them.
Ah, the Turbo Button!
I think by the time I got my first IBM PC the button no longer did anything, but it was still there on the case for some reason. I remember pushing it repeatedly, puzzled that nothing went faster.
I have one in my car. It doesn't do anything, either.
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.
If the fan was turning on where it wasn't before, it seems like cooling was once happening through natural dissipation, but after your fix it needed fans to cool faster. So the fix saved time but burnt extra electricity (and the peacefulness of a quiet room.)
This is pretty easy to understand IMO. About 70% of the time I hear machine's fans speed up I silently wish the processing would have just been slower. This is especially true for very short bursts of activity.
Obviously the proper solution is to adjust your system thermal management / power targets, but you can force programs to slow down yourself by changing the scheduling policy:
chrt -i 0 <cmd> > Obviously the proper solution is to adjust your system thermal management / power targets,
My point is that I understand the users' complaint and request for a revert, not that I can't address this for my own machines. The proper solution for non-technical people is to ask the expert to fix it, which may include undoing the change if they were never interested in the process finishing faster anyway.I did solve this problem once upon a time by running the process in a cgroup with limited CPU, though I later rewrote my dwm config and lost the command, without caring enough to maintain the fix.
The proper solution for non-technical people is to ask the expert to fix it
This isn't something the developer has any meaningful control over. Scheduling policy is the responsibility of the host system, running faster usually consumes less power, and the developer has no way to know when an operation will kick in the undesirable fans because it depends on what else the system is running. The best they can do is a checkbox that runs the old code or adding sleep calls insteadYou probably wanted a low thread priority/QoS setting. The OS knows how to run threads such that they don't heat up the CPU. Well, on modern hardware it does anyway.
I’d expect any os worth it’s name to run threads in a way that minimizes total energy not fan noise.
People with desktop computers don't care about total energy, but they do care about fan noise for overnight maintenance tasks.
The OP did say this was circa 2010. So we're talking 15 years ago.
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
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.
> 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".
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.
1. I do that once in a while. There is only so much thinking you can do in a day or a week that you need some mindless activity
2. Today morning, fresh in the new year after a break -- I took a day off on the 2nd, and I last worked on December 19th, I am not able to get into the zone, and luckily a training email popped up -- spent an hour doing that. Normally my manager would have had to remind me.
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.
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. :)
LoL managers.
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.
No. The product manager has to understand the big picture, but when you're working on a team that big, it follows that you're going to be working on a product big enough that no one person is going to be able to keep every single small detail in their mind at once either.
You wouldn't expect the engineering manager to micromanage every single code decision—their job is to delegate effectively so that the right people are working on the right problems, and set up the right feedback loops so that engineers can feel the consequences of their decisions, good or bad. In the same way, you can't expect the product manager to be micromanaging every single aspect of the product experience—their job is to delegate effectively so that the right people are working on the most important problems, but there are going to be a million and one small product decisions that engineers are going to have to have the right tools to be able to make autonomously. Plus, you're never going to arrive at a good engineering design unless you understand the constraints for yourself intuitively—product development requires a collaborative back and forth with engineering, and if you silo product knowledge into a single role, then you lose the ability to push back constructively to make features simpler in places where it would be a win/win for both engineering and product. This is what OP means when they say that "The engineer who truly understands the problem often finds that the elegant solution is simpler than anyone expected".
If it’s impossible to understand users problems then something has gone horribly wrong.
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?
Probably just let them vent until they adjust their habits and just chat with their co-workers, without the need to use this as an excuse. Then, they can enjoy the fast loading times :)
Why would the boss accept that? They automated the work to eliminate employee downtime. If the employees were upset to lose their chatting time then presumably they lack the agency to choose chatting over work duties when they’re unblocked. The only way to help them in that situation is to organize them
Because the 10 minutes of chatting has value too. Which is why corporations make you spend so much time on team building exercises and axe throwing.
No, that's HR justifying its existence.
Plus that's for higher stature service based roles, not warehouse logistics.
It's also mostly bullshit.
Teams work because they have the right combination of skills, both personal and technical, high EQ and IQ, leadership and ownership.
Whether or not you fall backwards into a team's arms or have to participate in childish games is not relevant.
For most people, liking and being friends with the people you work with is a huge factor in how much you like the job and are willing to stay. Most of the times I’ve left a job it’s been triggered by the people I liked talking to leaving and the remaining team members being dull and anti social.
Ignoring the users is the correct solution. Defining company culture through software loading is ridiculous.
What about the second order effects?
Ignoring the customers becomes a habit, which doesn’t lead to success.
But then, caving to each customer demand will make solution overfit.
Somewhere in there one has to exercise judgement.
But how does one make judgment a repeatable process? Feedback is rarely immediate in such tradeoffs, so promotions go to people who are capable of showing some metric going up, even if the metrics is shortsighted. The repeatable outcome of this process is mediocracy. Which, surprisingly enough, works out on average.
Steve Jobs has a bunch of videos on creating products- https://youtu.be/Q3SQYGSFrJY
Some person or small team needs to have a vision of what they are crafting and have the skill to execute on it even if users initially complain, because they always do. And the product that is crafted is either one customers want or don’t. But without a vision you’re just a/b testing your way to someone else replacing you in the market with something visionary.
This requires correct vision + enough influence to execute.
This is not a repetitive process. It’s pretty hard to tell apart a visionary from a lunatic until after they deliver an outsized success.
First define who the real customer is.
Second define what the real problem is.
Third define a solution that solves 80 percent of their problem.
None of this is intuitive or obvious. It may not even be technically feasible or profitable.
Everyone's brain builds a model of the world.
One of those higher levels of maturity that some people never reach is to realize that when your model becomes incorrect, that doesn't necessarily mean the world is broken, or that somebody is out to get you, or perhaps most generally, that it is the world's responsibility to get back in line with your internal model. It isn't.
This is just people complaining about the world not conforming to their internal model. It may sound like they have a reason, but the given reason is clearly a post hoc rationalization for what is basically just that their world model doesn't fit. You can learn to recognize these after a while. People are terrible at explaining to each other or even themselves why they feel the way they feel.
The solution is to be sympathetic, to consider their input for whether or not there is some deeper principle or insight to be found... but also to just wait a month or three to see if the objection just dissolves without a trace because their world models have had time to update and now they would be every bit as upset, if not more so, if you returned to the old slow loading time. Because now, not only would that violate their updated world models, but also it would be a huge waste of their time!
Thoughtful people should learn what a world model violation "feels like" internally so they can short-circuit the automatic rationalization circuits that seem to come stock on the homo sapiens floor model and run such feelings through conscious analysis (System 2, as it is sometimes called, though I really hate this nomenclature) rather than the default handling (System 1).
> But how does one make judgment a repeatable process?
Principles can help scale decision-making.
Their bosses are likely happier for the lower downtime required to run the software anyway.
The solution is to accept that this isn’t a software development problem, and to remove yourself from the situation as painlessly as possible.
If a manager wants to structure a morning break into their employees’ day, they can do that. It doesn’t require a software fix.
Completely insane, who doesn't get to have coffee breaks without manager permission? Surely any org that treats its employees as adults would not have this problem.
Organizing workers
What’s the alternative? Ask the boss for favors? That’s what organizing is for
Hyrum's Law: https://www.hyrumslaw.com/
That is https://xkcd.com/1172/
Please stop abusing co-opting and denigrating the title of engineer.
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/
Likewise, "Abstractions don’t remove complexity. They move it to the day you’re on call." made me think of this 23 year old classic from Joel Spolsky, the Law of Leaky Abstractions: https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...
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.
That's fine ... only have to size your projects accordingly!
That actually sounds brilliant!
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 this is true for essential complexity. And indeed it's one of the best reasons to release early and often, because usage helps clarify which parts of the requirements are truly required.
But plenty of projects add quite a lot of incidental complexity, especially with technology choices. E.g., Resume Driven Development encourages picking impressive or novel tools, when something much simpler would do.
Another big source of unneeded complexity is code for possibilities that never come to fruition, or that are essentially historical. Sometimes that about requirements, but often it's about addressing engineer anxiety.
If - to take a convenient example - I use a library sorting function instead of writing my own sorting code, it's true that I haven't removed the complexity of the work my program is doing: It sorts. But I have arguably reduced the complexity of my code.
Similarly, if I factor out some well-named function instead of repeating the same sequence actions in multiple places - the work to be done is just as complex, and I haven't even removed the complexity from my code, but - I have traded the complexity of N different pieces of code for 1 such piece plus N function calls. Granted, that tradeoff isn't always the right thing to do, but one could still claim that, often, that _does_ reduce the complexity of the code.
You absolutely can remove unnecessary complexity. If your app makes an http request for every result row in a search, you'll simplify by getting them all in one shot.
Learn what's happening a level or two lower, look carefully, and you'll find VAST unnecessary complexity in most modern software.
I'm not talking about unnecessary (nor incidental) complexity. That is a whole other can of worms. I am talking about the complexity required given what you need to a system to spec. If choices are made to introduce unnecessary complexity (eg. "resume driven development" or whatever you want to call the proclivity to chase new tech) - that is a different problem. Sometimes it can be eliminated through practical considerations. Sometimes organization politics and other entrenched forces prevent it.
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.
I don't follow. Following the robustness principle doesn't necessarily introduce novelty. Perhaps a bit more complexity, but just how much depends on how clever you try to be.
What did you mean?
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.
15 years in leadership worked at 3 jobs lead major transformations at retail where nearly 100B of revenue goes through what i built. Ran $55-$100M in a yearly budget… over 300 FTEs and 3x contractors under my or my budget,…largest retailer in google at that time…my work influenced GCP roadmap, Datastax roadmap, … much more all behind the scenes…. besides your capabilities and ability that had to be there to get you in those positions - but once you are in those positions - only that mattered is politics and asskissing. I know so many people smarter than me, always stayed lower b/c they didn’t know how to play politics. Only reason i never got higher was I didn’t know how to play politics and kiss ass any more or any better.
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.
So teach your kids to kiss ass and play poltiics.
Or to stay far away and do something useful with their lives.This is what I really don’t get about these types of folks. Do they really want to remember their life’s work as “kissing ass and playing politics”? I get the “work to live” and all that, but you’re basically tossing away half your life…for what, money? How much money do you need!?
Because that's not how they perceive their works. Instead it is "advocating for one's own team and passion", "helping others advance their career", "networking and building long-term connections".
[dead]
Well you can "work to live" in a nice big house, with a nanny, eating steaks, flying business class to ski in the alps or scuba in the Galapagos... I think it takes a lot of money before you feel like you don't need more money.
Not at all. Most people can be super happy with less than the average tech salary (at a point where they don't feel they need more if it comes at the expense of work life balance, time with family, job satisfaction, etc).
I’ll never understand this WHY X - BECAUSE Y - WELL Y IS TOO MUCH, Z IS MORE THAN ENOUGH comment trifecta. Obviously a lot of people are not super happy, otherwise they wouldn’t kiss asses and play politics to get more money.
You are responding to a "money != happiness" comment with "people kiss asses to get more money because they're unhappy". Just saying.
Just that all of those activities you mention feel like a useless life compared to spending time with your own children in a house big enough for everyone to have their space, but small enough to force you to feel you're living with each other, seeing them grow and thrive, and going around your closest nature patch.
Not much money is needed to have a fulfilling and worth-living life.
Other than the big house, which can easily be achieved in much of the country, nothing in the list above incentivizes me to either work harder or kids ass.
Sure, lots of people don't care about those things and therefore don't shape their careers to get them. But some do, and that's what we're talking about.
Though to be clear I should have said "it can take a lot of money..."
It feels unsavory from the outside, but politics is also the art of getting stuff done. It’s not throwing your life away if you can point at an org chart and a roadmap delivered and say “I helped build that”. Leadership is just as important as implementation.
You need to have the right personality. Either actually enjoy the game, or have an unsatiable (fear-driven?) need for status, or something else of this sort. We don't get to choose our personalities, though some limited modifications are possible - see treatments for personality disorders, for example.
> actually enjoy the game, or have an unsatiable (fear-driven?) need for status, or something else of this sort
Ie. Somewhat serious mental disorders as requisite for leadership.
I wonder how we got onto this darkest timeline?
I question this every single day. Constantly the argument arises that if I played politics and ass-kissed, I might receive more opportunities to create bigger impact to help people / entertain people / provide some valuable service or product. Yet it feels painful to have to self-promote (even if framing it as "documentation of your work").
It is akin to musicianship in a sense. How many of the absolutely, obscenely, most talented musicians have you come across in completely obscured settings? At the pub, the hole-in-the-wall jazz club in a C-tier city, deep on the internet with 13 plays on SoundCloud. But we all know that pop music doesn't necessarily reward technical musicianship.
It's similar in life & career.
Well, I think that it depends on perspective and motivations.
Kissing asses/politics can be treated as skill used for different purposes. Imagine your ambition is to build bridge, skyscraper or fancy opera house.
To be chosen as the one for such projects, you must play many games including politics.
(I assume good intentions, selfish ones are possible too, but are they worth discussing?)
Depends where you want to live, but $5M to $10M would help with enough passive income to future proof one’s family and their kids.
[dead]
For some, that's not only their competency but they enjoy it.
Is building relationships and status less worthwhile than building code or bridges or houses or painting pictures?
People get to choose the game they play.
> …for what, money? How much money do you need!?
"more" seems to be the answer to many.
It isn't the highest paying path in life, but this is what I chose as well. Working for small companies with good people is infinitely better than working at massive companies with decent people. No matter how many good intentions there are, the politicking is utterly exhausting and unfulfilling.
Then again, I'm the kind of person who moved to the countryside to get away from the city life, so YMMV.
I've done both things, and they have their pros and cons. Big businesses can build bigger and more impactful things, and it is very satisfying to contribute to those things. The original poster is still clearly proud of the things they were able to build by "playing politics and kissing ass".
But (for me) there is definitely a certain ennui to being a little cog in a big machine, especially because everybody else there is doing the same thing. So being in smaller more cohesive companies definitely has its advantages.
The grass is always greener and all that!
Why not both?
> 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.
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.
> It is by far the most useful skill to have in workplace.
This might be defacto true in most workplaces, but defending "politics over competence" boils down to "I deserve the rewards from other people's work".
People oppose it because it is morally wrong, not because they think it is an inaccurate description of reality.
You say that as if politics is optional. It isn't, decisions need to be made and politics is the process of making those decisions: who decides, and why.
In academia, for example, there is less politics because the publishing system sort of becomes the decision process. You apply with your ideas in the form of papers, the referees decide if your ideas are good enough (and demonstrated well enough) for the wider audience to even get to see. Then some politics, a popularity contest. But crucially this system famously leads to a LOT of resources being wasted, good research that never goes anywhere because nobody cares about it, or bad research that does nothing but everyone cares (cold fusion).
Politics is just a name for how we decide things. And yes, it sucks, but that's because we suck.
With this understanding of academia, you are perfectly suited to doing software development for them, because if you think there is "less politics" in academia, you are being foolish.
Academia is notorious for politics, especially around tenure and grants, scholarships, etc.
Publication politics are just a small part of that, but even there, working out which name goes in what order of the authorship of the paper is political.
Academia is not more notorious for politics than a corporate job, in my opinion. I've done both. Academia tries its very best to be meritocratic if anything. There is of course some degree of politics, it is inevitable, which was the point I was trying to make.
It’s not politics over competence. It’s getting things done in the real world
Sometimes.
Sometimes it's just bullshit.
Learn the lingo, the language, the proper way of posturing and the correct way to shirk responsibility and that's what matters in certain orgs.
I sound really bitter, but I'm not, I'm actually quite good at the game and I've proven that, I just don't really like the game because it doesn't translate into being able to take pride in what I've done. It's all about serving egos. Your own and others.
Every french multinational I've worked for is entirely built on this.
You're not wrong. You're just missing the thing people are complaining about: The existence of people who succeed in pushing for inferior solutions, and managing to leave before it becomes clear (which can take years in a large company).
My previous company is in a bad position and many such folks are finally being outed. But it takes lots and lots of screwing up before the fat is trimmed.
> The existence of people who succeed in pushing for inferior solutions, and managing to leave before it becomes clear
Guess this is just random evolution at play. Some companies will pay a bigger price than others. And not everyone even recognizes it and pinpoint it like you did.
But overall influencing people is on net good skill for the individual. And what is good for the geese is good for the gander??
> Some companies will pay a bigger price than others.
The problem is that typically a large company has one or a few golden geese. They can milk it for a long time because of an existing moat. The moat keeps shrinking, but it can sometimes take a decade or two for others to catch up.[1] That's plenty of time for such folks to make a career of playing politics well without contributing much.
Lots of people at that company left before things went bad and are poisoning other companies.
[1] Just look at Google and search. Or Microsoft and Windows. Or even Microsoft and Internet Explorer.
I've literally never had the thought of "how do I influence other people." Why is that considered a valuable skill? It just sounds like a nicer version of "manipulation".
If other people are not smart enough to see why your ideas are superior then you need to explain it to them or otherwise convince them to go along somehow.
Most of my "influencing" is just repeatedly explaining things to people and letting them think through all the bad ideas and dead ends themselves.
[dead]
> I've literally never had the thought of "how do I influence other people." Why is that considered a valuable skill?
If you're a software developer you must have thought "current priorities are not right, we should do X for the users / Y to get better quality" and tried to influence your management to get those priorities moved. Maybe by starting a campaign with your users so the demands come from multiple services and not just you, or by measuring quality indicators and showing how what you want to implement would improve them etc.
That's why you want to start getting coffee with people, maybe go outside with the smokers. It can take months of "work" to get people to propose the idea you want done.
But this kind of influencing won't help your career.
[dead]
trying to make a convincing argument about anything is "influencing" people. its manipulation if you are trying to convince someone of something you know benefits you more than the person.
I don't disagree with you, except that a career can stagnate. Maybe you are already working in your ideal role, solving cool problems every day. Maybe moving up the ladder nets you more money but less of what you actually want in life.
Less a comment for yourself and more for the reader by the way. It is important to know what you want and strive for that.
Nah, people say this all the time but organisations where these sorts of gratuitous social games are absent tend to BTFO of organisations where they're present/expected.
Or continue being an ass and kissing asses, and watch the workforce unionize and see how the people YOU disdain shows you who has the real power
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.
> 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.
It does matter though. I also find it off-putting, but in the same way as lots of other stuff that I don't like about the reality of human society. The trick (I think) is to strike a balance between being open-eyed and realistic about unpleasant truths like "career advancement matters" without losing yourself to cynicism and self-interested gamesmanship.
I read this article as striking this balance pretty well. (Though it's certainly reasonable to quibble with it.) The one I struggled with was the one about not doing glue work just out of helpfulness, to conscientiously make it legible work instead of a personality. I hate this! This is totally my personality. I like being helpful and I like doing this kind of work and I really don't want to think or care about how it is reading to upper management.
But I also think he's pretty spot on about this. It's a very rare personality that can remain content in being the glue holding things together somewhere deep in the leaf nodes of a big organization, while seeing everyone around you graduate to bigger and better things because their work was more legible than yours. Very few people manage this without becoming bitter.
So I read Osmani's advice on this more as avoiding a common pitfall of resentment more so than as cynical careerism.
(Another unpleasant truth about "glue work people" like me, is that we aren't actually holding everything together, and the rest of the team can easily pick up the slack once it is documented and legible. This is exactly what Osmani suggests, instead of "helpfully" responding to all the DMs or requests for help about things, document what you would do in response to the common questions, and set up a rotation of people in charge of responding to them. This is a real bummer to me, because again, I really enjoy spending my time being the go-to helpful person on a team, but this is the much better approach for the organization, and ultimately for everyone including me.)
FWIW, from a stoic viewpoint, glue/coordinator roles are getting eviscerated by basic LLMs.
I feel the resentment is stronger if you ignore the game and get lulled into contentment when others are more transactional. It's all about interfaces and continuous contracting. And planning 2+ steps ahead.
Oh I disagree entirely with your first sentence. LLMs continue to be much better at writing lots of code than keeping track of how all the pieces of an organization actually fit together.
I'm pretty sure it's good at both.
>I like being helpful and I like doing this kind of work and I really don't want to think or care about how it is reading to upper management.
Coding aside, I'm afraid this is already falling prey to LLMs plugged into exec calendars and org charts. You're adding yet another non-human, digital layer.
I'm happy to agree to disagree, but I think this seems like a misunderstanding of the kind of work I'm referring to. It's not clear to me how being plugged into exec calendars and org charts would help, so I think we're probably talking about different things.
But that the with is misunderstood and invisible to lots of people is the whole point of the thread! So it's an understandable misunderstanding :)
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.
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.
>b/c they didn’t know how to play politics
Or they refuse to play that bs game
True. I used to count myself in that category. Do the work and stay away from games. I was also thinking of myself as clever, self-respecting by doing hard work and leaving daily politicking for others. And now sometime back I got like 2-3 dressing downs from managers, reason being I am not taking leadership feedback seriously enough and mending my ways. This despite I am only one with left with knowledge of legacy system. Clearly I am pretty dispensable while thinking otherwise all along.
No outside prospects considering market situation, miserable current workplace ultimately due to my choices. So in end just no winning for me by not playing game.
Politics and leadership is a responsibility. By avoiding it, you're setting a bad example. Once you know how an organization works, you should help lead it.
If we consider a family, you're essentially saying you'll only "do the work": brush teeth, feed kids, clean up, but not take on any responsibilities for the actual goals of the family. Not pushing to have your kids learn things, just executing somebody else's ideas, driving them to sports; not improving the living situation by perhaps investigating if you should get a bigger car. Nothing leading, only executing the ideas of your spouse.
I exaggerate of course, but there is something there.
> And now sometime back I got like 2-3 dressing downs from managers, reason being I am not taking leadership feedback seriously enough and mending my ways.
It's important that you have relationships with your boss's boss. Some organizations call these skip-level 1-1s, other times it's just riding with your boss's boss in the car. This also is not politicking or CYA.
The reason is that managers are fallible, and when you have a relationship with your boss's boss, it helps get things back on track when someone (you, your boss, or your boss's boss) makes a mistake.
Getting back to the point: If you get a dressing down from your manager, your relationship with your boss's boss helps you know if you deserve it, or your manager made a mistake and your boss's boss has to intervene.
---
Quite tangible: A few weeks ago my manager gave me a dressing down. Earlier in the day I had a conversation with the CEO where he told me I was 100% in the right, so my manager was basically putting his foot in his mouth the entire time they gave me the dressing down. It's interesting to see where the situation is going to go, because everyone (me, the CEO, and everyone else in the company) really respects my manager and wants to continue working with them in a non-managerial role.
In your situation, it's end of year review time. He might be softening you up.
Why not mention to your manager that CEO supported you? Are they working with different data? I get these may not be fun to press on right before the holidays.
Don't make assumptions. My employer does not do end-of-year reviews.
To make a long story short, my manager got angry because I wrote a quick and dirty tool that bypassed a lot of confusing abstraction layers, and is significantly easier to use than the tool the company currently uses.
When my manager got angry, I first told my manager that we shouldn't argue in front of the entire office. Then I went to the CEO for advice. The CEO gave me advice that I used on my 1-1 with my manager later that day. (The CEO was also quite happy that I made a quick-and-dirty tool that made peoples' lives easier.)
> Why not mention to your manager that CEO supported you?
I suggested that my manager discuss the issue with the CEO when they told me that he didn't think he could "sell my tool" to the CEO.
To make a long story short, this is a case where my manager started the company, and people / project management is not their strong part. The limiting factor is funding, otherwise we'd have hired a proper project manager and promoted my manager (the founder) to a thought leadership role.
>I suggested that my manager discuss the issue with the CEO
Point blank:
Why not tell your manager you already spoke with the CEO instead of
1. Not mentioning you already overstepped your manager
2. And the skip-level boss/CEO liked the idea.
This seems like potentially good intentions being easily perceived by your manager as passive-aggressive. Maybe your skip level told you to use that phrasing.
Regardless, good luck.
I think you're misinterpreting the situation, because I didn't "overstep" my manager, and in a small company everyone has a relationship with everyone. (IE, what I did was taking initiative and making good use of dead time.)
I'm not comfortable discussing this further in a public forum at this point, but you're welcome to look at my profile to contact me directly if you want to.
If you're still looking at this thread, this article explains what's going on: https://www.startups.com/articles/how-founders-get-fired-by-...
The article takes a harsh tone on the situation, which really isn't true. (I wish the author avoided the word "failed" because the situation is really about recognizing success and playing to strengths.)
Sure, you have a lot more tactical context.
I agree that diagnosing and treating Founder's Syndrome is a natural, healthy outcome.
"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.