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.
The art of over-engineering your side projects
241–250 of 272 posts
Re: The art of over-engineering your side projects
#242Earlier quoted context omitted.
HN is made up of two groups in ever constant warfare, the yin and yang, as it were- the group who thinks that programming should be fun, experimental and enjoyable, and the group that thinks that programming is a means to the end of getting a product to market and nothing more. Whenever a post from one group (such as the article) comes out, a post from the other (such as OP) will quickly appear. And everyone loves it…
This is mostly off-topic, but being able to identify or root out the value mismatches between people in a discussion (as you've done) seems like an essential ingredient to productive discussion. I've noticed that people who can do this are disproportionately better at achieving their goals than those who can't, especially in engineering organizations. Exceptions of course for zealots and revolutionaries.
Re: The art of over-engineering your side projects
#243The whole point of a side project is to over-engineer it! The thought of holding myself to deadlines and driving myself to "ship" is totally antithetical to the entire purpose of a hobby project. It's a welcome relief from the 9-to-5 constant necessity to cut corners and finish things without ever properly understanding them because there's no time. For my side projects, I actually want to go down rabbit holes. I wil…
Re: The art of over-engineering your side projects
#244The whole point of a side project is to over-engineer it! The thought of holding myself to deadlines and driving myself to "ship" is totally antithetical to the entire purpose of a hobby project. It's a welcome relief from the 9-to-5 constant necessity to cut corners and finish things without ever properly understanding them because there's no time. For my side projects, I actually want to go down rabbit holes. I wil…
Re: The art of over-engineering your side projects
#245The whole point of a side project is to over-engineer it! The thought of holding myself to deadlines and driving myself to "ship" is totally antithetical to the entire purpose of a hobby project. It's a welcome relief from the 9-to-5 constant necessity to cut corners and finish things without ever properly understanding them because there's no time. For my side projects, I actually want to go down rabbit holes. I wil…
HN is made up of two groups in ever constant warfare, the yin and yang, as it were- the group who thinks that programming should be fun, experimental and enjoyable, and the group that thinks that programming is a means to the end of getting a product to market and nothing more. Whenever a post from one group (such as the article) comes out, a post from the other (such as OP) will quickly appear. And everyone loves it…
Re: The art of over-engineering your side projects
#246Lots 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"
Lately I'm pulling back from technical deep diving at work. A lot. My role as an enterprise architect (bleh, don't judge too much plz) means I necessarily have to shift to big picture guff and stop spending time on the details pieces. In short, I don't really get to engineer as much as before.
Of course, I'm an engineer at heart so the idea of ignoring the details is anathema and it frustrates me. When I'm deep in whiteboards, board meetings and shitty powerpoint at work, the side projects and home lab become my release valve. It's a coping mechanism, I think.
Likewise, when I'm sucked into low-level grind at work which happens from time to time, side projects stagnate. I don't need them for a while.
Re: The art of over-engineering your side projects
#247The whole point of a side project is to over-engineer it! The thought of holding myself to deadlines and driving myself to "ship" is totally antithetical to the entire purpose of a hobby project. It's a welcome relief from the 9-to-5 constant necessity to cut corners and finish things without ever properly understanding them because there's no time. For my side projects, I actually want to go down rabbit holes. I wil…
The main reason I've wanted other people to use the things I've made is to learn more about what I've built and how it could be better.
Re: The art of over-engineering your side projects
#248Re: The art of over-engineering your side projects
#249Re: The art of over-engineering your side projects
#250The whole point of a side project is to over-engineer it! The thought of holding myself to deadlines and driving myself to "ship" is totally antithetical to the entire purpose of a hobby project. It's a welcome relief from the 9-to-5 constant necessity to cut corners and finish things without ever properly understanding them because there's no time. For my side projects, I actually want to go down rabbit holes. I wil…
HN is made up of two groups in ever constant warfare, the yin and yang, as it were- the group who thinks that programming should be fun, experimental and enjoyable, and the group that thinks that programming is a means to the end of getting a product to market and nothing more. Whenever a post from one group (such as the article) comes out, a post from the other (such as OP) will quickly appear. And everyone loves it…
Yet it would not exist without the second group because it was started by an investment fund/startup incubator.
I agree with you, I love both perspectives and the passions they ignite. I am squarely in the first group, and I love reading about the real life realities of product design/management, pitching, etc.