The art of over-engineering your side projects • Hacker News Board

Re: The art of over-engineering your side projects

#251

Post by howlgram » Sat, Sep 02, 2017, 10:03 AM UTC

soheil wrote: post #205

johnfn wrote: 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…

And then there is everyone else in between, including me who both want programming to be fun and enjoyable and on the other hand simultaneously care about getting a product to market.

yeah but those don't make for interesting articles or discussions

Re: The art of over-engineering your side projects

#252

Post by kerkeslager » Sat, Sep 02, 2017, 10:55 AM UTC

scott_karana wrote: post #233

mark-r wrote: post #148

Earlier quoted context omitted.

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 ;-)

There are no silver bullets, but there are wooden bullets that are totally ineffective.

Re: The art of over-engineering your side projects

#253

Post by rochak » Sat, Sep 02, 2017, 12:27 PM UTC

jcadam wrote: post #131

I absolutely use my side projects as a vehicle to learn new things... though I always try to pursue ideas that at least appear to have a possible path toward monetization at some point (though I haven't had much success with turning much of a profit from any projects thus far) :) For my current side project, which I've been working on for a year (and is probably a month or two away from being "beta-able"), I've learn…

Could you tell me how you go about knowing what all you might be needing.

Re: The art of over-engineering your side projects

#254

Post by chris_st » Sat, Sep 02, 2017, 1:00 PM UTC

iamnafets wrote: post #194

johnfn wrote: 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 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.

Absolutely. This even works at a somewhat lower level... I remember hearing an argument between two cow-orkers, and realizing that each was thinking different (but similar!) things, but assuming the other was thinking the same thing. Angriness ensued...

Re: The art of over-engineering your side projects

#255

Post by jcelerier » Sat, Sep 02, 2017, 1:32 PM UTC

outworlder wrote: post #143

majewsky wrote: post #60

Earlier quoted context omitted.

> Minecraft was built in Java and was TERRIBLE for the first couple of years, now look at it Well, it still takes absurd amounts of memory for what it's doing, which I guess is on par for Java. (On my notebook with 4GB RAM, modpacks fall into one of three categories: "works well", "have to shut off as many OS services as possible before starting" and "forget it".)

> Well, it still takes absurd amounts of memory for what it's doing Does it though? There's a non-trivial amount of data being loaded (and generated) all the time. You have mentioned modpacks. Those can be HEAVY. And a single not well programmed block can bring down and entire server.

comparing minetest (a c++ minecraft clone) and minecraft gives the following memory usage upon starting on a blank new world. Also, minecraft takes five times more time to launch.

  smem  | grep mine 
   5728 jcelerier minetest                           0   433136   439287   466348 
   7044 jcelerier java -jar /usr/share/minecr        0   691476   708501   753948

Re: The art of over-engineering your side projects

#256

Post by brianpan » Sat, Sep 02, 2017, 3:34 PM UTC

johnfn wrote: post #185

czep wrote: 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 two groups of people on HN: people that think everything is binary and people that think everything is a continuum.

I'm somewhere in the middle.

Re: The art of over-engineering your side projects

#257

Post by bthallplz » Sat, Sep 02, 2017, 6:03 PM UTC

iamnafets wrote: post #194

johnfn wrote: 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 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.

This skill is one of the key differences that I've noticed among philosophy students (majors) and everyone else, with their skill being far more developed than others'.

I'm not sure if persons with the skill are more disposed towards studying philosophy or the study of philosophy prompts the development and demonstration of that skill more, but hang out with the philosophy kids and you might come to refine this skill by social osmosis.

Re: The art of over-engineering your side projects

#258

Post by kerkeslager » Sat, Sep 02, 2017, 6:31 PM UTC

scott_karana wrote: post #125

kerkeslager wrote: post #49

Earlier quoted context omitted.

Potential customers do care about the stack you're running. They care if they have to download Java or Flash. They care if they have to be connected to the internet or can use your product offline. They care if your program starts quickly. They care if your program runs quickly once started. They care if your program has bugs (let's not pretend different languages aren't more or less error-prone). They care if your p…

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

Have you figured out a way to make a mature implementation of the JVM start up fast? Nobody else in the industry has.

Is there some way I know of to package Flash games so that Firefox users can play them without downloading Flash?

I get that done of the examples I mentioned are arguable, but some of these are pretty unambiguously stack intrinsic. Some usability concerns cannot be addressed in some stacks.

Re: The art of over-engineering your side projects

#259

Post by juanuys » Sat, Sep 02, 2017, 6:44 PM UTC

hamvocke wrote: post #46

Good points in there. I have a little trouble with "mistake #5" though. I found that worrying about deployment automation early on is immensely valuable, especially for side projects. I don't always find time or interest to keep working on side projects after a regular day of work. Quite often there are weeks or even months where I abandon a side project only to come back at a later point when motivation is back or t…

I definitely automate locally by way of Makefiles, running tests then using the GCloud/aws CLI to deploy from local. Things like TravisCI, webhooks, etc come much later if at all.

Re: The art of over-engineering your side projects

#260

Post by jeffdavis » Sat, Sep 02, 2017, 7:03 PM UTC

WalterSear wrote: post #158

markcerqueira wrote: post #138

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…

If you have to start giving reports, it kills creativity. The point is to do something everyone else may think is irrational, but you feel would lead somewhere interesting.