Nothing ventured, nothing gained

What follows are some strong opinions I have regarding software development. Most of these aren’t original, but together, they form the framework for how I think about software and it’s design and development in a production environment.

In no particular order:

• Software engineering is a discipline. You don’t master the art of software engineer just because you have a passion, a hobby, a degree from a university, or a book titled “C++ in 365 days”. These factors may help, but it’s discipline that keeps you practicing, studying, and applying the scientific method, which ultimately makes you a better software engineer.

• Focus on delivering value to customers. If you’re write it, test it, buy it, sell it, pay for it, run it, own it, or use it, you are a customer. Any single project or organization will have multiple customers. Figure out who your customers are and how to maximize their collective goals.

• Reading software should be a pleasure. Good software reveals it intentions by following conventions and using design patterns. If software is primarily read by other software engineers, it should be written in a manner for other software engineers to read. Sometimes this manner is called a domain specific language.

• Learn to build, follow, and break conventions. Conventions exist everywhere either by accident (a recurring pattern) or intentionally (by design). A team should follow conventions and also establish them when they don’t exist or capture them when they begin to emerge. Keep in mind that even conventions can have scalability issues. Teams should recognize when an existing convention stops scaling and introduce new ones. For large bodies of software every piece should have a place, and every place should have it’s piece.

• Keep things simple by recognizing high compute costs. Never try to design everything up front and all at once. When developing new features, it’s easier to do so on top of components that are small and decoupled rather than large and complex. That’s why it’s important to start work by doing the simplest thing possible.

• Testing is important, but not as important as strong team communication. A program with 100% test coverage doesn’t imply that it’s 100% functional. In fact, that opinion is extremely dangerous since it’s possible to have a busted program with 100% test coverage. Better communication will always beat better coverage.

• Building products is a team sport. Finding the right people, motivating them, and putting them in the right positions is key to the success of a product. Don’t just hire someone for what they already know, hire them because of their ability to learn. The idea that great products are built by people in silos is no longer the truth. Collaboration and different perspectives make a better team and build a better product.

• Writing testable code is the trick to writing reusable code. If you’re having a hard time isolating a piece of code, it’ll generally imply you’re going to have a hard time reusing it.

• Code reusability isn’t as important as code usability. An API should be usable much like a user interface: it should be clear to users, simple to use, provide shortcuts for commonly completed activities, and consistent.