Build what you want to use.

You know, it's like, make the film you want to make, not the film you think you ought to make, right? 'Cause I think when people make things in a cynical way, like "oh this genre's hot now, let's do this," and they're not really that invested in it, you can tell, you know?

-- Edgar Wright

I alluded to this topic previously, when I talked at length about Web scraping, but this should be more straightforward than that. You should... you know, build what you want to use. You should also fix the things you want to use (where you can), if you're not already in a habit of doing that. The Internet is full of pieces about how to build a Pinterest clone, or a chat application, or some third thing... But we're going to talk about a good way to avoid drowning in tutorial hell. And that's by solving for problems you, personally, have.

If you want to avoid getting lost in a spiral of dwindling motivation, build something that will actually improve your life.

You should also know that I'm writing this, I'm reading it in Ron Swanson's voice. Naturally this isn't the most literally mechanical of discussions, and won't be nearly that succinct, but hopefully you're already starting to see a little of why.

(...it's also because I finished a first watch of Parks and Rec shortly before I wrote the initial draft.)

Annoyance driven hacks development

(Oblitagory disclaimer -- I was a Ritalin child and am in fact allowed to make that joke.)

'80s Guy: Listen, big guy, now that you're my protégé, it's time I cut you in on the secret to success. Any guesses?

Fry: Work really, really hard?

'80s Guy: No.

Fry: Oh, thank god!

-- Futurama, "Future Stock"

If it's a problem you personally have, then it's a problem you personally care about. The issue with glorifying hard work on its own is that whether you worked hard is different from whether your hard work tangibly benefits anyone. Even if you're not like me -- an escapee of Christian fundamentalism, whose schooling mostly came from firm believers in the Puritan work ethic -- I'd be willing to bet you've heard your teachers rationalize about this. About how there's no value to shortcuts, or how working during your off hours is somehow a reasonable expectation, how work will "teach responsibility" even if it doesn't do anything else, or how the use of modern technology is cheating... I mean, mine told me I'd use cursive in real life.

(Dating myself, I guess, but it's about how old your ideas are. Which is the point, because...)

I reject this viewpoint, enthusiastically. I am, of course, a tech worker, and while hard work has its place in actually solving problems, fundamentally, technology exists so that you can work less hard. At a certain point, bruteforcing everything stops making you virtuous and starts making you bad at your job.

In real life, and especially in this line of work, hard work purely for hard work's sake can easily be a bad thing.

The enforced realities of capitalism aside, it's important that, at least sometimes, you're building something that personally matters to you.

Building the things you want to use means your work, hard or otherwise, has an express goal of benefitting you. Spending too much time on job searches? Build a crawler to get your listings for you. Want to track a more specific kind of workout than a typical app for this will give you? Seems like you've got a good excuse to dig around about CRUD APIs. Or maybe you just have a large quantity of files you need to manipulate -- whether you're just moving them around, running a CLI tool to convert them to a different format, or even mining custom text formats for metadata after also converting them from an older format.

Now you have a reason to pick up something new, and you're not just doing it so you can say you know whatever hot new tech is trending in [CURRENT YEAR]. These can still totally be excuses to do that, but now they have a point beyond just learning exercises or pRoFeSsioNaL gRoWtH or whatever. I'd even go so far as to argue that having an actual purpose behind it benefits you more as a professional -- you have to also define the specific nature of what your problem is, and what the threshold is for considering it "solved." You can do this without having to wrangle a bunch of external stakeholders, because you -- uniquely -- know what considerations and constraints have to go into that definition. This is a useful springboard into other ancillary topics around project and product management (not that I especially consider either of these to be my wheelhouse) -- you have total freedom for defining your "product" requirements, because you are your target userbase.

You also don't have to go free-form with this. Tutorials can still be useful points of reference, since your problem may still be similar enough to something that already exists that it can act as an overall guideline for what sort of functionality you might need and how you could implement some of it. You're not going to be reinventing any wheels by, say, implementing user logins. Your entire project may even just be a niche-focused of something that has a full tutorial. Say, "build a workout tracker," but specifically for Dance Dance Revolution. (I didn't actually use a reference for this, but you get my point.) Further, it's also an excuse to play around with various kinds of project methodologies. Personally I've gotten reasonably good results out of Scrum but the entire point of this is to figure out what works for you, personally. You can even do it with things you do pick up on the job. I did this with Scrum, and accidentally found myself building a Kanban board for the lighting project I was working on. Or vice versa -- fixing the papercuts you encounter on the job can be an excuse to experiment with something new while making your own life (and sometimes other people's) easier.

(To be clear, though, I wouldn't recommend working in professional settings where this is frequently required. It's bad for consistent testing if your product team doesn't tell you, to a reasonable degree, what the required behavior is up front. It's bad for workplace accessibility to require extra organziational tasks in a line of work that attracts neurodivergents at double the rate of other professions. It's also... the job of managers to actually tell you what they expect of you. But it's also key to understand that this is about building skillsets that go beyond your job.)

A DIY habit will enhance your life, by making you more self-sufficient. You know what's even better than knowing a good repair tech who can help you out with your electronic woes in an emergency? Not needing one, because you are the pasta maker... I mean repair tech.

UNIQUE SKILL ACQUIRED...

Ok, but how else will it enhance my life?

Glad you asked, minds of those reading this.

It can save you money. It's not just that you don't need to depend on repair techs. It also changes your relationships with vendors. If you, for instance, have soldered the panel of a DDR pad back together, you can also wire up custom light controllers, flash them with something like WLED and have the RGBedroom of your dreams without having to be tied to someone else's services. And you can do this with a lot of things... Run a local AI chatbot, and use it to teach you something else. Grab an old Android device in your junk drawer and load it with an aftermarket image like LineageOS and a bunch of free apps from F-Droid. Setup your own network storage, with a big drive and a single-board computer like a Raspberry Pi. Stream from it on your other devices using tools like Kodi. Setup file sync so you can keep files stored locally on the go.

These are all off the cuff exmaples, that mostly don't require an extensive amount of time or hardware, but the other important thread they share is that these are all things you can run on device. They don't even just save you money; they take back a little bit of your freedom and your privacy from big tech conglomerates.

And just as importantly, sometimes we can't save money -- because while there are tradeoffs to each side of the "build vs buy" argument, buying isn't always an option. Sometimes the thing you want to use just doesn't exist. Sometimes it isn't enough to just say "I did rhythm games at X difficulty for Y time." Sometimes you need to be able to stash every arcade track from Dance Dance Revolution into a database, to then also reference them when logging setlists -- because you're just really tired of looking them up and storing them in plain text, and it's not actually a useful metric of progress when you do.

And sometimes you've got less frivolous use cases, where you save meaningful amounts of time, effort and aggravation. Like doomscrolling job boards.

I already can't count the hours I've also gained back from:

All while (roughly) tripling my outreach volume, specifically because I'm not getting distracted by the various time sinks in this process.

You can also use it to make money. Your DIY habit will build you other tangible skills, depending on your use case, that you can then show off to future employers. For instance -- those lights I mentioned also integrated into a unified control interface that later became my first exposure to Docker. Building DIY projects can also entail building on-ramps to other DIY projects. My Web scraping writeup, for instance, ballooned to the size it is because I kept finding additional use cases. It also periodically leads to conversations about freelance work, has been something I've been able to show off in technical interviews, and amusingly even turned up one job that required me to solve a CTF -- using a nearly identical fetch loop -- to submit the application. (Some of the utility functions were outright copy-pastes, even.)

Ego driven development

You might be reading that and wondering, "wait a minute... didn't you just spend several months and 10000 words building a scraping bot with as few external tools as possible?"

I'm not saying that I didn't make this harder than it needed to be, or that I never do that. There's value in showing off sometimes, after all, and doing something hard can be impressive.

"Hard" is also relative. Constraints can be useful for keeping yourself from trying to do to many things at once, and learning lower-level tooling means you don't need to relearn this later in some new framework, even if you do have to implement a bit more yourself.

There's value in, for instance, just getting really comfortable with using Markdown for content, and hand-rolling as much of your CSS as possible. Like I did for the site you're reading right now! And have been for the tracker I've been working on. Because while this too is a constraint, the Web is forward compatible. The CSS you learn now will continue to work later, and so will the HTML that Markdown converts back to. These aren't equivalent, I realize -- Markdown is more of a loose collection of supersets than a spec, and so for CSS we'd be talking about something like Sass. But either is lower level than using a UI library like Bootstrap or Tailwind. And I'd personally argue Markdown is more of its own language -- a document format aimed at readability in plain text, and not purely a way of composing cleaner Web content. This one also has discrete, functional utility beyond that: stripping out extra structure from the source HTML shrinks it substantially, which will matter if you store a lot of it. And by removing structure that will vary across sources, you can check them against each other to do things like duplicate post detection.

Importantly, though -- and I at least think I've been pretty clear on this by now -- there's zero reason that the benefit to you can't just be that you're doing something because it's fun.

I also didn't have to start tinkering on code-driven synths. But aside from being able to show off a fresh knowledge of Ruby a bit, it also meant not getting bogged down with several research dives on various DAWs, even if it did briefly get me bogged down figuring out how to track drums. (And while I can feel some of the recording tech knowledge resurfacing the more I do this, that also skewed more toward live instruments.) And having something where you're not so overwhelmed with options that you're flipping through virtual instruments like it's Netflix can be just the right amount of constraint that you can focus on the part that you actually enjoy.

It's fun to wire up customized lights. It's fun to show off scratch-built swipe effects. It's fun to use these things and know that you made them, and that you know how to maintain or repair or extend them if you need to.

A good DIY habit will leave you something meaningful to show for it. That something could still be a bit of an intangible, and it could literally just be something cool to show off. But sometimes it'll give you something useful. Sometimes it'll give you a whole career path.

And as much as this is a bit of a lie -- because the Internet is of course a network, and even if you wander it in a solitary manner it's still full of other users (at least for now) -- maybe it'll leave you with some sense of...

I don't know, wired individualism?