How to Start (and Build) a Software Career

As I had mentioned in a previous post, we are now actively hiring software developers to our development center in Tel Aviv, Israel.

As part of the interviewing process, we see software developers (and other candidates) look at various alternatives, and having a hard time to decide on a potential direction for their software career. The decisions are naturally harder for young developers who haven’t yet established some career path; but, I’m sometimes surprised to see senior engineers who seriously look at options very distant from one another, such as (as one example) building security devices vs. building web applications.

Here’s my two cents on things to look for in starting (and building) a career in software. Some of the considerations below are specific to engineering positions (developers and testers) but many are as applicable to additional roles such as product management, project management, product marketing and at times sales.

1. Work for a company that develops software using an Agile methodology

Don’t worry about the definition of Agile. Read the Agile Manifesto if you must. But, the key (or litmus test, if you will) is: go work for a company that releases software frequently: every week, every couple of weeks, every month or—if you have to—every two months.

In a previous blog, I’ve expressed my own opinion on why Agile development is critical to the business success of software-as-a-service companies.

But, for a career path it is less about business success and more about the basic knowledge on how to develop software, which is materially different between companies that develop using Agile methodologies and companies that use the 50+ years old waterfall model (which constitutes of sequential steps of requirements, design, development and testing).

A practitioner in Agile development plans differently (learns the art of breaking complex requirements into small ones) and scopes differently (using proxies for actual work). Agile practitioners work in a different technical environment, which in all or almost all cases includes continuous integration. One learns how to collaborate tightly with co-workers and peers (necessitated by the short cycles). One learns how to plan for testing and test differently (employing practices such as test-driven development, and breaking responsibilities differently). And, one learns how to incorporate customer/user feedback quickly and effectively.

It doesn’t really matter which methodology you’re going to be using; whether it’s Scrum, Kanban or the now somewhat deprecated Extreme Programming. But, for crying out loud, don’t consider working for companies that plan and market “major releases” of software once or twice a year, and use the waterfall model. If you do, you’ll learn how to write 100-page documents that will hardly be read. Or, you’ll learn to sift through 100-page documents and find the few paragraphs that let you do your job. You will spend most of your time waiting for information from upstream (“The specs should be ready next Monday.”) or waiting for downstream stakeholders to deal with what you’ve delivered (“No, don’t start anything new, QA will be starting to test the version in 2 weeks, so we’ll have plenty of work then.”). And, you will hardly get any timely direct customer feedback.

But then, don’t trust me on this one. Read, for example, how Facebook delivers code. LinkedIn releases software multiple times a day. (Disclosure: Greylock Partners is an investor in Facebook, LinkedIn and our company, WebCollage). Or, pick a few software companies you think highly of and find out how often do they ship code.

2. Work for a company that hosts its own software (a.k.a., SaaS, web application)

Yes, some companies will continue to physically ship software, and some people will continue to buy and install it. I use Microsoft Office (which is shrink-wrapped software) at work to write documents, and we at WebCollage use other on-premise software (for example: as part of our development environment).

But:

The portion of the software that is physically “shipped” is going down—more software is delivered “in the cloud”.

Even the big traditional on-premise software vendors are now announcing “cloud versions” of their software. Microsoft has delivered Microsoft CRM and Office 365 (which, by the way, is updated quarterly, according to Microsoft, compared with the 3-4 year release cycle for the on-premise version). Oracle has announced a few days ago that it would provide cloud services, reversing Larry Ellison’s statement that cloud computing was “vapor” (read more here).

Gaining experience in a declining industry or practice can hardly be argued to be a smart move. Would you want to develop a profession in CD or DVD burning, in the world of streaming?

Specifically, working in an “on-premise” world, you will spend your time learning how to create software that works with multiple configurations and environments (to support multiple customers), how to develop super-smart upgrade and update procedures, and how to deal with multiple versions of the software that exist in the marketplace simultaneously. This knowledge is gradually (and quickly) becoming irrelevant, and you will find yourself learning a thought process that is already out of date.

The innovation happens in the “cloud”

Think of where software-related innovation has happened in the last decade. Google? Facebook? LinkedIn? Zynga? Or, where business innovation backed by software grew new business categories: Airbnb, Groupon or Netflix (another disclosure: Greylock, one of WebCollage’s investors, has also invested in Airbnb and Groupon). All those companies developed software in the “cloud”, incorporating innovative elements of connectivity and collaboration that either enabled new categories (like Facebook) or challenged existing categories (like Netflix).

Admittedly, the only exception to this is mobile “apps”, which are “shipped”; but, how many apps are truly stand-alone on a user’s mobile device, without a significant portion located in the cloud? While “apps” may be “shipped”, most apps have much (or most) of their logic and value in the cloud part.

3. Work using modern technologies and mainstream programming languages and environments

Anecdotally, you are very likely to yield an exceptional salary by becoming an expert in the COBOL programming language. (If you have never heard of COBOL, that’s fine; you shouldn’t; it’s a 50+ year old programming language.) There are 1,000 open positions worldwide for COBOL programmers, and only 900 COBOL programmers still alive1, hence you’ll always find a job with high compensation. But, in the same way you wouldn’t want to drive a 50-year old car to work, you don’t want to program in a 50-year old programming language at work. In both cases, it’s not fun, and you will often get stuck.

In reality, though, do yourself a favor. Pick a career in a mainstream development language. As of 2011, most new code in the world is written using Java or .NET. Some is written using Python, PHP and Ruby. A lot of code was written in C and C++ in the past, but these programming languages are now kaput, so unless you want to be the equivalent of the COBOL guru in a decade, stay away from those (I had taught Advanced C++ for several years back in the 90’s, and I think very highly of Bjarne Stroustrup‘s work, but you really don’t want to deal with memory management in the 21st century, or wait for day-long compilations, common in C++).

Similarly, stay away from entering a career in a programming language you’ve never heard of, even if the hiring manager tells you it’s the best thing since sliced bread, and that one day all companies will use it. This may be true, but in the meanwhile you are most likely be spending your time fighting problems specific to that language, working with half-baked libraries and development environments, and most likely working for a company that will have failed because it couldn’t hire programmers both willing and capable to deal with those type of issues.

In the same way, pick a company that uses a mainstream set of technologies. If you think that NoSQL is the future, that’s fine. If you like SQL, that’s fine too. If you’re in the Java world, and you like J2EE, that’s fine; if you like Spring and Hibernate, that’s fine too. But, do yourself a favor and don’t go work for a company that uses an ADABAS database management system (a creation of the 70’s). I have no idea how well it works (or if it still does), but you’re more likely to spend your time dealing with unique quirks than innovate, and you’re very unlikely to be able leverage the specific know-how in your next job.

Some final thoughts

As people decide on their next (or first) career move, there are a multitude of factors in the decision. There’s the compensation one will be getting; there’s the distance one needs to travel; there’s the people one would be be working with; and there’s one’s belief in a company’s financial success. All these factors weigh in when making a decision.

But, to build a robust software career, it’s important to figure out where the market is heading, and to align one’s moves with that. The software industry is moving fast, and staying behind is typically a bad strategy, even when other factors weigh in.

1I believe there are still some million COBOL programmers in the market. If you like the idea of a career path of being one of those million, this post is not for you.