Hacker News new | past | comments | ask | show | jobs | submit login
How I Side Project (dotink.co)
129 points by guiambros on July 29, 2019 | hide | past | favorite | 20 comments

Lots of interesting ideas in this -- well worth the read -- but in the competition for most productive paragraph, I would guess the following would win:

"Having built a variety of apps, I now have some template or framework that I can copy from a previous project when I start almost anything new. I use Torus, my frontend framework, for all my web projects, and I have a template I copy for my backend projects and static sites. I have a lightweight slap-on CSS library for making things look good with low effort with blocks.css, and these templates and copy-paste snippets make getting started super quick, even with fairly involved projects. I was only able to release RecruitBot in 6 hours because I could lean on both my frontend framework and a backend I copy-pasted from Studybuddy, and because I could easily deploy it on a server I had available for my projects. This might not be the most glamorous approach to starting new projects, but it gets me up and running quickly with a new idea, and that matters more than anything at the start. Having these battle-tested tools that I’ve used over and over again within easy reach has been the single most helpful thing in being able to push out MVPs and prototypes quickly."

I've been using my own super minimal unit testing framework for all of my personal projects for about 2 years (https://gitlab.com/distilled/distilled/tree/develop). It's designed to be very flexible, and very, very fast to get up and running -- for new projects I want to be able to start writing unit tests within 30s to a minute after calling `npm init`.

As far as I know I'm the only person who currently uses it, but it's saved me so much time that even if I'm the only person who ever uses it, it'll have been well worth the effort I spent writing it.

I'm working on a similar project for documentation generation (https://gitlab.com/dormouse/dormouse/), and I expect that to be the same deal -- I'll probably be the only person who uses it, but I don't care because it'll pay for itself just from the time it saves me.

Part of the advantage of having your own frameworks that you tightly control and understand is that they can be more specific to what you need. It's a tough balance -- I don't advise people to constantly reinvent the wheel, but occasionally existing wheels are really badly designed (looking at you esdoc), and in those cases it's often less work to reinvent the wheel than it is to use a misshapen wheel forever.

I've been toying with the idea of creating my own lightweight JS and CSS framework so I can achieve similar levels of productivity. I know it varies between people but I find using third-party frameworks slows me down more often than not when I want to quickly build something.

I wonder if it is faster to learn a tool deeply than to build your own.

The advantage of building your own is that you are forced to go over every piece of it. However, if there was a way to do that for a pre-written tool -- say, rewrite things more efficiently, or just use it in weird ways -- it might be faster to learn than build.

The reason it would be faster/better to learn a tool deeply is now you have more than one mind working on the problem. Your own and all the other geniuses out there working on the tool. And the tool can be simple. (Just use Torus, for instance).

I think there's truth to both. A great example of the second kind is Chrome Devtools (or firebug, or insert-other-browser-equivalent-here, but I think Chrome leads the pack here). Chrome's developer tools is a gold mine of incredibly useful tools for profiling, measuring, and understanding complex frontend applications, and most developers only use a tiny fraction of the features it offers. Learning devtools deeply has been one of the most worthwhile investments of my time in my short dev career.

But the reason I lean towards build-your-own is that, especially for libraries and dependencies, popular tools that are "production-ready" also tend to aggregate over time features that everybody wants, but might not be useful to me personally -- it's hard to stay focused while growing to be the dominant tool in the industry. And that also makes it difficult to understand it completely. I think I understand React _well_, but wouldn't dare say I understand it completely; I can confidently say I understand every single line of Torus, because I maintain all ~1000 lines of it. And that makes it easier to stay in "the flow" when working.

I am currently in the process of doing something similar: https://github.com/CarlMungazi/aprender-js

Once I'm done, I'm probably going to have a proper crack and either building my own tool or collating smaller libraries (and by small I mean they do one thing only and do it very well) into a toolkit I can build stuff very quickly with.

I think the knowledge gained by building your own tool (CSS library, UI framework, state management library etc) seeps into any work you do with other tools or programming in general. It also depends on your aim. You will be more productive using whatever approach you spend time learning deeply.

Boy have I got a treat for you -- or maybe not if you're very knowledgeable in the space -- but this is an amazing course for walking you through the main functions of a framework and the code for some major frameworks:


I am not associated with Udacity, but I love them so much I promote them every chance I get.

Nice - will check it out if I ever get the time.

I would imagine rolling your own also puts you at significant risk of being distracted by yak-shaving.

I've done lots of side projects over the years.[1]

The things that stand out for me in staying sane working on them, and occassionally getting them done are

1. the most important thing: prototype end-to-end user workflows to prove out that the idea is a good one AND that it's technically possible -- you'll discover lots of technical issues you'll need to go solve when do this (put them in the to-do list mentioned later). Don't over-design anything at this point. Just make it work. Be okay with rough code or experiences. Get the idea working and it'll be a great motivator. Likewise, if you get a rough experience working and realize it's not a great idea, you can move on and do something else!

2. make the project easy to leave and come back to (see next two items).

3. create TODOs.md markdown file in the project and just add items as you go along. This is your source of truth of what to work on next. Don't use any fancy task-tracking service or app, just a simple markdown is good enough. And it should live with the project so you can read it and see what's next.

4. always have a "next task" that you are working on. Don't focus on too many tasks at once b/c you will get overwhelmed and give up. When you are looking for a fun design to think about when you're going for a walk, you can think about this next task.

5. be okay with leaving the project for a while (months, or years). You can always come back to it if you want.

6. don't stress about how quickly you're making progress. Do it for fun.

[1] https://www.ussherpress.com/

Author here -- was hoping to be on HN for my post on exploring sorting algorithms with 2D visualizations [1], but I guess this works too. Glad a lot of the points here resonates with the crowd.

[1] https://dotink.co/posts/visualizing-sorting-algorithms/

Moving all my side projects from Heroku, netlify, Lambda, hyper.sh & S3 to a personal Kubernetes cluster hosted on GKE has been a huge help for me in actually getting my projects out the door.

I'm the only user for almost all my projects though.

One thing that I'm trying to internalize is when you're building a side project/rapid prototype, you need to be lenient on adhering to best practices. Here's a good video from Startup School that shows technical cofounders answering the best practices vs. speed question: https://youtu.be/tSW-GePDwn4?t=1365

They talk about not having unit tests, or CI/CD, etc.

Core functionality first, polish later.

If functional utility is found you'll continue to garner an audience. Otherwise you're polishing something people don't want/need.

> “FreeBusy”, a web app that allows people to find a time that’s open on my calendar and suggest or schedule a meeting time quickly without email back-and-forths.

Heard of Calendly?

> “Gestural”, a JavaScript library for making multi-touch gesture recognition easy on the web.

Heard of Hammer.js?

Yep, and yep. I've looked at Calendly, but there's a certain kind of joy to making your own, perfectly-fit solution to simple problems. I've also looked at Hammer.js and actually really like what they've done with the project. Again, I wanted something that better integrated with other libraries I've written.

Just because a project exists doesn’t mean you can’t have your own take on it. A lot of projects basically do the same. Just look at all the ride sharing apps.

Yes. That's pretty obvious, thanks.

See https://news.ycombinator.com/item?id=20572020

What happened after Basecamp got big or simpler CRMs than Salesforce became a thing? Many many overlapping products came out. Nothing wrong with that.

Yes. I know. I just didn't know whether or not the OP had heard of these things. From their comment it seemed as though they just wanted to solve the problem that Calendly solves for themselves. If I were jotting down side project ideas, I would have written "I'd like to make something like Calendly, but with x, y, and z changes."

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact