Ask HN: Haven't worked for a while, best guide/advice to start a hobby project?

[HAL9OOO]

I'm in a weird place. I used to work as a developer but never thought I was that great. Most of my jobs were small features, fixing bugs, etc. Honestly I was quite lazy and coasted somehow. I’m trying to change all of that now.

I feel like I'm behind 'bootcamp grads' because they can actually push deploy real code.

I have a bunch of hobby project ideas, for example one tries to use the Spotify API and the MapBox API, but every time I start I get overwhelmed with what stack I should use, and how to actually get a ‘real’ application out. It’s hard to explain. I have a lot of anxiety and analysis paralysis about this.

I’m hoping for some great resources to actually build something and learn at the same time, so I can get my confidence up and actually get some MVPs going so I can ‘learn by doing’.

I feel like every tutorial I look at either:

1. Starts out great, explaining stuff but then becomes outdated/frustrating by the end (ex: https://www.smashingmagazine.com/2019/03/spotify-app-vue-nuxt-javascript/)

2. Is WAY too basic. I don’t want to learn basic syntax over and over.

3. Keeps making me switch tech stacks. I just want to use Python/Flask or learn JS/Node. I want to use VUE just because it’s new and it’s docs seem good. I don't even know what's out there anymore or what's good about it. I just want some consistency. Everyone says the stack doesn't matter too much anyway. Just want it to be fun...

RealPython and FullStackPython seem like they have good tutorials so far but what I’ve been googling so far (Spotify Vue Tutorial Project Setup) has not come up with stuff that clicks with me.

Sorry for the ramble… I just want to work without feeling bored or overwhelmed. Any suggestions? Thanks ~

[HAL9OOO]

Thanks for all the replies guys! It's going to take me a while to read through all of them and process them. I guess this is the benefit of having eyes looking at your post on Christmas Eve, people feel like helping :).

Happy Holidays Everyone~

             /\
            <  >
             \/
             /\
            /  \
           /++++\
          /  ()  \
          /      \
         /~`~`~`~`\
        /  ()  ()  \
        /          \
       /*&*&*&*&*&*&\
      /  ()  ()  ()  \
      /              \
     /++++++++++++++++\
    /  ()  ()  ()  ()  \
    /                  \
   /~`~`~`~`~`~`~`~`~`~`\
  /  ()  ()  ()  ()  ()  \
           |   |
          |`````|
          \_____/

[mam2]

Just get a random swe job and see how it goes. Worst case you get fired.

Also find a team of nice people like you.

[DantesKite]

I know how you feel.

It takes time to design interesting work. People often say follow your passions but sometimes the passion requires a brief period of tedious exploration while you set things up.

Through trial and error, you can slowly sketch out a landscape of interesting problems, like glossy monuments rising above the horizon. That’s how it feels anyways when you finally start making some progress; when you finally have fun problems to work on.

But in the beginning you almost have to guess what you think will be interesting. And there’s no guarantee it’ll be useful, but I’ve found a lot of times, the experiences and lessons you’ve learned in one project sets you up for the next.

Usually the things that annoy you the most tend to be the best starting places for interesting problems. And it’s important they’re interesting because it’s easy to lose motivation on things you don’t think are important. Then you’ll feel so guilty for not working, you’ll start working on uninteresting problems just so you can be productive (and that’s when the real trouble really starts). Because tedious, boring labor that slowly invades your life isn’t much different from slavery, the major difference being it tends to be more abstract and invisible.

[rlonn]

Very, very good comment! The past two years I've worked on three different pet projects: first one that was fun and interesting but where I was dependent on another developer, who ran out of time, so that project stalled.Then a project I did simply because I saw an opening in the market, but which wasn't fun or interesting enough - this meant I wasn't motivated enough to go the extra mile, or to pivot slightly when necessary. Project alive but going nowhere. For my 3rd attempt I sat down and tried to think of something that was fun and interesting, that I also thought MAY have market potential. It's still too early to say how it's going, but I notice I have no trouble at all fixing all the tiny, boring little details that need fixing here. It's just so much more rewarding.

[hollander]

> Instead of ‘finding your passion,’ try developing it, Stanford scholars say

https://news.stanford.edu/2018/06/18/find-passion-may-bad-ad...

[grblovrflowerrr]

I've been there before. After getting burnt out on my startup, I spent about half a year traveling and trying out other hobbies not doing any coding at all.

When I got back to it I felt a little bit lost as to what to do, but doing these things helped me get back into the habit:

- Find a good project-oriented book and just follow along. In my case this was "Elements of Computing Systems: Building a Modern Computer from First Principles", but according to your interests and skill-levels there's plenty of good project-oriented books out there. I think this is good to do in parallel with your own side projects, because it gives you structure that the writers gave some pedagogical thought towards, and will thus help you gain confidence by solving problems and building something substantial over several weeks or months. This confidence will then put you in a better headspace for your self-directed work.

Don't engage in the online tutorials, where the author maybe wrote in a couple hours over a weekend. Instead, find well-respected books and courses that the authors poured serious effort into and that people consistently cite as having been influential to them.

- Read and engage with activities besides programming. I think one problem beginning programmers have is that they get so obsessed with just consuming programming related content. While the concentrated education you'll get out of this is great, from my experience reading about programming and tech doesn't lead to interesting ideas about things to make. What I think does lead to interesting ideas is cultivating curiosity about the world, and feeding it through reading and exploring.

- Study good software. In most creative disciplines there's a huge emphasis on studying the works of the masters of the art. This is so students can 1) understand the discipline's history and 2) develop good taste. The creation of software, whether you view it from a coding angle or from a UI angle, is mostly a design discipline. So taste matters a lot. I recommend studying the history of computing and finding good old artifacts to study(history is good because the excitement the pioneers felt might rub off on you, and help you see the field from a fresh perspective). Any software that you personally enjoy using is worth studying like this, but I think paying attention to the classics helps too.

- Learn how to design. This might seem like a distraction, but improving your design skills even just a bit can really help with making your ideas more engaging. The design community also has a lot of practices and advice on how to come up with good ideas that are worth seeking out.

- Find creators whose work you enjoy, follow them, and study their work. The most creative and prolific people I know all have one or more creators who were massive inspirations for them, and that they obsessed over and often spent a ridiculous amount of time trying to emulate. Too much focus on the copying part can be a hindrance in the short term, but being sensitive to these chains of inspiration, and seeking out who inspired the people who inspired you, can lead you down interesting paths. Find networks of creatives locally, on Twitter, slack groups, wherever, and engage with them, and contextualize your work in their framework(whether it's startups, art, or anything).

- Read up on creativity! IMO while self-help and pop-psychology books/ can be counterproductive if you spend too much time in them, in small doses they can be useful for analyzing your habits and practices. I recommend reading visakanv's threads about these topics: https://www.notion.so/a-list-of-visakanv-s-threads-1a6ed25cf...

[santa_boy]

This is a very common problem. It is good to learn but it is even better to focus and push things out. This is particularly applicable if your application going down really doesn't hurt badly. Users / Customers care very less about the stack and many things that developers focus too much on.

There is way too much of good dev stuff to decide the "best one". Just pick one and move forward.

Read this thread ... [Ask HN: Successful one-person online businesses? | Hacker News](https://news.ycombinator.com/item?id=21332072) .... there are quite a few examples of people cranking out useful stuff with basic tech (primitive).

It may make sense to just push out and launch if it is anywhere in your realm of interest. And focus less on novelty and differentiation. Eat into the existing market if you are stuck finding a way to differentiate.

I've analysed 15 products, in an area I'm working on, over the past few months and they all seem to be doing fine. There is nothing particularly different among them and think they focus on market and selling to people who would use them to keep the lights one.

[stankot]

There are a couple of good comments, so I won't repeat what they said.

Find something you are actually passionate about. It doesn't have to be a big thing. You shouldn't care if it is a cool thing, or what other people think of it.

When I'm interviewing, I love when people showcase stuff they enjoyed building, rather than something bigger they made following a tutorial.

Here is an example of a really small project I enjoyed working on - https://muffinman.io/vertigo/ It was so fun, and I learned some canvas/svg stuff I never touched before. Even now when I look at it, it brings a smile to my face.

Another thing I think you should do is to document the whole process and write one or series of blog posts. It will help you understand the whole thing better, and help people in similar situation.

Good luck and please share with HN whatever you end up making!

[HAL9OOO]

Thanks man! I'm thinking about writing a few blog posts too, even if no one reads it I think it would be a motivator for me. I'll definitely post my projects on here when they get to an alpha state :)

[ernsheong]

Forget tech stacks. Just pick the simplest idea you can think of that you would actually use yourself, that seems to not be a complex software product. And do it!

I can assure you that the simplest of products will not result in the simplest code / stack.

It is important that you also personally want to use this thing, because when the going gets tough, you will stick with it.

[Ididntdothis]

And really finish it. Most learning is done while reducing bug count. Prototypes are easy in comparison.

[embit]

Agreed. My personal recommendation is to not worry about which stack is good but getting really really good at any one of the stacks. Mastery counts a lot.

[suhail]

If I were you...

1. Start with something simpler & work on building up your fundamentals. Build momentum & confidence.

2. Recognize your struggle is part of the journey of learning. When you read and don't understand a word, you look it up. Take the time to fight through the abstraction & learn some core concepts when you don't know what something is. It's ok to get distracted & go down a mini rabbit hole.

You may need to learn 5 things that seem unrelated to the task at hand. Those 5 things aren't a waste, you'll likely find the concepts useful later. I always did.

Consider not using some frameworks to remove some of the magic.

Build something you want so you finish it.

[ehnto]

> Consider not using some frameworks to remove some of the magic.

Learning a framework for a single project can sometimes mean a lot of learning abstractions that you'll never need again, and that didn't teach you any new core concepts.

I would only learn tools like React or Vue if I intended to use them for work, which is what I did. If I'm doing a fun project, I write native code because it's more fun to figure stuff out on my own and I come across more novel concepts and fundamental understandings that way. If I'm building a new project I will use familiar tools/frameworks, so that I can remove the noise of learning new stuff and focus on the build.

Frameworks take time and iterations to get used to and use effectively, they're best if you're going to be building a lot of things using them. They're more like a box of weirdly shaped tools that you like.

[tqwhite]

In my city, the programming unemployment rate is, like, 2%. If you haven't worked for awhile, it's because of your job hunting skills, not your tech stack. So, if having a job is reason you ask this, my answer is: read some books about job hunting. Don't worry about programming right now.

But, and I think, more importantly, you are taking this way too seriously. Programming is fun. Write something fun. Me? I think NodeJS and VueJS are fun. Write a node app that draws ascii images in your terminal. Or, figure out how to store stuff in a database (Mongo is also fun). Wire up a VueJS app that accesses it. (Then throw it all out. Your first is never good enough to keep.)

OR, go to Glitch.com and party around there. It's a very sociable place to do some coding and engage with other people who want to program. Lots of ideas there. You can pick up Node apps and extend them. That's a lot of fun.

OR, do CodeWars.com. Pick your favorite language and do some exercises. If you aren't inspired after a week of doing that, find another profession. You're not a programmer.

OR, read GitHub. As before, if you aren't inspired after a week concentrating on the cool things other people do, forget about programming, it's not in your blood.

But you will. Programming is the most fun you can have. It has all the ingredients. Always new. Good results. Fun community. You can do it alone and sitting down.

And relax.

[ken]

I don't agree with this advice. Why do I need to be inspired by what people are already doing? Someone is already doing that. We don't need more. Fred Rogers said "I went into television because I hated it so". I can't think of a better reason to enter a field.

Pick your favorite language and do some exercises. If you aren't inspired after a week of doing that, create your own language! All of the languages we have today still suck.

Read GitHub. If you aren't inspired after a week concentrating on the things other people do, pick something more worthwhile! Those things are only being done because someone chose to do them. They have no more right to direct the future of computation than you or anyone else.

Give me more programmers who didn't get here by the traditional path. I want the next generation of software from people like Alan Kay, Larry Wall, Bill Atkinson, and Tim Berners-Lee.

[hrehhf]

> In my city, the programming unemployment rate is, like, 2%. If you haven't worked for awhile, it's because of your job hunting skills, not your tech stack.

No, it is not due to job hunting skills. It's more like "culture fit" and other types of discrimination.

https://www.techrepublic.com/article/the-myth-of-the-tech-ta...

[52-6F-62]

I’ll second this advice: have fun.

A few years ago I wrote a Python script that took a TSV tile as input and randomly selected a secret Santa matchup that wouldn’t put partners together and then email them their matches with a backup to a file so nobody would know the matches. I could find out, but didn’t have to know the list to get everyone set up.

It’s been a ton of fun improving on that year over year, and it was a great learning experience.

It definitely doesn’t have to be a serious endeavour.

That said, initiating an open source library that fills a previously unfilled need is also a great learning experience. Plus, other people get to see and critique your code in public—it makes you give some things a second thought.

And yes, also in both cases I agree: relax.

[dominotw]

you can be working as a developer without 'working'

[issa]

It sounds like you need to figure out some basic goals first. If you're focused on finding a job, there are a lot of mid-size companies that could put you to work building small features and bug fixes and be perfectly happy. It might make more sense to find a company that uses the stack you are already familiar with. However out of date you are, there is a company still using that stack!

If you want to just have a hobby and expand your horizons, the most important thing is finding something FUN to do.

But forcing a hobby project in hopes of it leading to a job, if that's what you are trying, sounds like a recipe for disappointment.

[txcwpalpha]

You've already gotten a lot of good replies, but I was in your exact position and I want to share another perspective of what worked specifically for me.

First and foremost, stop worrying about making a "real application". Don't concern yourself with making this something that people will actually use, or something that could potentially make money, or the next Facebook. Just stop. You're never going to actually build anything if you keep second guessing whether or not it's a good thing to build. Instead, just acknowledge that your goal is to build something and to learn from it and have fun building it. If it turns out that your app becomes "real", then that is a huge bonus! But focusing on that as a priority is just going to be a blocker for you.

Second, if you are in a position where you are trying to "learn" new skills, then I would actually advise against starting with trying to build your Spotify/MapBox idea. Instead, pick an already existing something that either a) you already know a lot about or b) is a common app that people build (like a blog site or a reddit/HN clone). I know that sounds frustrating and not ideal, but I went through the same ordeal and it helped a lot. The reason for this is that there are tons of good tutorials for building something like a blog or social network site with all kinds of tech stacks, so that will help. The other reason is because you already have a feature roadmap laid out for you, and this will help get past the analysis paralysis.

For example, you can build an HN clone and just start off small by building the front page which links to other news sites. Then you add a login system. Then add comments. Then add points and ranking. Each step is small enough to actually be feasible, but probably tough enough that it will teach you new aspects (such as teaching you how to do logins correctly, or how to store comments effectively in a database, etc). And at each step, you still have the opportunity to add your own improvements as you see fit, so even though you are essentially building an HN clone, you can still add your own flair to it and explore your own personal interests.

I did the above, and I found that it was immensely helpful in actually getting past the analysis paralysis stage that it sounds like you are stuck at. After I built a simple news aggregator clone, I found that the process had taught me enough to then actually build one of my own personal ideas, and because I now had the foundational knowledge from building the earlier 'simpler' app, it was much easier to get a jump start on my own app.

[yumaikas]

Just wanted to second the recommendation to build something that already exists first. Like how artists do master studies, or still life, software developers can learn a lot by actually building something that already exists. It helps educate you about the nature of how certain things are built, and what considerations they have.

My first web project in Go was an email signup server. The second was a blog engine that still powers https://junglecoder.com. Both projects taught me a lot, and the blog took quite a while to finish up.

Getting something out the door and in front of other people, even if it's just your friends, is key.

[james_s_tayler]

Something I have found really great is to purposely build something you will never ever even be remotely tempted to ship but that has some degree of complexity to it. What's great about this approach is you are never forced to be bogged down in details that aren't relevant to you.

If you ship a product and I mean like really try to ship it with a launch and everything, you will spend a tonne of time on a) non-technical tasks that don't matter to your day job and b) technical tasks that don't matter to your day job.

For example graphic design, copywriting, marketing etc. All great stuff if you want to go the route of actually trying to launch a company. Terrible to get caught up in if you just want to learn to write production grade systems.

Technical tasks you have to spend time on for stuff you actually will ship do have some value but really it can be limited. You might spend time to build deployment pipelines or auth or HA deployments etc. All of that stuff is great IMHO and I personally value having done a lot of it but to a lot of engineers who work on established code bases and just never ever touch that stuff I feel like it's not a huge value add.

With a project you know you'll never ship you can focus only on the parts you want to. You can then layer lots of little mini-projects into it and use it to try out new things over time.

I guess I'd recommend trying to ship a real project solo at least once too. It gives you perspective.

[yumaikas]

So, I wouldn't worry a great deal about which stack land in. Once you get familiar with HTTP, you can switch languages later, if you feel the need.

If you're wanting an exercise to help you build up to the confidence to approach your own webapp projects, I actually recommend porting kbwiki (https://github.com/yumaikas/kbwiki) to the stack of your choice, if you're ok with reading Nim (it looks like python, though it's rather different under the hood).

The reason I suggest this is that kbwiki covers both basic HTTP auth, and running as an HTTP client. kbwiki also is a real, but small web app. I use it to power https://idea.junglecoder.com and https://feed.junglecoder.com. If there is another project that does a lot of what you want to do, porting it to a different language would be a good exercise.

After that, think of an idea of something you want to use, and then try to pick off a small part of it. Working with the Spotify API, maybe just try to build something that lets you list your playlists, or maybe just one playlist. Then, build out one more piece, and continue doing so.

Though, one thing I will say: Working with 3rd APIs is often much harder than just building out something that doesn't rely on them, due to having to implement authentication. So if you have a hobby idea that doesn't rely on a 3rd party API, I would bias towards that for your first project.

See if you can find a friend or someone to discuss ideas in more depth. Having that second opinion can help unstick you, or help refine your ideas. I'd be willing to discuss over email, if you'd like an ear (yumaikas94 at the google one).

Also, be willing to do things that don't follow best practices as such (as long as you're cognizant of the fact). I've written 3 webapps in the last year, none of which implement their own authentication, because they are designed for one single trusted user. I have a Jenkins status checker I use at work that relies on me copying the "remember me" cookie out of my browser into the filesystem.

For now, don't worry about being "current" techwise, worry about building up a portfolio of different things. Get building, and eventually, as you build projects, you'll find a groove, and then, if you want to build things that are sophisticated on the front end, you'll end up looking into React/Vue/Angular. If you like backend webapps, Python, Go, or JS/Node will start to stand out.

If you take a left turn, and decide to instead go into desktop apps (I highly recommend making at least one or two in your life, but no rush), C# or Java might look attractive.

My overall point with the last two paragraphs is this: Learn tech that will let you build what you want to make, not just because it has a lot of articles written about it.

[davismwfl]

If you are wanting to pick up Vue, choose node.js and start with the basic tutorial on setting up your project and project organization. Then do a tutorial on state management in Vue. At that point you should just get started on a project and stop doing tutorials until you run into something you don't understand. To get moving I like to pick a piece of functionality. In this case, login could be a good place to start. Whether you want to use third party auth or roll your own, it is a good place to start. Get login and state management working because once you have that running you can start implementing other functionality pretty fast.

The key is to pick a piece of functionality that does two things, one: simple but once completed is a component you'll need for your project, two: at the end of implementing that functionality there is something that works which you can build off. That's why I suggest doing those two tutorials and then starting with login and state management, it will help you move forward. Don't get ahead of yourself, pick small components of functionality and just start knocking them out. Don't think about the millions of options.

On your tech stack, pick whatever is most common for your stack, don't try to be complex when all you need is to get started. For example, node.js, postgresql or mongodb, Vue. That will give you the widest set of tutorials and help online and in the end it is extremely capable platform for nearly anything you want to build. And all of those are marketable skills.

edit: fixed a word

[HAL9OOO]

Thanks Davis! That seems look a good start. Sometimes I just need someone to tell me what to do I feel to put things into perspective. I'll start with the basic Node/Vue tutorials and focus on getting something deployed, implementing login and then some basic api integration and move from there.

I guess I can always refactor the code when I start learning about more complicated stuff.

[asiachick]

the problem i have with this approach is it's reinventing the wheel.

continuous integration, testing infra, rolling upgrades, deployment, logging, analytics on that logging, should all get solved problems I get out of the box in 2019

[madrox]

I always felt this way about graphics programming. I really wanted to make video games, but it seemed like all the books I read went from easy to "speaking a foreign language" from one chapter to the next.

I felt that way learning React not long ago. I feel that way learning any new tech. I'm pretty sure that's what learning feels like.

You got some great advice. One other thing I'll offer that may not occur to you as a self-learner: find a mentor who's done it before. You can often find people willing to help at local meetups if you have them in your area. A mentor can help with the elements that make you feel overwhelmed so you can get on with the business of learning a side project. This isn't necessary, but it can save you a lot of time on the road to building confidence.

When I was in this spot, it was easy to feel like I was "behind" or everything was too hard. I don't know if this helps, but it's something everyone goes through learning new things. Take your time. Go slow. Don't give up.

[keithnz]

I know this pain of being undecided on what to choose. Though the difference being I do have a core stack I build with, it's just when I do hobby projects I often want to try something new and end up exactly feeling like you feel, too much choice! But I've always found when I have a problem, I work better, so if you have MVP idea, flesh it out, define it best you can, then force yourself to choose. If you can't choose, use Node / Vue. It's all javascript and no matter what choices you make later, building something significant in javascript is going to serve you well. If you need a database, choose postgresql, getting some core sql skills is very useful, even if you end up moving to nosql dbs. If you need cheap hosting, try digital ocean. This is a bit different from my core stack, but I have built things with those things, and they are fine, not necessarily the best but have a lot of transferable knowledge and plenty of people use them so there is a LOT of info on how to do most anything you will want to do.

[ravioli_fog]

I'm sorry you are feeling anxiety and somehow "less". I've felt like that. I know others have too. It sucks, but its common and it will pass.

As for everything else, the biggest lesson that I have learned from my mentors this year is that everything is relative. For every choice you can make as a developer there are pros and cons. This language or that one. This framework or another, the list goes on and on and on. In fact making choices is a big part of everything we do. Naming variables is hard, primarily because we have to choose the best name. But how do we choose?

Learning how to make an informed choice is a powerful skill. The power I think, is from learning how to make a choice that once made, is satisfying to you. In other words the choices are hard and anxiety inducing: because they are choices. A silly assessment, but true. Pain is unfortunate because it hurts. Choices create anxiety becuase we have to make a choice and live with an unknown outcome.

So the hack, the trick, is to spend less effort on choosing and the majority of the effort on defining the context around the choice.

To your final statements: "I just want to work without feeling bored or overwhelmed. Any suggestions?"

I would say you should really evaluate the space of boredom, and the feeling of being overwhelmed. Spend most of your time just defining this. Give it a day or to and think about it, sleep on it.

Were you bored because you were just doing tutorials for no clear reason? >> Pick a project or outcome not an implementation.

Do you feel overwhelmed when you don't know what is next? >> Find a mentor.

Obviously these are just guesses, I don't know your situation. And if you just want another human to bounce ideas off of let me know.

[johnwalkr]

You could plan some small steps if you’re feeling overwhelmed. After reading some of the other replies, I came up with a few steps, tailor as needed:

1. Write down your goals or ideas for features. If you want to learn a specific framework, write that down as a /constraint/

2. (Optional depending on your style and background) Write down 10 or so requirements, if it feels natural to do so

3. Draw some block diagrams and flow charts. Keep it simple and think about which major components you need

4. Now you can survey frameworks. If you had one in mind as a constraint, does it still make sense? Pick whatever frameworks, libraries and development tools you need to solve your problems. If you don’t know what you need for a component, write down TBD.

5. Find a peer, and justify 1-4 to them. You will likely find most of your decisions make sense, but now you’ll have confidence and maybe make a few changes.

6. Now you can set up your development environment. You might find a few pain points already here and make a few more changes to your plan.

[moksly]

I wouldn’t worry about the popular hipster stacks, but rather shoot for something productive and preferably slow moving. There is a reason things like Django or Ruby on Rails help people actually get things out the door. They come with a lot of batteries included, and while it may not be the hip (or even smartest) way to do things, that doesn’t really matter nearly as much as getting shit done. stacks like Flask or anything JS backend really, will make you write tons and tons of code that other frameworks will give you for free.

At the end of the day, not a single one of your users are going to care about you tech-stack.

I work in the public sector, and we have a lot of legacy stuff. One of our most popular web apps, that always scores really high in user saturation when we review/audit, runs ASP web-forms. That’s some really old shit, and you really shouldn’t pick that up in 2019, but the point is that no one who uses it cares.

[shanev]

Is there a better term for "hipster stack"? Rails and Django were most certainly considered hipster when they first came out.

[iambrj]

You can see this[1] for ideas

[1] https://github.com/danistefanovic/build-your-own-x

[johndevor]

I was where you were. I think I fixed it by finding a project that really got me excited. You'll figure out the details like which tech stack of you're really excited.