This is going to be controversial to say, but tutorial videos have never made sense to me. It's literally the least efficient way to communicate that information. I know junior developers love these sorts of videos, but I think they're more entrainment than education.
With a webpage you can read at your own rate of understanding, you can quickly jump back to find points you may have missed or not fully understood. You can follow hyperlinks to documentation the author thinks is important. Best of all, you can copy and paste! Assuming you are a competent reader, you can usually achieve all this in a fraction of the time as well.
This is why I've been finding it difficult to learn Metal. Apple's documentation is terrible. The important information is in their WWDC video presentations, but a lot of that assumes you are already familiar with Metal.
The most frequently recommended book (Metal by Tutorials) often doesn't explain things. It tells you to open a file, type this text, open this other file, replace this line with this text. If I wasn't also reading Realtime-Rendering, I would have no idea what is really happening. I've been thinking I should go back to Vulkan. At least Vulkan has a spec, more books, and more samples.
Blog posts are really a scourge both when learning to do something new, and when you're googling your way out of a bug. Most of them are stuck in time (so no updates ever) and find solutions to problems that are similar to the one you're solving, but not quite the same.
I can't stress enough how important that statement is. I learned to code by refactoring and revising my old ideas. When I learned a new tech stack, a new library, a new pattern or a new methodology, I ended up refactoring old projects with the new mindset.
I always jokingly say that every codebase looks like crap after 2 months, because it is true. You see your own mistakes after what you've learned _through implementing it_.
Good engineers and architects know how to break down a large problem into small enough portions to be able to guesstimate whether it's possible. Then they build little prototypes for those unknown unknowns to come back with a better estimation. And those small prototypes / portions are something like a knowledge library, where you gain confidence over time when you solved and successfully implemented those already.
Bad engineers on the other hand always chase the new hype, instead of learning from their own mistakes they just rebuild the same crap all over again, assuming it will be better by using fancy new libraries. Unsuccessfully.
> I always jokingly say that every codebase looks like crap after 2 months, because it is true. You see your own mistakes after what you've learned _through implementing it_
I am on the tail end of making a game from scratch, and while I am quite proud of the feature/performance set, every 2 weeks I stop pulling from the feature queue and just enter 'editor-in-chief' mode where I find any new ways of doing the same thing and extend it to the rest of the code base.
Often its leveraging templating, or other generalizing techniques that reduce code-bloat.
I look back at the beginning of the PC era, which I hated.
We had modern multi-user and multi-tasking operating systems. We had decent high-level languages.
But the PC era started with DOS, a single-user operating system. And basic, which was so unsophisticated.
But looking back later I realized that the unsophisticated operating system and the unsophisticated language... they let normal people do things. You didn't need to understand semaphores or event-driven programming to make simple single-user programs.
And I kind of see people stuck in this distracting learning environment with too many moving parts, I think back.
There are projects like NAND2Tetris that IMO successfully capture that ethos. I’m also heartened by the retro movement, which keeps going from strength to strength.
The problem is likely that you never started at the basics, and never learnt what you needed to solve your problem. You also have a clear idea, and try to build all of it at once. A common mistake.
You want to build a todo app?
Fine.
You are going to need to have some website. Cool. You only need to google how to display “todo list” on the page. 5 minutes of html will teach you that.
Then a list. Again 5 minutes of html.
Then add an entry. 10 minutes of JavaScript.
You don’t need react. You don’t need to know closures. You don’t need lambdas. Nobody needs tailwind ever.
Conversely, I think they probably have a good grasp of the basics considering they've been through them so many times. The real thing they lacked was a reasonable idea. I find a lot of early engineers have this problem where the only things they actually want to build are too complex for their skills. So they end up stuck in this 'Tutorial Hell' loop hoping to acquire those skills until they actually reason down to a project that fits their skill level and go from there as OP did here.
“A webpage that counts down to a movie release.”
Not an app. Not a startup. Just a janky react/tailwind page.
Maybe part of the problem is trying to bite off more than you can chew, spinning up React and Tailwind for what could be a single HTML element, a CSS style rule or two, and a few lines of plain JavaScript code is a symptom here. This is like taking a cruise ship on a canoe trip and then complaining that it's too time consuming and difficult. Start simple, start small!
Consistency is key. I need it too. With 1000 things pulling me this way and that, I get the most done when I just open my IDE and do it. It's so hard though. I feel like an agoraphobic trying to leave the house. What's the big deal? Just open the IDE and start doing stuff... but it's almost physically painful to even think about... I gotta get help.
I get this aversion to action from time to time. I'm a big fan of slapping the earbuds in and just cranking up an album I know by heart. Gets the groove goin
Imagine the time spent writing this blogpost that could've been spent actually learning to program. Sounds like they've never actually been learning, just planning to learn
This is the way to do it, good work and great that you posted this. The first release of my 40 million download app was held together by proverbial ducktape - yet the lessons learned from actually releasing it got me to come up with much better updates: https://willem.com/en/2018-02-21_updating-snake-97/
i am almost the exact same but its more like 20 years for me. its not like i can't code, but i have never built anything. i have used python for my grad studies so i have some level of comfort with it and can do data related tasks to some degree in it. but i have never built anything.
there is this huge like "potential well" that becomes almost impossible to leap over.
"Last week I’m in a café, rewatching the same JavaScript tutorial for the 23rd time. Next to me? A 16-year-old casually building a Discord bot that streams live sports data."
You don't learn software development by just looking at tutorials, you learn software development by solving something real, something you want to accomplish. The 16yo probably isn't as great a coder, but they wanted something, a discord bot, and they just built it. Tutorials are a dull chore. Solving real problems will teach you the stuff you actually need and give a feeling of success like no tutorial or made up training project ever can, no matter how well it is presented. Also, if you're 9 years into coding as a hobby and cannot whip up a to-do-app almost instantly you really should rethink how you spend your time and effort. Woodworking is also fun.
This is going to be controversial to say, but tutorial videos have never made sense to me. It's literally the least efficient way to communicate that information. I know junior developers love these sorts of videos, but I think they're more entrainment than education.
With a webpage you can read at your own rate of understanding, you can quickly jump back to find points you may have missed or not fully understood. You can follow hyperlinks to documentation the author thinks is important. Best of all, you can copy and paste! Assuming you are a competent reader, you can usually achieve all this in a fraction of the time as well.
Bring back books!
A good, well written, in depth technical book is the best way to learn any language/framework beyond a surface level IMO
They seem to have gone out of fashion in favour of Pluralsight/Udemy/etc, but I think they are superior.
This is why I've been finding it difficult to learn Metal. Apple's documentation is terrible. The important information is in their WWDC video presentations, but a lot of that assumes you are already familiar with Metal.
The most frequently recommended book (Metal by Tutorials) often doesn't explain things. It tells you to open a file, type this text, open this other file, replace this line with this text. If I wasn't also reading Realtime-Rendering, I would have no idea what is really happening. I've been thinking I should go back to Vulkan. At least Vulkan has a spec, more books, and more samples.
I completely agree. Plus: videos, courses, “blog posts” but no books, no reference documentation.
Blog posts are really a scourge both when learning to do something new, and when you're googling your way out of a bug. Most of them are stuck in time (so no updates ever) and find solutions to problems that are similar to the one you're solving, but not quite the same.
> You learn by breaking, not by watching.
I can't stress enough how important that statement is. I learned to code by refactoring and revising my old ideas. When I learned a new tech stack, a new library, a new pattern or a new methodology, I ended up refactoring old projects with the new mindset.
I always jokingly say that every codebase looks like crap after 2 months, because it is true. You see your own mistakes after what you've learned _through implementing it_.
Good engineers and architects know how to break down a large problem into small enough portions to be able to guesstimate whether it's possible. Then they build little prototypes for those unknown unknowns to come back with a better estimation. And those small prototypes / portions are something like a knowledge library, where you gain confidence over time when you solved and successfully implemented those already.
Bad engineers on the other hand always chase the new hype, instead of learning from their own mistakes they just rebuild the same crap all over again, assuming it will be better by using fancy new libraries. Unsuccessfully.
> I always jokingly say that every codebase looks like crap after 2 months, because it is true. You see your own mistakes after what you've learned _through implementing it_
I am on the tail end of making a game from scratch, and while I am quite proud of the feature/performance set, every 2 weeks I stop pulling from the feature queue and just enter 'editor-in-chief' mode where I find any new ways of doing the same thing and extend it to the rest of the code base. Often its leveraging templating, or other generalizing techniques that reduce code-bloat.
I believe this is true for all learning, we consolidate knowledge by applying it, not by hearing about it.
I look back at the beginning of the PC era, which I hated.
We had modern multi-user and multi-tasking operating systems. We had decent high-level languages.
But the PC era started with DOS, a single-user operating system. And basic, which was so unsophisticated.
But looking back later I realized that the unsophisticated operating system and the unsophisticated language... they let normal people do things. You didn't need to understand semaphores or event-driven programming to make simple single-user programs.
And I kind of see people stuck in this distracting learning environment with too many moving parts, I think back.
There are projects like NAND2Tetris that IMO successfully capture that ethos. I’m also heartened by the retro movement, which keeps going from strength to strength.
That's why I like dabbling in Arduino - it is a very limited environment, with fairly linear code-flow. It harkens back to those ancient times.
... occasionally dabble in Lazarus/FreePascal to also scratch that "mid-90's" itch.
Admittedly, these days, I avoid web-based programming at every opportunity - am sick of learning new frameworks, new paradigms, etc.
The problem is likely that you never started at the basics, and never learnt what you needed to solve your problem. You also have a clear idea, and try to build all of it at once. A common mistake.
You want to build a todo app? Fine.
You are going to need to have some website. Cool. You only need to google how to display “todo list” on the page. 5 minutes of html will teach you that.
Then a list. Again 5 minutes of html.
Then add an entry. 10 minutes of JavaScript.
You don’t need react. You don’t need to know closures. You don’t need lambdas. Nobody needs tailwind ever.
Conversely, I think they probably have a good grasp of the basics considering they've been through them so many times. The real thing they lacked was a reasonable idea. I find a lot of early engineers have this problem where the only things they actually want to build are too complex for their skills. So they end up stuck in this 'Tutorial Hell' loop hoping to acquire those skills until they actually reason down to a project that fits their skill level and go from there as OP did here.
Consistency is key. I need it too. With 1000 things pulling me this way and that, I get the most done when I just open my IDE and do it. It's so hard though. I feel like an agoraphobic trying to leave the house. What's the big deal? Just open the IDE and start doing stuff... but it's almost physically painful to even think about... I gotta get help.
I get this aversion to action from time to time. I'm a big fan of slapping the earbuds in and just cranking up an album I know by heart. Gets the groove goin
Imagine the time spent writing this blogpost that could've been spent actually learning to program. Sounds like they've never actually been learning, just planning to learn
This is the way to do it, good work and great that you posted this. The first release of my 40 million download app was held together by proverbial ducktape - yet the lessons learned from actually releasing it got me to come up with much better updates: https://willem.com/en/2018-02-21_updating-snake-97/
I assume you have heard don’t let perfect be the enemy of the good?
I’m guilty of same thing, wanting to learn something completely before putting it to use, and thus never starting the real work.
Use what you need to solve your problem. Learning frameworks never made sense to me
i am almost the exact same but its more like 20 years for me. its not like i can't code, but i have never built anything. i have used python for my grad studies so i have some level of comfort with it and can do data related tasks to some degree in it. but i have never built anything.
there is this huge like "potential well" that becomes almost impossible to leap over.
This would be a great name for a tutorial:
How to write garbage code until it barely works.
"Last week I’m in a café, rewatching the same JavaScript tutorial for the 23rd time. Next to me? A 16-year-old casually building a Discord bot that streams live sports data."
You don't learn software development by just looking at tutorials, you learn software development by solving something real, something you want to accomplish. The 16yo probably isn't as great a coder, but they wanted something, a discord bot, and they just built it. Tutorials are a dull chore. Solving real problems will teach you the stuff you actually need and give a feeling of success like no tutorial or made up training project ever can, no matter how well it is presented. Also, if you're 9 years into coding as a hobby and cannot whip up a to-do-app almost instantly you really should rethink how you spend your time and effort. Woodworking is also fun.
This is the best HackerNews content in a while.
No LLMs, no Cursor, no false promises of AGI, just some musings about coding.