101–110 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.
Exactly. When I see a coworker start irrationally focusing on a new technology at work the first thing I think is "This person probably has no side projects to play with"
“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!” The good news is, once you've done that, you can get a pretty decent job. The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running. This is not enti…
And you'll likely have to.
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.
Exactly. When I see a coworker start irrationally focusing on a new technology at work the first thing I think is "This person probably has no side projects to play with"
My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.
“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!” The good news is, once you've done that, you can get a pretty decent job. The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running. This is not enti…
Good points in there. I have a little trouble with "mistake #5" though. I found that worrying about deployment automation early on is immensely valuable, especially for side projects. I don't always find time or interest to keep working on side projects after a regular day of work. Quite often there are weeks or even months where I abandon a side project only to come back at a later point when motivation is back or t…
I'm a big fan of doing the hard work early on. When you push that step off it makes dev later slow and frustrating.
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.
Exactly. When I see a coworker start irrationally focusing on a new technology at work the first thing I think is "This person probably has no side projects to play with"
Still, I completely agree with the point that "experiments" should be kept off the critical path as much as possible. It all depends where your risk/reward is, though. The people that took the risk on a stack and got rewarded with success are highly visible. Just as many took the risk and failed. (Probably more?)
> "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…
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.
Me too, I think there are two types of side projects, this article focuses on those which I believe people will try to generate a business out of, or at least some form of passive income. But there are also some side projects where you just want to get your hands dirty with some different tech, if you do deliver something then you can showcase it on your portfolio. I know when the app store gold rush first started a…
Considering this is only a side project, you have a high likelihood of abandoning it out of boredom, lack of traction or simply burn out. However, if your side project is "interesting" to you because you are experimenting with various tech, you come back to it because it is fun and it will keep you motivated.
It is totally cool to build something to learn and throwaway, but why not build something to learn that might also generate some income in the future?
IDK, I over-engineer my side projects every single time. Like tweaking for days something which is so clearly premature optimization. But sometimes I need that knowledge again for the next side project. And this over-engineering is often a way to simplify a reference architecture and be much faster at the end. So for me over-engineering equals learning but is also a big part of the motivation.