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.
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.
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 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 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.
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.
... 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.
Start by developing fundamental skills: learn your environment, your editor, your debugger, the syntax of the language.
It's like learning to cook. You need to develop safe knife skills, and learn the best way to cut and portion vegetables. Learn to oil and use a pan and thermometer to thoroughly cook, but not burn, your food. These are fundamental skills that can be learned through observation, but must be practiced through trial and error.
> Debugging is 90% of coding.
> You learn by breaking, not by watching.
This is how you learn, but is a terrible takeaway for learning to build software.
> Write garbage code until it barely works.
See here for another way:
How to Design Programs
"The typical course on programming teaches a “tinker until it works” approach. When it works, students exclaim “It works!” and move on. Sadly, this phrase is also the shortest lie in computing, and it has cost many people many hours of their lives. In contrast, this book focuses on habits of good programming, addressing both professional and vocational programmers."
"By “good programming,” we mean an approach to the creation of software that relies on systematic thought, planning, and understanding from the very beginning, at every stage, and for every step. To emphasize the point, we speak of systematic program design and systematically designed programs. Critically, the latter articulates the rationale of the desired functionality. Good programming also satisfies an aesthetic sense of accomplishment; the elegance of a good program is comparable to time-tested poems or the black-and-white photographs of a bygone era. In short, programming differs from good programming like crayon sketches in a diner from oil paintings in a museum."
It uses a language so simple that you can learn most of it in well under an hour[0], and with a proper editor few syntax errors are even possible. It leads you quickly to the important parts of conceptualizing, designing, specifying, implementing, and testing programs. Like cooking an entire meal, these are more fundamental, but higher level, skills that you can carry on to the other platforms that might draw your attention.
I highly recommend reading books over watching videos, but here is an online course that uses the book:
https://www.edx.org/learn/coding/university-of-british-colum...
[0]: https://courses.cs.washington.edu/courses/cse341/03wi/scheme...
“A webpage that counts down to a movie release.”
Not an app. Not a startup. Just a janky react/tailwind page.
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.
As for documentation, I see many people recommend reading it directly to learn, but I find it hard to get through, and just reading documentation also makes it difficult for the knowledge to organize itself in my mind (it's like getting lost in a well-made game without map hints) If I watch tutorial videos first, then writing projects or reading documentation becomes more comfortable. I think these things might be mutually reinforcing.
I would binge-watch courses on Coursera for many days straight. I think the problem mentioned in this article seems to be that he didn't actually watch the videos he saved, so even if he were to learn through documentation, the result would be the same. Learning and practice are mutually reinforcing, while learning styles may vary for each individual.
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.
I’m guilty of same thing, wanting to learn something completely before putting it to use, and thus never starting the real work.
there is this huge like "potential well" that becomes almost impossible to leap over.
No LLMs, no Cursor, no false promises of AGI, just some musings about coding.
How to write garbage code until it barely works.