Software engineering 101 for front-end developers

Photo credit: Stefan Stefancik.

About 18 months ago, I moved into a new role at Unscrambl as a UX designer and the lead of the front-end development team.

While interviewing several candidates for a front-end developer position, I spotted a troubling trend. Too often, the candidates lacked knowledge and appreciation of good software engineering principles, despite possessing several years of experience in web development. In my view, every software developer in my team needs to be a software engineer first. The opposite of this is what I call a programmer who is not an engineer.

The syndrome understandably results from a variety of reasons:

1. When a developer has constantly been working on small and/or short-lived projects and hasn’t had the opportunity to work on long-lived codebases
2. When the team’s culture has been emphasizing feature completeness and quick turnaround times over maintainability, test coverage, good code hygiene, and developer education
3. When the developer is fresh and possibly self-taught without formal training in software engineering

For any such developers who want to level up their game, I’ve summarized what I consider to be some of the most important software engineering principles to know and abide by. I’ve followed it up with a short list of must-read books that will help you on this path.

The principles

Now I address you, the developers, directly.

The bottom line is that with these principles, you’ll write better software. Your code will be of higher quality, more readable, less buggy, more testable, and more maintainable. You’ll never again be called a code monkey. And never again will you find that your code devolves into a messy spaghetti the moment it grows beyond a certain size or complexity.

So here are the principles.

1. Don’t repeat yourself (DRY)

This principle prescribes that you must not repeat any logic while writing code. So, if you’re clustering two lists of objects based on a property on the object, write a method that does that and call it twice. If you are validating a large number of forms on your UI, build a validation library (or pick an existing one), and use it everywhere. When you write code only once:

1. You can expect that code to behave exactly the same every time you reuse it.
2. If you make a mistake or introduce a bug, it’s going to happen only in one place and one fix will take care of it everywhere.

The guiding principle is that the less code you have, the fewer problems you have.

2. Single responsibility principle (SRP)

A reading list