DaedTech

Stories about Software

By

Turning Tech Hobbies into Side Hustle

I just dug up a tweet I made about 4 years ago.  I did this because I remembered saying it, and because it perfectly illustrates a distinction I’m going to make today.  Specifically, I’ll talk about the distinction between technical hobbies and side hustle.  And, I’ll then advocate for side hustle.  But first, the tweet.

Quick and to the point.  The year was 2013, and, during the course of yet another oppressive Chicago winter, I wanted to learn F#.  At the time, I ran an IT department as the CIO for a company, and I had come to miss writing code.  So, I took to Twitter and threatened to teach myself yet another programming language.

I’m embarrassed about this tweet, in a sense.  You might think the fact that I never wound up learning F# embarrasses me.  But no, I’ll get over that.  Rather, the undirected, goalless nature of the sentiment embarrasses me.  It does in the context of career, anyway.

Programming Hobbies

Before I go any further, I want to talk about the idea of hobbies and career.  At times, I’ve enjoyed hobbies, such as guitar playing, cooking, and home improvement, among others.  Given that I’ve historically earned my living in software development, nobody would confuse these hobbies with career plays.

The line blurs a bit with certain other considerations, however.  For instance, I could have regarded writing as a hobby for a good bit of my career.  These days, however, people explicitly pay me to write in various capacities.  This kind of knocks writing out of the realm of pure hobby for me.  And then there’s time you spend outside of work doing what you do for a living.  Let’s say, going home to learn F#.  It doesn’t pay your bills, but you can file it under the heading of “sharpening the saw.”  Sure, my job may not call for F#, but it makes me a better programmer (and, a better CIO, I guess).  So it counts as career-something.  Right?

Actually, I would now argue that no, it does not.  Had I gone home to learn F#, for the sake of learning F#, I would have engaged in a hobby rather than a career play.  You can’t just blindly count something tangentially related to stuff you do for a wage as career improvement.  And yet, we do that.  A lot.

Identifying Our Real Motivations

Whether hobby or pseudo-career hobby, a complex panoply of factors motivate our actions.  Even if we think otherwise, we don’t generally pursue something for a single, simple reason.  I didn’t sit down one day and think, “learning F# will offer me an opportunity to earn exactly $4,000 extra next year.”  Instead, some mixture of restlessness, boredom, interest, nostalgia, and who knows what else combined to give me an idea.

But when I look back on it, I can pick out a particular vanity motivation.  If I’m honest, I know that part of me said, “I want to be the sort of person that knows F#.  I want to be the sort of person that does functional programming for fun.”  If you’re honest, I bet you can recall instances of the same sort of thinking.

We pursue additional programming skill and knowledge for many reasons.  These include enjoyment, satisfaction in meeting challenges, and a general desire to “sharpen the saw.”  But we also do it, at least on some level, to establish our cred and impress our peers.  I have no problem with any of those motivations, but not all yield fruit equally.

Impressing Peers Instead of Buyers

Many years ago now, when I first setup this site, I showed it to my dad, a CFO at the time.  I told him that I planned to moonlight doing freelance work, and that I would blog about programming topics.  He furrowed his brow and pointed out that the people who would hire me to do programming probably didn’t care to read about programming topics.  He suggested I write to an audience of prospective buyers of programming services.

I assured him that my line of work differed from what he was used to.  After all, the hotshot, uber-successful programmers that I admired most blogged, and look at them.  He shrugged.

Looking back now, I tap into the same embarrassment that I mentioned at the start of the post.  My goodness, but he was right.

We in the programming world tend to revere those that give the best conference talks and that rack up massive stack overflow scores.  But in the years since, I’ve been surprised to learn that prodigious twitter followings, booked speaking schedules, and tech celebrity do not necessarily translate into more money or even more opportunity.  Sometimes they do.  But sometimes people with all of those things end up scrawling merge sort on a whiteboard during GiganTech’s interview process, same as anyone else.

The difference?  Those that translate tech celebrity into opportunity do so by establishing their audience as buyers.  Those that don’t parlay it into opportunity settle for merely impressing their audience.

Status Versus Opportunity

If you want to understand what I mean in more detail, take a look at K. Scott Allen.  He has as much tech celebrity as anyone else, but he also has, as I understand it, a great life.  An absolute Pluralsight legend, he has created some of the most popular courses of all time and netted earnings well into the 7 figures.  Savvy?

His tech celebrity means opportunity because he speaks not just to fellow programmers, but to buyers.  He impresses his customers.

Now, cross reference that against someone with only the status.  Let’s say that I had pursued my F# fancy with gusto, pouring in nights and weekends of study.  Eventually, I became a preeminent expert and F# MVP, which earned me tons of stack overflow points and invitations to speak at conferences.  I engaged the community in just this fashion during my spare time… but I continued to work the same job and felt, perhaps, mystified that my status did not translate to more than odds and ends opportunities.  Perhaps I get the occasional speaking fee or the odd request to teach a team of developers a bit of F#.  Nothing to sneeze at, but not exactly a path to early retirement.

So to get to the heart of the matter, I find myself retroactively embarrassed by my lack of business sense.  I wanted to impress peers instead of buyers.  But there’s no profit in impressing your peers.

The Good News: You Can Pursue Your Craft in Directed Fashion

Lately, I’ve been listening off and on to a book called, “Book Yourself Solid.”  There’s some good advice in this book, though it’s not really my style, exactly.  (Part of it I might chalk up to my mounting business self-help book fatigue.)  But he does articulate one thing that I find invaluable.  He calls it the “who and do what” statement.

He’s talking about people establishing themselves as business owners or freelancers.  But I’d expand this to anyone looking to adopt the efficiencer mindset (described in Developer Hegemony) or improve their careers.  Always make sure you have at the tip of your tongue the statement, “I help {who} {do what}” to explain your work.  The aforementioned K Scott Allen would say, “I help programmers learn the fundamentals of web development.”  If you work as a DBA, you might say, “I help software development teams not have to worry about the inner details of databases.”  You get the idea.

When I set out to say, “now I’ll start learning F#,” I had no “who and do what” statement, except the navel-gazing, “I’m going to help myself learn F#.”  Don’t repeat my mistake for yourself.

You can still learn new tech and you can still have a good time doing so.  But first, find a way to fit it into a “who and do what” statement.  Why do you need this language?  Whose itch can you scratch with this newfound skill?  It could be as simple as, “I’m going to learn F# so that I can immediately turn around and write/sell the E-Book, ‘How to F# by Someone That Just Learned It.'”

So next time you want to learn something, stop.  First, make it part of a prospective side hustle of some kind by figuring out a “who and do what.”  And no cheating by making the “who” you.  This will eliminate the natural tendency to chalk it up to “saw sharpening” that will theoretically someday make you more hireable by adding a 32nd technology to your resume’s alphabet soup.  You want to learn something new?  Great!  Just first find a prospective buyer that can make that learning pay for itself.

Want more content like this?

Sign up for my mailing list, and get about 10 posts' worth of content, excerpted from my latest book as a PDF. (Don't worry about signing up again -- the list is smart enough to keep each email only once.)

  • J-F Gilbert

    The number of ideas and thoughts I have that you put into words on your blog is scary ! It somehow validates and enforces them. Anyway, good post !

    • Glad you liked. Always good to get feedback that I’m not completely out on an island 🙂

      • Aravind Mohanoor

        I was about to make the exact comment as J-F Gilbert. Erik, this is just really good stuff.

  • Great post Erik, retweeted and bookmarked.

    I have a few questions about the last sentence:

    > Just first find a prospective buyer that can make that learning pay for itself.

    Can you go into details for this one? As a consultant, won’t it be unethical to jump into doing something while learning it and charging for it. It will take much more time for me.

    Also, without actually having a buyer, aren’t we still talking about a hypothetical perspective buyer that may not actually exist?

    • I may speak more to this in the form of a post, but I’ll offer a few thoughts here. First, I’d say that philosophically (and in my actual experience) you’re *always* learning during the course of a consulting gig, as opposed to offering a product or productized service. If nothing else, you’d be learning the client’s org structure, domain, work product, etc. Secondly, I’ve learned techs on the client’s dime as well. I think there’s nothing unethical about it at all as long as you don’t pretend otherwise. I’ve had clients specifically want *my* help with things, so they’ve been willing to finance my learning curve so that I would be positioned to help them. I think it only gets unethical if (for instance) you say “oh, sure, I can build you a Ruby on Rails lead generation site for you, and I’ll bill you hourly for it” and then you promptly start billing them for time you spend watching Pluralsight courses and reading Ruby books because you’ve never touched the tech. In other words, I think it’s just a matter of mutual expectations.

      As an aside, this concern also only applies to dollars for time billing models. If, instead of billing “time and materials” for the aforementioned Ruby site, you just said, “I’ll do it for $50K flat” and the client agreed, they wouldn’t care in the slightest how much time you spent teaching yourself Ruby. If you quote a flat rate, then you shift the risk/burden to yourself to learn, and away from the client (notwithstanding the potential downstream maintenance costs of your lack of experience)

      Now, in terms of a hypothetical buyer, that’s another possibility, and one that I don’t view as bad or as equivalent to having no buyer in mind at all. For instance, if I learn F# because of the vague idea that it will make me more marketable in some unspecified capacity, then I’m engaging in a hobby. If, on the other hand, I identify a segment of companies with some seriously large data on their hands, and I think they could use analytics on it to drive some profitable insights into their customer base, I might think to myself, “a functional language would help a lot with that. So, I’ll learn this functional language to flesh out a prototype that I can pitch to them.”

      There’s a world of difference in these two scenarios. The second one has risk as any entrepreneurial venture does. But the risk that it might not pay off or result in actual buyers is substantially different than the aimless pursuit of a hobby that might somehow be useful later. Doing anything on your own dime is inherently risky, business-wise. I’m essentially talking about at least envisioning some kind of return on investment scenario.

      • Thank you for the detailed reply!

        Agreed, the difference between the scenarios you mentioned is staggering. Thanks for clarifying, the example is spot on.

        I like how you frame freelancing/consulting as a business activity in “Doing anything on your own dime is inherently risky, business-wise.” From that perspective, it becomes really easy to pick things to learn.

        And now that I think of it, I’m learning App Development because I have the usual “Maybe I’ll make an app” plan. Maybe I can talk to existing web dev clients who may need an app and offer them a good rate.

        Thank you again, I read your posts regularly (about to get started on Developer Hegemony). Do let me know if I can contribute to the book promotion, would be happy to help!

        • I appreciate the support (reading the posts, buying the book, and joining the ambassador group)! Probably the biggest help at this point would be if you do read the book, and have something you like about it, I’m trying to gather testimonials.

          • Great, I will read and send feedback.