Top 10 Ways to Succeed as a Front End Developer in 2021

Thursday May 27, 2021

Front-End development is notorious for being the wild-west when it comes to development in general. But following these guidelines will help you streamline your workflow and create stability in the midst of constant chaos and change.

Hashtag Front End Development.

Front End Development - Picture of person standing on top of a mountain in the evening with both hands in the air.

Photo by Benjamin Davies on Unsplash

Now I am not going to bore you with an extra paragraph to read, so I’ll get straight to the point:

Have you ever built a sky-scraper or a house? Probably not. However, I’m sure you know as well as I do that if the foundation is weak, no structure will withstand the test of time. The same goes with programming (of any kind).

It is imperative that you know the ins and outs of the various ways of declaring variables, creating and manipulating Objects, Arrays, Functions, Classes, and are well versed in the two main paradigms of JavaScript — Functional Programming and Object-Oriented Programming (OOP).

Make sure you really understand the very basics of things such as Promises, Closures, Scope, the this keyword, Asynchronous programming, Hoisting, and Inheritance. Many of us love to think that we are well-versed in these areas of Javascript, but how true is that? Know what a 1st class citizen is in Javascript — (Functions are 1st class citizens for those of you who weren’t aware because you can pass them to other functions as arguments, return them from other functions and store them inside variables).

Know how to work with REST APIs, perform DOM manipulation with your eyes closed (not sure if this is possible) and understand the relationship between clients, servers, and databases. Knowing how the internet works on a high level also helps here. I can go on and on but I think I covered the basics. Moving on.

Whether you are a beginner who just graduated from a coding boot camp or a seasoned Front End Development veteran who has worked at agencies, startups, or at enterprise-level companies, the common factor of knowledge we all share is that things are constantly changing. New frameworks are now almost a weekly thing, constant updates to some of our most widely used tools such as Node, React, Angular, Webpack, etc., surely keep us on our toes.

Keeping up with such rapid change takes — above all, passion for coding, but it also takes presence of mind and maintaining situational awareness on our part (even though we get automated alerts on depreciated and outdated features). The desire to continuously roll with the punches and learn new things can take a toll after some time. Let alone the constantly evolving set of tools. The simple nature of legacy projects has a way of throwing unknown bugs leading from messy code-bases and corner-cases that were unaccounted for (stemming from short budgets and rush projects).

My point here is that the only certainty we have is uncertainty — and we must be okay with that. Although advocating for change in a professional manner is always appropriate, whining, complaining, and removing your frustration on others and/or your work IS NOT. Embrace change and change will embrace you back.

Piggy-backing off what I mentioned in the previous point, another thing I wanted to mention was the ever-changing requests and demands of clients. Human beings by nature are unsure but still sure kind of beings. We think we know what we want and we believe that we should have it according to our timeline, regardless of what our friends, family, and peers say. So why should it be any different for clients?

Even though it might seem that clients are automated robots who constantly vocalize things repetitively — I want this, I want that, can we add this please, can we change that… on and on, they just like us — are humans too.

So you or your team convinced the client to change their site’s Header background color to White in order to improve the contrast accessibility score, but they decided Grey is a better option and they want to add a search feature to the header as well. Now, this deviates from the proposed PSD and requires more code + time. And before you even finished implementing those changes, they added 5 more requests that are due by Monday afternoon (it’s Friday, so there goes your weekend). That’s just the way it is! The game of Front End Development.

I’d like to quote Clint Eastwood from his 1986 movie “Heartbreak Ridge” where he tells one of the young Marines to — “Improvise, Adapt and Overcome” (and if you’re a veteran reading this, thank you for your service!). My point is — always be willing to adjust accordingly to what the work demands. I’ll leave this here with that thought.

Imagine having your own cabin somewhere on a mountain-top… peaceful, quiet and all you can hear are the birds chirping (until a mountain lion shows up at your door). Imagine sitting on your perfect multi-screen setup behind a huge glass window and glaring away at the mountains as you follow the optometrist-recommended 20/20/20 rule (stare at an object 20 feet away for 20 seconds every 20 minutes).

This would be perfect, but let’s just say most office environments are crowded, loud and instead of listening to the birds chirping, all you hear is the phone going off and your co-workers talking about fantasy football. Ask yourself if this is the most productive environment for you and if it is, by all means!

However, for those of you who prefer a quieter environment where you can lock in and enter a trance-like state, this might not be the ideal work environment for you. Now by no means am I advocating one way over another, but speaking from experience — you can usually get more done with fewer distractions.

The Covid era has brought about many changes in our lives and has introduced the home-office lifestyle. Ask yourself if this is what you prefer. Or maybe you prefer a more hybrid approach… either way, the goal should be for you to be as productive as you can be. Work is for work, not for social hours. Some of us thrive in busy offices. Some of us prefer a home office.

Do what works best for you!

You’re working on a complicated bug when your manager pings you on Slack and tells you to drop whatever you’re working on and start working on this new feature that needs X, Y & Z (how often does this happen, common!?). You sigh loudly, grab your laptop, notepad, and away toward the conference room you go with your 16oz coffee.

After a 20 minute meeting, you have a good (not so good?) idea of what the specs are and once you get back to your desk, you try to decipher your chicken-scratch into actionable items. The follow-up email from your boss is still vague and the story item assigned to you on Trello is very limited, or worse — over-complicated! What do you do? The clock is ticking and you obviously cant sit there scratching your head trying to figure out the details of this thing.

A good approach here might be something like this:

Hey [boss-name], just following up regarding this new feature(s) we need. I just want to highlight my expected deliverables to avoid any misunderstandings and timely deliver exactly what is needed:

  • Deliverable 1
  • Deliverable 2
  • Deliverable 3

Please advise if I am missing anything here or if you have any other thoughts/suggestions. I am beginning the work now and will keep you updated on the progress as I go, via slack. I expect to have this done by [insert-time]. Thanks!

What this does, is alleviate any doubts your manager might have on your ability to complete the given tasks in a given time and keeps them informed so that they can plan ahead with other tasks/projects as well. Remember, we must always be considerate of our co-workers’ and managers’ time as well as our own. Teamwork makes the dream work. Good communication creates situational awareness and avoids miscommunication with your stakeholders. Saved time = saved resources.

Something that I have always practiced and has worked out extremely well for me (both in office and in remote environments) is conducting a morning check-in with my boss, a mid-day progress update, and an end-of-day status update as to where I stand at the end of the day (outside the door that is).

Doing this creates trust between you and your manager and the candy-on-top is the good quality of your work, delivered on time! Communicate well and often, even when it may not be required — product backlogs are best groomed when there is good situational awareness. At the end of the day, the work won’t suffer. Why? Because you communicated your part well and often!

I’ve been a developer for a little over 5 years and I have worked in Front End Development at all except enterprise-level companies (startups, mid-size, agencies). Each of them had a different structure them and the processes were unique to those existing structures. To be brutally honest, things such as Agile and Scrum are the least effective in agency environments, simply because of the varying number of clients and extremely tight deadlines. One can extract certain aspects of Scrum and use them fairly well in agency environments, however, you won’t get the most out of what Agile and Scrum have to offer.

For those of you who are unfamiliar with either of these — Agile is a Project Management methodology, of which Scrum is a framework. Agile introduces an iterative approach to delivering projects (not just software), where the Scrum methodology introduces things such as daily Scrum events such as morning stand-ups, sprint planning, sprint reviews and spring retrospects. Learn more about it here: https://www.scrum.org/resources/what-is-scrum (but after you finish reading this article).

Learning Scrum will help you and your teamwork in a more organized, communicative, and streamlined fashion to deliver features incrementally while creating a constant feedback loop from stakeholders and clients instead of delivering an entire project all at once! You will also find yourself becoming more organized, productive, and communicative as a result of practicing these methodologies on a daily basis.

So let me guess what your framework of choice is — but wait it really doesn’t matter and you know why? Because they all use JavaScript basics such as objects, inheritance, encapsulation, instances, etc., the list goes on.

Take React for example (and yes I know this is the older way of writing React components but I’m trying to make a point here):


class Welcome extends React.Component { 
   render() { 
      return <h1>Hello, {this.props.name}</h1>; 
   } 
} 

Here, we are literally just extending the functionality of a property called Component on the React object and applying it to the class Welcome . Nothing fancy here, just class inheritance. You get my point, understanding the core fundamentals of Javascript will really empower you to quickly understand the architecture of libraries such as React and frameworks like Angular and what not.

Now if we look at the newer way of writing React components, we can observe a more functional approach:


function Main() {
  return (
    <>
      <MapSection />
      <FeedSection />
    </>
  );
}
export default Main;

Although there is some react-specific stuff going on under the hood, we can clearly notice core Javascript features that are being used here. On to the next.

What I mean here is — understanding things such as the event loop, execution context, the call-stack, and the wide array of debugging tools available for you inside the (Google Chrome) dev-tools.

Do you know what happens when the client receives a 200 response back from the server? What happens when the browser engine parses an HTML file and the circumstances under which it makes appropriate network requests to fetch script files and stylesheets? Knowing how all this works on a high level will absolutely set you apart from other developers, but more importantly, it will enable you to write better code. “How” you may ask? Let me explain.

Imagine having an HTML file:

<!DOCTYPE html>
<html>
 <head>
  <title>Food Ordering App</title>
  <script src="./app.js" defer></script>
  <link rel="stylesheet" type="text/css" href="./styles.css">
 </head>
 <body>
  <main>
   <form>
    <fieldset>
     <input type="text" name="search" id="search_rests">     
     <button id="sort_rests">Sort Alphabetically</button>
     <select id="filter_by_type">
      <optgroup>
       <option selected>Filter by type</option>
       <option>American</option>
       <option>Asian</option>
       <option>Mexican</option>
       <option>Pizza</option>
      </optgroup>
     </select>
    </fieldset>
   </form>
   <div id="cards_wrapper"></div>
  </main>
</body>
</html>

The way the browser will parse this file is from a top-down approach. First we hit the !DOCTYPE declaration, after which we hit the <head> tag — now here comes the interesting part. Once our execution point reaches the <script> tag, the browser will not make a network request, because of the present defer attribute which allows the browser to parse the rest of the file and then make that network request after the DOM (Document Object Model) has been constructed, so as not to bottleneck and consequently reduce load-times.

Now when the browser starts parsing the JavaScript, observe what happens:

 

// CREATES / GETS INIDIVIDUAL CARD
const generate_view = (data) => {
  // HIDE ALL THE CARDS INITIALLY
  const cards_wrapper = [some code]  cards_wrapper.forEach(el => el.style.display = 'none');  // CLEAR OUR FILTERTED RESULTS
  filtered_results = [];  // CREATE CARDS
  data.forEach((el, idx) => {
   // IF JSON
   if (el.id) {
     create_card(el);
   }   // IF HTML ELEMENTS
   else {
    document.getElementById('cards_wrapper').append(el);
    el.style.display = 'initial';
   }
  });
}
generate_view([some code]);

The parser reaches the function generate_view , declares a variable called data , sets its value as undefined blah blah blah. The important point here is that when a function is invoked in Javascript, it creates something called an Execution Context and that function is put on top of the browser’s call stack to be executed. This happens for any function that is being invoked. Once the function has finished executing, it gets popped off the call stack and so on.

This is not a lecture on how the browser’s call-stack works but my point here is to paint a very high-level picture as to what happens when the browser parses HTML and JavaScript files — this sort of knowledge comes very much in handy when building scalable projects and debugging/optimizing performance issues etc.

Read that again.

And finally, avoid burnout. Just take good care of yourself. Coding away like a Ninja and constantly improving your skills takes time — I get it, trust me. Front End Development is fun. Lots of fun.  But over-working takes its toll after a while. This is why I’m keeping this paragraph short. Remember to eat right, exercise regularly, and take frequent breaks.

If you need some extra motivation, go read this article – Why We Must Never Give Up.

Now go enjoy yourself! Thanks for reading!

Originally Published on Medium in Javascript In Plain English

More content at plainenglish.io