[HN Gopher] Egoless Engineering
___________________________________________________________________
Egoless Engineering
Author : mcfunley
Score : 747 points
Date : 2024-12-03 20:38 UTC (1 days ago)
(HTM) web link (egoless.engineering)
(TXT) w3m dump (egoless.engineering)
| datadrivenangel wrote:
| 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 wrote:
| 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 wrote:
| 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_ wrote:
| 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 wrote:
| 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.
| 01HNNWZ0MV43FF wrote:
| If there's a country that doesn't speed and litter please get
| me a visa so I can go home
| mc3301 wrote:
| Japan (only 80% serious here)
| Aeolun wrote:
| Go to the countryside and be amazed. Exactly _why_ people
| litter to that extend 20km from civilization escapes me.
|
| 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.
| rglynn wrote:
| How is the work culture in Japan these days? Is it
| possible to find a company that doesn't have their
| peculiar (read "awful") work culture?
| rglynn wrote:
| Japan, although both of these are taken to the opposite
| extreme.
| boruto wrote:
| I am from an eastern society, So my first day in western
| society I saw a blue collar worker clean up his food crumbs
| on a REWE deli table. This might seem normal to do for you,
| but I swear I never seen anything like that in my life in the
| eastern society. I was 27 this had profound impact on me than
| reading any book, I still remember it after a decade.
| harry8 wrote:
| This works both ways or it doesn't at all.
|
| 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."
| neolefty wrote:
| I've encountered people who sincerely dislike talk of "values",
| and I think it's because they have seen them used as a flog
| rather than an inspiration. My guess is that there was a leader
| in their past who set values but didn't actually follow them.
| "We dig ditches" means "everybody but me digs ditches". It's
| hard to be both technically and morally capable, but I think
| that's what leadership requires.
|
| 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?
| spuds wrote:
| 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.
| dakiol wrote:
| 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.
| bibabaloo wrote:
| I feel this so much. I feel like most of my job is playing
| politics to make sure people are happy and let them feel like
| they're adding value. Rather than shipping things to users to
| improve the product. It's honestly so depressing. Strongly
| considering going back to work at a small startup, to avoid
| having to work with these layers of middlemen that really add
| little to no value.
| agumonkey wrote:
| the one who solves this problem will flood the world with a
| neverending wave of light..
|
| 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
| Micoloth wrote:
| A difficult quest indeed, but not impossible. Sometimes
| teams like this do exist.
|
| You know the ones. They founded the trillion-dollar
| companies you hear about and became billionaires
| themselves
| Vilian wrote:
| Nah, it's usually luck and robbing someone else work,
| windows apple Facebook etc
| bryanrasmussen wrote:
| I'm going to say it is efficiency and the ability to
| implement ideas well, even if they are stolen ideas, that
| account for more of the success for anything else.
|
| 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.
| agumonkey wrote:
| yeah there's always something a bit special in success,
| even if they took the idea, you can't just copy paste or
| you just produce shallow shiny stuff
| travisgriggs wrote:
| Lobby your government to tax management hours. That'll
| fix things.
|
| I often wonder how some open source projects manage to be
| so successful/productive with so little of what looks
| like corporate management.
| pineaux wrote:
| How would you implement this though? Wouldn't things just
| be renamed?
| Aeolun wrote:
| > 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
|
| Salary is inversely proportional to how much you actually
| (need to) do.
| motorest wrote:
| > I feel this so much. I feel like most of my job is
| playing politics to make sure people are happy and let them
| feel like they're adding value. Rather than shipping things
| to users to improve the product.
|
| 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?
| sensanaty wrote:
| I remember in a prior job that I had just joined when I was
| still new to the field, they had a bug board where they
| collected all the most common bugs users were experiencing.
|
| 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.
| sethammons wrote:
| Healthy orgs must have slack in the system and allow
| teams and individuals to do a little chasing of fun or
| meaningful things that give them intrinsic pride and
| motivation.
|
| 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.
| fatnoah wrote:
| > Healthy orgs must have slack in the system and allow
| teams and individuals to do a little chasing of fun or
| meaningful things that give them intrinsic pride and
| motivation.
|
| As an Engineering leader, I try my hardest to make sure
| this Slack exists for the exact reasons you listed.
| spuds wrote:
| Yeah I completely agree that a lot of structures work
| actively against this. Lot easier for me to write a bullet
| point about it than actually implement it at a company with
| an existing way of doing things. And I think it's almost
| impossible to implement from the bottom up, as it often
| requires some real process (and culture) changes.
| Dansvidania wrote:
| this really must be common. I myself could have written a
| similar (less well put) summary of my last two jobs.
| worksonmymach wrote:
| It needs a culture change. The magic words:
|
| "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.
| bjornsing wrote:
| I agree. First step I think is to start measuring what's
| important at the top of the organization. When you have
| weekly progress meetings with the CTO and CPO and only look
| at lists of new features, then new features will be what
| people think about. "What gets measured gets done", as they
| say.
| motorest wrote:
| > "Our customers prefer the product works over getting a
| new feature, so let's ensure that at any cost"
|
| 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?
| worksonmymach wrote:
| > 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?
|
| 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.
| motorest wrote:
| > A feature that drags people over is really a new
| product.
|
| 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.
| whstl wrote:
| False dichotomy. The point of the quote is to worry about
| not breaking the product. It's still possible to deliver
| features while keeping it working.
| motorest wrote:
| > False dichotomy.
|
| 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.
| jack_h wrote:
| > 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.
|
| 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.
| cereal_cable wrote:
| Quality can also become it's own trap as the entire org
| chases metrics aimed at quality. Soon you have loads of
| brittle tests that likely aren't adding great assertions
| but you have code coverage.
|
| 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.
| worksonmymach wrote:
| You are right and the biggest asset here are executives
| and management that can:
|
| 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!
| sevensor wrote:
| How do you build 1 and 2? It seems so simple: talk
| relentlessly about what you're trying to do as a company,
| and then figure out how to assign your people most
| effectively to do that. I've seen a number of leaders
| figure out the messaging and then flat out fail on
| execution. Once they've worked out the vision, they fail
| to give middle management enough latitude to accomplish
| it, and the lack of trust flows downhill.
| YetAnotherNick wrote:
| I have never seen positive impact from turning the devops
| dial up. Most of the times, we just keep on adding
| checklist items for quality and engineering practices.
| Devops keeps pushing things like observability and
| standardization through complex things like service mesh
| which creates all of its own problems.
| motorest wrote:
| > 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.)
|
| 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?
| Kinrany wrote:
| This sounds like the team is straightforwardly too big for
| the task. Especially the EM and the staff, lead and senior
| engineers all wanting the same one thing of a certain scope
| when they should be working at two different levels at a
| minimum
| mihaaly wrote:
| > 'modern team structures'
|
| 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.
| safety1st wrote:
| If you were the benevolent dictator of a small engineering
| with no stakeholders to answer to how would you fix this? How
| would you make ownership all the way to prod a reality and
| who would the owner be?
| julik wrote:
| There should not necessarily be an owner, but a responsible
| individual - which would then be "you", the benevolent
| dictator. Ownership "in and of itself" creates incentives
| to gatekeep.
| safety1st wrote:
| Why did I hire these people if I cannot delegate
| responsibility to them?
| julik wrote:
| This is what makes creating these performing structures so
| hard - once the incentives to "show ownership to demonstrate
| performance and get promoted" is permitted in the
| organization, people have to "play to stay at the table" and
| the actual necessary work ethic gets displaced. There should
| be a clear realisation that creating a moral maze is a taboo,
| and it is very hard for leaders to stick to that throughout
| the growth of an org.
| HL33tibCe7 wrote:
| > one staff engineer, one or more lead engineers
|
| An engineer isn't really a "lead" if there are multiple, or
| if they are outranked by a "staff engineer".
| layer8 wrote:
| * Separate bullet points by blank lines on HN. ;)
| spuds wrote:
| Yeah, I'm facepalming on that one. Thanks!
| tayo42 wrote:
| > 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
|
| 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
| spuds wrote:
| Yeah. And all the time spent on those 100 half baked ideas
| take away from time that could be spent working on the most
| likely cause of the next outage. (Real forward-looking risk
| reduction work.)
| agumonkey wrote:
| talking about ownership, I ran into some git repo with a
| "declaration of non ownership"
|
| an economy of giving in a way
| aylmao wrote:
| Recently, I was thinking plenty about trust within
| organizations, and it resonated with me too.
|
| 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
| spuds wrote:
| Yeah, I think there's almost always a point where a company
| decides they need to stop generally trusting their employees.
| Then all the trustworthy ones start getting more and more
| frustrated, or just start checking out. Agreed that most
| startups lean towards trust. Need to keep that going as long
| as possible, and stay away from hiring managers who think
| their primary job is "protecting" the company from anyone who
| might make a mistake.
| aylmao wrote:
| > Need to keep that going as long as possible, and stay
| away from hiring managers who think their primary job is
| "protecting" the company from anyone who might make a
| mistake.
|
| 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.
| RHSman2 wrote:
| This. This is what 'higher' ups should be aiming for. I
| try and do it with all my attention. The good fight.
| geophile wrote:
| Yes, and at the same time, companies start hiring employees
| that shouldn't be trusted.
|
| 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).
| tbrownaw wrote:
| > _Yeah, I think there 's almost always a point where a
| company decides they need to stop generally trusting their
| employees. Then all the trustworthy ones start getting more
| and more frustrated, or just start checking out._
|
| $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.
| kridsdale1 wrote:
| > there's almost always a point where a company decides
| they need to stop generally trusting their employees
|
| I recall exactly when this happened at Facebook.
| Aloisius wrote:
| _> Require ownership all the way to prod and beyond, no matter
| the role. (Turns out people tend to really like that.)_
|
| 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.
| T-Winsnes wrote:
| I think the right balance here is to have ownership of the
| outcome rather than the thing. E.g. you have ownership of
| making sure the feature you're working on makes it to
| production and works properly
|
| 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
| Aeolun wrote:
| Ownership to 'make sure it happens' is entirely different
| from being able to 'make' it happen. The first is
| absolutely toxic.
| motorest wrote:
| > * 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.
|
| 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.
| khafra wrote:
| The context of "stop making reactive decisions" isn't "start
| making proactive decisions." It's to just make fewer
| decisions.
|
| The specific example is of a rare event which, while
| regrettable, does not justify the cost of policy changes to
| prevent it.
| motorest wrote:
| > The context of "stop making reactive decisions" isn't
| "start making proactive decisions." It's to just make fewer
| decisions.
|
| You don't get the luxury of not making decisions. You
| always have to make decisions.
| khafra wrote:
| If you do not consider the problem at all, you have not
| made a decision on it; any more than you have to make a
| decision about, say, the most aesthetically pleasing
| perspective of Olympus Mons for prospective Martian
| colonists.
|
| 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.
| miki123211 wrote:
| > * 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.
|
| 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.
| lysecret wrote:
| Yea Germany quitting all nuclear comes to mind...
| Timwi wrote:
| I thought of that too, but also the US banning Kinder
| Surprise eggs.
| yard2010 wrote:
| Bad example in my honest opinion: Merkel made me believe
| it's the "worst case scenario" kind of thing - same reason
| there shouldn't be capital punishment. If you can't afford
| to pay the price in the worst case scenario you shouldn't
| take the risk.
|
| 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.
| kookamamie wrote:
| > Require ownership all the way to prod and beyond
|
| 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.
| Lanolderen wrote:
| Redundancy is honestly a good thing. Some smaller companies
| not in IT have their entire software/hardware infrastucture
| dependant on a single person who's been there for 20 years
| and it's objectively dangerous.
|
| 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.
| mihaaly wrote:
| Excellent points!
|
| I wonder why these almost never considered.
| wkrsz wrote:
| > Resist the urge to build walls between
| people/teams/departments
|
| 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".
| 9rx wrote:
| In fairness, it seems the problem in your case is that the
| "manager" has built up walls between people, trying to own
| the work, and in that not allowing you the full context that
| would allow you to make informed decisions around such asks.
| "The manager not wanting you to spend time debugging this
| now" should be a false premise. Knock down the walls and you
| will know yourself that you shouldn't spend time debugging it
| now.
| theropost wrote:
| I completely agree. I've had the privilege of working with a
| very small team of engineers--a team with diverse life
| experiences and unique areas of expertise but a shared work
| ethic: the willingness to try. We always said that most of our
| time was spent failing, and that's what made the moments of
| success so rewarding. When we finally succeeded, it wasn't just
| about the victory; it was the culmination of relentless effort
| that allowed us to push forward, improve our product, and
| refine our ideas.
|
| 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.
| RHSman2 wrote:
| I think there are ways of philosophy not process. And the
| philosophy has to be agile to those in it.
| kazinator wrote:
| The Process Person who wants to build a Mature software
| organization will say, process is seriously needed.
| kubanczyk wrote:
| That dork can only become factory manager when there are
| factory workers, see? "Process" is just a word for a
| production line of some kind - narrower or broader, but still
| a life-sucking endeavor.
| steelframe wrote:
| > 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.
|
| This is a central theme in Bruce Schneier's 2003 book Beyond
| Fear, which I continue to recommend 20 years after I first read
| it.
| harshaw wrote:
| 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 wrote:
| Well that shows my age, I thought twisted was being used as an
| adjective.
| sethammons wrote:
| Twisted was aptly named. It was the only async python we used
| around that same time. We moved to Go. It was glorious.
| webdevver wrote:
| good guide for allowing everyone to walk all over you
| majormajor wrote:
| 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 wrote:
| 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 wrote:
| Work is not a zero sum game, sometimes, everyone can win.
| awesome_dude wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| Nevermark wrote:
| > 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
|
| 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.
| MrMcCall wrote:
| There is no mismatch, friend. "Pulling others in", as you
| put it, requires two ends of the leveling-up: first, the
| initiate explains how to begin the self-evolution, and
| second, the newcomer accepts the challenge and begins
| their own path to self-evolution.
|
| 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.
| Nevermark wrote:
| Thanks for the rebuttle.
|
| 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.
| MrMcCall wrote:
| Well said, my friend. Thank you very much.
|
| 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.
| tbrownaw wrote:
| > _The success of any organization depends upon each member
| behaving selflessly to meet the needs of the group._
|
| 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.
| MrMcCall wrote:
| > A well-designed system will align individual self-interest
| with what's beneficial collectively.
|
| 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.
| mattcaldwell wrote:
| Lots of people in the comments exemplifying why I would never
| want to work with them.
| lijok wrote:
| 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 wrote:
| I'm saying the opposite. There are several comments that
| demonstrate an insecure "dog eat dog" mentality.
| instalabs wrote:
| > 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 wrote:
| 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 wrote:
| Where was the Musk bashing? I didn't see that in the slides.
| simonw wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Dansvidania wrote:
| I honestly did not notice the Musk bashing, but yeah, now that
| you mention it, I agree.
|
| Still 1 bad paragraph (or picture in this case) does not
| nullify 99 good ones.
| srid wrote:
| The fact that they so readily call Musk as being "narcissistic"
| (or "asshole" or "cult leader") reveals the rather dark nature
| of these "egoless" souls.
|
| 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.
| vitaminCPP wrote:
| Is there a video of the talk somewhere ?
|
| I prefer recording over slides.
| mcfunley wrote:
| Unfortunately no, I've only done it as a private event within a
| company so far.
| nvartolomei wrote:
| How does something like this scale for more than 10 people? 100?
| 1000?
| awesome_dude wrote:
| This is the problem all medium to large businesses face - red
| tape, faceless bureaucracy overloads the system
|
| Every. Damned. Time.
| aylmao wrote:
| fwiw, Etsy seems to have ~2.5k employees [1].
|
| [1] https://en.wikipedia.org/wiki/Etsy
| jakevoytko wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| n4r9 wrote:
| What is the wisdom, in your opinion?
|
| 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.
| dpc_01234 wrote:
| Lean and focused execution, quick iteration, over promise and
| under deliver (yes, in business it pays as much as engineers
| hate it), most people are actually a drag to productivity.
| Specifically with Twitter he drastically cut the head count
| and cost and all the people swearing how irreplaceable people
| being fired were and his Twitter is going to collapse any
| minute now were all wrong.
|
| Unlike most people praising the idea of egoless I don't need
| to like the guy to learn from him.
| aylmao wrote:
| Musk aside, I personally don't think Twitter is working better
| than before.
|
| 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.
| smitelli wrote:
| Separate from Twitter the company and Twitter the app, there
| is Twitter the community. That is absolutely dead, rotting,
| and never coming back to what it once was.
| beepbooptheory wrote:
| Do we really have to do this? How can this possibly be in good
| faith? Like, its 2024 dude, he is literally going to hold
| unelected office in the US. He is unquestionably a polarizing
| person. I'm not saying you have to have one opinion or another,
| but unless you are truly living on mars right now, how can you
| even feel the need to make this comment? Are you not witness
| already to the surely GBs of text saying different variations
| of what you said and all the replies and all the next replies.
| Like it is borderline insane to me!
|
| 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?
| sfink wrote:
| It was illustrating narcissistic personality disorder. Debating
| whether or not Musk delivers, or what personality traits might
| be behind delivering or not, is irrelevant to whether or not
| Musk illustrates NPD. It is easy to find examples of his
| behavior that matches [a layman's understanding of] NPD, so it
| seems fair.
|
| Saying that Musk's personality resembles NPD doesn't say
| whether he is or is not effective at some tasks.
| dpc_01234 wrote:
| It has nothing to do with the rest of generally good article.
| It's just a forced personal stab at disliked public figure.
| Ironically quite the opposite of egoless. Your politics are a
| big chunk of your ego. If you can't leave them aside and when
| dealing with technical stuff, then it's very much egocentric.
| Which surprise surprise is typically the case.
| threeseed wrote:
| > despite all the doomsayers Twitter is still working and IMO
| better than before
|
| 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.
| psunavy03 wrote:
| 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 wrote:
| 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.
| 0xbadcafebee wrote:
| _" 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I'm sure it's factual and common, but it's tone-deaf
| given the slide deck title.
| pjmorris wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| pphysch wrote:
| There's a manifest difference between people who are
| naturally humble+curious, and people who are idealistically
| seeking an "egoless" environment. The latter is what I am
| referring to.
|
| 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.
| aylmao wrote:
| I can agree that there's people who preach tolerance but
| don't actually seem to mean it, yeah. Have yet to see
| egotistical egoless-ness, but I'd suppose it'd just look
| like empty speech in a smilier fashion.
| bithive123 wrote:
| How predictable the ego's self-defensive reactions are.
| Merely encountering the suggestion that the ego is a
| necessary servant but a terrible master and it yelps "I'm not
| an egotist, you're the egotist!"
| bulatb wrote:
| There's a complex of these passengers you can't discuss
| because it wakes them up and they reflexively defend
| themselves. They wrap themselves around your sense of truth
| and it's impossible to get them out.
|
| Sleep tight. :)
| MrMcCall wrote:
| We each have the free will to choose willful ignorance
| over humble learning.
|
| 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.
| pphysch wrote:
| Which character is this referring to?
| weitendorf wrote:
| People may bring ego into programming because of some kind of
| pathology (eg the need to always be right or in control) but I
| think in many cases it's because they truly care about the
| work. And the problem is not that they truly care, but that
| there is a mismatch between the amount of
| influence/control/autonomy they wish to exert on their work and
| the amount they are actually able to exert on it.
|
| 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).
| MichaelZuo wrote:
| Well the 'pathology' is clear, isn't it?
|
| 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.
| dasil003 wrote:
| I think FOSS really only works well for infrastructure type
| of projects, things where the customers are downstream
| programmers or at the very least very technical sysadmin
| types and power users who can understand the gory details
| to some reasonable depth. Those projects work because they
| are centered around proven abstractions that are broadly
| applicable, thus allowing for a tight charter and some
| stability in requirements.
|
| 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.
| 01100011 wrote:
| Sometimes a person's dedication and care expresses itself to
| others as ego. Sometimes it is just ego.
|
| 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.
| weitendorf wrote:
| The problem with "ego" as a concept IMO is that it carries
| negative connotations with most people and isn't exactly
| well-defined - some people might see it as always a bad
| thing (I think you might fall into this camp given that
| your phrasing "dedication and care expresses itself to
| others as ego" rather than saying it merely is ego).
| Personally I think that that _is_ ego, but that ego is not
| necessarily a bad thing.
|
| 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.
| dasil003 wrote:
| I would argue that in fact you do need a critical mass of
| ego throughout the ranks of engineers in a large
| organization. An engineering culture where engineers
| don't care inevitably leads to abdicating responsibility
| for overall system health and even data/workflow
| correctness as PMs attempt to steer the ship without
| understanding the implications of what they are asking
| for. Once this has gone on for a while, the system will
| be so intractably broken, and the dead sea effect will
| have caused such a brain drain of all those capable of
| fixing the problems, that at some point there's no
| economical path to restoring the software systems to a
| healthy and maintainable state. At that point you might
| as well just call in the private equity guys and figure
| out how to extract maximum cash out of the business as it
| stands, because any code change becomes more likely to
| break more things than it improves.
|
| 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.
| bruce511 wrote:
| Agreed.
|
| 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]
| MrMcCall wrote:
| The ego is, indeed, referred to in a negative sense
| because most people do not sublimate it to serve the
| group. It's natural state -- and, therefore, our natural
| state -- is to be selfish to oneself and one's in-group.
|
| 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.
| Aloisius wrote:
| Huh. I thought it was thought of negatively because
| people confuse the word ego (self) with egotism/conceit
| (exaggerated sense of self-importance).
|
| 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.
| MrMcCall wrote:
| Selflessness merely means understanding that selfless
| service to others' happiness is a fundamental element of
| the spiritual path. We do not have to love them _more_
| than ourself, just equal, but we must take the chances we
| get to serve their happiness as much as possible.
|
| 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.
| RHSman2 wrote:
| How very well put.
| romanows wrote:
| Check out Hackers, by Steven Levy, for some fun tales from
| early in computing.
| smitelli wrote:
| I've noticed that some of the worst ego-related issues arise
| from people who care the most about their work -- the
| craftspeople, if you will. There is a type of person who will
| pour their entire soul into creating the most ideal expression
| of whatever it is they are trying to do. Sometimes that level
| of investment is warranted and even required. But mixed
| together with others who don't -- or _can 't_ -- operate that
| way, that's what leads to trouble.
|
| 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?
| MrMcCall wrote:
| Our expertise in any kind of technical skill that allows us
| to participate in society is of no importance compared to our
| becoming a positive member of all the societies/cultures we
| encounter. This requires becoming a compassionate, empathetic
| human being via deliberate, honest, self-critical work on the
| areas of our personality that cause unhappiness to others via
| selfish negativity.
|
| 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.
| ulyssesv wrote:
| wow, thanks for this.
| thundergolfer wrote:
| A read that book a couple years ago and thought it wasn't very
| good, probably the worst of the "classic" 20th century texts.
| The Psychology of engineering is underrated though and someone
| should really write a new book on it.
| tbrownaw wrote:
| It's also terribly ill-defined.
| srid wrote:
| The last paragraph is the interesting one, and here's the full
| quote in context: 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.
| yieldcrv wrote:
| I actually like how the standing committee are the best
| capitalists of them all
|
| 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"
| xyzzy4747 wrote:
| One of the reasons Communism failed was because of
| incentives. People were not rewarded with more compensation
| for working harder.
| robswc wrote:
| I know its getting off topic but I never understood why
| people seemingly couldn't accept that.
|
| Current systems don't have a 1:1 with "hard work" and
| success/comp but its about as close as you can get, IMO.
| Aeolun wrote:
| It's fine if _everyone_ gets the same. It's not fine if
| some people are more equal than others.
|
| Actually, no, it's still not fine, because whole heaps of
| people will pretend to be unable to do much.
| DrScientist wrote:
| When you mean incentives - do you mean the threat of
| starvation or the promise of a glittering palace?
|
| 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.
| bluecheese452 wrote:
| Did it fail though? China is doing pretty well and by most
| metrics Russia is doing worse post communism.
| mikrl wrote:
| >People were not rewarded with more compensation for
| working harder.
|
| Nit: they had worker's medals and similar non financial
| recognition.
|
| However yes, the price paid for labour was far below the
| point to ensure supply met the demands of economic
| development.
| MrMcCall wrote:
| The failure in this paragraph is that our highest and most
| important ability as human beings is to self-evolve ourselves
| out of our selfish ego into its selfless version.
|
| 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.
| oscillonoscope wrote:
| I'm not entirely convinced that ego-less is even a better way
| of doing things. Sure, the ego can go overboard but it also
| gives a sense of drive and direction. It isn't just the bad
| stuff. Without it, there's nobody taking ownership of the
| design or it's just designed by an apathetic committee.
| itishappy wrote:
| Pride and passion can exist without ego. I view this as
| appreciating things for what they are, not who they belong
| to.
| MrMcCall wrote:
| Yes, and not thinking that one is better than anyone else.
| We are all equal, no matter how much better we are than
| another, with respect to either some job skill or even the
| spiritual path. Dunning-Kruger's true-experts _are_ better
| than the slackers, but we must be humble to achieve that
| and then not be an ahole about our achievements.
|
| It's a tricky business, being a human being, with its very
| many pitfalls.
| worksonmymach wrote:
| Taking ownership is very much egoless! You are doing that for
| the team.
|
| 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.
| kookamamie wrote:
| You can never remove ego from the equation, completely.
| People are placed on different levels of organizations, with
| different incentives and agendas.
|
| 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.
| JKCalhoun wrote:
| Ego loss comes from experience, age. Hopefully.
| MrMcCall wrote:
| It is always our choice, each of us. If we want to become
| better, we can be, and will, if we ask for the right kind of
| help. If we don't give a sh_t, we will just continue being a
| selfish ahole. And remember that a person's religiosity has
| no bearing on this outcome; the truth resides in our heart's
| intentions and our ideals, attitudes, and behaviors towards
| others, where the rubber hits the road.
|
| 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.
| waiquoo wrote:
| What I have been thinking a lot about lately is that the focus
| should not be on the work. The focus should be on the handoff.
| If you build something, the goal is to have someone else use
| it. The work should focus on easing that transition. If it's a
| technology, what do you need to characterize so that the
| product people can work with it? If it's a product, how do you
| make it easy for your customers to get it? If it's an internal
| tool, what context and familiarity does the user group have?
| kubanczyk wrote:
| My humble experience is different. There is no surer way to
| create shitty, incoherent code, flaky tests, architecture
| mistakes, and Rube Goldberg machines, than when trying to
| satisfy various people in your org.
|
| Junior stays a junior in my book until they learn to "satisfy
| code" or to bring elegance instead of primarily satisfying
| specific people.
|
| If Henry Ford was listening to customers, he would start
| breeding a faster horse. That perfectly shows that ego can have
| a good side.
|
| Re ego, I think maybe the vocabulary choice is misaligned here.
| Anyway, these days, "team player" is becoming a sarcastic
| innuendo.
| jeromechoo wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Glad that one landed, thanks!
| zdw wrote:
| 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 wrote:
| 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 wrote:
| I like the idea but it's something that must be implemented from
| the top.
| thanksgiving wrote:
| 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 wrote:
| > _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 wrote:
| > 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 wrote:
| 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.
| sethammons wrote:
| I left a role because we owned it as a team, and as a lead on
| the team, I opted to take the shit work, so I found myself in
| yaml hell, configuring and tweaking configs in ever cryptic
| error messages. I was there to code and design efficient
| systems. Yaml sucked. Eventually, I left. We should have
| brought on someone who likes that shit.
| RobRivera wrote:
| I always check the ego at the door, but have a high threshold for
| persuasion if I've done due diligence.
| MrLeap wrote:
| 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 wrote:
| 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.
| shusson wrote:
| 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 wrote:
| "They get up to building entire GraphQL monstrosities to avoid
| talking to each other."
|
| I feel seen
| sethammons wrote:
| 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 wrote:
| 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 wrote:
| On the other hand, people can't possibly talk to each other if
| they are always in a meeting.
| fullstackwife wrote:
| Why I don't hear such discussions coming out of other engineering
| fields? Is this type of hamletization specific to software
| engineering?
| deadbabe wrote:
| 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 wrote:
| 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.
| weitendorf wrote:
| 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 wrote:
| 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.
| solatic wrote:
| > 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.
|
| 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.
| evantbyrne wrote:
| Yeah you really can't go this hands-off on deployments when the
| stakes are high. If someone could be physically harmed by bad
| code, then it all needs to be reviewed. If you can be hacked by
| a rouge deployment, then it all needs to be reviewed.
|
| 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.
| dmead wrote:
| This is impossible without egoless software engineering managers.
| default-kramer wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| How does giving them deploy access prevent them from breaking
| the build, too?
| smag wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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
| choonway wrote:
| 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 wrote:
| 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.
| luxuryballs wrote:
| 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 wrote:
| Deliver fast! Always at the worst times.
| farmeroy wrote:
| 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 wrote:
| 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.
| TacticalCoder wrote:
| 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
|
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| kubanczyk wrote:
| Chapters 4 and 5 of "Crucial Conversations" were an
| enlightenment for me, as full of cringe as it is.
|
| Their hypothesis (intuitive, no science there) is that fear has
| second side beyond passiveness, wall-building and
| procrastination.
|
| Fight or flight: people attack mostly out of fear. People
| micro-manage employees mostly out of fear. At work you don't
| think much about this aspect, as boss is simply a "jerk". (Bad
| mouthing, yet another way to deal with fear.)
| didibus wrote:
| 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 wrote:
| > 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 wrote:
| > 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.
| lll-o-lll wrote:
| It's been a while since I read it, but I thought the "actual"
| rule as articulated was. "Adding people increases
| communication overhead. _At a certain point_ , more people
| cannot increase speed but actually makes things slower".
|
| 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).
| BerislavLopac wrote:
| Fred Brooks never said that adding more developers does not
| help -- he was stating that solving the _single problem of
| being late_ will only be exacerbated by adding more people.
|
| 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.
| sublinear wrote:
| That these levers are the tool instead of mentoring and
| validating plans is an extremely strong signal these people
| should not be managing engineers.
|
| > Engineers have this lever of "technical ingenuity".
|
| LMAO this is not merely a lever. This is why you hired
| engineers.
| BerislavLopac wrote:
| I believe that the GP's point was that different roles have
| different tools in the box that are more efficient in their
| particular areas, and tend to rely on these rules even when
| solving problems in other areas.
|
| 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).
| noam_k wrote:
| I heard this phrase in college and it stuck: "when all you have
| in your toolbox is a hammer, every problem looks like a nail".
| jacobsenscott wrote:
| The main thing a good manager can do is act as a wall between
| the engineers and everyone above them, which is hard to do
| politically because it exposes a whole subtree of the org chart
| as useless.
| Aeolun wrote:
| 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 wrote:
| you fire them
| alkonaut wrote:
| 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.
| jamil7 wrote:
| 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 wrote:
| 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.
| thaneross wrote:
| If it's clear someone is not acting in good faith, I can think
| of three options:
|
| 1. Find out why and try to fix it
|
| 2. Fire them
|
| 3. Embrace the low-trust environment by trying to mitigate the
| dysfunction with layers of bureaucracy
|
| Strategy 3 seems quite popular, and to be fair it might be the
| only one that scales.
| euroderf wrote:
| 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 wrote:
| 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
| thisOtterBeGood wrote:
| Those Galadriel memes had me in tears :')
| locallost wrote:
| 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 wrote:
| There's an old rachelbythebay post that's relevant here:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "Like many of you, I was raised in the background radiation of
| Calivinist thought"
|
| Sorry -- you lost me in the first sentence.
| iterance wrote:
| 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
| mrweasel wrote:
| 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.
| zJayv wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I don't think engineers (especially non-managers) talk or write
| nearly enough about personality dynamics at the workplace.
| Conscat wrote:
| > 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?
___________________________________________________________________
(page generated 2024-12-04 23:01 UTC)