16 ms·

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

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.

mrisoli 9y ago
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 lot of people did this as experience to get iOs dev jobs.
- dcminter 9y ago
  Exactly - I enjoy side projects precisely because they're not bound by pragmatic concerns. I can delve as deep as I like into getting the CI pipeline working just right, making sure the servers and cacheing are set up ok and all those other things that I usually have to leave to colleagues. More often than not the skills I learn doing this kind of thing end up being very useful to me in the day job. I'd like it if the side project was successful enough to justify all of that yak shaving, but I don't really expect it to be and I'm not that fussed when it isn't. But if your primary goal is that your side project should become your day job then the article is pretty good advice. Leave your yak unshaven :)
  - TeMPOraL 9y ago
    > they're not bound by pragmatic concerns. 99% of the time, if you want to go pragmatic, you should buy a ready-made solution (and then possibly adapt it to your use case). It's efficient (especially if you need the problem solved to make money) - but it's no fun.
- mgolawala 9y ago
  I agree, but there are good reasons why it is often good to combine both types. 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?
Clubber 9y ago
I do that too, but make that my secondary goal. If it fails, at least I got to improve my skills on whatever technology I chose to build it in. It helps me push along when it gets to the dull parts.
bpicolo 9y ago
> Over-architecting infrastructure That's not a problem, that's the goal!
- amyjess 9y ago
  I have never regretted taking the time to make sure my projects have a proper logging infrastructure with every possible thing fed to the logger. I've built logging support libraries to set up AOP hooks to auto-log the call stack at all times, and it's been a lifesaver. I can't imagine not over-architecting this kind of stuff. I know I'd be in a world of pain several times if I hadn't.
  - cpfohl 9y ago
    If you would have been in a world of pain, I'd argue you weren't over architecting. You were doing your job just right!
  - tokenizerrr 9y ago
    How do you prefer to store/ship logs?
    - eropple 9y ago
      Not 'amyjess, but the rightest answer I've found (and I do a lot of this stuff) is to use a Bunyan-style one-JSON-object-per-line log file and ship to something that can consume it (ELK, CloudWatch Logs, whatever). AWS CWL is dirt cheap and the awslogs daemon, while pretty far from perfect, does work pretty well. You can also couple it with CloudWatch Metrics.
    - marcosdumay 9y ago
      That's completely dependent on the format of your infrastructure. There is no answer that will fit everybody, and asking around for advice of strangers may even bias you in a damaging way.
      - tokenizerrr 9y ago
bhouston 9y ago
I learned how not to over-engineer specifically from learning from my mistake of over-engineering my side projects. :)
meddlepal 9y ago
Yea a lot of my side projects are started out with the understanding they're not going to become anything more than toys for me to play with ideas. This article feels like it's written from the perspective of using a side-project to bootstrap a business rather than as a learning experience, hobby or toy.
shangxiao 9y ago
I often explore new stacks by building a product that already exists complete with identical css! For example: Wanna try out aiohttp, vue & css grids? Let's build a Slack clone!
- brightball 9y ago
  Yep. That's why I've rebuilt my little blog about a dozen times. I've built CMS's from scratch before (actually built a white label CMS generator) and it's a non-complicated process that I know deeply enough to push the pain points when I try things out.
alexandercrohde 9y ago
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"
- deleted 9y ago
  [deleted]
- shados 9y ago
  100% this. My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.
  - karrotwaltz 9y ago
    I recently built a C++ meta-programming monster for a side project. I want to make an article about that in the near future, and I am somewhat afraid that some people might think of reusing it in a real project. I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.
    - mindfulplay 9y ago
      That seems like a great side project. The one that let's you understand things NOT to do. At the same time, it helps engender basic traits like curiosity, try-until-you-fail-and-try-again, engineering skills etc. There are two types of side-projects though: one such as yours, where you try and understand a concept or engineer something just for the fun of it. And there is second one: a game that will mature into something; a hobby project that will actually develop into a company. I think it's good to disambiguate these two as the OP was more about the latter where you may never get to a point to see it run or build let alone flourish into something meaningful - as overengineering kills the fail fast fail often mentality and the project itself.
    - wellthen 9y ago
      My constant on-again/off-again side project is something similar but in C#. Spending a week building a preprocessor and then discarding it because I didn't need it was both infuriating and strangely pleasing at once. :)
overcast 9y ago
This is exactly how I approach side projects as well. I use them as iterative learning experiences, with each new project building on the last to more complex ideas. Learn a TON that way, and potentially build something that people want to use. You can always go back, and add things you've learned down the line. 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.
corobo 9y ago
Nailed it with this comment. My side projects are for learning. There was a moment or two where I was aiming to monetise but I'm not at that stage and I now realise that, I just want to play with technology. 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 :)
cagmz 9y ago
Where can one learn about different deployment approaches?
- caleblloyd 9y ago
  By "deployment approaches", I mainly meant CI/CD and infrastructure. So Jenkins, Travis CI, etc. to do the build work and testing, then automatically push to Kubernetes, Docker Swarm, AWS Lambda, etc. on the infrastructure side. For a side project, pick one on that you're interested in on each side. For example, maybe try out CircleCI and deploy to Google App Engine. Then you'll learn two new things, maybe one is great but the other is a pain in the ass. You can take the one that works well to a "real" project and talk knowledgeably to the architecture.
rdiddly 9y ago
Agreed; in fact, the title falsely (or maybe ironically) conveys a positive attitude about how it's an "art," thereby attracting people who, like me, wanted to hear about some gloriously and baroquely over-engineered side project that will never see the light of day. A large investment of time, effort and craft into something, for its own sake, with no heed to whether it will ever "ship": That's what art is, man! Should've been titled something like "Don't Over-Engineer Your Side Projects" or "How to Make your Side Project Resemble Your Day Job (If You Work for Sensible People)"
ukd1 9y ago
Boom. This. I wrote a response to this in a little more detail - https://rsmith.co/the-actual-art-of-over-engineering-your-side-projects-2af6326060bb https://rsmith.co/the-actual-art-of-over-engineering-your-si...
PaulHoule 9y ago
When you are doing a side project you typically have a number of risk factors such as: (A) using new tools, (B) working in a new area, (C) building a new type of application, (D) uncertain marketing, etc. Any kind of project has a "risk budget". If you have few other risks, then you can spend your risk budget on new tools. If you are facing high risks in other directions, it makes sense to stick with what you know.
adamkruszewski 9y ago
Most of my side projects are like that -- just an excuse to learn something and more often than not abandoned when I have learned what I wanted. Not the best way to develop software but a great one to learn new technology.
yingxie3 9y ago
I on the other hand, try to convince my employer to take on the new stacks, so I can play with it while getting paid

mrisoli 9y ago

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 lot of people did this as experience to get iOs dev jobs.

dcminter 9y ago
Exactly - I enjoy side projects precisely because they're not bound by pragmatic concerns. I can delve as deep as I like into getting the CI pipeline working just right, making sure the servers and cacheing are set up ok and all those other things that I usually have to leave to colleagues. More often than not the skills I learn doing this kind of thing end up being very useful to me in the day job. I'd like it if the side project was successful enough to justify all of that yak shaving, but I don't really expect it to be and I'm not that fussed when it isn't. But if your primary goal is that your side project should become your day job then the article is pretty good advice. Leave your yak unshaven :)
- TeMPOraL 9y ago
  > they're not bound by pragmatic concerns. 99% of the time, if you want to go pragmatic, you should buy a ready-made solution (and then possibly adapt it to your use case). It's efficient (especially if you need the problem solved to make money) - but it's no fun.
mgolawala 9y ago
I agree, but there are good reasons why it is often good to combine both types. 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?

Clubber 9y ago

I do that too, but make that my secondary goal. If it fails, at least I got to improve my skills on whatever technology I chose to build it in. It helps me push along when it gets to the dull parts.

bpicolo 9y ago

> Over-architecting infrastructure That's not a problem, that's the goal!

amyjess 9y ago
I have never regretted taking the time to make sure my projects have a proper logging infrastructure with every possible thing fed to the logger. I've built logging support libraries to set up AOP hooks to auto-log the call stack at all times, and it's been a lifesaver. I can't imagine not over-architecting this kind of stuff. I know I'd be in a world of pain several times if I hadn't.
- cpfohl 9y ago
  If you would have been in a world of pain, I'd argue you weren't over architecting. You were doing your job just right!
- tokenizerrr 9y ago
  How do you prefer to store/ship logs?
  - eropple 9y ago
    Not 'amyjess, but the rightest answer I've found (and I do a lot of this stuff) is to use a Bunyan-style one-JSON-object-per-line log file and ship to something that can consume it (ELK, CloudWatch Logs, whatever). AWS CWL is dirt cheap and the awslogs daemon, while pretty far from perfect, does work pretty well. You can also couple it with CloudWatch Metrics.
  - marcosdumay 9y ago
    That's completely dependent on the format of your infrastructure. There is no answer that will fit everybody, and asking around for advice of strangers may even bias you in a damaging way.
    - tokenizerrr 9y ago

bhouston 9y ago

I learned how not to over-engineer specifically from learning from my mistake of over-engineering my side projects. :)

meddlepal 9y ago

Yea a lot of my side projects are started out with the understanding they're not going to become anything more than toys for me to play with ideas. This article feels like it's written from the perspective of using a side-project to bootstrap a business rather than as a learning experience, hobby or toy.

shangxiao 9y ago

I often explore new stacks by building a product that already exists complete with identical css! For example: Wanna try out aiohttp, vue & css grids? Let's build a Slack clone!

brightball 9y ago
Yep. That's why I've rebuilt my little blog about a dozen times. I've built CMS's from scratch before (actually built a white label CMS generator) and it's a non-complicated process that I know deeply enough to push the pain points when I try things out.

alexandercrohde 9y ago

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"

deleted 9y ago
[deleted]
shados 9y ago
100% this. My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.
- karrotwaltz 9y ago
  I recently built a C++ meta-programming monster for a side project. I want to make an article about that in the near future, and I am somewhat afraid that some people might think of reusing it in a real project. I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.
  - mindfulplay 9y ago
    That seems like a great side project. The one that let's you understand things NOT to do. At the same time, it helps engender basic traits like curiosity, try-until-you-fail-and-try-again, engineering skills etc. There are two types of side-projects though: one such as yours, where you try and understand a concept or engineer something just for the fun of it. And there is second one: a game that will mature into something; a hobby project that will actually develop into a company. I think it's good to disambiguate these two as the OP was more about the latter where you may never get to a point to see it run or build let alone flourish into something meaningful - as overengineering kills the fail fast fail often mentality and the project itself.
  - wellthen 9y ago
    My constant on-again/off-again side project is something similar but in C#. Spending a week building a preprocessor and then discarding it because I didn't need it was both infuriating and strangely pleasing at once. :)

overcast 9y ago

This is exactly how I approach side projects as well. I use them as iterative learning experiences, with each new project building on the last to more complex ideas. Learn a TON that way, and potentially build something that people want to use. You can always go back, and add things you've learned down the line. 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.

corobo 9y ago

Nailed it with this comment. My side projects are for learning. There was a moment or two where I was aiming to monetise but I'm not at that stage and I now realise that, I just want to play with technology. 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 :)

cagmz 9y ago

Where can one learn about different deployment approaches?

caleblloyd 9y ago
By "deployment approaches", I mainly meant CI/CD and infrastructure. So Jenkins, Travis CI, etc. to do the build work and testing, then automatically push to Kubernetes, Docker Swarm, AWS Lambda, etc. on the infrastructure side. For a side project, pick one on that you're interested in on each side. For example, maybe try out CircleCI and deploy to Google App Engine. Then you'll learn two new things, maybe one is great but the other is a pain in the ass. You can take the one that works well to a "real" project and talk knowledgeably to the architecture.

rdiddly 9y ago

Agreed; in fact, the title falsely (or maybe ironically) conveys a positive attitude about how it's an "art," thereby attracting people who, like me, wanted to hear about some gloriously and baroquely over-engineered side project that will never see the light of day. A large investment of time, effort and craft into something, for its own sake, with no heed to whether it will ever "ship": That's what art is, man! Should've been titled something like "Don't Over-Engineer Your Side Projects" or "How to Make your Side Project Resemble Your Day Job (If You Work for Sensible People)"

ukd1 9y ago

Boom. This. I wrote a response to this in a little more detail - https://rsmith.co/the-actual-art-of-over-engineering-your-side-projects-2af6326060bb https://rsmith.co/the-actual-art-of-over-engineering-your-si...

PaulHoule 9y ago

When you are doing a side project you typically have a number of risk factors such as: (A) using new tools, (B) working in a new area, (C) building a new type of application, (D) uncertain marketing, etc. Any kind of project has a "risk budget". If you have few other risks, then you can spend your risk budget on new tools. If you are facing high risks in other directions, it makes sense to stick with what you know.

adamkruszewski 9y ago

Most of my side projects are like that -- just an excuse to learn something and more often than not abandoned when I have learned what I wanted. Not the best way to develop software but a great one to learn new technology.

yingxie3 9y ago

I on the other hand, try to convince my employer to take on the new stacks, so I can play with it while getting paid