4 ms·
> You’ll need to work around incompetence This one I am truly struggling with, and probably will the rest of my life. Sadly it hinders the success of all of us
by fullstackchris 4y ago
> You’ll need to work around incompetence
This one I am truly struggling with, and probably will the rest of my life. Sadly it hinders the success of all of us as software developers. I'm currently reading "How to Win Friends and Influence People" by Dale Carnegie and loving it, but can't help but thinking in the back of my mind that somehow all these rules and guidance he has for being a decent human with other humans are extremely challenging when (in some cases) you are FORCED to work with said incompetant collegue. I agree entirely with the authors wording around this point, including "frustrating", "exhausting", and "toxic". Call me an asshole but I'm an engineer, by definition I like doing things efficiently and to the point. Working with someone who can't be either is incredibly challenging. Would love to hear more strategies people have developed to deal with this.
Reading comments here, I want to be clear: I'm not talking about some ego-based notion of "incompetance" like "I can write code better than you". I'm talking about the bigwig guy on your team with a big wallet who tells you the product should be implemented in XYZ because he read an artical about XYZ in a magazine and thought it was cool.
> Dealing with people is hard. Dealing with uncertainty is hard. Dealing with uncertain people is harder. And that's what you're going to do as a software developer.
Also this, haha. This post is gold. Nice work!
- jooz 4y agoReading this point I realize is the one Ive improved last year. After covid crises, many seniors left, and I find myself being the more senior. There a few others seniors around me, but they have been on the same place all their life, so Im the senior with most different experiences. I often propose/ask other teams to implement changes that I need. Is often challenging, the are contrary to change. Specially if it comes from somebody outside their current team. I follow this approach: - I try to convince them, with diplomacy. Often what I request is also good for them. - If they refuse some _internal_ changes I propose, I live with that. If that issue some day impact me, I will communicate with them by opening a ticket. If they dont work on the ticket, will be a project management problem, not an software engineer problem. - I limit my interactions with them through their interface (ex: REST API provided by their service). On this point I'm rigorous, because the interface is difficult to change once is used by everybody. In summary, if they have bad implementations or bad design, I try to contain inside a box. Some day a new guy will be able to solve those internal issues. But I trace a line on the interface they provide, and ask for an interface that make sense.