Development philosophy #

This page details at a high level how I approach backend development, and should give you a good idea of how I collaborate with my teammates to design and develop software.

Summary #

I’ve always held the belief that backend is backend: there are no industry-specific elements of designing and building robust, efficient systems. When I design a solution, I focus solely on the foundation of the problem, identify the limiting factors, and ask if we can do better or if it’s something we need to design around.

Principles #

In this section I’ve tried to describe succinctly what I feel is most important in software development.

Growth #

I believe the most important part of this job is the willingness to learn. As developers, we are building a career on a framework, “software development,” that changes just as often as the most popular JavaScript framework. A flexible mind and continuous learning are imperative in this career, and I believe helping your teammates grow is just as important as learning new technologies.

Testing #

I don’t believe test-driven-development is a lofty or unachievable goal, but it’s a lot harder to do if the code isn’t written with testing in mind. Testing is one of the most important parts of developing software, especially backend services.

Tested code is code I can have confidence in.

Documentation #

Good software is well documented. I write code with others in mind and that means making sure they understand it. It doesn’t mean commenting every line, it means simplifying complex code and explaining how it solves the problem that it is solving.

Beyond the source code, I’m a staunch believer in the power of documentation. Everything I write has a README and I don’t publish code without documentation.

Quality #

My standard for code quality has to do with effort and thought. Elegant, general, simple solutions that lend themselves well to refactoring is what I want to see most. Less code means less bugs.

Process #

Product owners, salespeople, stake-holders, and junior developers are often more interested getting something done than how it gets done, especially in startups. There’s value to this, but as a product or service scales up in both customers and developers, scrappy development becomes an unmanageable hindrance.

New developers don’t have the documentation they need to write features or fix bugs, a problem bound to compound due to the lack of clarity and quality of the code. Bringing new developers on becomes a pain, it slows down development, and it makes conducting code reviews even worse because new developers don’t know the difference between something wrong that we need to live with and something that needs addressing.

As soon as we start scaling our customer base, process is more important than the product. If you want to scale, you need to be reliable, and reliability comes from a confident development team that fully understands their system.