Live data from Hacker News

The art of over-engineering your side projects

elsyms.com

231–240 of 272 posts

Re: The art of over-engineering your side projects

#231

Earlier quoted context omitted.

> "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?"

How about making wednesday mornings, a 4hr 'personal project' time? Make it a requirement that everyone has to work with tools at the edge of their skillset, that is also relevant to work, but let them choose what, why, how. They could work on a personal project, or experiment with a new library or tool they would like to incorporate. Start the day with a "not really a standup", where people can quickly explain what…

This also lets junior developers practice planning and self-management, since they basically have 12 hours to come up with something to show.

Re: The art of over-engineering your side projects

#232
post #185

Earlier 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 not specific to programming, but personalities in general. There are people who love the journey and others who love the destination. People rarely switch from one to the other. It's part of our core ideals. However, there is a large, vocal, percentage from both these groups that will always voice their opinion against an opposition opinion. It's not a competition and there's no correct answer. It's purely su…

The quote. "We agree to disagree".

Or else.

War begins!

Re: The art of over-engineering your side projects

#233
post #148

Earlier quoted context omitted.

Those are all client usability concerns, and none of them are stack intrinsic.

I think the point was that user doesn't care about your stack, but they care about the consequences of the stack you've chosen. It's a subtle but important distinction.

Of course. My point was that it's fairly common to write slow/unsuitable applications in spite of a stack's strengths, while stack limitations (or strengths) are generally overstated, depending on trends.

Proper engineering and design are required no matter what you choose.

No silver bullets ;-)

Re: The art of over-engineering your side projects

#234

At risk of a tar and feathering by the 'lean' crowd, I am going to declare that I don't do MVP's at all, and never really have, with any of my projects. Why? Well, because almost all my projects are designed for businesses and enterprises, and with that audience - things better work well and they better work first time during the demo or you don't stand a chance of getting a customer. Perhaps if I was writing a socia…

I fully agree with this. Big enterprise MVPs are often about cutting scope -- not cutting corners.

Of course, by the very nature of enterprise customers, sometimes there isn't a whole lot of scope that you can cut.

Re: The art of over-engineering your side projects

#235
post #185

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

It's the same group of people, they just may be in different moods at different times.

I was going to say the same thing. I've frequently argued both for the ruthless pragmatism of just-get-it-shipped and for self-indulgent exploration.

Re: The art of over-engineering your side projects

#236

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 actually do this. We plan the learning phase for the sprint and we time box these kind of things for 1-2 days.

Re: The art of over-engineering your side projects

#238
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…

> 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. The objectives for a side project are subjective, and so they should be. However I doubt most people truly have no intention to ever ship a side project or "don't care if nobody uses it", as admirable as that would be. I look back at my naive, recently gradua…

I'm pretty sure you just made an objective subjective about subjective objectives.

Re: The art of over-engineering your side projects

#239
post #185
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…

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…

There are things in-between, too - Enjoy the fun software development process to make an end product successful! And this is exactly my own feeling and goal, though I'm not doing it very well as of now ;)

Re: The art of over-engineering your side projects

#240
post #185
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…

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…

The yin and yang. I love it. :)
Post reply on HN