• Digs ditches. Nobody is too good for any task. • Returns shopping carts (even if nobody's watching). We leave things better than we found them.
It's amazing how most teams don't set norms/values at all!
Unions have this in spades. "My job is X, I don't do Y, in fact I'm not allowed to do Y as that takes a job away from whoever is supposed to do Y"
But yeah, most people just bring their trash home.
For those interested, Visas are really easy to obtain as long as someone is willing to hire you.
You want selfless devotion to the goal then you damn well better not be wasting my time and cutting costs at the expense of my productivity.
Managers who don't know what they're talking about and insist they do and insist they are right causing massive lost time, then want to hold meeting after meeting about how it is everyone else's fault. You've seen it. Why am I working long hours doing work, some of which is shovelling sand that need shovelling because I'm not too good for it when if that idiot had been restrained to their level of competence we'd already have delivered and I'd see more of my family. Selfless devotion? To what?
In the old days when SSDs were 'expensive' and companies economised and didn't immediately buy them for the team because my time isn't worth saving but they want me to stay back to get more done for a deadline? Selfless devotion to a goal you're showing clearly you don't care about.
This stuff is really normal. You have stories, everyone does. And so we take the path that is best for ourselves and those we like. Any other choice isn't "egoless" it's insane.
Managing a team is hard. Keeping idiots from having idiotic influence is hard. Spotting who is managing up is hard. Noticing, supporting and retaining who is good is hard.
Having someone with a massive ego who you might cross the road to avoid having to socially interact with other than they do a decent job of that hard managing might work out better than "Egoless."
So an approach might be to set only the values you can actually follow through on, and be clear when a value is aspirational. If you really do dig ditches (perhaps metaphorically, maybe by fixing deployment script bugs or something), then you can use it as a value.
To be clear: I'm definitely in favor of team values. Is there a way to make them achievable, but also grow them over time as you get better at them?
* Don't add process just for the sake of it. Only add it if seriously needed.
* Require ownership all the way to prod and beyond, no matter the role. (Turns out people tend to really like that.)
* Stop making reactive decisions. If something bad happened on a total, extremely unlikely lark, don't act like it's going to happen again next week.
* Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)
* Never forget your team is full of actual humans.
The PM wants his share of the cake, so any big feature needs to go through his approval (“does this feature delivers value?”, “how many users will use the feature?”, etc.)
The staff engineer needs to validate any design (that’s his job), and provide feedback if he thinks your design “sucks”. So if the feature ends up being successful, he gets points.
The senior and lead engineers need to own the design and implementation details. The leads would probably want to cover a good chunk of the solution so that it appears in their performance review. It’s gonna be though for senior engineers to get a good share if the leads are already one step ahead.
The engineering manager will own the timeline. He will ask you about estimates, but most likely you’ll feel the pressure of whatever imaginary deadline is set.
So there you are in the middle of all those people wanting their share. If you don’t manage to own a good chunk of that work, you won’t be able to show it in your perf. review. Owning is hard.
I have to say, though, that I only have experienced this in tech companies that are around 5-7 years (old enough to have well established processes, young enough to still hire like there’s no tomorrow) and that are obsessed with FAANGs: they will hire faang engineers only if they could. This mix ends up badly, because suddenly every team needs to be a high performing team, everyone is raising the bar and speed is number one prio. When working with companies that hire no faang engineers, everything feels better.
every day I wonder how come I do so few now that I'm paid compared to when I was jobless and hacking prototypes for $0
finding the recipe for creating goal driven, high speed, high quality, frictionless teams is a difficult quest
You know the ones. They founded the trillion-dollar companies you hear about and became billionaires themselves
I also bet they did come up with some small things here and there themselves, in the process of implementing stolen ideas, because often things become apparent at the moment of implementation.
I often wonder how some open source projects manage to be so successful/productive with so little of what looks like corporate management.
Salary is inversely proportional to how much you actually (need to) do.
Why do you feel your way of shipping things to users to improve the product is something that makes your team members unhappy and not able to add value?
I decided to, in the middle of the sprint when I was done with the sprint work and had some small downtime, take care of some of the smaller bugs that were easy to fixup in a day's notice. My PM at the time immediately questioned why I'm working on "irrelevant" tickets and not focusing on the wider project we were working on, the senior I was working under had the same stance, and the PR never ended up being merged. It was like 20 lines of very easy to comprehend code that was fixing one of the most reported bugs our users had, like 6 figure number of reports since the bug card was created.
When I left that company a year and a half later, that bug card was still open, with my now-rotting PR sitting there with a "closed" status.
It really jaded me on all of these bullshit processes, sprints, AGILE, whatever you want to call it. It was obvious that nobody gave a shit about what we were building and how, it's all just a game to pad yourself up and to look good to the higher ups who control if you get a raise or not. If someone above you can't somehow gain a lot by boasting about the work done, then you might as well not do it. I fucking despise the mindset and how prevalent it is in the industry.
Teams must advocate for projects, but, for individuals, one solution that I've seen help is that the week long oncall developer handles sprint interruptions, slack questions, and bugs. No sprint commitments. If something is not on fire, they get to work on whatever they think will add value at their discretion. New tooling, proof of concepts, pet-peeve bugs that can't get prioritized, etc.
After lots of stabilization work, devs looked forward to oncall.
As an Engineering leader, I try my hardest to make sure this Slack exists for the exact reasons you listed.
"Our customers prefer the product works over getting a new feature, so let's ensure that at any cost"
Number of features is a dial. You turn that down. You turn the operations (devops) dial up.
There is nothing modern about releasing half arsed shit... we been doing it since the dawn of civilization.
Do they, though? If a competitor launches a feature that all your customers want and start to switch to benefit from it, what are you going to do? Show burn-down charts of your bug backlog?
I would say this is not that common in SaaS. In that features are important but PMF is key. A feature that drags people over is really a new product. I can't think of an example of the bolt-on killer feature. And by the time you are big enough to run multiple distinct products youd better have good uptime. If you are a startup of course you need features but again finding PMF so you ain't worried about competitors. As a startup you are choosing boring tech and maybe a PaaS to help you do less productioning.
Notice the popularity of k8s, splunk, CI/CD, testing, multi region and so on? Yeah there is big money in being available.
But isn't that a post-facto observation? I mean, any project can work on a complex feature that's a flop, but sometimes a simple feature can go a long way and just tilt the scale. That's not a new product.
Not really. This is the fact of real world software development: your resources are limited, and either you invest them creating value for customers so that they choose your product over your competitor's or they choose your competitor's instead.
If you spend your resources on technical debt and clearing bug backlogs even of obscure nonblocking bugs, you're just spending your resources to offer your users more of the same. If you instead use your resources to deliver new features that might have a nonblocking bug here or there, you're improving your position over the competitor's.
Time to market matters. A lot. There is no such thing as time to empty backlog.
In the short term. Features can attract new customers but software that is frustrating to use due to a lot of low level bugs will repel existing customers towards competitors over the long term. If you've simultaneously decided tech debt isn't worth addressing then your competitor can easily overtake you. Furthermore adding feature after feature eventually leads to a kitchen sink product where potential customers are put off by the learning curve. This is really just a variation on the quantitative fallacy that ignores qualitative aspects.
Because that doesn't work soon you keep adding layers upon layers to reduce the risk and your time to delivery suffers.
All knobs have consequences and long term they can really compound. The balance of picking quality over features isn't something I've seen done amazing. I'd like to work somewhere that could pull it off.
1. Think
2. Know what is going on.
3. Effectively get the best from their people.
You want the whole org to engineer the right solution
Any metric that gets abused needs to be found and replaced. Companies should use metrics and be very respectful, curious and also suspicious of them. Even revenue!
I know companies that leave revenue on the table for strategy.
Finally quality is about probabilities. That test you wrote that takes 12s to run and flakes 0.1% adding 10 hours of build time a year ... what is the probability of it detecting a bug and what would the cost of that bug be. You need every engineer to think of that stuff. It is hard stuff to get right or even good.
I worked at places where a religion almost builds. People are hired to maintain those slow expensive unreliable tests! You want to improve that you now have politics!
That's literally the Product Manager's job. That's why your employer felt the need to pay a hefty salary to have that role played by a single person whose man responsibility is being held accountable for features being delivered.
I mean, do you expect on releasing features in a product without the Product Manager's say?
That makes as much sense as the PM expecting to single-handedly pushing software architecture changes without consulting with staff and senior engineers.
> So there you are in the middle of all those people wanting their share. If you don’t manage to own a good chunk of that work, you won’t be able to show it in your perf. review. Owning is hard.
Isn't this concern shared by everyone in your example?
This kind of argumentation somehow never settles with me and blocks me from reading on. 'modern', 'new', 'trendy', 'state of the art', 'industry practice' and alike all resonate with 'I do not know so I mimic how others do' in my mind. Weird, but do.
Are 'modern' team structures a desirable reference?
How about saying 'today's problematic team formations'? I'll try to understand so and read on.
---
Edit: it turns out we are on the same page, I jumped at ghost.
I hate this, like when there's an outage and the outcome is 100 half baked ideas that must be implemented, that just make things worse to work with
an economy of giving in a way
I've worked at a few startups and have seen high-trust environments lead to a lot of productivity, comfort and success— and the opposite for low-trust startups. In general, I think startups tend to lean towards high-trust, especially when they're small and early, but I was part of a 15-person one that was quite the opposite, and it was terrible.
The hiring process wasn't great. Long take-home task, and that was the only technical interview. A lot of talking, but not much noteworthy signal on the rest. Very long wait times. Now I know this is a red flag for low-trust companies. If they're not building trust at the hiring-stage, it means even after joining the organization it'll take time to acutally "be part of the team".
Once at the company, I had no permission to poke around— everything was hidden by default. There was no space for discussion, I was expected to learn, not to comment. There was plenty of micro-management; after all, if they don't trust you, they need to keep an eye on you at all times. You're probably doing something wrong.
The chasms were deep too; the company was building a web team to spin a contractor's project into a full web product, and I was supposed to lead it. We were disjointed from the rest of the company though, and would only hear about requirements through the founders. The team had interest on being more involved with the main product, but management just wasn't interested in making it happen, and just had us loiter around for a few months until they gathered requirements, and then implement some rather disjoint features.
The project failed. I'm working somewhere else now.
tldr; low-trust environments kill projects
On that note, a quick shot-out because I've been lucky enough to see the opposite happen at a big company too. Performance cycles at the company very much disincentivized big bets. Some engineers really thought project "X" was important, but it was risky— if it didn't pay off by the end of the cycle, per the way the bureaucracy worked, it wouldn't be great.
The manager very much tried his best to protect them against this. In fact I don't think it paid that cycle, but the project remained active until it did eventually pay off. Shoutout to managers like this. The easy route is to act like a messenger for higher-ups, and never put your own skin in the game— but there's some out there that want to do what's best, not what's easy.
Neither one causes the other, both occur as companies mature. I’ve seen this as startups mature. One very vivid recollection: we had a very strong and tiny dev team. Each dev owned a huge piece of the product. Definitely not egoless. We brought in trusted junior devs to grow. That was fine.
Then the very talented VP Eng. wanted a promotion and brought in a hack to replace him, who hadn’t coded in years, and was obviously more concerned with his career than our product. A real mediocrity. But the VP wanted to move on, so this mediocrity was hired, over vigorous objections.
That was the end. This new VP brought in mediocre devs, rewarding loyalty and “being a team player” more than productivity, or competence. He brought in employees who couldn’t be trusted.
As this was happening, we were acquired, and our new bosses from the parent company were used to employees who couldn’t be trusted, and acted that way.
HR knew that to keep the good engineers they had to do something, so they showered us with bonuses. That worked for a while. I finally got so bored and fed up that I left (for another startup).
$employer has formal separation of duties between development and build/release for some things, which deal with other people's money. I'm pretty sure it's mandated by customer contracts.
I recall exactly when this happened at Facebook.
Depends on what you mean.
Individual ownership over code/feature/module/etc would seem to run counter to the article - it's just another fiefdom.
Collective ownership? Sure.
With that ownership comes there responsibility and accountability of making sure it happens. The level of responsibility and autonomy that comes with that is what I’ve found people react positively to
I don't think this item was well thought through. Taking proactive decisions means allocating work for tasks that do not solve a concrete problem but bear the risk of introducing regressions. On the absolute best scenario, things continue to work as always. On the absolute worst scenario, you introduce a critical regression that brings down the service. There is literally no upside and all downsides.
There are many reasons why "if it ain't broke don't fix it" is tried and true.
> * Resist the urge to build walls between people/teams/departments. Instead, build a culture of collaboration (Hard and squishy and difficult to scale? Yup. Worth it? Absolutely.)
That really depends on what you mean by "walls". The reason Conway's law is a thing is that in order to have functioning teams you also need functional independence. If you need to book a meeting with anyone to justify pushing a change to a service you do not own, that's already a wall. No matter how easy it is to get through that wall, it's still easier to not have to go through it.
I can tell you an example of how independence always beats collaboration. Once I worked on a project where QAs were a separate team entirely, and made it their point to be the sole owners and maintainers of all automated test suites beyond unit and integration tests. We experienced a major regression that the regression test suite wasn't caught. I went right to the head of QAs and asked if I could push a commit to add a couple of regression tests. He politely declined by saying that they were already working on it and I wouldn't need to bother with that. Great, a victory for not building walls I guess? Except that his "we are working on it" ended up being "we added a ticket to our backlog and we might pick it up two months from now". Literally. And they never did, by the way, and the same regression was eventually introduced without anyone noticing.
In case you wonder how I solved that problem, I created my own regression test suite. Conway's law always wins.
The specific example is of a rare event which, while regrettable, does not justify the cost of policy changes to prevent it.
You don't get the luxury of not making decisions. You always have to make decisions.
The actual point stands, either way: Whether you do not make a decision, or you decide not to act, the outcome is the same--and it is often a better outcome than the result of reactive or proactive decision-making.
I feel like everybody needs to internalize this one (and that notably includes governments and politicians), but it's a really hard problem to solve.
If something bad happened, people (whether that be higher-ups, journalists, lawyers or your constituents) expect you to do something about it. "yeah, a child just got raped on our property but we don't have to do anything about it, it probably won't happen again" is not an acceptable answer in most circumstances, even if it's the right answer.
That being said, I believe failures and mistakes are simply part of our lives. I would turn the other way and run when someone says that he found the perfect system, in which there are no losses failures and problems. You are always limited by what you don't know you don't know.
Ideally this sounds great, practically it rarely happens in modern organizations.
Companies, and corporations especially, do not like the idea of engineers having personal ownership over things, as that makes them harder to replace, i.e. reduces the redundancy of the organization.
Is ownership incompatible with redundancy though? The way I understand it ownership is more so about keeping the app in the specific teams hands to avoid having secretaries running from team to team trying to keep teams from unintentionally sabotaging each other and handling suggestions in a constructive way so everyone is involved in the architecture and general direction of the product and they don't feel like code monkeys. You can still have 20 people on a single project each owning it to an extent. You probably even get more redundancy that way since people are incentivized to look at the bigger picture if they can impact it.
PS: Stupid question but is there an actual definition for ownership? I think I might be talking out of my ass here.
I wonder why these almost never considered.
Do you often have to deal with support staff reaching out directly to developers on Slack to investigate some problem – without going through "normal" process of creating a ticket that gets assigned? Or even asking for features.
Developers generally want to be helpful, but also small requests often turn out to be rabbit holes. And even in best case it distracts from work that was explicitly assigned and scheduled.
I noticed I experience a bit of anxiety every time I'm doing some work that came through backchannels. The way I try to alleviate is create the ticket myself, mention its source and assign it to myself. This way switching context is visible and I can tell myself that "if manager doesn't want me to spend time debugging this now, they can react".
Our approach was unique. We engaged directly with the people who did the work, learning from their insights and challenges, and built tools specifically for them. It wasn’t an Agile team or a Waterfall approach, or any other rigid corporate framework. It was an ad hoc team that came together organically to solve problems—and solved them faster than large corporations, consultants, or armies of workers ever could.
With just four people, we scaled applications, built automation systems, and tackled complex problems that delivered multi-million-dollar savings across the board. The process was simple: no micromanagement, no unnecessary oversight. Everyone contributed based on what made sense, and we all collaborated freely to solve problems as they arose, moving seamlessly from one challenge to the next. It was innovation through cohesion—a kind of synergy that can’t be forced or replicated through standard processes. It’s the magic of the right people, in the right place, at the right time.
Over the years, the tools we developed have grown into critical applications used by professional organizations, with over 3,000 users relying on them daily to make their work hundreds of percent faster. Yet, when these tools are handed over to large organizations for "modernization" or "corporatization," they often end up spending exorbitant amounts of money, adding no meaningful features, and making the tools less effective. Teams of 30 people fail to replicate what our small team accomplished. It’s a strange and frustrating reality.
I’ve tried to find ways to replicate this success, but I think it comes down to that intangible element—a “ragtag team” dynamic where the right people come together with a shared drive and passion. It’s rare, and perhaps it doesn’t exist as it once did. Maybe it’s out there, but we need to find ways to enable and foster it.
I've seen multiple people fired on completely different teams for trying to walk over people in environments like this. It's amazing what those firings do to everyone else's morale. It skyrockets.
The message becomes clear "balance compassion for self and others and lets ship the thing, or you can leave."
If that messaging threatens someone, they've got work to do.
> Computer Scientists are also really bad at it
> Despite literally studying the asymptotic limits of work completion under various conditions
There are so many times that I'm looking at the workflow thinking "We know how to break this up using distributed systems knowledge, why are we doing it this crazed way"
Embracing compassion for all those who drift into our orbit is the only way to improve oneself in all dimensions. Compassion is the common factor in virtue, and the cure for selfishness.
It is also the measure of every person, so once you begin orienting yourself in the moral compass' proper direction, you can begin to see how others are aligned or misaligned. Such selfish folks are those who just don't give a damn to become a better person, which would result in lessening the amount of hurt they inflict on others. Treat such people as well as you can, but be wary of their nature.
Unfortunately, very few human beings really give a damn about anyone not in their in-group. Such is our baseline mammalian heritage, which we must each overcome with deliberate spiritual self-evolution.
"The Way goes in." --Rumi
Personally I don't see it through such an individualist lens— I think this is a collective issue that can't possibly rely on an individual's "spiritual awakening".
As such, I think the bigger issue is that (in some cultures more and some less) people are actively encouraged to compete and feed their ego. At a societal level, for example, it'd be easy to blame schools or parents for this kind of education, but I think they're just doing what makes sense in their economic environment. If the world is winner-takes-all, I can't blame parents for wanting their kids to be "winners", lest they are left with nothing instead.
Going back to the post and the way this played out at the company— it was upper-management with the wide impact their decision-making has on organization as a whole, its rules and procedures, that led the change. It wasn't individuals each individually overcoming their own egos that led the change here. Once the precedent is set up-top, and the policies are changed, the rest could follow. It was top down and systematic.
If a person wants more power so they can enjoy such "fruits" (more money, control over other people, more pleasures, ...), then they will support people who exemplify those negative characteristics. Believe me when I say that despots don't gain power without significant support from other low-virue folks. That is really the story of human history.
But, no, it is each person's personal responsibility to seek and attain some measure of spiritual growth, with humility, honesty, perseverance, and study. Just like a CEO with bad personality traits will cause negative downstream effects, any individual with those traits will poison the teams they work on or whose work they affect.
As to competition among humans, that is just our common delusion, whereby we are fearfully convinced that we are merely mammals competing for scarce resources, instead of human beings who are capable of cooperation, generosity, compassion, and selfless service for the benefit of the whole, including future generations.
What we are witnessing across the Earth's societies is nothing less than the apotheosis of the masses' majorities exercising their free will to choose ignorance over wisdom in how we treat each other and what we will allow our organizations (such as corps and govts) to produce. A human life committed to selfish competition against other groups is a life wasted on mammalian idiocy, and always results in degradation of the whole.
Why are we not all humanitarians? Because most people reject our highest possible ideals, attitudes, and behaviors. Their reasons are numerous, but none hold any weight, for none will bring them peace and happiness, because only by making other people happy can we be happy. And we can only make other people happy by giving of our selves selflessly and compassionately.
There is a mismatch between your observations about humans as a whole, and the appeal to individuals and their individual values.
I am all for individual ethics, but half the people on the planet could have great ethics, and things could still devolve.
The way to scalable net-positive gains starts with oneself, but also requires finding ways to pull others into net-positive arrangements, in a way that generates value back to you. Then repeat on larger scales.
If a fraction of the planet worked hard from that standpoint, things would improve markedly. Even a lot of failures and a few successes would make a lot of positive difference.
Applying game theory, psychology and local conditions toward scaling up positive sum games, is another form of engineering.
Perhaps the highest form.
For those who invite, we are to do so with loving kindness, because the result is wholly dependent upon the receiver opening and then walking through the door we present. There is no compulsion in religion, and we must understand and remember that it is everyone's choice, and we cannot be negative about their declination. No badgering, no negativity whatsoever, period. We are to keep being kind with the hope that they will catch on eventually, as the events of their lives surface the negativity that they, themselves, have sown into the world via their willful ignorance. Perhaps they will reach a point where they've had enough of ignorance and are willing to give the Path of Love a try.
And this is no game, though systems theory is the proper model of our situation, where there in an intrinsic gravity we each face to the idea of overcoming our intrinsic negative traits (the vices of the heart/mind). Now, construct the model with cooperating verses competing individuals in the population, positive contributors verses negative contributors. Of course, you already correctly intuit the fact that the more of us that viewed our aggregate impact upon the Earth (and each other) this way (that we can actually change things by being a part of the positive force), things could improve quite rapidly. The fact is that we are moving in such a diametrically opposite direction to cooperative compassion that we are literally destroying the Earth for our future generations.
And it is our choice, each of us, individually, but with billions of us aggregating into a miserable mass of selfish f_cks who are causing unnecessary strife, unhappiness, and destruction via our willful ignorance of what is possible for us both individually and collectively.
You are right, I stand corrected - I think both approaches make sense for spreading change.
Yours on an every day basis, the viewpoint I gave requires opportunity, but matters too.
The thing with game theory, is it’s the right way to think of social structures that scale.
I think a lot of people’s behavior responds strongly to their incentives. All those people you (and I) are cynical about.
And ethics really are the positive sum “games”. Keeping one’s word, safety nets, helping our neighbors, win-win transactions and relationships - we adopt them as individuals for the immediate good it does, for us and who we interact with. And knowing if everyone did that we would all be better off. Even the self-isolating rich since society as a whole would run better.
Bottom up or top down encouragement are both with it.
Yes, changing incentives is the easiest way to provide a proper carrot to help people choose a better way.
And let's not forget that disincentivizing our leaders from being corrupt bastards is the proper use of the stick as well.
This is false. A well-designed system will align individual self-interest with what's beneficial collectively.
> Embracing compassion for all those who drift into our orbit is the only way to improve oneself in all dimensions.
What does compassion look like towards someone who's trying to mug me?
> It is also the measure of every person, so once you begin orienting yourself in the moral compass' proper direction, you can begin to see how others are aligned or misaligned.
I do not subscribe to your religion.
Feeling positively towards others, and acting beneficially to others, are not the same thing.
A well-evolved human being will fit into the team in the optimal way, so long as the team is constructed by a well-evolved human being, who will do what you suggest without interference from their ego.
> What does compassion look like towards someone who's trying to mug me?
To beat the everliving sh_t out of them to keep them from earning more negative karma in the future, while earning positive karma from helping protect other innocents. Remember, letting the oppressors run rampant is not helping anyone, so you can earn good karma by selflessly preventing. And God does not want innocents harmed, so protecting yourself (and other innocents) is God's Will.
> Feeling positively towards others, and acting beneficially to others, are not the same thing.
You're right, the feeling of love is of little importance if one does nothing to benefit them. The key is action, not warm fuzzies.
> I do not subscribe to your religion.
That's your right, just as it is mine to love you anyway and try to educate you out of your ignorance. If you don't want me to, then I'll not bother you, but this is a public forum, so we can post so long as we remain within the guidelines.
That said, I'm not advertising for any specific religion, but to the core of all of God's religions, because they each have compassion at their core, or they have gone horribly astray. You must find your own path within the umbrella of God's Loving self-evolution. Seek and ye shall find what is perfect for you.
When you tire of your unhappiness, you can pray that God help you out of your ignorance and guide you to a suitable teacher. You don't have to do anything like that in your life, just like you don't have to wear clothes at the mall or drive on the correct side of the road. I do suggest, however, that you do what's best for both you and others, for you and those around you will be happier that way.
This is how human life works: you don't have to follow the guidelines, but there's hell to pay if you're an ahole about it. Imagine a world where compassion for all those around us was the norm, instead of this idiotic, wasteful, strifeful competition that is spoiling the Earth and causing so much misery.
Are you saying you wouldn't want to work with anyone that agrees with the points in the article? If so, it would be interesting to hear your thoughts.
Reminds me of Tolstoy's “Happy families are all alike; every unhappy family is unhappy in its own way.”
I remember back in the late 90's and early 2000's it was similarly cool to bash anything related to Microsoft.
I spent a good bit of time writing a lengthy comment on slashdot about "Why to code". It was fairly poignant and well-received, except at the end of it I took a low effort pot-shot at Microsoft - because it was cool to do at the time.
Someone replied and (rightly) called me out on it. Why muddle an otherwise interesting talk / piece with a cheap, drive-by swipe?
That was nearly twenty years ago, but let's call this comment me paying it back (if the author reads HN).
"Redacted" is a very polite way of describing what the author did.
Still 1 bad paragraph (or picture in this case) does not nullify 99 good ones.
It is good to evaluate people on their actions rather than what they claim to be. We saw a good example of this in the Elm community[^1].
---
[^1]:
From https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/
> The leadership style in Elm is extremely aggressive and authoritarian.
> By that I do not mean impolite or rude. It is almost always very civil. But still ultimately aggressive and controlling.
...
> The team [at NoRedInk] shows a bewildering mix of cargo-cult inclusiveness coupled with inability to consider that anyone could be different from them in any way that matters.
From https://news.ycombinator.com/item?id=34746161
>> the core team has that "happy cult" vibe where they think that if they're (passive-aggressively) polite enough, they don't have to worry about anyone's opinion outside their insular little group.
> "Happy cult" vibe is exactly how describe that faux-niceness they throw around.
I prefer recording over slides.
Every. Damned. Time.
There were some annoying parts of the ultra-permissive culture. Sometimes you'd need to literally beg people to stop YOLO-committing code into your UI component because they're not checking how it looks with your flag enabled and they're breaking your A/B test over and over and you just lost a week because you need to restart it. But we gained more than we ever lost.
The productivity of every single team that I've been apart of, that shipped fast, was enabled through permission, by highly experienced domain experts who knew how to build guardrails instead of controls. Canary releases, monitoring and rollbacks, not release managers. Automated testing, not codeowners.
Controls prohibit actors from doing certain things. Outside of regulated environments, they should only exist at the perimeter of your business, interfering in the nefarious activities of malicious external actors.
Guardrails on the other hand, guide actors in the right direction. Well installed guardrails can see your legal team pushing changes to your API schemas.
Those guardrails however take real expertise to install.
Pizza teams that own the whole stack, and for the roles that don't need a full-time individual, specialists that come in and advise but also make it possible to DIY the things they do.
The best examples of specialists are Designers and Security teams as this talk highlights. They can make the tools and the means for other teams to self-service those needs. For example, security teams implementing CI tools and designers building design frameworks that are easy to apply. Conversely, they can feel free to make changes themselves and are empowered to at the best organizations.
Everyone else in product development is a generalist, including the managers, and everyone is on-call. When everyone is on-call then it results in far fewer alerts going off because when there is an issue, it's taken very seriously and remediated quickly in the following days & weeks.
I think GTM teams could also benefit from this same kind of process, but instead melding Marketing, Sales and Support roles and responsibilities.
My theory on why this wasn't more common in the past was that the work was too complex and specialized and that the tools and knowledge to do the job weren't as easy to acquire as it is today. LLMs have certainly leveled the playing field immensely in this area and I'm truly excited to see the future of work myself.
Steve Jobs seems to have poisoned the brains of whole huge swathes of people into thinking that "being an asshole to others" == "success," because it shows you're powerful enough to not have to deal with the consequences or something.
Revenue and user ship are steadily decreasing according to most estimates. Glitches and outages started happening immediately. Third party apps have been exiled. Hate speech and misinformation has surged.
From the outside it seems like the ship is gradually, painfully sinking.
On a technical level at least, there's times when it makes my phone warm up. There's random layout bugs, and things not rendering properly. At some point ads started opening on press-down, as opposed to a proper tap interaction (press-down, don't move, press-up). Now I accidentally open ads all the time.
Moreover, it's slower. Media and search specifically take longer to load. I work on web performance, so I very much noticed that suddenly one day things started loading more slowly for me. I thought it might be some temporary issue with their CDN or bad change messing up the way they schedule network calls, but it just stayed that way.
Perhaps you mean Twitter the company, in which case I don't know, maybe it's making more profit now and in that sense "works better"— but Twitter the app in my experience definitely doesn't.
How can you possibly care? Do you really not feel like you have won yet? What is even at stake!?
I just dont even understand the discourse anymore. Can't yall all be like "oh he is simply genius, of course all these normies won't get it. we dont need their validation anyway!" And then maybe we can stop doing this? Please?
Saying that Musk's personality resembles NPD doesn't say whether he is or is not effective at some tasks.
a) According to Fidelity it is worth 80% less than when he purchased it.
b) Threads and Bluesky are growing at 1m users a day. Former at ~300m MAU.
c) EU is going to be throwing the book at X over a failure to manage trust/safety.
By any definition X is not doing well.
He was in platform engineering, ensuring the server fleet was it top-shape etc. It wasn't over him to debug OS-level bugs. Very smart guy; if something was broken and nobody else could fix it, you went to him. He'd previously tracked product bugs down to the JVM garbage collector, or RHEL. He told me about the time he tracked a bug in a binary down to the OCaml compiler— if you read the x86 spec, it turns out OCaml wasn't using one of the registers properly and the binaries, under very specific circumstances, were technically buggy.
And on Fridays he hosted an informal get-together, open to anyone in the company, where anyone could go and chat about tech. Show something off, ask about a bug, bring up something cool found on HN— everyone was encouraged to pitch in (although often we wanted to hear him do the talking lol).
People like that are amazing, and I suspect he was that smart precisely cause he knew there was always more to learn; from the machines, and from other people.
First, by not writing rambling, pretentious, navel-gazing, ignorant powerpoints. This would be amazing if it were satire.
If that is not navel-gazing or humble bragging, what is?
It is a pretty common thing for people giving a talk to introduce themselves to give an idea of the experience on which the information that follows is built, normally at much more length.
I don't think it is uncommon for people on HN to have led small teams or biggish orgs :)
"There once was the first software engineering best-selling book. It was called The Psychology of Computer Programming (Weinberg 1971). There was a peculiar idea contained among the many excellent ideas of that book. It was the idea that the task of programming should be egoless. Programmers, the author said, should not invest their ego in the product they were building.
...
What’s the alternative to an ego-invested programmer? A team-player programmer.
The team player sees the software product as a team effort and a team achievement. Error reports and reviews and questions become team inputs to help improve the product, not threatening attacks to derail progress.
...
But after further thought, this notion begins to unravel. It is all well and good to advocate egoless programming, but the fact of the matter is that human ego is a very natural thing, and it is difficult to find people who can—or even should—divorce their ego from their work.
...
A system that works will have to acknowledge fundamental human traits and work within the bounds they create. And ego is one of those traits.
"
- 'Facts and Fallacies of Software Engineering', Robert Glass, 2002Ironically, it's the "egoless" crowd which tends to be ego-obsessed and solipsistic. They imagine an egoless world which simply requires that everyone thinks just like me; in effect, everyone shares the same "ego"/perspective. Only in this bizarre fantasy world can we move past the ego and focus on "objective reality". Ayn Rand is an example of this worldview.
In my experience, It's both non-factual (ego-less people are the first to learn from others when poised with new ideas) and short-sighted.
Now that you mention it, there are parallels with the "tolerance" ideologues. There are people who are naturally patient and empathetic, and then there are people who opportunistically pursue the in-vogue virtue of "tolerance", and end up practicing de facto intolerance in the process. Don't conflate the two.
Sleep tight. :)
You are correct, we can't "get them out"; only they can do that by exercising their free will to choose to become better human beings. We can, however, attempt to teach them with our positive ideals, attitudes, and behaviors, but we can only lead the horses' asses to water, not make them drink.
Note that we must remain humble and grateful in remembrance that we ALL used to be horses' asses, once upon a time, before we entered the Path of Love.
I wasn't there, but my understanding is that essentially all programming in 1971 was done in large corporate settings or universities/research institutions. Those are environments where it's rare for any individual (even someone nominally in charge of a project) to have full creative and technical control over something, and even when they do, it only lasts as long as the project/grant or until their employer puts them on something else.
Compared to the 70s there are effectively no barriers to a passionate engineer starting their own software project as either an open source project or in their own startup, and I'd argue that those are settings where it's actually highly beneficial to bring ego into programming. It's pretty much the same notion as "founder mode" or why BDFL is one of the most popular forms of governance for FOSS.
Personally I'd recommend anybody who "brings ego" to their dayjob to take a stab at FOSS or a startup rather than trying to fit a square peg (caring a lot about their work) into a round hole (the realities of working on large projects).
They’re not actually smart enough to keep track of what every other team is doing, at any point in time.
FOSS works because there’s usually only at most a few dozen balls in the air simultaneously, so someone who believes they can keep track of balls in the air gets by without looking ridiculous.
But that’s just not viable when there are hundreds or thousands of balls in the air simultaneously… their eye muscles literally couldn’t move and focus fast enough.
End user software by comparison, has not really been successful in the FOSS model. There have been many attempts, but they perenially lag behind commercial offerings, and thus primarily see adoption from the ideologically motivated and/or very cost sensitive users.
I think we've all implemented some clever trick in our code that we started to feel proud of. It's hard not to do. Even if you just contribute to a small piece of the project, you still might have those instances of pride. We're all human, and it's fine to take a little motivation from your accomplishment. But hold on loosely. Be critical of your baby and be willing to throw it out if it isn't the best approach.
I used to really like driver/embedded programming because it seemed like there was a 'best approach' or idiomatic solution for most problems that eliminated ego. It felt more like electrical engineering. I often felt programmers working on higher level software treated their work like a personal art project and that turned me off from it.
There is nothing wrong with taking pride in your work, nor in recognizing that you might actually be more knowledgable/skilled/correct in some particular matter than someone else and communicating that to them - as long as that sense of knowledge/skill/correctness is not misplaced, not expressed cruelly, and the actual reasoning is explained. To me, that is "good ego". But if someone thinks they always know better than someone else in all cases or isn't even willing to open discourse/explain why that's "bad ego".
I guess to me, the sentiment expressed in this article is one that I feel strays too far into the realm of toxic positivity or crabs-in-a-bucket where merely being opinionated or passionate about your work is a bad thing because sometimes other people get their feelings hurt when you explain why their approach won't work well. I just don't think being egoless is necessarily good. I certainly wouldn't sit there smiling while something I worked on for years got destroyed by other people, because it'd be impolite or egotistical to point out that they're destroying something. But of course, there is a difference between something actually getting ruined, and having a meltdown because someone started naming variable in snake_case instead of camelCase.
So yeah you need ego. That said, it must also be tempered with the reality of needing to compromise enough to satisfice all stakeholders (including both technical and business stakeholders of all the different flavors). The beautiful thing about software engineering though, is there is a reasonable amount of objective facts, metrics and tradeoffs, that given a critical mass of sufficiently skilled and mature engineers, common ground tends not to be too hard to align on. Or at least, far easier than to get a non-technical stakeholder to understand the long-term implications of a bad decision.
To make the best work you have to take pride in it. This work has my name on it, customers will use it, I want to improve their lives not make them worse.
The developers who come after me will need to assimilate this work. They'll need to build on it. I want to make their work a joy, not a burden.
Do I take pride in what I do. It's not enough that the code just compiles.
Pride is balanced by humility. I'm prepared to defend my choices (with well informed, well experienced) answers. But the choices I make are always a balance of upside and downside. And over my career things have changed which reweights some of those decisions. I'm open to external input from others because I want the result to be good not me to be right.
I want to be proud of my work. But I'm humble enough to let others help me to improve it.
[The above is my goal, sometimes I fall short]
There are 19 pairs of vice/virtue pairs in the ego. We can only decrease our ego's vice-eous tendencies by increasing our consciously manifesting compassion to everyone we encounter. It also helps to contact our Creator and ask for guidance. It awaits us in Its Unfathomable Lonliness to beseech it for help to begin and then see out the complete transformation of our ego into a selfless, servant of the happiness of others and the societies/cultures we inhabit.
That Path of Loving Service is the key to happiness, and is the opposite of narcissistic attitudes and bahaviors.
There is nothing mysterious about the ego; it's just that willful ignorance is one of our heart's vices, and its purpose is to deny that each person's ego transformation is not only possible, but the source of joy and community uplift, and is our free will to choose love or any of its many selfish opposites.
The same sadly has happened with confusion of the word selfless (having no concern with self) with unselfish (concerned with others before oneself) and altruistic (unselfish concern for others' well being).
Personally, I don't see any incompatibility between having a sense of self and healthy self-esteem and having compassion.
Indeed, I see a major incompatibility between actual selflessness and universal compassion - as selflessness would preclude compassion for oneself.
You're right about the negativity of the ego's self-important nature via conceit and egotism. Those are negative traits of the self. The goal of self-improvement is to become a consciously virtuous person who puts the needs of the whole in its proper place, and doesn't indulge their selfish vices, which always cause unhappiness to those around them.
Positive self-esteem, when due to being a compassionate person, is a necessary component of the self-evolving person, because honesty in grokking the truth of ourselves is an important part of our growth.
And, remember, universal compassion also includes being compassionate to our own self, and as we increase our virtuosness, we are ever more beloved by the universe, itself. The happiness on that path is not known by but a small minority of the world's cultures/societies.
Sorry I'm not writing so clearly this late in the day, but know that the ego we have a birth is mostly selfish. It takes a definite turn towards the light to begin the process of purifying it by degrees from egotist to self-actualized bearer of compassion. It's a true fight, fighting against our own fallabilities and weaknesses and selfishnesses. But it's the most worthy struggle we will ever undertake.
I've seen this manifest as long and scathing code reviews, attitudes of "give me that; I'll do it myself," low morale, burnout... I've never found an adequate solution. Sometimes it was my ego that was the catalyst in a situation. I recognize it now, could I have caught it earlier?
We are the only beings on Earth that can self-evolve, by using our conscience and mind to evaluate of our actions to find out where we are causing unhappiness. Then, we must engage our free will to choose to be better, and do the things that help us to grow spiritually out of the immature, selfish mammals we begin as, into the humanitarians that result from reaching our highest potential.
The most destructive lie we let our minds tell us is that this transformation is not possible, or is the figment of someone's imagination. The ego tells us this because the spiritual path entails the destruction of the negative ego. Under this existential threat, the ego defends itself like hell.
One of the reasons Communism eventually failed is that it assumed that we could all accept the philosophy "from each according to his ability, to each according to his need." The assumption that we could all subjugate our needs to those of others is about as faulty as the assumption that we can subjugate our egos for the betterment of the team. A system that works will have to acknowledge fundamental human traits and work within the bounds they create. And ego is one of those traits.S-Tier
I like it because its amusing and always gets a new generation of gullible people.
"hey, rent's pretty high, how about you all give the state all your property instead and I run the state until further notice"
Current systems don't have a 1:1 with "hard work" and success/comp but its about as close as you can get, IMO.
Actually, no, it’s still not fine, because whole heaps of people will pretend to be unable to do much.
Perhaps the disconnect between effort and outcome was a factor, though as discussed above don't under estimate the satisfaction of a job well done.
I think it's more likely to be the centralized decision making, and how the people who make those decisions get chosen. A centralized system where people are choosen based on political ability/connections is likely to lead to corruption and mediocrity.
Note the above problem can happen in other systems as well - I'm not sure US politics is operating well at the moment for example.
That paragraph is as completely wrong in its understanding of human nature as a paragraph can be. Yes, it is difficult, but we are all capable of choosing to put ourselves through this self-evolution of our ego's vices into their corresponding virtues.
It's a tricky business, being a human being, with its very many pitfalls.
Ego would be making sure you got "your" sprint tickets done, did no code reviews, skipped the retro. I think few people do that but they will if Goodhart's Law happens.
Thus, it's never a balanced setup where everyone's happily working towards a shared vision in equilibrium.
There's always someone having a larger incentive than the other person, overriding their decisions in a haste, in order to reach a bonus objective.
Welcome to the real World driven by capitalism.
If our heart is aimed right, we can take advantage of religious practices to level-up, but with a callous or cruel or hateful heart, no amount of religious practices is going to do anything but cement our horrible behavior. This is because we each have the choice of how and why to behave one way or another.
The love one feels in one's heart is of little consequence if there is no selfless action in service to the loved person's happiness. It all adds up, as do all the petty callous treatments of the people in out-groups we don't give a sh_t about. And we should care about everyone; that is the way of compassion.
One day I needed to get a hotfix out to prod STAT. I pinged my manager to accept the MR and explained all the testing I've done. He said I could just accept it myself if I wanted it up now.
Turns out I've had the permission to push to prod since day one. The only red tape I had to cross was my own confidence.
After being acquired (~80 person startup) we were part of 1000 person org.
As the CTO of the acquired company, coming into a larger org, I was front row to this type of infighting.
Especially when the CPO wants direct ROI, and less worried about creating compound value.
"Executives are well-adapted to insisting on fundamentally contradictory goals"
Is so well worded (and also so hilariously true) that I wanted to symbolically tip my hat at the author in case they read here.
Specifically, in "Built to Last" the ability to hold two contradictory goals is praised as "Genius of the AND", as opposed to "Tyranny of the OR".
> In Theory There Is No Difference Between Theory and Practice, While In Practice There Is
I for one used to believe in a cross functional team. I used to believe that everyone in a team should be able to do every task in the team. I still believe it somewhat but my ego is shattered.
I worked on one team where the lead believed in this more than I ever did. Consequently, I was doing tasks I sucked at and therefore didn't enjoy s lot more because as she said, it will help me improve.
Long story short, I didn't improve. I just got frustrated and I quit. I guess it was all fine from the leader's perspective as her team stayed the way she wanted anyway.
I went down this tangent to remind people that when things are going well, we can say a lot of things that are nice like kumbaya my lord but when things are tough is when our ideals and morals are actually put to the test.
When poop hits the fan, will leadership throw someone under the bus? Will team members feel like leadership will throw people under the bus? Kind of a difficult question that we can't answer until we are there and at that point it is too late.
Learning some skill requires X hours. Maintaining that skill requires Y hours/year.
Those numbers vary both by task (webdev has quite a bit of churn, where server OSes tend to have decade-long support lifecycles) and by person (not everyone learns at the same speed, and sometimes people learn different kinds of things at different speeds).
A team where anyone can do anything can work or now work, depending on how hard the things they do are, how many different things there are, and who's on the team.
I've been here. I find it helpful to try and automate away reoccurring dread tasks. Not everything can be automated, but most things can be.
Where I've worked, a cross functional team is one made up of functional experts from different groups. A team where everyone could do the work of everyone else was a team that was cross trained.
I find it's good to periodically examine things that you aren't persuaded by from the other person's perspective. Dig deep a little. Ask non confrontational questions to figure out where they're at and why they're there.
It usually uncovers useful understanding, even when your mind on the surface issue isn't changed.
I feel seen
It is not about "nog being able to collaborate" - it is about refusing to do so.
The problem is not just that the Designer might Break the Build or ship something broken one time (but know how to fix it). The problem is that stuff can (obviously, not in all cases, and not something you should just assume will happen without good evidence/reasoning) start breaking all the time because you have too many people changing things that interact with other things they only partially understand. Or it's that one team/"domain" ends up downstream or dependent on another, and locally optimal but globally suboptimal decisions made upstream (eg a bad but quick to implement data model, or adding more dependencies on something you're in the process of getting rid of) cause problems downstream. In these situations your "egoless domain experts" might actually need the authority to force these things to stop, or might get burnt out spending all their time firefighting or playing hero.
There are also some kinds of engineering mistakes that are literally business-killing, like major security breaches/data loss. Mandatory code review isn't a "feel-bad program", it's precisely to guard against disasters like this (also I'm pretty sure it's literally required by SOX/SOC2 and I'd certainly want my software vendors to implement this).
That's why I think this is actually a balancing exercise that is highly case dependent, not something you can merely say "just empower people we're all on the same team". If your team is highly skilled, conscientious, and motivated you can give people a lot of autonomy - if they're mostly unskilled and don't give a fuck about the quality of their work, you can't give them much autonomy. If the scope of what you're working on is huge (so huge that any one person can only have a working understanding of a small part of the whole) you probably do need more process and guardails in place than a smaller project.
But things need to be architected for trust. If you have lots of rigid processes, then there's no use for manually executed tools that will only be used if someone decides to use them. People will lean on the process, and every time something goes wrong, the process will be "improved" (as in, catch one more potential issue, at the cost of taking longer and catching two more non-issues and making people batch up their changes more, causing more conflicts, etc.) In a high-trust environment, people will use the manual tools when appropriate, and so there's incentive for architecting things such that the results of those tools and processes is useful. Tests are more likely to test real things. Staging environments will be made to better reflect prod.
If people care about it, they'll make it work. If they don't, they'll make it "work".
But yes, I agree that as you scale up, more and more things will get missed and you'll need to balance things out. It's just so, so common to go too far in the rigid low-trust direction.
People are so terrified that something might go wrong that they'll do things that end up making sure that something will go wrong. It'll be something later, or somebody else's problem, or whatever.
The broader approach here is to encourage frameworks where changes must go through policy-as-code frameworks. SMEs write policy that is then enforced (or just warned, for some period ahead of enforcement) by the policy framework. Policies can encode exceptions, but changes to policy (i.e. to add exceptions) require SME review. The benefit is - stuff that passes policy doesn't require explicit review, so in the normative case autonomous teams are not slowed down, and when they are (due to policy failure), then it is for Good Reasons.
> Mandatory code review isn't a "feel-bad program", it's precisely to guard against disasters like this (also I'm pretty sure it's literally required by SOX/SOC2 and I'd certainly want my software vendors to implement this).
High-trust environments trust engineers to understand the difference between "this is a serious change so I need someone to review it" and "I'm just fixing a typo here so I'm going to rubber-stamp it." But yes, SOC2 requires mandatory code review, tickets, the lot. Yes, it slows things down, but that is the price you pay to become a Serious Enterprise Vendor. No, it doesn't fundamentally erode high-trust culture. People can just mark their MRs as "I need a rubber stamp" and find someone else to rubber-stamp them.
And more generally, it is not fun using a lot of mainstream software these days because it is a buggy mess, and I believe a lot of that dysfunction is partially related to the low standards for correctness that development teams have.
> Then one day, our designer broke the build in the middle of the night. Everyone came in the next day and couldn’t work until they figured out what had happened.
I've heard this [campfire?] story before. A bad commit happens and now no one can do any work. And I don't understand... Is it really that big of a deal to have to revert to an older commit or comment out the broken code until it gets resolved? Sure, I can see it being annoying, but not bringing an entire group of developers to a standstill. What am I missing?
As a toy example, imagine a database with columns for `first name` and `last name` and an update that combined them into a single `full name` column. That's going to be tough to revert for users signing up with just their full names.
Although in this case the build broke because the last committer didn't have authorization to deploy to production. The "fix" was giving him permission to deploy in the future. It is not clear why the developers going about their regular day wouldn't naturally resolve the broken build.
I find "this worked for me once at Etsy when we were a 20 person team" not a very convincing argument. That does not mean I think he's wrong. Just that the conclusion needs better arguments.
One argument that comes to mind is: If you treat people like children, they will start behaving like children. Treat people as adults if you want them to shoulder responsibility.
The main message of this talk is that when a designer tried to deploy a fix into production and it blew up production, they realized he had the wrong kind of permissions and their solution was to give him full deployment permissions.
Well, great if that worked for you. It might or might not work for others.
I would recommend not letting anybody deploy to production. You can deploy to staging, then tests are run, and only after those all pass can anyone deploy to production.
Also, the current process is not just the result of ego. It is also the result of evolution. We usually take steps to prevent things from happening because they have blown up in the past and we would like to not have that happen again.
Absolutely, let the designer deploy. Let them have stage access first so they can play, sure. But let them not be blocked. And if they turn the site purple, consider revoking the trust. But default to trust
then how do you credit those who do produce results? Just put money into the anonymous one's bank account.
we don't have that problem where I am now, but we should teach queueing theory in middle school.
as a lead engineer this is something I don’t even want… as soon as you have keys to deploy to prod, guess what you’ll be asked to do? and always at the worst times!
https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
The points do "soften up" but it starts with this, at number one:
1. Every good work of software starts by scratching a developer's personal itch.
> "We are living in the age of narcissistic personality disorder"
With a picture of the man who revolutionized EV vehicles, worldwide. Who created a company that sends rockets into spaces and then... freaking catches the booster down to the centimeter with giant chopsticks... And who created StarLink. And all this in record time.
If he considers Musk has narcissistic personality disorder then the world needs way more of those people.
How can seriously write about methodology and criticize the one person (if there's only one to pick) who has a proven track record showing he masters efficiency?
And I can tell you, for sure, a type of place where I go and see a lot of soul-crushed, egoless, people: public servants in inefficient public administrations.
It must be hard for egoless people to live in a world created by people with incredibly strong egos.
Linus and Theo de Raadt certainly comes to mind. And we all use and depend on the work of these people.
At some point when you see crap, you have to take a stand. Be it when you find crap at work or be it when you read crap online.
I think Dan is missing mentioning one ingredient: Security.
Not code security, the human feeling of personal security. Most especially, of being secure in one's role.
And that drives so much of this. If everyone is secure in themselves, or able to transcend worrying about their personal security, then magic happens.
Without it, things will inevitably wander back to gatekeeping, control, and conflict. Much as in the world at large.
I think there's so much in that (although how to scale it out is clearly a tricky question). The best places I've worked, have all had the ability to make changes when there's a clear benefit. The worst places I've worked have had the opposite, where it's so hard to touch anything beyond the remit of a ticket or feature item, nobody changes things that are obviously flawed and easily fixable.
A manager, to which directors, CEOs, and so on are all included in, have this lever which is that they can hire more people and create new roles/re-organize teams. And they skew towards it for many problems...
We want to deliver features faster, what can I do, me, a manager?
- I could hire more engineers!
- I could reorganize my engineers so each one works on a specific type of issue
I'm picking at managers, but every role has this issue. Engineers have this lever of "technical ingenuity". And they skew to it as the solution to all problems.
We want to deliver features faster, what can I do, me, a software engineer?
- I could rewrite this in a more productive language/framework
- I could redesign this to make it simpler and easier to work on > hire more engineers
Did it mention any insight on what that point is? And did it contrast against any other approach in the studies? Like look at opportunity cost of this versus other ways to deliver faster?
P.S.: And I didn't mean that those levers are always wrong, more that I've noticed this bias towards the main levers each person has at their disposal. If there's no check on that bias, you, for example, end up in a company that keeps hiring at a furious pace and keeps rewriting all their services all the time in new languages or alternate designs to no end, because everyone just uses their obvious lever as much as possible with the good intent of trying to solve all the problems in the way they can.
Hence the more pithy “Adding people to a late project will make it later”. The assumption being that you’ve already maximised the number of people that could work on the thing (trying to get it out the door on time).
To use the infamous analogy that "nine women can't make a child in one month": it is still true, but if your goal is to have more children (as opposed to having one child be born sooner), adding more women would certainly help.
> Engineers have this lever of "technical ingenuity".
LMAO this is not merely a lever. This is why you hired engineers.
It is very common to see engineers trying to solve non-engineering problems using the "technical ingenuity" to attempt resolving social issues; sometimes it works well enough (e.g. timezones), and sometimes it fails pretty miserably (e.g. OLPC).
All these “if you do it this way it works” posts seem to assume everyone has the best of intentions (or at least want to do the best job possible), and especially in corporate settings I just don’t think that’s always the case. People are just there for a paycheck and to divert any possible responsibility away from themselves…
If so, then it's already pretty messed up.
In this particular case, there's a link at the bottom of the page, the guy used his own tool keynote-export tool to turn his Keynote presentation into a web page (Keynote is apple's powerpoint-like software):
But it made my heart warm that someone used Amdahl's law and applied it to people. It's how I've felt for a long time, and why I value communication but kept at a minimum.
I think it was about the blue company that's tried to pivot to the metaverse?
The gist of the post is that managers started to actively discourage looking outside of their little walled garden, to the point of people getting bad performance reviews for building bridges to elsewhere.
Must of the problems described here come from a cultural setup that you can't tell or even suggest your managers that they are stupid and/or someone above them is even more stupid.
I noticed that this is especially painful in the US companies, we in Europe seem to be much more lucky with telling people that they do stupid sh*t and not lose the job after telling that. But YMMV
Sorry -- you lost me in the first sentence.
I've read H&P and a bunch of PG's essays. Unsure what conflict exists btw Graham's writings and the content of this guy's powerpoint essay.
Giving people the keys to the car is both 1. how you make a happy person and 2. build systems that understand and operate with the bigger picture