Just like in real life, the art of engineering is iteration. So I always get quick and dirty results with my side projects, and iterate if it's worth iterating. But my side projects are just for myself, not for others, so it's things like writing a multi-thread stock strategy backtester, a dashboard for my IoT devices, etc. It's never that I think will make money.
The art of over-engineering your side projects
161–170 of 272 posts
Re: The art of over-engineering your side projects
#162I write a SVG path string optimizer for fun on the side. So far I wrote a custom decimal floating point type because of the 0.1+0.2 problem which I threw out afterwards, a zero allocation filter for printing rounded f32 without leading zeroes (.1 instead of 0.1) and dropping of unneeded spaces (.1.1 is valid and equal to 0.1 0.1), which I now want to replace with a custom float formatting routine.
All I did I did for fun and maybe learning something. So I think over-engineering side projects is fine.
Re: The art of over-engineering your side projects
#163Earlier quoted context omitted.
That's a thing. Expressing in public your desire to achieve something makes you less likely to deliver. http://www.psych.nyu.edu/gollwitzer/09_Gollwitzer_Sheeran_Se...
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.
Re: The art of over-engineering your side projects
#164Duck it, it's your side project.
You own it, nobody it paying you to work on it, over-engineer the shit out of it if you feel like it.
Re: The art of over-engineering your side projects
#165Earlier 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?"
Some companies are already doing this. When I worked at Intuit we would have Whitespace days and Innovation days, roughly every month or so where you could spend 1-3 days doing whatever you want.
Re: The art of over-engineering your side projects
#166I thoroughly enjoy over-engineering side projects, and writing about them (linked below). The trick for me is in managing expectations. It's completely possible for a learning project to evolve in to something widely used, just don't go in with that expectation.
https://blog.skywelch.io/2017/06/over-engineering-bunnies-io...
Re: The art of over-engineering your side projects
#167I actually find that unless I do some amount of project management (i.e. use Trello or Pivotal Tracker), I easily get myself sidetracked. I'll use other tools for longer running timelines, but splitting things out into small stories actually helps me stay focused without getting bogged down in considering the implications to every design decision I make.
For a lot of software, making the best decision today without worrying about tomorrow, while still following tried and true engineering practices (i.e. test driving, etc), leads to a project that continues to progress.
Re: The art of over-engineering your side projects
#168Earlier quoted context omitted.
"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).
> 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".)
4GB? I wouldn't expect most open world games to perform well with 4GB. I think 2010 was the last time I had a laptop with less than 8GB. My current laptop has 16GB. Game developera and certainly mod developers don't optimize for bargain basement hardware.
Re: The art of over-engineering your side projects
#169Earlier quoted context omitted.
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.
How do you prefer to store/ship logs?
Not 'amyjess, but the rightest answer I've found (and I do a lot of this stuff) is to use a Bunyan-style one-JSON-object-per-line log file and ship to something that can consume it (ELK, CloudWatch Logs, whatever). AWS CWL is dirt cheap and the awslogs daemon, while pretty far from perfect, does work pretty well. You can also couple it with CloudWatch Metrics.
Re: The art of over-engineering your side projects
#170If I don't overengineer my side projects -- if I stick to what's simple and practical -- how am I going to gain marketable skills with the modern frameworks?
Set your goals high for the project instead, achieving your goals can never be considered over-engineering. Don't let the scope creep into "oh I should totally spend 30 hours on this form design"