I'll agree with this as a self taught person.

I'll admit to being a little shaky on the types of programming needed in enterprise projects at the beginning (less of a focus on maintainable code, but probably more of a focus on what the machine is actually doing), as I only knew exactly what I needed to hack together whatever my hobby project was, but after 5 years of a career and working in 9 different languages it's been pretty easy.

I mean, occasionally there's something that takes a bit to work into my brain's L1 cache, like the precise semantics of prototypical inheritance in javascript, or call by name in scala, but for the most part, everything's been extremely transferable. A hashmap is still a hashmap in any language.

I taught myself to code in high school and then did the 5 year CS degree at university. School taught me a lot of interesting stuff that I probably would've never picked up on my own, and gave me a much more grounded perspective on the entire field. But very little that was directly relevant for enteprise programming (which I've been doing professionally for over a decade by now).

I have been writing JavaScript since JS has existed, and the One Weird Trick I learned to working with JS’s OO system is to use it as little as possible. Don’t get me wrong, objects are wonderful, but you don’t need JS’s barking insane semantics around “this” when static closures work fantastically. It’s not even the prototype model that I’m talking about, it’s having to do things like foo.bar.bind(foo) or having to know that an event handler will re-bind “this” and so on. The Vue and React communities have caught on to this, and writing code for those is so much more pleasant now that there are fewer land mines like that to step on.

As I was reading through it, it sounded like he didn't have an actual idea of what to build. I'd expect an 'idea guy' would learn just enough to get going and start building whatever the idea was, and use the project as a means to guide him to whatever he needed to learn next. I find this to be the most effective way to learn, as all the learning gets applied right away, outside of the context of a very controlled problem given by the teacher.

The idea that he was jumping from course to course, across a bunch of different languages made it seem like he valued having the identity as someone who built something, but didn't know what to build. The gap year suggests that as well. I've been in the same boat and the only thing that moved me forward was having a project to work on that I cared about. In my case, I had a normal job with some down time, and learned to code to make that job easier... no courses, just reading the docs and trying to solve the problem right in front of me. I actually had programming classes in college before this, and while I passed without issue, I never felt I learned how to code or built by own stuff, and years passed between that course and when I felt I actually learned. Having a problem, breaking it down, and building a solution, one small bit at a time, was required to go from knowing some basic ideas of syntax to knowing how to solve a problem with code.

I still struggle after 15 years into programming, and I never published or finished anything because of "judgement anxiety". I waste days, weeks, months writing and rewriting code and then I decide to abandon it because "other developers are going to see how shitty of a developer I am and it'll jeopardize my reputation forever".

Humility is my most used tool. Pick up lots of new things, embrace being a beginner.

> "other developers are going to see how shitty of a developer I am and it'll jeopardize my reputation forever"

Those who put down others or leave nonconstructive feedback, even HN commenters, are not worth your time worrying over.

It sounds like you have much too high expectations. If you must compare yourself to others and their code, do not compare yourself with those who publish code regularly. A more grounded comparison would be between you and others who don't publish - tinkerers, students, some enterprise professionals, and so on.

Anyways, you should see some code that gets submitted as homework tasks in interviews from enterprise programmers. That is the stuff that programmers do not publish, and the range of code quality and code understanding is large. There are working professionals with multi-year experience in C++ who cannot describe in their own words the relationship between a raw pointer and a memory address. I don't have a strong opinion on that, I've seen it all. But the quality bar to feel good enough about your work is not as high as you think it is, probably.

Also... there is a lot of fanaticism and brash comments about programming online. There is a reason why the "very online" group of people doesn't overlap with experts in any almost any industry. Opinions of most experts on things like code quality are very measured, they don't earn a lot of karma or upvotes, or likes. So don't put too much weight on what you see online when choosing to publish or not publish code, a lot of online comments are for shock value.

> other developers are going to see how shitty of a developer I am and it'll jeopardize my reputation forever

When I first started pushing out shit code on GitHub, I did it under a pseudonym and never tied it to my real identity. I think that really helps when first getting started since you know it’ll never affect you personally. After getting the hang of it, then perhaps tie that to yourself.

But to be honest, I doubt anyone cares much about your/my code nor would they bother judging it.

Of course, I’ve only been programming for ~5 years so I might be missing stuff.

You may not realize just how terrible much of production code actually is! ;-)

There is some source code I've looked at that I thought was clear and easy to understand (at the time at least. I also like simple C/C++ code that compiles with "make", ideally with minimal #ifdefs and without lengthy configure scripts.) This is very rare in my experience, although I really like to see it!

Seriously, building things that are fun and interesting to you and getting them to work is one of the best things you can do. Once you have something working then you can decide whether you can just clean up your existing implementation or whether you want to reorganize it or rewrite it completely, but you'll be at the point where you understand your problem and its solution.

Yeah, I don't think this guy's problem is that coding is hard, I think he finds learning hard. At this point I think a better understanding of pedagogy would help advance his coding more than anything.

He makes it pretty clear that his frustration was due to the overall brittle nature of code (change the wrong thing and the whole system breaks), not simply the learning process.

Unfortunately brittleness is baked into virtually very computer system and development process: it's all essentially predicated on a series of finicky text files (source code, config files, etc.), none of which have any inherent, enforced relationship to each other except when seen through the lens of an IDE, compiler or interpreter. The system as a whole doesn't enforce meaningful constraints, and when it does you often have nothing more to go on than a cryptic error message.

Unfortunately that has been the nature of software development for the past 70+ years. Some developers are creative, willing, and talented enough to deal with this realm. But it's not for everybody.

Even after a decade, many coders make limited progress for their potential, and some make very little. Progress depends on balancing consumption of knowledge and application. If one consumes a lot (watches many YouTube videos) but does not create anything with this knowledge, it is evident that they will not progress quickly. If one constantly applies the same knowledge and never seeks to learn new things, they will likewise stagnate.

I don’t know, I only bother to finish projects for work. With personal projects, it always ends up following the 20/80 rule — 20% of the code produces 80% of the value. The remaining 80% of code is largely uninteresting busywork and just isn’t worth the effort for a pet project.

But it’s definitely worth implementing the core concepts in total, both for whatever goal and your own learning. The rest just needs a working mental model, but actually implementing is a waste

As an aside, I’ve found this also holds true for most games, and stopped bothering to finish them (you can usually understand most games in total very quickly, largely because their systems are so shallow)

Yep. Resonates a lot. I've tinkered with code on the side and realised its very hard to do it "part-time".

Learned HTML/CSS in 2012. Built an app in Rails in 2014. Learned basic Javascript in 2018. Delved into React in 2020. Shifted to no-code. Back to Fundamentals in 2023.

I think its hard to really be good at it, but depends on the goal. Most people want to be software engineers for the wrong reasons these days. To me it was always a hobby and if I can build some small useful things for people with just front-end and a database its a win.

Its not easy though. It never was. It requires commitment and patience as well as regularity beyond tinkering with it 1 time a month.