9 Years of "Learning to Code" and I Still Couldn't Build a To-Do App(offpeaklog.bearblog.dev)
offpeaklog.bearblog.dev
9 Years of "Learning to Code" and I Still Couldn't Build a To-Do App
https://offpeaklog.bearblog.dev/learning-to-code/
28 comments
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.
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.
Any pluralsight style course ive ever taken is basically useless.
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.
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 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 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.
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.
... 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.
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
“A webpage that counts down to a movie release.”
Not an app. Not a startup. Just a janky react/tailwind page.
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.
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.
"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.
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.
The author is trying to eat an elephant and doesn't know where to begin. They are trying to learn too many things at once without a foundation to build on.
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
https://htdp.org/
"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...
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
https://htdp.org/
"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...
I feel like this learning method has benefited me, but it doesn't seem to be widely supported:
I'll work on a project for a while, then realize what knowledge I'm lacking, to the point where I can't even think meaningfully while working on it.
Then I'll take courses for a while, which helps me build a "knowledge map." I'll think, "Oh, so that's how it works."
Then I'll go back to working on projects.
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.
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.
Oh man. 9 years… just pick something, one thing. Just one new (or old) technology that interests you, and code something with it. That’s all.
After that, code the next thing. That’s all it takes. For reference, I still code with Object Pascal (because I like it), don’t care about newer languages. Recently got interested in lisp, picked janet[1], and coded something with it. Just do it (R)
[1]: https://janet-lang.org
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
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.
I’m guilty of same thing, wanting to learn something completely before putting it to use, and thus never starting the real work.
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.
there is this huge like "potential well" that becomes almost impossible to leap over.
This is the best HackerNews content in a while.
No LLMs, no Cursor, no false promises of AGI, just some musings about coding.
No LLMs, no Cursor, no false promises of AGI, just some musings about coding.
Use what you need to solve your problem. Learning frameworks never made sense to me
This would be a great name for a tutorial:
How to write garbage code until it barely works.
How to write garbage code until it barely works.
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.