Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The art of over-engineering your side projects

elsyms.com

Post reply on HN
Print view View original

111–120 of 272 posts

Re: The art of over-engineering your side projects

#111

Post by caleblloyd »

cagmz wrote: post #96
caleblloyd wrote: post #2

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.

Where can one learn about different deployment approaches?

By "deployment approaches", I mainly meant CI/CD and infrastructure. So Jenkins, Travis CI, etc. to do the build work and testing, then automatically push to Kubernetes, Docker Swarm, AWS Lambda, etc. on the infrastructure side.

For a side project, pick one on that you're interested in on each side. For example, maybe try out CircleCI and deploy to Google App Engine. Then you'll learn two new things, maybe one is great but the other is a pain in the ass. You can take the one that works well to a "real" project and talk knowledgeably to the architecture.

Re: The art of over-engineering your side projects

#112

Post by quadcore »

dancodes wrote: post #105
quadcore wrote: post #12

“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!” The good news is, once you've done that, you can get a pretty decent job. The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running. This is not enti…

What frameworks/methods are you using to develop a game in Go?

sdl

Re: The art of over-engineering your side projects

#113

Post by rdiddly »

caleblloyd wrote: post #2

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.

Agreed; in fact, the title falsely (or maybe ironically) conveys a positive attitude about how it's an "art," thereby attracting people who, like me, wanted to hear about some gloriously and baroquely over-engineered side project that will never see the light of day. A large investment of time, effort and craft into something, for its own sake, with no heed to whether it will ever "ship": That's what art is, man!

Should've been titled something like "Don't Over-Engineer Your Side Projects" or "How to Make your Side Project Resemble Your Day Job (If You Work for Sensible People)"

Re: The art of over-engineering your side projects

#114

Post by cookiecaper »

elsyms wrote: post #15
quadcore wrote: post #12

“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!” The good news is, once you've done that, you can get a pretty decent job. The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running. This is not enti…

"A customer will not know or care if you are using Ruby, Go, PHP or any other language as long as what you have written is performant and is fit for purpose (which all modern languages are)." Where games are concerned I'd tend to agree (though Minecraft was built in Java and was TERRIBLE for the first couple of years, now look at it).

These days, Java is on the faster side of languages in common use. At least it wasn't written in JavaScript or Python!

Re: The art of over-engineering your side projects

#116

Post by amyjess »

bpicolo wrote: post #21
caleblloyd wrote: post #2

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.

> Over-architecting infrastructure That's not a problem, that's the goal!

I have never regretted taking the time to make sure my projects have a proper logging infrastructure with every possible thing fed to the logger. I've built logging support libraries to set up AOP hooks to auto-log the call stack at all times, and it's been a lifesaver.

I can't imagine not over-architecting this kind of stuff. I know I'd be in a world of pain several times if I hadn't.

Re: The art of over-engineering your side projects

#118

Post by karrotwaltz »

shados wrote: post #104
alexandercrohde wrote: post #81

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"

100% this. My side projects are absurdly over engineered and I get nothing done. But I learn what not to do when it matters.

I recently built a C++ meta-programming monster for a side project. I want to make an article about that in the near future, and I am somewhat afraid that some people might think of reusing it in a real project.

I had a lot of fun doing it, and indeed learnt to not do it in prod, the compiler errors are a nightmare to read and good luck maintaining that in the long run.

Re: The art of over-engineering your side projects

#120

Post by cpfohl »

amyjess wrote: post #116
bpicolo wrote: post #21

Earlier quoted context omitted.

> Over-architecting infrastructure That's not a problem, that's the goal!

I have never regretted taking the time to make sure my projects have a proper logging infrastructure with every possible thing fed to the logger. I've built logging support libraries to set up AOP hooks to auto-log the call stack at all times, and it's been a lifesaver. I can't imagine not over-architecting this kind of stuff. I know I'd be in a world of pain several times if I hadn't.

If you would have been in a world of pain, I'd argue you weren't over architecting. You were doing your job just right!
Post reply on HN