I can't imagine ever shipping a side project. That's not why I build them. If I ever got to the point in my life where I do want my own company, a side project is not the way I want to go about it. Companies take a lot of work, that work has to be understood, then delegated and shared.
The technology aspect is really only 10% of it. Sure, it's the essential 0-to-1 kicker that gets you going, but once that's done you still have to find product-market fit. That quickly assumes second-job status and can wreck your personal life. I've seen it happen.
A side project means you're taking all that on yourself without any help or real guidance. Not having that help means that when you finally do ship your side project, it's probably not going to achieve the kind of rapid growth you need to make scaling up possible.
And you really need rapid growth in order for working on a startup of your own creation to beat out having a reasonably-decent job. And if you don't have a reasonably-decent job, it's way easier to switch jobs / industries than it is to build out your own company.
What I want out of a side project is the kind of deliberate practice that is often lacking in my real job. Also to chase down random mind hares that seize my interest.
There are tons of other people who also think side project is a way to learn something new, yet they ship.
Also there are tons of startups that started out as side projects. Facebook did.
You have no excuse. Stop lying to yourself because it's not doing yourself any good. The only reason you're not releasing your side projects to the world is because you are afraid of criticism.
I agree with a lot of this. My one comment is that not all side projects are about a "full startup business". I shipped my 2 mo. side project this summer. Donors Choose Project Finder
https://appsto.re/us/JVmbab.i . It was 100% pro bono , and to keep my skills sharp. So far over $20,000 in supported donations. Keep an eye open for the next set of features :)
> And you really need rapid growth in order for working on a startup of your own creation to beat out having a reasonably-decent job
I disagree. You only need to get the income you want with the work you are willing to invest. Depending on what you do and what you need, that can mean that scaling up is not required at all.
Bootstrapping a business out of a side project is a thing.
I think I've released all my side projects to the world out of laziness: my Github account is not a carefully curated resume, it's just "things which were interesting enough to warrant source control".
I finished my side project a couple of years ago, released it, and then found I was able to quit my Python webdev job and go full time making video games.
The key difference is that my project was a video game (this one: https://www.youtube.com/watch?v=YwXl8lDrxn8) and that takes a lot of temptation to do what the OP is writing about, rewriting stuff in Haskell for example. The interesting bit when it comes to side projects (and now my full time projects) for me isn't actually the tools or the methodology or anything like that, but the end result. I spent my teenage years building games that I never finished, and it made me quite miserable, because I so just wanted to finish something. Anything.
I remember the first game I ever finished was a clone of Snake. There was nothing remotely interesting in the implementation or in the design, but I was so flipping pleased with myself, I had finished something! And that let me slowly build my projects up to more interesting endeavours, and eventually to one that could be sold. Starting small was the key for me, as I learned two things: 1 - what was 'too much' for me to try and tackle at the time and 2 - self-discipline, not chucking the project the moment I got bored, or had a 'better idea'.
This is the advice I can give to anyone who has a side project. Get to the point where you can show something to the users and just start adding stuff.
Even if it's just two lines of code or changing the favicon - still worth it. In practice, it's harder to do than it sounds, but I've been doing it for some time and it's been going great.
In reality, you won't have millions of users on day 1 no matter how great your product is. If you start small and keep adding stuff you will have more success.
In fact, the biggest challenge for side projects is marketing and not the tech or infrastructure.
However, it also depends on the goal - if you want to build the project that makes money it's completely different story to experimenting with tech. In the end, you get the experience.
For example, a few years ago I managed to build an overengineered CDN product that compressed images on the fly (almost on the fly). I shipped the project and it even worked great for testers, but I didn't get to the point where it makes money, so I shut it down as with half unfinished features as it was taking too much time.
While building it I managed to learn Go, improve my AWS skills, plus some other tricks. Now it sounds like a great investment even though I feel that I haven't completed the project.
Okay, I am going to share my secret for finishing.
I discovered this late, but am glad I did. Are you ready for it?
The secret is this:
don't start something till you finish the last thing, no matter how poorly.
This goes even at a "micro" level, so don't start distributing the load on servers till you finish the last thing (interface), no matter how poorly you finish the last thing.
As someone who is trying to learn to code on their own, I feel like I understand this. The first question of "which language/stack/etc should I learn first?" has haunted me for the years I have been trying and getting nowhere.
Not EXACTLY the same problem as the author, because I am not building out scalable infrastructure. I just spent a ton of time learning the fundamentals of angular and node, then try to understand express, then grunt, and mocha and bower and... now I have weeks into this pile of stuff... nothing working and I am frustrated, disappointed, and oh look Overwatch patch notes.. time to try out the new hero.
Unless you want to focus exclusively on Web development, I wouldn't recommend picking Javascript as your first programming language. The ecosystem is fragmented, and the language itself is probably not the best for teaching. Have you considered learning Python or Ruby first?
On the other hand, if you're committed to Javascript, I think you should start at the most basic level. Angular is good, but it's a complicated system that takes time for even experienced Javascript coders to get used to. Same with Express, Mocha, Grunt, etc. These tools incorporate complexity to hide it from the programmer. But as a novice programmer, you DO NOT want that complexity hidden right off the bat.
Assuming you've gotten past the very basics (syntax of programming language, executing Javascript in the browser, reasoning about simple scripts), I would recommend the following as an exercise for learning:
Pick a fairly simple website and try to re-implement it, without looking at the original code. Don't start with angular, bower, or anything else. Just Javascript, HTML, and CSS. This is the fundamental language all browsers speak, and you have to be able to understand it for everything else to make sense.
As you work on the project, you might start to find things annoying. Like, dynamically changing page content with Javascript requires a lot of code. How could you make it easier? Think about, and possibly even implement, a solution that makes sense to you. Then, once you don't need it, you can reach for a pre-baked solution (like Angular, Vue, or React in this case).
I've built (and continue to) a lot of companies using Rails. I also do Swift on iOS and have been playing around with Swift on the server since last year.
I have some friends that have an idea and I'm going to help them build it. So what do I use? The fast, low memory footprint of Swift?
No. I use Rails. I use bootstrap. I don't make a JS only frontend with api backend (Turbolinks works fine). I use what makes me productive and what's gets the first rev out the quickest.
For hosting, I put it on my Mac Mini (in my living room) via VirtualBox, with the same Nginx proxy I use for all my projects. I have no problems with scaling because I don't need to. Cross that bridge IF I get there.
I went through a number of years trying the latest and greatest frameworks, aws configs, etc. None it mattered to my projects. It did help with day jobs, but that was it.
Some other poster here was right when he said tech is about 10% of your business. There is so much other stuff outside of building your app/site and having analysis paralysis is gonna stop you dead in your tracks.
My advice (as many on HN have said before): go with what you know, don't over engineer, ship early and often.
Being in the same position (trying to teach myself some web development in my spare time) I recently decided to focus on the absolute basics and work my way up from there. This was after I quit a beginner's course which started with bootstrap, jquery, meteor.js and mongoDB. This may be fine for others, but to me it felt frustrating because all the interesting stuff beneath was kept hidden from me. I just used some tools in a predefined way without really understanding what was happening.
You are probably way past this level, but I really enjoyed the interneting is hard tutorial (https://internetingishard.com/html-and-css/) and playing around with flexbox and media queries. At the moment I am looking into Free Code Camps JavaScript chapters. Seems like a very long road, but understanding the basics concepts first, learning a little more every day and just playing around with what I already know is what keeps me motivated. But of course YMMV and this may not be the best way if you are aiming for a quick change in career etc.
If this question has haunted you for literally years, the right question is "how do I get through my analysis paralysis", not "what is the right stack/language/etc."
Your problem is you have no momentum. You need to build momentum and get over your fear of shipping.
My advice: pick three "side projects": one that you can build in a day, one that you can build in a week, and one that you can build in a month.
Build the first one in a day and ship it. This will motivate you and build your confidence in your shipping abilities. Then build the second one in a week and ship it. Then build the third one in a month and ship it. You've now shipped three projects, good going!
That said, I want to echo what @vinceguidry said. Side project != business. If you want to build a business, the same logic applies... just get something out the door. But you need to be serious about ongoing support and maintenance. Whereas a side project could be anything, like a fun open source project, a personal website, experimenting with new frameworks, etc.
p.s. Don't be so hard on yourself. You just shipped a blog post to the top of HN. And you've got a long history of blog posts on there. Maybe you should ask yourself why you can ship blog posts but not side projects?
Suffering with dysthymia taught me many things. One of the things is that I may be fine working under pressure but my brain is not.
Side projects tend to be small , fast and enjoyable. This is the way the human brain works and is actually much more efficient than taking big steps.
Also make sure that your main goal is fun, if it is not, it will only get worse. Fun is the fuel of the brain. You cannot fight fun, because you cannot fight the brain. The brain always win.
Make your brain your ally and success will come. You are not your brain , your brain is a lot more than you.
Let me say once more , brain.
Brain
Oh and if you think your code will never sell , remember that fortunes have been built selling rubber bands for hair. There is always a way.
It depends on your goal. Is your side project aiming to become a side business or an experimentation to learn new things? If it's a business, it's important to get things done. If it's for fun and to experiment, sometimes the end goal is not to actually complete it. The endeavour itself will be reward enough, perhaps.
It's true that a lot of programmers do jump from shiny new tech to the next shiny new tech. If it's to start a business, it's probably best to stick with boring stacks.
I share the pain. I'm incredibly productive at my day job architecting and tying together a plethora of microservices to deliver a platform of unified products. Outside of work i am absolutely freaking worthless. My problem is largely perfectionism. I've started working on seemingly great ideas and then took a turn to build a tool that would make task A less hack-ish. A few weeks later I'd open-source the tool/library and jump back on to the project only to find yet another thing to bothers me. My thinking here is that while I'm working on something in my spare time I should enjoy doing things the right way instead of cutting corners to meet deadlines. If i don't do this I cannot help but feel unbelievably dissatisfied and usually quit within a few days. Still don't know how to get over the hump. I'm almost thinking i have some kind of psychological disorder. On a side note, this same behavior helps me a lot in other areas, like working on a project car where attention to detail and just taking time makes the end result much better.
There's a Garrison Keillor quote I love that I think relates to programming as well, "A written work is never finished, it's simply taken away from you at some point."
I think the author's intent is a good one and it overcomes the "perfect is the enemy of the good" trap we can all fall into at times. As the technical lead on a multi-team project last year, I had to beg my developers to just check in anything at one meeting because they were terrified of having the other teams see their imperfect code. When I assured them their code couldn't be any worse than mine, which I had checked it several times and actually had rejected by the version manager, that they were able to laugh and agree to start committing their work to the repository.
Your code is going to get criticized no matter how much you polish and engineer it. If you can accept that, then I think you will find yourself free to be more productive.
I built a search engine for lectures (https://www.findlectures.com), partly so I have something I can show people (e.g. my family otherwise has no idea what I do).
Trying to build something in your free time forces you to think about dividing work up into very small pieces (what can I do with a free hour, etc). I've found this very beneficial in a work environment.
If you get to the point where you can show people, showing people changes how you think about the project - some invisible social pressure to do better, similar to code reviews.
You also have to think through the structure of the entire project on your own - often in a work environment, you're joining something in progress.
This is also a great way to research new tools. Instead of thinking how cool they are, you evaluate how they fit into a "real" project, but without the pressure to actually make it work.
I struggled through the same thing once I started with TDD. I've never had problems completing and shipping new products (a solo founder i launched 20 saas sites last year) but after reading dozens of documents about why TDD is an absolute must for any serious programmer my hubris got the best of me and I decided that I too will join the bandwagon. Boy, was i wrong.. Maybe for big teams it is a must but for solopreneurs and 2 people teams I wasted nearly 8 months before i realized that not only my productivity had rock bottomed but I started hating something that I once passionately loved. Since that day I went back to php and angular js.
I do get occasional this feature not working mails but at least I'm creating new sites again and making more money. If there is anything you want to take from this rant is don't waste your time doing things that other people are telling you to (how ironic). Do what you love and you will get shit done.
For a small team you should probably only TDD the most critical stuff, and not everything. Stuff that has huge paybacks, critical code. Generally I have been reverting to coding first, unless in scenarios where I waste more time trying to manually test it.
I am feeling the same. I also bought illusion of superiority for doing it "right". Turns out for small team, SaaS application it is a lot better to "move fast and break things" of course there is "fix bugs even faster" that is missing. But anyway if you prioritise bugs before moving fast all goes well, if not then all TDD in the world with Uncle Bob and Martin Fowler will not help you.
It's okay not to ship personal projects. No one's really holding you accountable for that. Look at it this way, unfinished personal projects still give you value because you might still be using it in its incomplete state, and you learned something when making it. As you become a more experienced engineer, it's common to have more unfinished personal projects because you have difficulty approaching it with a hacker mindset where you throw all best practices out the window and get it working as quickly as possible. Accept it and try not to lose sleep over it.
The problem is when this behaviour crosses over into your professional life, because you're not delivering value to your customers quickly enough and as a result you'll either get sacked or the company can go bust. Having someone else to keep you in line works great, it doesn't even need to be a Product Manager or Product Owner. And if you don't have someone else to keep you disciplined, then you better work hard on improving this area where you're lacking. Write down ideas on paper for example and ruthlessly prioritise and prune them every morning. Sayings like "work on what's highest priority", "do the least amount of effort that results in the greatest value", "keep it simple", "reduce scope", "you aren't gonna need it", "defer nice to haves", and so on are things we hear so often because it really is good advice that you should follow.
You get depressed if you have an idea in your head all the time, but you can't finish it. Or you boggle down your head with details and never end up having something you can show to your second half. That's the problem with shipping personal pet project. You are your own manager unhappy with yourself as an employee.
I have this same problem. My finish rate is abysmal, but I've actually finished a few.
I've realized that finishing a project is roughly 10% exploration another 20% getting to working and at least 70% polish. The exploration phase is very enjoyable and it's what keeps me hopping from project to project. Occasionally, the enjoyment will phase will encourage me to keep plugging away at it until I get to working. This is the minority of my projects, but it happens naturally to some extent. But I rarely put in the time and work to do that other, much larger bit to get to a done state. Because that part is actually work and it's not fun.
But what I've discovered in looking at my projects that actually got to done is that there's one thing that, for me, leads me to finish...having a social pressure. The projects that I've discussed with friends and gotten them excited about are the ones that I finish. My attention will wane and I'll drop it for a bit, but then I'll have a conversation where someone asks what what the status is and I'll pick it up and work more. And if that repeats enough, I finish. The best case scenario is getting someone excited enough to actually code with me on a project. In those cases, we usually get to done pretty quickly.
I think this is why being a solo founder is so difficult. You're going to run into difficult stretches and you'll want to focus on something else. It's a very rare person that can continually return their focus to a single problem, even in the face of adversity. But if you've got someone else to steer your focus back, you can keep working long enough to succeed.
So here's my advice to a coder who's never finished. For your next side project, when you get the inspiration, instead of immediately sitting down at a keyboard, contact a friend, go out for drinks and tell them about your project. Better yet, get a group of friends and discuss it. Get them excited about it and let them know that you're excited about it. Only after that step should you start coding.
Two things have made a huge different in my ability to finish/ship:
1. External Deadlines. I'm a career teacher, mostly self-taught Python/Django developer, and am applying for dev jobs. The school year's over in June, and I want to be able to step into a new jr position in July/August. I'm planning to resign my position this spring, and cannot be out of work. My benefits and salary will stop in September. I'm f'ed if I'm not working by then. The need to ship projects (if only into my portfolio) is high.
2. "Deep Work" for time management. Ideas from Cal Newport's book "Deep Work" have been foundational in my getting more done. It's hard to find the energy to build my side projects/portfolio after wrangling eight year olds all day, so I started getting up at 5 am solely to work on my projects. I make coffee and toast then get to my desk. I close all applications except Atom, Dash, and Firefox; turn on Do Not Disturb; look at my to-do list in my notebook; then get to work. Having 75 un-interrupted minutes before my wife gets up allows me to get a huge amount done, and it's become gratifying to watch the 6 am commits pile up on my github punch card. I've also found that exerting discipline in this facet of my life has had a positive knock-on effect in other areas.
I came here to mention 'Deep work' (which I found a very effective way to do and talked about on HN previously [1]) AND another tactic which is giving me good results.
The trick I found to complete things is:
Do not switch ladders of abstractions. When working on a modern web application (with backend, frontend, css, testing etc) if you start with writing backend API calls, then just write all of them first. Starting with the API call for /user', /signup, /login, /compose, /rate, /play. Don't worry about it working. If you do TDD then fine, but if you don't tests before you write the code, then avoid writing tests until you're done writing the basic code for your API. Then you write tests for it and make sure that each endpoint at least works.
Then write E2E testing for it(for the backend). E2E tests are a great way to build your app with it's core functionality full working and validated. In other words, write unit tests which first call /signup, then /login, then /compose then /play (which is I presume one full flow of a user). This will help you figure out issues with your API and it kinda feels like writing a full app.
Once you're done with testing, then write the frontend, just simple HTML, don't worry about CSS. Don't try to grab React + ES6 + Redux boilerplate or things like that. Just go with the simplest thing. Even if after every action user has to refresh to page, so be it. Oh you heard about CycleJS and think that you should be using that instead? Well guess what, you purposefully chose a really terrible technology to build this app, so once you're done making your app in that crappy tech, then you can rewrite it in CycleJs or anything else you want.
This way, even if you abandon your CycleJS rewrite effort halfway, you'd still have a completed project(and trust me, you will never let your app be stuck at static HTML with no CSS). Chances are that you'd abandon it, when you've already written your app in CycleJS but made a new rewrite effort to write it in Vue.JS.
Basically idea is, you think in terms of one layer at a time, and you defer all desires to refactor things until you are done finishing that layer.
You could think of building a scalable back end you don't actually need as a form of premature optimization, and I think the way around that is to evaluate & measure what you actually need - problems you have now, not problems you might have later (no matter how sure you are). @gerlv's suggestion to "Ship daily" is great because it not only forces you to ship often, so you feel like you're getting something done, it also forces to you evaluate what you need, and forces you to quickly get feedback from users that should be the true driver of what you need. (Assuming you want users, rather than a finished side project just for you.)
Michael Abrash has some books on optimizing code in assembly language, and he takes special care to talk about why & when to optimize that would also apply here. The point he makes repeatedly is to optimize from the user's point of view - don't do something the user won't notice.
We all do it though, this is a human trait, but we programmers and computer scientists often amplify the problem. We love obsessing over what's "best", without regard to whether we actually need the best. We are taught during our Computer Science degrees to generalize and abstract at every opportunity, to plan for future problems we might have, and for future problems others have had that we might never have. We discuss incessantly how important it is for software to be scalable, and how to use the "best" everything, best language, best database, best algorithm, etc.
Strive to solve only the problems you're already personally experiencing, wait to solve problems until you are already experiencing pain, and ignore the problems that only "might" happen, then it will be easier to finish things.
> You could think of building a scalable back end you don't actually need as a form of premature optimization
I've heard this described as "solving the problem you wish you had". A globally-distributed, scalable cloud infrastructure of microservices is good for the likes of Google, Facebook, Amazon, Baidu, etc. because it solves problems they face: handling millions of hits in a timely manner; avoiding downtime, every second of which is user-visible, loses them money and damages users' confidence in their service; etc.
It's very unlikely that a side-project will ever face these problems; an off-the-shelf Web server on an off-the-shelf host (say, Apache running on EC2) is probably fine.
A side-project which isn't shipped will never face these problems, because it doesn't have any users, any uptime, any revenue, etc.
> NO MORE TRYING TO REWRITE THINGS IN HASKELL. JUST. GET. SHIT. DONE.
I chuckled at that, because while it makes for a good joke, I've learned from experience that writing stuff in less mainstream languages like Haskell is probably the best way to avoid getting distracted by trendy new frameworks all the time, since they tend to have smaller, more niche focused communities that don't produce new frameworks every week that would even be relevant to you.
The same thing happens in many other creative endeavors, such as photography. If you don't have a client that needs pictures soon, you can spend months and years reading on the best lenses and techniques and buying new gear.
Acquiring all that knowledge leads to a feeling that you _potentially_ can do more. You are _potentially_ more powerful. It is a good feeling. You can never be disappointed in yourself if you don't finish anything.
> If you're using AdBlocker, fair play, I don't blame you. But please consider chucking me a couple of quid: https://monzo.me/ewanvalentine
Am I missing something? It's a nice set of thoughts, but I can't imagine paying to have read somebody's personal blog, and would have been vaguely weirded-out at him having ads on it.
[+] [-] vinceguidry|9 years ago|reply
The technology aspect is really only 10% of it. Sure, it's the essential 0-to-1 kicker that gets you going, but once that's done you still have to find product-market fit. That quickly assumes second-job status and can wreck your personal life. I've seen it happen.
A side project means you're taking all that on yourself without any help or real guidance. Not having that help means that when you finally do ship your side project, it's probably not going to achieve the kind of rapid growth you need to make scaling up possible.
And you really need rapid growth in order for working on a startup of your own creation to beat out having a reasonably-decent job. And if you don't have a reasonably-decent job, it's way easier to switch jobs / industries than it is to build out your own company.
What I want out of a side project is the kind of deliberate practice that is often lacking in my real job. Also to chase down random mind hares that seize my interest.
[+] [-] cocktailpeanuts|9 years ago|reply
There are tons of other people who also think side project is a way to learn something new, yet they ship.
Also there are tons of startups that started out as side projects. Facebook did.
You have no excuse. Stop lying to yourself because it's not doing yourself any good. The only reason you're not releasing your side projects to the world is because you are afraid of criticism.
[+] [-] mattschmulen|9 years ago|reply
[+] [-] onli|9 years ago|reply
I disagree. You only need to get the income you want with the work you are willing to invest. Depending on what you do and what you need, that can mean that scaling up is not required at all.
Bootstrapping a business out of a side project is a thing.
[+] [-] XorNot|9 years ago|reply
[+] [-] shrimp_emoji|9 years ago|reply
Your what?
[+] [-] DizzyDoo|9 years ago|reply
The key difference is that my project was a video game (this one: https://www.youtube.com/watch?v=YwXl8lDrxn8) and that takes a lot of temptation to do what the OP is writing about, rewriting stuff in Haskell for example. The interesting bit when it comes to side projects (and now my full time projects) for me isn't actually the tools or the methodology or anything like that, but the end result. I spent my teenage years building games that I never finished, and it made me quite miserable, because I so just wanted to finish something. Anything.
I remember the first game I ever finished was a clone of Snake. There was nothing remotely interesting in the implementation or in the design, but I was so flipping pleased with myself, I had finished something! And that let me slowly build my projects up to more interesting endeavours, and eventually to one that could be sold. Starting small was the key for me, as I learned two things: 1 - what was 'too much' for me to try and tackle at the time and 2 - self-discipline, not chucking the project the moment I got bored, or had a 'better idea'.
[+] [-] gerlv|9 years ago|reply
This is the advice I can give to anyone who has a side project. Get to the point where you can show something to the users and just start adding stuff.
Even if it's just two lines of code or changing the favicon - still worth it. In practice, it's harder to do than it sounds, but I've been doing it for some time and it's been going great.
In reality, you won't have millions of users on day 1 no matter how great your product is. If you start small and keep adding stuff you will have more success.
In fact, the biggest challenge for side projects is marketing and not the tech or infrastructure.
However, it also depends on the goal - if you want to build the project that makes money it's completely different story to experimenting with tech. In the end, you get the experience.
For example, a few years ago I managed to build an overengineered CDN product that compressed images on the fly (almost on the fly). I shipped the project and it even worked great for testers, but I didn't get to the point where it makes money, so I shut it down as with half unfinished features as it was taking too much time.
While building it I managed to learn Go, improve my AWS skills, plus some other tricks. Now it sounds like a great investment even though I feel that I haven't completed the project.
[+] [-] startupdiscuss|9 years ago|reply
I discovered this late, but am glad I did. Are you ready for it?
The secret is this:
don't start something till you finish the last thing, no matter how poorly.
This goes even at a "micro" level, so don't start distributing the load on servers till you finish the last thing (interface), no matter how poorly you finish the last thing.
Now you have the secret. Go forth and complete.
[+] [-] nemacol|9 years ago|reply
Not EXACTLY the same problem as the author, because I am not building out scalable infrastructure. I just spent a ton of time learning the fundamentals of angular and node, then try to understand express, then grunt, and mocha and bower and... now I have weeks into this pile of stuff... nothing working and I am frustrated, disappointed, and oh look Overwatch patch notes.. time to try out the new hero.
[+] [-] l_t|9 years ago|reply
On the other hand, if you're committed to Javascript, I think you should start at the most basic level. Angular is good, but it's a complicated system that takes time for even experienced Javascript coders to get used to. Same with Express, Mocha, Grunt, etc. These tools incorporate complexity to hide it from the programmer. But as a novice programmer, you DO NOT want that complexity hidden right off the bat.
Assuming you've gotten past the very basics (syntax of programming language, executing Javascript in the browser, reasoning about simple scripts), I would recommend the following as an exercise for learning:
Pick a fairly simple website and try to re-implement it, without looking at the original code. Don't start with angular, bower, or anything else. Just Javascript, HTML, and CSS. This is the fundamental language all browsers speak, and you have to be able to understand it for everything else to make sense.
As you work on the project, you might start to find things annoying. Like, dynamically changing page content with Javascript requires a lot of code. How could you make it easier? Think about, and possibly even implement, a solution that makes sense to you. Then, once you don't need it, you can reach for a pre-baked solution (like Angular, Vue, or React in this case).
[+] [-] equalarrow|9 years ago|reply
I have some friends that have an idea and I'm going to help them build it. So what do I use? The fast, low memory footprint of Swift?
No. I use Rails. I use bootstrap. I don't make a JS only frontend with api backend (Turbolinks works fine). I use what makes me productive and what's gets the first rev out the quickest.
For hosting, I put it on my Mac Mini (in my living room) via VirtualBox, with the same Nginx proxy I use for all my projects. I have no problems with scaling because I don't need to. Cross that bridge IF I get there.
I went through a number of years trying the latest and greatest frameworks, aws configs, etc. None it mattered to my projects. It did help with day jobs, but that was it.
Some other poster here was right when he said tech is about 10% of your business. There is so much other stuff outside of building your app/site and having analysis paralysis is gonna stop you dead in your tracks.
My advice (as many on HN have said before): go with what you know, don't over engineer, ship early and often.
[+] [-] flxsrbr|9 years ago|reply
You are probably way past this level, but I really enjoyed the interneting is hard tutorial (https://internetingishard.com/html-and-css/) and playing around with flexbox and media queries. At the moment I am looking into Free Code Camps JavaScript chapters. Seems like a very long road, but understanding the basics concepts first, learning a little more every day and just playing around with what I already know is what keeps me motivated. But of course YMMV and this may not be the best way if you are aiming for a quick change in career etc.
[+] [-] sbov|9 years ago|reply
If this question has haunted you for literally years, the right question is "how do I get through my analysis paralysis", not "what is the right stack/language/etc."
[+] [-] chatmasta|9 years ago|reply
My advice: pick three "side projects": one that you can build in a day, one that you can build in a week, and one that you can build in a month.
Build the first one in a day and ship it. This will motivate you and build your confidence in your shipping abilities. Then build the second one in a week and ship it. Then build the third one in a month and ship it. You've now shipped three projects, good going!
That said, I want to echo what @vinceguidry said. Side project != business. If you want to build a business, the same logic applies... just get something out the door. But you need to be serious about ongoing support and maintenance. Whereas a side project could be anything, like a fun open source project, a personal website, experimenting with new frameworks, etc.
p.s. Don't be so hard on yourself. You just shipped a blog post to the top of HN. And you've got a long history of blog posts on there. Maybe you should ask yourself why you can ship blog posts but not side projects?
[+] [-] kilon|9 years ago|reply
Side projects tend to be small , fast and enjoyable. This is the way the human brain works and is actually much more efficient than taking big steps.
Also make sure that your main goal is fun, if it is not, it will only get worse. Fun is the fuel of the brain. You cannot fight fun, because you cannot fight the brain. The brain always win.
Make your brain your ally and success will come. You are not your brain , your brain is a lot more than you.
Let me say once more , brain.
Brain
Oh and if you think your code will never sell , remember that fortunes have been built selling rubber bands for hair. There is always a way.
" use the brain Luke "
[+] [-] drchiu|9 years ago|reply
It's true that a lot of programmers do jump from shiny new tech to the next shiny new tech. If it's to start a business, it's probably best to stick with boring stacks.
[+] [-] avenoir|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] ideonexus|9 years ago|reply
I think the author's intent is a good one and it overcomes the "perfect is the enemy of the good" trap we can all fall into at times. As the technical lead on a multi-team project last year, I had to beg my developers to just check in anything at one meeting because they were terrified of having the other teams see their imperfect code. When I assured them their code couldn't be any worse than mine, which I had checked it several times and actually had rejected by the version manager, that they were able to laugh and agree to start committing their work to the repository.
Your code is going to get criticized no matter how much you polish and engineer it. If you can accept that, then I think you will find yourself free to be more productive.
[+] [-] garysieling|9 years ago|reply
Trying to build something in your free time forces you to think about dividing work up into very small pieces (what can I do with a free hour, etc). I've found this very beneficial in a work environment.
If you get to the point where you can show people, showing people changes how you think about the project - some invisible social pressure to do better, similar to code reviews.
You also have to think through the structure of the entire project on your own - often in a work environment, you're joining something in progress.
This is also a great way to research new tools. Instead of thinking how cool they are, you evaluate how they fit into a "real" project, but without the pressure to actually make it work.
[+] [-] rglover|9 years ago|reply
Do the Work - https://www.amazon.com/Do-Work-Overcome-Resistance-Your/dp/1...
The War of Art - https://www.amazon.com/War-Art-Through-Creative-Battles/dp/1...
You have to build a muscle for this stuff. It's hard.
[+] [-] superasn|9 years ago|reply
I do get occasional this feature not working mails but at least I'm creating new sites again and making more money. If there is anything you want to take from this rant is don't waste your time doing things that other people are telling you to (how ironic). Do what you love and you will get shit done.
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] ernsheong|9 years ago|reply
[+] [-] ozim|9 years ago|reply
[+] [-] lubonay|9 years ago|reply
[+] [-] reledi|9 years ago|reply
The problem is when this behaviour crosses over into your professional life, because you're not delivering value to your customers quickly enough and as a result you'll either get sacked or the company can go bust. Having someone else to keep you in line works great, it doesn't even need to be a Product Manager or Product Owner. And if you don't have someone else to keep you disciplined, then you better work hard on improving this area where you're lacking. Write down ideas on paper for example and ruthlessly prioritise and prune them every morning. Sayings like "work on what's highest priority", "do the least amount of effort that results in the greatest value", "keep it simple", "reduce scope", "you aren't gonna need it", "defer nice to haves", and so on are things we hear so often because it really is good advice that you should follow.
[+] [-] wkoszek|9 years ago|reply
[+] [-] curun1r|9 years ago|reply
I've realized that finishing a project is roughly 10% exploration another 20% getting to working and at least 70% polish. The exploration phase is very enjoyable and it's what keeps me hopping from project to project. Occasionally, the enjoyment will phase will encourage me to keep plugging away at it until I get to working. This is the minority of my projects, but it happens naturally to some extent. But I rarely put in the time and work to do that other, much larger bit to get to a done state. Because that part is actually work and it's not fun.
But what I've discovered in looking at my projects that actually got to done is that there's one thing that, for me, leads me to finish...having a social pressure. The projects that I've discussed with friends and gotten them excited about are the ones that I finish. My attention will wane and I'll drop it for a bit, but then I'll have a conversation where someone asks what what the status is and I'll pick it up and work more. And if that repeats enough, I finish. The best case scenario is getting someone excited enough to actually code with me on a project. In those cases, we usually get to done pretty quickly.
I think this is why being a solo founder is so difficult. You're going to run into difficult stretches and you'll want to focus on something else. It's a very rare person that can continually return their focus to a single problem, even in the face of adversity. But if you've got someone else to steer your focus back, you can keep working long enough to succeed.
So here's my advice to a coder who's never finished. For your next side project, when you get the inspiration, instead of immediately sitting down at a keyboard, contact a friend, go out for drinks and tell them about your project. Better yet, get a group of friends and discuss it. Get them excited about it and let them know that you're excited about it. Only after that step should you start coding.
[+] [-] snarf21|9 years ago|reply
[+] [-] lukewrites|9 years ago|reply
1. External Deadlines. I'm a career teacher, mostly self-taught Python/Django developer, and am applying for dev jobs. The school year's over in June, and I want to be able to step into a new jr position in July/August. I'm planning to resign my position this spring, and cannot be out of work. My benefits and salary will stop in September. I'm f'ed if I'm not working by then. The need to ship projects (if only into my portfolio) is high.
2. "Deep Work" for time management. Ideas from Cal Newport's book "Deep Work" have been foundational in my getting more done. It's hard to find the energy to build my side projects/portfolio after wrangling eight year olds all day, so I started getting up at 5 am solely to work on my projects. I make coffee and toast then get to my desk. I close all applications except Atom, Dash, and Firefox; turn on Do Not Disturb; look at my to-do list in my notebook; then get to work. Having 75 un-interrupted minutes before my wife gets up allows me to get a huge amount done, and it's become gratifying to watch the 6 am commits pile up on my github punch card. I've also found that exerting discipline in this facet of my life has had a positive knock-on effect in other areas.
[+] [-] splintercell|9 years ago|reply
The trick I found to complete things is:
Do not switch ladders of abstractions. When working on a modern web application (with backend, frontend, css, testing etc) if you start with writing backend API calls, then just write all of them first. Starting with the API call for /user', /signup, /login, /compose, /rate, /play. Don't worry about it working. If you do TDD then fine, but if you don't tests before you write the code, then avoid writing tests until you're done writing the basic code for your API. Then you write tests for it and make sure that each endpoint at least works.
Then write E2E testing for it(for the backend). E2E tests are a great way to build your app with it's core functionality full working and validated. In other words, write unit tests which first call /signup, then /login, then /compose then /play (which is I presume one full flow of a user). This will help you figure out issues with your API and it kinda feels like writing a full app.
Once you're done with testing, then write the frontend, just simple HTML, don't worry about CSS. Don't try to grab React + ES6 + Redux boilerplate or things like that. Just go with the simplest thing. Even if after every action user has to refresh to page, so be it. Oh you heard about CycleJS and think that you should be using that instead? Well guess what, you purposefully chose a really terrible technology to build this app, so once you're done making your app in that crappy tech, then you can rewrite it in CycleJs or anything else you want.
This way, even if you abandon your CycleJS rewrite effort halfway, you'd still have a completed project(and trust me, you will never let your app be stuck at static HTML with no CSS). Chances are that you'd abandon it, when you've already written your app in CycleJS but made a new rewrite effort to write it in Vue.JS.
Basically idea is, you think in terms of one layer at a time, and you defer all desires to refactor things until you are done finishing that layer.
1. https://news.ycombinator.com/item?id=13813173
[+] [-] rickdg|9 years ago|reply
[+] [-] dahart|9 years ago|reply
Michael Abrash has some books on optimizing code in assembly language, and he takes special care to talk about why & when to optimize that would also apply here. The point he makes repeatedly is to optimize from the user's point of view - don't do something the user won't notice.
http://www.phatcode.net/res/224/files/html/ch01/01-01.html#H...
We all do it though, this is a human trait, but we programmers and computer scientists often amplify the problem. We love obsessing over what's "best", without regard to whether we actually need the best. We are taught during our Computer Science degrees to generalize and abstract at every opportunity, to plan for future problems we might have, and for future problems others have had that we might never have. We discuss incessantly how important it is for software to be scalable, and how to use the "best" everything, best language, best database, best algorithm, etc.
Strive to solve only the problems you're already personally experiencing, wait to solve problems until you are already experiencing pain, and ignore the problems that only "might" happen, then it will be easier to finish things.
[+] [-] chriswarbo|9 years ago|reply
I've heard this described as "solving the problem you wish you had". A globally-distributed, scalable cloud infrastructure of microservices is good for the likes of Google, Facebook, Amazon, Baidu, etc. because it solves problems they face: handling millions of hits in a timely manner; avoiding downtime, every second of which is user-visible, loses them money and damages users' confidence in their service; etc.
It's very unlikely that a side-project will ever face these problems; an off-the-shelf Web server on an off-the-shelf host (say, Apache running on EC2) is probably fine.
A side-project which isn't shipped will never face these problems, because it doesn't have any users, any uptime, any revenue, etc.
[+] [-] axlprose|9 years ago|reply
I chuckled at that, because while it makes for a good joke, I've learned from experience that writing stuff in less mainstream languages like Haskell is probably the best way to avoid getting distracted by trendy new frameworks all the time, since they tend to have smaller, more niche focused communities that don't produce new frameworks every week that would even be relevant to you.
[+] [-] spython|9 years ago|reply
Acquiring all that knowledge leads to a feeling that you _potentially_ can do more. You are _potentially_ more powerful. It is a good feeling. You can never be disappointed in yourself if you don't finish anything.
[+] [-] robbfitzsimmons|9 years ago|reply
Am I missing something? It's a nice set of thoughts, but I can't imagine paying to have read somebody's personal blog, and would have been vaguely weirded-out at him having ads on it.