DEV Community: James Robinson

5 tips for acing your first year as a junior developer

James Robinson — Sat, 06 Feb 2021 14:58:15 +0000

Starting a new job as a developer can be a daunting prospect especially if you’re coming from a self-taught background. For many junior developers starting their first job may evoke feelings of excitement as well as inadequacy. The feelings of inadequacy are commonly termed imposter syndrome. This is common for experienced as well as inexperienced developers, and these feelings are usually the result of working in a complex and constantly changing landscape.

There is so much to learn it’s almost impossible to understand all of it in any detail. Feelings of imposter syndrome can be even more intense for those just starting out in the industry because, well, they’re new to it.

Your first job as a junior developer is an important one. Mainly because this experience can ultimately determine whether this career path is for you or not. As a junior developer, it is up to you to ensure you do what it takes to make the most of this opportunity and experience. You’ve already cleared the first, hardest hurdle, you’ve managed to teach yourself how to code and now you’ve bagged yourself a job. Your next hurdle is surviving your first 6-12 months as a junior developer. This will be a challenging experience, but if you approach it the right way it will be an incredibly rewarding one, and you’ll learn a heck of a lot. Based on my own experiences during my first year as a junior front-end developer, I’ve compiled my 5 top tips for acing your first 12 months as a junior developer.

1. Prepare for a mindfork

In all honesty, there’s no polite way of putting this. You will be experiencing information overload on a daily basis (this never really stops but it tends to calm down as you gain more experience and settle into a job). This can be pretty overwhelming, and alongside the other conventions that come with a new job - like getting to know a new surrounding, new co-workers, processes, and coffee machines - things can get on top of you really quickly - but only if you let them.

Preparing yourself for this can go a long way toward helping you handle and cope with the rate of information overload. Aside from merely preparing yourself, here are a few approaches I took to handle this:

Keep notes in a markdown file

Keep a markdown file noting key pieces of information that would be wise for you to remember. Using markdown is cool because you can easily format your notes and they can live in your text editor so you can easily reach them when you're coding. Your notes can be codebase specific, they could relate to technologies the company/project uses - they can even be company-specific such as payroll and time tracking information, even where to find the toilet.

Ask for direction

Ask a senior developer or your mentor which areas of information you should be focusing on. You are effectively asking for help to streamline this information overload so you can process and learn the key parts. An experienced developer will have the context and foresight to direct you.

2. Communicate

This sounds like the standard tip of ‘be good at communicating’. But honestly, as a junior developer your communication skills are just as, if not more important, than your technical ability. Often, because you feel embarrassed that you might not know something and you’re hyper-aware that you feel out of your depth, it becomes tempting to silo yourself and hide away when you’re completely stuck on something - eventually, you might decide to ask for help begrudgingly. The problem is, if you don’t tell your co-workers or boss when things are hard or when you’re stuck then you risk shooting yourself and possibly your team in the foot. You won't help yourself and you won't allow your team and co-workers to help you. For instance, if you put off asking a question regarding a task that you do not understand you may end up blocked by this for a long time which may have been fixed really quickly if only you’d asked. The repercussions could be:

Your team might miss a sprint goal or particular objective
You may be perceived as underperforming

As long as you keep communicating you’ll allow yourself to progress at a much faster rate and you’ll allow your co-workers to help you too.

3. Be enthusiastic

As a junior developer, you’ve been hired under the premise that you have little to no experience and you will require extensive training and development. Although there isn’t huge (there shouldn’t be) pressure on you to perform and be highly productive at this stage, this is still a crucial time, and you should be looking to show enthusiasm for what you’re doing.

Enthusiasm is a fairly broad term so we can refine this a little more with a few examples:

Willingness to jump out of your comfort zone
Eagerness to learn new languages and technologies
Willingness to lend a hand even if you haven’t been asked to do so

Your fellow developers are way more likely to want to invest time in you and your progression because of this. Helping you to improve benefits the whole team not just you.

4. Ask good questions

This one seems a little silly but is in fact a skill in itself. Being able to ask good questions is incredibly important for all developers, especially juniors. Naturally, being new to the industry and new to a job you’ll have a ton of questions that you will want to and need to ask. Inevitably, if you’re constantly nagging the developer next to you with questions there’s a high chance this will become annoying for them - especially if you’re asking questions in a certain way. It helps to follow a few key question asking rules:

Prove you've tried

Before asking make sure you’ve actually spent some time trying to answer it yourself. This is especially poignant for coding questions. It might help to actually write down what approach you have taken, what issues you’ve encountered, and what you think the solution might be. When you ask, you can go over each of these points and whoever you’re asking is way more likely to want to help you because this shows you’ve actively made an effort to solve something independently. Here's an example:

Don’t

“I can’t get this h3 to center inside this div”.

“I'm struggling to center an H3 element horizontally and vertically inside a div. I’ve tried to use flexbox to do this. I have applied the flex display property along with justify-content and align-items center properties to the containing div but that hasn’t worked. I think it may be something to do with specificity. I’ve taken a look at the stylesheet but I’m struggling to find where the styles I’m applying are being overridden - if at all. Would you be able to point me in the right direction please?”

Batch your questions

Find the middle ground between asking questions too quickly and waiting too long to ask. Again, this is more relevant for coding specific questions. If you ask too quickly, you risk annoying the person you’re asking. And if you leave it too long you risk wasting company time and money. Seems like a catch-22, but there is a balance to strike - you’ll just have to work at it to find it.

Asking lots of questions is fine, but distracting the developer next to you with five questions in less than 10 minutes might be quite frustrating for them. Especially as context switching is a massive productivity drain for developers so it helps to be mindful of this. Instead, try to group/batch multiple questions together - you’ll find a lot of them will be related in some way too.

Please don’t let my advice put you off asking questions! Developers like to have their egos stroked (at least a little), so asking them about things they probably already know will usually result in you learning something valuable.

5. Find a mentor

If you’re lucky, maybe you'll be assigned a mentor at your new job. If so, then great! Please make use of them, they will likely have a wealth of knowledge surrounding not only the development side of things but also domain/company-specific knowledge that will help you settle in and progress in your role. I’d really encourage you to ask about this before starting your new position. Having a point of contact and someone to go to for questions regarding your progression and any pain points is really useful.

If you don’t have access to a mentor, all is not lost. If you play your cards right, often the more experienced developers you work with will become your de-facto mentors - especially if you’ve built a strong working relationship with them.

Final thoughts

As a developer you will always be required to learn new things, it’s the nature of the job. However, this learning experience is intensified for a junior developer given there is so much to learn and adapt to. It’s not just the new frameworks, libraries, and languages but it’s also working in a cross-functional team, working with other developers, working with a client, or with a business product. These things are really tough to become good at if you’ve never had a job as a developer.

Ultimately you need to be willing to step out of your comfort zone. Be enthusiastic about it and make sure you communicate your progress (or lack of). This will enhance your learning and rate of progression, ensuring your experience as a newly hired developer is a positive and rewarding one.

Thank you for reading!

If you enjoy reading my content and want to support my work, please follow me on Twitter 😊

Maximise your code-learning process by embracing frustration

James Robinson — Wed, 27 Jan 2021 17:28:39 +0000

With the availability of free online learning resources, it’s now ‘easier’ than ever to learn how to code. But is it really that easy? I can confidently tell you that it’s not. Self-learning is extremely difficult. That doesn’t mean I would advise against trying it.

A self-directed learning process is inherently tough because you need to pick what you’re going to learn and what you’re going to learn from. A degree course or bootcamp handles this for you and so, it’s one less thing to worry about. The sheer quantity of learning materials and resources can become a blessing as well as a curse. Because there’s no structured pathway set out for you, not only will you have to manage finding the best resources but you’ll also have to manage your progression through concepts and topics with increasing levels of difficulty and complexity.

With a degree programme, difficulty usually progresses incrementally over time, in general, you’ll find more foundational concepts and topics covered within your first year, by the second and third years the workload and intensity of learning increases, many of the topics and concepts that you’ll learn will be more complex and often build upon things you learnt at the beginning of your programme. I’m not suggesting that this is the gold standard for effective learning, but at a minimum, it does provide a structured pathway.

Ultimately, this is why self-teaching is tough because you’re not forced by anything – you’re going to have to guide yourself towards coding competency. You’re totally accountable for your own progression, and if you’re learning to code with the intention to land a job, you’ll need to ensure you acquire the skills necessary to become an employable developer.

The honeymoon phase

When you first embark on your code-learning journey there's a conflicting mix of discomfort and excitement. The excitement is often perpetuated by beginner-friendly courses and tutorials that hold your hand as they gently guide you through this strange new world. You’re exposed to new concepts, topics, and syntax in a safe and controlled environment. This is a very support-intensive process that’s very easy to become dependent on. The problem with hand-holding processes is that they don't last forever (at least they don’t if you want to progress).

Tutorials and courses can’t do the work for you, that’s up to you. And so, before long the novelty and excitement that often accompanies starting something new gradually wears off and this tends to happen almost as soon as the hand-holding honeymoon phase ends. Once you begin to tackle concepts and topics that are more challenging, this is when progress begins to stall and motivation levels tail off.

Learning is only worthwhile if it’s deliberate and focused

Learners often give up after this honeymoon period not because they lack the talent or capabilities to become a developer, but because of inefficient learning practices.

Learning for the majority of us is incredibly tough. We all learn in different ways, and this is true, but different ways do not necessarily mean ‘effective’. Most of our learning approaches are passive which limits our ability to progress. We’re in a constant battle with our brains. Our brains are naturally hard-wired to pursue the path of least resistance, to find the easier, most dopamine laden routes. It’s your greatest asset but can be your greatest enemy too. Passive learning is an ideal middle ground that seems to appease both parties. It appeases you because you’ve made a deliberate effort to learn, to sink some time into something (your inner-voice is happy) whilst your brain is appeased because it doesn’t have to work too hard to structure any new knowledge or learning.

Let’s define what we mean by passive learning within a coding context:

Watching tutorials or courses
Reading articles or books
Code along exercises
Learning things you already know

These passive approaches may work for a seasoned developer but for beginners, these approaches are often very ineffective. You’ll find ‘practice’ thrown into the mix to counter passivity but it’s not quite as simple as that. What do we even mean by practice?

All practice is not the same. You’ve probably seen more experienced developers regurgitate the trite expression that “practice makes perfect”. The problem is, it often doesn’t. Practice often follows a standard convention of mindless repetitions over content we already know or we’re already very familiar with. We do this because it makes us feel good, it makes us feel smart, it’s a dopamine trip for the brain. We end up mistaking these positive feelings for growth and progression. We often employ regular, repetitive practice as a means to mindlessly memorise content. Mindless repetition and memorisation cause problems because we fail to solidify our understanding of something. If you understand how and why something works it becomes much easier to structure that knowledge.

Enter deliberate practice. It has a huge amount of research and information behind it. Anders Ericsson coined the term while researching how people become experts. His 1993 academic publication has sparked much research and writing on the topic. James Clear has also written in great detail about this and I’d encourage you to read his awesome introduction on the topic which also contains some useful real-world examples.

To summarise, deliberate practice differs from conventional or regular practice because it is:

Purposeful
Systematic

In layman's terms, deliberate practice is basically doing things that aren’t necessarily enjoyable. Within a development context, there might be some variations in how we apply deliberate practice but in my opinion, it means figuring out what needs improvement and then focusing on improving that thing until you’re confident with it.

For instance, if you’re learning JavaScript and you’ve built a small todo app project (which naturally involves a fair amount of DOM manipulation) make sure you perform a retrospective on your project. Reflect on your understanding of the topics and concepts covered – do you really understand the DOM? Identify any pain points, any areas you struggled with and actively work on them. You don’t have to necessarily apply this process to a project, you can constrain this to a particular topic or concept – I’d actually encourage you to do that instead.

The hardest part of deliberate practice is the frustration and discomfort that comes with it. Ultimately, to be able to grow and improve in a meaningful way there has to be some experience of uncomfortability. This is all part and parcel of growth and we should expect to experience some degree of discomfort – you should in fact welcome it. When you work on something that is outside of your current skill level this naturally comes with a fair amount of struggle.

Dealing with the discomfort of frustration

Frustration and coding come hand in hand. Coding is a constant test of patience. Within a front-end development context, building a performant, accessible, and pleasant experience for users isn’t an easy feat. There are lots of moving pieces, lots of things you’ll need to consider as well as understand, so naturally, you’ll often encounter frustration.

Beginners treat frustration and discomfort as a sign of failure, they become stuck and often become disheartened and unhappy with their lack of progress. A common trait I’ve seen amongst successful developers that I’ve worked with (as well as successful students that I've mentored) is a high tolerance to frustration.

Ultimately, you must accept that frequent points of frustration are unavoidable in this profession. It all comes down to reframing the way you think about coding and how you channel as well as manage frustration. The first step is to readjust your expectations of coding. It's totally normal to feel constantly frustrated. The second, but most important step is to see frustration not as the enemy but rather, as a necessary side-effect of growth. There aren't many situations I can think of where growth in a particular discipline isn't accompanied by some level of discomfort or frustration. With this in mind, see frustration as something to continually seek out. Frustration is a fantastic marker for progress and a strong indication that you’re working outside of your comfort zone – all steps that are a necessity for growth.

Once you've embraced frustration, you'll naturally develop patience and resilience which are highly desirable qualities for a developer. Having the patience and resilience to methodically work through a complex debugging issue is an incredibly important skill, that’s why developers are paid good money!

Final thoughts

There’s a great deal to unpack here, and I feel like a lot of what I’ve touched on probably deserves some deeper exploration. For now, I’ll leave you with what I feel are the most important takeaways.

Practice can make perfect

Remember there are different forms of practice. Mindless repetition over content we already know is an inefficient code-learning mechanism. Successful learners often employ a deliberate approach to practicing which is systematic and purposeful – an approach that intentionally seeks out discomfort.

Build tolerance to frustration

Reframe the way you think about coding, it is a frustrating profession. Try to seek out frustration and discomfort because it’s one of the best markers for learning progression. If you’re frustrated there’s a good chance you’re reaching outside of your comfort zone. This is the sweet spot for learning.

In the end, there’s no one quick trick for achieving success (as with most things in life – coding included) but there are patterns and skills that do often differentiate the successful from the unsuccessful, and within a coding context the successful generally have a high tolerance to frustration and often engage in deliberate practice. What we’ve covered doesn't necessarily just apply to newbie coders, improving your learning practices and reframing the way you see and experience frustration can help developers of all experience levels.

Enjoy coding and embrace frustration!

Thank you for reading!

If you enjoy reading my content and want to support my work, please follow me on Twitter 😊

How to escape from tutorial land

James Robinson — Thu, 14 Jan 2021 10:36:23 +0000

So you’ve decided you're going to learn how to code and you’re going to teach yourself. You curate a small list of tutorials that you plan to start watching. You’re feeling super excited about your code-learning journey, you start working through your list - everything is going well and things seem to make sense. You end up having to rewatch a couple of videos as a few more advanced concepts start to rear their ugly heads. Nevertheless, you persevere and you manage to get through most of the tutorials. You’ve religiously followed them through, you’ve spent weeks doing so - months even. After finishing and feeling really impressed with your progress, you come up with a project idea. With this idea, you then decide to try and create something on your own, and all hell breaks loose. You hit a brick wall, you feel disheartened, and now you're thinking you don’t know anything at all.

Sound familiar? I’ve been there and I’m sure the overwhelming majority of self-taught developers have too. You’re stuck in tutorial-land or even ‘tutorial-hell’ as some term it. Don’t fret, and certainly don’t give up - you will be able to escape from this common trap that beginner coders find themselves in.

Hello brick wall my dear friend

The first thing you need to recognise is that this proverbial brick wall is actually your best friend. You need to embrace the frustration and the sometimes helplessness that comes with it. Ultimately, this is where the real learning happens. In a real job, this is exactly what you’re going to come across all the time. You’ll need to solve problems that you aren’t sure how to solve and you’ll be doing it with deadlines looming too. For those that are self-teaching, once you recognise this situation is totally normal and expected then you can seek methods to overcome it.

I’m not suggesting tutorials aren’t useful, nor am I suggesting you shouldn’t watch them. Tutorials are useful for learning syntax and/or the basic foundational concepts behind certain technologies. Plus they’re great to get a quick overview of what a certain piece of tech does and how that may fit into the whole front-end landscape. They certainly provide a solid platform to work from. But in the end, they won’t do the work for you and there is no way you’re going to be able to watch tutorials, passively code along and magically develop the skills needed to bag yourself a job.

For you to truly understand something you will need to practically apply what you’re learning and doing so will improve your understanding and cement those concepts. Those that are self-teaching probably already recognise this, and are most likely being encouraged to build code-along projects as part of some tutorials. In my opinion, this isn’t always the best way to learn - it’s a very passive learning experience and all too easy. A lot of students that I mentor often tell me that they watch tutorials and code along but still feel like they’re not actually learning. If you’re learning how to code and you aren’t constantly hitting your head up against a brick wall then you’re doing something wrong. In reality, the process is enjoyable but also very challenging, frustrating, and at times incredibly tedious.

The truth is, being stuck in ‘tutorial-land’ or ‘tutorial-hell’ will most likely come down to a couple of things:

You are coming up with project ideas that are too ambitious for your current skill set
You are trying to learn too many things at the same time

Lower your expectations

If you’ve just started learning a new technology, let's say React for instance. You may have followed an extensive tutorial and you’re ready and eager to build a project using it - it may even be a project that you want to add to your portfolio and showcase to employers. I would almost definitely hold back on creating something too complex. Start with a very very simple app, and build lots of them. Lower the standards of the project you want to create, I guarantee the one you were thinking of was probably too complex for you at this time. With this approach you can focus on truly understanding the code you’re writing and because your project expectations are a lot lower you can focus on the things that matter.

Ultimately your goal should be to churn out lots of small, almost ugly projects that vary ever so slightly. After you’ve done this you might start finding the process kind of well, boring. That is a fantastic place to be! If the process becomes boring then you know it’s time to add some more complexity, but as mentioned make sure you’re realistic about this complexity, don’t go full steam ahead trying to build a full-stack CRUD app when you’re just starting to learn React.

During this process of churning out smaller apps, try not to copy and paste code. Be honest with yourself if you’re pasting code that you don’t understand. This will potentially bite you in the rear in the future especially when you’re trying to debug issues that involve that pasted code. This process might seem a little underwhelming. The thing is, a large part of effectively learning how to code is carrying out repetitive processes, being incredibly persistent, and practicing over and over again until it becomes second nature. That is how you cement what you’ve learned. Going forward, it will be much easier to build something more complex upon a solid foundation.

Try not to learn too many things at once

If you’re concurrently learning Vanilla JS, React, Angular, Vue, etc, how can you possibly find the time or have the mental energy left to learn any of these technologies thoroughly? I understand why people do this, they see junior developer job descriptions that list half a million technologies and skills so the logical approach is to start learning all of them. In reality, you may end up only working with a few of those skills, decent employers will be willing to give you a shot if you are well versed in the fundamentals and can show an appetite for learning.

Ultimately, you should aim to focus on one topic at a time, remove any unnecessary distractions, and eventually you’ll feel way more comfortable with the things you’re learning.

What next?

The goal for a lot of readers will be to land a position as a front-end developer. Having a semi-structured learning path will really help you achieve your goals. So far, we know that tutorials are useful for building base knowledge on a chosen technology or concept and now we know that building apps (that aren’t too complex) are a great way to cement those learnings. You’re probably thinking this is all well and good but at some point, you'll need to work with something more challenging.

Adding more complexity to the apps you're building may be one way of doing this. That’s great, but ultimately you want to get a job being paid to do this stuff, so your best bet is to try and replicate what you’d actually do in a real job as closely as possible. There are many analogies for this, I love mountaineering and when I’ve climbed some challenging mountains in the past, I always have to get myself into shape before-hand. The best way to get better at climbing mountains is to actually climb mountains. Seems simple and obvious enough, but so many people would head straight to the gym and jump on the treadmill. They might get super fit doing so, but once they put a 15 kg rucksack on their back and have to climb difficult terrain up into the sky they’ll definitely struggle.

Your next step should be to try and replicate what you’d actually do in a real development job as closely as possible. Contributing to open source is a great way to do this. A lot of beginners are hesitant about open source, there is a lot less hand-holding than the tutorials provide and it can be a pretty scary prospect. I’d encourage you to persist and try and find a project (it doesn’t have to be mega-popular or incredibly complex) that interests you and try and make a contribution in some way. This could be:

Improving documentation
Suggesting a new feature
Reporting bugs
Fixing any pre-existing bugs

You may be unsuccessful, maybe the maintainer(s) aren’t interested in your fixes or suggestions. Do persist because you will find a project that you will have success with. Even if you don’t, you would have acquired some really useful skills in the process. I plan to write in more detail about the whole open source contribution process soon, so watch this space.

Final thoughts

This idea of ‘tutorial-land’ or ‘tutorial-hell’ probably doesn't even exist, it will most likely come down to your own project ideas that are a little too ambitious for your current skill set. On top of this, you’re also probably trying to learn too many things at once. The outcome of this will leave you demotivated and unsatisfied with your learning progression.

Stepping out of this safe, guided environment is tough, but by doing so your progress and the quality of your learning will almost certainly improve. There isn't a one-trick approach to learning how to code. Tutorials are a useful tool amongst many that you should be utilising - it boils down to you being able to recognise when you should reach for them whilst understanding their limitations.

Thank you for reading!

If you enjoy reading my content and want to support my work, please follow me on Twitter 😊

How do you know when you’re ready to apply for front-end developer positions?

James Robinson — Fri, 01 Jan 2021 15:05:28 +0000

When I was learning front-end development I would Google this question often. When you’re teaching yourself it’s a lot more difficult to measure your own ‘readiness’. When you take a course or attend a bootcamp it’s easier to define this because there is a set start and finish. Those that are self-teaching will have to define this for themselves.

Many factors play into this state of ‘readiness’. The main factor is people's own expectations, one developer's definition of ready may be the complete polar opposite to another’s. What really matters to us is what employers think. In this article, we will attempt to produce a definition to put your mind at ease.

My own experience

I am completely self-taught with no previous relatable experience in tech. I did build my own computer many moons ago but that had little bearing on my ability to code, I’d just about heard of HTML!
It took me around 11 months to land my first position and on reflection, I felt I could have started applying for roles a little sooner than I did. I was all too focused on trying to perfect my knowledge and get to a place where I considered myself to be ‘ready’.

The truth is, you’ll probably never reach a place where you are entirely happy with your readiness. If I had waited until I felt ready, my hair would be white and I’d be collecting my pension and I’d still be asking the same question. Thankfully my hair is still (mostly) brown and I have a few more years before I can start collecting my pension. Ultimately, it's about learning just enough to land yourself a job - you'll learn so much faster once you have one.

Defining ‘ready’

If you are seriously willing to put in the time to learn, you’ll inevitably give yourself the best chances of landing a junior developer position. My definition of job-ready would look something like this:

Thorough knowledge of HTML, CSS, and JavaScript (especially JavaScript)
An understanding of web accessibility
Some experience with a JavaScript framework/library
Some understanding and experience with build tools, task runners & preprocessors
Willingness and aptitude to learn
Passion and enthusiasm for development
A portfolio of projects to showcase coding ability
Some open-source contributions (probably a nice-to-have)

Let’s have a look at each of these criteria in more detail:

Thorough knowledge of HTML, CSS, and JavaScript - especially JavaScript

You can’t cut too many corners here - this is your bread and butter. These are the core browser technologies, and this is where you will be spending your time as a front-end developer. Whatever job you take, whatever framework, templating system, or library you work with, you will be utilising these technologies - even if there is a fairly thick layer of abstraction over them.

For those that are looking to become UX-focused front-end developers you’ll probably want to centre more of your time toward the HTML, CSS side of things. For those wanting to become JavaScript focused front-end developers (now commonly termed ‘front-end engineers’), you’ll want to point your focus toward JavaScript – make sure you learn the fundamentals, as well as more advanced concepts such as closures, prototypes and inheritance, promises, etc.

Some experience with a JavaScript framework and/or library

This is probably the most contentious of all of the items on this list. It’s become very common for job descriptions to ask for proficiency or some experience with a front-end framework or library (usually, Angular, Vue, or React. Sometimes jQuery is thrown into the mix even though it’s a less opinionated utility library).

I’ve compiled some results on a random selection of 20 job adverts (for junior front-end developer positions advertised in the UK), to see what proportion place an emphasis on JavaScript frameworks as an essential prerequisite for the job.

Personally, I wouldn’t lose too much sleep over this one. As you can see there are plenty of jobs that look for JavaScript proficiency in general, rather than tied to a specific framework.

If you’ve got the basics nailed down, then by all means have a play with a framework that takes your fancy. Build a small project to show you can pick up some new tech and make something productive. Ultimately, you’re applying for junior developer positions so there shouldn’t be too much expectation on you to know a wide range of frameworks.

An understanding of web accessibility

Thankfully, more companies are now taking the accessibility of their websites more seriously. Inaccessible websites shouldn't just be the responsibility of designers. As front-end developers, it is important that we take web accessibility seriously and with the growing complexity of the front-end landscape sometimes accessibility get's left behind.

You don't need to be an expert, but showing an understanding and appreciation for web accessibility will certainly help once you start applying for positions. The chances are high that you'll be asked a question on this in an interview too.

Some experience with build tools, task runners, and preprocessors

Junior front-end developer job descriptions tend to have this listed as a nice-to-have skill. If you have a general understanding of their purpose, when you’d probably reach for one and how they generally fit into the front-end tooling landscape then this is probably enough to satisfy most employers. If you’ve already picked up a front-end framework, then you almost certainly will have used some form of build tool/bundler such as Webpack anyway.

Willingness and aptitude to learn

If you’re not willing or capable to learn new things, then you’ve definitely picked the wrong industry! Don’t panic if you think you’re a slow or ineffective learner – you can get better at this.

Remember, skills and technologies will come and go, but if you are able to learn and adapt then you’ll be extremely sought-after and your career will be more on your terms.

Passion and enthusiasm for development

You’d be surprised how many people there are working in the industry who aren't passionate or enthusiastic about what they do. If you’re in this for the money and the job opportunities alone, then it’s going to be a bumpy ride.

When the poop hits the fan and you have a deadline looming and you can’t get your code to compile or you can’t fix a release-blocking bug then you’ll hate every minute and wonder why you even got into this industry. Development is tough and it will be a lot tougher if you have no passion or enthusiasm for it.

A portfolio of projects to showcase coding ability

This is your time to impress prospective employers and let your code do the talking. You don’t necessarily need to have a dedicated portfolio site, you could just pin some of your best repositories on your GitHub profile and share that with employers.

Don’t sweat too much about code perfection, but do make sure the code you write is DRY. It should be maintainable and clean (if you can write some tests too then extra points for you!). Ultimately the proof is in the pudding, if an employer can actually see you know how to code and you can do so without potentially causing an immediate firestorm then they are more likely to give you a shot.

Some open-source contributions (probably a nice-to-have)

Although I’ve listed this as a nice-to-have, I would strongly encourage you to get involved with open source projects. Your contributions don’t have to be substantial. Even contributing documentation is a hugely worthwhile endeavor that many library authors will be grateful for.

Contributing to open source can be a scary prospect for beginner developers. Too many beginners find themselves trapped in tutorial land, spending too long passively churning out todo apps - this can be a hard trap to escape from. I’m not saying tutorials aren’t useful, it’s just that contributing to open source is pretty much as close as you’ll get to being a professional developer. Depending on what libraries/frameworks you end up contributing to, your contributions could be considered genuine work experience.

Making open source contributions will require you to have been exposed to a few important conecepts, practices, and transferable skills:

Version control
Working with tickets & issues
Working with professional developers
Creating pull requests
Experiencing a code review process
Setting up a local development environment
Contributing code to a pre-existing codebase

This is essentially what you’ll be doing in a real job, so having these experiences will stand you in good stead once you begin applying for roles. It already proves that you have what it takes to write code at a useful standard.

Final thoughts

If you can tick off most of the criteria in my ‘ready’ list, then you’ll probably be set to start applying for positions. The length of time it takes to get here will be highly individualized and will depend on whether you can commit to learning full-time or part-time, so your mileage will vary. Don’t become too fixated on time and hours invested. Although there will be a correlation between time invested and progress, time spent is not always the best measure of progress. Likewise, don't fuss over every item in the list, if your learning processes are polished and you think you’re ready to start applying a little sooner than you originally envisioned then I would encourage you to go for it.

The job searching process probably warrants an article of its own but for now, just bear in mind that to many companies, entry-level really means 'senior-level experience at an entry-level salary', so don’t become too disheartened when you get rejected for positions. Persist, keep learning and you’ll eventually land a job.

Thank you for reading!

If you enjoy reading my content and want to support my work, please follow me on Twitter 😊

Everything you need to know to become a front-end developer

James Robinson — Sun, 20 Dec 2020 17:46:39 +0000

Now, more than ever, people want to learn to code, with many hoping to be skilled enough to land themselves a job. A sizeable proportion of these individuals will be looking to become front-end developers. Even in these difficult times, the market still looks good - the ongoing skills shortage for developers isn’t going anywhere anytime soon.

With this said, due to the proliferation of coding boot camps and online self-teaching resources, the market for junior front-end developers is very competitive. I wouldn’t let this dishearten you; it just means you’re going to have to do a little more to make yourself stand out from the rest of the candidates applying for each position.
This guide is intended for those thinking about learning front-end development and for those who have already started. We will define what a front-end developer does, and the skills necessary for the job. Knowing this will enable you to plan your learning processes more effectively and set realistic goals and expectations.

The current front-end developer landscape
Which skills should you learn
Learn to focus on what matters
The rarely talked about skills
Conclusion

A little context

Historically, front-end developers worked extensively with HTML and CSS and with a little bit of JavaScript sprinkled in for good measure. Nowadays, as the web has evolved and matured, applications and websites have become increasingly more complex. With this increase in complexity, the scope of responsibility of modern front-end developers has shifted. It has caused a slight, albeit noticeable, divide in the type of front-end developer. On one side, you have a developer, whose work is heavily focused around JavaScript and the many libraries and frameworks that are built with it. On the other side, we have developers whose work is targeted more toward HTML, CSS, design, and accessibility. You may see these types of front-end developer roles termed ‘UX’ or ‘UI’ developers. Those front-end developers, who live largely within JavaScript-land, are increasingly referred to as front-end ‘application developers’ or ‘engineers’.

It’s worth noting that this is not always the case. The split is not as refined as the one between the front end and back end - there are still plenty of ‘front-end developer’ titles on job adverts. I’ve drawn attention to this current trend, mainly because it may help shape which technologies you wish to focus on, and indeed later, what types of jobs you will apply for. Regardless of this distinction, front-end developers will always be confined to the browser – that is something we can be sure about.

Let's talk about skills

As a front-end developer, your job and your ultimate focus is to make things work well within the browser - with the end goal to deliver a pleasant, performant, and accessible experience for users. Regardless of the myriad of skills that are listed for front-end developer (and its variations) job adverts, HTML, CSS, and JavaScript are the fundamental technologies the browser uses to transform basic text content into the web page you see within your browser. Whether you work directly with these languages (for instance, HTML may come for a templating language, or CSS may be produced using a preprocessor) or not, having a solid understanding of them is vital for doing a good job.

Several front-end developer pathway illustrations are quite useful for gaining a more holistic overview of what’s required for the modern front-end developer. As you can see from the one below, there are quite a number of technologies and concepts here, and this is not necessarily the route I would recommend. However, many of these skills you’ll commonly find listed in job descriptions.

Learning pathway courtesy of GitHub user Z8264

Before rattling through each of these technologies, you should start with the basics - the very foundations of the front-end; HTML, CSS, and JavaScript.

HTML

Often overlooked, and probably deserves a little more attention than it gets. Make sure you have a solid understanding of HTML. It’s the very first file the browser parses before building out the rest of a website. It’s also the fundamental technology that provides meaning and structure to a webpage. You shouldn’t be focusing on memorising every element in the markup language, more importantly, you should understand its role in the front-end ecosystem, and how its semantic nature and structure can play a crucial part in making websites and applications more accessible to its users. You’ll also be using JavaScript often to alter the output of HTML in the browser, if you don’t know HTML; you will struggle to effectively alter it with Javascript.

CSS

Before venturing into using CSS frameworks such as Bootstrap, Tailwind, etc., and preprocessors such as Sass and Less, make sure you know how to write CSS well. CSS can seem easy enough at first, but gosh it can be deceptively difficult. Ask any developer working on a large codebase with thousands of lines of badly written CSS. Poorly written CSS can cause code bases to become bloated and difficult to maintain. But if you rock up to a new job having a solid grasp of it, diving head-first into some bug fixes shouldn’t be too much of a challenge for you. Once you have a good level of understanding, then I would recommend looking into preprocessors (and frameworks if you wish).

JavaScript

In the past, jQuery (a small and still very popular library) was enough to get the job done JavaScript-wise. It was more than sufficient to handle any basic client-side logic - for instance, toggling element visibility or basic animations. However, due to the incredible growth and proliferation of the JavaScript language, an enormous JavaScript ecosystem has developed. The growth of front-end frameworks and libraries such as Angular, React, and Vue is a direct result of this. So much so, it’s almost hard to imagine the front end without it. Even if you’re a more design-focused front-end developer you will need to interact with JavaScript at some point.
Front-end frameworks have certainly introduced more complexity into the front-end skillset, ultimately they require developers to have a much deeper understanding of programming concepts such as higher-order functions and functional programming. Frameworks generally require developers to manage and utilise a larger set of tools and concepts. A few examples would be:

Build tools (general framework tooling)
Client-side routing
Component driven design patterns
State management
Testing (unit, integration, and end-to-end)

This is not to say that these types of concepts have/are not used outside of frameworks and libraries. It's just that more often than not we find these concepts and patterns baked-into the frameworks and libraries as part of their overall coding philosophy and paradigm. One thing is for absolute certain, you need to have a solid foundation and understanding of JavaScript if you want to become a JavaScript focused front-end developer. That sounds a little self-evident given the above are all JavaScript frameworks and libraries. But the thing is, when dealing with the likes of React, Vue, and Angular a lot of the time you have to follow a fairly restrictive and directed coding approach (for instance, React relies heavily on functional programming concepts), mainly because this is prescribed by the frameworks themselves. This isn’t necessarily a bad thing, we may write code the ‘Angular way’ or the ‘React way’ because in the long run, it’s easier and quicker to build maintainable and performant applications and websites. But there is a caveat to this. These frameworks and libraries can often create a layer of abstraction over plain old JavaScript behind the scenes - which may not be ideal for a beginner. Given this, your best approach is to develop a solid understanding of JavaScript before reaching for a framework. This is incredibly beneficial for a couple of reasons:

You'll learn said framework much quicker
You’ll be able to pick up new JavaScript frameworks and libraries quickly
You’ll be able to debug JavaScript issues more effectively

Do not try to learn everything

Probably by this point you might be feeling a little overwhelmed with it all. Maybe you had no idea where to start and what to learn in the first place and now you have all these crazy lists of technologies and complex diagrams and your brain is freaking out. Well, don’t panic just yet! Here’s the thing with all of these complex roadmaps and pathway diagrams, there are too many technologies to learn in a great level of detail – which is particularly relevant for newbie coders. What’s more, is having a broad but shallow understanding of many front-end technologies better than a deep and thorough understanding of the core, fundamental technologies? I would argue that it is not. I’m sure some would disagree.

I'm not suggesting you don't learn a front-end framework. I just believe you shouldn't learn it for learning's sake - and certainly not before you've developed a reasonable understanding of JavaScript. Ultimately, there is one prevailing topic that we have to manage as front-end developers, and that is keeping up with the forever changing landscape and the increasing number and scope of technologies used to build websites. It’s been termed ‘front-end fatigue’ in the past. I would say it is our approach to learning (along with some other less talked about skills), that will enable us as front-end developers to adapt and also to enjoy learning new tooling, frameworks, and libraries as they inevitably appear.

Bear in mind, there is a real chance you’ll get a job somewhere and find out that you’re not going to necessarily be working with all of the latest trendy frameworks. Let us imagine you did in fact start work on a cool, hip, React project at a fictitious workplace. You work on it for six months and you begin to feel pretty comfortable with the project. Maybe the project has neared completion, it’s started to mature and you’re feeling pretty content. Suddenly, your boss calls you in for a meeting and tells you that the company needs you to jump onto another project starting next week. That project will be using Web Components (the native web approach to building components).

Now, this situation will be much easier for you if you have a deep and thorough understanding of JavaScript and a great approach and process to learning new things. As a result, working with Web Components won’t be too difficult for you. Sure, it will take you some time to get to grips with the change of scenery and a new way of doing things but nothing you won’t be able to manage. Conversely, if you didn’t have a solid understanding of JavaScript, and instead you opted in your learning pathway to follow the ‘framework chaser’ approach, spending almost all of your time learning different frameworks, then you might just find yourself in a bit of a pickle.

Now, I’m not saying you wouldn’t ever be able to understand how Web Components work, I’m sure you would. All I’m suggesting is that it will be much easier for you if you focus on learning JavaScript in-depth, that’s what all of these frameworks and libraries are ultimately built with. I’m sure there will be some argument against this, especially from those who want to become solely React focused developers. That’s cool, but React will also evolve and change over time and new features will be released. Components in React were largely built using Classes, but after the release of Hooks, entire React applications are now built with only functional components. Both of these approaches require a solid knowledge of JavaScript.

What am I suggesting then?

Aside from having a thorough knowledge of the fundamental front-end technologies, (HTML, CSS, and JavaScript) it is also useful to have another set of less talked about skills. These skills – in my opinion – are just as, if not, more important. I’ve put my first-rate drawing skills to the test below and mapped out my own skill diagram.

We’ve already covered code-related knowledge, so let’s talk a little about the rest of the skills:

1. Ability to learn

Your approach and ability to learn is critical to you becoming a great developer. Front end, back end, full stack, whatever stack, being an effective learner will enable you to keep up with changes in the tech landscape and also make you super valuable as an employee and prospective employee. Many of us believe our ability to learn is an innate skill that cannot be improved. This isn’t the case! I’ve written in more detail about this with some useful tricks and tips for improving your learning processes. If you are good at learning you'll embrace the chance to learn new things, and importantly, you'll be highly adaptable. Remember, a career in development means a career of learning - professional developers feel that way too.

2. Debugging skills

This one seems a little broad, but ultimately you’ll spend a lot of time as a developer debugging the code you’ve written and the code another developer wrote many years ago. In-depth knowledge of the codebase and the languages you are coding with will obviously help with this skill. Also having a methodological approach to debugging can be very useful. Being good at debugging code is almost a necessity rather than an option, it's about having the patience to test out your assumptions until you find the bug. As a front-end developer, you should be comfortable using the developer tools in whatever browser you like to code with (I prefer Chrome developer tools). Make use of the debugging features available such as breakpoints, debugger statements, and stepping through code.

3. Ability to read source code

More often than not you will be working on a pre-existing codebase. It may contain tens of thousands (maybe hundreds of thousands) of lines of code that many developers have written. Quite frankly it might be one giant, messy pile of spaghetti code.

Being able to read and make sense of source code will help you quickly become productive on projects and codebases. When working on a real project, most of your time will be spent reading, not writing code. Becoming good at reading source code is a fast way to not only get to grips with the codebase and project at hand but to also learn and improve in general.

4. Asking the right questions

This one might seem a little silly, but it’s a very important one - particularly for junior developers. It’s not only the practice of asking the right questions that is important but it’s also when to ask the right questions that is equally important. When you’re working on a real project you’ll most likely be working with a team of developers. Some developers are easier to work with than others (this goes for working with people in general) and to ensure you keep your teammates on your side, make sure you don’t ask a question every two seconds. Prove that you’ve spent some time trying to solve a problem yourself. It might be useful to write down what approach you have taken, what didn’t work, what you think the problem might be, and if you have an inclination toward a potential solution. This shows whoever you are asking a few things:

You actually care about trying to solve something independently
You’ve made an effort

When I first started as a junior front-end developer, (depending on what I was working on) I would often use what I termed the 30-minute rule. Essentially, I would give myself 30 minutes to try and solve whatever I was stuck on. If I had made no progress, hit a real roadblock, and exhausted my own research, I would ask another developer for help (admittedly I was also super lucky to work with an awesome, talented, and extremely helpful team of developers at Potato). This way, we save some company time and money by solving something a little quicker. Your team will thank you in the long run because you managed to unblock yourself and carry on with your work.

5. Communication skills

This skill ties in with what I mentioned above. Being able to communicate when you’re stuck (‘blocked’ as it is termed in the industry) will be crucial to you and your team delivering work and meeting deadlines on time. Being able to communicate early on when you do not understand a particular task or goal will also help to ensure you are more effective as a developer and you that you don’t stress yourself out too much.

There is more to communicating than just being able to raise any issues or blockers you may have. Being friendly and approachable, whilst being able to effectively explain complex concepts in an easy to understand way, will help others better understand you. This is also a really important skill for those looking to one day become mentors.

Final thoughts

Learning front-end development shouldn’t be a stressful, overwhelming experience. By focusing on learning too many technologies you will end up developing a broad and shallow understanding. In my opinion, you are best placed, developing a deep and thorough knowledge of HTML, CSS, and JavaScript, whilst working on additional skills that are often less talked about – namely, your learning ability, debugging skills, ability to read source code, ask good questions and your communicative skills. If you feel ready to pick up a framework, only do so when you have a solid understanding of JavaScript. If you get caught up chasing the latest industry buzzwords you’ll end up losing sight of what it takes to become a great developer.

My advice might seem a little contradictory. On one hand, I'm telling you that the tech landscape is constantly changing and you need to be able to adapt to this, and on the other, I'm suggesting you focus on learning the core technologies. Trying to learn everything is a fast way to burn yourself out. If you can learn the fundamentals inside out and work on the other less talked about skills, the world will become your oyster. You'll be able to learn and adapt to whatever's thrown your way.

One thing is for certain, you will always be required to learn new things; you’ll never get to a point where that will suddenly stop. As my good friend Heraclitus said many moons ago, "the only constant in life is change". Some employers may be looking for a candidate that is an expert in many different frameworks and libraries. Likewise, a lot of great employers will also be looking for developers who have excellent foundational knowledge, are highly adaptable, quick learners, and who are ready to dive into a codebase and get up to speed and contribute quickly.

Thank you for reading!

If you enjoy reading my content and want to support my work, please follow me on Twitter 😊

Improve your learning ability to help you learn to code

James Robinson — Wed, 16 Dec 2020 12:16:43 +0000

It's something we are all guilty of. We watch a video, attend a lecture, or read an article on a subject matter we wish to learn. More often than not, when it comes to an end, we feel a small sense of accomplishment that we have learned something - we close our laptop or our book and we carry on under the assumption that we have furthered our knowledge on the subject at hand.

The truth is, for a lot of people, this process is extremely ineffective. In fact, it is the way that we approach learning and subsequently the learning processes that let us down. Whilst a lucky minority have an innate ability to easily absorb information, it is not so straightforward for the rest of us. But it doesn't have to be that way. Learning is a learned behaviour and because of this, we can become better at it. Doing so could make all the difference in your coding journey. It may not make you the next coding prodigy, but almost certainly, it will make you a better developer.

Start with honesty

Improving your ability to learn can only ever work if you're honest with yourself. I know, I know, it sounds a little cliche I hear ya. But think about it, if you're truly honest with yourself (and this doesn't always mean being highly critical) this will open up many doors that will inevitably lead to self-improvement.

In the context of learning to code, this will become crucial - not only as you learn to code initially, but also throughout your career as a developer. Your ability to learn, and learn well, will be incredibly important to you as a developer. From the perspective of a front-end developer, this couldn't be more true. The tech landscape on this side of the stack is forever changing, maturing, and evolving. With new frameworks and libraries launched almost every day it seems, at some point in time you will almost certainly be required to learn something new, be it for a business purpose at work, a side project, or even for a new client.

Improve your learning process

Now you're totally cool with being honest with yourself. Whatever you're currently learning there is always an improvement you can make to your processes (or lack thereof). For instance, let's say you want to teach yourself how to code, with the end goal of becoming a front-end developer. Let us assume you have a solid grasp of the fundamentals of HTML and CSS but now you wish to learn JavaScript. You decide to follow some online tutorial courses. The courses (like many) are structured as a progressive learning experience, i.e. you start with the very basic foundational concepts of the language and gradually move on to more challenging, tricky aspects. Whilst you rattle through a particular course, you are probably encouraged to build small, contrived projects as you go, and by the end of the course, you may work toward building something a little more substantial with the focus being to build upon the concepts you have covered during the course.

What often happens with this approach, is that you get some way through the course, maybe just past the foundational concepts (maybe not even that far) and you hit a roadblock. This usually occurs when one of two things happen:

You start to explore more advanced concepts
You try to build some application or small project

Sadly, a lot of people become disheartened, their progress stalls, they think they're not good enough, not smart enough to code and this significantly hampers their learning process - they may even decide to give up entirely. Some onlookers may be thinking that's fine, this is just a way to whittle out those that aren't up to scratch and shouldn't be a developer in the first place. Well, maybe in some cases that may be true, but for others, that is definitely not the case.

Most of these individuals will be self-teaching, they may be working a full-time job, have a family, and/or juggling lots of different things in their life all at once. The solution for these individuals is multifaceted, it isn't just a 'one quick trick solution'. One particular facet of this solution will be improving their learning process. Time management will be in there too. But in keeping with the main topic of this article, we will focus on the learning process itself. Here are five actions these individuals could take to improve their process:

1. Make notes as you learn

The notes you make could be handwritten or they could be typed. They do not have to be extensive, nor do they have to cover every nook and cranny of a particular topic. If you decide to write more elaborate and detailed notes then great, but most of the time a short list of key points and take-aways will suffice. Also noting down what you did not understand can be super useful, especially when you go back to reflect on these notes (which you should do). They could be as brief as the example below which looks at some key differences and similarities between let and const:

let and const are block-scoped
If I want a variable to be reassignable I should use let
When I do not intend for a variable to be reassignable I should always use const
Using const will help safeguard against involuntary reassignments

Make sure you look over your notes. It's best to have a quick look either a few hours after you've written them or the next day. Essentially, once you're pretty sure you've forgotten them.

2. Practically apply what you're learning

Whilst you're learning, open up the developer tools console, your IDE, or whatever coding environment you are using and test things out. For instance, using our example above, if const is useful for protecting against involuntary reassignments, actually test it out. See if the console spits out an error when you try to reassign a variable already declared with const.

If you're unsure of anything you're learning, always try and test out any assumptions you may have. Using developer tools is a perfect environment for doing this.

Practically applying concepts can be tough, and a real blocker for many beginners. It hurts your brain, and it's really easy to procrastinate at this point when things get challenging. As hard as it may feel, you should endeavor to embrace these uncomfortable feelings! This is where the real learning occurs.

3. Don't let time or fancy completion badges become your metric for progress

Just because you've completed a section in a course, watched an entire video, or even read through an article, this doesn't mean you've learned what you needed to. Even if you've spent x amount of your allocated learning time on a particular topic, doesn't mean you've learned what you needed to either. The best metric you have for moving on with a course, topic, or learning resource is whether you have understood the material. In most cases, this will take a lot longer than you initially anticipate.

What do I mean by understood? In my opinion, this means that you are able to verbally explain out loud the topic you're learning (this can still be fairly broad) and additionally, be able to explain this with code. Using our JavaScript variable example above, could you explain those concepts to yourself verbally? Could you also demonstrate that you understand said concepts with code in the console too?

Explaining something to yourself out loud can be a really useful learning tool. Mostly because it's quite uncomfortable and often you quickly realise how little you actually know about a given topic.

4. Once you have understood, move on

This is a super important point too. Don't become overly obsessive about understanding something. There is a fine line between trying to understand something and then trying to memorise something. I would advise against memorising programming concepts. There is too much content to memorise. Plus, there is no need. You have the internet at hand and a plethora of resources at your fingers tips to jog your memory if you have forgotten the name of a particular array method, for instance.

What's crucial, is that you feel comfortable with your understanding of a given topic. Once you do, you should move on. Having said this, if you thought you understood a topic and moved on, only to realise - when future content became more complex - that you actually didn't understand, then you should go back and cover that content again.

Conversely, if you did understand a topic, but at some point, your future self appears to have forgotten it, a Google search will jog your memory and you'll realise that in actual fact you only needed a quick reminder.

5. Beware of the rabbit hole

Finding yourself in a rabbit hole is a common occurrence in the development world. Learning when it's okay to venture deeper and when you should climb back out is the real challenge. For those teaching themselves to code, try to stick closely to the topic you are covering. Just learn what you need to learn for now. It's not possible to cover everything.

Using our JavaScript variable example above, you may find your research leads you to a variety of other concepts. Maybe your research lead you toward an important concept in JavaScript called 'scope'. If you have no understanding of scope at this time, it may be best to move on for now and come back to this more advanced topic when you are ready. Do note, I'm not saying you shouldn't learn about scope in JavaScript, I'm merely suggesting you focus on learning one topic (if you can) in detail at a time.

Final thoughts

Your best metric for your progress is achieving a solid understanding of your learning topics. As mentioned at the beginning of this article, for you to be able to improve your learning ability you need to be honest with yourself when you don't understand. Following the learning points above may seem time-consuming and overly cumbersome, but in reality, you'll save time in the long run. Even better, you'll gain a deep and thorough understanding of many development concepts that will stand you in good stead for a career of learning.

Thank you for reading!

If you enjoy reading my content and want to support my work, please follow me on Twitter 😊

DEV Community: James Robinson

5 tips for acing your first year as a junior developer

1. Prepare for a mindfork

Keep notes in a markdown file

Ask for direction

2. Communicate

3. Be enthusiastic

4. Ask good questions

Prove you've tried

Batch your questions

5. Find a mentor

Final thoughts

Maximise your code-learning process by embracing frustration

The honeymoon phase

Learning is only worthwhile if it’s deliberate and focused

Dealing with the discomfort of frustration

Final thoughts

Practice can make perfect

Build tolerance to frustration

How to escape from tutorial land

Hello brick wall my dear friend

Lower your expectations

Try not to learn too many things at once

What next?

Final thoughts

How do you know when you’re ready to apply for front-end developer positions?

My own experience

Defining ‘ready’

Thorough knowledge of HTML, CSS, and JavaScript - especially JavaScript

Some experience with a JavaScript framework and/or library

An understanding of web accessibility

Some experience with build tools, task runners, and preprocessors

Willingness and aptitude to learn

Passion and enthusiasm for development

A portfolio of projects to showcase coding ability

Some open-source contributions (probably a nice-to-have)

Final thoughts

Everything you need to know to become a front-end developer

Table of contents

A little context

Let's talk about skills

HTML

CSS

JavaScript

Do not try to learn everything

What am I suggesting then?

1. Ability to learn

2. Debugging skills

3. Ability to read source code

4. Asking the right questions

5. Communication skills

Final thoughts

Improve your learning ability to help you learn to code

Start with honesty

Improve your learning process

1. Make notes as you learn

2. Practically apply what you're learning

3. Don't let time or fancy completion badges become your metric for progress

4. Once you have understood, move on

5. Beware of the rabbit hole

Final thoughts