Software Engineering 101 for Front-end Developers

Harshath J.R.
Jun 19, 2017 · 7 min read

Every front-end developer must also be a software engineer.

About 18 months ago, I moved into a new role at Unscrambl, Inc. as a UX Designer, and the Lead for the front-end development team. Our talented team is building an enterprise web application of non-trivial complexity, and we’re actively looking for fresh blood to join the team of front-end developers (if you’re in the area, get in touch with me! 😊).

While interviewing several candidates for a front-end developer position, I spotted a troubling trend. Too often, the candidates lacked of knowledge and appreciation of good software engineering principles, despite possessing several years of experience with 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, like

  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 be aware of and to abide by. I’ve followed it up with a short list of must-read books that will help you on this upgrade path.

The Principles

The bottom line: with these principles, you will write better software. Your code will be of higher quality, more readable, less buggy, more testable, and more maintainable. You will never again be called a code monkey. 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 they are: The Principles.

1. Don’t Repeat Yourself — DRY

  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 less problems you have.

2. Single Responsibility Principle — SRP

That is the idea behind single responsibility principle. When writing code, you should write it in the form of small simple modules, each of which does takes care of a relatively simple and small responsibility. By module, I mean mean whatever is the unit of composition in your code — classes, functions, components, etc. So in real terms, SRP means writing smaller functions that do just one thing, smaller classes that have a small and singular responsibility, etc.

When modules are small and isolated:

  1. they are easy to conceptualize and implement for you. (easy to write)
  2. they are easier for your co-developers and future developers to read and understand. (easy to read)
  3. they are MUCH easier to unit test thoroughly. (easy to test)
  4. it is easier to add/modify their behavior, especially if you have good unit test coverage. (easy to maintain)

If done right, DRY will become a side-effect of SRP — you are automatically writing reusable code, and not repeating the same thing multiple times.

3. Dependency Injection — DI

The benefit of DI is that when combined with SRP, not only do your modules become small, but also isolated from the rest of your code. And that is something very powerful.

  1. Your modules become reusable in a whole new way. (reusability)
  2. For unit testing, you can inject fake/mocked dependencies when instantiating your module in the test. (testability)

If you’re familiar with angular, or with Spring in Java, you may recall echoes of what I talked about above. Most modern frameworks will provide you a means to use DI in your code. The point of this article, however, is to introduce you to Dependency Injection as a fundamental principle of software engineering, rather than as a feature of an arbitrary framework. The frameworks that provide/support DI simply make it easy for you to follow this principle.

4. Unit testing

The act of writing unit tests will reveal to you if your code is well designed or not.

When your code follows DRY and SRP, it will be very easy to unit test. The anti-thesis of this is that if your code repeats itself over and over, you’ll find yourself writing tests for the same behavior repeatedly as well. If your modules do not have a small enough responsibility, you’ll find that writing unit tests for them will become harder. If your functions are too long, it will become near-impossible to test all the if-else logic branches.

The process of writing unit tests is amazingly good at raising all the red flags present in your code. If you find that writing unit tests is complicated and hard, it is a symptom that you need to re-examine your code’s design and refactor it.

So if you’re serious about writing well-designed and maintainable code, you MUST start writing unit tests, without excuses.

What’s Next — A Reading List

However, this is a good place to start off from. I highly recommend following this up with the following books on software engineering. These books do not market themselves as books specifically for front-end engineering, or backend application development, or any other specific area. But they do have plenty of code examples to help you internalize the principles and to let you Use the Force.

These books should be considered a mandatory primer for anyone who is serious about upgrading their software engineering chops. They will level-up you from a programmer to a software engineer.

  1. Working Effectively with Legacy Code, by Michael Feathers. This book will give you an appreciation of what it is like to work with long-lived code bases, and how to write code now so future You (and future Your Colleagues) can be happy developers.
  2. Refactoring: Improving the Design of Existing Code, by Martin Fowler. You’ll get a whole new appreciation for the word “refactoring” after reading this book.
  3. Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma et al. This is also famously knows as the Gang of Four book. If you want a simpler version of this, check out Head First Design Patterns too.
  4. Clean Code, by Robert C. Martin. Enough said.
  5. Advanced reading: Continuous Delivery, by Jez Humble and David Farley. This book talks about the software development process from an enterprise standpoint. This may not be directly applicable in small companies, but if you know this stuff, you can scale up your team without wandering astray.

Let me know of any other principles you think are Important (with a capital I), and about any books you think are equally deserving of being on a must-read list for software engineers. I’m glad to discuss it and add it to this writing.

Check out all the top articles at


Our community publishes stories worth reading on Android…