Developers As Product People
As a developer writing code is only part of the journey. You might be getting paid to write code, and your situation might also be that you’re being paid to write a solution for a very specific problem space. It also might be a given, that the solution or answer to a problem has been figured out by someone else and they need you to turn these ideas into code. This is all common.
No matter if you’re in charge of building the product or part of a huge constellation of people working on a product, it always comeback to the fact, that we’re building products. This is how you or the company you work for makes money. Delivering a product that satisfies a need or solves a pending problem. But it’s not even about the product. It’s the problem the product is set out to solve. Nothing new here and still, if I asked you who’s in charge of thinking about the product, hardly would you come up with “developers”.
Asking around, the answers would probably be a Product Manager or a Project Manager or someone from UX but hardly developers. You might hear cliches like “If I’m not coding, I’m not productive” or “These developers should focus on writing code”. But before writing any code or before even jumping into a project, wouldn’t it be interesting to figure out what problem you’re actually trying to solve here?
There’s a huge difference, once you ask this fundamental question. It gives insights into your and your customers motivation. Just like a great talk, you clarify the Why? Why should the audience sit here and listen to this talk. Answering the why? provides meaning, context and an expected outcome.
Once you know the problem you’re out to solve, you’re able to step out the box you’re in. For example as a developer you might be in a box, because you have been hired as an specific framework or language expert or for your expertise in a specific technological domain. It opens up new ways of seeing the bigger picture. Of course this is not for everyone and some people only want to work away on a very low level, focusing on a small problem space. This is all good and valid.
It might also depend on what stage you are on your journey. You could have been programming for one or two years and your focus is clearly on learning your domain. You might be only interested in writing code, no matter what you’re actually building at this stage. This is all valid. But progress can be a different thing or have a different meaning for everyone.
When I hear developers say “learning is the most important skill”, most simply mean learning new frameworks or technical details. But learning can be something different. Learning could mean, I want to learn about the problem this product, I’m currently writing code for, solves or I want to learn to be a better communicator.
Just think about this, what happens when we take a step back from any implementation details and ask “What are we actually solving”? It opens up a new way of seeing things. Maybe the code you’re writing is not the answer to the problem and you could spend time writing something that actually matters. Once you understand the problem, you’re in a good position to ask questions. What’s more interesting than having given answers? Is asking questions. There is nothing more boring, than someone having an answer to every question. It takes away the possibility to explore new ways of solving a problem. So called best practices are here to validate the status quo, which is all fine and good in certain situations. The interesting things happen beyond the best practices and so called expert opinions.
As a developer writing code is only part of the journey.
