My horrible career

My horrible career

How I failed upwards, and eventually found a job I can’t be fired from

This is the first of a five-part series about my horrible career: how it started, how it’s going, and what I learned from making every mistake imaginable.

  1. My horrible career
  2. Not a real developer
  3. Master of my domain
  4. If you need the money, don’t take the job (coming soon)
  5. Will write for food (coming soon)

The full series is now available as a book, exclusive to Go Club members—subscribe to get your copy!


I recently had a fascinating, and wide-ranging, conversation with ace developer advocate Zack Proser, of the highly recommended Supercharge Your Dev Skills blog. We’re both very interested in tech careers and how they work (or don’t), and Zack had some penetrating questions about my own career, and whether or not I’m any good at taking my own advice. (Spoiler alert: no.)

In this first part, we’ll talk about the beginnings of my career, from unemployed CS bum to tech writer, sysadmin, and “under construction” web designer. Over to Zack:

John, you have a lot to say in your recent book Code For Your Life about the importance of having a plan for your career, and it really resonated with me. It’s made me stop and think a bit about the goals that I always just sort of assumed I’d achieve one day, and ask questions like “When, though?”. And “How, exactly?”

I know, right? There’s a very funny British zombie movie from the 2000s called Shaun of the Dead, directed by Edgar Wright, in which Simon Pegg plays a guy who’s pushing thirty, but feeling a bit directionless, and drifting through his life.

He works in a hi-fi store, but he’s the oldest of the sales assistants, and there’s a great scene where he’s talking to one of the juniors, played by Rafe Spall:

SHAUN: Look, Noel, I know you don’t want to be here forever. Neither do I. I’ve got things I want to do with my life.
NOEL: When?

I am Shaun, needless to say. Perhaps there are many other Shauns reading this and smiling ruefully.

Actually, I was even older than Shaun when I first started thinking seriously about what I wanted out of a career, beyond just making rent and having somewhere to go every day. And I think that’s probably a pretty typical experience.

Most people don’t really have a career plan, as such. They’re more just sort of winging it. At first, it’s astounding to learn that people are willing to pay you to sit in a comfy chair in a warm room, diddling around with computers. I mean, we’d probably do it for free, wouldn’t we?

That’s true, but I think I’ll edit this part out—we don’t want everybody to know that.

Fair point. But it’s certainly a delightful thing to realise, as a young person entering upon adult life, that you have a talent, or an inclination, that’s going to give you a certain amount of employability. We’re very lucky that computer jiggery-pokery is economically valuable to society (at least, for now).

However, it’s such a broad field that just because you’ll probably be making a decent salary after a few years, that doesn’t mean you’ll necessarily be doing work that’s interesting, enjoyable, or valuable. We can probably all think of jobs we’ve done in the past where that wasn’t the case.

And, once you reach a point where you are making enough money to support yourself (and maybe a family), is that it? What’s your life really about, when it comes down to it? Are you doing something that keeps you engaged and excited, that makes you happy, that has some meaningful positive effect on the world?

If not, when are you going to start? And how do you get there from here? These are the kind of questions I’m encouraging people to ask themselves, and I hope the book gives them some sort of useful framework to start thinking about it, and maybe filling in some of the answers as time goes on.

The book says “Start at the end”, so let’s do that. What is your job now, and how do you feel about it?

When people ask me what I do, and I’m in a hurry, I usually just say “writer”, because people tend to stop listening after that. If I’ve got more time, though, and they look interested, I might add “and mentor”.

And it’s pretty great! You know how you always wish you had a slightly better job? Well, I no longer wish that. I can’t imagine doing anything more fun or rewarding than what I’m doing now.

Just explain what you mean by “mentor”, because that’s not usually a job title.

Well, right. I think we’re familiar with the idea of mentoring as being a mixture of teaching, coaching, guidance, and general support. We all do that to some extent, I hope, but in my case I also provide mentoring as a professional service. I have a number of students, or mentees, whatever you want to call them, that I work with regularly as part of the BIT software engineering program.

I also write books, mostly about Go, but occasionally about other things, such as careers. That’s also part of the mentoring, of course: it turns out a lot of the skills you need to succeed as a software developer are analogue, not digital. In other words, dealing with people, processes, management, and the business side of things.

And you know a bit about that, because you have your own independent business?

That’s right. I’ve run my own company, Bitfield Consulting, for about fifteen years, and over that time I’ve gradually moved from “mostly consulting” to “mostly writing and mentoring”. Maybe I should change the name, but I’ve had the T-shirts printed now.

We’ll get to consulting later on, but tell me a bit about your mentoring.

Well, I love working directly with students, pair programming with them, debugging, talking through design problems, and giving them feedback on their projects. It’s great fun, and I get as much out of it as they do.

For one thing, I really enjoy seeing them blossoming as software engineers, succeeding in their careers, and achieving their dreams. It’s nice to feel that I’ve played some tiny role in that, even though it’s often just a case of giving them confidence in the skills they already have.

You know, sometimes you just need someone to say “Actually, you can do this!”

That really does help, especially coming from someone much more experienced.

I’ve been programming for forty-plus years, I’ve worked in dozens of jobs in multiple areas of tech, consulted for companies all over the world, and published many books, but I still feel like an imposter. I mean, there’s so much stuff I don’t know, and so many people who are a heck of a lot more expert than me.

So if I feel like that, I know it’s much worse for people who are just starting out. A bit of friendly encouragement and guidance can help, I think.

Something that also features in your books. It often feels like you’re talking directly to the reader, saying “You can do this!”

I hope so. In fact, I couldn’t write the books without having had the mentoring experience.

I mean, you don’t really understand something until you’ve explained it to someone else—ideally, several people. When you see the idea from all those different perspectives, it’s much easier to write about it.

There’s a lot of different aspects of software engineering: design, user interfaces, APIs, readability, language syntax, the standard library, the tech stack, and so on. In teaching these things to students, I learn about what people do and don’t find intuitive or easy, what puzzles them, what causes confusion, and what helps to resolve it. All of that learning feeds into the book writing, of course.

Sometimes I’ll be reading something you’ve written and a question about it starts to form in my mind, but then in the very next paragraph, you answer that same question!

That’s definitely what I’m going for. It’s not mind-reading: it’s just that I’ve learned to anticipate what questions people are going to have about a certain subject, and I’ll try to answer them in the text.

I hate it when I read something and at the end I’m still puzzled about a bunch of stuff. You want to call up the author and say “What did you mean by this, though? Stop talking in riddles!”

People can be very knowledgeable about something, but not necessarily very good at expressing it clearly.

That’s very true, and conversely there are some terrific writers who just don’t really have much experience of actually doing the thing they’re writing about.

As for me, I’m not the world’s greatest software engineer, and I don’t even claim to be a brilliant writer (I’ll leave that for others to say). I’m just the overlap in the middle of that Venn diagram.

I know a few things, and I can write about them clearly enough that it at least helps people get the basic idea, so they can jump-start their own learning.

That sounds like a pretty good career, and I can see why you enjoy it. So let’s talk about how it all started. What was your own career plan, and when did you first start thinking about it?

This will make me sound like a massive hypocrite, but I never really had a career plan as such. I just bounced around the tech industry for a few decades and ended up somewhere more or less randomly that’s turned out to be pretty great.

If you’re content to do the same, that’s fine by me. Maybe you’ll be just as lucky (or privileged) as I was. On the other hand, maybe you won’t.

Maybe it’s a good idea to be a little smarter than I was, and start thinking about this stuff earlier on in life. That way, you can take control of where you end up, instead of just having it happen to you while you’re not looking.

Did you always know what you wanted to be, even if you didn’t specifically plan out how to get there?

Not particularly. It’s more that I was never really any good at anything else.

I was a standard computer nerd as a kid, of course, and giving me detention in the computer lab was like throwing Brer Rabbit into the briar patch. I did okay in the traditional CS pathway subjects like math and physics, and indifferently in others.

The choice facing me at university level was really between playing with computers for three years (in a nice warm lab), or something involving hard work and study. So that was a bit of a no-brainer.

What was your first job after college, then?

Well, to my surprise and alarm, it turned out that companies were not queueing up to offer me employment. Most CS graduates look for software development jobs, and so did I, but I didn’t have much luck. I applied to a lot of companies, but gradually accumulated a huge pile of rejection letters. You name it, I didn’t get it.

In some cases, I think I got the rejection letter before I’d even applied.

You got decruited.

I think the word must have got around somehow. To be fair, while I technically managed to acquire a degree, the actual marks I got didn’t really bear very close inspection, and I wasn’t in any other way an outstanding candidate.

I had a great time at university, though: I learned a great deal about all sorts of things, including life, love, and myself. I just didn’t learn a lot about databases.

Possibly because you didn’t attend any of the lectures?

That’s true, but as I explained to the professors at the time, I had better things to do. (So did they, I’m sure.)

So, no regrets, but I wasn’t an academic superstar, or even a minor planet of any kind. I was a halfway-decent programmer, at least for a kid fresh out of school, but there were plenty of people who were way smarter and more experienced than me.

The trouble is, they were all applying to the same jobs as I was.

It seemed like everyone else from my cohort got hired, often working for merchant banks at eye-popping starting salaries, while I was still skulking around the Unix lab at odd hours, trying to look like an undergrad who had a right to be there, instead of an unemployed man with an expired student ID, who didn’t.

The only other thing I had even the slightest aptitude for was writing. I would turn in term papers on compiler design and context-free grammars, or whatever, and they would be written with an inappropriate degree of zip and élan, like something in Wired or The Verge.

I can just imagine you adding a little zip to your term papers. Élan, even.

I got marked down for that a lot, because you’re supposed to write academic papers in a rather stuffy voice, with lots of jargon. The denser the jargon, and the more obscure the point, the more impressive it sounds and the higher your grade. I failed at that completely, because it seems like such a pointless activity. I want to write technical stuff that’s (a) interesting and fun to read, and (b) that people can actually understand.

When?

Don’t you start. I ended up getting a job as a technical writer for a small computer company in London (actually, it was a fair-sized company, but they made small computers).

I wrote manuals, help files, the little quick-start inserts you get with consumer electronics showing you where to plug things, and any arbitrary bits of text as needed (”Wipe clean periodically with a soft, dry, lint-free cloth. Never submerge the device in water.”).

And that’s how you became a writer?

Well, yes, but via a number of interesting detours. I learned a lot about the craft of writing in that job: how to write in different registers for different audiences, how to edit my work, how to edit other people’s work, how to survive your work being edited by other people (it’s tough, don’t let anyone kid you).

But if you’ve written eight or ten user manuals, you’ve more or less written them all, and I was rather restless and dissatisfied. I was surrounded by smart programmers of all kinds: people who understood hardware, people who worked on real, grown-up desktop applications, people who knew about operating systems (they were writing operating systems). But, being merely a lowly writer of words, I wasn’t invited to write any actual code (and rightly so, as I now reflect).

That doesn’t sound like a situation that would really suit someone like you.

It chafed, my friend. I was learning a lot by osmosis, and because tech writers have to work pretty closely with the programmers who are building the stuff they’re supposed to document. But I couldn’t help getting involved in other things, just by overhearing conversations or seeing people doing stuff, and wanting to join in.

It happened that the company had its own NNTP server, which is an ancient protocol that very few people reading this will have heard of. Just as HTTP is the basis of the web, NNTP was the basis of Usenet, which was the predecessor of things like forums, Twitter (or whatever it’s called this week), and (though it pains me to say this) Reddit. Anyway, in those pre-web days companies would often host their own “news” (that is, Usenet) servers to save on bandwidth.

I’m going to say you somehow got access to that server.

There was a dusty old PC under a desk somewhere running some vaguely acceptable form of Unix such as Xenix, and it ran the news server. Everyone was very nervous of it, because it was Unix (the opposite of Lex in Jurassic Park, I suppose). So I got involved in running this machine: software updates, backups, the usual care and feeding. Like Twitter, the firehose never shut off, and the machine had a tendency to fill up its disk if you didn’t regularly trim some of the binary newsgroups. (Yes, uuencoded porn was a thing. I don’t know if anyone browsed it at work.)

Eventually the web came along, which shows you how long ago this was. My little estate expanded to include a web server (Windows NT running IIS, four words I’m happy I’ll never hear again). I even worked on the firm’s early website, when the main framework for front-end development was Notepad and HTML.

So that’s where you get your righteous Web design skills from? Not even being sarcastic, hardly.

My HTML was tight. Tiled backgrounds, flashing marquees, “under construction” GIFs, frames, whatever I could jam in there. Flash, JavaScript, and even CSS were a few years away, but I did my best, and my websites were the most “My eyes! The goggles do nothing!” that anyone could possibly wish for. Not much has changed about that, as you can see.

So when did you first manage to get paid for softwaring, instead of just writing and artisanal server crafting?

When I moved on from the PDA company I fell (again rather coincidentally) into a job running Unix webservers, this time for an online news site (which, like most online news sites, is now long defunct).

I also did some sterling work putting extra RAM in PCs, showing people how to reboot, and crawling around under desks plugging in errant network cables. One nice thing about working in IT is it keeps you from getting too grand an idea of yourself.

I’m still not hearing about any programming.

Well, over time, and with a certain amount of sheer persistence, I managed to parlay my sysadmin duties into some actual software development. You know the kind of thing: it started as a five-line shell script for running backups, and in a couple of years it was a 5,000-line spaghetti Perl abomination that ran the entire business, and no one but me understood it. (Not even I understood it, of course, but that didn’t stop me tinkering.)

It was the perfect recipe for job security: if you write bad software that people depend on, you can make yourself indispensable.

I might edit this part out too.

I’m here to drop truth bombs. But even though I was developing a lot of software, I wasn’t officially a software developer. That came later—

Let’s pause at that point, to generate some artificial suspense and excitement.

Really? Well, okay.

Don’t miss the next part, where we’ll learn more embarrassing and discreditable secrets about John’s past.

Wait, what?


Next: Not a real developer

And you can read the whole series right now in this charming, fun-size ebook, exclusive to Go Club members.

 
 
People skills for developers

People skills for developers

You can do this: surviving day one

You can do this: surviving day one

0