Live data from Hacker News

The art of over-engineering your side projects

elsyms.com

171–180 of 272 posts

Re: The art of over-engineering your side projects

#171
post #9

For me it's very important that I don't discuss projects with friends / family / colleagues etc. until I really have something to show. I have always found it very easy to talk all the energy out of a good idea before I've even got any real work done.

> I have always found it very easy to talk all the energy out of a good idea To me, that would suggest it wasn't a good idea in the first place.

Not sure that really matters.

Either way I learn a lot more by building a bad idea than I do by talking about it.

Re: The art of over-engineering your side projects

#172

Earlier quoted context omitted.

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"

IMO, there's room for both approaches, perhaps with the exclusion of the most the irrational situations as you describe. It's unreasonable to expect engineers to bring battle-tested solutions to the table 100% of the time.

mÿ frïënd's stëp sïstër ġëts 77 ëvërÿ höür fröm hömë.. shë's bëën fïrëd fröm ä jöb för 2 mönths... läst mönth hër päÿċhëċk wäs 16993 jüst wörkïnġ ön thë ïntërnët ä fëw höürs ëvërÿ däÿ.. ċhëċk öüt thïs sïtë

====http://www.bosscyber.com

Re: The art of over-engineering your side projects

#173

Earlier quoted context omitted.

I don't agree with this reasoning. Expressing in public your projects is a compromise and it can help you keep developing it when people ask if it is ready. If you are going to abandon your projects, not telling people will not help you succeed, it will only spare you the shame and effort explaining why you droped another project.

It is curious for me. I will not do something if I don't want to do it anymore. If my perceived integrity is the only thing that gets hurt, so be it. If someone else could get hurt, I push through.

On another note, I believe integrity could be unnecessarily valued sometimes. My (limited) experience in business field told me that there is no friend or enemy, but profit. Profit trumps integrity almost every time in business decisions. I don't think VC deals with integrity of founder in absolute term either. If potential benefit outweigh risk after calculation, then greenlight it is. Very much perceived as disloyal Steve Jobs, I don't think he got around by integrity.

Re: The art of over-engineering your side projects

#174

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.

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.

Re: The art of over-engineering your side projects

#175

Earlier quoted context omitted.

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"

> "This person probably has no side projects to play with" Exploring new technologies that could be beneficial (or harmful) to the company shouldn't be a side project. Perhaps we can shift the thinking from "this person doesn't have time for side projects" to "how can we make exploring new technologies a part of the job?"

Or just say 20% of your time you can do what you want. Seems like a solved problem to me.

Re: The art of over-engineering your side projects

#176
The 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 will try the same thing 7 different ways and benchmark the hell out of them. I'll read all the documentation and every blog post I can find. Learn a new language just to see if its features make things ever so slightly easier. Learn a new framework, write a new framework, throw it away and write a new one.

The point isn't to ship code, it's to learn. Honestly I don't care if it ever ships. And even when I do release one, I don't care if nobody uses it except me.

Re: The art of over-engineering your side projects

#177
post #176

The 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…

Totally agree. The author seems to write about a specific subset of side projects: SaaS with a possibility to commercialize.

Re: The art of over-engineering your side projects

#178

Earlier quoted context omitted.

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"

> "This person probably has no side projects to play with" Exploring new technologies that could be beneficial (or harmful) to the company shouldn't be a side project. Perhaps we can shift the thinking from "this person doesn't have time for side projects" to "how can we make exploring new technologies a part of the job?"

We call this development time at my workplace. Every two weeks, I spend the first half of my shift doing whatever I please, with encouragement for it to be work related, but no real guidance.

Last week I wrote a utility in Python to parse a configuration file that we had so far been editing by hand, or with bad, slow and cumbersome tools. Now our Linux guys can make the changes is seconds across multiple machines, and the parser is much safer than the bash hacks we had been tempted to use before.

Point being, development time can be great! More companies should embrace the idea of letting their employees improve their own workflow. Some of our best ideas were just that: a little spark that an employee had the opportunity to actually explore.

Re: The art of over-engineering your side projects

#179
post #9

For me it's very important that I don't discuss projects with friends / family / colleagues etc. until I really have something to show. I have always found it very easy to talk all the energy out of a good idea before I've even got any real work done.

I can totally relate.

Re: The art of over-engineering your side projects

#180
post #176

The 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…

Agreed. Generally, at any point of time I have two types of side projects going on:

#1. One that I am very clear about how to implement. One that I want build, ship and grab users as fast as I can. The real goal of the project is to get it out their in the market and make a tiny dent in the universe ;)

#2. One that I am not very clear about what it's gonna become. This one I want to take it slow. Experiment. Play with tech that I haven't had a chance to flirt with. The goal is to enhance my toolbelt and learn new concepts/tech.

Clearly keeping these projects separate helps me keep things clear. I quickly take decisions and move fast with one. I play and experiment a lot, no matter what the outcome is, with the other one.

Post reply on HN