Ask HN: What lessons did you learn from your best or worst colleagues?

This, so much. Every branch or decision point in either the domain model/flowchart/spec/etc or implementation should be carefully considered. This applies doubly so to error handling. Also, try to make the code paths look like or at least be recognisable by the spec. Try to keep one mental model of what happens that the team all share.

Best: never start implementing something if you don't know how it solves the problem or why its needed

Its very common for people to come to you with a suggested solution rather than telling you their problem.

Can't count how many times I've been assigned to build feature X, and upon further digging realized it will not solve the requester's problem or won't do what they think it will.

So I'm actually planning on writing a blog post on it which at some point I'll share, but, basically -

Responsible: You're the one affected by something, and the one expected to respond to it (first, possibly only). You have incentive to prioritize it highly and deal with it. I.e., if anyone cares about it, it's you. So, for instance, an alert goes off that a service is down. While it may affect the whole company, if it's your service, -you- are responsible for it. "We're all responsible for it" is not true; who feels that sense of ownership, who is going to have to write the post-mortem, who would be blamed if it's a blame culture, etc. Or, more succinctly for this example, "who is waking up to deal with it". This matters because it's too easy to blur lines of responsibility; is the director of the department responsible for it? No; while long down time that leads to revenue loss may require his presence in meetings and things, he isn't expected to actually go fix it himself. He's responsible for hiring the right people, and setting the right policies in place; NOT answering the Pagerduty. Broadly sharing responsibility is an anti-pattern, and, frankly, a lie; it's why "decision by committee" and "too many cooks in the kitchen" are bad ideas.

Empowerment: The changes you need to make, you can make. This might be in terms of organizational authority, or actual technical permissions. In the prior example, if I can't access prod enough to fix the issue, I'm not empowered. What I AM empowered, and responsible, to do, is send emails/call someone who can make the changes. If I don't know who that is, I'm not knowledgeable; I can do what I -am- knowledgeable of (send an email to the whole department? Post it in a seemingly relevant Slack channel? File a ticket?), and then wipe my hands of it until I can either acquire new knowledge (who to reach out to), or new empowerment (the ability to make the changes).

Knowledgeable: Knowing what needs to be done. This might be a business need, or it might be technical. Technical is 'easy', in that you can usually go learn it on your own, but the business is harder, as it comes from somewhere that may not want to work with you, or that you can't identify. As an engineer, I might be responsible and empowered to build things, but I'm not knowledgeable about -what- the business wants/needs; I have to get that information from product or other stakeholders.

If I know what and how something should be done, I'm responsible for delivering it, and I'm empowered to actually go get it done, I can (and if a good employee, will) do it. If I'm missing any of those, I can't; I have to get the missing piece(s). This sounds obvious, and it kind of is, but pretty much every organizational problem I've run into can be framed using this (though sometimes with slightly hand-wavey definitions).

Dev is blocked on product; dev doesn't have the knowledge to know what to build. Go to product; they don't have the knowledge either. Further, they're not empowered to prioritize getting that knowledge; instead, they're spending all their time on what they feel responsible for, say, unrelated meetings, UX design, and documentation of status. A fix: change what product is responsible for (from "gather status and respond to upper management -> unblock dev"), and empower them to prioritize their time accordingly.

Dev feels releases are a pain in the ass; they are responsible, but empowerment to actually push to prod resides in an ops team. The ops team has the empowerment, and the knowledge, but they don't feel responsibility; if a release goes bad it's their issue, but if a release doesn't happen it's the dev team's issue. A fix: Either empower devs to release to prod without the ops team's involvement, or make ops feel responsible for releasing (i.e., time between dev says "we want this released", and when it gets released, is a factor on how the ops team's performance is evaluated).

Determining what is missing provides direction in what to address to solve the problem, and if you're unable to, moves it from something to agonize over, to something to accept as not something under your control.