allenc allencheung

From Front-End to Full-Stack Engineer

Front-end (FE) engineering is a relatively new specialization of software engineering, come of age because of the increasing complexity of front-end web development. Its precursor and cousin is the applications engineer – both involve coding an user interface, but FE eng. usually refers to a web front-end coded with HTML/CSS/Javascript, while app engineers build on top of an OS-specific framework, whether it is Objective C or .NET.

Full stack (FS) engineering is exactly what it sounds like: the engineer knows the entire web stack, from product to UI to front-end web engineering to back-end engineering to database and systems. An FS engineer is pretty much the ideal startup founder or hire, and also quite valuable in larger organizations from their breadth of knowledge.

My theory is that the most straight-forward way to becoming a FS eng. is through FE engineering; an FE eng. should look to grow his engineering expertise as well as his UI skills, and the project work and interactions with others in the company should encourage this growth. If being the “rockstar pirate ninja badass hacker” is your career aspiration[1], here’s why and how front-end engineering gets you to there.

I should first define the role of front-end engineering – I’ve seen this question asked explicitly as well as implicitly. FE engs work between the UI designer and the back-end engineers; they take design mocks and implement a user interface, and ensure that the interface interacts with backend systems by performing the necessary state operations. Web interfaces are created with HTML and CSS, and state is changed in the browser via Javascript; hence, most define FE eng. as software development primarily with these three technologies.

In reality though, FE engs have to interpolate gaps that the UI design does not specify, and extrapolate the backend logic, controllers and handlers that have not been built. Static visual guidelines just don’t convey the dynamic nature of today’s sites, so it’s really up to the FE guy to internalize a site’s complex state and present a consistent design. At the same time, this added dynamism has wrecked havoc on previously-pristine backend models and controllers, which now have to manage partial sets of data with views and AJAX JSON returns and deal with the increased load.

As a FE eng, it’s perfectly within your right to fold your hands, kick the mocks back to the designer and tell the Rails guy to add another five API functions. But you already have the incentive (it’s blocking your work) and the tools (being exposed to UI design, and having to engineer the front-end with best-practices) to resolve these issues without having to call for help. Even if you don’t now, as you already work with both sides it’s easy enough to ask a few questions or sit down and learn a few tricks.

Eventually, this exposure will expand your technical and design horizons. In smaller companies, this leads you to being a designer/developer hybrid who can be product in any part of the product stack: the genius hacker guy with enough hustle to tackle any thorny issue. In larger companies, a dynamic emerges where the product and UI personnel will come to  you for engineering consultation, while the other engineers will look for you for design suggestions; again, you become the go-to point man for the team.

Of course, I haven’t covered how to become a FE eng., only how FE engineering can lead to FS engineering; I think that’s another topic on its own and be released as an encyclopedic volume. I know how I came to call myself one, but I’m curious about the paths others have tread – drop a comment and let share your success!

Footnotes    (↑ returns to text)

  1. Though seriously, even if you are one, don’t call yourself that.
By allen
allenc allencheung