When software projects go sideways, it's rarely because of bad code. More often, the trouble starts upstream—with unclear priorities, shifting goals, or mismatched expectations.
We pulled off a completely harebrained marketing scheme, and had a blast doing it. We built a devious little social game for a conference, gave away $1500 to the winner, and got a ton of bang for our buck.
One of our smartest devs had a great insight: talk about tradeoffs. Instead of, "No, that's a bad idea," they found ways to say, "Interesting! We can do that. But here are the tradeoffs if we do."
You can look at an error, or a problem, as defeat; but you can also look at it as an indicator of an opportunity to grow. Getting stuck gives you a path, a direction to explore.
The least error-prone line of communication is the shortest one. And so you, dear developer, must talk to your customers. Listen to them. Shadow them. Watch them work. Build a relationship. Know some of them by name. This will save you from all sorts of communication woes.
A powerful heuristic I used as a Product Manager was to always ask, "What problem are we solving here?" This reframes the question, "Why are we doing this?" But framing with problems tends to lead to more specific, less mushy answers. It forces you to dig a little deeper and do some critical thinking.
Communication skills will make or break your product development process. But **communication is hard**.
Other teams have a lot of requests for your product (or demands, depending on the culture of your company). Believe it or not, this is a gift.
As a developer, you might not have direct control over what your company wants to measure. That's fine. But you *can* be conscious of what you and your team decide to pay the most attention to and look at day to day.
A rigid process is inflexible and brittle. A great process is form-fitted to the humans and circumstances it exists to serve.