DEV Community: Tim Rooke

Project - The Training Log

Tim Rooke — Fri, 19 Feb 2021 09:34:53 +0000

My aim for 2021 is to have a personal project on the side that I can keep chipping away at. In the past, I have started many projects only never to return to them, so I am keen to get into the habit and keep it ticking over. Usually, my projects are a little too ambitious for side projects and as a result, I get frustrated with the lack of progress and give up. Also, I've never struck up a good, regular routine. I often start on the occasional spare weekend and then never have time to revisit it, so this time I am trying to try a more piecemeal approach of committing little and often. In line with my "Consume, Build, Teach", I'll be trying to do at least one commit per day in an effort to carve out a routine and to keep the project progressing. Also, I am hoping to blog along the way about the build, so it will at least provide some useful content.

My grand idea is The Training Log. I run a lot. I use Strava, which is great for recording my runs, but not so good at keeping notes and performance data about my runs. The Strava model is slightly misaligned with my personal use. I like Strava's social features: the user feed, local legends, and segments as well as the functionality features it provides such as GPS recording. It's great for interacting with friends and seeing how fellow runners are progressing. However, it offers no way to store my thoughts and feelings about my runs. Normally, I am forced to use the description box. However, this isn't great. I don't really want to bore people with a frank, long-winded analysis of how I was feeling on my run, what I ate the night before and how well-hydrated I was. Also, when it comes to analysis a free-text description is basically useless. It gives no structured data and makes it very difficult to compare nuances across runs. Thus, The Training Log will provide a house for that. Longer-term, I'll sort out a Strava integration whereby activities automatically get imported and I can privately add all the notes I need and combine them with the analysis I want. This way I'll get my own private part of the internet for documenting my training efforts while continuing to use Strava for the features that I really like. Integration to the Strava API will make the process pretty seamless.

The initial build seems fairly straightforward. I'll leave the Strava integration for later. I've done some authentication work on the Strava API before so I know that that is possible. Lots of people do not use Strava (or any running app), so I want these users to be able to use the app as well. My concern with diving straight into the Strava integration is that the app will become tightly coupled to the data that the Strava API provides. Therefore, the app will be buggy and a poor user experience for manual users. To begin with, it will be a manual entry. In principle, the app is just a RESTful application with authentication, so I am hopeful it is not overly ambitious. Initially, it'll be a glorified ToDo app where users can name and add notes to their activities. But, I think with some simple additional features it can have quite a distinct use case.

Anyway, idea semi-formed, domain purchased, and npx create-react-app the-training-log executed I think that I am ready to go! I always forget about the amount of crud you have to deal with when starting a new application. I do it so infrequently nowadays that every time I come to it the process has changed again. Logo design, favicon creation, scouring different fonts and images - it's pretty exhausting 😅 All the useful websites have changed and all the React and Express utility packages have newer versions.

I am still figuring out exactly how I want to build it. I'll be using familiar technologies JavaScript, TypeScript, Node, and Express. However, I want a cost-efficient, high-performance way of hosting and serving the content. Also, I don't want to lose hours of time faffing with server configuration and deployments. My current thinking is that I'll set the backend up with Firestore using cloud store and functions. This will be new to me. I did a project a while back for a friend using AWS Amplify and Serverless and loved how simple it was. I've heard good things about Firestore - and Google's documentation is generally pretty good. A key benefit to this route is that I can use Google to manage the authentication workflow, which I don't really want to be wrestling with myself. If I am releasing the app publicly to users (at some point), then I owe it to them to ensure details and data are being managed properly by a third-party. I could do this, but for a side project, I am happy to outsource this. Also, Firebase makes Google authentication really easy which is an additional plus.

Anyway, if I am disciplined, I am planning a blog once a week about the progress. At this point, I have been sorting the basic project and firebase setup. I have a holding page up https://thetraininglog.com/.

Credit to these sites, which help with assets and resources for the initial setup.

Fonts
- https://www.1001fonts.com/
- https://fonts.google.com/
Favicon
- https://realfavicongenerator.net/
Images
- https://unsplash.com/
Image Functions
- https://www.remove.bg/ (Transparent background)
- https://pinetools.com/darken-image (Darkening images)
- https://tinypng.com/ (Compress images)

The Dreaded Refactor

Tim Rooke — Sat, 13 Feb 2021 14:52:18 +0000

I came across the talk: “Develop, Debug, Learn” by Christian Heilmann this week, which got me thinking. In the talk, Christian Heilmann focuses in part on developer’s continually patching of increasing issues and the general failure of most developers to properly understand and address the problems with their code.

For example, when we’re faced with a React application that is bloated, slow, and CPU-intensive, our immediate instinct isn’t to refactor the code to make it more performant. This seems a logical solution. We have a problem - bloated code - so identifying these areas and addressing the issues seems a sensible approach. However, this is rarely what happens in the ever-changing, evolving JavaScript ecosystem where there seems to be a multitude of new developments and technologies that allow us to continually patch our poorly written, sloppily structured code. These evolutions in the web development ecosystem are great, powerful tools and they allow us to continually move forward, adopt new approaches and operate in the margins of cutting edge technology. We are naturally drawn to them. They feel progressive, forward-looking, evolutionary. Something novel, something shiny, something new.

The dreaded refactor, on the other hand, is the antithesis of that. It involves dealing with legacy code - wading through the bog of ES5 syntax and perilous conditional statements. It feels too overwhelming. Furthermore, not only are we not progressing and learning new technologies. With the refactor, it almost feels like you're regressing. Treading trodden ground. Solving problems that have already been solved.

As I thought about this point further, it became clearer to me that there are more examples of this. In recent years, the web development and JavaScript ecosystem reels off a history of taking good, well-tailored tools designed to enhance the technology stack and overusing those in ways to avoid refactoring.

My immediate thought when writing this was Redux. The state management tool, which was almost a prerequisite to using React or so it seemed. In 2016, Dan Abramov, the creator of Redux, cautioned about using Redux unnecessarily in a blog post titled: “You Might Not Need Redux”. As applications have grown, Redux has become a handy device for dispensing with proper well-orchestrated local state in favour of stuffing, an ever-swelling global store full of localised data. As a result, the global state of many applications has grown too large, which has caused application load times to suffer. The logical solution here would be to revisit the global state and pare back its inefficiencies, remove the unnecessary data and ultimately refactor the code. The common solution here is adopt a practice like code splitting, so that we can patch up the problem: keep our oversized, global state, avoid a refactor while also improving the application load times.

As I read the ThoughtWorks technology review, it became clear across the web development spectrum there was a shared theme. While there were a few technological newcomers, there seemed several warnings of caution and overuse.

In the talk, Christian highlights various tools that have been developed to enhance the JS ecosystem, tools like Babel, Webpack, Sass. Tools that have their merit and serve a valid purpose, but have become ubiquitous with web development to the point that they often overused and abused. Moreover, they are support rafts for code that is badly in need of refactoring. Minification has a valid use case, and is absolutely necessary, but it has also provides additional latitude for inefficient code. Polyfills have usurped the need to understand nuances in browser behaviour. In the TechWorks Radar, browser polyfills are specifically called out, stating that all too often "web applications ship polyfills to browsers that don't need them". Code splitting allows the bloated bundles to be gobbled up in a more manageable way by the browser. All these techniques have their place, but all are used to some degree to patch inefficient code. They have become development solutions, rather than development enhancements.

While writing this, a question occurred to me: "When was the last time I properly refactored something?" I don't mean refactoring the code that you're currently working on. I mean you code an application, time passes, changes happen, which means that code now requires some attention. Do you refactor the code? Or do you reach for the nearest tool to help solve your issue? As developers, we too readily reach for the newest tool and make it fit, rather than rolling up our sleeves and embracing the dreaded refactor.

Consume, Build, Teach

Tim Rooke — Tue, 19 Jan 2021 09:23:08 +0000

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.