Consume, Build, Teach

A learning process to help you develop as a developer

Subscribe to my newsletter and never miss my upcoming articles

I’m keen to get back into writing about new stuff I have learnt as it may potentially help others, but mainly it helps me solidify my knowledge and further understands that which I was learning. I was listening to a Fixate podcast with Kent Dodds earlier in the week and Kent mentioned he has the mantra of: “consume, build, teach”. In essence, to learn and level up as a developer, you need to consume — research and understand the new code, framework, library, package that you’re dealing with. Read articles. Watch videos. Gain knowledge. Build — have a practical understanding of how the package, library, framework works in a development environment and gain more context on how it is used. And, lastly, teach — which is simply the ability to articulate what you’ve learnt to others either face-to-face, online videos, blogs or a more formal traditional teaching environment.

One of the main struggles I have as a developer with some experience is learning. Ultimately, it is daunting. It feels as though there are a million new frameworks that need to be learnt and I am only just getting to grips with my first few. Therefore, knowing where to start is problematic.

I often find myself spending more time thinking and googling what to learn, rather than learning itself.

As result, I’ve tried to implement the ‘Consume, Build, Teach’ mantra into my daily workflow over the last couple of weeks to help me improve and progress as a developer. However, based on past experience, I’ve identified some things I need for this to work effectively.

  • Avoid that overwhelmed feeling. This is all too common in my development life. When I feel overwhelmed, I am not productive.
  • Small incremental progress. No amount of progress is too small — set daily, achievable goals, rather than lofty, overly ambitious long-term aims.
  • Maintain focus. Learning doesn’t necessarily have to be rigidly structured and prescribed, but it should be linked and related. In order to progress, it should build on what you know and not be a disparate array of technologies.

Consume

A problem I have always had is — how to consume new stuff? On the one hand, there are tonnes of videos, books, articles out there to help. Should I follow an online tutorial? Or perhaps just read the latest blogs on the commute to work? Is that enough? Do I need to do both those things? And listen to podcasts on top of that?! It can feel like information overload.

I have tried and failed to learn and develop in certain areas in the past. For example, I started a course on Data Science and Algorithms last year. It was interesting, though not that practical. I struggled to make progress. Realistically, I was writing code for 40 hours a week in my day job, I have other hobbies such as running, I maintain a social life and a general habitable living standard, so the time I have available to learn new stuff is relatively limited. People that have more time will be able to take on a meatier challenge. For me, trying to learn a whole new area like Data Science and Algorithms was just too much. It didn’t really build on my web development background at all. It was like going back to basics and I wasn’t progressing my existing knowledge base at all and everything was completely new. The feeling of being overwhelmed emerged. My goal lacked focus. And the objective of learning abstract ‘algorithms’ was simply too far-sighted.

Therefore, this time around my learning will be focused and related to what I know. My day job is Full Stack JavaScript (TypeScript, React, Redux, Node, Express, Mongo), so I am confident my learning and development in these technologies will continue as work with them daily and interact with other colleagues. However, I will continue learning and experimenting with these technologies. Secondly, in my role at the moment, we are looking at re-building parts of the system, which means more thinking about data modelling and system design. We're also introducing more formal development practices like coding patterns will Object Orientated programming. These higher level concepts will help inform what I am learning. It will probably mean that my learning is looser and flip-flops as priorities and my workload changes, but it will always mean that what I am working on is relevant and applicable.

A second issue I increasingly struggle with is finding suitable resources. Although there are tonnes of materials out there, finding learning resources for someone that is not a beginner, but still fairly junior was actually a struggle. I found the beginner ‘zero-to-hero’ tutorials too slow and not an efficient use of time. However, other resources, which are for more advanced developers, veer in the other direction and assume several years of experience that I don’t currently have. And again, not being that relevant. Finding the right balance can be quite a challenge.

I now watch a lot of code-alongs or live coding sessions on Twitch or YouTube, which have been helpful. A great example is a React calculator app by Michael Jackson, one of the creators of React Router. I knew some React when I watched this, but the way he solved some of the problems was completely new to me and a completely different — and better — approach than I would have taken myself.

I was surprised at how useful I found them. Some points of observation on why they work for me:

  • Faster: The pace is faster than a basic ‘how-to’ tutorial and the emphasis is less on teaching and explaining execution elements like functions, variables and reducers, and more on higher level concepts.
  • Real Coding: Mistakes get made and you see the process of debugging code, which is beneficial. Something that you don’t get in an uber polished pre-recording tutorial series.
  • Reliable learning benefit: An additional benefit here is I always learn something. For example, if I am not learning new syntax, I get to see how another developer (generally a more experienced developer) structures and organises their application, how they call APIs and so on. If it doesn’t teach me new things, it gives me exposure to a different way of doing things I’ve done before.

Conferences can be a bit hit and miss, but spend a bit of time finding suitable topics and they are really useful. The YouTube channel Coding Tech has a tonne of conferences available to watch. Lots are 20-30 minutes which mean you can squeeze them into a busy schedule. Conferences on new releases such as React Hooks, React Context, Babel 7 are good and help build on your existing knowledge of the general web development ecosystem. The fact that they are demoing new functionality means that the content is pretty simplified as everyone is seeing this for the first time. Therefore, your lack of experience doesn’t mean you lag behind and ensures you always learn something new.

Lastly, but the hardest thing for me, is to read regularly. I have set myself an aim to read one meaningful post a day on at least one of the topics I am learning. It’s not much — but again, it’s small incremental progress on my aims and allows me not to feel overwhelmed by how much I need to read. If I miss a day, it’s just 10–15 minutes of extra reading to catch up.

To help with this, I’ve set up a Feedly account to aggregate the blogs and newsletters I am interested in. An important point here is to be frugal about publications that you add. I’ve tried to use this method before and failed because I’ve added too many blogs or I’ve added news aggregator sites that pump out several articles a day. As a result, my feed is crammed full of stuff — some it relevant, some of it not. I get overwhelmed and ultimately end up giving up. This time I’ve only added a few blogs and no authors that produce more than a couple of posts a week. Once set up, I marked all the posts that had automatically been added to my feed as read, so that my inbox was completely empty. Then, day-by-day as articles trickled in — one or two a day — I read them as they come in. It was manageable, incremental and most of all I was completely on top of things.

Build

Next in the mantra is build. As mentioned, my main procrastination is figuring out what I should be learning. To solve this, I put down constraints on what I am going to learn or improve upon. If it’s not relevant, I am not interested. This has been the most useful thing I have done. It seems small, but it is a really effective exercise. It just cuts out all the noise and stops your mind from wandering and gives you some focus. When I do a personal project now, I know it’ll be JavaScript and React without even thinking. Before I nailed down these goals, I often thought “I do React in my day job, so maybe I’ll give Vue a go”. Without the focus, you get swamped in the availability of resources out there pretty quickly.

Ultimately, the aim of all of this is to learn and progress. It seems natural at this point  to look at the skills required by Senior Developers. Below are three different soundbites from Senior Developer job descriptions for a JavaScript role.

5+ years of software development with real-world full-stack JS applications

Strong, proficient working knowledge of Javascript (Native) + ES6, React, Bootstrap, HTML/CSS

Minimum of 5 years architecting scalable robust applications in Javascript (and frameworks such as AngularJS and ReactJS)

A constant theme is that they want someone with insert number of years here experience in a specific language. No job description asks for someone with 1–2 years experience in 4 or 5 languages. They all want a developer with deep, detailed knowledge of how one language works. The accumulation of knowledge and skill that comes with time is ultimately what matters. Therefore, as mentioned, this is why my list shares the JavaScript theme. This is entirely intentional and maps to the point above about learning one language really well.

A second benefit with them all being JS-compatible is that I want stuff that I can get into and progress with quickly. I may only have 20 minutes or the odd hour here or there, so I can dip in and out of these topics more easily because of my existing JavaScript knowledge than I could a completely new language. This is important I’ve found. The ability to make visible incremental progress for me is what motivates me to keep going. Therefore, if my goal is too big and I am not progressing because I can’t find a 3-hour window I end up giving up.

A strategy I have taken to help with this and to build more stuff is to try and make one meaningful Github commit a day. Again, this harks back to my need for small incremental progress. This has worked well. I often surprise myself with how much I can get done in a quick 20 minutes. It also helps my development workflow. I’m not great at committing early and often, but the time constraints in my working day mean I am enforcing this principle by default. Secondly, it has helped me to isolate issues. When I am building a personal project, I work on one feature only to be distracted by some rogue CSS styling. I get completely distracted. With this approach, I know I’ve only got 20 minutes, so let’s add some form validation — and I do it with laser-focus. Again, the time constraint serves a great way to stay focused and not get distracted.

Teach

Well. That’s where the blogging comes in 🙃

I find it really valuable to write, though I’ve not been doing it as much as I’d like recently. It allows me to articulate my thoughts, gain a clearer sense of coding or technical problems I am faced with and, lastly, allows me to share with the wider community any thoughts and ideas. Also, the habit of writing helps inform other good habits I ought to have. If I am writing, I am generally writing about the code I have written or ‘new stuff’ I have learnt, so by writing I am naturally nudged to write some code or learn some ‘new stuff’ as a consequence. It helps my personal and professional development immensely and as a result, slots in nicely as the last block of the ‘Consume, Build, Teach’ mantra.

#learning#learn-coding#javascript#web-development#development
 
Share this