30
Mar 15

Goodbye IBM, Hello Workday

HALO JumpAfter the guts of five years in IBM, I’m leaving at the end of the week to
go herd computers in a DevOps team for Workday.

Five years, six teams, seven projects, a dozen or so releases, a few
patents, made the Irish Olympic shooting team, got married, had  a son,
moved house – it’s a lot of memories for one job 😀

Next up: learn a new programming language, six new technologies, not have to drive round the M50 twice a day, actually be within walking distance of good coffee, two barbecue joints, all the technical meetup locations and even DURC…


04
Dec 12

First Job: Small startup or large company?

Cubicle Farm

 

Another point raised recently in a discussion on the boards.ie Development forum (we’ve had a few interesting career-related threads there of late):

When a new graduate is starting out, should they seek out jobs in small startups or large companies?

The very popular answer in the blogosphere/twitosphere/hypecentral is that the smaller startup is the better choice by a country mile, that you have a greater chance of establishing your professional reputation because you’ll have more autonomy, you’ll build more of the products, you’ll work on everything so you’ll gain a wider range of experience faster, you’ll be able to move up the ranks faster, and you’ll get to try new technologies, new techniques, new tools and new shiny things far faster than in a large monolithic company.

Maybe. But I have a different opinion.

As a first job, I’d suggest taking a role in a large company in preference to taking a role in a small one (assuming, of course, that you have the choice!). Yes, in a small company you’ll get to use more tools, take on larger projects and do more design level work.
And you won’t be ready for it and you’ll make a mess of it. Yes, you will. We all did in our first job, that’s why your first job is an entry-level one. No shame in it, you’re learning and it’s expected that you’ll be sloppy in places you didn’t know you had to be neat in, and that you’ll bite off more than you can chew, and that you’ll take on tasks that more experienced people know are doomed and wouldn’t touch with a barge pole. That’s fine. But in a small company, you can wind up being given something important to do that with and the fallout is generally not more training when you inevitably screw up! 😀

In larger companies, you won’t get near design work of any magnitude for a while, but you will be surrounded by experienced people and if you want to learn and grow as a professional, that’s a pretty good environment to do a first job in. Stick it out for a year or two (or even three or four), and then once you’ve knocked off the worst of the rough edges, go for a smaller company or even a startup and use the tools and do the things you couldn’t in the larger company. Not only will you appreciate it more, but you’re likely to screw up less as a result.

Also, remember this is your first job. It’s not just software you need to be learning, but how the workplace itself operates, how to work with other people in teams on large projects (you haven’t met a large project yet, not if you’re a new graduate. The largest thing you’ll have seen in college work doesn’t even begin to approach the largest thing you’ll work on in industry) and other non-technical things that we just don’t teach in college. It’s how to get on with people that you like and people who irritate you to the point where you’d rip the skin off their face with a rabid badger if it’d make them stop talking for five minutes; it’s how to deal with managers and other bosses, both the good ones and the bad ones (and how to tell the difference); it’s how to deal with clients (though you may not see any in a really large company); it’s how the company is an actual business that needs to earn money and how that affects designs and priorities; and most importantly -if you can see it – how the company hires new hands and what they look for and how they decide how much to pay them.

Oh, and if you can learn about when to stick with the job; when not to take the job; and when (and how) to quietly resign and run for the hills – that would be a good thing too, but the odds are that you’ll be a few jobs learning that (that’s just how it goes, you need data points).

You won’t learn much about those things in a four-person startup, no matter how cool the tools or tasks they have. (Well, maybe the bit about running for the hills, or the bit about bad bosses, and you definitely will learn about the dire need for having written contracts for every last little thing; but other than that…)

Mind, you’ll be learning to eat bitter, but that’s part of the first job anywhere; it’s just that a few people in our industry think they never need to learn it (and they’re the poorer for it and they’re fairly easy to spot because they create unnecessary work for those around them). In a larger company, it’s a lot easier to learn to eat bitter (for one thing, the paycheque cushions the blow; for another, there’s usually more support and better trained managers, and less panic).

It’s not very sexy, compared to the startup world’s “f*** you” attitude and generally insufferable behaviour; but if you want to be a professional instead of a “passionate rock star artiste“, it’s probably the better choice to go work for a large company and actually learn your craft – after all, the startup mythos is always saying that college courses can’t teach you to be a great developer; so if you are going to go do the apprenticeship role, you might as well do it at a place where they’ve proven they’re good at what they do… and frankly four lads in a garage somewhere working on the next twitter clone to vanish into the aether taking all their funding with it is not a better place to learn professional practice than a fortune 500 company that’s been around for decades and shows no signs of vanishing just yet!

There was… some dissent regarding this opinion 😀

 


11
Aug 10

Choosing the next job rather than finding it…

A few weeks back, at the end of April, my contract with the Suura project in TCD ran out. We were close enough to the finish line that I offered to stay on for a few weeks unpaid, but TCD rules prohibited this, so that drew a line under the Suura project for me, though I did walk away with a patent being filed in my name (and four others) for the system and a promise of equity share should things ever sort themselves out.

But with the wedding round the corner and having gone from looking at very high potential rewards to yet another run through the recruitment process, I was feeling a bit miffed at the startup life. I went through my usual post-contract routine of writing up my last log entry on the job (always keep a log of what you do and plan during the job), and then taking a week and doing absolutely nothing. Not lazing about, but studiously doing nothing, letting the mind go null and letting the “dammit, I missed the morning meeting with X” sensation die away (because if you don’t, you can’t focus on the next thing, you wind up scattered all over the place mentally).

After that, I sat down and went through my logs from the last four or five years and as many SMEs and startups, and noted all the things that bugged me about those roles; and all the things that I liked in them and wanted to see more often. And I went through my current google reader subscriptions and the items I found myself reading in dZone and Hacker News and Programming Alltops. I added all those together and also looked at how the upcoming wedding was going to change priorities, and sat down to draft a list of criteria for the next role.

I know that sounds a bit arrogant, especially in our current economic climate, and worse than that, it sounds like the advice every career coach, life coach and self-help book writer out there peddles on a daily basis. And I’m a bit more reactionary on this sort of thing than most in our industry – I thought Mike Rowe’s take on work and jobs was a breath of fresh air in a room filled with manure (the second ten minutes, not the first ten – the first ten are just fun 😀 ):

But here’s the thing – desperately going from job to job really is a bad idea in our industry. It can look appalling on the CV and thanks to Jason Calacanis’ tweet-started shouting match a few months back, it’s the hot-button topic of the month in some sectors. And even skipping the points that there are often valid reasons for jumping from role to role on a near-annual basis, there’s the fact that it’s just not very good for your personal life either (and dammit, I like having a personal life). So I wanted the next role to be long-term, and rather than just go for the first random job that I could do that paid enough, I thought I’d try a more focussed search for “the” role instead, to see how it’d play out.

So here were the criteria I came up with.

  • The role should be for a large, stable company. Well, obviously. But it was more than just because startups are so volatile, it was because in all the SMEs and startups I’ve been in so far, there’s an inversely proportional relationship between the size of the company and the panic level in the company when absolutely anything goes wrong. Regardless of the true significance of the problem, pretty much all the SMEs I’ve been in have been guilty of assigning tasks according to the volume of the shouting from the clients at one point or another; or of getting into some serious bikeshed design discussions. The theory was, a large and stable company won’t have quite such a rapid panic response – it simply couldn’t if it had enough people in it. Panic responses generally need a startup-style environment with one or two people in charge, without that, panic can’t really take hold.
  • It should be either a systems administration or a low-level programming role. The roles I’ve held and the work I’ve done in the past five to ten years have all been caught between sysadmin and low-level programming, from linux device drivers to tuning databases for LAMP stacks. That’s the kind of level I’m most comfortable with, and I’m still not even close to bored with it or to thinking I know even half of what there is to know about it. But I’ve never made the decision between sysadmin and dev; and devops isn’t really a half-way house, so I have both down as acceptable.
  • It should have a focus of either “scale” or “mobile”. Because at the moment, aside from a few niches like security, there’s nothing else going on that’s interesting. Building large-scale systems and building mobile systems; it’s either of those or nothing if you want to do interesting stuff, because as of yet, we don’t know how to do either. And that means opportunity – to learn, to play and to profit.
  • It should be a role using C or Python or both. I’m fairly okay with C. After fifteen years of using it, I’ve gotten to the point where it’s not so much quirky as normal. And I’m really enjoying learning to use Python, and I’m impressed with what it can do at the application level. So using C would make my work life easier, and Python would be fun. Both would be perfect. Granted, this isn’t a deal-breaker, but it is important. And definitely no Java. That abomination unto dog is something I find painful to use at the best of times.
  • It should be in Dublin city centre. For eleven years, I spent between 90 minutes and two hours a day travelling by bus and train to get to college or work. For a further two years, I spent a similar amount of time driving that route. Then I moved to the city center and could walk to work in under twenty minutes. I’m never, ever, going to accept a work commute over 30 minutes again. Life’s just too short, and time’s too valuable.
  • It should be a job for the next 5-8 years, not the next year or two. After a few years of having companies fall out from under me, or become places that were toxic to stay in, I’m sick of instability. I’m craving a role where knowing where I’ll be in a year is not an act of divination. I want to work in a place where market pressure doesn’t turn everyone into foaming-at-the-mouth release junkies, or the-world-is-ending paniced firefighters, but where a sensible timetable survives at least the first brush with reality (even if it doesn’t survive intact and whole).
  • The salary should be in an acceptable range. I’m not greedy by nature, unless we’re talking about cake. As far as money goes, I’m normally of the opinion that I want to pay my bills, have health insurance and a pension, buy an occasional toy, and have some savings for a rainy day. That doesn’t actually take as much as you’d imagine. However, in our industry, salary is also a communications channel, and in the business world, it’s a statement of how your work environment will treat you. So I want mine back up where it would have been had I not taken a kicking from the Revenue Commissioners for working in a college startup (smart economy, eh? How about not levying contract researchers for pensions they can’t benefit from while they try to start SMEs you can tax?). Besides, I was about to get married, and a family isn’t far behind that, and while I’m not greedy by nature, I also like the idea of my kids getting to go to college and having a decent life.

On top of those criteria, there were other things in the back of my mind about the kind of people and the kind of management styles I prefer, but those weren’t well-formed enough to make the list. So with those criteria, I sat down to draw up a list of suitable companies, and I came up with a grand total of three – Google, IBM and Amazon. A fourth was added after talking to a few others in the industry (Facebook), and Amazon was moved a bit down the list for dev roles after talking to a few other friends. As it happened, Google had been asking me to interview for a few months, so they were up first, but CVs and emails went off to contacts in the others. Google’s interviews were a washout, however, as I’ve mentioned before.

The first to respond of the three remaining candidates was IBM. They’d been on my “would like to work there” list since they opened the Linux Technology Center the year I graduated, I had friends working there happily for years, and they certainly fitted the bill for being large and stable. When the initial phone contact I got turned out to be someone I’d known back in my PhD days and I learnt that the role was focussed on the low-level work needed for dealing with large-scale systems, it got very promising indeed. The initial interview was tough enough to be interesting, but what really got me hooked was the mindset of the managers doing the interview. Commitment to a healthy work-life balance, a strong emphasis on professionalism rather than rock-star programming, and sane expectations of workloads. And a fairly comprehensive lack of bullshit didn’t hurt.

It was at the point where I was walking away from the second interview, looking at green fields and rabbits and trees and a horizon all around (live in the Docklands for a year; you’ll crave those things too) that I realised not only was this a good fit to my criteria (with a small tweak to the “Dublin city centre” criteria), but that I really wanted to work here. Happily, they offered, I accepted, and I started work in the new role this week and am currently hip-deep in anagnorisis! So maybe choosing the job you want is a good idea, at least for software engineers…