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 aspiration1, 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!
Though seriously, even if you are one, don’t call yourself that.↩
do industry needs programmers who can work on objective-c,basically on mac os platoform ?
Yes, iOS devs are some of the most sought-after devs in the industry right now.
can you suggest me some international certifications in objective c, cocoa programming and mac os x platform,that can get me a good job ?
Thanks for the interesting article. I haven’t come across the phrase ‘Full Stack Engineering’ before, but it’s a good label for what my role has evolved into over the last 7 years or so.
I personally think it’s a valuable resource for any development or support team to have in small quantities, especially when a given application requires a particularly systemsy solution. I’ve found that these roles tend to crop up in smaller teams and organisations because larger teams tend towards more layers of management, who tend to prefer individual roles to have obvious labels for their specialisms.
But who do they turn to when something isn’t working quite right or a project has ground to a halt because the UI team can’t agree an api with the server-side team? That’s where you need somebody to understand what’s going on in the pipeline from the browser’s javascript engine over the network, through the firewalls, bouncing round the presentation and logic tiers and into the storage.
It also tends to evolve into a more background role, helping answer questions for a specialist who needs to understand something from the other side of the fence, so I wholeheartedly agree with your point about helping UI people with server side API questions, or storage people come up with system load estimates. It also helps to keep the whole system in at least one person’s mind at once, I’m sure we’ve all come across projects with increasingly complex solutions to a problem that could have been simply redefined if only somebody could see the consequences.
I can’t say what routes are available to get here in every organisation, but I can say what works for my team, quiet curiosity and an aptitude for learning. Generally speaking, computer engineers are easy to get carried away when up to their elbows in something technical, especially when you can add some enthusiasm and interest to what they’re doing.
When you’ve come up with a question or a requirement that would normally get passed along the stack, follow along with it, ask the person to work through their analysis with you so that you can get to grips with the processes that lead on from your specialism. That way you’ve got the context of your current understanding to pick up the next link in the chain, which is way easier to learn than in the abstract.
The trick is to get recognised for the value this brings, it can be a demanding and invisible role. Despite needing to keep track of quite a few technical disciplines, I’d say you need to cut 2 parts technical guru with 1 part communication, so that you’re useful to your team. There’s no point diagnosing a spike in disk i/o to a poor use of recursion in javascript if you can’t explain it to your team and teach them why it happened and how to avoid it in the future and then present the problem and the solution to your manager-but-three.