81–90 of 272 posts
Lots of times I use side projects as a way to explore new stacks, deployment approaches, etc. The goal of the project is not to deliver anything, it's to learn so that when I go to do my next "real" project at work, I know what works well and what doesn't.
That's a pretty ignorant and potentially short sighted statement. Look at what happened to Instagram. They almost lost it all because they hadn't planned for the possibility of handling scale quickly
Sometimes you simply don't have the luxury of monitoring and modifying to account for load and redundancy. Sometimes you're monitoring says "hey traffic" shortly followed by "OMG YOU'RE SCREWED" because you can't possibly think up and implement an appropriate scalable architecture, and modify the codebase to handle it and and and while your servers are melting and everyone is yelling at you.
Yes, this is very unlikely to happen, but when it does it can cost you your business if you're not prepared. Obviously apps with no networking and no viral component are far less likely to have this problem. Got a macApp that creates icon sets for XCode? Yeah, you can ignore this scaling issue. Writing the next Instagram? You're a fool if you don't have plans in place, in advance of launch, for . handling the onslaught of people that will make your business successful.
Lots of times I use side projects as a way to explore new stacks, deployment approaches, etc. The goal of the project is not to deliver anything, it's to learn so that when I go to do my next "real" project at work, I know what works well and what doesn't.
One thing I do not do, is just rebuild something someone else has already done in a new "stack", just to see if I can. Any project I undertake is a new idea I've not seen done, or with features I want.
> "Develop your project. Then, put it on the bare minimum architecture that it can run on (be that a 512MB instance from DigitalOcean or a medium instance on AWS). As you get more users, monitor, and modify the infrastructure appropriately to account for load and redundancy." That's a pretty ignorant and potentially short sighted statement. Look at what happened to Instagram. They almost lost it all because they hadn…
I had never heard this version before. The story I heard was that they pivoted from burbn, which they felt was to cluttered and unfocused. [1]
If they followed your advice, they would have built a scaled up version of burbn, which nobody would have used.
[1] http://www.makeuseof.com/tag/1-billion-in-2-years-the-story-...
For those who are interested: Video: https://streamacon.com/video/laracon-us-2017/day-2-mathias-a... Slides: https://speakerdeck.com/minicodemonkey/launching-and-scaling...
Lots of times I use side projects as a way to explore new stacks, deployment approaches, etc. The goal of the project is not to deliver anything, it's to learn so that when I go to do my next "real" project at work, I know what works well and what doesn't.
Actually starting to livestream them now as I figure if others can see what I'm trying to do I might be able to get instant feedback on how to do things better - crowd sourced learning :)
I always overengineer my side projects, because it's way more interesting that way. I do side projects for fun and to learn something, both of which happen more easily when the project is overengineered.
#3 hits home. I've been "working" on my side project for 3 years now with almost no progress because I'm constantly intrigued by new frameworks and BaaS. I spend all my time tinkering with them until I get bored with it all together. If I had just built the thing in Rails from the start I'd probably have a solid app under my belt by now.
Thinking about using Unity now...