I disagree. Experimentation is an important part of learning and yes, initially there's a lot of "wooo, shiny!" going on. It doesn't matter - you are STILL learning.
It also helps to remember that software projects are never finished - only abandoned.
I think the author of the post was trying to say that he has disproportionally allocated his time from finishing projects to just learning new things. There needs to be a good balance between keeping up to date with technology and producing something from the technology.
I feel you’ve been on the right track all along. Instead of doing the opposite on the programming side you might need to do the opposite on the product and selling side. Instead of building something you have no passion for look for ways to sell what you have already created. In other words see if you can productize your "auto-scaling, multi-zone, cloud infrastructure". There’s definitely other people who would like to use that.
Or teach people how to use the new shiny thing.
Or help them decide the pros and cons of new technologies by talking about the subtle distinctions you have noticed between them through your experimentation.
> In other words see if you can productize your "auto-scaling, multi-zone, cloud infrastructure". There’s definitely other people who would like to use that.
While working to build out the "auto-scaling, multi-zone, cloud infrastructure" product, OP (or anyone for that matter) will get caught up building his own front end JS framework that will address some shortcomings of AngularJS or reactjs.
If I understand correctly, the point of the article is that it's incredibly easy to lose focus of what you set out to do and get distracted by something that is not very important to your project/startup.
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.
The number one thing to remember is almost no one cares what tech you used. Just get it shipped.
People have built million dollar business that had it's first iteration in MS Excel, if it is useful to someone and kind of serves the purpose then that is enough for a start.
Totally agreed. It is all about your solution for removing the customer's pain. The sooner you can do that, the better it will be for you and your customer.
I'm on the verge of completing one of my side projects. The most useful thing that I've found that helps me stay focused is to already have users who you know will want it. By staying focused on you users and what they want, you can stop a lot of this shiny chasing before it starts.
That's where "eat your own dogfood" comes in. It does not replace having real users, their feedback is invaluable. But if you yourself really use the functionality of the project, the production version the others see as well, then you can become yourself the user that pushes you as a developer to get things done and online.
Well, you probably know that. But for me that was important, so I'll mention it anyway.
You are one of the 2/3rd kids who were part of the marshmallow experiment. You cant control your desire for immediate gratification. I feel that with the level that you are in, you need a bigger problem to solve, rather than start a new startup(whatever that is). I know your type, I was like you, most of my friends are like you.
Also did I mention that you are an introvert by nature (read susain cain). You are easily distracted by shiny things.
P.S. I am no expert, those are just the things that I realized about myself....
P.P.S Shit. I think I am still like you, because otherwise I would have worked on the code review that I was supposed to do....
Offtopic: I got quite a NSFW Ad when I clicked through to this. Well depending on the workplace. But yeah not something I'd love a colleague to see over my shoulder.
Zero or more feature nudity, ditto sports, one's a flowchart, but they have one thing in common: Nude or not, none of them have anything to do with your work. So what makes any of them NSFW? (The subject of this discussion is "getting things done".)
My side projects usually aren't meant to get completed. I specifically use them to try new things. If it works out, I might use the new stuff in my job. If not, I gained some knowledge.
Some of my stuff is good enough to use (as in early alpha), but doing the final 20% won't pay off anyway.
Infrastructure wise, I'm absolutely guilty of this as well. I have found that there's a middle ground...
You (probably) don't need the microservices and the complexity that comes with it, upfront. A monolith (and the simplicity in terms of deployment, logging, monitoring, etc. etc.) will probably do early on.
However, you don't want to shoot yourself in the foot for when it turns out you do need those things.
I try to write code in self-contained modules, with well defined boundaries, and glue it together in a monolith. If/when it needs to be split out into separate services, it becomes much easier.
So, application/business logic code: keep the standards high, do shit properly. Glue code to keep it all together? Less important. You can rip that out later and move to different infrastructure with the same code.
That's very generic advice, and I seem to always break my own rule on this at some point... but I find it's a better mentality for when shit just needs to get done.
Doesn't help with tech choice in general though (and I'm often guilty of this as well...).
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.
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 :)
Agreed; many side projects are just for fun, to create a tool that you want & you don't care if others want it (though you may or may not choose to share it having created it), to ship just to show your friends, or see how it does in the wild without caring about whether it generates cash; just hoping that a few people find it & appreciate what you've made.
Personally I'd hate to run my own business, since that means moving away from the code (even if you get another person to take care of the non-code stuff; you still have to go out and find the right person for that / get involved in things that you wouldn't otherwise choose to). That said I'd love to create something, put it out there, and have 5 people come back and say "thanks for this; you've fixed a problem that I was having"; to get 100 people say that would be even better; any more and I'd probably start to get upset as there would become expectations to start implementing things the user base was asking for, rather than just doing my own thing; which for a hobby project is all I'd want.
A lot of my side projects relate to my day job; I use my spare time to create tools which make my work life simpler. Sure the IPO belongs to my employer, but it means I remove frustrations from my working day without having to justify spending company time on the tools which allow that, and I can share these tools with colleagues so that my friends get the benefits too. That makes for a pleasant life.
> 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.
> Bootstrapping a business out of a side project is a thing.
Sure, but it's not reliable. And that lack of reliability makes it inferior to a good job. If you're really a glutton for punishment and don't mind letting the market be your teacher, then you can make it work eventually.
If you're wired that way, for sure do what you need to do so you can stay sane. That's a big ole' pile of nope for me.
If you can't find a good job in the tech industry, then you're either not really looking, aren't mobile enough, or have personal circumstances, like kids, preventing you from moving.
I've never had a bad job. Every job I've ever had after high school, I was glad to have and reluctant to leave. Except the military. I was glad to leave that. But I was also glad to have it.
Jobs can be worked on, you don't have to accept bad situations. I've negotiated raises, perks, all kinds of quality-of-life improvements that were unheard of 5 years ago are on the table today. It's a great time to be alive.
I agree with everything you're saying except for this one. It's (currently) easy to get a tech job (in certain areas). It's NOT easy to get a good job. Unless you're well known, or have some popular programming blog with lots of readers, or really self promote well, you have to pound pavement with the rest of us to fight for a good company.
There are plenty of dog jobs doing enterprise middleware API plumbing, and polishing a product for a zombie startup that doesn't know they're dead yet, and being 8th engineer from the left at BigBoringCorp. Maybe easy to get those jobs. The good ones, interesting problems, successful product/company, growth opportunities, steady pay/raises, outstanding benefits, etc. are not growing on trees.
A decent job is one that a) pays you reliably b) isn't a sweatshop, and c) doesn't have political problems that you can't handle. I've had these jobs throughout my career and I'd be very happy to continue having them up until the day I retire. Many of what you call "dog jobs" are jobs that I could be perfectly comfortable in.
The reason I can be comfortable in these jobs and many techies would feel So Unbelievably Professionally Stifled is because I have separated my personal life goals from my professional life goals and correctly (to me anyway) prioritized personal over professional.
If you're feeling professionally stifled, then you probably have personal issues to work through that would bear more fruit than moving the needle professionally. If you have a great job, but a shit marriage, you need to reprioritize. If you have a great personal life and you still feel professionally stifled, then by all means start moving that needle.
To me personal life is endlessly fulfilling, I can devote 24 hours a day to it if I was independently wealthy. Personal life is defined by achieving goals together with people you're very close to.
Just about any job in America that's not bleeding over into your personal life is a good job. That's my definition. I want to bleed my personal life into my professional life and not the other way around. This is where quality-of-life perks like work from home days, unlimited PTO, and such come in. Things like successful products, growth opportunities, meaningful raises, are nice-to-haves and not essentials.
These are the kinds of comments that keep me coming back to HN. While I don't share your view, it's articulated so well and definitely gives me something to reflect on. Thanks.
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.
Oh believe me, I did try. Moved in with a business cofounder and started working on an idea. We squabbled over a lot of things before I realized that it was a marriage and not a transaction, and what I wanted was more transactional. So I bailed and got a job.
I still talk with the guy and fill out estimates for his potential clients whenever he wants. We'll eventually hack out a working professional relationship and start a company together.
The fact of the matter is that personal life matters more to me than professional life. I think a lot of people wind up using professional accolades to make up for things they can't get in their personal life. Maybe that's not you, but for me, working on my relationships and my emotional health is 100x more important than a big pile of money and influence ever will.
Maybe your answer to this is to "just work harder." To that I just have to say, 'absolutely not'.
It doesn't sound like you were working on a side project there, and even then, you have one bad experience and throw your hands up?
You can have a rewarding personal life and still learn while building something on the side, and show it to the world. But, I think you have to be prepared to appreciate the process without expectation of payoff. Just my observation, your comments read like there is a preoccupation with the latter.
There's no point in shipping unless you're gunning for a payoff. Sure, if you want to find meaning in giving total random strangers things that they want you to give them, knock yourself out.
There is a lot of point in shipping, and as somebody else pointed out that something made in 2 hours can also be shipped.
What shipping has taught me is to really really restrict the scope, the un-essentials. That in turn has helped in my day job as well, to negotiate correctly on milestones, feature scope etc helping me in staying sane and productive!
>> strangers things that they want you to give them
I don't know if you mean OSS users by this but if yes, then where are these users pestering the authors to give them something, they just lap it up if it is useful when the author gives it to them.
> Maybe your answer to this is to "just work harder." To that I just have to say, 'absolutely not'.
I said "ship" it. not work harder. You can even ship something you built in a couple of hours.
It IS ok to not ship every single project you work on, but it is not ok to be proud of how you never ship.
Personally in terms of "learning" I learned 90% of what I have learned AFTER shipping. You think you are learning but you are only scratching the surface.
It still takes time. Time spent away from your loved ones, away from your friends, away from doing the things you really want to do with your time. It's great that you find meaning in learning from the market. But the only love the market can really give you is colored green.
As someone who started a side business with the thought of doing both that and my normal 9-5 until my side business took off, everything you've said in all your responses is completely accurate.
I found out that after landing six clients and taking on a ton of business, myself and my partner (who was also working a full-time job too) got in and suddenly my personal life vanished. Sure, the money was rolling in, but all of my relationships suffered, I didn't have time to do the things I really wanted to do.
Worse yet? I felt like all my clients would want the latest and greatest web technologies and applications to make their businesses run smoother and easier to manage. Nope. They just bickered with me and it was a series of struggles to get anything done. Twelve iterations of design and several "come to Jesus" meetings couldn't stop the non-stop changes for one client. Another client was stuck in a paper and pen world and didn't want to automate or change anything about the one process that hindered their business. Another wanted web design from 1995. It was maddening.
After a year, I fired three of my clients, finished two of the sites and cut those clients loose and then kept the only one that was a joy to work with.
My life returned to normal, but it made me realize exactly what you said. My LIFE is more important than a pile of money. Maintaining my relationships with my family and friends should be more important.
"I said "ship" it. not work harder. You can even ship something you built in a couple of hours.
"
I did that and gained nothing from it. I don't mean it as a complain, more like reality check - most of the time you don't magically learn by shipping whatever you done in few hours.
That's because "shipping" doesn't mean just posting it online randomly where nobody finds out.
It's like saying "I have a Twitter account and nobody cares what I say, I never get a single reply or a like. Btw I have 0 followers".
Shipping means getting it out there AND see what people think of it. If you at least tried to do that, you would have probably learned something. Even one person looking at your thing and giving you their thought is a learning experience.
Most people don't do that because they don't want their ego to be hurt. My point is don't worry about that and just talk about stuff you build with as many people as you can and hear what they say. It's ok even if they tell you it's shit, because you have now learned that you have built shit (You would not have known that if you never talked to anyone), and if you did built shit, you can learn what makes it such a shit, so next time you can do better. Otherwise you can just keep making shit.
People seen it, you assumed wrong. Some people give good quality feedback, some people give bad quality feedback and I really did not gained all that much. I was ok with not gaining much, I am not complaining. People do and don't do things for variety reasons, even one human has usually multiple contributing reasons for everything. If you assume single reason for most people, you are likely to be wrong.
Lastly, random strangers on the internet telling you that you did build shit does not mean you did built shit. Nor them telling you that you did something awesome means you did something awesome. They may be right or wrong, they may be trolls, they may want to feel you good, they may have had bad day.
The feedback may be useless simply because they have different goals that you had. Especially in situation where your goal was to ship whatever is possible withing x hours (topic of this thread) and the public it is a shit cause they would accept something equivalent to days of work. Which is alright as far as I am concerned, but hardly a learning experience.
A B C - Always Be Closing! In this case, always be shipping. I see a lot of resentment around here against the fact that you developers are always seen as lowly peons by managers. And here we have the perfect example why: this guy doesn't care about shipping, he only care about going into his little world and doing what he wants. This type of mentality leads to what we managers call 'coder mentality'. Programmers that see themselves as programmers instead of problem solvers. You need to get out of your head and realize that coding is just a tool to solve a problem. It's not something that you do just because. It makes no sense. Coding in of itself is useless.
Problem solving though, is very useful. Some problems require only coding, some problems require some coding and other things, and other problems require no coding at all in order to be solved. You should always seek to solve problems that you and others have. Don't just go into your world and start coding. That will not make you a better programmer.
We managers hate the 'coder' because he just wants to code and not solve business problems. That is why you are treated the way you are treated and will always command less respect than others. By the way, when things are down and we have to let people go, who do you think we let go first: the guy who shows interest in the business and how to make work better and cut costs, or the guy who just puts headphones on and starts coding surrounded by red bulls?
I'll leave you with the now famouse Glengarry Glen Ross Scene: https://www.youtube.com/watch?v=v9XW6P0tiVc
Always be shipping! You don't ship, you don't exist. When I hire I always ask about shipped products specifically. The things that didn't ship don't exist. I consider that wasted time. One shipped product means more than 1000 personal projects that didn't ship, no matter how much you think you learnt.
I'm in a similar situation to GP. I've done tons and tons of side projects but I rarely have anything to show for it.
And why should I? I'm doing it mostly for the fun of coding, and striving to "ship" things takes some of the fun away. I most certainly do not want to start a start up from any of my side projects. Perhaps an established open source project at most.
I do "release" my project, ie. push them to GitHub, but they don't really gather any attention or contributions from others. Sometimes I share some snippets in relevant discussions and receive positive feedback but I have no idea what it would take to actually gain any traction.
So I've basically given up on the idea of "finishing" or "shipping" or whatever. I have 3 hours of free time on Saturdays and I get to choose how to use it. I can either do fun stuff (coding, art, etc) or desperately try to "ship" and gain traction but that just isn't fun.
That said, if anyone is interested in open source space simulation (my current "main" side project, 5+ years in), get in touch on HN. There's no way I'll ever ship it alone, but it's nearly impossible to get anyone else to help me with it because I don't have anything cool and shiny to show.
I think you are doing great that you're releasing them into public, but your problem is you are not sharing it enough.
I have many friends who release things like you. I'm not saying you are doing this but these guys just release and make no effort to promote them. They are afraid that they will get hurt if they try hard and no one still wants their thing.
I understand this is totally valid fear and I have it too, but I also know that getting the word out vs not doing it makes a huge difference.
Next time you build a product try to post it online everywhere like Reddit and Show HN. I'm sure you'll gain more confidence and experience from it.
Thanks for the feedback. Yes, I probably do share too little, and I get too discouraged when reddit downvotes my stuff to oblivion.
> Next time you build a product try to post it online everywhere like Reddit and Show HN. I'm sure you'll gain more confidence and experience from it.
Here's the problem, I never "build a product". My free time is not nearly enough to build a proper product that would a) be fun for me to write b) interesting enough for the general public.
Basically the best I can do is show a few screenshots or a few hundred lines of interesting code. In my experience, that's not enough to gain traction on Show HN or Reddit. Sometimes I share screenshots on IRC and do get some interesting follow-up discussions but that doesn't really help me to get these projects any further.
Maybe I should gather up the courage and start posting to reddit /r/gamedev "screenshot saturdays" threads for getting feedback and encouragement. Although I'm not really doing a game here.
But yeah, I mostly try to not think about the idea that I'll never finish these projects and have fun while hacking on them. I've been doing this for 20 years now and never really "shipped" anything, so I might as well stop worrying about finishing and just have fun.
Wow, I was going to write my own story of putzing around with side projects here, but yours matches it perfectly. I've got a local repo with probably dozens of 50-100% completed hobby projects, but I don't really release anything. I used to release stuff but then it becomes a maintenance pain. Users don't get that this is a hobby for you, and don't understand why you don't respond and fix right this minute. This is especially true for free projects.
I currently work full time for a company whose policy forbids releasing anything I work on in my free time, so it's kind of nice--the decision is pretty much made for me.
I guess the advice is learn to _finish_ things but don't get too hung up on releasing them. Unless you're trying to build a business in which case you need to follow a totally different path (release MVP early, get feedback, iterate, market fit, etc.).
Yeah, I stopped working on "infrastructure" utility libraries and similar projects because the maintenance burden is too high. Some people just don't get it - I'm not in it to provide a free service to anyone.
Luckily I live in a country where the law doesn't allow an employer to forbid releasing projects done on free time, so I don't have your issue. I would seriously reconsider my employment if I were given such restrictions. As little as I finish stuff, the ability to share and receive feedback from strangers in the internet is still positive to me.
Out of curiosity, how did they pressured on you and which community was it in (linux/frontend/java/python/etc)? Many project I seen (and used) seem to be abandoned after a while or are maintained slowly, so you not being able to maintain long term seems pretty much standard to me.
> Basically the best I can do is show a few screenshots or a few hundred lines of interesting code.
I've got some similar projects: An NES emulator that I play with optimizations in, and a bunch of utilities related to the game Ultima Underworld, which are basically waiting to be plugged into an as-yet-unwritten game engine. There's some interesting code (both mine, and disassembled code from the original game binaries), but the shiny, attractive parts are spread thin.
Plus, if I had external pressure to work on these things, I feel like they'd lose some of their interest. Part of why I like them is that they're impractical projects that I can putter around in occasionally, when the muse strikes.
They are afraid that they will get hurt if they try hard and no one still wants their thing.
I'm in this kind of release, not because of fear, but because promoting project takes times (a full time job for some people) and I prefer to spend my time programming something else
Yeah, it takes a huge amount of time and effort to make your voice heard and your project promoted.
I have a feeling that naturally extroverted people do not understand that it takes a real push from other to show your work to strangers.
Same thing as the discussion about "demo days" earlier today. Those who are good in promoting are not necessarily those who are good in building projects. This applies to other aspects of life as well as it does to pitching startups.
These are all very neat and polished projects. And you have the advantage of doing web sites / apps which is a lot easier to release than a native app. The stuff I do simply isn't viable on the web (or even if it were, it wouldn't be fun) and I'm not particularly interested in working within a browser sandbox.
It's much, much harder to get a project to a state where someone can git clone, build and run it. Depends a lot on the target platform and the nature of the project, some languages and platforms are easier than others.
No need to be arrogant, though. Nice that you have the time and the ability to finish but don't expect everyone else to have the time and the capabilities to do so.
> I have many friends who release things like you. I'm not saying you are doing this but these guys just release and make no effort to promote them. They are afraid that they will get hurt if they try hard and no one still wants their thing.
The thing is, not everyone builds things to have something at the end. A lot of my side projects exist because I enjoy hacking on them, not because I have some particular end result I'm looking for.
Of course, I have other side projects where I want both, and for those, shipping probably has value.
I write a lot of personal userscripts that I upload publicly to Greasyfork just in case they benefit someone else or someone asks me to share with them. I rarely have plans to improve or maintain any of my work beyond my own benefit. I fix bugs only when they are an issue to my personal work flow. Most of them are quick hackjobs I write in 10 minutes to fix some personal pain point on websites I use.
The amount of users that (a) browse the same websites I do and (b) take issue with the same things I take issue with are next-to-zero.
I also don't care to hear how I could refactor huge parts of my code to be more extendable in the future - because I have no plans to extend it to begin with. I know the code is absolute garbage and I can easily improve it if I took 10 minutes to refactor it. But it works and that's all I needed, so that's all that gets done.
People have different motivations for releasing publicly. I know you were probably speaking more to side projects, especially potentially profitable ones, but I felt I'd throw in my $0.02 to accompany all the others.
I've got a side project with minus $30/month in revenue, with no plans to do much better. I have 3-5 users who complain when the site goes down and give me feedback on new features.
The motivation for the project is twofold. The simple joy of creating something -- no different than hanging a child's drawing on the fridge, and to keep my skills current and to play with technology I might otherwise not be using at work.
That being said -- I agree with you -- without shipping a working product, you've got nothing.
I dont want everything I do criticized. I dont want every small doodad I make to have to worry about licenses and IP. I dont want to have people yelling at me for not supporting a weekend project.
As a specific example, I wrote a personal set of Minecraft tools.
I read a lot of file format information off the wiki to get compatibility with their map (and other) files. Did I accidentally use protected IP because the wiki wasnt clean information? Maybe. Did I stray in to copyright violation by using their names for blocks, rather than renaming the numeric codes? Possibly.
Then there's the fact version 1 was a hacked together spaghetti ball with magic values all over the place I wrote in an evening. Would I have benefited from having that feedback told to me? Not at all -- that was actually solid engineering to get 'er done as a prototype.
A week later version 2 was out, but it was a complete rewrite that didn't have any compatibility. Maybe feedback would've been helpful here, but even I thought there were still some obvious flaws because I was trying a new style of programming in Python, and it hadn't gelled yet.
Version 3 was a week or two after that, with another breaking rewrite. This time it used a model of automata from a completely different source, changing the storage format, adding a scripting interface, etc. with only a thin definition file for and import/export layer to Minecraft.
And that's where it sits on a drive, 90% finished automata development tools with MC compatibility because I learned what I wanted to from the project and moved on to other things. (I say 90% finished because while it works fine, there are features I thought of but didn't add.)
I don't want to keep working on it, I don't want to share the implementation of the automata engine because it's slightly buggy, and I don't want to support the project if others choose to use it. (And they very well might -- MC development tools suck.)
What would've been gained, at any point, in "shipping" it (beyond using it myself to make a few maps, which I did)?
> 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 often set the bar so high there is no chance I could ever finish. The only projects that are attractive and shiny enough are those that are too big to finish.
E.g. I could choose between writing, completing and shipping a small indie game. Or I could write an OS from scratch, or the next Unreal Engine because I think it looks shiny.
Obviously I have no chance in hell of compleing a AAA game engine. Or an OS that does any more than say "Hello world" on boot. But I can pretend to be writing a AAA game engine - and I can keep pretending for many nights, until I have 1% of a game engine. At that point, there is probably something shinier that gets my attention.
So releasing it to the world: Obviously: I could put my 1% of a game engine on github for everyone to see, and that would be "releasing it to the world". But most likely no one would see it! I have hundreds of projects sitting around in various stages of completeness. Perhaps 2 or 3 were ever in some kind of usable state - and what they do have in common is that it was horrible to "finish" them in terms of making a proper repo, readmes, deployments, setups etc...
The reason finishing stuff and shipping them is so boring is because even a trivially small project that people actually want to use will have a ton of work required that aren't coding. I have no interest deploying a web app, no interest in drawing (or searching for) graphics for the little indie game etc. I'd rather make a new placeholder game than finishing the first one! I just want to code. I don't mind showing my code. I just normally don't want make a finished product of it. I get enough of that at work.
Edit: noticed someone said pretty much exactly this already and you responded. Oh well.
I find your OS example a little bit misplaced considering a quite complex OS can be completed by one person (obviously more complete than "hello world") but regardless of that, the commercial value of a new OS is quite low but the usefullness of learned (I'd say) is quite high.
> I often set the bar so high there is no chance I could ever finish. The only projects that are attractive and shiny enough are those that are too big to finish.
This reminds of a chapter in "Computer Power and Human Reason" where Joseph Weizenbaum describes the differences between compulsive programmers and professionals.
> His main interest is, in any case, not in small programs, but in very large, very ambitious systems of programs. Usually the systems he undertakes to build, and on which he works feverishly for perhaps a month or two or three, have very grandiose but extremely imprecisely stated goals. [...] It is characteristic of many such projects that the programmer can long continue in the conviction that they demand knowledge about nothing but computers, programming, etc. And that knowledge he, of course, commands in abundance. Indeed, the point at which such work is often abandoned is precisely when it ceases to be purely incestuous, i.e., when programming would have to be interrupted in order that knowledge from outside the computer world may be acquired.
My interest is usually more in some specific problem or algorithm. I'm curious how subsurface scattering works so I write a sloppy pathtracer just to act as a shell for what I really wanted to do - the complex algorithm. Once I get it half working I'm done, because the goal was neither to make a product or to finish even the subsurface scattering part perfectly, the goal was to code and to understand the algorithm.
I'm not really in it to create, and that's perhaps the key. I write programs because that's how I understand problems. If I could understand something by reading a book or Wikipedia page then I'd often just do that and not have to do the coding at all!
Doing this kind of superficial learning-through-coding is fantastically effective I must say.
"The only reason you're not releasing your side projects to the world is because you are afraid of criticism."
No, I have side projects to learn and play. Lots of things I try end up in production code at work because I learned how to do it. Of the projects that are in pretty good shape I don't want to ship it because then I'm committed to supporting it. Shipping turns a side project into a job and unless I have a killer app that will make me some serious money - I have a job and I don't need another.
Side projects die because your initial enthusiasm wears off and you start to realize that you are midway through a project that you initiated for your own self amusement and it's no longer making you happy. Don't beat yourself up about walking away. It doesn't mean that you are a quitter and you'll never accomplish anything. It means that you need to find something more important to do. Important tasks are self-justifying; you don't have to talk yourself into working on them. When you find yourself on something important, your motivation will come. You will see it all the way through.
In the case of Facebook, I think it must have felt important, because it saw instant success around campus. Once you see that something is generating success, even on a relatively small scale, that starts to validate its importance and you can rationally consider increasing your commitment.
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".
Most of the projects I work on in my free time I start because I want to learn about something (new language, new UI framework, whatever), and once I feel I have achieved that, my motivation drops dramatically.
Also, not having to deal with deadlines, strange and ever-shifting requirements, or angry users is part of the fun. Walking away from a half-finished program is not something I could get away with at work, so it is kind of a relief to be able to do that sometimes.
"No more big re-writes because there's some hot new JS library. No more microservices for the sakes of it, no more overly ambitious build pipe-lines. NO MORE TRYING TO REWRITE THINGS IN HASKELL. JUST. GET. SHIT. DONE."
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?
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.
100% agreed. I used to think that I "understood" this. But as you said it's much harder to do in practice. To anyone else who thinks "oh yeah I know all about that" without having actually done it, don't get so self-confident until you pull it off.
"Ship daily" only works with web applications. If I were to ship my applications daily (or rather: each day where there occur changes), I would just be compiling packages all the time. (Before you ask: This cannot be automated further. I will not give my GPG key to some automation to sign the packages with.)
When I was working on a game, we created a Patreon and promised new demo to backers every month. It's very motivating - you have clear deadline, money and feedback.
Web apps have the advantage that users don't have to actively update anything. One page load and they use the updated product.
Receiving daily updates for desktop apps would suck because it typically requires the app to quit and start again. A good compromise would be updates every four weeks. At the same time you as a developer always leave your app in a state were you could push an update anytime. So you still work incrementally in daily units of work.
Daily updates for libraries … if it's only publicly available code, I don't see a reason not to push daily. Anyone interested can check the commit logs. For compiled binaries on the other hand I can see update fatigue for users (other developers). Once a month or longer seems fine.
In the end, push regularly (daily, weekly, monthly, whatever fits you) without annoying your users by spamming them with updates, while at the same time reduce work units to a size that does not feel overwhelming.
You could have a "nightly" release, which is updated as often as you like, alongside the "real" versions. Those who want the nightly can have it, those who want steady, stable releases can avoid it.
Push to your own local repo daily. Push to the actual users less frequently. Weekly, monthly, 3 months, just pick something reasonable and -stick to it-.
I think the basic idea is get it running and keep it running making incremental improvements. Whether your project is in an interpreted language or takes a day to build only changes the pace. I've worked on both time scales and focusing on getting something basic running then adding to it has worked for me.
You can ship daily even if your process is not automated. I usually automate building and deployment later in an application's life -- not at the beginning.
You can automate all steps for building an application but the signing to make your life easier. You can also automate things locally if you're worried about what you're signing.
The bottom line is that this applies to all apps (though your users might be irritated if they need to keep downloading updates).
I automate my deploy process by passing my password as an argument to my automation script. maybe you can try figuring something similar out.
Because yeah, by hand, even deploying my webapp would take a couple hours. it took me maybe 8hrs of labor to setup my deploy script but given as I've deployed maybe 50 times so far it's paid off.
Hours? Could you elaborate a bit what exactly you mean with "by hand"? I'm probably not thinking manually enough, I can't come up with what could possibly that time intensive about any deployment.
"By Hand" I mean running each command required to deploy line-by-line, at the command line.
For me, that would be:
1) provision VM
2) configure the new VM (security hardening, install utils)
3) download app from git and configure it
4) take image of vm
5) install new image into my autoscaler
6) hot-replace live instances of previous version with new version.
doing each of those commands by hand and waiting for each to complete could easily take 1.5 or 2 hours of work. I did it by hand the first couple times but once I figured out my workflow I automated it (bash script) as fast as possible.
I spent a couple days looking into ansible, but as I have a very specific need I didn't want to spend 2+ weeks adding another chunk of "technical debt" to my product.
I already have a Makefile to automate most of the steps, but you still need to write changelogs, push a signed tag to Github, update the package specs and create and push all the repos.
Don't agree. I think that is like saying you can become a professional athlete by just working out everyday. We mostly know what works. It's comradely, career and cash. Most things worth doing isn't going to result in much professional progress or money in the beginning, so working with and showing things for your community is generally the most important. That's what driving every sports team, music group, enthusiast etc. in the beginning. You still of course need the time, knowledge and motivation to do something.
Shipping can be the result of, or one way, to do the right things. But if you look at projects on Github it's usually not a lack of "shipping daily" so much as a lack of packaging it as something useful. Often you see daily commits until the motivation wears off and the project stops. But the software is still buggy, there's no screenshots, it's not straight forward how to build it, lacks documentation etc. They haven't made it into something that is easy for other people to appreciate, so they don't get much positive feedback.
In terms of incomplete projects, "Ship daily" could apply to shipping something that sorta works to your non-tech business partners, pre-launch. If you don't have business partners then use your friends or, heck, even yer mom. Just show daily progress to someone (anyone) else. Doesn't have to be your users (which you may not even have yet).
This is great advice, but when it's not possible to ship daily, I find that even just committing once a day is a good micro-goal to keep projects moving. The GitHub streaks feature can help motivate you too.
Here's the thing, there's a lot of social pressure in our industry to start a startup.
I wonder if OP has ever question why he wants to create these startups.
I found a while ago, that I like kids, I like playing with them, I would never have one though, I see Startups as the same way, it's something you'd be stuck forever, like my JQuery Mobile based product of my own startup, I can tell you now that I get to fuck around in my free time, now I'm happier.
You need to question yourself more, are you a programmer or an entrepreneur?
I often find that when I'm working on a really good side project I severely underestimate the time to finish.
Of the few times I've forced myself to actually finish it ended up completing in the wee hours of the morning.
So I've became more picky about the side projects and if I'm unwilling to commit to finishing it in the wee hours of the morning then it probably isn't worth doing at all.
The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
219 comments
[ 3.5 ms ] story [ 247 ms ] threadIt also helps to remember that software projects are never finished - only abandoned.
Or teach people how to use the new shiny thing.
Or help them decide the pros and cons of new technologies by talking about the subtle distinctions you have noticed between them through your experimentation.
While working to build out the "auto-scaling, multi-zone, cloud infrastructure" product, OP (or anyone for that matter) will get caught up building his own front end JS framework that will address some shortcomings of AngularJS or reactjs.
If I understand correctly, the point of the article is that it's incredibly easy to lose focus of what you set out to do and get distracted by something that is not very important to your project/startup.
I guess all of us learn something similar to this at some point in our lives.
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.
People have built million dollar business that had it's first iteration in MS Excel, if it is useful to someone and kind of serves the purpose then that is enough for a start.
Well, you probably know that. But for me that was important, so I'll mention it anyway.
Also did I mention that you are an introvert by nature (read susain cain). You are easily distracted by shiny things.
P.S. I am no expert, those are just the things that I realized about myself....
P.P.S Shit. I think I am still like you, because otherwise I would have worked on the code review that I was supposed to do....
Zero or more feature nudity, ditto sports, one's a flowchart, but they have one thing in common: Nude or not, none of them have anything to do with your work. So what makes any of them NSFW? (The subject of this discussion is "getting things done".)
Some of my stuff is good enough to use (as in early alpha), but doing the final 20% won't pay off anyway.
You (probably) don't need the microservices and the complexity that comes with it, upfront. A monolith (and the simplicity in terms of deployment, logging, monitoring, etc. etc.) will probably do early on.
However, you don't want to shoot yourself in the foot for when it turns out you do need those things.
I try to write code in self-contained modules, with well defined boundaries, and glue it together in a monolith. If/when it needs to be split out into separate services, it becomes much easier.
So, application/business logic code: keep the standards high, do shit properly. Glue code to keep it all together? Less important. You can rip that out later and move to different infrastructure with the same code.
That's very generic advice, and I seem to always break my own rule on this at some point... but I find it's a better mentality for when shit just needs to get done.
Doesn't help with tech choice in general though (and I'm often guilty of this as well...).
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.
Personally I'd hate to run my own business, since that means moving away from the code (even if you get another person to take care of the non-code stuff; you still have to go out and find the right person for that / get involved in things that you wouldn't otherwise choose to). That said I'd love to create something, put it out there, and have 5 people come back and say "thanks for this; you've fixed a problem that I was having"; to get 100 people say that would be even better; any more and I'd probably start to get upset as there would become expectations to start implementing things the user base was asking for, rather than just doing my own thing; which for a hobby project is all I'd want.
A lot of my side projects relate to my day job; I use my spare time to create tools which make my work life simpler. Sure the IPO belongs to my employer, but it means I remove frustrations from my working day without having to justify spending company time on the tools which allow that, and I can share these tools with colleagues so that my friends get the benefits too. That makes for a pleasant life.
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.
Sure, but it's not reliable. And that lack of reliability makes it inferior to a good job. If you're really a glutton for punishment and don't mind letting the market be your teacher, then you can make it work eventually.
If you're wired that way, for sure do what you need to do so you can stay sane. That's a big ole' pile of nope for me.
Good jobs are hard to come by and can be unreliable also.
I've never had a bad job. Every job I've ever had after high school, I was glad to have and reluctant to leave. Except the military. I was glad to leave that. But I was also glad to have it.
Jobs can be worked on, you don't have to accept bad situations. I've negotiated raises, perks, all kinds of quality-of-life improvements that were unheard of 5 years ago are on the table today. It's a great time to be alive.
There are plenty of dog jobs doing enterprise middleware API plumbing, and polishing a product for a zombie startup that doesn't know they're dead yet, and being 8th engineer from the left at BigBoringCorp. Maybe easy to get those jobs. The good ones, interesting problems, successful product/company, growth opportunities, steady pay/raises, outstanding benefits, etc. are not growing on trees.
The reason I can be comfortable in these jobs and many techies would feel So Unbelievably Professionally Stifled is because I have separated my personal life goals from my professional life goals and correctly (to me anyway) prioritized personal over professional.
If you're feeling professionally stifled, then you probably have personal issues to work through that would bear more fruit than moving the needle professionally. If you have a great job, but a shit marriage, you need to reprioritize. If you have a great personal life and you still feel professionally stifled, then by all means start moving that needle.
To me personal life is endlessly fulfilling, I can devote 24 hours a day to it if I was independently wealthy. Personal life is defined by achieving goals together with people you're very close to.
Just about any job in America that's not bleeding over into your personal life is a good job. That's my definition. I want to bleed my personal life into my professional life and not the other way around. This is where quality-of-life perks like work from home days, unlimited PTO, and such come in. Things like successful products, growth opportunities, meaningful raises, are nice-to-haves and not essentials.
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 still talk with the guy and fill out estimates for his potential clients whenever he wants. We'll eventually hack out a working professional relationship and start a company together.
The fact of the matter is that personal life matters more to me than professional life. I think a lot of people wind up using professional accolades to make up for things they can't get in their personal life. Maybe that's not you, but for me, working on my relationships and my emotional health is 100x more important than a big pile of money and influence ever will.
Maybe your answer to this is to "just work harder." To that I just have to say, 'absolutely not'.
You can have a rewarding personal life and still learn while building something on the side, and show it to the world. But, I think you have to be prepared to appreciate the process without expectation of payoff. Just my observation, your comments read like there is a preoccupation with the latter.
There is a lot of point in shipping, and as somebody else pointed out that something made in 2 hours can also be shipped.
What shipping has taught me is to really really restrict the scope, the un-essentials. That in turn has helped in my day job as well, to negotiate correctly on milestones, feature scope etc helping me in staying sane and productive!
>> strangers things that they want you to give them
I don't know if you mean OSS users by this but if yes, then where are these users pestering the authors to give them something, they just lap it up if it is useful when the author gives it to them.
I said "ship" it. not work harder. You can even ship something you built in a couple of hours.
It IS ok to not ship every single project you work on, but it is not ok to be proud of how you never ship.
Personally in terms of "learning" I learned 90% of what I have learned AFTER shipping. You think you are learning but you are only scratching the surface.
I found out that after landing six clients and taking on a ton of business, myself and my partner (who was also working a full-time job too) got in and suddenly my personal life vanished. Sure, the money was rolling in, but all of my relationships suffered, I didn't have time to do the things I really wanted to do.
Worse yet? I felt like all my clients would want the latest and greatest web technologies and applications to make their businesses run smoother and easier to manage. Nope. They just bickered with me and it was a series of struggles to get anything done. Twelve iterations of design and several "come to Jesus" meetings couldn't stop the non-stop changes for one client. Another client was stuck in a paper and pen world and didn't want to automate or change anything about the one process that hindered their business. Another wanted web design from 1995. It was maddening.
After a year, I fired three of my clients, finished two of the sites and cut those clients loose and then kept the only one that was a joy to work with.
My life returned to normal, but it made me realize exactly what you said. My LIFE is more important than a pile of money. Maintaining my relationships with my family and friends should be more important.
I did that and gained nothing from it. I don't mean it as a complain, more like reality check - most of the time you don't magically learn by shipping whatever you done in few hours.
It's like saying "I have a Twitter account and nobody cares what I say, I never get a single reply or a like. Btw I have 0 followers".
Shipping means getting it out there AND see what people think of it. If you at least tried to do that, you would have probably learned something. Even one person looking at your thing and giving you their thought is a learning experience.
Most people don't do that because they don't want their ego to be hurt. My point is don't worry about that and just talk about stuff you build with as many people as you can and hear what they say. It's ok even if they tell you it's shit, because you have now learned that you have built shit (You would not have known that if you never talked to anyone), and if you did built shit, you can learn what makes it such a shit, so next time you can do better. Otherwise you can just keep making shit.
Lastly, random strangers on the internet telling you that you did build shit does not mean you did built shit. Nor them telling you that you did something awesome means you did something awesome. They may be right or wrong, they may be trolls, they may want to feel you good, they may have had bad day.
The feedback may be useless simply because they have different goals that you had. Especially in situation where your goal was to ship whatever is possible withing x hours (topic of this thread) and the public it is a shit cause they would accept something equivalent to days of work. Which is alright as far as I am concerned, but hardly a learning experience.
And they both managed to keep it civil several responses in. (Although one of the people is definitely nicer than the other -- I won't say which).
I'll leave you with the now famouse Glengarry Glen Ross Scene: https://www.youtube.com/watch?v=v9XW6P0tiVc Always be shipping! You don't ship, you don't exist. When I hire I always ask about shipped products specifically. The things that didn't ship don't exist. I consider that wasted time. One shipped product means more than 1000 personal projects that didn't ship, no matter how much you think you learnt.
And why should I? I'm doing it mostly for the fun of coding, and striving to "ship" things takes some of the fun away. I most certainly do not want to start a start up from any of my side projects. Perhaps an established open source project at most.
I do "release" my project, ie. push them to GitHub, but they don't really gather any attention or contributions from others. Sometimes I share some snippets in relevant discussions and receive positive feedback but I have no idea what it would take to actually gain any traction.
So I've basically given up on the idea of "finishing" or "shipping" or whatever. I have 3 hours of free time on Saturdays and I get to choose how to use it. I can either do fun stuff (coding, art, etc) or desperately try to "ship" and gain traction but that just isn't fun.
That said, if anyone is interested in open source space simulation (my current "main" side project, 5+ years in), get in touch on HN. There's no way I'll ever ship it alone, but it's nearly impossible to get anyone else to help me with it because I don't have anything cool and shiny to show.
I have many friends who release things like you. I'm not saying you are doing this but these guys just release and make no effort to promote them. They are afraid that they will get hurt if they try hard and no one still wants their thing.
I understand this is totally valid fear and I have it too, but I also know that getting the word out vs not doing it makes a huge difference.
Next time you build a product try to post it online everywhere like Reddit and Show HN. I'm sure you'll gain more confidence and experience from it.
> Next time you build a product try to post it online everywhere like Reddit and Show HN. I'm sure you'll gain more confidence and experience from it.
Here's the problem, I never "build a product". My free time is not nearly enough to build a proper product that would a) be fun for me to write b) interesting enough for the general public.
Basically the best I can do is show a few screenshots or a few hundred lines of interesting code. In my experience, that's not enough to gain traction on Show HN or Reddit. Sometimes I share screenshots on IRC and do get some interesting follow-up discussions but that doesn't really help me to get these projects any further.
Maybe I should gather up the courage and start posting to reddit /r/gamedev "screenshot saturdays" threads for getting feedback and encouragement. Although I'm not really doing a game here.
But yeah, I mostly try to not think about the idea that I'll never finish these projects and have fun while hacking on them. I've been doing this for 20 years now and never really "shipped" anything, so I might as well stop worrying about finishing and just have fun.
I currently work full time for a company whose policy forbids releasing anything I work on in my free time, so it's kind of nice--the decision is pretty much made for me.
I guess the advice is learn to _finish_ things but don't get too hung up on releasing them. Unless you're trying to build a business in which case you need to follow a totally different path (release MVP early, get feedback, iterate, market fit, etc.).
Luckily I live in a country where the law doesn't allow an employer to forbid releasing projects done on free time, so I don't have your issue. I would seriously reconsider my employment if I were given such restrictions. As little as I finish stuff, the ability to share and receive feedback from strangers in the internet is still positive to me.
I've got some similar projects: An NES emulator that I play with optimizations in, and a bunch of utilities related to the game Ultima Underworld, which are basically waiting to be plugged into an as-yet-unwritten game engine. There's some interesting code (both mine, and disassembled code from the original game binaries), but the shiny, attractive parts are spread thin.
Plus, if I had external pressure to work on these things, I feel like they'd lose some of their interest. Part of why I like them is that they're impractical projects that I can putter around in occasionally, when the muse strikes.
I have a feeling that naturally extroverted people do not understand that it takes a real push from other to show your work to strangers.
Same thing as the discussion about "demo days" earlier today. Those who are good in promoting are not necessarily those who are good in building projects. This applies to other aspects of life as well as it does to pitching startups.
http://jpad.io/ - Java snippet runner that means less boilerplate and automatic display as html tables / charts. http://www.sqldashboards.com/ - Real time chart your database queries http://www.timestored.com/ - Niche database training and tools
cough always be pushing :)
It's much, much harder to get a project to a state where someone can git clone, build and run it. Depends a lot on the target platform and the nature of the project, some languages and platforms are easier than others.
No need to be arrogant, though. Nice that you have the time and the ability to finish but don't expect everyone else to have the time and the capabilities to do so.
The thing is, not everyone builds things to have something at the end. A lot of my side projects exist because I enjoy hacking on them, not because I have some particular end result I'm looking for.
Of course, I have other side projects where I want both, and for those, shipping probably has value.
The amount of users that (a) browse the same websites I do and (b) take issue with the same things I take issue with are next-to-zero.
I also don't care to hear how I could refactor huge parts of my code to be more extendable in the future - because I have no plans to extend it to begin with. I know the code is absolute garbage and I can easily improve it if I took 10 minutes to refactor it. But it works and that's all I needed, so that's all that gets done.
People have different motivations for releasing publicly. I know you were probably speaking more to side projects, especially potentially profitable ones, but I felt I'd throw in my $0.02 to accompany all the others.
I've got a side project with minus $30/month in revenue, with no plans to do much better. I have 3-5 users who complain when the site goes down and give me feedback on new features.
The motivation for the project is twofold. The simple joy of creating something -- no different than hanging a child's drawing on the fridge, and to keep my skills current and to play with technology I might otherwise not be using at work.
That being said -- I agree with you -- without shipping a working product, you've got nothing.
As a specific example, I wrote a personal set of Minecraft tools.
I read a lot of file format information off the wiki to get compatibility with their map (and other) files. Did I accidentally use protected IP because the wiki wasnt clean information? Maybe. Did I stray in to copyright violation by using their names for blocks, rather than renaming the numeric codes? Possibly.
Then there's the fact version 1 was a hacked together spaghetti ball with magic values all over the place I wrote in an evening. Would I have benefited from having that feedback told to me? Not at all -- that was actually solid engineering to get 'er done as a prototype.
A week later version 2 was out, but it was a complete rewrite that didn't have any compatibility. Maybe feedback would've been helpful here, but even I thought there were still some obvious flaws because I was trying a new style of programming in Python, and it hadn't gelled yet.
Version 3 was a week or two after that, with another breaking rewrite. This time it used a model of automata from a completely different source, changing the storage format, adding a scripting interface, etc. with only a thin definition file for and import/export layer to Minecraft.
And that's where it sits on a drive, 90% finished automata development tools with MC compatibility because I learned what I wanted to from the project and moved on to other things. (I say 90% finished because while it works fine, there are features I thought of but didn't add.)
I don't want to keep working on it, I don't want to share the implementation of the automata engine because it's slightly buggy, and I don't want to support the project if others choose to use it. (And they very well might -- MC development tools suck.)
What would've been gained, at any point, in "shipping" it (beyond using it myself to make a few maps, which I did)?
I often set the bar so high there is no chance I could ever finish. The only projects that are attractive and shiny enough are those that are too big to finish.
E.g. I could choose between writing, completing and shipping a small indie game. Or I could write an OS from scratch, or the next Unreal Engine because I think it looks shiny.
Obviously I have no chance in hell of compleing a AAA game engine. Or an OS that does any more than say "Hello world" on boot. But I can pretend to be writing a AAA game engine - and I can keep pretending for many nights, until I have 1% of a game engine. At that point, there is probably something shinier that gets my attention.
So releasing it to the world: Obviously: I could put my 1% of a game engine on github for everyone to see, and that would be "releasing it to the world". But most likely no one would see it! I have hundreds of projects sitting around in various stages of completeness. Perhaps 2 or 3 were ever in some kind of usable state - and what they do have in common is that it was horrible to "finish" them in terms of making a proper repo, readmes, deployments, setups etc...
The reason finishing stuff and shipping them is so boring is because even a trivially small project that people actually want to use will have a ton of work required that aren't coding. I have no interest deploying a web app, no interest in drawing (or searching for) graphics for the little indie game etc. I'd rather make a new placeholder game than finishing the first one! I just want to code. I don't mind showing my code. I just normally don't want make a finished product of it. I get enough of that at work.
Edit: noticed someone said pretty much exactly this already and you responded. Oh well.
So yeah you sure could complete and release shit, you just don't want to for some reason or other.
Terry is a force of nature.
This reminds of a chapter in "Computer Power and Human Reason" where Joseph Weizenbaum describes the differences between compulsive programmers and professionals.
> His main interest is, in any case, not in small programs, but in very large, very ambitious systems of programs. Usually the systems he undertakes to build, and on which he works feverishly for perhaps a month or two or three, have very grandiose but extremely imprecisely stated goals. [...] It is characteristic of many such projects that the programmer can long continue in the conviction that they demand knowledge about nothing but computers, programming, etc. And that knowledge he, of course, commands in abundance. Indeed, the point at which such work is often abandoned is precisely when it ceases to be purely incestuous, i.e., when programming would have to be interrupted in order that knowledge from outside the computer world may be acquired.
I'm not really in it to create, and that's perhaps the key. I write programs because that's how I understand problems. If I could understand something by reading a book or Wikipedia page then I'd often just do that and not have to do the coding at all!
Doing this kind of superficial learning-through-coding is fantastically effective I must say.
No, I have side projects to learn and play. Lots of things I try end up in production code at work because I learned how to do it. Of the projects that are in pretty good shape I don't want to ship it because then I'm committed to supporting it. Shipping turns a side project into a job and unless I have a killer app that will make me some serious money - I have a job and I don't need another.
In the case of Facebook, I think it must have felt important, because it saw instant success around campus. Once you see that something is generating success, even on a relatively small scale, that starts to validate its importance and you can rationally consider increasing your commitment.
Your what?
Most of the projects I work on in my free time I start because I want to learn about something (new language, new UI framework, whatever), and once I feel I have achieved that, my motivation drops dramatically.
Also, not having to deal with deadlines, strange and ever-shifting requirements, or angry users is part of the fun. Walking away from a half-finished program is not something I could get away with at work, so it is kind of a relief to be able to do that sometimes.
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?
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.
Receiving daily updates for desktop apps would suck because it typically requires the app to quit and start again. A good compromise would be updates every four weeks. At the same time you as a developer always leave your app in a state were you could push an update anytime. So you still work incrementally in daily units of work.
Daily updates for libraries … if it's only publicly available code, I don't see a reason not to push daily. Anyone interested can check the commit logs. For compiled binaries on the other hand I can see update fatigue for users (other developers). Once a month or longer seems fine.
In the end, push regularly (daily, weekly, monthly, whatever fits you) without annoying your users by spamming them with updates, while at the same time reduce work units to a size that does not feel overwhelming.
You can automate all steps for building an application but the signing to make your life easier. You can also automate things locally if you're worried about what you're signing.
The bottom line is that this applies to all apps (though your users might be irritated if they need to keep downloading updates).
Because yeah, by hand, even deploying my webapp would take a couple hours. it took me maybe 8hrs of labor to setup my deploy script but given as I've deployed maybe 50 times so far it's paid off.
For me, that would be:
1) provision VM
2) configure the new VM (security hardening, install utils)
3) download app from git and configure it
4) take image of vm
5) install new image into my autoscaler
6) hot-replace live instances of previous version with new version.
doing each of those commands by hand and waiting for each to complete could easily take 1.5 or 2 hours of work. I did it by hand the first couple times but once I figured out my workflow I automated it (bash script) as fast as possible.
I spent a couple days looking into ansible, but as I have a very specific need I didn't want to spend 2+ weeks adding another chunk of "technical debt" to my product.
This is so true. I, as well as a few others I know, have built some pretty cool things that have never gotten the attention they deserve.
I've built a good base for mplyees in about 4 months. Marketing it and getting it out there will take a lot more time unless I get lucky.
Shipping can be the result of, or one way, to do the right things. But if you look at projects on Github it's usually not a lack of "shipping daily" so much as a lack of packaging it as something useful. Often you see daily commits until the motivation wears off and the project stops. But the software is still buggy, there's no screenshots, it's not straight forward how to build it, lacks documentation etc. They haven't made it into something that is easy for other people to appreciate, so they don't get much positive feedback.
This is great advice, but when it's not possible to ship daily, I find that even just committing once a day is a good micro-goal to keep projects moving. The GitHub streaks feature can help motivate you too.
I wonder if OP has ever question why he wants to create these startups.
I found a while ago, that I like kids, I like playing with them, I would never have one though, I see Startups as the same way, it's something you'd be stuck forever, like my JQuery Mobile based product of my own startup, I can tell you now that I get to fuck around in my free time, now I'm happier.
You need to question yourself more, are you a programmer or an entrepreneur?
So I've became more picky about the side projects and if I'm unwilling to commit to finishing it in the wee hours of the morning then it probably isn't worth doing at all.