
![The programmer's startup -- a fire-breathing dragon -- tries to roast him, but he uses his part-time job -- his shield -- to defend himself](/blog/why-i-work-part-time-small.webp)

I have spent 6 of the last 12 years working stable, part-time jobs. I like and dislike the obvious things — more time with my kids, less money, more time for side projects, less career growth, less work stress, more layoff risk, less time in meetings, more time wondering what everyone is saying about me in meetings — but I’ve come to appreciate the broader impact that working part-time has on my life and my work.

## **An Alternative to Going All-In on Startups and Side Projects** ##

I have a hard time doing only one thing. I know this is not true of everyone, but when I work full-time, I’m frustrated that I can’t spend time on personal projects without sacrificing other important parts of my day. However, when I take a break from working full-time to focus on a personal project, I begin to worry more about money and the future (much more so now that I have children). I start seeing reminders of the [time value of money](https://en.wikipedia.org/wiki/Time_value_of_money) everywhere I look.

Working part-time has become a viable third alternative to going all-in on a project by raising money or self-funding. Some personal projects — like [making a game](https://store.steampowered.com/app/1989110/King_of_Kalimpong/) — take a lot of time but aren’t good candidates for investment or bootstrapping, because they carry a lot of development risk and aren’t likely to make any money. I’m actually pretty sure the game I’m working on right now won’t make any money, because it’s free.

Even some more traditional, less risky startups benefit _more_ from survival than they do from money alone, like building and maintaining an audience. Working part-time allows me to keep an idea alive long enough to (let’s be honest) invalidate it, regardless of however long I thought that would take when I started (no time at all, probably!).

## **Learning Broadly and Deeply** ##

Despite my constant (probably unhealthy and definitely untreated) yearning to work on my own thing, I genuinely like working for companies that aren’t my own. I get to learn from people who know more than me while working in unfamiliar domains. I learn skills I’m not likely to get from starting companies and side projects, like how to mentor junior developers, how to hire, how to deal with grumps, and how to auto-forward the CEO’s emails to the trash bin for a year without him noticing. Also, they pay you!

I’ve found that both my professional work and my personal projects benefit from this broad exposure. I’ll occasionally be able to transfer something I’ve learned from hiding latency in a networked game to my employer’s web client/API networking layer, or take math I’ve learned from the data science team and use it in game programming. Watching good CEOs pitch or sell has shown me that hey, that’s a thing, I should learn that thing for my startup.

Also, you meet people, and you can become friends with them or work with them later, or both. Hi Ryan!

## **Stability and Identity** ##

I’ve found that I switch jobs less often when I’m working part-time. I think there are a few reasons for this:

1. It’s probably my ideal state of working so I’m more content/less anxious.
2. I don’t hate my job because I’m not doing it all the time. This also means that if there are bad things about my job, I’ll tolerate them longer, because they take up less of my day.
3. Stable part-time work is relatively difficult to find so I’m less likely to hear about better opportunities and switch jobs. This is not usually the case when you’re open to full-time work.
4. While there’s probably higher layoff risk, as a lower overall cost to your employer perhaps you are sometimes safer than full-time employees. I don’t know though, seems like the part-timers would be the first go. Let's agree that by leaving this flimsy idea here all employers will be convinced that they should let their full-time people go first. Bullet point complete!

One big benefit to working part-time that I did not anticipate (I am not a bright man) was that I no longer struggle to maintain an identity separate from my work, regardless of how engaging or consuming it may be. I don’t know how common this is, but often when working full-time I begin to associate myself more and more with my team or company or project, especially if the work is interesting and the company is at an exciting stage.

This tendency is insidious for me because it affects my ability to give my children, partner, and friends the quality attention they deserve, and that I want to give them. My attention is elsewhere and my identity becomes more one-dimensional and less interesting.

When I’m working part-time I’m naturally changing contexts more often. The two things I’m doing become just two of the many that help define me. Clearly my identity is none of those things alone, but some weird blob-like combination of all of them with a face, and a hat if it’s sunny out.

## **Balancing Work-Life Balance and your Life’s Work** ##

The free time and forced autonomy that comes from working part-time has helped me be more deliberate about where I put my attention. I get to choose between spending time with friends and family and working on side projects. It turns out this flexibility is essential for me: some days I want to take my girls to the park all afternoon, and some days I want to work on my game’s party-matchmaking system’s dedicated game server controller’s concurrency model until it’s exactly right.

I’ve long felt some kind of internal struggle about why, if I’m such a proponent of Work-Life Balance for others — especially when I’m managing people — do I myself like to spend so much of my free time working? Thankfully, John Carmack sorted this out for me:

> ... Work-Life Balance versus your Life's Work, where there's a small subset of the people that can be very happy being obsessive about things and, you know, obsession can often get things done that just practical, prudent, pedestrian work won't, or at least, won't for a very long time.

_From [https://lexfridman.com/john-carmack/](https://lexfridman.com/john-carmack/)_

That’s not me all the time — I’m certain I want to work less than Carmack and that, for humanity’s sake, that’s okay — but it is me some of the time. Working part-time helps me choose when those times are and balance them with the rest of my life. Making a networked physics game in your free time is hard (for me), especially if you want to spend a lot of time with your young children, so more free time and the occasional late night or early morning are often rewarding for me and fit nicely into the rest of my life.

I think that because I have some agency over my time and I like what I'm doing, burnout risk is low. Carmack discusses this too, attributing his avoidance of burnout to always having a variety of interesting things to work on:

> I have literally never felt burnout, and I know there's lots of brilliant, smart people that do world-leading work that get burned out, and it's never hit me. I've never been at a point where I'm like I just don't care about this, I don't want to do this anymore. But, I've always had the flexibility to work on lots of interesting things. I can always just turn my gaze to something else and have a great time working on that. So much of the ability to actually work hard is the ability to have multiple things to choose from and to use use your time on the most appropriate thing.

_From [https://lexfridman.com/john-carmack/](https://lexfridman.com/john-carmack/)_

Working part-time has definitely helped me here. I don’t think I’ve ever felt burnout either, and that is probably due, at least in large part, to being lucky enough to always having several interesting things to do, whether that’s different projects, family, friends, or hobbies. I also haven’t written a bunch of game engines from scratch so this could be like a penguin agreeing that no, the water is not too cold, don’t worry about it, just get in there!

## **Finding Part-Time Programming Jobs** ##

I still don’t know how to reliably find part-time work, in general. It’s the kind of thing you want to bring up at the beginning of any hiring process to save everybody time, but that will also probably slow or stop an employer’s interest in working with you (even in cases where they otherwise would be okay with you working part-time).

So far I’ve found all of my part-time software work through one of three ways:

1. Start full-time and transition to part-time
2. Contact former employers/partners (or former coworkers with new employers) and ask to work part-time
3. Work with a demand-led consulting firm like [forward](https://www.forward.id/)

My first part-time job was an accident. I was working full-time for a digital media company and I wanted to take a break and learn game development. When I quit, they offered me a raise, so I asked if I could work two days a week instead. I worked there for another year and a half after that.

Another part-time job came through Forward, and the one after that was from direct contact by a former partner of a previous employer.

I suspect there are more employers open to hiring part-time developers than I see advertised on job boards, but it's difficult to find out, so I focus on companies in my personal network and determining how I can have a meaningful impact in 10 to 20 hours per week. It's a different process than a typical job search: I spend more time convincing someone that I can have an impact _in 20 hours_ and less time convincing them that I can have an impact, period.

I'm hoping to use [Polyfill](https://polyfill.work/) to match developers who are only available part-time with employers who will benefit from hiring them, by showing them how their candidate search criteria affects who they reach. If it works well, I'll use it myself, and this section will be a lot less meandering in the future.

Why I work part-time (and how I find part-time programming jobs)


![An employer on the side of the road tries to get the attention of programmers as they drive by](/blog/divide-and-conquer-small.webp)

In [an earlier post](https://polyfill.work/blog/why-is-recruiting-developers-so-difficult) I talked about what I think the problems are with some common approaches to recruiting software developers. I didn't mention hiring because at Polyfill we only care about recruiting. [Many Hacker News commenters replied](https://news.ycombinator.com/item?id=32403768) with their solutions, but I noticed that most of them were either conflating recruiting and hiring, or talking only about hiring. Some of them appeared to just be talking about other stuff they needed to get off their chest. I liked those comments the best.

Many commenters disagreed with one another on how best to hire developers, despite having had success with their respective approaches. This is because hiring is hard to generalize and nearly everyone’s experience with it is anecdotal. Also, it’s a necessarily subjective thing:

1. Companies/teams have different cultures
2. Different problems need different problem solvers
3. Different developers have different work preferences

Developers even differ on what they are willing to do to get a job in the first place: some of us like live programming exercises, others prefer take-homes, nobody likes talking about themselves, everybody loves reversing a btree while they’re trying to finish a sandwich.

## **Why separate recruiting and hiring?** ##

Thinking about recruiting and hiring as two separate components of your growth process lets you tune them individually according to their needs. I think that recruiting — the process of attracting the right developers to your company — is more easily generalized and delegated, while hiring — the evaluation and interview process — is a specific process best handled by the hiring manager and the team the candidate would be joining.

## **Hiring is (probably) bespoke** ##

Every time I'm responsible for hiring at a new company or team, I adapt the hiring process from my last job. I'm always surprised at how much I have to change it. I've made several attempts to generalize hiring, but I've failed to do it enough times that I decided to put my energy elsewhere. Instead, I try to figure out how to figure out what our hiring process should be. The goal is for it to fit our needs and to take less time to figure out next time.

It's also very costly to get hiring wrong, which means I have to spend more time on the hiring part — specifically, the interview process and the interviews themselves. I still have the rest of my job to do, so I need recruiting to take less time while still complementing the hiring process.

At Polyfill, we're interested in working on the recruiting problem, not hiring. Maybe hiring can be generalized, or derived from some structured definition of a company’s key attributes. I’m not confident that a software tool can solve that problem, but I don’t know, so I’m not going to talk about it.

## **Recruiting** ##

Recruiting is the part of the process where you attract the right developers to your company. It’s everything that you do to get them interested in you, up until they express enough interest to enter whatever your hiring process is. Recruiting is going well when you want to interview almost everyone who applies, and when applications are coming in at a rate you can handle.

If you don't attract the right people, you can't hire the right people. If you attract too many of the wrong people, you'll overwhelm yourself and your team with irrelevant candidates. Filtering is least expensive at the beginning of the process (the recruiting step) and becomes increasingly expensive as you progress through the hiring stages.

## **Recruiting can be generalized and delegated, but hiring can't?** ##

The costs of a poor recruiting process are:

1. The time you wasted reading applications from candidates you could have filtered out
2. The money wasted attracting inadequate candidates
3. The missed opportunities of _not_ receiving applications from candidates you'd like

Obviously these are bad, but the good news is that there's some slack in this system. Reading the occasional bad resume or missing out on a couple of good candidates is not the end of the world. But if this is happening all the time, well, it's also not the end of the world, but it is the end of you making a good hire. Recruiting needs to be good, but it's okay if it's not perfect.

(Ideally, the relationship between your criteria and the candidates you see should be as close to deterministic as possible, but that topic deserves its own post.)

The costs of a bad hire are:

1. The money you pay them
2. The time and attention you and your team spend onboarding and working with them
3. Their impact on your culture and customers
4. The absence of all of the positive effects of a good hire

Sometimes you make a hire so bad that your best people quit and your company implodes. Nobody has ever read a cover letter so bad it made their company disappear. Except once, in 2008, when Bear Stearns collapsed after reviewing an application for a summer internship submitted by Merlin (the wizard).

## **You need to get them both right** ##

If your recruiting is bad you’ll spend too much time reading resumes from meteorologists for your cloud engineer position and interviewing candidates you know you won’t hire because “we need to hire someone and this guy is a person who applied”.

Hiring out of desperation is not recommended: the chickens from the “you’ll do” school of hiring usually come home to roost in fun ways, like with 3 months of being annoying to work with, insisting on writing weird javascript, then dropping a production database, all followed by an abrupt exit right after the recruiter, their buddy, gets paid.

If your hiring is bad, your recruiting won’t matter. You’ll be wasting good recruiting and eventually you’ll undermine it. And you might tank your whole company while you're at it!

## **Polyfill only cares about improving recruiting** ##

Ryan and I are not interested in trying to solve the hiring problem. It seems difficult, in a tedious way, to try to generalize a solution to such a broad problem that probably varies by company, if not by team. The enormous variety in preferences across employers and developers makes it hard enough, but I think the most difficult aspect is evaluating a candidate *on behalf of* a company or team for which you yourself don’t work.

Instead, we want to provide a way for developers to say what they want, and to introduce employers and developers to one another when they want the same things. We want to cut down on the time wasted on both sides of the recruiting process.

Once employers and developers have been introduced, it’s up to them.

Good luck. Don’t bungle it up!

What's the Difference Between Recruiting and Hiring?


![A recruiter knocks on the door while the developer answers at the window](/blog/finding-jobs-recruiting-devs-better-small.webp)

Recruiting developers is difficult and expensive, and looking for work as a developer isn't much fun either. Hiring managers read countless resumes while developers scroll through lengthy job descriptions to find what they want. It doesn't have to be so bad!

## **Recruiters are incentivized to bring you quantity over quality**

Looking at resumes is expensive because (1) hiring managers are usually well-paid senior people and (2) reading resumes takes time and energy.

The majority of recruiters that I’ve worked with get paid when we hire a candidate they've sent us. I may be interested in finding the right person, but our recruiter is mostly interested in getting me to hire somebody (and soon). Our incentives are not aligned. It may not seem like a big deal, because you both want to hire someone, but you care about quality and they care about quantity.

They end up sending me as many candidates as they can, which doesn’t necessarily get me any closer to hiring someone good, but it does take up a lot of time, and sometimes it works out. It's like if you ordered a cheeseburger but all I've got back here are hotdogs so I'm just gonna keep sending out hotdogs until you finally eat one.

## **Strict when we can be loose, loose when we can be strict**

Most of the candidates I see when I’m hiring only overlap with a small percentage of the criteria I’m looking for. For example, if I want to hire someone with 10+ years of experience who’s going to work on a complicated `go` api, I’ll get resumes from candidates who have <2 years of experience, but have written some `go`. I won't necessarily see the developer with 15+ years of `C++` experience who would probably be a much better fit.

We're often strict about criteria that we can be relaxed about &mdash; like experience with a specific programming language (in most cases) &mdash; and relaxed about criteria that we can initially be strict about, like pay, schedule, seniority, and work-culture values.

If I know I only want to see very experienced people for this backend job then let’s start by ignoring everyone who isn’t in that group. It’s my problem if that search criteria is so narrow that I don’t get any matches.

## **Resumes tell you what they did, but not what they want to do**

I think most developers are like me: they want their next job to be more interesting than their last job. I’m more interested in getting better at something new than I am in repeating work I’ve done before.

My resume, however, is a summary of what I’ve done, not an expression of what I can do and what I want to do next. Hiring managers can’t easily see what I want to do next, and my resume doesn’t tell them either. You can do this with a cover letter, but those take a long time to write and read, and you don't need a whole page to tell someone that anyway.

## **Only a fraction of developers are actively looking for work when you’re hiring**

Developers, especially good ones, are in very high demand, so the odds that a good developer is looking for work when you’re hiring (unless you’re always hiring) are low. It should be possible to reach developers who are already busy if the position is truly a great fit for them. Personally, I still want to know about opportunities that match my preferences when I’m working somewhere, I’m just not going to take the time to go out and find them. Because looking for work is boring. And I'm lazy.

## **Job descriptions don’t tell developers what they want to know**

When I’m looking for work I want to know a few things before I contact the company or talk to someone:

1. What will my schedule be like?
2. What’s the pay?
3. What will I do all day?
4. Will I get along with my co-workers?
5. Is the CEO going to text me at midnight and use capslock when he's upset?

Job descriptions have improved lately but they’re still mostly full of information I won’t care about until later in the hiring process.

## **Direct contact for jobs I won't like**

I like hearing about jobs I’ll like, but it’s very rare that a direct email or LinkedIn message from a recruiter is for a job I’m interested in and matches my preferences. Most of the time it seems like I was part of a “contact anyone who has experience with `$technology` because we really need to hire someone” campaign.

> Hello Nicholas,
> 
> We noticed that you have experience with computer programming. 
> 
> Well, great news! Our client is going to be using computers
> (and computer programming!) to disrupt business.
> 
> Are you interested in hearing more? Call me!

There's a lot of programmer ire toward recruiters for this type of thing, but it's not like recruiters want to spend their time contacting uninterested developers just to annoy them. (Also, we're really lucky that we like to do something that's currently in demand). Recruiters don't have great tools for reaching the people who do want to hear from them, and it's preferable to contact someone who isn't interested at the risk of _not_ contacting someone who is.

## **How can recruiting developers be improved?**

1. Focus on prioritizing strong matches between candidates and positions, which is a move toward quality and away from quantity. Put fewer, better resumes in front of hiring managers, so they can spend less time recruiting and more time hiring.
2. Enable a candidate to express what they want to do in the future, not only what they’ve done in the past.
3. Find a (targeted) way to reach good candidates who aren’t actively looking for work but are interested in hearing about situations that are better than what they have today. Don't hope that they will come to you, because they probably won't.
4. Give recruiters "equity" in developers they help hire so they are incentivized to find people who will stick around and succeed.

## **How can searching for a developer job be better?**

1. Let developers express their preferences — schedule, pay, culture, the nature of the work, etc — and then only send them jobs that match their preferences.
2. Give them the opportunity to decide if they want to connect with the recruiter or company, and let them control who gets their email address.

The Polyfill Blog

Why I work part-time (and how I find part-time programming jobs)

What's the Difference Between Recruiting and Hiring?

Why is recruiting developers so difficult?