Drew BarontiniProduct Director at Differential

Development Principles


February 13, 2020

Reading Time

1 min.

One of the great parts of software development is the ability to solve a given problem in a variety of ways. But that’s also an aspect that makes it challenging and, at times, frustrating. Just like core values can help evaluate and guide your choices, so, too, can a set of "Development Principles".

Here are my Development Principles.

Establish conventions.

Spend the upfront time establishing conventions and guidelines for how to write and organize code so you don't have to waste the cognitive energy later.

Ask questions.

There are no bad questions. Any question will help unlock more knowledge and insight into why something was done. The developer who wrote the code should be able to explain why they did it that way. If they can't, it's an opportunity to Strive for clarity.

Narrow the scope.

Continually refine the scope of the problem so that the solution is narrow in focus, making it easier to reason about, and easier to refine over time. The goal is to make the least amount of changes to solve the problem.

Strive for clarity.

Don't try and be terse for the sake of being terse. Name a variable what it is and does. Reading code should make sense. Make it clear to other developers what the code does and why it does it.

Be intentional.

When you do something, make sure your intentions are clear, and it is geared towards solving the root problem. Don't let your Pull Requests change 10 different things. Narrow the scope.

Don't overthink it.

Keep it simple, and make the solution as clear and as simple as possible. No code is perfect, and code, like any text, is an iterative function that evolves over time.

Favor real use-cases over edge-cases.

There will always be edge-cases and things lurking in the unknown, so make sure to err on the side of real use-cases that solve real user problems. Don't overthink it.

Focus on the user.

The code is meant to solve problems of an end-user. Keep the focus on them primarily, and secondarily on other developers — the users of the code itself. Think first that you're writing this code to solve a real pain a user is feeling, and you're also writing it so another developer can understand it and improve it in the future.