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 ~
Happy Holidays Everyone~
/\
< >
\/
/\
/ \
/++++\
/ () \
/ \
/~`~`~`~`\
/ () () \
/ \
/*&*&*&*&*&*&\
/ () () () \
/ \
/++++++++++++++++\
/ () () () () \
/ \
/~`~`~`~`~`~`~`~`~`~`\
/ () () () () () \
| |
|`````|
\_____/
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.
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...
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.
Find something you are actually passionate about. It doesn't have to be a big thing. You shouldn't care if it is a cool thing, or what other people think of it.
When I'm interviewing, I love when people showcase stuff they enjoyed building, rather than something bigger they made following a tutorial.
Here is an example of a really small project I enjoyed working on - https://muffinman.io/vertigo/ It was so fun, and I learned some canvas/svg stuff I never touched before. Even now when I look at it, it brings a smile to my face.
Another thing I think you should do is to document the whole process and write one or series of blog posts. It will help you understand the whole thing better, and help people in similar situation.
Good luck and please share with HN whatever you end up making!
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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/
> 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.
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!
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.
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.
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.
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.
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.
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!
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 =)
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.
Start looking on UpWork, Fiverr etc...
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.
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
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.
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!
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
Good luck!
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.
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.
Good luck.
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]
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.
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.
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.
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.
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.
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.
But that aside, I would probably try to work through eloquentjs, the projects ramp up very quickly and are a great foundation
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.
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!
If you wrote some code and put it on GitHub would that count as deploying real code?
It might be something that helps you
Since you mentioned Python, Django is a good option to get started & build on a reliable foundation.
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
I want to start a /js/node etc myself to learn.
Start there.
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.
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.
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.
"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…"
Hurry Up Very Limited Time
FREE FREE FREE