by Shaun Michael Stone

My role as a Front-end Web engineer explained ?


Hi, my name is Shaun Stone. I’m a senior front-end web engineer from London, UK. I work in the FinTech industry and love what I do. In this article, I want to explain a bit about my role. To anyone out there who wants to pursue a career in web development, you may find this useful.

I will cover: what we do, how we manage our work, the career path, languages and tools we use. In conclusion, I will provide advice on how you can break into the software industry. Don’t worry, I’m not selling anything — some advice I wish I had when I started out. ?

A front-end web engineer is responsible for implementing visual elements that users see and interact with in a web application.

We build UI ?

We are focused on building the UI (User interfaces) for the users of our website or web application. We consider a few things:

  1. Accessibility: Often overlooked on the web, we design our applications to cater for users with some form of disability. This could be some cognitive impairment or limited dexterity. Someone who struggles with clickable areas such as radio inputs or checkboxes is an example.
  2. Aesthetics: The styles of our UI elements such as the buttons, the fonts, and the spacing. Recently we implemented a design system that enforces consistency across our products. More information on design systems can be found here.
  3. Performance: We have to think about the performance of our applications to keep page speeds fast. This involves reducing network requests, keeping images and SVG files optimized using methods like compression. The quicker you load that signup page, the more chance you have of users signing up. We use Lighthouse by Google to benchmark and gather interesting metrics.
  4. Security: Paramount. Tiny bugs in code can result in private information being leaked, and there are people out there hungry for it. Of course, it’s a huge topic. Check out Information Security Basics by Mozilla:
  5. Quality of code: We use code reviews to check each other's work. We require at least two approvals before anything can proceed to our live applications. We use coding standards that have to be followed across the whole of front-end. Github allows us to do this and more.

Management of Work ?

We follow the agile principles of software development, as do most companies. It’s a way of planning our work for the next two weeks (a sprint). During that process, we refine the tickets we have that follow those two weeks.

All the remaining work we have is stored in what’s called a backlog. This backlog gets filled with work we are to do in the future.

Having a road-map gives us a clear direction of where we want to be. To do this, we use a project management tool called Jira by Atlassian.

Ceremonies ?

  1. Sprint planning sets the team up for success throughout the sprint. The meeting involves walking through the backlog of work to be done, and prioritizing what should be completed for the next two weeks. The team has to estimate each story to see how much effort is required by us. Based on the effort involved, we can gauge capacity (how much can be done versus the development resource available).
  2. Daily stand-up is a very brief meeting with your team to explain: what you did yesterday, what am I doing today, and is there anything stopping me from doing my job? (blocking). This keeps everyone in the loop. Keep it short. Once upon a time, a stand-up lasted an hour for me… ?
  3. Sprint review happens at the end of the sprint. We showcase to other stakeholders (member of the Product team, users of our system) what we managed to achieve. We do this by doing a demo of the work we have been doing. This gives them confidence that we are progressing.
  4. Retrospective is a way to reflect back on what went well and what didn’t. This brings up problems. From those problems we create actions. An action is a thing to initiate a process where we can stop that negative thing from happening again. The things that went well give us an understanding of what makes us work better.

Career path ↗️

Companies have their own career paths. A very common pattern of progression as a software engineer is the following.

Please note: This is my own opinion and based on my own experiences. The term ‘Engineer’ and ‘Developer’ are used interchangeably.

  1. Junior developers have little to no experience. They need to be guided by more senior members of the team to do their work. They will usually ask many questions but can learn a lot and will be very motivated to do so. Their salary is entry-level.
  2. Mid-level developers have a reasonable amount of experience. They can achieve certain tasks on their own. But still, need to look to senior members for guidance from time to time. They can assist Juniors and also provide good ideas to senior members.
  3. Senior developers can deliver from start to finish with no guidance. They lead others to do the same and follow good practices. They are experienced enough to know when things can go wrong and how to avoid those problems.

But when you get to Senior, is that it? No, it shouldn’t be. There are two paths you can follow.

4a. Tech lead/Principal Developer/Architect would be given to the core/higher rank developer in the team who provides a solid technical vision and has the respect of their peers. Less involved in code, and more so in the foundations of the languages and libraries used, the development process, and the infrastructure.

4b. Team Lead/Team Manager is now more focused on the people of the team. Their well being, their career progression and having a one-to-one with each team member to make sure they are happy but are also delivering as expected. More meetings would result in less development time. Management skills are required, and it’s no easy task.

Following on from that you could move to a more executive role. An example is an Engineering manager. This person manages multiple Tech leads/Team leads. Another example is the Chief Technology Officer.

Companies usually rate your competency level down to the number of years of experience you have. To me, this is a fallacy. I have worked with new starters who were labeled more Junior but were knowledgeable and strong. Candidates should be taken at face value.

Languages to learn ?

  1. HTML is a markup language, the structure of web pages.
  2. CSS is the language for describing the presentation of the web, dealing with colors, layout, spacing and more.
  3. JavaScript is the language of the web. It’s a client-side language and enhances the interaction for the user on a web page.

Invest a lot of time into mastering these three languages. I have a quick example of how they work together in this CodePen. Have a play around!

Please note: This example is simplified for demonstration purposes only.

View my CodePen here

If you are up to it, create your own version with a company name of your choice and post in the comments.

Tools to use ?️

  1. Use Git to manage the versions of your code. It allows teams to collaborate on files without causing loss of work.
  2. Use an Integrated Development Environment (IDE) to write your code. It’s software that is like Notepad but comes with more bells and whistles. It can provide suggestions on how you write your code, and color codes your text so it’s easier to interpret.

Advice ?

The first thing to do is create a Github account. Like Behance for Designers, this will be a place where you can showcase the code you write. It will give us (employers) something to work with. When I left University, I was looking for an opportunity to build something even if it was for free. I knew in the long term it would benefit me.

Find Freelance work ?

One of my first freelance projects was for a huge company. The application they wanted me to build was easily a quote of £2–3K. I did it for a couple of hundred pounds. It was a complete steal for them, but it helped in the interview for my first job, that’s for sure.

Prove your work exists ?

Whenever I review CVs, usually if it says you did a course on Udemy and that’s it, then that will not suffice. I want to see proof of your work. For every project you have worked on, even if it was a personal project or for a family member, it’s something that can be put on the CV. These claims of experience should be backed up with real evidence, whether it’s a link to the video demo or a link to the real page.

First job? Great! ?

Now you’re pulling together a small collection of work. You impress a small company and begin your first job. You will be a junior, and the people around you have a lot to teach you for free. Learning from your peers is the best way to learn in my experience, and is — of course — much cheaper. Most online courses help at first and are good to follow sparingly. You should be able to elevate your skills via real commercial experience going forward.

Prove yourself ?

Show that you are passionate about your work and that you want to proactively improve things. Every job you get will have good and bad qualities about it. Try and figure out how to improve the bad things and take the good things on board for any future ventures. In a new job — if that may be — teach them the good things you’ve learned previously, and try to fix the new bad things. If you feel you are not learning anymore, change circumstances so that you are. Your skills should always be relevant in the industry, otherwise, you get left behind. It’s sad but true.

Sell yourself ?

Always find excuses to add to your LinkedIn. Explain what you did in your job (roles and responsibilities). Document it like a diary before you forget about it. Add a professional photo and a strong summary. This is what I have currently. It has evolved over the years.

To date I have 7+ years experience building web applications. I’ve worked in automotive, finance, online gaming and been exposed to building and maintaining bespoke web applications for various companies involved in: car valeting, digital entertainment, industrial gases, retailing and broadband comparison services. Some of my key interests involve writing fiction and non-fiction, building and integrating APIs, automating repetitive tasks, building mobile games and animations with Haxe, Unity or JavaScript/HTML5 canvas.

As well as reading a lot of technical books, I’ve written my own called Automating with Node.js. I read articles on platforms such as Sitepoint, CSSTricks, Egghead, PHPArchitect and Smashing. I attend conferences such as PHP London and keep my eye on Facebook and Google’s developer channels. I’m always open to new approaches and look out for any tips and tricks I can apply to my own work — that I can also share with my peers.

It’s a fast-paced industry ??

The front-end world moves very fast. Libraries/frameworks always seem to be popping up year on year. You will see that a lot of roles require experience of React (created by Facebook), Angular (by a Google employee), or Vue (by a smart guy called Evan You). There are many more but I won’t go into detail now.

Try and grasp these libraries as they are very much in demand. I work with React in my role and have invested a lot of time in becoming proficient in using it. These libraries and frameworks are a layer that sits on top of the JavaScript language. Become a pro in JavaScript first.

Build stuff ??

Motivate yourself to work on a project in your own time. For years I was so interested in personal game development projects. You learn so much during the process. I randomly thought at work one day, “Wouldn’t it be a good idea to have a game like Battleships, but with rabbits instead.” I know right… weird thought to have.

So I found an artist, told him what I wanted, and then got to work on a proof of concept. To play, you place five bunnies and five traps, then sit back and watch. I won’t ruin the surprise. Game here.


That’s it for now. If you ever want more advice, feel free to contact me! Thanks for reading and good luck! Drop a few claps if you’d like. ?

All the best,
Shaun Michael Stone. ✌️