
Ask HN: Haven't worked for a while, best guide/advice to start a hobby project? - HAL9OOO
I&#x27;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.<p>I feel like I&#x27;m behind &#x27;bootcamp grads&#x27; because they can actually push deploy real code.<p>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.<p>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’.<p>I feel like every tutorial I look at either:<p>1. Starts out great, explaining stuff but then becomes outdated&#x2F;frustrating by the end (ex: https:&#x2F;&#x2F;www.smashingmagazine.com&#x2F;2019&#x2F;03&#x2F;spotify-app-vue-nuxt-javascript&#x2F;)<p>2. Is WAY too basic. I don’t want to learn basic syntax over and over.<p>3. Keeps making me switch tech stacks. I just want to use Python&#x2F;Flask or learn JS&#x2F;Node. I want to use VUE just because it’s new and it’s docs seem good. I don&#x27;t even know what&#x27;s out there anymore or what&#x27;s good about it. I just want some consistency. Everyone says the stack doesn&#x27;t matter too much anyway. Just want it to be fun...<p>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.<p>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.

------
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...](https://www.notion.so/a-list-of-visakanv-s-
threads-1a6ed25cf06e49e388a303903d597b73)

------
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](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/](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.

~~~
anongraddebt
I love this insight/observation.

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

~~~
lolinder
For the most part I agree, but there are times where a framework can teach a
valuable pattern that, even if you don't end up using it, expands your view of
what's possible. Vue helped me understand events a lot better than I did
before, and Redux is good to try at least once simply because it's such a
different way of thinking about state mutation compared to what you'd usually
come up with using just native code.

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

------
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](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](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](https://idea.junglecoder.com) and
[https://feed.junglecoder.com](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

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

~~~
asiachick
not surprised on the downvotes. Many devs will choose reinventing the wheel
over using existing solutions. Their competitors will be on to release 7.9
while they're still trying to figure out how to ship version 0.2 without
losing all the data from 0.1

Batteries included systems are a force multiplier. Engineers like writing code
more than shipping. Go to any game jam and watch the teams using Unreal or
Unity. Their progress dwarfs those that start from zero. While the teams using
the full engines are adding game play features the teams starting from scratch
are trying to figure out how to load 3D data or debug why their graphics
aren't on the screen yet.

It's no different with apps. A good app framework or web app framework gets
you to a working state ready to just work on what makes your app different.
Starting from scratch means you're still trying to figure out how to get your
DB backed up while the other devs are adding features.

~~~
lolinder
OP isn't trying to win a competition, it sounds like they're trying to learn
to be a better developer. I know way too many devs (and have been one myself)
who can use a batteries-included system until something goes wrong, but
because they have no idea how such a system is constructed they can't debug
it, or they don't understand why something isn't performing well.

It goes with the adage that every developer should implement a linked list
exactly once—you should use the standard library from then on, but if you
don't understand what's going on under the hood, you'll misuse it eventually.

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

~~~
91edec
> Is there a better term for "hipster stack"?

Javascript eco system.

~~~
y4mi
You made me laugh, but it is unfair.

vue, (p)react and angular all have a better frontend development experience
than you'd have with Django/rails.

It just increases your tech stack from one component by at least 3 (webpack,
nodejs, frontend-lib like vue/(p)react/angular )

And that is sometimes more than it's worth.

~~~
moksly
> vue, (p)react and angular all have a better frontend development experience
> than you'd have with Django/rails.

I don’t know much about RoR, but I think Django has a pretty great front-end
experience. In general I think the classic MVC approaches are highly
underrated. Well maybe not so much now that React, Vue and Angular are all
doing components that you can incorporate in your standard MVC, but I’ve
always found the SPAs and it’s MvvM architecture needlessly complicated unless
you desperately needed offline functionality.

It’s gotten quite popular of course, and great things can be build with it,
but it’s so complicated that it makes a one-person project into something you
often need at least two specialists to do well.

------
iambrj
You can see this[1] for ideas

[1] [https://github.com/danistefanovic/build-your-
own-x](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.

------
psaux
Founder here of a few startups. Was a total hackasaurus, and very similar to
you in the quality. I then decided to build a new product with some friends.
Changed it all! I had to start from scratch and build the whole stack. Lots of
headaches, but learned so much. I didn’t use search to find the solutions, I
did try to figure most of it out myself. Yes, you will be slower, but you will
learn so much in the end. I think a lot of the issue is around existing
content on the web or using pieces of some else’s code. Think of an idea,
doesn’t have to be new, and dive deep. I love paper too, draw out your
thoughts and ideas.

------
geofft
If you want to play with APIs, and you know Python, I would just access them
from normal Python with 'requests' (or any other normal HTTP client you like,
but 'requests' is the most popular and makes doing the right thing
straightforward).

In my opinion there's a lot of value in building something that _works_ and
then going from there. If you know Python and Flask, build your thing in
normal Python and Flask, rendering templates, not doing dynamic stuff in JS.
Then add Vue or whatever else once you have a basic thing working to make it
fancier.

------
nerder92
The best advise I can give you is: "Do it with a friend"

It's the best formula to keep yourself accountable and keep going even in the
less fun moment (because even in Greenfield hobby project there are shitty
moment's)

If possible do it in pair programming, it's the best for sharing and learning
from each other meanwhile

------
itgoon
> I get overwhelmed with what stack I should use, and how to actually get a
> ‘real’ application out

Don't worry about it, then. A "real" application is one that works and gets
some interest. If you can get someone to say "I like it, but..." that "but"
will give you plenty to learn from.

I hope this helps.

------
slantyyz
If your goal is to finish something you started, then pick the _easiest_ stuff
to learn that can produce the _fastest_ results based on whatever you already
know, even if what you know is "out of fashion".

Also, keep in mind that any tool you build can have very modest beginnings. It
might not even have a GUI for your first release.

For example, I absolutely hated the Stripe Admin interface when it related to
debugging stuff related to another project I was working on, so I wrote a
really mickey mouse Node script to pull data from the Stripe API to make it
easier to go through the data I needed while I was testing.

That script quickly turned into a simple Electron application that slapped a
GUI around my original script. I hadn't really used Electron before and it
gave me an excuse to learn it quickly (and reuse some existing UI code I wrote
for other projects).

That Electron app then turned into a bigger Electron application that could
access multiple APIs and data sources to collect data into local files and
databases.

So if you can just pick one small thing that annoys you (I find that something
annoying produces faster results than something _interesting_ , ymmv), you can
build something modest to address the immediate problem, and then iterate on
it to build it into something bigger and better.

I could have just as easily turned my original script into a command line
executable, an NPM or a small Dockerized web app container - do whatever is
interesting, fun and useful for _you_.

------
caconym_
Building anything real is a lot of work. The real question is: what kind of
work do you want to be doing?

I don't really program for fun anymore, but when I did, I always worked on
completely personal things I could build without relying on monolithic
frameworks. In practice this usually meant command-line or terminal-based
apps, e.g. text editors.

I didn't build anything the world hadn't seen some version of before, but the
crucial difference between these projects and something like e.g. a Reddit
clone is that most of the challenges I set for myself were pure problem-
solving. I never had the patience for projects that had me constantly Googling
for APIs and domain-specific hacks and so on, for a similar reason to what I'm
picking up from you: it all seems arbitrary and brittle and subject to change,
and it's not at all fun. It's drudgery. It feels like running on a treadmill,
except you're still just sitting on your ass getting older.

It's rewarding to solve complex problems elegantly, and the most challenging
pure implementation work I've done has been on my own time. I like to think I
learned a lot, in "pure" topics as well as design at complexity scales that a
lot of developers never see, and my career to date seems to suggest that I
wasn't wasting my time.

Sometimes I don't give this advice, because I don't know how well it would
work for somebody who's trying to bootstrap a career from zero professional
experience, but it sounds like that isn't the case for you. Unless you think
there is some framework or technology that will give you a clear advantage
applying for jobs you want, I think you should leave the drudgery at work and
spend your time enriching yourself with interesting problems. Pick something
you think is interesting and challenging, and learn what you need to learn to
make it happen.

------
whalesalad
I’ve been having fun with learning how to talk to raspberry pi accessories
using the i2c bus. I’m specifically playing around with Elixir and the nerves
framework. It’s fun to reverse engineer someone else’s Arduino or Python code
and use it to inform my Elixir code. When I say fun it’s a huge pain in the
ass and progress is extremely slow but I’m able to talk to my GPS and
accelerometer at this point. It’s kinda refreshing from the typical web
development stuff.

In your case I think you’re creating a lot of anxiety by making the assumption
that you need to be perfect right out the gate. I do this to myself as well,
so perhaps I’m projecting. Slow down! You’ve already recognized an area you
know you can improve in, that’s the first step. Don’t push yourself so hard to
get everything perfect. Focus on learning one thing at a time and apply them
to real problems. You’ll keep certain things and identify things you can do
better in the next project. Wash. Rinse. Repeat.

------
csallen
Start small. Way smaller than you think is reasonable. Nothing saps motivation
like overly ambitious projects (read: 99% of projects) where it takes you
forever to get to any sort of milestone. Every time I work on anything that
takes longer than a few weeks I regret it.

Build something you can get actually get to the "end" of in a trivial amount
of time, ideally just a few days. Avoid using lots of APIs or adding a bunch
of features. Make it simple at first, then iterate on that.

For example, Indie Hackers started as just a blog. I built and designed it in
less than week. A few months later I added a forum. That was about 8 days from
idea to release. Both were barebones MVPs.

Also, you seem super focused on tech stacks. I don't think it matters nearly
as much as you think. Just pick something, follow their official tutorial, and
stick with it until it's familiar.

------
franky47
I was in a very similar situation about a year ago.

What changed is that I took freelance contracts, on stacks that I had tried to
use in side projects but failed to ship because of analysis paralysis. The
simple fact that the project is not yours to drive, that income is ensured and
that there are not many ties (less than an actual job) was an ideal framework
for polishing my skills on some parts of the stack (React and general front-
end design).

After that, going back to side projects felt much easier, some decisions which
would have triggered anxiety attacks before seemed more obvious.

If you can't/don't want to go the freelance way, it may work with other work
organisation ways, as long as you're not the (only) one who has to make the
non-technical decisions, so you can focus on gaining experience dealing with
the technical part of problem solving.

~~~
pythonbase
Doing freelance gigs is a good option to pick up new skills. If you can hit
the ground running and cope up with the stress of learning and delivering at
the same time, go for it.

Side note: I got into Python, and web scraping in particular, by picking up
few freelance scraping gigs. Learned a lot in few days and this sparked my
interest in Python.

------
caseymarquis
I would strongly advise that you pick a stack, and then build a library or
repository that you can clone in order to easily make new projects and push
them to Heroku.

You're probably going to think of dozens of things it would be neat to work
on. If you have to spend a week each time you start a new project before you
get to the interesting part, then you're much more likely to just give up. If
you can have a new website online in 5 minutes with free hosting, https, user
auth, a database, and a basic frontend, then you get to have fun doing the
interesting parts.

I did this with my current stack of choice (.NET Core/VueJS), and left myself
directions for getting a new project going:
[https://github.com/caseymarquis/QApp](https://github.com/caseymarquis/QApp)

------
saadmrb
You sit back down to start with the coding, then reality strikes!

There is a lot to do. There's market validation, finding customers, talking
with people, creating landing page and coding.

You feel so overwhelmed about all the things to do that you decide you'll
start the side project later, and it bites the dust.

So my advice is : Just start.

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

don't we all suffer from Imposter Syndrome in one way or another?

Why not try to go back to the basics. Don't beat yourself up, or pressure
yourself. I would do research on a specific stack I like first and what I want
to learn more about. Then dive into that very deep. The more I learn about the
stack the easier it is to find ways to apply the stacks advantage in specific
use-cases. Then try to build something based on that. It's sort of the reverse
what I would "normally" do, but more fun because I allow myself to tinker and
make mistakes (or do something outrageous, just for the sake of proofing it's
possible to do it with that technology). Usually the decision what I build
automatically emerges in that process.

if unsure if _floating_ or _swimming_ why not float[1] for a while?

[1] from Hunter S. Thompson’s Letter on _Finding Your Purpose and Living a
Meaningful Life_ [https://fs.blog/2014/05/hunter-s-thompson-to-hume-
logan/](https://fs.blog/2014/05/hunter-s-thompson-to-hume-logan/)

 _> And indeed, that IS the question: whether to float with the tide, or to
swim for a goal. It is a choice we must all make consciously or unconsciously
at one time in our lives. So few people understand this! Think of any decision
you’ve ever made which had a bearing on your future: I may be wrong, but I
don’t see how it could have been anything but a choice however indirect—
between the two things I’ve mentioned: the floating or the swimming._

ps: for me one of the most soul crushing and mind-numbing things is having to
wrap some fragile REST endpoints into my app. Doing so can quickly get results
and I understand why people do it, but in a side project I rather learn what a
specific IETF/RFC or academic paper is about and then do something with that.
The experience/knowledge from that is IMO much more valuable than being able
to hammer out 3rd party API's in whatever language.

------
mysticmode
As someone said below, your anxiety or too much analysis has to be look at it
in another level.

But as far as tech stack goes.. This is my opinion.

There is a lot going on, lots of new tools, technologies and resources coming
along. But it is totally fine with what programming languages you are
comfortable with at the moment IF you are going to do a side/hobby project.

Anyhow, you will have to iterate it a lot on the go. Honestly, some parts of
it can be fun and some others wouldn't be. But you have to keep up with it in
order to do the release.

So, I'd put this Addy Osmani's quote here: "First do it, then do it right,
then do it better".

All the best!

------
_august
This is a real hurdle to starting projects. Spend a day researching stacks.
Keep it simple. Go with tech that you know.

My current stack is:

    
    
      * Creat-React-App
      * Node/Express Server
    

This keeps things super simple and basic, and I can extend it with Mongo /
GraphQL / etc etc.

If you know python and want to use Vue, you could do:

    
    
      * Simple Vue frontend
      * Flask API
    

Worry about things like SSR, routing, etc, afterwards when you have something
basic running. It's MUCH easier to iterate, than it is to start something. So
make the starting part easy.

------
f2000
IMHO, the best stack is the one you are most familiar with. Start with what
you are most comfortable with and build from there.

The hardest part is coming up with a product that someone else would pay money
for and then making that first sale.

btw, I love reading about tech stacks, This vs. That vs. Other blogs/articles
- but honestly, it just a distracting hobby at best.

This is advice for bootstrapping. If you're trying to get a job, then yeah,
focus on some specific stack and start learning it and building projects to
put on github and blog about.

------
rando_guy_here
I think you need to ignore the projects you are trying to do and instead work
on getting a decent CI/CD workflow setup, preferably with strong automation
driving it. The reason I say this is that it sounds to me like you are a
victim of lots of unfinished projects that probably never got running properly
in dev, let alone in a deployed environment. I've been there and I know it's
very demoralizing to work on something and not close the loop on it, and to be
staring at a mass of code that didn't go anywhere. I fixed this in my own
projects by starting to treat my side coding as proper development work. I put
together a Jenkins container with pipelines that test/build/deploy my code
automatically. I actually write tests and spend real time on architectural
decisions that I might not have cared about if I was just hacking. The result
has been that I'm a stronger dev now, much more professional and productive in
my workflow, and my side projects are actual software that builds green and
deploys. It took me like a month of side time to set that container up like I
wanted it, but it has completely changed how I feel about my work. I take it
seriously now. Give this a shot if this sounds right to you, I think it could
help. Best of luck:)

------
meesterdude
Obviously, the paralysis and anxiety is something to look at.

Also: I wouldn't so recommend Vue. Focus on rendering boring, server-rendered
HTML first. Add vue later.

I'm a big fan of rails for the unique focus on developer happiness and
velocity it places on the stack. There are similar stacks "technically" but
it's the difference between a modern OS and windows 3.1. To which I say, the
stack DOES matter; they are not interchangeable because they each have
different philosophies and priorities. If rails wasn't free I'd paid for it.

But it depends on your priorities and what you're trying to do. I want to be
effective at, and enjoy building, web applications. But if you're trying to
just learn X technology or language vs building an MVP, those priorities can
shape what you work with.

My best advice is aim to succeed even if you fail. Do things the RIGHT way,
use the tools / technologies you've always wanted to. Even if the project goes
nowhere, at least you got to play with something, and be professional about
doing it.

Lastly, think of small problems you COULD solve, or explore. then build off
those.

------
latte
Just as a suggestion - try to focus on your ideas, not on the technical
knowledge that seems necessary for the implementation. To roll out an MVP, a
Django app on PythonAnywhere may be enough.

Only after you have tested your app with some real users and when you start
feeling that PythonAnywhere is limiting you, start learning about more
advanced technical stacks or infrastructure - you will feel more motivated to
learn it if there is a need to use it.

------
TrevorFSmith
Instead of starting on your own, maybe look for an open source project that
you find useful and seems well maintained with an active community. Then see
if they have marked any of their bugs or issues as good for new devs. You'll
learn about the (sometimes terrible) group dynamics of software teams, you
won't have to start a project from scratch, and you'll be exposed to the tools
and code patterns in use today.

~~~
iudqnolq
Can you expand more on how to go about learning to understand a large open
source codebase for the first time?

~~~
TrevorFSmith
Usually it's best to pick up one of the "good for new people" bugs and then
work your way out from there, eventually reading (or at least skimming) most
of the code and understanding the build tools.

~~~
iudqnolq
I really want to get started contributing to Rust, and they have well
documented good for newb bugs. Still very intimidated because I've never
worked with a codebase I couldn't read all of in a sitting before. Any
suggestions?

~~~
steveklabnik
You might enjoy [https://rust-lang.github.io/rustc-guide/](https://rust-
lang.github.io/rustc-guide/)

But seriously, the team is very happy to onboard new people, don't worry about
it. I know it's not that easy to just stop worrying, but it's not a big deal
at all. The compiler team is happy to help.

~~~
iudqnolq
Awesome! I've been lurking on Zulip, and everyone seems so nice. Should
probably just ask...

------
danschumann
always work on the step you know you can take next. There are lots of unknowns
in every project, but there are usually a few knowns. Usually the problem is
not pulling the trigger to move forward on the knowns. You will have to re-
write, you will have to backtrack, you will end up wasting oodles of code and
time, but steps backwards are steps forward when learning is a part of it, and
learning is always a part of it.

------
wewegogo
Idea for a simple Flask/Vue App: Multiplayer Anagram

I used to enjoy playing this years ago on a flash based gaming website but
thats been taken down and I can't seem to find a simple html based one that
lets you play with others online.

Gameplay:
[https://www.youtube.com/watch?v=Tb5-A-FLC98](https://www.youtube.com/watch?v=Tb5-A-FLC98)

------
theossuary
> every time I start I get overwhelmed with what stack I should use, and how
> to actually get a ‘real’ application out

Decision paralysis is something I struggle with too. Being able to recognize
it and move forward, instead of second guessing yourself, helps a lot. It's
good to remember engineering is about making trade-offs. Every solution will
have shortcomings.

I've also found being strict about refactoring to be very useful. Don't solve
problems before you need to. Don't write a function till you actually need it.
Don't start with a complicated class structure, start with a some procedural
code and naturally grow and refactor it. Don't try to start a project as if it
were already 6 months old.

Bit of a ramble myself, but I get it. Second guessing your technical decisions
is just something we have to find strategies to work around. Doing that makes
us better. Working on side projects is a fantastic way to do it too, so kudos!

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

Probably you need to redefine what MVP means. Start with like a hello world
app in Vue, and get it deployed to the point that you can show your friends.
You want to build a feedback loop as quick as possible, and many tutorials
skip that. So get to where you can build deploy and test ASAP, even if the
features aren't really there.

Trying to include too many APIs up front is going to lead to a combinatorial
explosion of problems. Learn VUE first (maybe a blog project or todo list or
whatever is the popular tutorial project these days), then set about learning
the Spotify API once you have a chance of knowing whether any given problem
you encounter is the fault of spotify, the api, or vue =)

------
PopeDotNinja
If you find a old tutorial that you like, how about updating the tutorial for
yourself and writing a new one as you figure it out? I learned React in 2018
from a tutorial made in 2016. The first thing I had to do was learn how to
update Webpack from version 2 to 4. And while bits of the tutorial were
outdated, a lot of it still applies.

Also, you aren't in control of what tech stack you use. I once moved 4000km
from San Francisco to Washington DC to take a Ruby job for doing Selenium
style automated testing on Android . Within a week I learned that Ruby
approach wasn't going to work, and then I had to learn Java from scratch.
Focus on learning how to complete tasks in the something, and worry less about
living in a comfortable box labeled Full Stack Python Developer.

------
leoplct
Solve a problem that other hate to solve it because it's frustrating and
boring.

Start looking on UpWork, Fiverr etc...

------
Habesha
Part of this tutorial shows you how to use spotify API (among other APIs).
[https://www.freecodecamp.org/news/apis-for-beginners-full-
co...](https://www.freecodecamp.org/news/apis-for-beginners-full-course/)

------
j45
First, rediscover how to build for fun. Highly recommend playing as a beginner
with JavaScript in 30 days and p5.js.

If you like a vue, take a paid vue course that costs $20 or so per month. The
material will be vetted, you won’t have to piece as much together.. and can
ask lots of questions.

------
mrpoptart
Do everything with no framework. Vanilla JS, basic Rails, Basic PHP. Whatever
you know the best, use it and build it. Don't get distracted by features.
Until you have a working system, you don't need to refactor. Start with one
tiny bit and move on from there.

------
NightlyDev
You say you want to use python or nodejs, so just go with one of them and
don't look back. It really doesn't matter what you choose, just start
creating. Don't spend days upon days trying to predict issues that you might
never ever have.

------
m__
Subscribe to and watch destroy all software by Gary Bernhardt. It will teach
you skills that are applicable to any stack and more importantly, watching him
program will show you what us possible in terms of craftsmanship.

------
agumonkey
I had a similar work path, most side projects ended up as READMEs, some I
would finish because of interviews, but nothing satisfying.

Right now I work with in a restaurant, and the dude manages sales by hand. So
naturally I tried making a stupid simple order intake thing in Vue.

\- Having a 'real' use case with a potentially real user gives a lot more
motivation. And at the same time I can learn and fail on my own.

\- It grew from simple form to nested editor to multiple object stores and
pages

\- It's a bit above the usual frontend tutorial (todomvc and similar) without
being too ambitious

Maybe that can inspire you a bit. Good luck

------
loblollyboy
Building something w django is easier than bug fixes (imho). Django is just
that well documented and easy to use. Bugs, of course, are not. If you want to
write code, for _your_ features, just write it in your view (this is what
django calls the controller). Maybe it should be written somewhere else, but
in my projects I wrote most of the logic in views, and if you are using other
libraries/apis, you can just follow their docs or use stackoverflow. If you go
down this route you will, at the minimum, learn a lot.

------
lawn
> but every time I start I get overwhelmed with what stack I should use, and
> how to actually get a ‘real’ application out.

Just start.

If the stack is your problem, just pick one. _Any_ will do. Then just slowly
start working towards your goal. There's no shortcut.

And this danger of getting stuck can come up again and again. For example you
might be worried that the architecture you chose is bad, and you spend a lot
of time making it perfect (which is impossible). Realize that the important
thing is creating something, so you should ruthlessly push forward.

------
bakhlawa
You’ve already got a lot of great advice. I’ve been in the same position and
would submit I’m still in the same spot. What has helped is “scratching an
itch”, trying to do basic things. The feeling of accomplishing something, even
small, is powerful and motivating.

One idea I didn’t see suggested is pairing up with a friend and working on
learning/doing together. It will help push through when the learning gets
overwhelming/frustrating and bring some joy back into the process. Good luck!

------
bakhlawa
Pair up with a friend and learn/do together. It will help push through moments
of frustration and a partner will serve as a check on giving up prematurely.
Good luck!

------
NicoJuicy
Everyone starts with no knowledge.

A good developer is one who walked the road already.

Why not start as a junior in a real team, learn from better persons.

Learn the basics first ( eg.Clean Code).

Learn architecture after ( 4layer).

There will always be a nicer js stack, I have a lot of experience. But I also
struggled how to set up the frontend stack upfront in Vue ( not single pages).

I would actually advice on . Net core, the documentation is great, visual
studio community is great and a lot of work is done in c# + tutorials are
widely available

------
dnautics
If you want a stack that won't force you to learn a billion things, I
recommend elixir/Phoenix which will take you from hello world static up to
javascript-free serverside rendering, deploying with ssl (no nginx/uwsgi
necessary), and there are nice services for deploy like gigalixir.
Documentation is great and comprehensive. It's also just about the most fun
programming language I've ever encountered.

Good luck!

~~~
AlchemistCamp
Elixir is my go-to default for any new web app. Another great deployment
option is Render (founded by early Stripe dev, covered here:
[https://alchemist.camp/articles/elixir-releases-
deployment-r...](https://alchemist.camp/articles/elixir-releases-deployment-
render))

------
thinkingemote
If what you are doing isnt working how doing something different?

For example how about working from the outside in? Start with a basic UI made
in a graphics program and work your way to implement it. Or just do the
smallest API call you can make.

The key thing is to do something you are interested in, not what WE are
interested in. Do it because you are liking it and do not do it to post on
Show HN.

And we don't care what technologies you use, really, it makes no difference.

Follow your passions.

------
sergiotapia
Don’t follow tutorials. They kill your creativity. Instead think about
something useful to you and build it. Get stuck? Learn and ask. Build more.
And so on.

~~~
criddell
I think tutorials can be useful, especially for something entirely new. If I
just open a text editor to a blank page it's really hard to get going. If I
have a demo project it's much easier to start to modify that to do something
else.

------
pm
I suffered from the same paralysis when attempting to do my own projects, and
it had less to do with the tech than it did the problem I wanted to solve.

Eventually, to get started, I settled on doing a small command line app in
Python/Click. It was a utility I actually needed (even if someone else didn't
really need it), and it's the kind of thing I could iterate on without too
much trouble.

It's usually much easier to start small.

~~~
passthejoe
I did the same, only with Ruby. Iterating now would be refactoring with better
code and adding a GUI. But now I have a working utility that I use every day.

------
zoom6628
Been there myself. My solution is forget all those frameworks. Just build
something from scratch using as little bling as possible. Maybe even just
python+bottle for a web app. That should take less than one hour to get a
result. The. Do tasks in one hour chunks that get results. E. G. Add argparse
and command line help, add a logo to displayed html page.... And so on till
you have broken thru.

Good luck.

------
crazypython
Remix this. It is a base version of a popular MMO game. I am developing one of
the better versions, with the game split into multiple files and with many
engine improvements. If you make something impressive enough, I might invite
you work on my game with me. [https://glitch.com/~arras-
template](https://glitch.com/~arras-template)

------
sillysaurusx
What sort of projects do you enjoy working on? If you can answer that for
yourself, then you can usually find one that doesn't seem boring.

------
deepaksurti
>> I just want to work without feeling bored or overwhelmed

Then I guess you need to work on some hard problems, sorry if I have assumed
you haven't tried those.

This can be a good starting point and the ROI will be really good, if you are
looking at long term ROI. [1]

[1]
[https://news.ycombinator.com/item?id=21790779](https://news.ycombinator.com/item?id=21790779)

------
ConcernedCoder
Every cool thing that I've ever built has started with an idea becoming a
basic ( and I mean really basic ) proof of concept... just enough to see all
the concepts and moving parts working together... start there, forget about
all the tech stacks and just sit down and code something in whatever language
you're comfortable writing in... the rest will follow.

------
richardjennings
I would suggest taking all the stacks you are interested in end to end with
automated testing and deployment. A static html page with consideration to
aspects such as accessibility and time to first render is not necessarily
trivial. Building out in different stacks from such a starting point would
likely give you a valuable insight that is imho often overlooked.

------
danans
> but every time I start I get overwhelmed with what stack I should use

Make an educated guess and build your idea using it. Anyways, no matter what,
you are going to throw away the first version you make, whether you succeed,
fail, or because the first stack you chose wasn't the best choice.

The knowledge you are left with after that process will be more valuable than
anything else.

------
jraph
I would advise you to try to build something simple and small. It may become
bigger afterwards. Ideally, this (initially) small project would scratch an
itch.

That way, you have something immediately motivating, small and simple working
soon so you don't get lost (lack of motivation, too much complexity) and
overwhelmed, and you can still improve it later.

------
omneity
Start with the smallest piece that gives you motivation, might not even need a
backend component.

For example, a tiny widget that shows you an artist page or whatever, that can
be embedded.

Then ship that, show it to HN and all around. This should boost your energy
and motivation.

Tackle a slightly bigger project afterwards. Loop a few times and voila!
You're over the hill.

------
29athrowaway
1\. Think of a highly desirable role.

2\. Visit the website of a company that you would like to work for.

3\. Look for a role similar to your highly desirable role.

4\. Read the requirements for that job.

5\. Learn the skills / technologies listed as requirements for that job.

You don't even need to apply for that job, and you can do this as many times
as you want.

------
Gabriel_Martin
Help someone. Remove indecisiveness by putting into their hands what you'll
use by following their need (and their lead!), that way you can structure your
hobby time around building it for them, and not have to worry so much about
tutorials and stacks, you'll have a goal.

------
pbreit
If you are not employed, go get a job.

------
aerovistae
You are in a position extremely comparable to one I've been in myself. I had
the same feeling about my jobs, also hadn't worked for awhile, considered
myself lazy/coasting, wanted to get hobby projects going but had trouble.

So, having had success with my hobby projects in the sense that I reached my
technical/product goals and then ended up landing a great tech job off of
them, here are my thoughts, in no particular order:

1\. Tech stack doesn't exactly matter. Don't overthink it. I personally love a
variety of languages and want to be fluent with django, flask, express,
sinatra, node, spring, and sails. That is, however, impractical, and comparing
them endlessly is unproductive. They can all do what you need. Some are more
complex than others, and learning curve is IMO the most important point of
comparison. I ended up going with expressJS which is fantastically
straightforward to set up and work with, and is extremely powerful and
flexible and mature. That was partly because I was already fluent in JS from
doing frontend work.

2\. I wouldn't really recommend tutorials. If you wanted to build (for
example) a twitter clone, you probably already know you need backend code
serving HTML views. So just follow through the "Hello world!" tutorial on your
framework of choice until you have it serving HTML views, then build off that,
progressively googling things as you add complexity, e.g. "how to do user
login with django". If you encounter a bit of syntax or a concept you're
unfamiliar with, google the shit out of it. If you find nothing, ask on
stackoverflow. I have asked like 400 questions there. I'm shameless.
Stackoverflow tells me my questions have helped 3.7 million other people over
the past 6 years.

3\. If you want to do Vue, do Vue! Great! Frankly I think the prominence of
react now is so great that I would be reluctant to focus energies on something
else, but any good company won't care if you already know it or not, because
you can learn it on the job.

4\. Kind of repeating myself, but don't look for "spotify vue tutorial
project"....that'll get you nowhere. Figure out how to use Vue, then figure
out how to use the spotify API, then tie them together on your own.

5\. It really helps to nail down what you're using. I did a lot of comparing
for where to host my application, a lot of googling "X vs Y" and finally went
with Heroku. It really depends whether you want to be doing your own server
administration or whether you want most of that handled for you. EC2 and
digital ocean will leave you managing your server, where Heroku for instance
will not. I strongly recommend heroku, personally, or something similar to it,
for the stage you're at.

6\. Once you nail down HOW you're going to deploy your product, like with
heroku, DEPLOY IT IMMEDIATELY! Deploy your first line of HTML, the one that
says "welcome to my website" and make sure you can see it at `your-
website.com`, whatever your URL is! It's so motivating to get that link out of
the way, to know you already have the setup ready to put the code into
production. As you commit each new thing, keep adding it! Keep deploying! It
will feel like you're really getting somewhere and keep you motivated. If you
wait until it's finished to do all that, you're far less likely to ever get
there because mentally it will feel like you're eons away from completion.

~~~
HAL9OOO
Thanks man! You're post resonated with me. I also believe I need the original
"feel good" feeling of deploying something early to make my confidence go up.

------
austincheney
My personal advise: don’t waste time dicking around with a tech stack. Just
write the code for your application as directly as possible. Write what’s
important first to make it work then incrementally add features.

A tech stack is like a cookbook. Commercial cooks don’t dick around with
cookbooks because if they ever want to make money they must be able to ship a
product fast and scale their effort across multiple orders simultaneously.
Cookbooks are written for a home user to slowly slave over a single entree as
a cooking passion. Likewise a tech stack is for a corporate developer who has
more time to burn and would rather dicking around with configuring things than
making tough product decisions.

Not investing in a tech stack will force you to question your basic
assumptions of architecture so that you focus first on the areas most
important to your application. That puts your product first. As the
application grows refactor as necessary.

------
scottlecrab
Pick anything on here that interests you and get to it:
[https://dev.azure.com/s-lambert/_git/Lets%20Get%20Wild!](https://dev.azure.com/s-lambert/_git/Lets%20Get%20Wild!).

------
kartoniks
Go agile for yourself. Push little changes and then increment, making stuff
better. Try to get a feature done on the first day, no matter how small it is.
It feels very rewarding and motivates to continue. Little steps first, no
matter the stack

------
werber
I wouldn’t try to Learn nuxt before Vue. Frontendmasters has a great variety
of tutorials for Different js skill levels

But that aside, I would probably try to work through eloquentjs, the projects
ramp up very quickly and are a great foundation

------
LegitGandalf
I recommend running a serverless stack so you can avoid getting hung up on
infrastructure shenanigans. It's super cheap too. React SPA via CreateReactApp
using cloudfront+s3 to host the HTML+css+js and API gateway ->lambda backend
-> w/dynamodb to store your data and you can get something cool and useable
going. In that stack you can mix and match other UI tiers, swapping vue,
angular or polymer in for react.

I recently completed a proof of concept with both polymer and react on the
above stacks, probably going to do angular next. There were some annoying
things in the area of error reporting being unclear from AWS' stack, but once
I figured out that CORs warnings from the UI tiers accessing the API gateway
usually mean a self inflicted typo in my url it was pretty smooth sailing.

~~~
stoicShell
A few questions, as I don't know AWS much beyond basic VMs.

\- Is all this easy to do following their docs, are we talking 1 h setup or 1
day?

\- Cost: how much are we talking per week/month? (assuming no traffic but
yours)

~~~
LegitGandalf
The setup was pretty straightforward with tutorials galore and it's rediculous
cheap, the most expensive part is the route53 stuff as it costs a buck a month
or something like that to route a domain. Well, I bought a few domains too so
those are like 15 bucks a year (I got them from a random registrar, not aws).

Don't get me wrong though, it won't be a path of roses, aws error messages
sometimes make no sense whatsoever and require some googling to figure out,
typos are NOT your friend!

Luckily Google usually led me to someone trying to set something up similar
and I could logic it out from there. My #1 thing that I wish someone had told
me was that if you make a Ajax call to your web API and the browser spits out
a CORS error, check, triple check the url and what kind of call you are making
(POST, GET, etc) because at least on my setup mistakes in those actually shows
up as a CORS error instead of your typical 404 error.

I also bit the bullet and figured out how to use one of the serverless sites
to deploy the AWS API+lambda+dynamodb one one fell swoop using a .yml file.
But first I did it all by hand via the AWS gui so I could get some idea of how
it worked. That .yml file is a whole other rabbit hole as the error messages
are pretty obtuse at times.

Edit: One thing to watch for on cost is the dynamodb, by default they reserve
25 total transactions per second on the free tier. If you try to increase the
performance by reserving much a whole lot more, like 1000 tps per table/index,
that will get pricey right quick. So either leave it at 25 and recognize that
if you add an index things might get throttled while it builds the index, or
do what I did, which is I went ahead and switched it to the pay as you go
model since $0.20 per million transactions is plenty cheap and I'm not even
flirting with that 20 cents on my proof of concepts that span 5 different web
domains.

~~~
stoicShell
Wow, that is everything I asked for and more; thanks a lot for taking the time
and effort to summarize all this. Now I feel like I can get started with this
tomorrow.

Couple remarks:

> CORS

Oh, that may save me lots of time... Seems related to http headers at first
Googlance? These bit me in the past (in middleware and backend apps) and I
still don't have a solid grasp of when I should use which.

> dynamodb

I'll probably do the same as you then.

I've got hobbyist hardware at home (behind 1G fiber) so I usually use that as
a lab — I still have to make a 'serverless' platform though — so anything too
expensive I can balance back 'on-prem'.

I need to learn AWS anyway (who doesn't, I figure, if you intend to CI/CD as
small/one-man team). Glad I can go the serverless path to get my feet wet!

Thanks again.

------
ngz00
Anyone have any good recommendations on deployment platforms that are cost
effective and don't compromise on technology? Think Heroku, but with support
for HTTP/2 and internal mesh networking.

------
ChrisMarshallNY
I can't exactly tell where you're at, as far as the need for work.

From what I can see, it looks like you are able to keep the lights on, and you
don't need the work.

If so, this is where I'm at. It's both good and bad.

I may be coming from a very different place, so YMMV.

I worked as a "ship" programmer and manager for over thirty years. I've been
writing shrink-wrapped software (actual deliverable) for my entire career.
It's taught me a great deal.

The last decade or so, my management responsibilities meant that I couldn't
code on the job, so I created a number of open-source projects. I didn't have
a "We own the ideas that you come up with in the shower" clause at work, so I
was free to do this.

They have been fairly successful, in a rather limited scope. Since all the
work was initially done with a "bus factor" of 1, the projects are not
massive; but they are very, very important to a certain demographic. They
needed to be done at a professional level; not at a "hobby" level.

I am now at a place where I never need to work again, if I don't want, but I
want to work.

During the week, I get up every morning at 5AM, do my exercise, then roll up
my sleeves, and start coding. Weekends, I let myself sleep in until 6:30AM.
I've been doing this for the last couple of years. It is now Christmas
morning. I am taking my time doing my exercise, and will get back to coding
the the Bluetooth OBD driver I'm making in an hour or so.

Yeah, I'm obsessive.

I write every line of code as shipping code; even if I never plan to ship. My
test harnesses are fully-qualified apps that could be released to the app
store, with localization and full-fat documentation.

Will I work again? Maybe. I certainly have skills and experience that could
make folks with established corporations a lot of money, but I've found they
are reluctant to hire folks my age; regardless of what I'm capable of doing.
I've set up a consulting corporation, and we'll see where that goes. If
nothing else, it gives me a structure to buy the toys I want.

No matter. I work as if I am writing shipping code. The satisfaction of
finishing a deliverable-level project can't be replaced. I do everything as
open-source. My portfolio is _gigantic_ , and is not consistent of dozens of
forked projects. Just about every line of code in it was my own. My GitHub ID
is solid green. I have over a decade of commit history in dozens of repos.

I'd suggest that you consider establishing a portfolio. Write code that is
meant to be shared and re-used. Write developer utilities, drivers and tools.
Test the code well. Document it well. Craft it like you are a master
goldsmith, creating royal treasuries. Establish a personal/professional brand.
Decide on what that brand means, and make all your work reinforce that.

The world needs high-quality software. Write as a vocation; not a hobby, and
whether or not anyone else values or pays for your work. If nothing else, it
will be useful as an example to others.

Maybe find an NPO/NGO that doesn't have a pot to piss in, but a cause you can
support. Write pro-level code for them that they could never afford on their
own. That's what I did. I can definitely say that the code I've written has
saved lives, and restored hope.

It also feels great to write beautiful code. Every project I do is completely
shippable, and highly-polished, with strong branding, rich UX and a great deal
of documentation. I'm a reasonably good artist. I was trained as one, many
moons ago.

For me, doing the work is its own reward. I haven't been paid to write code in
over twenty years. I don't care. I love coding. I've been writing open-source
stuff for most of those decades. When they stopped paying me to write code, I
didn't miss a beat, and kept writing.

I also like to write articles on my personal sites and Medium. I don't
particularly care if anyone reads them or not. They give me practice doing
another thing that I like to do: talk about myself ;).

Just my $0.02.

Have a great holiday season!

~~~
HAL9OOO
Thanks man! I've saved up some money and It's always seemed in my path to stop
working at a big company and try to do my own thing... just I'm scared and
also I can see when the money is going to run out and the thought of going
back to a 'normal life' scares me. I know I have it in me but I just have to
find something in myself that I lost along the way. Hard to explain.

~~~
ChrisMarshallNY
No need to explain. I understand completely.

I wish you luck, and your extracurricular work can definitely be a stepping
stone towards your dream.

The only suggestion I would make, is to keep your eye on the ball. Always make
sure the product and the goal get first priority. If you make enough to buy a
Tesla, maybe defer the car, and get some test kit, instead.

------
sjg007
The key to treating anxiety is to confront the fear. But it's not clear what
your fear is here.

If you wrote some code and put it on GitHub would that count as deploying real
code?

------
dalacv
Try using bubble to build your prototype.
[https://bubble.io/](https://bubble.io/)

It might be something that helps you

------
mch82
Art projects & games are fun ways to learn.

Since you mentioned Python, Django is a good option to get started & build on
a reliable foundation.

------
soheil
Use ruby on rails with jquery and mysql on aws and ignore all the haters.

Close your eyes and just build what you want. Those technologies have been
tried and tested over and over again yet the latest js stacks have cult like
followers for a few years and seem to take the entire internet by storm before
no one hears about them again.

If you need inspiration to ignore all the haters I recommend the creator of
ruby on rails. He also accurately mentions how TDD and VCs are important
plagues to be avoided [https://twitter.com/dhh](https://twitter.com/dhh)

------
willart4food
[https://www.startupschool.org/](https://www.startupschool.org/)

------
idclip
I have a similar issue, so if youre open to it, pm me, let’s coop this.

I want to start a /js/node etc myself to learn.

------
Quequau
Oh wow I'm in the same boat only I used to do embedded development.

------
WalterBright
I'd buy a kit. Lots of them on Amazon.

------
mch82
What is your goal with the project?

------
cryptozeus
Why do you get bored and quit ?

Start there.

------
readme
I have a colleague like you. Your problem is this: you say you want to build
something cool, but then you follow up with "but every tutorial I read..."

There is NO guide to building something new and cool. Yeah, you will build
upon existing stuff, but you need to come up with your own plan and then
research specifics to fill in the blanks. You may have to repeat work, so just
accept that.

~~~
not_kurt_godel
This is great advice. Stop making "learning the framework(s)" part of the
goal. Pick something that is in the rough genre of what you want to do, and
bulldoze through it to Do The Cool Thing. Accept that you will be working
inefficiently and painfully at times. That's how you gain experience, and
through that experience you will grow an understanding of how the frameworks
differ from each other and which are most suitable for certain kinds of tasks.

------
elfexec
> I just want to work without feeling bored or overwhelmed.

Imagine being bored AND overwhelmed. Now that's something I wouldn't wish on
my worst enemy.

But if you want to deploy "real code", I suggest choosing a programming
language and building a "complete software".

1\. Write a compiler for C ( or more realistically a subset of C )

2\. Write a basic web server

3\. Write a basic database ( RDBMs )

4\. Write a basic browser

5\. Write a basic chess engine with board ( if you are interested in AI topics
)

6\. Write a basic kernel ( or pieces of the kernel )

7\. Write a basic debugger

Or if you graduated from a CS program, go look through your projects that you
did and redo them or expand on them. Anyways, hope you find the project you
are looking for and good luck.

~~~
edgyquant
The only one of these that isn't going to be overwhelming is, maybe, the chess
game.

------
jstewartmobile
Do something else. My God there is so much that needs to be done outside of
software, no one is doing it, and civilization is turning into shit because of
it.

If you need us to give you the secret sauce to doing software without feeling
bored or overwhelmed, I hate to break it to you, but there is no secret sauce.
Roll with that.

------
sonny9966
Free LIVE Training Webinar Reveals...

"How I Earn Up To $14,444 Per Day Just Sending A Quick Email To People Who
Visit My Odd 2 Page Website…!

And How You Can Get A Copy Of Everything I Use To Do This For FREE…"

[http://bit.ly/ILOVEMoney](http://bit.ly/ILOVEMoney)

Hurry Up Very Limited Time

FREE FREE FREE

