<title>How I side project.ink</title><link rel="canonical" href="https://dotink.co/posts/how-i-side-project/" />

<ul>
<li>It used to take me hours to get everything set up to deploy a project, from getting a domain to setting up DNS, finding a server, getting all the configurations right, and so on. These days, depending on the kind of project, I can deploy it within seconds or minutes of it being done. I don’t need to think about it these days, and it’s mostly due to repetition and practice that I’ve gotten to this point. I use <a href="https://surge.sh">Surge.sh</a> for static deploys, (Zeit Now)(<a href="https://zeit.co">https://zeit.co</a>) for serverless deployments, and my custom server infrastructure on <a href="https://digitalocean.com">DigitalOcean</a> for more heavyweight apps and services.</li>
<li>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 <a href="https://github.com/thesephist/torus">Torus</a>, 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 <a href="https://github.com/calhacks/recruitbot">RecruitBot</a> 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.</li>
<li>Use a consistent set of small tools, and know it well. Some people use side projects to learn a galaxy of different tools and frameworks and libraries, which is great for them. But I don’t really work that way, and I’ve come to use a really small set of tools and libraries for all of my projects. As a benefit of using a consistent set of tools, I’ve come to know all the tools I use <em>very well</em>. If anything goes wrong, chances are, I’ve probably seen and solved the problem before, and I can probably fix it with a single Google search at most. Besides the ones mentioned above, these tool are Vim and Tmux for text editing and working in the command line, Chrome Developer Tools for web development, telnet, curl, dig, and whois for troubleshooting network issues, and Adobe XD for UI prototyping and design, when I need it.

<ul>
<li>This is also one of the reasons I enjoy working with tools I write myself, like Torus and Ink, rather than using other heavyweight libraries or languages – if something’s broken, I can just dive into the source code of the framework or language I’m using and figure out what exactly is going on, because I wrote it!</li>
</ul></li>
</ul>

<h3 id="embrace-the-rough-prototype">Embrace the rough prototype</h3>

<p>The first working version of <em>anything</em> is <em>rough</em>. It’s ugly. It works, but just barely, and it’s fragile, and it’s so satisfying. Here’s a glimpse into those moments from the last week.</p>

<p>This is a 2-by-2-pixel image that I rendered by manually writing each byte to a file in the BMP image format.</p>

<p><blockquote class="twitter-tweet" data-lang="en"><p lang="en" dir="ltr">Current state of affairs:<br><br>In just under 100 lines of Ink code…. <a href="https://t.co/PXZqh5PxI8">pic.twitter.com/PXZqh5PxI8</a></p>— Linus (@thesephist) <a href="https://twitter.com/thesephist/status/1151420325462102016?ref_src=twsrc%5Etfw">July 17, 2019</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></p>

<p>Here, I’ve just managed to render a blurry, blotchy black-and-white image of a Mandelbrot set. I’d go on to polish the algorithm here to render a full-color 1080p image later that night.</p>

<p><blockquote class="twitter-tweet" data-conversation="none" data-lang="en"><p lang="en" dir="ltr">~67 lines of Ink, and we have the first glimpse of a picture!<br><br>Took most of the last hour troubleshooting a sign error. Smh. <a href="https://t.co/59WnSqo80P">pic.twitter.com/59WnSqo80P</a></p>— Linus (@thesephist) <a href="https://twitter.com/thesephist/status/1152098082642808832?ref_src=twsrc%5Etfw">July 19, 2019</a></blockquote>
<script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script></p>

<p>I’ve been trying to share more and more of my projects at this early “it’s kind of mostly working, but only sometimes” stage. I think this is the most satisfying part of early-stage projects. Until this point, I’ve been working on it fueled purely by the hopes and guesses at whether the project idea would pan out, but once I hit this point, it’s easy to see how I could iterate my way to a prettier, smoother, more high-quality, more stable solution. It’s the tipping point – the rough prototype.</p>

<p>Sometimes, I’d be fueled by this moment to keep going, but this is also a safe point to stop and pause, catch up on sleep, get to that meeting I’ve been pushing back, or whatever else. It’s safe to take a break here, because I’ve hit that tipping point, and I know I can pick things right back up when I return, because there’s something already working. But until I get to this point, it feels like an endless sprint.</p>

<p>Once I have the rough, working prototype, it’s also a good time to reflect and refactor or rewrite my initial implementation of something. <a href="https://github.com/thesephist/torus/blob/master/src/jdom.js">Torus’s HTML parser</a> went through a big rewrite a week into the project, because I thought of a much faster, less bug-prone design. But I couldn’t take risks in rewriting the parser until it was at least complete.</p>

<p>No matter the project, the bottom line is, if I get to this rough prototype point, I’ve done it. There is a thing that does a thing, and sometimes, that’s enough of a starting point to feel like it’s 80% done.</p>

<h3 id="don-t-be-shy-about-giving-up">Don’t be shy about giving up</h3>

<p>If you’ve scrolled through my GitHub repository list or my <a href="https://linus.zone/projects">unofficial-official personal projects directory</a>, you’ll know that for every project I’ve “launched” or finished, there’s a graveyard of things I’ve attempted but given up on. I used to be more troubled by that ratio, but I’m less bothered by it these days.</p>

<p>I think when it comes to personal projects, some ratio of finished- to abandoned-projects is a sign that I’m experimenting and playing around with ideas, and more importantly, that I’m prioritizing judiciously and saying no to things when it doesn’t make sense to keep pushing forward on a project that isn’t feeling productive or interesting to me anymore. Heck, I have, like, four different versions of a to-do list manager I’ve attempted and I haven’t got a single working version yet. That’s a bit annoying, but I think that’s fine.</p>

<p>While giving up or stopping work on projects isn’t problematic, I do think it’s important to find or study what went wrong at each instance and try to avoid the same miscalculation in the future. The tricks I outlined above, about how I try to work on an idea the same day it pops into my head, staying consistent with tools, and so on – these tricks are the result of thinking about why some projects didn’t work out in the end, and considering how I could avoid the same problems in the future.</p>

<h3 id="make-it-easy-to-iterate">Make it easy to iterate</h3>

<p>As I’ve been steadily growing my zoo of active projects, I’ve been learning to place a greater emphasis on easy maintenance and iteration. In a word, this means making it easily to monitor when things are up and things go down, making it quick to push out updates, to find out what’s going wrong, to restore from a backup with minimal effort, and to hit the reset button when something inexplicably explodes without notice.</p>

<p>When I had one or two running projects, if one went down or lost some data, I could just go in, restart it, may be fix a bug that day. But I have more projects in actively operation these days than I can keep in my head, and it’s become increasingly important that I figure out the “ops” side of things. I may go into a deeper dive on my personal ops and infrastructure (Tweet at me if you’d like to read about that), but for here, suffice it to say that I’ve written many a scripts and automation configurations so that I can backup, restore, push out updates, and run tests against changes easily for all of the breakable projects I have running. DigitalOcean’s easy backups has been really helpful here, as well as learning some basic shell scripting and automated testing.</p>

<h3 id="be-ambitious-not-comfortable">Be ambitious, not comfortable</h3>

<p>My most successful projects have been, without question, the ones that I’ve attempted with <em>absolutely no clue</em> on where I would even start.</p>

<p>When I began working on Apogee, a Chrome extension to cite webpages that ended up growing to about a quarter million users, I could barely write working JavaScript. The first thing I did that night was Google search “how to make a chrome extension”. When I started writing Torus, I had used frameworks like Backbone before, but had no clue how I would go about writing my own. And my latest pet project, <a href="https://github.com/thesephist/ink">Ink</a> started when I barely knew what parsers were, let alone understand how interpreters and compilers worked deep under the hood.</p>

<p>I compensated for these holes in my knowledge with two useful skills: typing quickly and precisely into Google Search, and not being afraid of reading and re-reading things I didn’t fully understand until I did. For the Ink project in particular, for the last month, I’ve probably been reading 1000-2000 words per day on compilers, language design, garbage collectors, memory management, and a bunch of other related topics. I’m still confused about lots of things, but I have a <em>far</em> better understanding of what’s going on on my computer than I did prior, and I have a mental compass for what topics I should poke into next. (In particular, big thanks to <a href="http://craftinginterpreters.com/contents.html">Crafting Interpreters</a>, which was invaluable in initially figuring out where the heck I was even supposed to start.)</p>

<p><strong>Err on the side of being too ambitious, and don’t worry about starting in your comfort zone.</strong> I find that the most satisfying, interesting, fulfilling projects are the ones where I had to find and draw the map as I went.</p>

<h3 id="sharing">Sharing</h3>

<p>Lastly, I’d like to do more of what I’m doing right now – sharing, talking about what I’m working on and what I’m learning, what’s interesting and surprising, and occasionally, about how I work personally and what makes my schedule tick, if it’s interesting to you.</p>

<p>It surprises me what kinds of projects people find interesting. Sounds from Places wasn’t technically interesting at all – just a static site linking to some MP3 files – but that received the warmest reception online that I’ve had for any project except Lyrics.rip. Neither project was technically challenging or involved brilliant strokes of insight, but I think they were artistically interesting and fun ideas, and that seems to be what sparks people’s imaginations more than custom programming languages or frontend frameworks.</p>

<p>I like to joke that, in an alternate timeline, my dream career would to be move to LA to become a professional concert pianist and composer. I’m constantly amazed by what art can communicate – well-crafted art doesn’t necessarily communicate technical knowledge or know-how, but it begs interesting questions and opens up people’s imaginations in unexpected ways.</p>

<p>Even as my personal projects continue to be a way for me to learn and experiment with technologies, I hope I can get to a point where I can also build things that go beyond that, to be tools that artists can use to tell better stories or find better media for their ideas, or even to open up new and interesting questions altogether.</p>

<p>At any rate, I’ll keep hacking and sharing, and I appreciate you being here to tune in when things get interesting.</p>

    <hr/>    <p>        If you enjoyed this piece, you might also enjoy        my next post,        <a href="https://dotink.co/posts/visualizing-sorting-algorithms/"><em>Visualizing and exploring sorting algorithms in two dimensions with Ink</em></a>.    </p></article>

</main>

<footer><div class="overlay">    <div class="left">        <p>- Linus</p>    </div>    <div class="right">        <span class="square"></span>    </div></div>

</footer>

</body>