Time written.October 01, 2019

One Year Of JavaScript

#Webdev

At the time of writing this post, I have been a full-time frontend developer for a little over one year.
It seemed like a good opportunity to jot down some thoughts on how the year has been, what I have learned and where I would like to be come this time next year.

Previous experience

When I started working as a full-time frontend dev I had a few months experience using HTML, CSS and JS, as well as a knowledge of Bootstrap. And a little bit of jQuery.

What I thought

There were a few points when I thought I knew a little about frontend web development but there were a lot more times when I felt like I knew nothing because the amount to learn seemed like too much.

How the year has been

Real-world tasks have made me feel more confident in my ability to problem-solve and build applications. There have been people around to help with tricky tasks but I have also been left alone to bugfix and maintain the JavaScript for a large interactive selling page, with plenty of legacy code.

Resources I recommend

This is just a VERY small list of things I incorporate into each month:

  • Technical books - Code complete is a great resource. There are many others including the O’Reilly series
  • ‘Javascript/ReactJs Weekly’ circular email - keep up with the world of JS
  • Meetups - Important!! A great chance to learn from others and meet local devs and network.

Some advice

I have had input and advice from people with experience. Here are some pointers I have drawn from this year:

Ask questions
You are expected to get good at problem solving, a lot of which will be independent. You will not remember everything because you are not Superman or an elephant(elephants never forget, btw) and you may not be able to troubleshoot an issue in a reasonable timescale, at which point asking the question is a smart decision. Go for a walk. A few minutes away from your screen allows you to view a problem with fresh eyes.
I noticed a pattern in the type of question I asked - “have you tried [insert straightforward check]?” Or something similar. The solution to most problems is usually logical. Break it down… Ask yourself the question first and action the answer you would give. (Taking a break will help with asking better questions)

Right tools for the job
You may be confident using a technology, but there may be something out there waiting for you that will better suit your end product. It never hurts to see what’s out there.

Measure twice, cut once
Don’t rush into a project without first having a sound understanding of what is needed “If the foundation [of a house] hasn’t been laid well or the planning is inadequate, the best you can do during construction is to keep damage to a minimum.”
-Steve McConnell, Code Complete

MVP (minimum viable product), start something and build upwards
Only start something you can finish. Release something basic and functional, THEN fix any bugs, add functionality and develop features. The longer a project is open and unfinished, the more likely it is for any original plan to drift away down stream.

What next

I am now familiar with Javascript. I will continue to improve using React.Js this year and maybe explore some server-side Javascript(Node).

Gatsby Website made by Jack Murphy | Cookies | Style guide