Forem: Itamar Turner-Trauring

How to prepare for losing your programming job

Itamar Turner-Trauring — Wed, 20 May 2020 13:07:00 +0000

Another week has passed, and a few million more people in the US have filed for unemployment. While the current situation hasn’t impacted programming jobs quite as much, it’s just a matter of time before the economic damage hits most everywhere. There will be layoffs, and plenty of them, and occasionally whole companies shutting down.

So even if your job is secure now, you might still lose it in the future. How can you prepare? What can you do to reduce your future risks?

The first thing you need to do is come up with a plan, which is what this article is all about. In particular, you will want to:

Try to make sure you have the necessary financial resources.
Make your future job hunt easier, by building a network, making sure your skills are up-to-date, and making sure you have visible public proof of your skills.
Come up with a series of fallback plans if things don’t go well.

Let’s go over these one-by-one.

Money in the bank

If you lose your job, you lose your paycheck—but you still have to pay your bills. And after the dot-com bust, the last big tech recession, it took years for all the jobs to come back

If you have at least six months of living expenses in cash, that’s a good start. If not, it’s best to think about how to get there.

There are two sides to this:

If possible, you need to cut your expenses, which will both allow you to save and reduce how much money you need for each unsalaried month. See this more detailed article.
Ensuring your financial assets, if you have any, aren’t correlated with your job.
1. If you own stock in your own company, you are making a double bet: if the company goes down, you will lose money and your job.
2. If you work for a startup that needs to raise money soon, a crashing stock market will also greatly reduce the viability of your current job.
3. More broadly, if you own stocks and to a lesser extent corporate bonds, how correlated are they with your ability to keep a job?
4. Even more broadly, how much of your net worth is tied to the tech industry, or the economy as a whole?

In short, you want cash on hand, and plenty of it.

Making your future job hunt easier

Searching for a job will be much easier if you:

Know lots of people.
Have useful skills.
Can visibly demonstrate you have those skills.

Let’s cover those one by one.

Knowing lots of people

Applying for a job by sending in your resume is the hardest way to get hired. It’s much easier if you know someone who can vouch for you, can get you past the initial screen, or can fill you in on what the hiring manager really wants.

So the more people you know, the better off you are. See this article about (social) networking, but that can take time and is harder during a pandemic. But there are still a few easy things you can do in the short term:

Join a public Slack or two for the technology area you specialize in. You can help answer people’s questions, see when people mention they’re hiring, and more broadly get a better sense of the zeitgeist, which is useful for building your skills (see below).
Keep the contact info for former co-workers. This can be done via LinkedIn, for example, and often there will be an ex-employee Slack. If there isn’t one, you can start it—especially if your company is having initial rounds of layoffs. This too can often be very educational, as former employees might be more forthcoming.
Find ways to help other people. Can you teach useful skills? Join a local mutual aid organization?

Build useful skills

If you’ve been working at the same job for a while, it’s easy for your technical skills to get a little stale. Unless you’re working at the right place, hang out with the right people, or do the right things, you might not be aware of the latest technology, or you might be using out-of-date practices.

So you’ll want to update your skills a little. As always, doing this extensively outside of your job may not be possible, so try to:

Spend an hour a week, ideally during work hours, getting up-to-date on the latest technologies.The goal here is breadth, not depth: sign up for a newsletter for your technology stack (he’s a partial list), skim the topics at a relevant conference, maybe watch a talk or two. I cover learning for breadth here, but the basic idea is that knowing a tool exists and what it does can take very little time, and is quite valuable on its own: both on the job, but also in interviews (“I haven’t used it myself, but I believe tool X is how you would solve this”).
Try to learn more technologies on the job, because that is the best place to do so.

Create visible proof of skills

Having skills is one thing, proving you have them is another.It is therefore quite useful during a job hunt to have some visible, public proof you have these skills. For example:

Open source: When I moved to the US in my 20s, my work on an open source project made it much easier for me to get job interviews, and eventually job offers.I t wasn’t just that my resume said that I knew computer networking, I could point to a publicly available project used by real people and say “I worked on that”.

Even if you share code that isn’t widely used, it can still be useful as proof of skill.

Conference talks: Speaking publicly about a particular skill, technology, or project is a great way to get public proof of skills. With conferences moving online, speaking at conferences is now much easier. You don’t have to travel or pay for you travel, and you don’t have to get approval from your manager to lose work. If there’s a topic where you know enough to help someone else, look for conferences on the topic and submit a proposal.

Blogging: Have something to share, or learning something new? Write it down and share it publicly. Writing well is an immensely useful skill in general, so this will also count as improving your skills. You can write for your own blog, or you can propose a blog post on your company’s tech blog, if they have one.

Fallback plans

In an ideal world you would lose your job, start a job search, find a new job within a month, and everything will be fine. Sadly we don’t always live in an ideal world.

So if you live in a country like the US that has a shitty social net it’s worth coming up with a series of fallback plans, if only for your own peace of mind.

For example, how can you make your money last longer?

As soon as you lose your job, apply for unemployment.
Cut additional costs.
If time stretches on and you still don’t have a job, figure out ways to reduce housing costs. Are you young and have the ability to move back in with your parents? Have more room than you need and the option of adding roommates? All in a pandemic-safe way, of course.
Any ways you can make money some other way, if it’s really taking too long?

If you can’t find a job immediately, you will have probably have more time to upgrade your skills.

Which skills are worth working on?
What’s the best way to improve them?

You’ll also want to meet more people who can help you find a job.

Can you go to online meetups?
Find more places to interact with people online?

Write this all down, and when you’re worried you’ll at least have the comfort of knowing there will be some things you can do if and when your job goes away.

We’re all in this together

As with most big problems, there is only so much you can do as an individual: to meaningfully improve the situations we need to work together, whether in mutual aid groups or via political organization. On the other hand, you need to ensure that you as an individual are doing OK; you can’t help others if you’re collapsing under your own troubles.

And since this can all be overwhelming, start with a few simple actions:

Cut an expense or two.
Get in touch with some old co-workers.
Sign up for a newsletter.
Start writing down your fallback plans.

And then, once you have things under control emotionally, when you have a plan and you know what you’re doing next, start thinking about how you can help others, and work with other people to improve things for everyone.

Tired of scrambling to get your job done?

If you were productive enough, you could take the afternoon off, confident you’d produced high value work. Not to mention having an easier time finding a new job when you need one.

Learn the secret skills of productive programmers.

Doing more with less time: critical skills for productive programmers

Itamar Turner-Trauring — Tue, 19 May 2020 16:10:00 +0000

This article was written during abnormal circumstances, with much of the planet under lockdown due to the COVID-19 pandemic. Parents with children at home have far less time, and pretty much everyone is feeling stressed and distracted.

Under more normal circumstances there are only so many hours in the day to do your job; now it’s even worse. And yet work needs to get done: code needs to get written, features need to be shipped, bugs need to be fixed.

Faced with an ever growing list of tasks, how do you get everything done?

The short answer is, you can’t.You will never get everything done.

What you can do, though, is choose the right work, the most valuable work, the most useful work, the work with most leverage. Choose the right work and you can gets orders of magnitude improvement in your output.

Let’s see how.

The goal: increased output

Your output as a programmer is based both on your productivity and on how much time you work:

Output = Productivity × Time Worked

The first thing to notice is that there is a hard limit on how much increasing your working hours can help. After all, there are only 168 hours in a week.

If you never slept, ate, or did anything but work—and this will literally kill you—you can work 4.2× as much as a 40-hour workweek, and that’s it. And even with smaller increases in work hours, the gains quickly decline. As you work more hours you’ll become fatigued and make more mistakes; beyond a certain point those extra work hours will decrease your productivity, canceling out any gains.

What is output for a programmer?

Since increasing working hours isn’t really an option, the key to increasing your output is increasing your productivity. Productivity is the output you produce in each fixed unit of time, for example:

Productivity = Output per week

If you’re going to improve your productivity, you need to understand how to measure output.

The obvious measure is how much code you write: the more code, the better. This measure is obvious, popular, and completely wrong.

All other things being equal, is it better to implement the same feature with 10 lines of code, or 10,000 lines of code? If we measure output by code produced, the latter solution is better, but in most cases a 10 line solution is preferable to 10,000 lines. More code means higher maintenance costs, not to mention more opportunities for defects.

Your job as a programmer is not writing code, your job is solving problems: software is a tool, a means to an end. Software becomes valuable because of the problems it solves.

As a rough measure, your output as a programmer can be measured by the problems you solve: the more significant the problems you can solve, the better.

If you work for a business, significance eventually translates directly or indirectly into monetary terms: money made or money saved. In other areas you can come up with domain-specific concrete measures of usefulness: number of people served, carbon emissions reduced, number of scientists using your software, and so on.

Note: If the problems you solve produce negative value you will become anti-productive: the better you are at your job, the more damage you will cause.

If making money hurts people or the environment, your work may be productive for your employer but anti-productive for society as a whole. So make sure you’re carefully considering the ethical consequences of your actions as a worker.

How to increase productivity

Given the above, here’s how you can increase your productivity:

Find the most significant problem you can work on.
Come up with the most efficient solution to that problem.
Implement the solution with minimum wasted time.

Let’s go through these steps one by one, and see why they’re key to productivity.

1. Find the most significant problem

Let’s consider our formula for productivity again:

Productivity = Significant problems solved / Week

There are many problems you could be working on, so first you have to choose one. If you could solve either of these problems, should you be working on:

Implementing a particular missing feature; this will increase revenue by $50,000.
Fixing a bug that was decreasing customer retention; this will increase revenue by $1,000,000.

All other things being equal, the second problem is obviously the one you should be focusing on. Even if it takes 10× as long to solve and implement that bug fix, it should still be the highest priority:

Productivity of #1 = $50,000 / 1 Week = $50,000 / Week
Productivity of #2 = $1,000,000 / 10 Weeks = $100,000 / Week

Here’s the issue: in order to fix that expensive bug and improve customer retention, you need to know the problem exists. If no one ever notices that customers are leaving, if no one ever finds that bug, if no one realizes the connection between the two—then that problem will never be solved.

And that’s why finding problems is the first and most valuable step in increasing productivity.

2. Come up with an efficient solution

Once you’ve identified the most significant problem—or once your manager assigns you a problem they identified—you need to come up with a solution.

Which solution do you think is better?

Takes 1000 lines of code and 4 weeks to implement.
Takes 100 lines of code and 3 days to implement.

All other things being equal, the second solution is obviously better.But again, you need to find that solution.

If you only ever find that first solution, then no matter how efficiently you implement it, no matter how focused you are, no matter how much you manage to speed things up—you’re still implementing a much less efficient solution.

And that’s why identifying better solution is the second most valuable step in increasing productivity.

3. Implement the solution without wasting a time

Once you’ve identified a problem and chosen the solution, there is only so much leverage you have to improve productivity. You obviously want to avoid getting stuck and spinning your wheels, because wasted time reduces your productivity.

But given a particular solution, there’s only so much waste you can reduce, only so fast you can go:

Wasted time → $50,000 / 2 weeks = $25,000 / week
No waste → $50,000 / 1 week = $50,000 / week

Efficient implementation is the last and least valuable way of increasing productivity.

The skills you need to increase productivity

While you get the most increased productivity from identifying problems and the least from efficient implementation, your career as a programmer progresses in the opposite direction:

Junior engineers implement solutions.
Senior engineers find solutions and implement them.
Principal or staff engineers identify problems, find solutions, and implement them.

So becoming more productive isn’t just about helping your employer’s bottom line, it’s also about learning the skills that will give you more pay and more influence.

Critically, technological skills are necessary but not sufficient:

Your JavaScript skills don’t matter if you can never meet deadlines.
Your testing skills don’t matter if you can’t convince your manager of the value of testing.
Your software architecture skills don’t matter if no one has ever heard of your product.

How do you learn these skills?

Elsewhere I've written many articles on improving your skills.

And this article is actually an excerpt from a book I've written, The Secret Skills of Productive Programmers, covering the non-technical skills you need to get better at identifying problems, solving problems, and implementing them on schedule.

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 3900 other programmers, and every week you’ll learn how to avoid another of my mistakes.

What can a software developer do about climate change?

Itamar Turner-Trauring — Tue, 10 Sep 2019 04:00:00 +0000

Pines and firs are dying across the Pacific Northwest, fires rage across the Amazon, it’s the hottest it’s ever been in Paris—climate change is impacting the whole planet, and things are not getting any better. You want to do something about climate change, but you’re not sure what.

If you do some research you might encounter an essay by Bret Victor—What can a technologist do about climate change? There’s a whole pile of good ideas in there, and it’s worth reading, but the short version is that you can use technology to “create options for policy-makers.”

Thing is, policy-makers aren’t doing very much.

So this essay isn’t about technology, because technology isn’t the bottleneck right now, it’s about policy and politics what you can do about it. It’s still written for software developers, because that’s who I write for, but also because software developers often have access to two critical catalysts for political change. And it’s written for software developers in the US, because that’s where I live, and because the US is a big part of the problem.

But before I go into what you can do, let me tell you the story of a small success I happened to be involved in, a small step towards a better future.

Infrastructure and the status quo

About a year ago I spent some of my mornings handing out pamphlets to bicycle riders. I looked like an idiot: in order to show I was one of them I wore my bike helmet, which is weirdly shaped and the color of fluorescent yellow snot.

After finding an intersection with plenty of bicycle riders and a long red light that forces them to stop, I would do the following:

When the light turns red, step into the street and hand out the pamphlet.
Keep an eye out for the light changing to green so that I didn’t get run over by moving cars.
Twiddle my thumbs waiting for the next light cycle.

It was boring, and not very glamorous.

I was one of just many volunteers, and besides gathering signatures we also held rallies, had conversations with city councilors and staff, wrote emails, talked at city council meetings—it was a process. The total effort took a couple of years (and I only joined in towards the end)—but in the end we succeeded.

We succeeded in having the council pass a short ordinance, a city-level law in the city of Cambridge, Massachusetts. The ordinance states that whenever a road that was supposed to have protected bike lanes (per the city’s Bike Plan) was rebuilt from scratch, it would have those lanes built by default.

Now, clearly this ordinance isn’t going to solve climate change.In fact, nothing Cambridge does as a city will solve climate change, because there’s only so much impact 100,000 people can have on greenhouse gas emissions.

But while in some ways this ordinance was a tiny victory in a massive war, if we take a step back it’s actually more important than it seems. In particular, this ordinance has three effects:

Locally, safer bike infrastructure means more bicycle riders, and fewer car drivers. That reduces emissions—a little.
Over time, more bicycle riders can kick off a positive feedback cycle, reducing emissions even more.
Most significantly, local initiatives spread to other cities—kicking off these three effects in those other cities.

Let’s examine these effects one by one.

Effect #1: Fewer cars, less emissions

About 43% of the greenhouse gas emissions in Massachusetts are due to transportation; for the US overall it’s 29% (ref). And that means cars.

The reason people in the US mostly drive cars is because all the transportation infrastructure is built for cars. No bike lanes, infrequent, slow and non-existent buses, no trains… Even in cities, where other means of transportation are feasible, the whole built infrastructure sends the very strong message that cars are the only reasonable way to get around.

If we focus on bicycles, our example at hand, the problem is that riding a bicycle can be dangerous—mostly because of all those cars! But if you get rid of the danger and build good infrastructure—dedicated protected bike lanes that separate bicycle riders from those dangerous cars—then bicycle use goes up.

Consider what Copenhagen achieved between 2008 and 2017 (ref):

	2008	2018
# of seriously injured cyclists	121	81
% who residents who feel secure cycling	51	77
% who cycle to work/school	37	49

With safer infrastructure for bicycles, perception of safety goes up, and people bike more and drive less. Similarly, if you have frequent, fast, and reliable buses and trains, people drive less.And that means less carbon emissions.

In Copenhagen the number of kilometers driven by cars was flat or slightly down over those 10 years—whereas in the US, it’s up 6-7% (ref).

Effect #2: A positive feedback loop

The changes in Copenhagen are a result of a plan the city government there adopted in 2011 (ref): they’re the result of a policy action. And the political will was there in part because there were already a huge number of bicycle riders. So it’s a positive feedback loop, and a good one.

Let’s see how this is happening in Cambridge:

Cambridge has a slowly growing number of bicycle rider. This means more political support for bike infrastructure—if there’s a group that can mobilize that support!
With the ordinance, more roads will have safe infrastructure.For example, one neighborhood previously had a safe route only in one direction; the other direction will be rebuilt with a protected bike lane in 2020.
With safer infrastructure, there will be more bicycle riders, and therefore more support by residents for safer infrastructure. Merely having support isn’t enough, of course, and I’ll get back to that later on.

If Copenhagen can reach 50% of residents with a bicycle commute, so can Cambridge—and the ordinance is a good step in that direction.

Effect #3: The idea spreads

The Cambridge ordinance passed in April 2019—and the idea is spreading elsewhere:

The California State Assembly is voting on a law with similar provisions (ref), through a parallel push by Calbike.
In May 2019 a Washington DC Council member introduced a bill which among other points has the same rebuild requirements as the Cambridge ordinance (ref).
The Seattle City Council passed an ordinance, parts of which were literally copy/pasted from the Cambridge ordinance (ref).

All of this is the result of local advocacy—but I’ve no doubt Cambridge’s example helped. It’s always easier to be the second adopter. And the examples from these larger localities will no doubt inspire other groups and cities, spreading the idea even more.

Change requires politics

Bike infrastructure is just an example, not a solution—but there are three takeaways from this story that I’d like to emphasize:

If you want to change policy, you need to engage in politics.
Politics are easier to impact on the local level.
Local policy changes have a cumulative, larger-scale impact.

By politics I don’t just mean having an opinion or voting for a candidate, but rather engaging in the process of how policy decisions are made.

Merely having an opinion doesn’t change anything. For example, two-thirds of Cambridge residents support building more protected bike lanes (ref). But that doesn’t mean that many protected lanes are getting built—the neighboring much smaller city of Somerville is building far more than Cambridge.

The only reason the city polled residents about bike lanes is because, one suspects, all the fuss we’d been making—emails, rallies, meetings, city council policy orders—made the city staff wonder if bike infrastructure really had a lot of public support or not.

Voting results in some change, but not enough. Elected officials and government staff have lots and lots of things to worry about—if they’re not being pressured to focus on a particular issue, it’s likely to fall behind.

What’s more, the candidates you get to vote for have to get on the ballot, and to do that they need money (for advertising, hiring staff, buying supplies). Lacking money, they need volunteer time.

And it’s much easier for a small group of rich people to provide that support to the candidates they want—so by the time you’re voting, you only get to choose between candidates that have been pre-vetted (I highly recommend reading The Golden Rule to understand how this works on a national level).

What you can do: Become an activist

In the end power is social. Power comes from people showing up to meetings, people showing up for rallies, people going door-to-door convincing other people to vote for the right person or support the right initiative, people blocking roads and making a fuss.

And that takes time and money.

So if you want to change policy, you need to engage in politics, with time and money:

You can volunteer for candidates’ political campaigns, as early as possible in the process. Too many good candidates get filtered out before they even make the ballot. That doesn’t mean you can just go home after the election—that’s when the real work of legislation starts, which means activism is just as important.
You can volunteer with groups either acting on a particular issue (transportation, housing policy) or more broadly on climate change.
Also useful is donating money to political campaigns, both candidates and issue-based organizations.

Here are some policies you might be interested in:

Transportation policy determines what infrastructure is built—and the current infrastructure favors privately-owned cars over public transportation and bicycles.
Zoning laws determine what gets built and where.Denser construction would reduce the need for long trips, and more efficient buildings (ideally net zero carbon) would reduce emissions from heating and cooling.
Moving utilities from public to private ownership, so they can focus on the public good and not on profit.
Bulk municipal contracts for electricity: this allows for cheaper electricity for all residents, and to have green energy as the default.
State-level carbon restrictions or taxes.

Where you should do it: Start local

If you are going to become an activist, the local level is a good starting point.

An easier first step: Cambridge has 100,000 residents—city councilors are routinely elected with just 2500 votes. That means impacting policies here is much easier than at a larger scale.Not only does this mean faster results, it also means you’re less likely to get discouraged and give up—you can see the change happening.
Direct impact: A significant amount of greenhouse gas emissions in the US are due to causes that are under control of local governments.
Wider impact: As in the case of Cambridge’s ordinance, local changes can be adopted elsewhere.

Of course, local organizing is just the starting point for creating change on the global level.But you have to start somewhere. And global change is a lot easier if you have thousands of local organizations supporting it.

It’s a good to be a software developer

Let’s get back to our starting point—you’re paid to write software, you want to do something about climate change. As a software developer you likely have access to the inputs needed to make political campaigns succeed—both candidate-based and issue-based:

Money: Software developers tend to get paid pretty well, certainly better than most Americans. Chances are you have some money to spare for political donations.
Time: This one is a bit more controversial, but in my experience many programmers can get more free time if they want to.

If you don’t have children or other responsibilities, you can work a 40-hour workweek, leaving you time for other things. Before I got married I worked full-time and went to a local adult education college half-time in the evenings: it was a lot of work, but it was totally doable. Set boundaries at your job, and you’ll have at least some free time for activism.

You can also negotiate a shorter workweek, which is possible in part because software developers are in such demand. I’ve done this, I’ve interviewed people who have done it, I’ve found many random people on the Internet who have done it—it is possible.

If you need help doing it yourself, I’ve written a book to help you negotiate a shorter workweek. If you want to negotiate a shorter workweek so you have time for political activism, you can use the code FIGHTCLIMATECHANGE to get the book for 60% off.

Some common responses

“There will never be the political will to make this happen”

Things do change, for better and for worse, and sometimes unexpectedly.To give a couple of examples:

In Ireland, the Catholic Church went from all-powerful to losing badly, most recently with Ireland legalizing abortion.
The anti-gay-marriage Defense of Marriage Act was passed by veto-proof majorities of Congress in 1996—and eight years later in 2004 the first legal gay marriage took place right here in Cambridge, MA.

The timelines for gay marriage and cannabis legalization in the US are illuminating: these things didn’t just happen, it was the result of long, sustained activist efforts, much of it at the local level.

Local changes do make a difference.

“Politics is awful and broken”

So are all our software tools, and somehow we manage to get things done!

“I don’t like your policy suggestions, we should do X instead”

No problem, find the local groups that promote your favorite policies and join them.

“The necessary policies will never work because of problem Y”

Same answer: join and help the local groups working on Y.

“It’s too late, the planet is doomed no matter what we do”

Perhaps, but it’s very hard to say.So we’re in Pascal’s Wager territory here: given even a tiny chance there is something we can do, we had better do our best to make it happen.

And even if humanity really is doomed, there’s always the hope that someday a hyperintelligent species of cockroach will inherit the Earth. And when cockroach archaeologists try to reconstruct our history, I would like them to be able to say, loosely translated from their complex pheromone-and-dancing system of communication: “These meatsacks may not have been as good at surviving as us cockroaches—but at least they tried!”

Time to get started

If you find this argument compelling—that policy is driven by power, and that power requires social mobilization—then it’s up to you to take the next step. Find a local group or candidate pushing for a policy you care about, and show up for the next meeting.

And the meeting after that.

And then go to the rally.

And knock on doors.

And make some friends, and make some changes happen.

Some of the work is fun, some of it is boring, but there’s plenty to do—time to get started!

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 3600 other programmers, and every week you’ll learn how to avoid another of my mistakes.

Setting boundaries at your job as a programmer

Itamar Turner-Trauring — Wed, 03 Apr 2019 04:00:00 +0000

There’s always another bug, another feature, another deadline.So it’s easy to fall into the trap of taking on too much, saying “yes” one time too many, staying at the office a little later, answering a work email on the weekend…

If you’re not careful you can end up setting unreasonable expectations, and ending up tethered to your work email and Slack. Your manager will expect you to work weekends, and your teammates will expect you to reply to bug reports in the middle of your vacation.

What you want is the opposite: when you’re at home or on vacation, you should be spending your time however you want, merry and free.

You need to set boundaries, which is what I’ll be discussing in the rest of this article.

Prepping for a new job

Imagine you’re starting a new job in a week, you enjoy programming for fun, and you want to be productive as soon as possible. Personally, I wouldn’t do any advance preparation for a new job: ongoing learning is part of a programmer’s work, and employers ought to budget time for it. But you might choose differently.

If so, it’s tempting to ask for some learning material so you can spend a few days beforehand getting up to speed. But you’re failing to set boundaries if you do that, and they might give you company-specific material, in which case you’re just doing work for free.

Learning general technologies is less of a problem—knowing more technologies is useful in your career in general, and maybe you enjoy programming for fun. So instead of asking for learning material, you can go on your own and learn the technologies you know they use, without telling them you’re doing so.

Work email and Slack

Never set up work email or Slack on your phone or personal computer:

It will tempt you to engage with work in your free time.
When you do engage, you’ll be setting expectations that you’re available to answer questions 24/7.

While you’re at work you’ll always have your computer, so you don’t need access on your phone. If you do need to set up work email on your phone for travel, remove the account when you’re back home.

And if you want to have your work calendar on your phone, you can share it with your personal calendar account; that way you’re sharing only your calendar, nothing else.

Vacations

When you’re on vacation, you’re on vacation: no work allowed. That means you’re not taking your work laptop with you, or turning it on if you’re at home.

A week or so in advance of your vacation, explain to your team that you won’t be online, and that you won’t have access to work files. Figure out what information they might need—documentation, in-progress work you want to hand off, and the like—and write it all down where they can find it.

If you must, give your personal phone number for emergencies: given you lack access to your work credentials and email, the chances of your being called for something unimportant are quite low.

You’re paid for your normal work hours (and that’s it)

A standard workweek in the US is 40 hours a week; elsewhere it can be a little less. Whatever it is, outside those hours you shouldn’t be working, because you’re not being paid for that work. Your evenings, your weekends, your holidays, your vacations—all of these belong to you, not your employer.

If you don’t enforce that boundary between work and non-work, you are sending the message that your time doesn’t belong to you. And if you have a bad manager, they’re going to take advantage of that—or you might end up working long hours out of a misplaced sense of obligation.

So unless you’re dealing with an emergency, you should forget your job exists when your workday ends—and unless you’re on your on-call rotation, you should make sure you’re inaccessible by normal work channels.

Struggling with a 40-hour workweek? Too tired by the end of the day to do anything but collapse on the sofa and watch TV?

Learn how you can get a 3-day weekend, every single week.

Do they have work/life balance? Investigating potential employers with GitHub

Itamar Turner-Trauring — Thu, 31 Jan 2019 05:00:00 +0000

When you're searching for a new programming job you want to avoid companies with long work hours. You can ask about work/life balance during the interview (and unless you're desperate, you always should ask), but that means wasting time applying and interviewing at companies where you don't want to work.

What you really want is to only apply to companies that actually allow—or even better, encourage—good work/life balance.

Close reading of the job posting and company hiring pages can sometimes help you do that, but some good companies don't talk about it, and some bad companies will just lie.

So in this article I'll explain how you can use GitHub to empirically filter out at least some companies with bad work-life balance.

Let's look at GitHub profiles

If you go to the profile for a GitHub user (here's mine) you will see a chart showing contributions over time. The columns are weeks, and each row is a day of the week.

Each square shows contribution on a particular day: the darker the color, the more contributions.

What's most interesting here are the first and last rows, which are Sundays and Saturdays respectively. As you can see in the image above, this GitHub user doesn't tend to code much on the weekends: the weekend boxes are mostly blank.

You can also use this UI to see if the company uses GitHub at all. Given this many boxes, the user's employer probably does use GitHub, but you can also click on a particular box and see the specific contributions. In this case, you would see that on one particular weekday the user contributed to "private repositories", presumably those for their employer:

On the other hand, if you were to click on the weekend boxes you would see that all the weekend contributions are to open source projects. In short, this user doesn't code much on the weekend, and when they do it's on personal open source projects, not work projects.

Generalizing this process will allow you to filter out companies that don't have work/life balance for developers.

Investigating work/life balance using GitHub

There are two assumptions here:

This is a relatively small company; large companies tend to vary more across groups, so you'll need to adjust the process somewhat to focus on programmers in the group you're applying to.
The company uses GitHub for most of their source code.

Company size you can figure out from the company page or LinkedIn, usage of GitHub will be something we can figure out along the way.

This is not a perfect process, since users can disable showing private repository contributions, or it's possible the developer has personal private repositories. This is why you want to check as many profiles as possible.

Here's what you should do:

Find a number of programmers who work for the company. You can do this via the company's website, and by the company's page on LinkedIn, which will list employees who have LinkedIn profiles. You can also check for members of the company's GitHub organization, if they have a public list, but don't rely on this exclusively since it will likely omit many employees.
For each programmer, use your favorite search engine and search for "$NAME github" to find their GitHub profile. Try to do some sanity checks to make sure it's the right person, especially if they have a common name: location, organization membership, technologies used, etc..
For each programmer, check if they contribute to private repositories during the week. You do can this by visually seeing if there are lots of green boxes, and by clicking on the Monday-Friday boxes in the timeline and reading the results below. If they mostly don't, the company might not use GitHub.
If they do use GitHub at work, for each programmer, check if they code on the weekend. You can visually see if they have lots of green boxes on Sundays and Saturdays.
If they do code on the weekend, check if those are work contributions. You can do this by clicking on the weekend boxes and seeing if those are contributions to private repositories.

Additional tips:

If the company mostly writes open source code, you can check if the programmers contribute to the relevant open source repositories during the weekend.
Look for correlated weekend work dates across different people: if 5 people are working on private repos on the same 4 weekends, that's probably a sign of crunch time.

By the end of the process you will often have a decent sense if most of the programmers are coding on the weekend. Note that this method can only tell you if they don't have work/life balance—you still can't know if they do have work/life balance.

So even if you decide to apply to a company that passed this filter, you will still need to ask questions about work/life balance and listen closely during the interview process.

Always do your research

Before you apply for a job you should always do your research: read their website, reads all their job postings, talk to a friend there if you have one... and as I explained in this article, their GitHub profiles as well. You'll still need to look for warning signs during interviews, but research is still worth it.

The more you research, the more you'll know whether you want to work there. And if you do want to work there, the more you know there better your interview will go.

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 3600 other programmers, and every week you’ll learn how to avoid another of my mistakes.

A 4-day workweek for programmers, the easy way

Itamar Turner-Trauring — Fri, 25 Jan 2019 05:00:00 +0000

You’re dreaming of a programming job with 30 hours a week, a job where you’ll have time for your own projects, your own hobbies (or even just time to get all your errands done!). But this sort of job seems practically non-existent—almost no one advertises programming jobs with shorter workweeks.

How do you carve out a job like this, a job with a shorter workweek?

The ideal would be some company or employer where you just can ask for a shorter workweek, without having to apply or interview, and have a pretty good chance of getting a “yes”.

In this post I’ll talk about the easiest way to get what you want: negotiating at your current job.

The value of being an existing employee

As an existing employee you are much more valuable than an equally experienced programmer who doesn’t work there.

During your time at your employer you have acquired a variety of organization-specific knowledge and skills. It can take quite a while for a new employee to acquire these, and during the ramp-up period they will also take up their colleagues’ time.

Here are just a few of the things that you’ve likely learned during your time as an employee:

The existing codebase.
Local best practices, idioms, and coding conventions.
The business processes at the company.
The business domain.
The informal knowledge network in the company, i.e. who is the expert in what.

Not only do you have hard to-replace skills and knowledge, you also have your work record to build on: your manager knows what you can do. Once you’ve been working for a manager for a while they’ll know your skills, and whether they can trust you.

A real-life example

In my own career, being an existing employee has benefited me on multiple occasions:

After a number of years working as a software engineer for one company, I got a bad case of RSI (repetitive strain injury). I could no longer type, which meant I could no longer work as a programmer. But I did stay on as an employee: one of the managers at the company, who I’d worked for in an earlier role, offered me a position as a product manager.

In part this was because the company was run by decent people, who for the most part took care of their employees. But it was also because I had a huge amount of hard-to-replace business and technical knowledge of the company’s product, in a highly complex domain.

I worked as a product manager for a few years, but I never really enjoyed it. And with time my hands recovered, at least partially, potentially allowing me to take up programming again. After my daughter was born, my wife and I decided that I’d become a part-time consultant, and take care of our child the rest of the time, while she continued working full-time.

My manager was upset when I told him I was leaving. I felt bad—but really, if your boss is unhappy when you’re leaving, that’s a good thing.

In fact, my boss offered to help me find a less-than-full-time programming position within the company so I wouldn’t have to leave. I’d already made up my mind to go, but under other circumstances I might have taken him up on the offer.

Notice how I was offered reduced hours, even though companies will never advertise such positions. That’s the value of being an existing employee.

Asking for what you want

Unless you work for a really bad manager—or a really badly managed company—a reasonable manager would much prefer to have your experience for 4 days a week than have to find a train a replacement. That doesn’t mean they’ll be happy if you ask for a shorter workweek: you are likely to get some pushback.

But if you have a strong negotiating position—financial savings, valuable work, the willingness to find another job if necessary—there’s a decent chance they will eventually say “yes”.

Does negotiating seem too daunting, or not something you can do? Plenty of other programmers have done it, even those with no previous negotiation experience.

Much of this article was an excerpt from my book, You Can Negotiate a 3-Day Weekend. It covers everything from negotiation exercises you can do on the job, to a specific script for talking to your boss, to negotiating at new employers if you can’t do it at your current job.

With a little bit of practice, you can get the free time you need.

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 3600 other programmers, and every week you’ll learn how to avoid another of my mistakes.

Negotiate your salary like a 6-year old

Itamar Turner-Trauring — Fri, 18 Jan 2019 05:00:00 +0000

You’re applying for programming jobs, you’re hoping to get an offer soon—and when you do you’ll have to face the scary issue of negotiation.

If you read a negotiation guide like Valerie Aurora’s HOWTO (and you should!) you’re told you need to negotiate: you need to ask for more. And that’s good advice.

The problem is that asking for more is scary: it feels confrontational, your body will kick in with an unhelpful adrenaline surge, it’s just not comfortable. And honestly, given you only negotiate your salary every few years, that adrenaline surge probably isn’t going to go away.

But I think you can get past that and negotiate anyway—by embracing your inner 6-year old. In particular, a 6-year old negotiating for snacks on a playdate.

Snack time!

Let’s set the scene.

A 6-year old named Emma is visiting her friend Jackson, and now it’s time for a snack. Jackson’s parent—Michael—now needs to feed Emma.

Michael would prefer the children not eat crackers, but he has a problem. Michael has some authority over Jackson since he’s his parent, and some knowledge of what Jackson is willing to eat. So he can say “you’re eating one of these mildly healthy snacks” and that’s the end of it.

But Emma is just visiting: Michael has less authority, less knowledge, and a hungry 6-year old is Bad News. So Michael comes up with an acceptable range of snacks, and tries his best to steer towards the ones he considers healthier.

The conversation goes something like this:

Michael: “Would you like some fruit?”

Emma: blank stare.

Michael: “How about same cheese?”

Emma: shakes her head.

Michael: “Yogurt?”

Emma: shakes her head.

Michael: “Crackers?”

Emma and Jackson: “Yes!”

Michael has committed to feeding Emma something, he doesn’t want her to go hungry—but he doesn’t have the normal leverage he has as a parent. As a result, Emma can just stall until she gets what she wants. Particularly enterprising children will ask for candy (even when they would never get candy at home!), but stalling seems well within the capacity of most 6-year olds.

Salary time!

The dynamic of hiring a new employee is surprisingly similar.

Whoever is making the offer—HR, an internal recruiter, or the hiring manager—has already committed to hiring you. They’ve decided: they had interviews and meetings and they want to get it over with and just get you on board.

So they come up with an acceptable salary range, and offer you the low end of the range. If you accept that, great. And if you say “can you do better?”

Well, they’ve already decided on their acceptable salary range: they’ll just move up within that range. They’re not insulted, they’re used to this. They’re not horrified at a hole in their budget, this is still within their acceptable range.

You went from fruit to crackers, and they can live with that. All you have to do is ask.

Embrace your inner 6-year old

Much of what determines your salary happens before you get the offer, when the decision is made about what salary range to offer you.

You can influence this by the language on your resume, by how you present yourself, how you interview, and by noting you have competing offers. It may not feel like negotiation, but it’s all part of the process—and while it’s a set of skills you can master as an adult, that part is far beyond what your 6-year-old self could do.

But the actual conversation about salary? Pretend you’re 6, pretend it’s a snack, and ask for more—chances are you’ll get some delicious crackers.

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 3600 other programmers, and every week you’ll learn how to avoid another of my mistakes.

Competing with a "Stanford grad just dying to work all nighters on Red Bull"

Itamar Turner-Trauring — Wed, 09 Jan 2019 05:00:00 +0000

A reader of my newsletter wrote in, talking about the problem of finding a job with work/life balance in Silicon Valley:

It seems like us software engineers are in a tough spot: companies demand a lot of hard work and long hours, and due to the competitiveness here in Silicon Valley, you have to go along with it (or else there’s some bright young Stanford grad just dying to work all nighters on Red Bull to take your place).

But they throw you aside once the company has become established and they no longer need the “creative” types.

In short, how do you get a job with work/life balance when you’re competing against people willing to work long hours?

All nighters make for bad software

The starting point is realizing that working long hours makes you a much less productive employee, to the point that your total output will actually decrease (see Evan Robinson on crunch time). If you want to become an effective and productive worker, you’re actually much better off working normal hours and having a personal life than working longer hours.

Since working shorter hours makes you more productive, that gives you a starting point for why you should be hired.

Instead of focusing on demonstrative effort by working long hours, you can focus on identifying and solving valuable problems, especially the bigger and longer term problems that require thought and planning to solve.

Picking the right company

Just because you’re a valuable, productive programmer doesn’t mean you’re going to get hired, of course. So next you need to find the right company.

You can imagine three levels of managerial skill:

Level 1: These managers have no idea how to recognize effective workers, so they only judge people by hours worked.
Level 2: These managers can recognize effective workers, but don’t quite know how to create a productive culture. That means if you choose work long hours they won’t stop you, however pointless these long hours may be. But, they won’t force you work long hours so long as you’re doing a decent job.
Level 3: These managers can recognize effective workers and will encourage a productive culture. Which is to say, they will explicitly discourage working long hours except in emergencies, they will take steps to prevent future emergencies, etc..

When you look for a job you will want to avoid Level 1 managers. However good your work, they will be happy to replace you with someone incompetent so long as they can get more hours out of them. So you’ll be forced to work long hours and work on broken code.

Level 3 managers are ideal, and they do exist. So if you can find a job working for them then you’re all set.

Level 2 managers are probably more common though, and you can get work/life balance working for them—if you set strong boundaries. Since they can recognize actual competence and skills, they won’t judge you during your interview based on how many hours you’re willing to work. You just need to convey your skill and value, and a reasonable amount of dedication to your job.

And once you’ve started work, if you can actually be productive (and if you work 40 hours/week you will be more productive!) they won’t care if you come in at 9 and leave at 5, because they’ll be happy with your work.

Unlike Level 3 managers, however, you need to be explicit about boundaries during the job interview, and even more so after you start. Elsewhere I wrote up some suggestions about how to convey your value, and how to say “no” to your boss.

Employment is a negotiated relationship

To put all this another way: employment is a negotiated relationship. Like it or not, you are negotiating from the moment you start interviewing, while you’re on the job, and until the day you leave.

You are trying to trade valuable work for money, learning opportunities, and whatever else your goals are (you can, for example, negotiate for a shorter workweek). In this case, we’re talking about negotiating for work/life balance:

Level 1 managers you can’t negotiate with, because what they want (long hours) directly conflicts with what you want.
Level 2 managers you can negotiate with, by giving them one of the things they want: valuable work.
Level 3 managers will give you what you want without your having to do anything, because they know it’s in the best interest of everyone.

Of course, even for Level 3 managers you will still need to negotiate other things, like a higher salary.

So how do you get a job with work/life balance? Focus on providing and demonstrating valuable long-term work, avoid bad companies, and make sure you set boundaries from the very start.

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 3300 other programmers, and every week you’ll learn how to avoid another of my mistakes.

Tests won't make your software correct

Itamar Turner-Trauring — Wed, 12 Dec 2018 05:00:00 +0000

Automated tests are immensely useful. Once you’ve started writing tests and seen their value, the idea of writing software without them becomes unimaginable.

But as with any technique, you need to understand its limitations. When it comes to automated testing—unit tests, BDD, end-to-end tests—it’s tempting to think that if your tests pass, your software is correct.

But tests don’t, tests can’t tell you that your software is correct. Let’s see why.

How to write correct software

To implement a feature or bugfix, you go through multiple stages; they might be compressed or elided, but they are always necessary:

Identification: Figure out what the problem is you’re trying to solve.
Solution: Come up with a solution.
Specification: Define a specification, the details of how the solution will be implemented.
Implementation: Implement the specification in code.

Your software might end up incorrect at any of these points:

You might identify the wrong problem.
You might choose the wrong solution.
You might create a specification that doesn’t match the solution.
You might write code that doesn’t match the specification.

Only human judgment can decide correctness

Automated tests are also a form of software, and are just as prone to error. The fact that your automated tests pass doesn’t tell you that your software is correct: you may still have identified the wrong problem, or chosen the wrong solution, and so on.

Even when it comes to ensuring your implementation matches your specification, tests can’t validate correctness on their own.Consider the following test:

def test_addition():
    assert add(2, 2) == 5

From the code’s perspective—the perspective of an automaton with no understanding—the correct answer of 4 is the one that will cause it to fail. But merely by reading that you can tell it’s wrong: you, the human, are key.

Correctness is something only a person can decide.

The value of testing: the process

While passing tests can’t prove correctness, the process of writing tests and making them pass can help make your software correct. That’s because writing the tests involves applying human judgment: What should this test assert? Does match the specification? Does this actually solve our problem?

When you go through the loop of writing tests, writing code, and checking if tests pass, you continuously apply your judgment: is the code wrong? is the test wrong? did I forget a requirement?

You write the test above, and then reread it, and then say “wait that’s wrong, 2 + 2 = 4”. You fix it, and then maybe you add to your one-off hardcoded tests some additional tests based on core arithmetic principles. Correctness comes from applying the process, not from the artifacts created by the process.

This may seem like pedantry: what does it matter whether the source of correctness is the tests themselves or the process of writing the tests? But it does matter. Understanding that human judgment is the key to correctness can keep you from thinking that passing tests are enough: you also need other forms of applied human judgment, like code review and manual testing.

(Formal methods augment human judgment with automated means… but that’s another discussion.)

The value of tests: stability

So if correctness comes from writing the tests, not the tests themselves, why do we keep the tests around?

Because tests ensure stability. once we judge the software is correct, the tests can keep the software from changing, and thus reduce the chances of its becoming incorrect. The tests are never enough, because the world can change even if the software isn’t, but stability has its value.

(Stability also has costs if you make the wrong abstraction layer stable…)

Tests are useful, but they’re not sufficient

To recap:

Write automated tests.
Run those tests.
Don’t mistake passing tests for correctness: you will likely need additional processes and techniques to achieve that.

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 3300 other programmers, and every week you’ll learn how to avoid another of my mistakes.

'Must be willing to work under pressure' is a warning sign

Itamar Turner-Trauring — Mon, 03 Dec 2018 05:00:00 +0000

As a programmer looking for a job, you need to be on the lookout for badly managed companies. Whether it’s malicious exploitation or just plain incompetence, the less time you waste applying for these jobs, the better.

Some warning signs are subtle, but not all. One of the most blatant is a simple phrase: “must be willing to work under pressure.”

The distance between we and you

Let’s take a look at some quotes from real job postings. Can you spot the pattern?

“Ability to work under pressure to meet sometimes aggressive deadlines.”
“Thick skin, ability to overcome adversity, and keep a level head under pressure.”
“Ability to work under pressure and meet tight deadlines.”
“Willing to work under pressure” and “working extra hours if necessary.”

If you look at reviews for these companies, many of them mention long working hours, which is not surprising. But if you read carefully there’s more to it than that: it’s not just what they’re saying, it’s also how they’re saying it.

When it comes to talking about the company values, for example, it’s always in the first person: “we are risk-takers, we are thoughtful and careful, we turn lead into gold with a mere touch of our godlike fingers.” But when it comes to pressure it’s always in the second person or third person: it’s always something you need to deal with.

Who is responsible for the pressure? It’s a mysterious mystery of strange mystery.

But of course it’s not. Almost always it’s the employer who is creating the pressure. So let’s switch those job requirements to first person and see how it reads:

“We set aggressive deadlines, and we will pressure you to meet them.”
“We will say and do things you might find offensive, and we will pressure you.”
“We set tight deadlines, and we will pressure you to meet them.”
“We will pressure you, and we will make you work long hours.”

That sounds even worse, doesn’t it?

Dysfunctional organizations (that won’t admit it)

When phrased in the first person, all of these statements indicate a dysfunctional organization. They are doing things badly, and maybe also doing bad things.

But it’s not just that they’re dysfunctional: it’s also that they won’t admit it. Thus the use of the second or third person. It’s up to you to deal with this crap, cause they certainly aren’t going to try to fix things. Either:

Whoever wrote the job posting doesn’t realize they’re working for a dysfunctional organization.
Or, they don’t care.
Or, they can’t do anything about it.

None of these are good things. Any of them would be sufficient reason to avoid working for this organization.

Pressure is a choice

Now, I am not saying you shouldn’t take a job involving pressure. Consider the United States Digital Service, for example, which tries to fix and improve critical government software systems.

I’ve heard stories from former USDS employees, and yes, sometimes they do work under a lot of pressure: a critical system affecting thousands or tens of thousands of people goes down, and it has to come back up or else. But when the USDS tries to hire you, they’re upfront about what you’re getting in to, and why you should do it anyway.

They explain that if you join them your job will be “untangling, rewiring and redesigning critical government services.” Notice how “untangling” admits that some things are a mess, but also indicates that your job will be to make things better, not just to passively endure a messed-up situation.

Truth in advertising

There’s no reason why companies couldn’t advertise in the some way.I fondly imagine that someone somewhere has written a job posting that goes like this:

“Our project planning is a mess. We need you, a lead developer/project manager who can make things ship on time. We know you’ll have to say ‘no’ sometimes, and we’re willing to live with that.”

Sadly, I’ve never actually encountered such an ad in the real world.

Instead you’ll be told “you must be able to work under pressure.” Which is just another way of saying that you should find some other, better jobs to apply to.

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 3300 other programmers, and every week you’ll learn how to avoid another of my mistakes.

Enthusiasts vs. Pragmatists: two types of programmers and how they fail

Itamar Turner-Trauring — Mon, 12 Nov 2018 05:00:00 +0000

Do you love programming for its own sake, or do you do for the outcomes it allows? Depending on which describes you best you will face different problems in your career as a software developer.

Enthusiasts code out of love. If you’re an enthusiast you’d write software just for fun, but one day you discovered your hobby could also be your career, and now you get paid to do what you love.

Pragmatists may enjoy coding, but they do it for the outcomes. If you’re a pragmatist, you write software because it’s a good career, or for what it enables you to do and build.

There’s nothing inherently good or bad about either, and obviously this is just a simplification. But understanding your own starting point can help you understand and avoid some of the problems you might encounter in your career.

In this post I will cover:

Why many companies prefer to hire enthusiasts.
The career problems facing enthusiasts, and how they can solve them.
The career problems facing pragmatists, and how they can solve them.

Why companies prefer hiring enthusiasts

Before we move on to specific career problems you might face, it’s worth looking at the bigger picture: the hiring and work environment.

Many companies prefer to hire enthusiast programmers: from the way they screen candidates to the way they advertise jobs, they try to hire people who care about the technology for its own sake. From an employer’s point of view, enthusiasts have a number of advantages:

In a rapidly changing environment, they’re more likely to keep up with the latest technologies. Even better, they’re more likely to do so in their free time, which means the company can spend less on training.
Since they’d write software for free, it’s easier to pay enthusiasts less money.
It’s also easier to get enthusiasts to work long hours.
Finally, since enthusiasts care more about the technical challenge than the goals of the product, they’re less likely to choose their work based on ethical or moral judgments.

But while many companies prefer enthusiasts, this isn’t always in the best interest of either side, as we’ll see next.

The career problems facing enthusiasts

So let’s say you’re an enthusiast. Here are some of the career problems you might face; not everyone will have all these problems, but it’s worth paying attention to see if you’re suffering from one or more of them.

1. Exploitation

As I alluded to above, companies like enthusiasts because they’re worse negotiators.

If you love what you do you’ll accept less money, you’ll work long hours, and you’ll ask less questions. This can cause you problems in the long run:

Long hours can lead to burnout, in which case you might not enjoy coding at all, even in your spare time.
Less money reduces your options outside of work.
Finally, you really shouldn’t do work that’s immoral or unethical: there are plenty of fun problems that won’t make you feel guilty.

So even if you code for fun, you should still learn how to negotiate, if only out of self-defense.

2. Being less effective as an employee

Matt Dupree has an excellent writeup about why being an enthusiast can make you a worse worker; I don’t want to repeat his well-stated points here.Here are some additional ways in which enthusiasm can make you worse at your job:

Shiny Object Syndrome: As an enthusiast it’s easy to choose a trendy technology or technique for your work because you want to play with it, not because it’s actually necessary in your situation. The most egregious example I’ve seen in recent years is microservices, where an organizational pattern designed for products with hundreds of programmers is being applied by teams with just a handful of developers.
Writing code instead of solving problems: If you enjoy writing code for its own sake, it’s tempting to write more code just because it’s fun. Productivity as a programmer, however, comes from solving problems with as little work as needed.

3. Work vs. art

Finally, as an enthusiast you might face a constant sense of frustration.As an enthusiast, you want to write software for fun: solve interesting problems, write quality code, fine-tune your work until it’s beautiful.

But a work environment is all about outcomes, not about craft. And that means a constant pressure to compromise your artistic standards, a constant need to work on things that aren’t fun, and a constant need to finish things on time, rather than when you’re ready.

So unless you want to become a pragmatist, you might want to get back more time for yourself, time where you can write code however you like.You could, for example, negotiate a 3-day weekend.

The career problems facing pragmatists

Pragmatists face the opposite set of problems; again, not all pragmatists will have all of these problems, but you should keep your eye out to see if they’re affecting you.

1. It’s harder to find a job

Since many companies actively seek out enthusiasts, finding a job as a pragmatist can be somewhat harder. Here are some things you can do to work around this:

Actively seek out companies that talk about work/life balance.
When interviewing, amplify your enthusiasm for technology beyond what it actually is. After all, you will learn what you need to to get the results you want, right?
Demonstrate the ways in which pragmatism actually makes you a more valuable employee.

2. You need to actively keep your skills up

Since you don’t care about technology for technology’s sake, it can be easy to let your skills get out of date, especially if you work for a company that doesn’t invest in training. To avoid this:

Actively seek out tasks, projects, or new jobs that will force you to learn new technologies on the job, in depth.
Spend an hour every week gathering a broad but superficial knowledge of new technologies.

3. Pressure to work long hours

Finally, you will often encounter pressure both from management and—indirectly—from enthusiast peers to work long hours. Just remember that working long hours is bad for you and your boss (even if they don’t realize it).

Programmer, know thyself

So are you an enthusiast or a pragmatist?

These are not exclusive categories, nor will they stay frozen with time—these days I’m more of a pragmatist, but I used to be more of an enthusiast—but there is a difference in attitudes. And that difference will lead to different choices, and different problems.

Once you know who you are, you can figure out what you want—and avoid the inevitable obstacles along the way.

We all make mistakes, and I’ve got 20 years’ worth: from code that crashed production every night at 4AM, to accepting a preposterously bad job offer.

Every painful failure taught me a lesson—but only after it was too late.

You can do better! Join 2900 other programmers, and every week you’ll learn how to avoid another of my mistakes.

When and why to clean up your code: now, later, never

Itamar Turner-Trauring — Fri, 02 Nov 2018 04:00:00 +0000

You’ve got to meet your deadlines, you’ve got to fix the bug, you’ve got to ship the product.

But you’ve also got to think about the future: every bug you introduce now will have to be fixed later, using up even more time. And all those deprecated APIs, out-of-date dependencies, and old ways of doing things really shouldn’t be there.

So when do you clean up your code?

Do you do it now?

Later?

Never?

In this article I’ll go over a set of heuristics that will help you decide when to apply three kinds of fixes:

Updating dependencies that are out-of-date and usages of deprecated APIs.
Refactoring to fix bad abstractions.
Miscellaneous Cleanups of anything else, from coding standard violations to awkward idioms.

Heuristics by situation

Prototyping

Before you start building something in earnest, you might start with a prototype (or what Extreme Programming calls a “spike”). You’re not going to keep this code, you’re just exploring the problem and solution space to see what you can learn.

Given you’re going to throw away this code, there’s not much point in Updating or Miscellaneous Cleanups. And if you’re just trying to understand an existing API or technical issue, you won’t be doing much Refactoring wither.

On the other hand, if your goal with prototyping is to find the right abstraction, you will be doing lots of Refactoring.

Updating: never.
Refactoring: now if you’re trying to prototype an API or abstraction, otherwise never.
Miscellaneous Cleanups: never.

A new project

When you’re starting a completely new project, the decisions you make will have a strong impact on the maintenance code going forward.

This is a great opportunity to start with the latest (working) dependencies, situation-specific best practices and maintainable code, and the best abstractions you can come up with. You probably won’t get them completely right, but it’s usually worth spending the time to try to get it as close as possible.

Updating: now.
Refactoring: now.
Miscellaneous Cleanups: now.

An emergency bugfix

You need to get a bug fix to users ASAP. While you might see problems along the way, but unless they’re relevant to this particular bug fix, it’s best to put them off until later.

Sometimes that might mean fixing the bug twice: once in a quick hacky way, and a second time after you’ve done the necessary cleanups.

Updating: later.
Refactoring: later.
Miscellaneous Cleanups: later.

New feature or non-urgent bugfix

When you have a project in active development and you’re doing ongoing work, whether features or bug fixes, you have a great opportunity to incrementally clean up your code.

You don’t need to fix everything every time you touch the code. Instead, an ongoing cleanup of code you’re already touching will cumulatively keep your codebase in good shape. See Ron Jefferies’ excellent article for details.

Updating: now, for code you’re touching.
Refactoring: now, for code you’re touching.
Miscellaneous Cleanups: now, for code you’re touching.

A project in maintenance mode

Eventually your project will be finished: not much new development is done, and mostly it just gets slightly tweaked every few months when something breaks or a drop-down menu needs an extra option.

Your goal at this point is to do the minimum work necessary to keep the project going. Refactoring and Miscellaneous Cleanups aren’t necessary, but Updates might be—dependencies can stop working, or need security updates. And jumping your dependencies 5 years ahead is often much harder than incrementally doing 5 dependency updates at yearly intervals.

So whenever you have to do fix a bug, you should update the dependencies—ideally to Long Term Support releases to reduce the need for API usage updates.

Updating: now, ideally to Long Term Support releases.
Refactoring: never.
Miscellaneous Cleanups: never.

Balancing present and future

Software projects tend to ongoing processes, not one-off efforts. A cleanup now might save you time later—but if you have a deadline to meet now, it might be better to put it off even at the cost of slightly more work later on.

So takes this article only a starting point: as with any heuristic, there will be exceptions to the rule, and you need to be guided by your situation and your goals.