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
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 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.
"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:
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.
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!
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.
Readit News
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
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...
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.