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…
The art of over-engineering your side projects
231–240 of 272 posts
Re: The art of over-engineering your side projects
#232Earlier 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…
Or else.
War begins!
Re: The art of over-engineering your side projects
#233Earlier 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.
Proper engineering and design are required no matter what you choose.
No silver bullets ;-)
Re: The art of over-engineering your side projects
#234At 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…
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
#235Earlier 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.
Re: The art of over-engineering your side projects
#236Earlier 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?"
Re: The art of over-engineering your side projects
#237Re: The art of over-engineering your side projects
#238The 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…
Re: The art of over-engineering your side projects
#239The 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
#240The 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…