Search for a command to run...
I’m a Web Developer based in Adelaide, Australia. Even though I have a Telecommunications Engineering degree and an MBA, coding is my passion and my new professional career focus. Developing applications for the web has become my drive.
No comments yet. Be the first to comment.
TL;DR: We’re no longer limited to using generic productivity tools. With the rise of AI-assisted coding and platforms like v0, Bolt, Cursor, and Windsurf, it’s now possible to build simple, custom tools (microtools) that fit the way you think and wor...
The first time you look at Claude Code closely, it can feel like a box full of parts that all seem important, but not obviously related. You see CLAUDE.md. Then rules. Then skills. Then hooks. Then su
TL;DR: We’re no longer limited to using generic productivity tools. With the rise of AI-assisted coding and platforms like v0, Bolt, Cursor, and Windsurf, it’s now possible to build simple, custom tools (microtools) that fit the way you think and wor...
Unlock the Full Potential of Static Typing in Your React Projects
Front-End vs Full-Stack Web Development: Which Career Path Is Right for You?
Do you want to learn Python or improve your skills in this popular programming language? If so, you might be interested in the Python for Everybody Specialization course on Coursera. It’s a great way to master the basics of Python and explore its app...
Damian Demasi's Blog
34 posts
Web Developer - I switched careers in my 40s - Writer of web development blog posts - I love to share Notion templates
Buy me a coffee!Let me introduce you to Ron, an ordinary person like you and me, except that he was born into a world of magic. Life led Ron to experience many adventures when he was young. Still, he somehow ended up working as a manager in a retail wizarding joke emporium, a job he ultimately got tired of. As he wanted to start working in something more rewarding, he began investigating a possible career in programming and, more specifically, in web development.
This content is also available on my YouTube channel, and you can watch it here:
But Ron knows he has some problems with his study techniques: he doesn’t know how to improve his weakest points, often thinks that tests are a waste of time, and constantly takes feedback incorrectly.
In this article, we will help Ron by teaching him how to attack his weakest points to improve them, how he can learn by testing himself about programming concepts and allow feedback to improve his coding skills.
This article is the second one about distilling the concepts presented in the book Ultralearning by Scott Yong. I apply those concepts to learning programming, as I believe they are very useful. If you wish to know more about these topics, I recommend reading the book.
I will publish at least two more learning principles applied to programming in the upcoming article, so you might want to subscribe to my newsletter get a notification when it's published.
OK, let's help Ron with the first principle: Drills.
As soon as Ron sat down and opened his online course about programming, he felt overwhelmed by the complexity of the topics he wanted to learn. According to the book, applying a "divide and conquer" approach is the best way to overcome these challenges.
Ron could break down complex topics into smaller pieces, understand them, practice them, and once he masters those small parts, put them back together.
The key idea behind drills is to choose critical concepts and practice them. Drills build up from the principle of Directness, discussed in my previous article, but it goes a bit deeper, with a narrower focus.
Suppose we start by putting into practice a programming concept through directness. In that case, we could then find the most complex components that produce the most significant impact on the main concept and create drills, which are essentially practice sessions, to improve them. After we have completed our practice sessions, we can go back to the central concept and see if we understand it better.
Ron finds it difficult to transfer this idea into practice, so let's give him a couple of tactics he can use to design his drills.
In this tactic, we will find ways to drill (practice) only one specific component of the concept or skill we are learning.
As it turns out, Ron has problems understanding the structure of HTML documents. In this case, he could practice small pieces of the HTML structure, such as the HTML version information. Once he has practised this piece until it comes natural to him, he can move on to other elements, thus growing his knowledge and expertise about HTML.
Sometimes we will need to practice a part of a concept that's not easy to reproduce by itself. In these situations, we could copy the features we don't want to practice to focus on the parts we do.
Ron wants to practice some HTML form elements, such as <input> and <label>. To do this properly, he will need to write a lot of HTML code just to reach the section in which he can finally introduce a <form> element and practice its sub-elements: <input> and <label>.
<!DOCTYPE html>
<html>
<body>
<h1>The label element</h1>
<p>
Click on one of the text labels to toggle the related radio button:
</p>
<form action="/action_page.php">
<input type="radio" id="html" name="fav_language" value="HTML" />
<label for="html">HTML</label><br />
<input type="radio" id="css" name="fav_language" value="CSS" />
<label for="css">CSS</label><br />
<input
type="radio"
id="javascript"
name="fav_language"
value="JavaScript"
/>
<label for="javascript">JavaScript</label><br /><br />
<input type="submit" value="Submit" />
</form>
</body>
</html>
By using the copycat tactic, Ron can just copy and paste the code needed to build an empty form and build on top of that, practising the elements he wants to learn.
Building on this concept, and once Ron gains more knowledge about versioning systems, he could even use Git to create branches of his code and practice parts of it.
Another way to practice specific code concepts is to have a programming session around a coding challenge. Websites like CodeWars offer many coding challenges we can use to practice our coding skills and improve.
In websites like this one, Ron is not only going to write code but also look at other muggles', I mean people's, solutions, something that will teach him about the different ways a programming challenge can be solved.
🧑💻 Here is a list of sites to practice code:
Let's now help Ron to overcome his preconceptions about tests and use them as a learning tool.
Ron is used to thinking about testing as a way to assess knowledge when, in fact, it's also a way of creating it. We should test ourselves before we feel confident, even if we don't know all the answers, because doing this will prepare our minds to pay attention to information that looks like a solution when we learn it later.
Ron is used to spending long hours passively reviewing his highlights on books and notes, hoping that something will stick to his memory, but this is not what retrieval is about. Retrieval is closing the book and trying to answer questions about the topic we just learned. This is why it's essential to build our own projects in programming because it's here when we discover what we know and don't know.
If we have the answers to what we want to retrieve, such as the book's answer keys, we can compare our recalled knowledge with the actual correct answers, thus improving our understanding and retention.
Ron is taking a course on JavaScript, and the instructor says, after showing how something is built, "OK, now you try to build this functionality". Ron should try to build it without taking a second look at how the instructor did it and Googling things he doesn't know or remembers. After he finishes creating it, he can continue watching the course and compare his solution with the solution provided by the instructor. This will trigger several "aha!" moments for Ron, keeping him engaged in the learning activities.
Ron should avoid doing simple retrieval, such as answering multiple-choice questions. He should try to do open retrieval: writing as much as he knows about a specific topic. This is the best method to make the most of his retrieval activities. For more details about the scientific proof behind this, read chapter 8 of the book Ultralearning.
Ron asks for some tactics about how to put the retrieval concept into practice, so let's take a look at the following ones.
After reading a book section or learning a new concept, we could try to write down everything we remember on a blank piece of paper. Doing this will help us to remember these concepts later.
We often take notes during our learning process to highlight things that we consider to be important. A better way of taking notes is to write them down as questions to be answered later.
I actually did this when I was doing a Udemy course about JavaScript. As the course introduced concepts, I wrote them down on a Notion database in the form of questions. This is how I managed to write 318 questions (with their answers) and have them ready for my recall sessions.
For example, instead of writing "Type coercion is…" we could write "What is type coercion?" and refer to where we can find the answer. In this example, a link to a blog post in FreeCodeCamp will suffice: "Type coercion is the process of converting a value from one type to another (such as string to number)."
But I have a disclaimer to do, and I'm sure Ron is going to relate to this: even though I have all these questions, I'm still struggling to find time and energy to do some recall on them. So, don't be like me, and find time to answer the questions! 😅
As we go through our learning material, we could create challenges for ourselves to solve later. For example, if we are learning about APIs, we could create a challenge to use an API.
We could create a list of all these challenges to address later and have our own repository of code examples we could use in the future.
Let's now help Ron overcome his tendency to take feedback in the wrong way.
During our learning process, we are going to find feedback. It could come from other people expressing their opinions, but more often than not, it will come from a computer: our code doesn't work as expected.
We shouldn't let our egos get in the way of this feedback. On the one hand, we can think that as our program is not working, we are not suitable to be programmers. Or on the other hand, believe that we are great programmers because we got our "Hello, world" code working on the first try.
Ron usually feels reluctant to share his code with others as he will face criticism. The bad news is that others must review our code, as this is a standard practice in the programming industry. Here we should remember the concept of having a growth mindset (as I discussed in the first article of this series) and don't take feedback or criticism in the wrong way. Feedback is what makes us better programmers.
Let's give Ron some tactics to improve his response to feedback and use it in the best way possible.
Every time we receive feedback, it will be made of a constructive and noisy part. We should learn to disregard the noise and focus on the constructive part.
For example, someone can comment about Ron's code: "You are not good in programming because you forgot to clear the timeout in this React component. You should go back to selling magic jokes…". The constructive part of this feedback is that Ron should pay more attention to clearing timeouts in his code to avoid memory leaks, for example. The noise is the first and last part of this feedback, a subjective judgement someone made about Ron's capabilities as a programmer, and he should disregard that, as the person giving the feedback probably doesn't know Ron well. He can't possibly write code without making mistakes (that's why our code needs to be reviewed by peer programmers and pass quality assurance tests).
We need the computer's feedback when writing code, as it will tell us if the code is working or not. If Ron makes too many mistakes, or too few, he should decrease or increase the difficulty of the project he's working on to get helpful feedback.
This kind of feedback is not about the code we are writing but the overall success of the strategy we use to learn how to code.
Ron could experiment with different study methods, comparing and contrasting them. The best way to make this comparison is to test himself: does he learns more with method A or B? Which method takes more time? Which method is the most likely he will use in his study activities?
Coming to an end in this article, I hope we have given Ron a good idea about how he can improve his weakest points, learn effectively by testing himself and constructively take feedback to improve his coding skills. I'm sure Ron now feels more confident about learning how to program.
I want to remind you that there are at least two more principles I'll cover in the coming article, so you might want to subscribe to my newsletter to get a notification when it's published.
Have you ever felt like Ron did? Which one of the covered principles resonated most with you? Please leave your answer in the comments so we can discuss more about it.
Thanks for reading, and see you next time! 👋
🗞️ NEWSLETTER - If you want to hear about my latest articles and interesting software development content, subscribe to my newsletter.
🐦 TWITTER - Follow me on Twitter.