One year on
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.
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 (yuk!), and a little bit of jQuery.
What I thought
There were a few points when I thought I knew a little about frontend 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
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
- Meetups - Important!! A great chance to learn from others and meet local devs and network.
I have had input and advice from people with experience. Here are some pointers I have drawn from this year:
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.