Every line of code you write is a liability. That line of code you just wrote adds complexity to your code base, gives you more nuances to remember, it might even be a bug. If code is so expensive and dangerous. What can you do? After all, you are a developer.

The answer: You must remember your real job… Delivering value to the users.

Users don’t care what your class hierarchy looks like. They don’t care which language or framework you’re using. They don’t even care if your system is a cloud ready microservice. The user only cares that your product is helping them.

Reminders for Delivering Value

You can ensure you are delivery value by remembering these principles.

The Why is More Important Than the How

We became developers because we are problem solvers. When a user comes with a suggestion, we jump to the how of what they are asking for. We never take the time to understand why they are asking for this feature.

This leads us to deliver exactly what the user wanted. Just to leave them disappointed in the result, and our hard work rarely used.

It is crucial to apply our problem solving skills in the right place. We need to understand what the real problem is, then work together to come up with a better solution.

Strive for the Simplest Solution First

When we start on a project, we think of the perfect solution. We create our own requirements; we dream up scalability, robustnest, the perfect UI…

The user just wants to get rid of the spreadsheet that’s driving their department insane. Turns out they only have 20 users and don’t care about the UI at all.

We need to focus on solutions that are delivered at the scale of the problem, not stroking our egos by doing what Facebook does to support the billions of users that we don’t have.

Deliver Something Tomorrow

We’ve all had projects that began weeks after the famous kickoff meeting. Questions come up… What are we building again? Did we really agree to have this feature? Why is this feature even included?

Don’t wait until you forget everything about the project to start on it. The best time to get started is right after deciding what the project is. That’s when all the details are fresh, creative juices are flowing, and we are excited about the solution.

We need to use this time of heightened productivity to deliver something, and then show it. It will be rough, but the users can see our passion for the project and provide feedback to us. They start to trust us to deliver. By showing something early and often, we gain their trust for the entire project.

Everything is Code

When we start on projects, there is a desire to nail down all of the details. We come up with requirements, then diagrams, and then an over all design. After that, we begin work and everything planned immediately becomes outdated or cumbersome to maintain.

Here is the problem: The documentation and diagram we just created bears the same expenses as code. What happens if we forget to update our documentation? Well, the documentation is now lying to us. False documentation will make your code harder to maintain than no documentation at all.

There are two kinds of documentation that we should have: Documentation that is automatically generated, and documentation that explains the why (mainly for that weird bug we found last week with a solution that makes no sense). Everything else is too expensive, unless we are creating a library where documentation is as important as the code.

Final Thoughts

Every developer faces these pitfalls. No developer will deliver the perfect solution. However, with a few reminders, we are able to achieve better results.

Each of these topics could be its own article. So if you would like to hear more about a topic, please let me know!