[dehrmann]

> That's when I decided that I didn't need to go to college. I could just teach myself, for free, through all these online resources.

> I went through all the tracks, from basic HTML (again) to JavaScript and even Ruby amd Python. And I was super proud of myself for doing just that. I then started this 2-day python crash course...

> It's been 10 years since I first started learning how to code. And I still struggle with it, a lot.

> I go back to the basics, again and again and again.

There shouldn't be this much struggle after 10 years. I wonder if your issue is you were never intentional in your learning and practice and just bounced from topic to topic. You say you're the "idea guy." There's a saying that it's better to finish something than to start something.

[al_borland]

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.

[yuktrn]

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".

[musicale]

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.

[_lvbh]

> 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.

[ted_bunny]

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

[Freedom2]

> "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.

[clnq]

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.

[Kamq]

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.

[codebolt]

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).

[sproingie]

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.

[kirso]

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.

[setr]

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)

[rainonmoon]

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.

[kmoser]

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 every 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.