3 ms·

This is a horrible website and you will likely experience diminished tenure if you follow it's advice. First, there is a complete lack of empathy for the perso

• mbrodersen 6y ago
  Go around might be the only option available to you if you don’t want to quit your job. I have been lucky enough to experience only a few difficult co-workers in my career but a few of them were toxic beyond belief. And not even “rationally toxic” as in doing it to further their own interests (they would regularly sabotage themselves on top of sabotaging everybody else).
• awillen 6y ago
  Seriously - the "Patent Author" PM may well have come to be that ways because if he doesn't, the engineering team just makes assumptions (that are wrong) and build the wrong thing, instead of checking with the PM. When I've worked with dev teams in India (with me in CA), I have written extremely detailed and specific product specs, because I'm asleep while they're working, so if something is unclear it can waste a whole day of a dev's time.
  • deleted 6y ago
    [deleted]
  • lobstrosity420 6y ago
    The article on Patent Author does mention as one of the exceptions exaclty that - working with teams on different time zones may require a Patent Author attitude. However, I do have to agree with the original comment in this chain, that website is filled with bad advice and slightly sociopathic in nature.
• yowlingcat 6y ago
  Can't agree more. Everything from the framing of the problems, to the solutions, to the model of how things work (and how they ought to be fixed) go directly against anything that has ever worked in my experience.
• bri3d 6y ago
  Fully agreed. Amusingly, every single archetype in the "manager" section of this site contains advice which runs exactly counter to the advice from the also highly-upvoted "Common Mistakes of New Engineering Managers" article currently on the HN home page. This just goes to show the extent to which our industry is still very "unsolved" and contains a multitude of often completely-opposed opinions - which means that reducing these opinions and the people who hold them to labels and suggesting they be "solved" is patently ridiculous.
  • tehjoker 6y ago
    Management has been around since ancient times in various forms. There are things that kinda work, but the game keeps changing as the interests and balances of power shift in the workplace. Why would it ever be "solved"?
    • bri3d 6y ago
      It wouldn't! - which is pretty much the point I was trying to make about generalization and stereotypes, although I do think there are fewer "generally accepted best practices" in this industry than in most.
  • Joeri 6y ago
    But that’s just because managing software development is about managing people, and the behavior of people can’t be captured by logical rules. In other words, I doubt that there is something that can or even should be solved here. I think this quote says it best: “The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function.”
    • bri3d 6y ago
      I feel like between this and the sibling comment my point was misunderstood - to clarify, I wasn't trying to say "our industry is unsolved but should be solved," rather, "there is no 'solve' for these sorts of things which aren't even 'problems' so much as difference of opinion, even outside of the technology industry, and within the technology industry there is an even greater breadth of opinion around product and project scheduling and management" - so, the linked article is triply ridiculous.
• rdtwo 6y ago
  Go around is a valid strategy, eventually your entire team will go around the difficult person and the difficult person will no longer be part of the solution chain essentially relegated to obscurity. Works in big teams with sufficient overlap not in small ones
  • Seirdy 6y ago
    Soft agree. Going around people isn't always as borderline-sociopathic as people in this thread make it out to be. For example, the given solution for handling the process-obsessed is surprisingly non-toxic: encourage them to favor incremental change to give them the time to learn and grow their strats enough to come up with something that's tailored to the team.
  • TameAntelope 6y ago
    I literally don't know how else to deal with certain categories of folks with whom talking and trying to resolve the issue has no effect. Going around them/ignoring them is literally the advice you get from basically every literature I've read, and I've read a lot about this. But you do have to try to work through the issue first, and you have to be willing to try again if they seem open to resolving the problem down the line. Never write someone off completely (for professional disagreements).
    • NotPavlovsDog 6y ago
      What would you suggest from your readings? I've mostly benefited from hard realism approach and Actor theory (as applied by some: everyone has an agenda, to work with them: Align, make Peace, or Destroy).
      • cosmodisk 6y ago
        This seems to be working best for me so far.
      • TameAntelope 6y ago
        It's actually a bit of a gap -- everything I've read tries very hard to assume positive intent; people will cooperate if you can create a sense within them that they can express themselves without fear of reprisal or judgement. The reasoning in the literature for avoiding this topic is sound. If you provide the "destroy" option to folks, they're usually going to go with that pretty quickly, and only nominally go for the other methods of resolving conflict. I've had someone make that determination about me at a previous role, which then put me obviously in a "what do I do with this person?" position which itself led me to the "ignore/destroy" answer. If it hadn't been an option, would this person and I have had a more pleasant working environment?
• defen 6y ago
  I think there's a kernel of usefulness here, as long as you keep in mind that the labels don't inhere in the person, but rather refer to behavior and are relative to their current role. Developers love to systematize so it's easy to forget that people don't really fall into neatly labelled categories like this. A "downtrodden" QA person could become uptrodden on a different team. Having a "patent author" PM is probably a good thing if you're working on life-critical software. Even an "incompetent" developer can learn to become better, or might be better suited to some other project. I'm decent at embedded development but if you put me on a deep learning task I'd be incompetent initially.
• bartread 6y ago
  > This is a horrible website and you will likely experience diminished tenure if you follow it's advice. I'm pretty sure it's supposed to be at least somewhat humorous/tongue in cheek. I can certainly recognise the tropes both in myself and in others. It's just kind of fun, and I'm certainly not planning to take any of its advice that seriously.
  • forty 6y ago
    I'm baffled that some people might think this is serious. I found it hilarious.
    • bartread 6y ago
      Indeed, and there are loads of them on this subthread. I'm dating myself here but it just goes to show that, absent body-language, voice tone, and other contextual cues, humour still sometimes doesn't communicate well on the web.
• hinkley 6y ago
  > If you follow the advice from this website you will end up being the problem. If you meet an asshole in the morning, you met an asshole. If you meet assholes all day long, you’re the asshole.
• kerblang 6y ago
  The only one that kind of bothered me was "The Legacy Maintainer" which argues that your legacy maintainers _want_ to be stuck on a legacy project with their career in ruins. In my experience, nobody wants that, but neither can they do anything about it. Then again, the world already looks down on LM's as effectively an "untouchable" caste, so any excuse will do.
  • JshWright 6y ago
    If that's the only one that bothered you, you may want to consider why that is. It's something you have experience with, and therefore feel empathy for. Is it likely that you just happened to have experience with the one "role" that's worth being empathetic towards?
  • kube-system 6y ago
    I've worked with tons people who have built their careers around a particular piece of technology, get comfortable in that role, and never leave.
• outworlder 6y ago
  > This is a horrible website and you will likely experience diminished tenure if you follow it's advice. Only if you take this seriously. It's no less toxic than a Dilbert strip. You are also doomed if you try to follow Dilbert.
• konjin 6y ago
  You sound like the The Peacemaker. You should try and see how websites like this facilitate technological excellence even though they make you uncomfortable.
  • joshuamorton 6y ago
    What? The peacemaker wants to avoid arguments. Going around someone avoids arguments. The peacemaker would follow the advice on the site and go around someone. This person, on the other hand, is saying thats bad, and that a more confrontational (but less passive aggressive) approach is likely better. That's both more mature and more likely to lead to technical excellence.
• bigbob2 6y ago
  Agreed - maybe there is a grain of validity in many of these stereotypes, but it's riddled with misinformation such as: > Typically – especially on large development teams – low quality is caused by individual developers rather than the team as a whole. Maybe that's true at whatever firm they work at, but in my experience it's failure of leadership to implement process where it's needed. I've been viewing it in a comedic light because it feels like a joke, and it is quite funny.
• h1fra 6y ago
  I can not say it's a true piece of art, but looking at the engineering row, I have met every single cliché in this list and the description are perfect. Each individuals are unique, so the "solutions" part is foolish, only a bad manager would follow them blindly but I would definitely say that the labelling is on point
• jtdev 6y ago
  I sense that you may fall into one of these categories and you don't like that...