Man you just hit me hard with this... Also add one insanely overbearing mother that expects straight As and a perfect child, on top of some bullying and such... Really leads you to just want to curl up and not take risks anymore. I've just been discovering, through the aid of therapy, just how much my mother has affected my whole life up to this point. I love her and she was doing her best. I really believe she was, based on her mother (oof, even more insane lol). Man has it done a number on me in every way you can imagine. I only mention this because your piece of essentially having the fear to move any personal projects to portfolio projects is very real with me,as well.

Side-note... How old are you? What frameworks? What personal projects? I'm 40 and just REALLY beginning this journey into coding and as much as I love it it is also insanely overwhelming because of reasons you started and also my terrible ADHD. So hard to stay focused on learning a piece at a time. My brain wants to open all the links, check out all the courses and YouTube videos... And it becomes too much.

> and also my terrible ADHD

FWIW, programming and ADHD tend to go well together once you can get past the basics. Especially when you're in the flow of things, it's just a constant loop of small change -> visible progress -> dopamine hit. Combine that with hyperfocus on the occasional deep bug and it can feel like a superpower.

Don't get me wrong, there are lots of other times where it doesn't work like that, and this assumes you can actually get started, but when you do it can be magical.

Not GP but I share similar experiences as you. Started coding as a teenager, but after I got my first job I did similar things as you for a very long time on and off until only a few years ago.

In part, it's good that you're trying out new things. That part should always be something we do. But the issue is when you don't have developed taste and principles to discriminate between things that just sound interesting and things you actually want to explore.

For me the solution has been to develop a small set of important values by asking fundamental questions. Why do I program? What does emotionally satisfy me (fun/pride/learning)? What is valuable for my users? What are computers for? What makes a good program?

Ask questions like that and you get a list of important things that you focus on.

Whenever I see something new, it first has to get through my value filter.

My reading, learning and tinkering list is still growing slightly faster than it shrinks. But I'm much more content and happy with what I actually end up doing or reading.

Hear, hear

A framework that I have found helpful for situations like this:

When you feel this way, that you "want to" do something but it keeps not happening, then there's evidently something inconsistent in your mental state: you seem to think you want to do one thing, but (it would be fair to say) since you're not doing it, maybe you don't 'actually want' to do it. The idea being that 'true wanting' compels actions. So when you fantasize about doing one thing, which you think you want, you're actually in the process of fulfilling a different want about something else (such as: "to feel like you are making progress on demonstrating value").

To disentangle this you have to figure out what you "actually want", resolving the inconsistency, usually by asking yourself: "what do my actual behaviors reveal of my actual desires?" Recognizing the revealed desire seems, empirically, to help move past it, while not recognizing it leaves you/me/whoever in this seemingly infinite loop of feeling incapable of action.

Sometimes just revealing the loop you're in unkinks it immediately and leaves you free to do something new. Sometimes, strangely, it makes you instantly uninterested in the whole topic, and then, in the space left by the now-uninteresting topic, new interests float in --- real interests, which come packaged with 'real' wanting that you can actually act on.

This is a nice little self-interrogation framework—thanks for sharing!

It reminds me of a common refrain/warning among aspiring writers: it's not enough to want to be a writer, you have to actually want to write. Both for a host of psychological reasons and for the simple fact that you'll never be A Writer unless you're putting pen to paper on a regular basis.

Some time ago Ive started to think in the same way, since it lowers guilt, it unlocks energy to ask what do I really want to go

I tell people to build a small crud application that you can use to manage some data you have some interest in. I've build a similar non-marketable applications, usually a todo/project management application or something that imports a bunch of stock market data probably 30 times now, I actually use the project itself to learn new languages and frameworks because it hits most of the areas I will have to learn to be productive and I can pickup the language semantics along the way. When you're done you have code that is going to be doing things you will actually encounter in the wild instead of contrived and isolated examples from text books.

My favorite part is once I'm done I feel comfortable enough with reading through repos and some books over how to be more efficient/idiomatic and then going back through my little project and refactoring it.

With all that said I have a graveyard of projects in languages and technology that is probably not used anywhere commercially and the project itself is languishing if it was completed at all - but for example, I have a half working todo app in racket and despite being a junk app in a non-commercial language, I had to learn lisp and it at least subtly has influenced how I approach problems. Same thing with Rust which I actually use quite a bit personally and commercially, but when I originally learned it I was 100% golang professionally and I noticed my golang functions would resemble rust functions if I squinted and I think the complexity in my golang went way down.

I guess my advice is Just Start Building Projects (that you may never even show anyone or post on github, much less go marketing it.) and you will benefit from it massively. If you are able to learn and benefit from it _and_ it becomes popular or a commercial success than great! But who cares, on the internet no one knows you aren't a dog.

That hits close to home. I was cleaning my drive recently and I have a folder of completed projects ( which has few items ) and various random stuff that I briefly found interesting over the course of the years ( and then just gave up as soon as something else caught my attention or got bored.. you know the drill ).

Some of it helped me a little ( that is partially how I learned basics of R ), but I fear that it also held me back as I never really finished any of the more amusing projects and did not experience that feeling of finishing something.

And as you get older, it is harder to expose yourself to that scrutiny.

I would give you different advice than "just start building projects": The language and framework that the first iteration of something is built in does not matter. You already know enough tools to build anything you want. If you want to build stuff, stop learning new tools. Maybe you'll replace the time you've been spending learning new tools with video games or TV shows, but maybe you'll replace it with building stuff, instead.

This is a classic trap that young programmers fall into, to fetishize tools and condition doing useful work on learning a bunch of tools. Just say no!

(This isn't anti-intellectualism - you'll eventually learn a bunch more tools as you go.)

The advice should be, build stuff that you find interesting. I don’t think prospects and motivational words are sufficient to get you to do things, but curiosity - or even better, child-like curiosity- is a far better lever to help you get things done.

My advice is not to focus on a portfolio or a "project". Find things that annoy you in life that code can fix, write that code. Some of these things will become more complex then others. I would advise against anything larger than 3 days of work (as in distinct days spent working on the project ,not total hours) in scale, as you'll just feel bad when you don't finish the latest grandiose dream.

Don't worry about how pretty or impressive the code is. The point is the function. Save everything in a projects folder, no matter how shit.

At some point you'll hit a point where a project hits the right intersection of elegance/function/polish, and then you can throw that on a portfolio page. Then another one, and another one.

The important thing is the end goal. As long as that goal is to impress other people you will be paralyzed by fear of rejection. If the goal is to fix a problem for yourself that's much more achievable, as the only bar you need to meet is "did it fix my problem?".

Random sampling of my own "frustration" projects: - automatic version control in SQL Server for object/table definitions - cron script that scrapes + downloads the latest driver from Nvidia from their website, installs it, then deletes the file - command line tool that formats text in the clipboard various ways (mostly I use this for transforming csv/excel files into SQL lists or table inserts) - a small utility for printing notes on a receipt thermal printer - a Lemmy scraper that combines different communities into a single coherent image board (I hated their default media presentation)

A smart person's fallacy is that more learning will yield a better outcome. (Note they've largely been rewarded for learning across their school career because that was something they excelled at). I've come to believe that in fact action should precede learning. That is first take action-- fire, ready/recover, aim (repeat).

We think we can just learn to succeed, but in fact we need to learn in the right direction, which requires to first attempt it and gather feedback of where to learn.

I always seemed to switch languages, frameworks, projects, operating systems...seldom making something.

From an interviewers perspective, it can be nice to see someone with varied experience across an array of tech. But just one or two demonstratable projects can seal the deal.

At this point I'd be happy with three person listing one language/framework and one good project.

I feel the same. For me the learning is the enjoyable part, and building a 1000th TODO app or a mediocre blog does not appeal to me. Although I'd like to have a blog and it would be great if I had some examples of the frameworks I've learnt, it's not something that I'll spend my time on.

> This is a behavioral habit, a disastrous one and potentially career-ending or at least progression-ending.

Or it's just that reality lurks somewhere and that hidden complexity will arise making the effort unsatisfying with roadblock happening too early.

Most people that achieve their pet project scope it into a narrow solution that don't address general problems. If your interest is the general problem, your solution is likely to be hard and complex, and narrowing it make it uninteresting.

Each experience is different, but since I stopped caring about half baked solution to general hard problems (New Web UI Framework ! Implementation automation !) and stopped daydreaming about building a solution, but merely thinking of the problem itself, I stopped plateauing and resumed a steady progress in my relationship with tech.

Creating a project is tough because there are so name variables to contend with: better ideas, “this won’t pan out”, small burnouts, no accountability on time wasted on procrastinating, self doubts, money, opportunity cost analysis making you switch etc.

So you do need to just build once or twice to experience the hardship of it to see if this is for you

I wrote a post about this that may help you. Please take a read and let me know https://noben.org "how to finish"

Your blog is beautiful, thanks for sharing.

> And right now I'm in the process of learning yet another framework.

Why not build a framework? At this point, you might be a subject-matter expert of frameworks!

You know what you like and how you want to use it.