The Tool Trap

Quilters, woodworkers, programmers, writers, singers, and gamers. These people all do something different, yet there’s one thing bringing all of them, all of us, together. The one thing we can all agree on. We want more tools.

We want more tools and we want better tools. We want better computers, better cameras, better rigs. We want a new keyboard, a new display, a new pen. New wheels, new parts, new boards, new needles, and new threads. Only then we will finally get to do what we want.

After those first two paragraphs, you probably expect me to tell you tools aren’t actually that important. Or that they’re just another way we fool ourselves into unhappiness. Sorry, not today. Tools are important.

Without tools, you can’t get your craft done. Full stop. A writer without a pen can’t write, a programmer without a keyboard can’t code. Anyone telling you tools don’t matter is fooling you. You’ll usually hear it from the people who do have the tools. They don’t remember what it’s like not to have them.

If you use a keyboard 10 hours a day, it’s worth investing money into a good keyboard. If you get income, or joy, from singing, it’s worth getting that microphone. Tools enhance your work, and make a serious difference. Tools amplify your craft multiple times over.

That said, tools won’t change you. We buy shinier tools thinking they’ll help us change who we are. And this is the tool trap. They don’t. Better tools make your craft better, but they won’t make you better.

I fell for the trap many times over, and got overpriced tools for nothing. Maybe you can relate. My computer is painfully slow, for example, so I thought getting access to a new one would instantly make me stick to a weekly schedule of new YouTube videos. It didn’t. I wasn’t making videos before, and I’m not making videos now.

If I were into making videos in the first place, then yes, it would have made sense to upgrade. The new computer would have made my craft better. But if you’re not interested in something in the first place, a new tool won’t do it.

I find it useful to keep this heuristic in mind whenever I feel like buying something new: Will it help me change my craft, or am I hoping it will change me instead? If it’s the latter, then, close the tab and move on.

Zero to Web Dev: Beginnings

At its core, trms is the journal of a generalist. And what generalists do best is starting new things. So here I am starting something (relatively) new. I’ve never used purple before in one of my header images so you know this is a big deal.

I always believed I wasn’t smart enough to do programming. I did go to a CS-oriented high school, and we did learn some Java and x86 assembly there, but I wasn’t great at it, and when it came time to go to university, I chose not to pursue things further. Looking back, that was pretty silly. But hindsight is 20/20, and I was just 18. So here’s my attempt at setting things straight.

For a couple of months now I’ve been diving into the world of web development, devoting nearly all of my free time to it. So I wanted to share my journey with you.

This post won’t go into the nitty-gritty details, instead it’ll be more of an overview showing what I’ve done so far. I’d like to make more detailed posts going through everything I do, such as particular challenges, tough parts, etc, but now, since I’m writing a post covering about a month or two of work, that would make it way too long. Let’s start.

Prior Experience


If you’ve ever looked to learn web development, or even software development in general, it’s likely people told you about freeCodeCamp. It’s a free… code camp that teaches you web development, and a couple other things. It boasts thousands of hours of content and shiny certifications. So some years ago I went for it, and even got the first certification.

Will I continue with it now that I’m picking programming up again? No. I originally wrote many paragraphs here explaining why not but that’s out of place here. In short there’s nothing wrong with FCC per se, it’s just not for me for now. I might go back to it in the future though to grab some extra certifications, why not.

Some Random Stuff

For a while I was into making small scripts for virtual retro consoles like TIC-80. I made some and it was fun, but that was it.

Back in 2017 I taught myself some Python and I made a Telegram Messenger bot with it for a group I have there. It was actually pretty neat and we are still using it four years later. The code is super messy though and I’m surprised it’s lasting as long as it does. It’s basically a castle made out of popsicle sticks.

The Plan

The plan is to go through some sort of linear online course and follow it, but to then start making small projects as soon as I feel capable, even outside of the course. I’d like to also contribute in some small way to open source projects, as soon as I can do so without annoying the maintainers too much.

I believe the best way to learn is to do projects on your own. But you do need to get the basics from somewhere, so I’ll use the course(s) as a foundation, as a rail I can follow when I feel I need to move further ahead. After all I can’t learn if I don’t even know what to learn.

The Journey / The Projects

The Odin Project

I chose to go with The Odin Project to learn/revise the foundations of web development. Odin is an open source online course, maintained by volunteers, aiming to get you from zero to web developer. That sounded pretty good, so I went through and finished their foundations course.

Odin is mostly an aggregator of resources rather than a fully original course. Each lesson is a collection of external links to articles and videos. Occasionally, Odin contributors will write a lesson up themselves, but that’s rare. This is both great and not so great.

It’s great because it allows Odin to focus on organizing the flow of the course rather than having to maintain a huge amount of text. It’s not so great because by learning this way, you are switching teachers/teaching styles constantly. There is no cohesion, and each post assumes a different background. There is a bit of context switching to do before moving on to each new resource. But it’s not such a big deal.

TOP intersperses lessons with practical projects. I liked that. The projects are actually challenging and require you to Google for stuff, which, it seems, it’s what development looks like in the real world anyway.

TOP starts with a couple of sections dedicated to setting up your machine and things like learning how Git works, for example. They don’t provide you with an in-browser text editor, they make you go through installing and setting up a development environment on your own machine first. This, I found brilliant and useful. It’s great to use the actual tools of the trade right from the start.


Odin then gets you to do some HTML. Since I had experience with basic HTML and CSS before, I flew through this one and quickly completed their first project: the Recipes website. Moving on.


After having you go through a series on CSS and the CSS Flexbox (which I found super useful), they have you do another project. This time, they show you a picture of a landing page, and you have to recreate it yourself using only HTML and CSS. Here’s my result.

I really enjoyed doing this project since it applied everything I learned before, and it didn’t hand-hold me so much. They pretty much just give you the picture and tell you to replicate it, which felt like an accomplishment when I finished it.



This section of the foundation course was the most challenging but also the most rewarding. Some courses teach you frameworks immediately, but Odin starts by teaching you how to manipulate what you see on the webpage with pure JavaScript. After a couple of short lessons, you’re thrown in the deep end making an etch-a-sketch-like small web app. Here’s my result. This project wasn’t without its challenges, but overall it was doable. Which means it was just the right difficulty.


As soon as you’re done with that, you’re hit with another project: this time, you’ll make a calculator. That was a bit harder than I initially thought since I hadn’t thought of a lot of edge cases (e.g. what if a user presses the “=” button at random times? Or the “X” button? Things like that.) Once I figured those out (which, admittedly, did take a while) here’s the final result. It turned out alright.


So, that was the foundations course done. Overall, it wasn’t too bad. I started with some pre-existing knowledge of HTML and CSS, and I ended up making a functional calculator show up on a web page.

I selected Odin’s next course (Full Stack Javascript) and moved on. This course is packed much tighter, and it has a ton more content. You’re taught a lesson on JS objects then you’re thrown another challenge: the library.

This is the project that, so far, took me the most time and effort. There were times when I had to step away from the code for a while and just let my mind rest for a bit to figure out what to do next or how to solve some particular problem.

The worst thing about programming for me, so far, is that once you find the solution to your problem, you realize how obvious it was the entire time, and it makes you feel a bit dum-dum. But I suppose that’s just how it is.

So here’s the final result for the library project. You’re basically tasked to make a “library” website where people can add books to their shelf, toggle their read status, and remove them. You’re given some guidance, but it’s very minimal. Overall, I think it really pushed me, but it was worth it. Pairing the buttons you see on screen to their own “card” was a challenge. Also, I couldn’t make a nice dialog box to insert the new books, instead I’m using browser prompts, which is kind of annoying. But it’s good enough to pass for now.

Thoughts / Things I Learned So Far

Since I have a full time job I can’t go quite as fast as I’d like, but I’m trusting that doing something every day, no matter how small, will eventually get me there. Also, even if I could go faster, I’m afraid I might burn out, so I’d rather take things at a leisurely pace and enjoy the ride.

Overall, I went from little knowledge of web development to making some small yet interesting projects, such as the landing page, the calculator, and the library. That’s something. I do wonder how larger projects are done and managed, so that curiosity pumps me up for the future.

I do feel that being in a community, or in a classroom with other people struggling with your same problems, would help out. Not just in solving the actual problems, but for motivation, too. I am aware that Odin and pretty much every course has a Discord server, but I’m not too comfortable just introducing myself to a number of complete strangers and getting into the community, especially when the communities are of thousands of members, and most people are just there to seek help and nothing more. I wouldn’t want to be a burden on those five people who actually help others out, but who are already stretched thin due to the amount of newbies coming in.

I think web development in general has been moving extremely fast these last couple of years. This is great, since there is progress, but it also makes online articles/tutorials obsolete really quickly. Online courses try to keep up, but random blog posts might not be so useful if they’re even just 1-2 years old. This is in contrast with other areas of software development where things basically froze.

Sometimes Odin is behind the curve, recommending articles from 2012, and in this respect, the Fullstack Open course from the University of Helsinki does seem to be much more up to date. But that’s for the next episode.

You can find me on GitHub here. If you’re a dev, or just into this type of thing, I’d love to hear from you. Maybe we can help each other out.

The Curse of Preparation

There are two kinds of people. One doesn’t start doing something unless they think they are fully prepared. Others just start doing stuff, then figure it out along the way. You should aim to be in this second group. If you are in the first, welcome. Read on.

I’m sure you know some people like that. Someone you know has done something way before they were “ready.” They opened a business, started making content, moved country. Maybe it went well, maybe it didn’t. But they did it anyway.

You see, the problem with people like us is that we overestimate the cost of failure and underestimate the cost of preparation. It’s counterintuitive, but preparing, in most cases, is more expensive than failing.

When you prepare, you are delaying the actual start of your project. And time, sadly, is a one-way road. Each day spent not working on your project is a day you could have. When time is so limited, each passing day becomes more and more expensive. You know what I’m talking about: when you were a kid, or in school, days were nothing. You probably felt no guilt wasting en entire week. Now, when work takes away your most precious hours, and the clock ticks, every minute counts. And it’s not going to get better.

The most compelling argument against preparation though is that the real preparation is in the doing. People learn how to drive a car by driving a car. They learn how to shoot an arrow by shooting an arrow. Yet, we think we can prepare for our projects by reading up on them. That’s like thinking the best way to learn to swim is to read a book about swimming.

Creating is a skill, just like driving and shooting arrows. The only rational and effective way to get good at creating is to start creating.

When you first drove a car, you weren’t good. You knew there were risks involved. Yet you did it anyway, and now it’s second nature to you. The first time you create it’s not going to be good. There are risks involved. But if you do it anyway, it too will become second nature to you. And by create I mean anything from writing a paragraph to finally starting your business.

People like us think failure is the end of the road. We think failure is a cost too heavy to burden. But to fail is to prepare. We imagine in our head Micheal Phelps just jumping in the water and being the absolute best from day one. Or we imagine Mark Zuckerberg pouring over PHP books for 20 years before starting to write a single line of Facebook. But those are constructs of our head, pushing us to prepare so we avoid doing the actual work. They are far from the truth.

If you do something then succeed, great: you got what you wanted. If you do something then fail, also great: you learned a lot so that you can succeed next time.

You don’t get ready then start. You start then get ready.

Stuck in Generalist Hell

They say you should write about the question that’s burning in your mind. So here’s mine: is there a generalist hell? And am I stuck in it?

When saying the word generalist, you’ll get one of two reactions. The first is “jack of all trades, master of none,” a negative take on generalism defended, for example, by Jeff Atwood.

This view seems to circulate the most in techie/engineering rings. Just yesterday I was browsing Hacker News when I came across a comment that went “being a generalist is worse than useless — i would not advise it.” That’s just one example.

The other view is Naval Ravikant’s, mimicking Heinlein:

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, […] program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

Robert Heinlein

So which is it?

Readers of my blog and people who know me know: I am undoubtedly a generalist. In this blog alone I’ve talked about topics ranging from knowledge management to typographyhabitswritingenergystartupsproductivitytypesetting, and more. Outside of the blog I’ve sold my own software, I’ve taken up marketing and sales roles, I’m the sole technical writer and QA guy at my workplace. I studied CS in high school, then got a degree in a social science. I write blog posts, did voice acting, learned and taught three languages, and wrote academic papers about Byzantine robots.1

Is this good? Maybe. There are some advantages.

In the workplace, it’s harder for people to play on your ignorance. You know approximately how long something takes to make, and you understand, at a basic level, how it works. You know enough to know whether others are doing their job or not.

Being a generalist is nearly a requirement to be an entrepreneur. You have to know how to build, and you have to know how to sell, at the minimum. And you have to know whether the people you hired are actually competent, even though you don’t have their mastery.

So why am I talking about generalist hell?

Well, for example, I’m good at marketing and sales. But if my company wanted to, they could hire a specialist who could do it better. Same thing for QA, technical writing, management, and everything else I do. My blog is no different: while I write about all these different things, you can find people who write about each specific topic better than me.

When you’re a generalist, for anything you do, there is someone who can do it better. You’re not good enough to be a full-time developer. Or a QA engineer, technical writer, blogger, academic, marketer, what have you. You’re good enough to understand it all, but not good enough to have achieved mastery in any one of them.

When applying for jobs, generalist hell comes especially alive. Being a generalist automatically excludes you from applying to any company that’s not incredibly small. The last thing a medium to large company needs is someone who can do “a bit of everything.” True, there is an advantage to showing up to smaller companies. After all you’re a person who takes the place of 4-5 others, so the savings are considerable. Eventually, though, they will outgrow you.

It seems I’m stuck between a rock and a hard place. Either I buckle down and master a skill or I become an entrepreneur. What should I do? This is the question burning in my mind.

Key Takeaways from “Hell Yeah or No” by Derek Sivers

Derek’s books, for me, are an auto-recommend. They’re the opposite of most non-fiction you can find today: small but packed super tight with ideas and insights.

Here are my takeaways from Derek’s Hell Yeah or No. I originally posted them on my Twitter but I think they are worthy of a larger audience.

If you say you want to do something but aren’t doing it yet, you don’t actually want to do it.

If you want a title, you have to earn it. And you have to keep earning it for perpetuity.

Most people don’t know why they are doing what they are doing. Once you find out what you want to do and why, focus on it and let go of everything else.

No matter what you do and how you do it, some will always say you’re wrong. Just keep plowing.

Copy shamelessly. Your voice will still shine through.

Your old self still tells you what you love and what you hate, even though you are a different person now.

Character and self-identity are built through small actions.

Find your balance between focusing on the short term and on the long term.

Say yes to what excites you, no to everything else.

It’s ok to not be useful to others all the time.

As soon as you feel addicted to something, anything, quit it cold turkey. Maintain your independence and room for growth.

In learning, working, or anything else: there is no speed limit. Go as fast as you want.

When working, you’d be surprised at how much you could accomplish if you just took it easy.

There are two best times in life: when you are completely connected, and when you are completely disconnected.

If you are facing two different options, there are likely more.

When people give you advice, they’re just giving you their winning lottery numbers. (see: Prescriptions Won’t Save You)

Early on, say yes to everything. Then pick one, and say no to everything else.

Treat Your Habits Like Meetings

The biggest problem with habits is that it’s hard to stick to them. After a while, we just stop showing up. How do we trick our brain into helping us? I have a method.

In The Value of Doing a Little I suggested only doing the bare minimum so that you’re more likely to stick with things. That works well, but often, it’s not enough. Knowing that you’ll do the bare minimum helps you get through your habit, but it’s still hard to get up from the chair and actually start. It doesn’t kick you in the butt.

Now, love them or hate them, you show up to work meetings. True, most could have been a Slack message if only communication between you was better, but you show up to them nonetheless. The meeting gets onto your calendar, you prepare for it, check the time, and show up exactly when and where you need to.

Without a valid reason, you wouldn’t be late to a meeting. You wouldn’t delay it at the last minute. And even more so, you wouldn’t just completely miss it.

That’s the power of meetings. I have a daily meeting at work every morning and I’ve never once missed it. It’s perhaps one of the most regular things in my life. By contrast, during the same period, I started about 3 different exercise regimes and many more “daily” habits that went nowhere.

What if we could harness the “showing-up” power of meetings and bring that to our habits? I’ve been trying for a while and, so far, I like the results.

I now put my “major” daily habits onto my calendar. From 8 to 8:45 AM, it’s exercise time. That’s my meeting with exercising. I know it, and my partner knows it. At 8 AM, I need to show up. If I don’t, I need a really good reason. Just like I wouldn’t skip a work meeting, I wouldn’t skip this one.

My partner studies Italian from 11 AM to 12. She puts her devices on do not disturb and at 11 AM she’s in front of her computer and shows up to her meeting with Italian.

It’s so good that, to me, it almost feels like a superpower. My brain made a strong connection between the concept of “meeting” and “showing up consistently”, so this trick effectively hijacks this connection for my own good.

Want steps to do? It’s simple:

  1. Add your habit to your calendar. Don’t forget to set a reminder a couple of minutes before the habit starts.
  2. When the time comes, you’ll get a notification. It’s time to show up for your habit. That’s it.


  • If you live with someone, tell them you have this meeting at X time on Y day, so they can nudge you and make adjustments accordingly.
  • This is a real meeting. You’re busy. Don’t schedule something else during this time. Don’t accept other invitations. Don’t have a meal during your meeting.

It worked for me. Let me know how it works for you.