6 ms·

> Every time you see collaboration happening, speak up and destroy it. Say “there are too many people involved. X, you are the driver, you decide.” (This is a g

• kykat 11mo ago
  At my previous job, "what about..." slowly became a trigger word for me EDIT: In the context of infinite pixel tweaking, layout tweaking, and of course, new features that would require significant full stack rework
  • hinkley 11mo ago
    The four worst words on a software project are: “Why can’t you just…”
    • fullofideas 11mo ago
      Closely followed by “This should be an easy lift”
      • Aperocky 11mo ago
        I mutter this a lot. Except when I do 95% of the time I perform the easy lift right after.
        • rdtsc 11mo ago
          That’s the only way I would utter it — if I can then sit down and so do it. If I am asking someone else to do I would ask them to tell me how hard it would be and if they need help or if they suggest a different approach.
      • neilv 11mo ago
        "Delivering this feature goes against everything I know to be right and true. And I will sooner lay you into this barren earth, than entertain your folly for a moment longer." -- Krazam, "Microservices", https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
  • marcusb 11mo ago
    I once worked at a place where one of the partners consistently claimed the engineering team over-built and over-thought everything (reality: almost everything was under-engineered and hanging on by a thread.) His catch phrase was "all you gotta do is [insert dumb idea here.]" It was anxiety inducing for a while, then it turned into a big joke amongst the engineering staff, where we would compete to come up with the most ridiculous "all you gotta do is ..." idea.
    • 0x457 11mo ago
      Have WE tried using caching?
  • theideaofcoffee 11mo ago
    Similar to my experience doing low-level systems work, being prodded by a "manager" with a fifth of my experience. No, I'm not going to implement something you heard about from a candidate in an interview, an individual whom we passed on within the first 30 minutes. No, you reading out the AI overview of a google search to me for a problem that I've thought about for days ain't gonna work, nor will it get us closer to a solution. Get the fuck out of the way. "Can't we just..."
  • CBLT 11mo ago
    I'm there right now at my current job. It's always the same engineer, and they always get a pass because (for some reason) they don't have to do design reviews for anything they do, but they go concern-troll everyone else's designs. Last week, after 3 near-misses that would have brought down our service for hours if not days from a corner this engineer cut, I chaired a meeting to decide how we were going to improve this particular component. This engineer got invited, and spent thr entire allocated meeting time spreading FUD about all the options we gathered. Management decided on inaction.
    • asa400 11mo ago
      People think management sucks at hiring good talent (which is sometimes true, but I have worked with some truly incredible people), but one of the most consistent and costly mistakes I’ve observed over my career has been management's poor ability to identify and fire nuisance employees. I don’t mean people who “aren't rockstars” or people for whom some things take too long, or people who get things wrong occasionally (we all do). I mean people who, like you describe, systemically undermine the rest of the team’s work. I’ve been on teams where a single person managed to derail an entire team’s delivery for the better part of a year, despite the rest of the team screaming at management that this person was taking huge shortcuts, trying to undermine other people’s designs in bad faith, bypassing agreed-upon practices and rules and then lying about it, pushing stuff to production without understanding it, etc. Management continued to deflect and defer until the team lead and another senior engineer ragequit over management’s inaction and we missed multiple deadlines at which point they started to realize we weren’t just making this up for fun.
• bfkwlfkjf 11mo ago
  I just gave this feedback to my boss today
• tombert 11mo ago
  One of many reasons I left Apple. My manager's manager would say stuff like this all the time, and then when I actually made my PR he would basically have me redesign stuff from scratch. It made me dread working on projects because I knew that no matter what I did I would be forced to rewrite it from scratch anyway.
  • AceJohnny2 11mo ago
    One of the many reasons I'm still at Apple. My manager honors my decisions (sometimes, let's be honest, with gritted teeth). ("People don't leave jobs, they leave managers")
    • JKCalhoun 11mo ago
      Yep. There are many, many teams at Apple. Your manager makes all the difference in the world. Hated working on the Photos team at Apple, loved all the other teams I worked on. (So I left the Photos team to go work on a team where the manager was cool. I was able to stay at Apple, just move about.)
      • tombert 11mo ago
        I don't dispute that. I wish I had been on a better team. My team had a famously high turnover rate, so it wasn't just me. I liked my direct manager just fine, he's a decent dude, but I thought his manager, who I had to deal with a lot, was kind of a dumbass and I did not enjoy working with him at all. I tried joining other teams but without going into elaborate detail it didn't pan out.
    • IshKebab 11mo ago
      I normally move within a company when I want to quit a manager. It's much easier than getting an entirely new job usually. And you have a lot more information about the potential role. It's also a good way to get into areas you have no experience of.
      • tombert 11mo ago
• jstummbillig 11mo ago
  > This is a great way to lose employees. A great way, you say. Taking notes!
• hinkley 11mo ago
  There are worse outcomes than that. Software devs are clever people. Not all of us can be confrontational, and confrontation is not the only tool available to those who can. If you as a boss find yourself to be very busy all of a sudden, it is likely because you have pissed off and alienated your reports by questioning and overriding their judgment too many times. Suddenly the team needs your “help” to make every decision, and every bad outcome of those decisions suddenly becomes a surprise to them. They’re letting you choke to death on your own arrogance and control issues.
  • ninetyninenine 11mo ago
    Software devs also all think they're smart and they talk that way and take pride in it. The reality is many software devs are dumb af.
    • binary132 11mo ago
      “trust nobody, not even yourself” applies here for sure.
    • hinkley 11mo ago
      We are by and large hired for cleverness, so there’s a lot of selection that makes that true even if undergrads are not far off from average. It would be better if we were hired for wisdom. Don’t confuse cleverness and foolishness. You can be both. But devs aren’t usually the ones treating their reports like children and then acting surprised when their prophecies become self fulfilling. You can blame Taylor for that.
      • appreciatorBus 11mo ago
        Developers may be hired for cleverness, but cleverness in code and technical matters does not necessarily carry over into cleverness with respect to office politics or good management.
        • hinkley 11mo ago
• ergocoder 11mo ago
  The equivalent of "I told you so". Yeah, you should never do that in any situation.
• petralithic 11mo ago
  Exactly, these two sentences seem at first related, > No deadlines, minimal coordination, and no managers telling you what to do. > In return, we ask for extraordinarily high ownership and the ability to get a lot done by yourself. but can be insidious if implemented incorrectly. High ownership to do what you want, but what happens if what you decide goes against the goals of the manager or the company itself? No company can succeed without at least some sort of overarching goal structure, from which employees will naturally avail and seek to benefit themselves.
  • wordpad 11mo ago
    I think if you are empowered to make decisions as an employee it's YOUR responsibility to know the limitations of your scope and when to seek feedback and approvals from architecture, management, business or whoever. So if your decisions are getting turned over, you are either making decisions outside of your scope or your management is genuinely micromanaging you.
• nojs 11mo ago
  If you don’t collaborate before it’s shipped and don’t retroactively review after it’s shipped, how do you provide input?
  • kevmo314 11mo ago
    You iterate on what’s shipped. It’s not a one-and-done kind of deal.
    • dragonwriter 11mo ago
      Iterating on what has shipped inherently involves review of what has shipped.
• dragonwriter 11mo ago
  I'm not sure that's a corollary, it seems to have tension with "Prefer to give feedback after something has shipped (but before the next iteration) rather than reviewing it before it ships. Front-loading your feedback can turn it into a quasi-approval process." Though I guess it is in tune with "no managers telling you what to do."
• tossandthrow 11mo ago
  "it's your call" does not mean there are no requirements. On my team it is always people's own call, but they also need to be critical thinkers and call for the right thing. If a manager, denotationally, can call out that there is something missing, then it was not implemented right.
  • enraged_camel 11mo ago
    “It’s your call” specifically means all the decisions on the table are valid and fit the requirements and the employee is being granted permission to make a judgment call. Questioning that judgment call afterwards is shitty and leads to an erosion of trust because the employee will thereon second guess themselves and also try to avoid making any decisions (because they expect them to be overridden).
    • jsiepkes 11mo ago
      > and fit the requirements And that is where the friction is. A lot of these requirements are implicit. For example; If an application is built around Protobuf / gRPC and you suddenly start doing JSON / REST you are going to need a really, really good reason for that. Since you are introducing a new technology, with all it's glory and all it's horror. So your judgment is going to be questioned on that and most likely the reaction will be; We are not going to do that.
• 6510 11mo ago
  If you know they are going to be like that you could try getting the information out of them as early as possible. Ask a bit to much about every detail, find the point where it annoys them then try not to cross it. When you inevitably do remind him of the previous rewrites and the time it consumed. It is our job to perfect this system. It gets considerably harder to request changes after you've asked not to be bothered with every detail. That said, I will never work for a company unless I get to make all of the decisions, write all of the code and do all of the maintenance. The work one person can get done cowboy coding a pile of spaghetti is mind blowing. Cleaning up the mess later is so much easier and so satisfying if it was your own making. Until recently this was a bad formula as it makes for a terrible bus factor but now that we have LLMs it suddenly seems entirely reasonable.