12 ms·

Egoless Engineering

• mattcaldwell 2y ago
  Lots of people in the comments exemplifying why I would never want to work with them.
  • lijok 2y ago
    There is currently literally 1 comment disagreeing with some of the points in the article. 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.
    • mattcaldwell 2y ago
      I'm saying the opposite. There are several comments that demonstrate an insecure "dog eat dog" mentality.
• webdevver 2y ago
  good guide for allowing everyone to walk all over you
  • majormajor 2y ago
    If you're a manager, you put this stuff in place in-part so that everyone understands that you will be watching for attempts to walk all over others.
    • MrLeap 2y ago
      Agree with you. Every successful team I've been on looked like this. Basically everyone just wanted to ship a thing. If that's the baseline norm, anyone motivated by politics or pecking order bullshit glow hot and everyone can see them. 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.
  • malfist 2y ago
    Work is not a zero sum game, sometimes, everyone can win.
• datadrivenangel 2y ago
  The part about intentional team values is very good: • 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!
  • nox101 2y ago
    Western society (or at least USA society) seems to me to foster the idea of "not my responsibility". My example would be, going to a fast food place and not cleaning your table even though there are trashcans and places to put your tray. Spilling something and not even attempting to clean up after yourself. 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"
    • xyzzy4747 2y ago
      Incidentally I noticed in India most fast food shops have enough spare workers to clean tables for you. So you don't have to clean your own table.
    • _DeadFred_ 2y ago
      Huh? US society doesn't foster that. Sounds like you just live in a crappy area or a rich super entitled one. I've never lived in an area where people just left their fast food mess or just left spills. It's never been an attitude fostered anywhere I've lived. To be fair I mainly had experience with the midwest/western USA, maybe the east coast is different.
      • fragmede 2y ago
        there's definitely a "it's not my job to _____, why would I do someone else's job for them" attitude I've noticed from some people, though I couldn't say what traits they share so as to identify a subgroup.
      • seadan83 2y ago
        Maybe some things feel more prevalent. I'd say this is largely confirmation and/or sampling bias. Nobody knows without actually doing the sociology that there are these tendencies. To the extent that we have anecdata, we don't know how much more prevalent such tendencies are. The USA is a big AF place, 400 some million people.
• spuds 2y ago
  Really resonated with this, reminded me of the journey I went on over the course of my dev career. By the end, my advice for every manager was roughly: * 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.
  • agumonkey 2y ago
    talking about ownership, I ran into some git repo with a "declaration of non ownership" an economy of giving in a way
  • dakiol 2y ago
    With modern team structures it’s difficult to have ownership all the way to prod. My team consists of: one product manager, one staff engineer, one or more lead engineers, one or more senior engineers, one engineering manager. 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.
• harshaw 2y ago
  Random comment: slide 10 talks about using Twisted and then adding a twisted middle layer. 2010 me (or earlier) liked Twisted a ton but not sure I would have foisted this technology on a development team. As a single dev doing all kinds of crazy shit it (sort of) worked but was pretty hard to debug or understand.
  • from-nibly 2y ago
    Well that shows my age, I thought twisted was being used as an adjective.
  • sethammons 2y ago
    Twisted was aptly named. It was the only async python we used around that same time. We moved to Go. It was glorious.
• awesome_dude 2y ago
  This really hits > 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"
  • awesome_dude 2y ago
    Also, we literally invent a system that shows how our software mirrors the company we're automating (DDD) and completely miss that we're different parts of a distributed system ourselves.
• MrMcCall 2y ago
  The success of any organization depends upon each member behaving selflessly to meet the needs of the group. Selfishness in any organization is a parasitic drain on energy and productivity. 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
  • aylmao 2y ago
    > Such is our baseline mammalian heritage, which we must each overcome with deliberate spiritual self-evolution. 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.
    • MrMcCall 2y ago
      Well, the higher-ups (in all organizations) do, indeed, have a greater cultural influence on the group's ideals, attitudes, and behaviors. The especially problematic aspect of this is that we often reward the least compassionate with greater responsibility. That is backward thinking from backward-facing people. 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.
• instalabs 2y ago
  > So that was a high-level overview of how all struggling companies are unique. But they’re also all the same. Reminds me of Tolstoy's “Happy families are all alike; every unhappy family is unhappy in its own way.”
• claytongulick 2y ago
  Was an interesting discussion, but lost me with the sort of pointless Musk bashing near the end. 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).
  • zomglings 2y ago
    Where was the Musk bashing? I didn't see that in the slides.
    • simonw 2y ago
      I had to look pretty hard to find the Musk bashing - there's a (face redacted) photo of Musk carrying his sink around on the slide about narcissistic personality disorder.
      • claytongulick 2y ago
        The slide that has an iconic, well known photo of Musk, where his face is scratched out and "screw this dumbass" is written on top is pretty easy to find. "Redacted" is a very polite way of describing what the author did.
      • bigiain 2y ago
        Part of me wants to say "Using a picture of Taylor Swift when talking about successful recording artists wouldn't make anyone bat an eyelid. This was a discussion about narcissistic personality disorder..."
  • dpc_01234 2y ago
    Microsoft was doing all sorts of immoral anti-competitive stuff, and trying to strife free and open source movements to protect their monopoly. They deserved the hate. They came around and complaining about them mostly stopped.
• vitaminCPP 2y ago
  Is there a video of the talk somewhere ? I prefer recording over slides.
  • mcfunley 2y ago
    Unfortunately no, I've only done it as a private event within a company so far.
• nvartolomei 2y ago
  How does something like this scale for more than 10 people? 100? 1000?
  • awesome_dude 2y ago
    This is the problem all medium to large businesses face - red tape, faceless bureaucracy overloads the system Every. Damned. Time.
  • aylmao 2y ago
    fwiw, Etsy seems to have ~2.5k employees [1]. [1] https://en.wikipedia.org/wiki/Etsy https://en.wikipedia.org/wiki/Etsy
  • jakevoytko 2y ago
    I was at Etsy after Dan left, and I think it scaled pretty well from the few hundred engineers when I joined to closer to 1000 when I left. Etsy's engineering culture had a lot of problems, but they weren't caused by empowering people. If anything, being encouraged to work cross-functionally built a lot of empathy and understanding for different roles and hats in the org, and made a lot of engineers a lot more effective. 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.
• lijok 2y ago
  Most of the issue exemplified in the article arise due to a lack of domain expertise, not ego. Parochialism, maybe, as it relates to lack of expertise. We fear what we do not understand, which translates into domain ownership and controls over guardrails. 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.
• caust1c 2y ago
  This is great! The best teams I've worked on have worked towards the following: 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.
• dpc_01234 2y ago
  The stab at Musk seems out of place. You might not like him, or his politics, but he took over and reformed a slow and bloated place, and despite all the doomsayers Twitter is still working and IMO better than before. And he has a solid track record of delivering: finance app, electric cars, rockets. Sure he over-promises and under-delivers, sometimes borderline lies, etc. but there is a huge amount of wisdom behind what he's doing, and you're doing yourself a huge disservice by just dismissing one of the most successful technical entrepreneur of our times.
  • lijok 2y ago
    He did all but the Twitter takeover prior to turning shitheel. And I wouldn't consider Twitter reformed, so much as its goals have changed.
  • psunavy03 2y ago
    And he'd be even more successful if he didn't insist on also being a complete, utter egotistical asshole. Leave whether or not you agree with his policy positions aside for a moment; it's fairly obvious that the guy is a complete shitheel of a person who's basically the dictionary definition of "brilliant asshole." 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.
    • dpc_01234 2y ago
      First, I have no idea if he's a "utter egotistical asshole". Never met the guy, and I assume that most people hating on him formed opinion of him by consuming heavily negatively biased sources. However, I assume he is some type of an "asshole". And "he'd be even more successful" if he wasn't is just very wrong, IMO. From my experience the top of any organization is completely overrun by assholes. Some smart, some dumb, some more moral, some less, but generally assholes. Being an asshole is selected for in hierarchical organizations and simply required. Part of the reason why leftists dream about some socialist utopia, when attempted in practice is ruined by some asshole(s) taking over power and turning the social utopia into totalitarian distopia.
• 0xbadcafebee 2y ago
  "How do we tear down parochialism and ego?" First, by not writing rambling, pretentious, navel-gazing, ignorant powerpoints. This would be amazing if it were satire.
  • Dansvidania 2y ago
    I don't see what you see. Would you mind what part of this seems pretentious, navel-gazing, ignorant? ( I think rambling was stated in the article :)
    • quonn 2y ago
      Literally on the second slide: "I’ve done engineering since the turn of the century, and led small teams and biggish orgs." If that is not navel-gazing or humble bragging, what is?
      • Dansvidania 2y ago
        I would propose to you that those might be factual statements. I don't really see any self-indulgence in stating where one is coming from when writing a post that is a critique of organizations. 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 :)
        • quonn 2y ago
          I‘m sure it‘s factual and common, but it‘s tone-deaf given the slide deck title.
  • deleted 2y ago
    [deleted]
• psunavy03 2y ago
  Really goes to show how the whole "I have the hardest job in the company and all y'all are just morons" attitude really needs to die.
  • aylmao 2y ago
    I once had the pleasure of working with a guy who probably did have one of the hardest jobs in the company, but also had a very positive attitude towards everyone else. 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.
• pjmorris 2y ago
  An ageless idea... "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, 2002
  • pphysch 2y ago
    > 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. Ironically, 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.
    • aylmao 2y ago
      Claiming that the "egoless" crowd is egotistic, because "they want everyone to think like them" is like claiming the "tolerance" crowd is intolerant, because "they don't tolerate intolerance". 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.
• jeromechoo 2y ago
  I joined my current company to work on Growth. I was added to Gitlab, and for the first 3 months I pushed all my commits as MRs that my manager reviewed and merged into main. Standard procedure. 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.
• bearjaws 2y ago
  The section on Deriving the Equation for a Disaster is perfect. 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.
• Dansvidania 2y ago
  I did not finish yet to read, but "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.
  • mcfunley 2y ago
    Glad that one landed, thanks!
  • zdw 2y ago
    This is pretty close to what's espoused in the Jim Collins books which are descriptive of specific companies but get turned into proscriptive nonsense by people who don't get that. 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".
    • Dansvidania 2y ago
      I think the discussion gets complicated but I’ll make an attempt at brevity: IMO executives/higher management must be able to juggle/balance _potentially_ contradictory goals. The issue is when they push this responsibility to rank and file employees.
• xyst 2y ago
  I like the idea but it’s something that must be implemented from the top.
• thanksgiving 2y ago
  I want to go off a small tangent > 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.
  • tbrownaw 2y ago
    > 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. 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.
  • MrLeap 2y ago
    > I was doing tasks I sucked at and therefore didn't enjoy s lot more because as she said, it will help me improve. 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.
  • wheelinsupial 2y ago
    Do you mind elaborating on the definition of "cross functional team" here? It seems either non-standard or something that may differ by industry. 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.
• RobRivera 2y ago
  I always check the ego at the door, but have a high threshold for persuasion if I've done due diligence.
  • MrLeap 2y ago
    This sounds healthy. 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.
• tracerbulletx 2y ago
  Sports metaphors are a bit unpopular in tech, but the teams that win championships in sports have exactly the same dynamics as a good business team and we should be taking a lot more from that school of thought.
  • seadan83 2y ago
    What are those dynamics specifically? How often do winning teams actually share those dynamics? Which dynamics are more important? Which dynamics are required but not necessary to win (ie: which dynamics are required to not fail, but not sufficient to win?)
• shusson 2y ago
  There are a lot of big egos in team sports, and in high performing teams you often have a team full of big egos, although there are usually a few "team players". I wonder what coaches think about ego.
• reutsharabani 2y ago
  "They get up to building entire GraphQL monstrosities to avoid talking to each other." I feel seen
  • sethammons 2y ago
    The weird balancing of plates I have seen developers do to not talk to each other amazes me. I often have to remind frontend that we are on the same team as backend and we own the technology: if we need an api to behave differently, let's make that happen, not code around it. Similarly, I have to tell the backend team that the things they find frustrating can be automated, processes can be changed, and we can talk with ops and platform teams to come up with solutions instead of coding around it.
    • julik 2y ago
      Yes, but when you do manage to get people to "say what they mean" I had the following response from a frontend bloke (me being on the "backend" side, even though I never refused to work on frontend per se): "I don't like you and I don't like your stack, I want to make decisions regarding frontend without consulting with anyone, I want to get promoted for running a team which overcomes any hindrances related to either how the product actually works or that human collaboration requires communication." It is not about "nog being able to collaborate" - it is about refusing to do so.
  • marcosdumay 2y ago
    On the other hand, people can't possibly talk to each other if they are always in a meeting.
• fullstackwife 2y ago
  Why I don't hear such discussions coming out of other engineering fields? Is this type of hamletization specific to software engineering?
  • deadbabe 2y ago
    Unlike other engineering fields, software engineering is more similar to being a writer, and that’s another field that has big egos. The work you put out directly speaks about your personal abilities and worth.
  • 9rx 2y ago
    Perhaps because you are not in tune with the goings on of other engineering fields? I don't know what the Hacker News of civil engineering is, but it is likely you will find similar discussions happening there.
• dmead 2y ago
  This is impossible without egoless software engineering managers.
• weitendorf 2y ago
  Definitely agree that domain experts are preferable to domain owners, and that overly explicit specialization causes problems, but at the same time I think it's quite possible to stray too far in this direction too, and that the author didn't really address that. 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.
  • sfink 2y ago
    If you care about the experience of your co-workers, you won't repeatedly break stuff. (Or if you do, it's because your tooling hasn't scaled enough to keep up; you need a staging area or precommit hooks or whatever.) If you know you're trusted to do your job, you will work to maintain that trust. 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.
• default-kramer 2y ago
  Kind of tangential, but: > 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?
  • itishappy 2y ago
    Stateless code makes for boring programs, but stateful code can be difficult to roll back. 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.
    • 9rx 2y ago
      While that would certainly impact production, it would be a bit strange for development environments to be stateful in the same way. Those not immediately involved in dealing with the stateful issue seemingly should be able to continue with their work away from production systems just fine. 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.
  • cdchn 2y ago
    How does giving them deploy access prevent them from breaking the build, too?
  • smag 2y ago
    I actually saw this happen at Google: no one could pinpoint the cause of the broken build for a while, and then it turned out to be a UX designer who broke the build. He was apologetic, like McFunley's example. But unlike the example, this guy never made another commit.
• from-nibly 2y ago
  I spent so much time at my last job trying to implement this with so much resistance. I felt so insane for getting resistance I ended up becoming a jerk and hated who I was. The worst part was because I was so good at what I did people started trying to protect me from getting angry. That made me even more angry and jerky. I hope I will be forgiven, I hope I can become better.
• fefe23 2y ago
  I like his other two talks better than this one. 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.
  • sethammons 2y ago
    Why can the tests not be ran automatically and why not let anyone deploy at anytime? Like, if super senior dev or first day intern deploy, I expect tests to run and the deployment to go out and for systems to be automatically monitored and the deployment reverted if errors pop up, and also manually revertable if a test missed something. 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
• luxuryballs 2y ago
  hahaha they gave the designer keys… to deploy to prod! 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!
  • datadrivenangel 2y ago
    Deliver fast! Always at the worst times.
• choonway 2y ago
  the opposite of an egoistic programmer, is the anonymous one. then how do you credit those who do produce results? Just put money into the anonymous one's bank account.
• motohagiography 2y ago
  Slides 25-26 filled me with hollow, empty laughter. we don't have that problem where I am now, but we should teach queueing theory in middle school.
• farmeroy 2y ago
  Part of me wants to say that it's best to work in a 'low-ego' environment as opposed to a 'high-ego' one - or to avoid working with people who have 'huge egos'... but I honesty find any discussion about 'egos' relatively devoid of meaning. As someone else said, it's difficult to find people who work without ego (whatever working without ego would mean). Most of my professional experience is as a working musician, and it goes without saying that artists have egos, in the sense that they try to bring something from their inner selves to the outer world, and that they invest a lot of effort in learning how to do so properly. Sometimes I've felt that the best musicians I've worked with were "low ego" but this could be just that they are supremely confident and also not lacking in affirmation from their audiences - and if they are kind, from their fellow musicians. The worst people I've worked with are talented people who can't seem to find the affirmation they crave, but feel they deserve. They feel constantly slighted and left behind. As a band leader, I realized I simply have to stroke these people's egos - no matter how confident, skilled, or amazing some people seem they are riddled with self doubt and absolutely need outside affirmation. I used to fight it, but eventually learned it was my job as a manager of sorts to do so...
  • neolefty 2y ago
    I find "ego" to be really interesting — on the one hand you want high-ego: confidence to try things, strong sense of mission — and on the other hand you want low-ego: selfless giving, able to let go of ideas that aren't working. Are those egos the same thing? I really don't know.
• stringhacker 2y ago
  [dead]
• TacticalCoder 2y ago
  This completely disregards the methods that brought us the most successful software ever written, which we all rely upon and which the world rely upon to function. https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar 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. Ego. > "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.
• coderintherye 2y ago
  Kiva's engineering drew quite a few lessons from Etsy, though we never got so big. 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.
  • mcfunley 2y ago
    Yeah you are right about this, psychological safety is a key ingredient in what “good” looks like. Blameless culture stuff is a bit of another ball of wax, so I didn’t get into it too much.
  • benrutter 2y ago
    I was listening to Andrew Kelley (of Zig fame) in a podcast the other day. He talked about the fact that, because the zig foundation is a bunch of empowered experts, he doesn't really need to manage work because people following their own idea of good software leads to really great work. Having the psychological safety of "being trusted to do what you think is right" is critical. 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.
  • steve_adams_86 2y ago
    Years and years ago I helped someone with a remote team (quite a while before remote was common) try to get his team to be more productive. We'd sit and chat about the state of things, ups and downs since we last spoke, and try to figure out strategies to improve process and get things working more smoothly. For a few months virtually nothing changed despite all kinds of small efforts scattered around. He was dealing with pretty insane stuff. Clearly competent developers were letting PRs languish for weeks. They weren't producing code to their own standards consistently. Designers were dumping deliverables last minute with no documentation or guidance for implementation. Just assets, hurriedly put together, with some palpable hope that they'd just get used and everyone would carry on without their involvement. There was no collaboration, very low communication, and hardly any cohesion across teams. After a few months I came to realize that everyone was struggling in their role in some way or another, afraid to admit it, and unsure of how to catch up and keep up. Expectations of them were remarkably low, but no matter who fell behind they would eventually begin this oscillation between scrambling and vanishing. I recommended that he let everyone know it's okay. We all fall behind, we've all got life going on, and having no deliverables happens. I suggested that the messaging would need to be sincere, clear, and personal in order for everyone to really believe that it was okay that they weren't performing well. After a week or so of figuring out how he wanted to address everyone about it, he did it over a group call and was a total human being about it, describing his own struggles, challenges with staying on task, his inability to program "well" due to his lack of training, and so on. It was great, and very sincere. He made it clear that he knew what was happening, but he wasn't upset and he wasn't pointing fingers. The results were like night and day, though not immediate. Everyone gradually started explaining where they were. Maybe they had kid stuff in the way, got stuck getting a test to pass, didn't understand the problem well enough, no sleep, sick, etc. PRs got reviewed more often because there was less shame around letting them sit at all. Everything generally got better. Not perfect, but workable. At the time that I recommended he do that, I felt a little bit insane. Like, what if this just permits everyone to be even worse? What if it comes off like it's a trap, and everyone gets even more paranoid and insecure? Am I just imagining everyone wants this because it's what I've wanted in the past? Since then I consider it one of the most essential components of functioning teams. People can still be high performers in unsafe roles, but the team as a whole suffers for it, then the company does as well. Especially the company, over time.
• didibus 2y ago
  One thing I've realized is that people in different roles have different levers to solve problems, and they naturally skew to using that lever to try and solve all problems, even if that lever can't solve the problem and could make it worse. 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 It becomes really hard to accept that, maybe, as a manager, you can't do anything about it, except support and encourage those that can, like the engineers themselves. How could you help them deliver features faster? 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
  • throwaway2037 2y ago
    > hire more engineers I was listening to a podcast with Joel Spolsky recently. He told a story that when he went to Microsoft, they had done internal research (and experiments) to debunk some of the theories from Fred Brooks' "Mythical Man Month". At the time, he generally believed in the "rules" from "Mythical Man Month", and was pleasantly surprised to learn about this further research. In short: Adding more developers does help, up to a certain point.
    • didibus 2y ago
      > Adding more developers does help, up to a certain point 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.
• Aeolun 2y ago
  Ok, but how do you deal with people that submit broken CSS, break the site, and are unapologetic? Especially when you are in no position to fire them (because laws, or organisation)? 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…
  • brainzap 2y ago
    you fire them
    • alkonaut 2y ago
      That takes months or years if it's possible at all (at least in many places). For any place where you can neither fire bad devs nor find very good ones to replace them with, the trick is to make good processes and products using mediocre people. And that's hard. But that's also why a lot of processes appear, that would seem unnecessary to someone who is a good engineer and used to working only with good engineers.
      • imtringued 2y ago
        You fire them anyway. The problem isn't incompetence. It's the inability to self reflect and see your own mistakes as mistakes that is missing.
  • jamil7 2y ago
    I guess you need to put automation in-place that interrupts these people when they're trying to deploy something broken. Tests, linters, static analysis etc.
  • xandrius 2y ago
    There must be a point in which they can be fired, unless there some nepotism going on. If so, then it's already pretty messed up.
• euroderf 2y ago
  OT: What is this presentation format called - slides on left, text on right ? Are there any dead simple tools to optimise making them ?
  • mewse-hn 2y ago
    It's basically a powerpoint presentation. The slides are projected to the audience and you have a field for the presenter's notes. Any powerpoint style software should be able to do this. In this particular case, there's a link at the bottom of the page, the guy used his own keynote-export tool to turn his Keynote presentation into a web page (Keynote is apple's powerpoint-like software): https://github.com/mcfunley/better-keynote-export https://github.com/mcfunley/better-keynote-export
• thisOtterBeGood 2y ago
  Those Galadriel memes had me in tears :')
• FreeInsulation 2y ago
  [flagged]
• locallost 2y ago
  It makes sense, but I wonder if it's something most people feel it should be like, but the reason it's not is that it's not possible. I switched jobs recently looking for something like this, but still haven't found it. Now I know the argument of the article is that it worked in one place, but maybe this was just lightning in a bottle of same minded people coming together. So maybe the answer to the problem is that it doesn't take a large number of extremely ego driven people to mess everything up. I say extremely because I think to an extent everyone has one. 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.
• red_admiral 2y ago
  There's an old rachelbythebay post that's relevant here: https://rachelbythebay.com/w/2018/03/21/next/ https://rachelbythebay.com/w/2018/03/21/next/ 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.
• kunley 2y ago
  Oversimplifying warning: 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
• julik 2y ago
  This is incredibly good, and reflects most of the things I have bumped into that made me miserable. One of the takeaways for me (which transpired where I am now) is "to do devops properly, do not have, hire or designate dedicated ops people". It works exactly like it should.
• danesparza 2y ago
  "Like many of you, I was raised in the background radiation of Calivinist thought" Sorry -- you lost me in the first sentence.
  • iterance 2y ago
    That's fair, but if it makes you at all curious to learn what he means, you night find it rings true - if not for you, certainly people you know. https://en.m.wikipedia.org/wiki/Protestant_work_ethic https://en.m.wikipedia.org/wiki/Protestant_work_ethic
    • mrweasel 2y ago
      I feel like the concept of "protestant work ethic" has been coming up a lot lately. Make me wonder if this is going to be the stoicism of 2025.
      • stavros 2y ago
        I hope not. I, for one, don't view the Protestant work ethic in as positive a light as I do Stoicism.
  • zJayv 2y ago
    also: "I also read Hackers & Painters at an impressionable age and was kind of a jerk about it for a while. This talk is about how despite this, I got better." 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.
• gregors 2y ago
  In my opinion very little of this has anything inherently to do with development, but organization science in general. All these problems exist is every org corporate or otherwise.
• mattxxx 2y ago
  From the title, I wanted to dislike this, but Dan McKinley drops another banger slide. 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
• jboggan 2y ago
  I really liked the part about engineering committing to force multiplication of the other parts of the business. Once in a senior data engineering role I took it upon myself to just teach the PMs SQL and let them start running their own analyses, with regular weekly 1:1s and office hours. It totally wasn't my job but it saved me twice the hours I normally spent responding to their ad hoc requests, allowed some wild hairs to turn into actual profitable products, and hopefully stimulated some professional development.
• oceanparkway 2y ago
  I don't think engineers (especially non-managers) talk or write nearly enough about personality dynamics at the workplace.
• Conscat 2y ago
  > I also read Hackers & Painters at an impressionable age and was kind of a jerk about it for a while. My mom gave me Hackers & Painters when I was 13 or so, but I still haven't read it. What about it turns children into jerks?
• maximus93 2y ago
  Egoless engineering is such a great mindset—focusing on team goals over individual credit really makes collaboration smoother and ideas stronger. It’s amazing how much better things get when everyone’s just working toward the best solution, not personal recognition. Definitely something more teams should embrace!
• rolandthomas 2y ago
  [dead]
• neycoda 2y ago
  I mean, these seem like good passwords at least.
• haroldkurt50 2y ago
  [dead]