what helped me was someone explicitly telling me all the blog posts were aspirational and when you look at their personal githubs even the authors don't usually live up to it outside of their open source / industry contributions.

and also knowing just how many people and how much money goes into those processes that I just do not have at home.

you've only got a finite amount of time and energy. Write for you. Open source it if you want more polish, and let other people bring the polish they want from it. But write for you, first and foremost.

after all, once written, most of my little things only do their one thing, and they don't need to do it very efficiently these days.

"Good code" is like good writing -- it needs an editor or four, and some friends you know to look over it (or enough time invested to be those for yourself), and much like editing, is also unnecessary outside of formal audiences.

personal code vs [code as communication of an idea so that many people can work on many moving parts nearly interchangably], is like social media posts vs deep dive blog essays.

all the advice doesn't apply, and all that really matters is that in the end, you built the thing you didn't have, but needed. Home code is like weekend warrior garage woodworking, the blog posts are like woodworking youtube telling you all the best stuff to buy every month and how you're supposed to use it, even though you can do it with simple tools just as quickly if you aren't running a job shop.

what are you coding with and what for? for me, i realized that it's better to write something than nothing. case in point: vvvvvv, one of my favorite games of all time, includes a switch statement that has several hundred cases? that handles most of the game logic. if i remember correctly, there's something similar in undertale's source too! and both of these games are nonetheless critical, commercial successes despite it. there's absolutely a balance to be found between writing performant, extensible code and writing the easiest solution to get things done, but as they say, perfect is the enemy of good

i'm sorry you're struggling with this!! i relate a lot, it's tough to stay motivated.

something that helped me was thinking about how other creative pursuits work (i firmly believe coding is a creative medium). as you improve at drawing or composing music or whatever, you naturally start to incorporate more little details into your work, and noticing, developing, and most importantly knowing when to apply those techniques is mastery of the skill, imo. there's a long period with every art form where you just have to think about chords or anatomy or whatever the medium is made of a lot, and it takes forever and is super annoying, before your innate sense for that stuff develops.

i don't know how long ago you started coding, but for me it took a good 10 years before i felt really comfortable in my text editor again the same way i felt when i was 14. 8 or 9 of those years i felt exactly the same way you do now, like i was getting in my own way by pursuing what felt like aesthetics over "real work." there is a time and a place for cutting corners in the name of getting shit out the door (and it's worth knowing how to do that), but there does also come a time when things start to click, and you can feasibly create what's in your head to a high degree of quality more often than not.

a phrase i like for this is "it took me 10 years to learn how to do it in 10 minutes."

so don't give up, take breaks if you need to, and just keep trying new things and building your inner framework 💜 you got this!!

The answer is simple, but difficult. You start fucking typing. Any time you catch yourself thinking, just fucking type. Put a comment saying "this is crap and needs rewriting", accept that you probably never will rewrite it, and then just fucking type. TYPE DAMN YOU!

A lot of the time you'll discover what you were typing was wrong - like in a fundamental "solving the wrong problem" sense, and then you can just delete the whole damn thing without even refactoring. Think how much quicker that was than agonising over getting it all perfect, before THEN deleting it. You got to the same end result, but faster and with less brain pain.

😅😭
still stuck on that, but starting to move on. what has made me move on was completely unrelated to coding though: it was an acknowledgement that i've had enough doing things other people ways and hurting me, and it was time to instead find my ways even if it weirds people out. and it has started percolating to code. good luck 💜🫂

I don't think this is unique to coding- imo it's difficult to match the motivation and enthusiasm for something when you've just started it, or still learning quickly.

My fix here has been to set myself goals- with reasonable timescales. and then stick to them.

That way it stops becoming a case of "how can I do this perfectly?" and starts becoming a case how "how can I do this well enough, and quickly?"

Unfortunately, and I really hate that life is this way- discipline wins out over motivation- motivation (for me at least) waxes and wanes depending on all kinds of trivial nonsense. The weather, what I've eaten, what's on the news- but if I try to hold myself accountable, and push through- more often than not- my motivation comes back half way through working on that day's task.

IT SUCKS, BUT THATS WHAT WORKS FOR ME- SORRY!

Some really good advice in this thread, I too have gone through that feeling of "wow I got so much more game done back when I didn't know anything"

Part of that is likely bias but it's true that it's easier to just brute your way through problems not necessarily knowing any of the pitfalls you're heading toward.

For me the largest sin is trying to design a system or solution that can solve every pitfall or edge case I can think of. I would just be stunned to inaction trying to solve the Rubik's cube before typing anything. I still catch myself doing this.

In the end I agree most with Tom's answer which is you have to just start typing with what you have and what you need right now. What minimum feature does that system need to perform in order for you to be unblocked and work on the next thing? Make it do that. Hide it behind a function call that you could swap out later, add a comment, "Todo: this will need to handle x and y someday" and move forward.

The difference between doing this now and doing this when you didn't know anything, is that now you can apply general practices for making code readable, maintainable, and scalable. I don't know what this system will be but I know to not make it's tendrils so entrenched as to make it impossible to swap out later! Always code with the expectation that it might get deleted later!

The really fun stuff is when you come back to that code days or a month later you realize that all your concerns and assumptions about what it needed to do were wrong. You didn't actually have the use cases to design from and now you do and wow isn't it nice you didn't spend a month writing a complex solution you were going to have to throw away!

I sympathize a ton with your feeling here. I assure you it gets better!!!

I very much had this problem (and still do to some degree). I either try find something new to learn or I just try do the thing. By try do the thing I mean I just start writing with the understanding I'm either going to refactor it down the line or it's never going to come up (either cause I finish it or I drop the project). Part of it was understanding not every project needs to be grand and something I'd show off to the world. Not everything needs to be open sourced or a résumé piece, some things can just be for you.

Another thing I found helped was writing things for my friend group. Our group has a small pool of software my wife and I have written that only we use. It's allowed to be jank cause I'm always there when it's used so I can always quickly troubleshoot. My most recent project was a rewrite of an old even janker version of the same project so we could watch movies together. The code is awful, it violates everything you'd expect from a modern web app but we can watch movies together and that's what matters.

The way I've some to see it, I'm better at programming now so now I can do it "badly" better.

What a lovely comment section this post has. Lots of people who are between 25% and 89% understanding what you said and what you meant (both very high numbers for a concept like this with 100 being an utterly impossible goal) sharing personal advice on what they do and understand about their own personal process trying to guide you to be more like them out of love. Seeing a comment section like this makes me feel like it's possible not to feel alone in this world and makes me want to try harder to connect with others. This truly is love and care. You've got some great people rewarding you very well for the emotional vulnerability you've shown. Thank you for posting this.

I know the feeling too! Something I found helpful in last year's Advent of Code was to start off deliberately writing the worst code I could get away with - no abstractions, hardcoded numbers, one-letter variables, everything like that. I also tried forcing myself to avoid thinking how the part 1 solutions for each day might generalize into part 2 and focused on only solving the immediate problem.

It ended up being a bunch of fun and strangely cathartic to intentionally write terrible code! And then as the month progressed and the challenges got harder, it was interesting to see which techniques for cleaner, better organised code ended up being necessary to bring back.

I get this feeling a lot. One thing that works for me when the situation allows it is to pair with someone else who has the enthusiasm.

I think you may need to scale back something, throw some aspects under the bus to allow you to be productive with the others. For personal code, I think flexibility and scalability are both great choices for dump stats.

Flexibility in particular can be aggressively discarded because you can always just change the code later if you change your mind about what it's going to do. Nobody else is there to stop you.

This definitely happens to me.

I've also found certain languages make this easier to worry about (Rust) or easier to just do things and make stuff work (Ruby). So where quality doesn't matter so much, switching to a worse language can paradoxically be better ^_^

The straightforward trick that I use (which was used on me when I started working, and I use on the people who come to me for advice) is to remember that it's software, just bits. You can always come back to make it better. You can make terrible decisions and fix them later. We leave every project unfinished, because it takes an infinite amount of time to really finish any project. And you need to convince yourself that it's fine, because either you'll get to it eventually, or...it's no longer your problem.

The more subtle approach is to ask, for any task, what the return on investment looks like. "I don't know." Sure you do. If it causes you more pain to make something happen than the pleasure you'll get out of it, time and money or not, then it's a bad deal.

But there's also the flip side of this. Are you having fun when you go down these semi-obsessive paths? There's nothing wrong with enjoying "thinking about things" more than doing them for a while, and maybe leaning into it for a while will help.

Hiya, a bit late reply (wait actually nevermind people are still replying :P), but what I try to internalize that works well for me is that all of these guidelines are really for the 2nd, 3rd, etc. drafts of code.

The first version of a module I write roughly and unselfconsciously (or try to at least). Then once I've done that, I have all these book chapters and posts in my head about refactoring and naming conventions and good commenting and "separation of concerns" and you name it, and I use those as tools to improve the code. And can usually do that reasonably quickly.

There's this saying in writing that a good first draft is one that is Done (not "good"), and I find that applies to programming in ways that are not identical but sometimes useful. With programming the "unit" for a draft is more like a module, rather than the whole thing like it can be with writing, because if you wait to refactor a whole program odds are that will be a PITA. So the rhythm I use is more like "an hour to a couple hours of rough coding -- then polish/improve it that day (or the next)."

I still think it's really worth it to think about how to solve the problem, and to do some design, before jumping in and hacking -- but a lot is best left to later iterations.

Maybe your learning curve will end up being figuring out what you should care about in the 1st version and what you should leave until later polishing. I hope this helps.

i feel this one a little too much. i don't have a good way to deal with it but i've thought about if something is worth doing, it's worth doing poorly.

i can always go back and improve something that sucks + is bad. if i need to fix it then i'll spend the time to fix it later. i got caught on this repeatedly when making my little junk (tetris) renderer and i had to tell myself who is going to give a shit. nobody is going to care and if it becomes an issue i can fix it later.

even after over 12 years of doing this "professionally".