How I Became a Better Front-End Developer

This blog is not a list of technologies or libraries to go through, but a way of looking at career development.

I’ve worked in development for over 25 years, becoming a decent developer has always been a goal of mine. At times, I feel like I’m getting there. Other times I feel like I’m a million miles away. In those 25 years I have architected and managed enterprise teams in fields as diverse as telecom, oil and gas, shipping, and finance. The development work in all these sectors is mostly the same. Here is the secret I’ve found along the way that made me a better developer (not just a better front-end developer).

“Know what you don’t know” is the best piece of advice I have received in my career.

 What I take from this is that there are many things in development I’m not an expert on, but need to be aware of the existence of. You may not know all the ins and outs of, say, accessibility for a website, but you should be mindful of it, why it’s vital for consumer websites, and who to turn to for help implementing it.

Reflecting on the things I know I don’t know, I can evaluate how important they are and prioritize learning them. As a front-end developer, if your website is an external facing site, you might want to prioritize learning how to increase accessibility for your users over, say, CSS variables. One of the best things a developer can do is a self-assessment of what they like to do, what they are good at in development, and what gaps they should work to fill in. You have to do a brutally honest appraisal of yourself which can be hard. However, any developer can benefit from this work.

 Here is an example of what you can look at, based on my experience as a front-end developer.

Identifying Your Interests and Knowledge

Most front-end developers can place themselves on a spectrum of how artistic or technical they are in their personality. The horizontal axis will run from someone who is very creative with very little interest in the technical aspects of a web page or native front-ends to someone that is only interested in the 1s and 0s of development. The vertical axis will be their knowledge of development practices.

If you take a standard distribution curve to this, it maps out a general sense of your effectiveness.

There’s nothing wrong with being on one end or the other. However, as a manager, I would like to have the full spectrum covered on my development teams. Kind of like so.

From sitting with users in meetings and focus groups I came to some realizations about where I fell on this chart. I did not know the psychology behind why action buttons needed to be on the right side of a page or why text should be around 80 characters in length or why we aligned things in 12 column sections. When I looked at myself with a managerial eye, I realized I was very much on the tech side of the chart. To make myself a more productive front-end developer I decided to do two things:

1. Move my interests closer to the middle.
2. Broaden the standard deviation of my knowledge.

Having a broad knowledge base will help you in your career because when staffing a project, managers usually have to make decisions on what and why we need specific talents for a project. Most of the time, it comes down to how can we do the most work with the least number of people. As you start broadening your knowledge, you can show your ability to do more than a small piece of the work. Also, you will begin to learn more of the cutting edge technologies and skills that you could influence the way your company works. All of this can make you a more valuable developer. 

For me, I decided I would broaden my knowledge by learning more about the design side of UI. This would move me here on the graph.

Listening to experts on the subject of UI/UX is an excellent way for front-end developers to get a general knowledge of design. First, you can learn empathy for how designers solve issues. Second, it can allow you to interject why, from a programmable view, a particular design does not work, in a way that designers will listen to and hear. Lastly, as stated before, it can make you a more valuable developer if you can wear multiple hats on a team.

Going with the Flow (Chart)

Looking at one aspect of your development persona is not enough to become a better developer. You should also evaluate what types of environments you thrive in. There are many ways to do this but let’s focus on one.

The psychologist Mihaly Csikszentmihalyi outlined a theory that people are happiest when they are in the “flow.” Flow is a state in which people are so deeply involved in an activity that nothing else seems to matter. What this means is that most people like to be profoundly challenged in a way that requires a high skill level. 

For day-to-day work, I’m not sure flow is sustainable. Being so focused that nothing else matters may be attainable for a bit, but life does happen. Family, illness, fatigue, business priorities changes, workplace politics are just a few things that can take you out of the zone. However, what the Csikszentmihalyi “flow” chart below can do is tell us where we like to work.

This chart describes the possible mental states during a task in terms of challenge (vertical axis) and skill level (horizontal access). For most tasks that people take on, there is a clockwise movement through this chart. When they first stat, they’re starting at Apathy. As a task becomes more challenging but their skill has yet to increase, the user will move up to Worry then Anxiety. As their skill level increases during execution of the task, they will start moving to the right, towards Flow.

Let us modify this chart a bit and say the challenge level (vertical axis) is not only based on the difficulty of the project but also the timelines we are under for the project. Now, I’ve worked with some people that need to be in the Anxiety, Arousal (as in excitement), or Flow sections or they get distracted very quickly. They need the adrenaline rush of the challenge. I also know other developers where the stress of timelines and the pressure to get work done makes them physically ill. They often make more mistakes when they are in the Anxiety or Arousal zones, and they like to live in the Control, Relaxation or Boredom (as in tasks are routine)sections.

For me, I like to live in the Control section of this chart. I want to flex my brain and find a solution to severe problems. However, I love having deadlines and reaching the perceived “doneness” of an application. I also don’t like the pressure of always being under the gun because of some arbitrary deadline.

As you review yourself and your relationship to this chart, see where you like to live, and how you can move the needle to fit your comfort level. If your job fits more in the Apathy or Boredom sections, but you are someone that enjoys a more significant challenge, then consider setting artificial deadlines to increase the challenge level. The opposite would be to pad your estimates to give yourself more time and keep things in the Flow or Relaxation sections. 

For me, I pad my estimate on how long it takes to get things done, managing the expectations on what can and can be delivered, and pushing “scope creeps” to future sprints. These tricks allow me to stay in the Control or Relaxation sectors.

Keep in mind; you might only be able to move the needle so far. It is during this exercise that you might have to answer the hard question — Is this job the right fit and do I need to change roles or even careers?

Being One With Yourself

The magic here that everyone has it in themselves to be a fantastic developer. The key is being honest with yourself, as well as having coworkers and peers that can help give honest feedback when needed. Self-evaluation should happen every couple of years or whenever you are moving to a new major task or role. Make sure to look at other aspects of yourself and your skills to see where you might want to improve. All of this will make you a better developer and team member.

Related:

• The Front-End Developer — Full-Stack Developer Paradox
• Rediscovering the State of Flow