We Need You
Motivations
I put the luggage in the trunk and got into the Uber. I wasn't quick enough or conspicuous enough in putting on my headsets, and the driver asked the usual question:
"Where are ya going?"
"Tokyo," I said.
"Oh, fun! Business or pleasure?"
"Both?"
"How long will you be there?"
"36 hours."
"36 hours! What line of work are you in, if you don't mind my asking?"
"Software."
Then the predictable question arrives: what would I recommend the Uber driver, or their kid(s), do to break into the software business? Everybody wants some of that hustle. I understand. It wasn't too long ago that I was on the outside looking in, also! I want more people to join the industry. Goodness knows we need more people. Especially more people of color and other minorities. We need more diversity. We need more qualified people. So I abandon the podcast I was about to listen and start talking to the Uber driver. It's a conversation I've had a hundred times this year in Ubers all over the world.
There's clearly a shortage of insight (or whatever it is I will attempt to offer here) on this topic, so I've (finally!) decided to (try) writing it all down for others. I hope this helps somebody out there. If you have questions, I'm always happy to lend a listening ear on Twitter (@starbuxman), where my direct messages are wide open.
Keep in mind that I've been a professional programmer since 2002. I'm going to do my best to be helpful with these answers, and I'll draw where applicable from lived experiences. Still, a lot has changed since I got into the business. I'll try to note what I've observed.
Getting Started with Programming
This question is one I get all the time. It's hard to give a right, reliable, one-size-fits-all answer. First of all, there's no single kind of programming. That is to say, it's a bit like the world of medicine: you're going to specialize in something. Nobody does everything for every job. And that's OK. You're going to find your beautiful and trade niches every now and then as your career progresses.
So your first job is to learn to write a basic computer program. Programs often share a lot of similar concepts: variables, functions, objects, if/else, loops and other control-flow mechanisms, etc. Once you've got the hang of doing one of all these things in one language, and can kind of intuit where you might use each one, then you can take those semantics and apply them to other languages. Other languages might prioritize their unique way of doing any one of those things as being more critical in the use of the language. Still, ultimately, you're going to deal with some or all of those concepts. The syntax may frequently change while the semantics change more infrequently.
When I was a child, my dad took me to the "Barnes & Nobles" bookstore. They were (are?) a bookseller. There was an adjoining Starbucks. We were relatively poor, so we'd go into Starbucks. I'd buy a "venti-drip" - a large, 20-ounce cup of black coffee - and then wander into the connected bookstore. I'd invariably have a backpack with a clipboard. I'd use the clipboard (and paper! and pencils! and other assorted things I wouldn't know how or where to find in my own home these days) and the notepad on it, and I'd read books on computer programming. I'd scrawl notes and programs on the notebook.
We couldn't afford those often $50+ books. So I'd sit on the hard floor surrounded by a stack of books. Just chipping away, noting enough stuff down to tide me over until I could get back next weekend. Years later, when I started earning enough money to afford books, one of the first things I wanted to do was to buy books. I loved them. I stockpiled them. I had to buy increasingly larger IKEA bookshelves to accommodate them.
Later in life, when I got my first publishing deal for a book, I insisted that the publisher also give me unlimited access to their books as PDF files. I wanted to own books legally!
Today, in December 2019, the situation is very different. There's always been access to credible articles and blogs and Usenet posts on computer programming, but I feel - perhaps a bit biased - that today's programmer has access to infinitely more (free!) resources to get started. These are not scattershot little articles, these are entire courses you can take that take you from novice to a working program. There are too many to count. I'll list a few resources that I got back when I googled "intro to programming" and the name of a site.
I didn't list YouTube, but there are, of course, a ton of good options out there. If I were you, I'd look for tutorials on a language like Python, which offers an excellent, accessible introduction to computer programming concepts.
There are also so-called boot camps. These are live, in-person programs that teach you how to code. Usually, they're heavy on applied computer science and light on the academics and concepts. The goal is to get you a job. These boot camps aren't free, but they often work. They teach you enough to be useful. If you're any kind of curious, you'll be armed with your familiarity with whatever you've learned at that boot camp to soak up other, adjacent concepts then. Do that enough, and you have yourself a ballgame.
The boot camps are definitely not free - some can even be quite expensive! But many of them will defer your tuition fees until after you've landed a job. Some will also go a step further and condition your tuition fees on the very fact of you securing a job! I've never used any of these, but suffice it to say that they exist and you might research them if you're so inclined.
These boot camps are a testament to the idea that being a programmer isn't something so hard that only the unicorn geniuses can do it. People who tell you it's too tricky are trying to act as gatekeepers; ignore them. If I can do this work, then you definitely can too. I am also inherently suspicious of anybody who doesn't want more people in technology. After all, we need you in our communities.
We Need You More Than You Need Us
We need you more than you need us. Companies today are no longer struggling to find analog use cases that might become digital. They 'e digital-first, at this point. Almost all businesses are software businesses. In order to be successful, you will need to deploy software. This creates a growing market for programmers. Whoever controls the computers controls the world.
I believe that programming should be a fundamental skill, like cursive used to be, taught in every school. It's hard to imagine how something so foundational to our society - computer systems - ended up being controlled by the elite few. We need to fix this. To put back computers in the hands of the every-person.
The United States Needs You
In the United States, in particular, we've long had a talent shortage. There aren't enough H1B visas to allow technology workers to come in. We've got the demand, but not enough people, so technology companies try to bring in folks from overseas. They do this with VISAs that allow people to enter the country to do work. Keep in mind, this isn't outsourcing! They're bringing the people to work in the United States, not sending the work to people overseas. This isn't cheaper. It's markedly more expensive for American companies to sponsor people and support their relocation. If American companies could hire locally, and get the qualified people they need, they would.
Another common strategy is setting up another office in other countries with more indulgent VISA allotments. Some companies set up offices in our neighbor Canada where - generally - the cost of living is as much or more than the equivalent costs in nearby US state Washington or Oregon, and the employer also has to pay more in taxes for things like mandated single-payer healthcare. Again, this isn't a cheaper option than hiring locally. It's just what these companies need to do to meet the demand.
No, Really, We Need You. Yes, YOU.
Ignore the talent shortage, dear reader, and we still have one other, global problem. The software industry right now is slowly going through a bit of internal soul-searching. In the last decade, it's become crystal clear that the world of software is (awkwardly) dominated by men. And typically only a few varieties of men. In the US, there are very few people of color, or minorities, in software. There are very few women.
Here are some diversity numbers from Apple and Google that I pulled from a CNBC article, Silicon Valley's Achilles' heel threatens to topple its supremacy in innovation.
The numbers for all employees break down as follows: 21 percent of Apple employees are Asian, 9 percent are black, 13 percent are Hispanic, and 3 percent are multiracial. Some 54 percent are white. Women make up only 23 percent of workers in tech roles and 32 percent of employees overall, according to Apple.
Google found similar results in its diversity report: In 2017, Google's overall workforce was 56 percent white, 35 percent Asian, 4 percent Hispanic, 2 percent black and less than 1 percent American Indian or Alaskan Native, and Native Hawaiian or Pacific Islander.
It's not hard to identify some of the nefarious reasons for this result. There are more obvious reasons for this situation. Some people gatekeep. They want to ensure theirs is a more prized position by forcing scarcity of supply. And it would be nice to be able to believe that things are getting better, but the fact remains that there are bigots out there. Overt racists and homophobes and whatever. And of course, there's toxic masculinity, which seems to rear its ugly head all the time.
And for every blatant and small-minded bigot in the categories I've just described, there are several more who - I imagine - don't wake up and laugh maniacally that they just can't wait to impede the careers of women, minorities, and POCs. These people are not cartoon villain people utterly lacking in empathy. But they're human. And they have biases that get reinforced by their surroundings. These biases are there and sometimes manifest unbeknownst to their bearers.
One place where biases manifest "subconsciously" is in hiring. I scare-quote that word because I don't want to let people off the hook for their prejudices, even if - once confronted and made aware of what the results were - they wanted to undo it immediately. It's still a problem. But I want to believe these people want to get better. I certainly wish to excise my unconscious biases.
Some organizations are doing things to combat bias. One such practice is to route resumés through an independent service that strips all incoming resumés of any indications of gender, culture, or anything else, leaving only the achievements and qualifications of the person. Even well-intentioned employers end up making more diverse hires through this process. There are obvious benefits to this: an environment with a diversity of ideas and insights can produce more solutions than a more myopic one. It also makes interpersonal skills more important and results in an organization that prizes team players. But did you know that companies with more racial and ethnic diversity are 30% more likely to have financial returns above peers?
Tentpole companies in Silicon Valley are aware of the issues in hiring, and some have started to make strides in replenishing their ranks. It's slow work logistically, one imagines. Hopefully, companies hire with diversity and inclusion in mind going forward, but they still have their existing, possibly non-diverse workforce. They can't very well fire everyone and start over. The less divorce a workforce, the less inclined and welcomed diverse people will feel joining that workforce. This creates a vicious cycle, indeed.
Degree or not Degree: That Is the Question
"Alright already!" I imagine you exclaim. Maybe you didn't need to be persuaded to take that next step. Perhaps you're here because you want to figure out how to do it. What's the most straightforward path in? And, here, I don't know what to tell you. I think about my little girl a lot here. What would I tell her? I would say to her she needs a degree. Are there other ways into the business short of a degree? Sure. Tons! It's not, strictly speaking, required that you obtain a degree to work in this industry. Tons of the best developers I know don't have degrees in computer science, or - if they do have degrees, they're often entirely unrelated to computer science. I have a lot of friends who have higher degrees in physics or music, for example. Something about those two pursuits that drive people to software for reasons I suppose I'll never understand.
You have to consider what an employer is trying to do: they're trying to minimize risk. They don't want to invest in an unknown quantity. Nobody does. And, indeed, they won't want to spend at the prices organizations pay in Silicon Valley!
Anybody in this industry will tell you that there are apparently as many imminently qualified engineers with no degree as there are terrible engineers with a degree. A degree does not entirely de-risk the hiring of someone. But it's a good bet. A degree, any degree, tells hiring organizations that you can stick to a schedule (and manage time), that you have the discipline and drive to cross the finish line, that you are willing to do hard work, and that you can follow through. After a certain point in your life, those skills mean far more than whatever you learned in any particular course, whose utility will likely erode in time anyway.
One thing many schools don't teach you is how to be a team player. We'll revisit this point.
A degree solves the chicken-and-egg problem: you need the experience to give an organization confidence that you can do a good job, but you can't get hired and get that experience without prior experience. Good organizations know that an engineer never stops learning; there's no such thing as a fully-formed engineer. It's important to be well-rounded and to have a sense of what you'd reach for in a given situation, but depth comes with how applied you are how hard you work. You'll always have to learn something, someday. A good organization will encourage the learning process, not penalize it. So when, as a young engineer, you join an organization, you'll be expected to learn on the job. They know you don't have every skill you'll need to do the job. Nobody does! And, a corollary to that, by the way, is that if you truly do have every skill you need to do your first job, it's probably not a job you want to spend a long time at. Strive to find places where you can grow!
Beyond the basics of programming and computer science in general, your ability to do a particular thing is not what is represented by a degree. Don't get me wrong; if you have a focus on something like machine learning, distributed systems, or whatever else, you'll benefit from being able to show that you've had a few years studying the topic. But these fields are so vast that a couple of years doesn't buy you much in the way of credibility. There are other means of obtaining that credibility.
Remember: there's a tension that institutions of higher learning have to negotiate: ground the learner in fundamentals and theory, and hopefully give them the skills needed to participate in the industry, with the understanding that there's still a lot of learning to be done before they're useful in industry, or lean towards pragmatism with more vocational training. It's hard to do both thoroughly, and there's no right answer here. It's more about what the local market demands. I tend to think that more time learning fundamentals are critical, but I really hope people graduate with a sense that - in the real world - they will be spending time with others, and that a ton of what people spend their time doing in industry is learning how to collaborate with things like Github, Slack, e-Mail, and indeed whole software methodologies like agile programming. Some of these things are ephemeral; who knows how long Slack will be around? But their use is typical of any generation of software development.
How else can you assuage an organization's concerns about hiring you? How else can you persuade them that you've got what it takes? Remember, they're looking for people that they'd feel happy to welcome to the team. People who pull their weight. There are others - and some might argue better - ways of demonstrating these qualities.
One of my favorites today is Github. Github is a social network for developers. If you haven't used it before, then you absolutely should. Learn how the Git version control system works, and then learn how Github works. Git is a technology for managing source code. It makes it easy for teams of people to collaborate on the same codebase, hopefully avoiding conflicting changes to the codebase. Software is a team sport. Tools that better support collaboration represents significant leaps forward in the industry. A typical software project is composed of source code files. There may be one or (more likely) many source code files. All of these source code files need to be stashed somewhere so that everyone involved in the development cycle can pull down the files to their local machine, make changes, and eventually synchronize them back to the original source code, ideally without stepping on each other's toes. Git solves this (admittedly) mundane problem. Github is a service - a website at www.Github.com - that makes it trivial to create new (and free) Git repositories and then invite people to collaborate with you. If you only had Git, you'd have to install your own Git server and then deal with security for all users. You'd have to set up a computer and backup hard disks and all that. With Github, all that process goes away. You can go from idea to a new repository admitted team members in a minute. It's that fast!
Github also makes it super easy to search and surface new repositories. There are millions (tens of millions? billions?) of software projects hosted on Github.com. A good deal them are open-source - you can see the source code. Even better, the open-source model encourages collaboration. If you can see the source code, then you can use the source code. If you like the source-code - if it scratches a particular itch of yours - then you can use it as-is or improve it as you see fit or needed. We call this "scratching our own itch." Even better, you can submit the changes you've made to the code back tot he original repository. Now, everyone else benefits from the work you've put into it. This iterative approach - where random people can consume and expand upon other people's code for the betterment of the entire community - has really powerful implications.
Suppose you found a Github repository that does most of what you are dreaming of in a solution to a problem you've got. Suppose you wanted to build a bot for Facebook messenger. There's a lot of work involved in doing that. If you could rely upon somebody else's work, customizing it as required to support your use-case, then you could use a lot of the initial development effectively. All you need to do is worry about taking that source code the last-mile. You "scratch your itch," molding the code as required to support your use-case, and now you've decided you want to contribute this change back. You can engage the team working on the project. Talk to them. Learn from them. They originated the code, so they'll know the project better than you might. Perhaps they could mentor you. Maybe they could help you flesh out a solution that would be worthy of inclusion in the codebase if you were to go off and implement that solution. You can send back your changes as a "pull-request," which the team can choose to accept into the codebase or to ignore. Now, the next person who comes along benefits from both the original work and your work. Even better, your contributions to the project are documented. Your efforts have a digital paper trail. This paper trail demonstrates a lot of what most organizations or I would want out of a new hire. Can that person work well with others? Learn the codebase and the technology on the flow? Start and then deliver something? Share? And all the while maintain a quality contribution?
Github is a great way to learn more. It's a great way to level up your skills. It's also a great way to score some quality mentorship with people whose skills you admire, appreciate, or respect. Having your contributions accepted into a big project with gifted engineers is a very rewarding experience. That's one way to help persuade an organization of your worth. Indeed, if you make enough contributions, the organizations will often find you before you find them.
Keep in mind that your every line of code in the industry will not, statistically speaking, be in open-source Github projects. You may not even use Github for your source code host. Plenty of people prefer on-premise tools like Gitlab to confer a Github-like experience but hosted privately within an organization.
Another great way to help de-risk your hire, very much in the same vein as Github, is to get accepted as an intern. The easiest way to do this is through a university that facilitates them, but it's not the only way. Some organizations invite people to apply. Software companies in Silicon Valley don't pay a ton for internships, but they're useful in small doses, to give you daily, applied, software development experience. It's not a pretty job, but somebody has to do it! You learn a lot about the process, around the edges, when doing actual work with a team.
There's another channel, but I don't know if I could recommend it. You might pursue certification. I remember getting the Sun Certified Java Programmer certification back in 2002. I don't know if that certification opened any doors for me or not. I don't think it did. I don't think any company even asked about it. Today is a different world, and your mileage may vary. I suspect I would care about certification for things like cloud computing infrastructure in today's world since those are whole other worlds of complexity separate and apart from the world of programming with which programmers will need familiarity. It'd be nice to know that a potential hire could jump right into the deep end of production deployments.
Or, maybe some mix of these approaches is right for you. Work on Github when you have some free time, but also attend university. Or even do a boot camp. Find ways to demonstrate experience.
Software is a Team Sport
I want to re-iterate this as it is super important. Software is a team sport. Most software you use in your day to day experience was developed with other people. It is the product of collaboration. I know that it's easy to draw the conclusion that developers are the socially awkward, typically male, lone-hero types who surround themselves with terminals scrolling at nonsensical speeds in dark rooms, but this is all utter nonsense. Most software is written in the light of day with other people who are often just staring at a single screen trying to figure things out.
I've been in the industry since 2002, working professionally on software. It was many years even before then that I last felt confused about the tokens that I was required to type. Or the syntax I was required to use. Appeasing the compiler is almost never my problem these days. Indeed, the compiler starts to become your friend after a while; it takes away some of the uncertainty of programming and lets you focus on the rest of the process. And that is a good thing because there is a lot to focus on.
Hat tip to Josh McKenty on finding this epic document on all the ways people in organizations communicate and why they communicate.