Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Haven't worked for a while, best guide/advice to start a hobby project?
109 points by HAL9OOO 5 hours ago | hide | past | web | favorite | 60 comments
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 ~






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.


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.

Completely agree.

Your only goal is build then launch. Be 100% focused on this.

Reading and learning will be required, but should be set against a specific task that is part of your product launch goal. You only need to research as much as is necessary to achieve the next task (that gets you closer to launch). Then you move on. Your code doesn't need to be a masterpiece. It just needs to work. You don't know which idea will be a winner, yet, so save the really hard work for the idea that sticks.


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~

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

What is your goal with the project?

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.


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!


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.


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!

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.


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

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.

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.


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.


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.


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


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.


Awesome. And yep, that's the idea, just get it moving and as you go through the project and learn more you'll find things you can (or want to) refactor to make better. But at least you moved forward.

You aren't alone, we all need a little nudge in a specific direction sometimes. :)


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


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


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.

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!


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.


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


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.


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.

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


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.

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.

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


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.


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.


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.

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

If you have an open source codebase you use for other projects or for personal reasons, usually you'll notice some rough edges that you want to see fixed. I have found that diving into the code around those issues is a good way to get started.

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.


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.

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.


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


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


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.

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

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.

Why do you get bored and quit ?

Start there.


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


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.


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.


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)


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.


For the first year, you get one million requests per month for free. After that, it’s $0.20 per million requests. There’s also a component based on time & memory usage, but it appears to be small, too.

https://aws.amazon.com/lambda/pricing/


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.

If you are not employed, go get a job.

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.


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

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.


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


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.

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.

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.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: