Tips for success as a full stack software engineer
By: Richard Mahler
Tags: Software Development, Career Development, Software, Software Engineering, Full Stack Developer

Are you a full stack engineer?

Software engineers are often lumped into three categories, whether in the official job title or informally. As a refresher:

Front End Engineer — Typically works on the code for an application that ends up directly interfacing the client or user. Think user interface for the most part, such as a web site. Any code that builds the user interface such as HTML, CSS and/or Javascript. There are numerous languages, frameworks and paradigms that are used to build the front end. As an example, being proficient in Javascript is useful for web pages, but there are an assortment of Javascript libraries and frameworks such as React, Angular or Vue. Often, a front end engineer is given visual specifications and the user experience from interacting with the user interface such as clicking a button.

Back End Engineer — This is the engineer that works on the code that operates behind the scenes. This includes REST APIs, databases, messaging, caching and anything that works with the business logic and storage layer and makes good things happen such as object retrieval, creation, deletion and updates. Having extensive experience in one or more backend language(s) such as Java or Python and a storage/database technology such as SQL or NoSQL is a good start. While there are many more architectures that can complicate a back end engineer’s job, often the work is in learning good coding principles and integration with other back end components.

So what about a full stack engineer?

Photo by Matt Moloney from StockSnap

A full stack engineer is a combination of both, as you might figure. This can be equally split, or lean towards front or back end depending on business need. Sometimes, this engineer may wear others hats, with responsibilities such as managing builds, integration testing and deploying to production.

While a front-end engineer or a back-end engineer can be specialists in their domain, a full stack engineer can be thought of as a generalist and thus tend to require a solid set of skills in both areas to succeed. The benefit of becoming full stack is in flexibility and having a broader understanding of the picture, particularly that of software design and architecture. Many engineers start their career as full stack engineers who then go with the option of considering front-end or back-end jobs out of specialization or preference. Sometimes front-end or back-end engineers become full-stack as well.

Regardless if you are starting or experienced, here are a few tips I found useful during my career as a full stack engineer:

Know the pros and cons of your stack

Like a fine recipe, understanding how an application is put together from its individual software components is key. It can help to have a high level design of the entire architecture, whether it’s a commonly used bundle such as LAMP or MEAN, their variants or a custom application stack. Understand the pros and cons of each component, how they fit together in the software and evaluate the trade offs such as ease of use/learning, performance, reliability, security and scalability.

As an example, ExtJS has the flexibility of using the MVC (Model-View-Controller) or MVVM (Model-View-View-Model) architectural pattern. Choosing to use MVC may be better for applications when various components need to be done in parallel whereas MVVM has the benefit of building reusable components easier, as it is decoupled from business logic. Knowing other benefits and drawbacks is important as you build out your application.

Your manager or higher ups might have the final say on what you are using, but it’s always a good idea to bring up potential improvements by digging into the components and raising issues with the current design or suggesting replacements that would be useful for version 2.0 and beyond.

Be a master of source control

Mastering source control is important for collaboration with other developers and keeping track of multiple copies of code for different versions of the software. It’s almost unavoidable to be an efficient developer when version control software such as Git is ubiquitous and used in projects of all sizes. Learning how to use it well and using it efficiently with the help of visual tools to compare diffs of the same document, preferably with who changed what, can be a time saver for reverting broken code or breaking changes from another developer. Then talk to that developer :)

Your application may use a single repository for the full stack, or into separate repositories. Smaller applications may start out with a single repository and separate as they get larger. Deploying applications with a specific version for the front-end and another for the back-end is useful in this manner. Developers often have set permissions for their own repositories but a full-stack developer often can check multiple repositories and should be able to track changes and determine whether bugs arise in the front-end or back-end.

Don’t underestimate testing

The importance of testing cannot be understated. Unit tests particularly, as they should be written to catch bugs before they are detected later in the development cycle. Ideally they should be written as simple as possible, with each test written in single use cases with minimal assertions and fail-fast. Full stack engineers should be familiar with unit testing for individual pieces and examine code coverage, often through the use of a tool such jacoco.

Often, you might hear about Test Driven Development (TDD) when you read about testing. Basically, it’s writing the test cases before writing classes or business logic which you need to develop until they pass and then rinse and repeat those steps for other requirements. It’s a good practice to follow for simplifying your work and reducing your workload.

It’s good to refactor

Code changes rapidly to meet ever changing requirements or scaling up to millions of users. Sometimes it can be overwhelming when viewing diffs and see 2000+ lines of code changed and wonder why that developer needed to do all that work in the first place. No kidding. The major reason for refactor is keeping code DRY and making code reusable for other uses and in the long run, simplifying the code for other developers. Adapt to keeping code as clean as possible and pick up this book if you haven’t read it before.

Learn from your fellow coworkers

This is probably the most important tip. Being a generalist often tends to overlook some of the details that a specialist front or back end engineer may have. One way to learn from them is through looking at their code in source control, but even better is through pair programming with them and understanding their feedback in code reviews. Good code reviews should be constructive and help with learning for all developers and fill in missing gaps.

I’ve found it helpful in particular learning about the Airbnb JavaScript Style Guide from a front-end developer to improve my own ReactJS code. Little did I know how useful this would be, especially after that developer left the company.

Conclusion

There is a lot more to being a good full-stack engineer than what I’ve written, but these are some of the basics that are more geared towards a generalist as opposed to someone tied to just part of the software stack. I would say that just as with being any good software engineer, it helps to continuously learn, from your own experiences as well as the never ending changes to existing software tools and technologies.