In the second part of my short series of deranged, febrile scrawlings which Jamie somehow finds the patience and tolerance to read, we’ll be looking at the….erm…interesting subject of Careers in I.T. This is a tough one for me. I try not to give advice, because when I do, a hand-cart mysteriously appears and things go to Hell in it with such velocity that Physicists would need to seriously consider the principles of Special Relativity if they ever got to know. So you should take this, less in the spirit of ‘sage advice’, and more along the lines of “look at all the horrible screw-ups I made, and don’t let it happen to you”. Cuz, you see, they’re MY horrible screw-ups, I made them all by myself and you can’t have them. Go make some horrible screw-ups of your own. It’s easier than you think.
i. So, you want to work in some area of Information Technology?
I.T. is a huge, unimaginably vast area. Finding your way through it can sometimes feel like navigating Manhattan in the Evening Rush, and at other times like trying to cross the Rub’ al Khali on foot with a busted compass. In each case, the same strategy applies: identify a target that’s within your reach, and make sure you pack enough supplies to get you there. Once there, restock, get the map out, and make sure you’re certain of your next target before leaving the relative security of where you’re at right now.
If there’s one thing I’d like you take away from this discussion, it’s that the end-point you had in mind when you set out might not be the end-point you reach. You might, for instance, set out to become a programmer but find out that you’re better suited to be a Tester. Under no circumstances consider this to be a ‘failure’ or ‘second best’. I.T. is full of fascinating, imperative careers and you’ll be doing yourself a serious disservice if you don’t at least think about several of them.
ii. Do I need to go to College?
This is a difficult question for me to answer, and in order to explain why it’s difficult, full disclosure is needed. I had the chance to go to Government-run University back when it was pitifully inexpensive and very good value for money. If I come out and say “yes, you really need higher education” then your natural rejoinder is going to be “yeah, you would say that. But I can’t stump up the obscene fees that even modest institutions charge right now”. And if I try to tell you that Higher Ed isn’t a prerequisite, you’re going to think that I’m one of those revolutionaries who storm the castle and then promptly bold the door behind them. So the correct way to answer the question isn’t by reference to what I did at all, but rather the generation of people who are coming up after me.
The senior programmer on my team who, by the way, is just about the most talented and skilled system engineer I’ve ever had the awe-inspiring pleasure to work with, decided to skip University altogether, and went to trade school instead. His rationale for doing this was that he already knew what skills he wanted to acquire, and was happier just forking over modest fees for the exact classes he wanted, get working as fast as possible and minimize his debts. I don’t doubt that he could have skipped formal education altogether, and self-studied that lot, but that kind of insane self-discipline and confidence about what it is that you want is about as common as rocking-horse stool.
The big thing I’m going to keep harping on all the way through this article is that, unless you possess that kind of steel-minded determination and utter confidence, your first few years (at least) in I.T. are going to see you changing your mind. A Lot. And you are really quite likely to find that a dedicated course in programming, and only programming, is going to leave you short – not only in the case that you decide that programming isn’t what you want to do full-time, all the time, but as your career diversifies and expands. So let’s think about what a course of higher or continuing education can do for you, and what you might want to take away from it.
In preparation for writing this, I went back over my old day journals and broke down, roughly, how an average project breaks down in terms of tasks. Put very simply, the timeline seems to go like this:
|----------------|----|-------|----------------------------|----------|--------------------------------|
1 2 3 4 5 6
i. Software Design
ii. Data Design
iii. Programming
iv. Testing and Debugging
v. Release: Sales Support
vi. More testing and debugging
Now, do you see? During the initial phase of product development, programming part is only about 10% of the actual work in the v1.0 of the actual product. MUCH more time and effort is spent on testing and debugging (which of course involves programming too, but not in the Development phase.) After your first release to customers, you’ll find even more effort being spent on debugging, as they turn up stuff that you didn’t. Even the design phase takes longer than the initial programming phase – which is exactly as it should be. Now let’s take a look at what academic and industrial skills we need to apply to each of those phases:
i. Design – Human Interaction, Reasoning, Advocacy, Rhetoric, Economics
ii. Data Design – Logic, Reasoning, History, Database Skills
iii. Coding, History, Writing
iv. Hard Science (Physics / Chemistry), Forensic Science, Reasoning, Coding
v. Marketing, Human Interaction, Writing
vi. Hard Science, Writing, Reasoning, Coding
Before we start rationalizing that stuff, I want you to pay attention to the fact that Coding is a part of only 3 out of 6 of those steps. It’s not even the biggest part of all of them. Keep that in mind as we break down each step and think about what use we’re putting those skills to, and where we might get them from.
We start with a design. So far, we haven’t even begun to think about what language we’re programming in, what Database system we’re using or what the User Interface is going to look like. That’s exactly as it should be. Making those decisions early will prejudice important decisions we have to make during this stage.
For this stage, we have to decide what our piece of software will accomplish and how. This will involve a lot of argument. To make sure that your awesome ideas get heard, you’ll need to get along with people and not be a prick in the discussion sessions. The sort of skills you might learn from voluntary counseling or community activism, for instance. You’ll need to be able to make your case, and come up with supporting evidence. That’s reasoning, advocacy and rhetoric – which you’ll learn as well as anywhere from Classical Philosophy, Law or Bible/Koran studies. Finally, you’ll need to justify the resources you’re asking for, which means you’ll need to know how growth models work, when microeconomic conditions become macro, and the correct time to hire new blood. If you’ve ever helped out in the family store or business, this won’t be news to you, but studying a little economics won’t hurt either.
By the time we get to data design, you’ll need more reasoning skills – once this design is set in stone, it will be very difficult to change radically. You’ll need a knowledge of history – and how to synthesise historical data– so you can instantly recall what went to crap and why. And, almost as an aside, yeah, you should study some database system skills too (of which more later)
The Coding stage will see you need to do actual programming, and later we’ll discuss “what language should I learn”. The fact is that the problem will be driving the language choice at this point, and not, never the other way around. But you’ll also need to be documenting every single thing you do, and so thoughroughly that if you get flu tonight, anyone from your team can pick up your notes and keep truckin’.
I referred to debugging and testing as Hard Science because….well, that’s what it is. You construct a hypothesis and test it against the software. And either your hypothesis breaks, or the software does. That’s how you find bugs – by the exact same experimental methodology that you’d use to investigate the properties of a chemical compound or the acceleration of an object in motion. I called it forensic science because you’re looking for the abnormalities and errors that help you reconstruct the story of how a failure occurred, not unlike trying to learn something from a corpse fished out of the ocean (and only slightly less ick), and you’ll need your reasoning skills for exactly the same reasons. The release stage is all about sales and marketing, and then, once we start getting feedback from our early-adopter customers, it’s back into the debugging cycle again, possibly with a view to introducing a few small features.
This is a very, very simplified case of what a software project looks like. If one of yours ever ends up looking like this, give yourself a hearty pat on the back, call me and I’ll buy you a donut. The reason I raised the point at all is to give you an idea of all the other skills you’re going to be packin’ when you actually start working as a programmer. I’m not saying that programming is a trivial skill to learn – far from it – but if you make the decision to enter (or return to) higher education, there are lots of things that you should be studying to take advantage of that experience, and programming is only one of them.
On the other hand, if you can’t afford college, or you’re just disinclined to go, or go back, that’s hardly the end of the world either. Pick up a short conversion course, an internship, and get to work as fast as you can.
In conclusion, we need to understand that there are a ton of skills, abilities and frames of reference that you’ll need that come from disciplines that at first sight don’t seem to have anything to do with software engineering at all. Social Science, Creative Writing, Hard Science and Reasoning are just as important as anything else. This isn’t to say that programming is trivial, but the big picture is so much more.
iii. What programming language should I learn?
At last! An easy question!
The answer: any damn one you please.
Fact is, whatever you study and whatever you like best is very, very unlikely to be the one the one you’ll end up using. The day your language choice ends up driving your project design decisions is the day you FAIL. Back in the day, no-one could figure out why the Amazon guys built their first version in LisP, which was considered to be a cranky research language that no-one sane would ever use for production. The reason is that LisP is designed to process data structures, which became the backbone of Amazon’s Recommendation system, which is something that other language just can’t do as well. If those guys had set out to shoehorn Amazon into ASP or Perl or Java, they couldn’t have built the product they did.
There are so many programming languages out there that the choice can seem giddying. If you are just starting out, I’d recommend picking one with a syntax that will get out of your face as quickly as possible and let you concentrate on learning basics. Traditionally, this meant C (not C++ or C#), which consists of only 32 keywords. You could reasonably expect to work through the standard text in a month, at 2 hours per day.
For numerous reasons, C isn’t used so much in production nowadays, although if you want to work on embedded systems, operating systems or the very high-performance parts of games, you’re not going to escape it. The modern teaching language of choice is becoming Python, and for good reasons: it runs on everything, there are a ton of resources available for it, and it has the advantage of being approachable enough for children to learn, but scalable enough to take right up into Google production code. Python scores over C in that it also supports concepts like Functional Programming (just like LisP!), Object-Orientation and Abstraction.
I can’t talk about Python without talking about Ruby, because they’re very much siblings. They do almost the same things (although in radically different ways), and they have about equal share in the wild right now. By Ruby, I mean Ruby, not Rails. Rails is da bomb an’ all, but you’re learning programming, not frameworks. When you’re happy with dynamic overloading, anonymous functions, linked lists and data structures, then by all means get stuck into Rails. The other language that we shouldn’t ignore is JavaScript. As we discussed last time, ten years ago, JS was untouchable (and not like Elliott Ness, either. More like an open sore) because of all of the horrible uses it had been put to. But it’s undergone an astonishing rehabilitation thanks to Gmail’s patronage and the development of libraries like JQuery and NinjaTools. An important moment was when Douglas Crockford released his book “The Good Parts” which went back and treated JS as a serious programming language instead of the abomination that put pop-up windows all over your screen.
You can learn all the principles of programming from Javascript, and the good part is that you already have it, at least if you’re reading this. In fact, I’d probably go as far as to say that you’ll need to be packin’ some Javascript on your bandolier in the modern I.T. world in any case; but we need to add the same caveat that we added to Ruby: when you start out, stick to strict Javascript and stay away from the libraries for now. All that stuff about Lightbox windows and image pickers is cool, sure, but you’re at wax-on-wax-off stage right now, so no Jquery for you yet, Grasshopper!
Scheme is another oldie-but-goodie that you might want to check out. It’s a LisP-like functional language that you won’t find much used in production (although it is used in big production products – my spies tell me that it’s used in the SwissProt protein database interrogation tools). You probably shouldn’t make it your first stop, but it’s a nice compare-and-contrast to some other language you’ll also be studying. If you’re inclined towards electronic engineering, you’ll want to look at Assembly languages. If you want a language which is constructed to practically force good coding discipline onto you, Google’s Go! Language (GOLANG) is worth checking out – it’s as different as can be from Python or Ruby, but it also scales up from beginners-to-NORAD as well as the others do.
Finally….I’m as unwilling to discommend anything as I am to advise anything, but if you’re starting out, the one language I’d avoid is Java. This might sound strange, since Java is wildly popular and probably one of the most used production languages in the world right now, but that’s exactly what makes it a horrible learning language. You can’t learn the fundamentals of programming from Java, because it’s too tightly bound to its own production environment. I’m actually considering an entire post on Java right now, because naturally, it’s at the heart of the Android ecosystem…
In conclusion: pick a language that will enable you to study the principles of programming, and stay away from ones that force you into their way of doing. Once you’ve got the hang of that, transitioning to another language (which you’ll be doing in your first week at work anyway, and then every year for the rest of your life) will be easy.
iv. Startups.
Everyone wants to be an entrepreneur. Everyone wants a business card with “CEO” on it and everyone wants to be a twenty-five year old millionaire. (well, almost everybody. There is, of course, nothing in the world wrong with modest ambitions, or minimizing the time you spend at work. Hell, I don’t know what I’d do if I was wealthy). Some folks like the idea of trying to start a business from nothing, just to see if they can do it.
I.T. Startups are, of course, the Philosophers’ Stone of the industry. Get the spell right, and you can turn iron into gold. Get it wrong, and you’re face to face with a scary demon wanting to know if he can have your soul for all eternity (in the case of small businesses, the demons usually disguise themselves as bank managers, debt collectors or bailiffs). Some people enjoy the challenge, others would much rather go to work for someone else and not have to worry about where their next medical insurance payment is coming from.
Fortunately, the capital outlay for a modern IT startup does not have to be onerous. Used to be that a little office, a small server, a couple of development machines would be enough. In 2013, I think even that’s overkill for most people. When I started programming for a living, having a “server” meant Windows NT4 on a high-end PC (Linux as not production-useful, and affording a commercial Unix – SCO or Solaris – wasn’t an option). This would have been about USD 1000 all-in. Fast-forward to Now, and USD30 / month gets you a Virtual Server in Ubuntu or Red Hat, which does everything that throbbing box in the corner does, but doesn’t even drink electricity or pump out hot air in July. You can sit in your favourite coffee shop any time of the day or night, fire up your cheap Taiwanese tablet PC and log in to your VS, and you’ve got access to a full-blown production or development Linux environment.
The first time I ever did a “video conference”, I spent a weekend lashing up an old Security camera to a video capture card, a pair of Shure SM-57 stage microphones and wrangling with my boss’s golf club for the loan of their 48” projection TV. Renting the “conference hub” cost USD200 / hour. It was a nightmare of twisted wires, mangled insulation and insulating tape everywhere, plus a bit of carelessness with an X-Acto knife that is the reason my email address is now ‘scarthumb’, but my some miracle, we actually managed to get Our Office, Cape Town and Hong Kong online at the same time. In a world where Skype and cellphones with built-in video cameras are just a fact of life, this probably sounds laughable, but please remember, this was only sixteen years ago. The point of this story is that the infrastructure you need for a small startup – fast internet, cheap cellphone, video conferencing and instant messaging, access to a test / development server – which, a decade ago, were barely affordable – are probably stuff that you take for granted every day, and amen to that. Anyway, all the stuff you need for your startup is probably just the stuff you already have, and all you need is your killer idea, and away we go…..right?
Hmmm. Not Quite.
Startups are just about the most appallingly stressful things a human being can do to themselves. It’s not just the fact that you won’t have a guaranteed income….erm, ever. It’s not just the fact that the whole world will be literally waiting to laugh at your failure. It’s not just the fact that, if you happen to become successful, everyone will want a piece of you and you won’t ever be able to tell your friends from your enemies ever again (until the hipsters turn on you, and then you’ll have no trouble identifying your true friends: they’re the ones going ‘meiow’). It’s the fact that there is absolutely no way to find out if you’re doing the right thing or not. To ameliorate this spiral of madness and paranoia, there are a few steps we can take….
1. Get yourself in a position where you do not have to worry about where your next 6 months’ worth of meals are coming from.
You cannot concentrate on cool ideas, networking, finding customers and image building when you’re fretting about money. You just cant. So do all you can to take that out of the equation. If this means moving back in with your parents – swallow your pride. If it means having a part-time job and working your startup in the afternoons, deal with it. For the record, I got real lucky; I found a company that was willing to pay peanuts for a part-time IT maintenance / support person, and in exchange for sub-minimum wages, I got the use of a little corner desk, fast internet and telephone. This was pretty sweet, but it failed because I didn’t think of the next part until it was too late…
2. Do Not Work Alone.
If you can’t convince even one other person of how cool your startup idea is, what chance do you think you stand of convincing customers, users, investors or VC’s? Little companies are echo chambers at the best of times, and you’ll need someone to call you out on your bullshit when you start getting delusional and believing your own hype.
Fortunately, (as we saw above), your partner doesn’t need to be on the same site as you, although having them within 3 timezones is a definite advantage (unless, say, you plan on having a part-time job in the daytime, a cat-nap from 18:00 until 23:00 then working until 04:00. This kind of thing can definitely work, if you make a schedule and stick to it. Having a partner waiting for you to come on line will help.)
In my case, if I did startup again, I would want at least two partners, and at least one of them in the same room as me for at least several hours a day. Your mileage may, of course, vary.
3. Consider moving to a city with a startup scene
This kind-of contradicts what I said in (1), but there are huge benefits to being around other people who are going through what you’re going through. Networking becomes easier if you’ve got a neighbourhood café or bar that hosts meetup events; grabbing an expert for an afternoon to help out with a really tricky problem becomes a possibility, too, and you’ll often find that you can arrange this on a no-money basis: I give you four hours of hardcore AI in exchange for a bunch of neat graphics for my site, stuff like that. Sadly, you may very well find your startup suffering from credibility if you’re not in a ‘recognised startup centre’, and certain investors and MicroVC’s will insist that you’re geographically close to them.
Where are these places? Well, they change from month to month, but certain places seem to be fixed nexuses. The world capital, of course, is the San Francisco Bay Area, probably followed by Cambridge, MA or Cambridge Cambs. Elsewhere, Shibuya, Mong Kok and Melbourne seem to be popular. You’ll constantly hear Boulder CO, Austin TX, Vancouver and Seattle being mentioned, and a bit of intel I heard recently suggests that Riga or Helsinki are worth keeping an eye on, as the Baltics and Scandinavia get ready to capitalize on their climate for data centre location (those places are excellent global hubs as well). The post on this very site, which suggests that somewhere like Monrovia might be coming up in the future, fascinated me. In short, the list will change as fast as your twitter feed, and it’s not always the places you expect.
4. Consider going Straight-Edge.
I started this section humourously (along the lines of “…and if you’re not celibate now, a year into your startup, you sure will be, whether you like it or not….”) , but rapidly realised that there’s nothing to joke about here. Startups are notoriously punishing on both your mental and physical health. It’s not just the constant stress you’re under, but the lifestyle itself leads to sleep loss, neglect of exercise, poor nutrition and any kind of substance abuse you can name. If you choose to follow (3) and move to a place with a big startup / entrepeneur community….well, you’re going to find yourself amongst some pretty bohemian company, and it’s very easy to get starstruck, especially if you’re not from an environment like that. Many of the people you meet will be kind and supportive, but some of them will be predatory and usurious.
Running a startup requires iron determination and the will to cope with crushing disappointment and unholy work hours, and probably without anything resembling a good health insurance programme. If you’re not eating properly, not exercising, not getting enough sleep and getting bad habits, you’re just asking to be skinned alive, with your ultimate fate being your skull on a stick as a warning to the foolish. Don’t let it happen to you!
In conclusion…
Let’s not fool ourselves. The stats on startups are horrifying. 19 out of 20 fail within one year, and 9 out of 10 of those fail within the following 2 years. That’s 1 out of 200 who actually make it to profitability. But if you think of your startup as a learning exercise – a sort of practical MBA if you like – there’s no reason why you can’t use it to obtain a ton of experience that just taking a job won’t give you for years. Even if you do shut up shop within 18 months, you’ll have learned a ton of stuff that will make you much more interesting to employers. And who knows, you might be the 1-in-200.
So, at the end of this article, I’ve got the following subjects left to cover. I’d be interested to know what people would be interested to have me write about next:
Ø Programming in Java inc. Android
Ø Learning Database Technologies
Ø Beginning System Design and Project Management.
Richard is a creakingly ancient nerd who doesn't want to mess up stuff for the next generation with his cantankerous old-guy ways. He's old enough to remember watching Doctor Who on a B&W TV and listening to Slayer, Ice-T and Joy Division on LP, and programming in Assembler on a ZX-80. If you really, really want, you can write to him on: scarthumb AT lofilabo DOT com.
