Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Moonlighting as a Software Developer: Getting Started

DZone's Guide to

Moonlighting as a Software Developer: Getting Started

Sometimes we need a little extra income, and as a developer, one way might be to moonlight as one. In this post we take a look at how to become an enterprising developer.

· Agile Zone
Free Resource

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Today’s question is about moonlighting as a software developer. It’s short but sweet.

Any tips for finding moonlighting opportunities?

Sure! Let’s do that.

Defining Moonlighting

First, though, I want to make it very clear what we’re talking about here. Moonlighting isn’t a synonym for freelancing or contracting. Instead, it has a very specific connotation.  You can look to the dictionary for the technical specifics.  Emphasis mine.

Paid work that you do in addition to your normal job, especially without telling your employer.

To unpack, we have a core component and a second, common one. You do work in addition to a salaried job, and usually without informing your primary employer.

For the rest of this post, I’m going to assume that you don’t want your primary employer to know that you’re doing this. I’m also going to assume that we’re talking about moonlighting related to your software development work and not you getting a cashier’s job at the local bodega. You make a living as a techie and want to earn some additional cash, also as a techie.

Image title

Weighing Legal Implications of Moonlighting

Right away, this topic may bring ethics to the front of your mind. The world of salaried employment conditions us to feel dirty doing this. As I describe in extensive detail in Developer Hegemony, corporate culture creates the paradigm of ownership, in which companies quasi-own their employees. Whether you do it at work during your 40 (okay, more like 50) hours per week, or from the comfort of your home, anything business-y you do belongs to your employer.

Unfortunately for employers that feel entitled to this, it turns out that this level of implied ownership isn’t legally binding or enforceable as part of standard employment. It’s only a cultural thing (at least in the US). This leads them to ask and wonder what to do about the moonlighting problem. They can enact reasonable restrictions as part of the employment agreement (e.g. that you don’t simultaneously work for their competitors and that you don’t profit from their intellectual property). And when they do this, they usually go the draconian route and try to get you to sign your life away.

So you have some things to consider. From a legal perspective, you should obviously avoid doing anything bad faith to your main employer. You should also check any agreements they’ve had you sign attempting to restrict your outside activities and then evaluate the risk you want to incur. I am not a lawyer, but I can say that the most likely outcome for running afoul of such an agreement is rebuke or maybe termination. They’re unlikely to come after you legally and, if they did, it’s debatable whether the court system would ever enforce something that smells like indentured servitude. You can read an interesting, nuanced account of such a thing from the employer’s perspective here.

And Also the Ethical and Cultural Implications

But that only speaks to legal concerns. Ethically, you’ll likely incur the judgment of anyone at your office that finds out, particularly idealists. The tribal nature of corporate employment creates culture narratives and a sense of belonging for that archetype. Pragmatists will probably side with them since moonlighting is an opportunist play and likely to make them jealous. 9 times out of 10, you’re on an island if anyone finds out about this.

You can, of course, go the full transparency route. Solicit permission to do a little bit of unrelated development work or consulting on the side. Or, better yet, lay it on the table when negotiating a job offer. I did this at the last couple of jobs I had, effectively calling any restrictions on my own business deal breakers and amending the contracts they asked me to sign. But just remember that they can say no, which would make you doing it anyway a bad faith act, and probably a reasonable justification for termination. As they say, perhaps better to beg forgiveness than ask permission.

So let’s assume that you’re going to do this quietly and in your spare time. Let’s also assume that you won’t do even more questionable things than moonlighting. For instance, you won’t do your moonlighting instead of your work at the office and you won’t use your corporate laptop to work for another company.

The Challenge for Moonlighters Relative to Freelancers

So now you’ve steeled yourself against any risk you might incur. Time to put out your feelers and reel in some work. Right?

Well, yes, absolutely. But understand your competitive disadvantages. I count two of them.

First, companies looking to buy app dev typically want 40 hours per week. You might think that someone is looking for only 5-10 hours, but this is rarer than you’d expect. The learning curve and cultural expectations work against you, making most buyers in that pool ones with pretty limited budgets. They’ll look to full-time freelancers. Secondly, full-time freelancers have the advantage of using all the marketing channels at their disposal. They can set up a website, sign up for freelancing sites, and generally equip themselves with a broad and passive work pipeline.

You will have a much harder time doing this. You can anonymize yourself to some extent in these channels and use them for moonlighting. But you’re better served by taking a wholly different approach, and one that doesn’t really leave a paper trail, so to speak. You don’t really want to wind up in your boss’s office, looking at your feet while you explain how she came to schedule an interview with you through elance or something like that.

Look Behind You: Leverage Past Connections and Jobs

So for moonlighting, you need to leverage your network as much as possible. This means meeting up for coffee, making phone calls, and sending personalized emails. And not en masse, either. You can’t blast out an announcement on LinkedIn about your intentions.

Go instead to people who know you, your work, and your capabilities. The best source for moonlighting gigs, in my experience, will come from former employers. Since you’ve left, they probably have some dusty corner of a codebase that nobody wants to touch. That used to be your thing, and now touching it terrifies everyone, so they put it off. You can help with that, and it doesn’t take a lot of hours.

But you’ll have more than just former bosses. Reach out to coworkers that have moved on from your mutual former employer as well as friends and family. With these pieces of outreach, however, you need to do some thinking about what you can bring to bear for them. If the coworker knows you as the person that migrated the company to Git when you worked together, see if his current company could use that same service. Get creative. Don’t just send off emails saying, “hey, I want money, so here’s my resume with 8 billion acronyms, frameworks, and languages.” Don’t make people do homework to figure out how you’re useful.

Open-Source and Conference Salvation

As you work your way through a list of contacts, start to think about your public profile. Remember, making a marketing website or applying to freelancer matchmakers carries a risk. But contributing to open-source or speaking at conferences/user groups typically doesn’t. Do the former, and you’re a mercenary. Do the latter and you can still be a mercenary, but now disguised as a journeyman idealist. It’s the perfect cover.

But you know what else? It works. It gives you visible public expertise and people will seek you out for that expertise. If you start contributing to or speaking about things used inside of other companies, you’ll hear from all sorts of folks interested in that expertise. Much of this will be the normal babble of recruiters and the like, but you’ll find a bit of signal in that noise. Some of those reaching out will want just a little of your time or a few questions answered.

And that serves as the perfect start of a moonlighting relationship.

Differentiate Yourself With Different Offerings

I’ll close with what I think is both the most abstract and important bit of advice I can offer. Part and parcel with the last section’s reputation marketing comes differentiation.

For the overwhelming majority of software developers, any work they do, freelance or full time, comes down to generalist hourly labor. You give them a spec and they spend 40 hours per week at $50 per hour turning that spec into code. As a moonlighter, you have 5-10 hours a week to offer someone. If you try to compete with 40-hour per week developers, those developers will offer bulk discounts and undercut you on price (I mean, not with any actual intent — it’s just what happens by default).

You need to differentiate yourself. Figure out how to offer a productized service (e.g. the aforementioned “I’ll migrate you to git”). Become enough of an expert to consult (and I mean actually consult — not just bang out code for someone else and call yourself a consultant.)

This differentiation brings the whole thing home, in fact. You can use this to do your in-person outreach and you can target your speaking and open-source contributions to support your offering. So my tip for finding moonlighting opportunities? Make them. Finding job opportunities happens through recruiters and websites. Finding opportunities to deliver lots of value in a short time window happens through niching and differentiating yourself.

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

Topics:
agile ,consulting ,freelancing ,developer career path

Published at DZone with permission of Erik Dietrich, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}