I recently had the chance to chat with a high school honor society about the wide and wooly world of software development. For me, this was a rare opportunity to consider the industry as it appears from outside the bubble. I left with plenty to think on; hopefully everyone else felt the same.
I’m sharing the transcription here as a resource for anyone considering a career in software—and as an open invitation to other developers to join the conversation. Without further ado,
I didn’t start in Software, which is as good a place to start our conversation today. I played with computers in high school, sure, but I spent college studying mechanical engineering. ME cycle times are long—once you’ve designed a part it can take months to get a prototype back; more if you’re building something exotic—but in software you can test an idea out in a few hours and have it to your customer tomorrow. I appreciate the fast feedback. You can make lots of problems when you’re moving fast, but you can fix them quickly, too. So software it was.
The thing to remember is that you’re rarely as locked in as you think you are. When you’re tired, burned out, and ready for something new, there’s usually a path open. It may not be easy, but it’s there.
That being said, there are a thousand things you can learn and you’d go crazy trying to master them all. It’s a little well-worn, but Joseph Campbell had a good point: “find your bliss.” Or, if your bliss is hiding, invest in foundational skills that you can leverage in many different settings. Which is a long way of saying that even if you’re angling for a career in software, study hard and pay attention in English class.
Everyone loves this answer, but “it depends.”
Last night I met up with a friend who’s been studying at a code bootcamp. Three months ago she’s a full-time accountant. In a few months, if her job search goes well, she’ll be a full-time software developer. Having a degree in computer science certainly won’t hurt your job opportunities, but there are jobs in software development that don’t need any degree at all.
So, it depends. What are your priorities? I went to state school because it was big and cheap. That meant lots of opportunities—in coursework, internships, and extracurriculars—and not much debt. But if you’re looking at PhD track or trying to get funding for a startup in Silicon Valley, you’ll have an easier time with a big name like “Carnegie Mellon,” “MIT,” or “Stanford” at the top of your diploma.
Hiring varies a lot, mostly across companies. Startup companies may talk to you over the phone, run a coding interview, and give you an offer at the pub. Older, established companies will have a Human Resources (HR) department with an Applicant Tracking System (ATS) and a slow, ugly front-end website where you can submit your resume, a cover letter, and three pages of demographic data to apply for the job.
Pretty much everyone has a jobs page, though, where they’ll list present openings. These are great places to find the skills the company may be interested in and how their hiring process works. Check them out. If they don’t have the details you’re curious about, email the company and ask. Hiring great developers is hard, and most of us are happy to hear from a prospective candidate!
There’s this picture in the popular imagination of a programmer sitting at their desk all day just opening and closing text files, and some days are like that. But we don’t always know what to write in those text files, which is to say that we don’t always have ready answers to whatever problems we’re being asked to solve. Before we sit down to write, we usually need time to read up, talk things over with a product manager or our customers themselves, and bounce ideas around with our colleagues.
Much of the day, then, is spent learning what we don’t know. Googling, reading up on Stack Overflow, meeting with our teammates, bosses, and so on, until we’re out of bad ideas. At that point we’re ready to start on what we hope is a good one. Then we take it as far as we can, discover it probably isn’t quite right either, crumple it up, and start all over again. The dirty little secret is: we’re usually much better prepared on the second go-around.
All that said, there are times when we do feel like we have the one right answer. We’ll charge ahead and hammer it out. But we have to be very, very careful with that. Maybe it works. Sometimes it does. But odds are that it won’t work as well as a solution that our colleagues and customers have challenged and bought into.
That’s the day: reading, talking, listening. And then those text files.
Always knowing the answer!
Kidding. If I only get one, I think it’s curiosity. Communication is a close runner-up—compassion, too—but given all the things that we don’t know, taking joy in discovery and learning new things is absolutely crucial. Now, those joys still need to benefit your team, your managers, your customers, and so on—“how can we solve that? Could it work better if?”—but without that curiosity you’ll never get there.
Curiosity, communication, compassion. Whichever it is, you’ll notice that none of them are particular to software. They’re attributes that will help you wherever you are, whatever you do. And better yet, they’re ones you can practice and actively develop.
This varies a lot with company and role. At larger companies you’ll tend to work 40 hours a week, maybe a bit more if you’re on-call or facing a deadline. It can be more—quite a bit more—at a hungry young startup, but never forget to save time for yourself.
I’ll share some advice from a point in my life when I was working nights, weekends, all of it, on what was basically my dream job. We had an unlimited vacation policy, which is startup code for “no vacation”, so I wasn’t taking any. At one point my boss took me aside and chided me. “Burnout is real,” he said. I didn’t believe it at the time, but he was very, very right. When I left the job all I wanted was to get as far away from it as I could. Even if you love your job, and you should, always make sure there are room for other things in your life.
Like travel. If you want to travel, angling towards sales can get you out working with customers and solving problems for them on-site. There are also more marketing-oriented roles: developer evangelists, for instance, who spend a lot of time at conferences and trade shows talking up the company’s products or services.
Then there are jobs, and most of them are this way, where you’ll be in the office 9-5 just working on your projects. Even then, jobs tend to be pretty flexible. It’s a great time to be in software development. Hiring great people right now is hard enough that most managers will go out of their way to help their employees do what they need to do.
When you have to write an essay, do you do it all at once?
One hand went up in the back. Yeah, the back. I know. But I know better than to doubt the back row on geography alone. Writing it once is optimal, and if you’re that student that ships the first draft (and lives with the consequences), well, power to you.
OK, we’ll talk about that after the class. But usually, you don’t. You write an outline and shuffle it around until it feels right. Then you write a draft, and either the deadline’s in an hour and you turn in whatever you’ve got, or you throw it out and write a better one the second time around.
Software’s like that. You throw it away, often, because it’s cheap to throw it away. We drove over a bridge at the Tacoma narrows last weekend that’s a 2.0 because the original met the wrong gust of wind and fell into the ocean. That’s traditional engineering for you. But in software, you get used to being wrong and trying things over again.
Even if you’re messing up, though, it’s important to make sure everyone knows what you’re doing and why. That’s how teams work. But as a software developer it’s also important to think in very precise terms about what you’re about to ask a computer to do.
You all know that the world’s built on software: stoplights, class schedules, college admissions—pretty much every technology you encountered on your way in to school today had some software element that may or may not have known anything about you or your environment. Take a step back, though, and think about the implications.
If I want to help you bake a cake, I’ll write you a recipe. You’ll follow it and voilá! Out comes a cake. If I leave something out, you’ll do your best to fix my omission. In other words, you can absorb some fuzziness and still get your cake. If I’m writing software to bake that cake, though, that leeway disappears. I hand you a program, you plug it into your computer, and hit “run”. That’s great for you. You don’t need to know how to follow the recipe. You just need to have it, and something—a computer—that knows how to follow it. Then, out comes a cake.
But I have to be very careful about what I’m telling it to make. If I leave off the cook time, the computer may bake charcoal, or just burn the whole place to the ground. When you’re the one running my program, recipe, whatever, you’ll catch those stupid mistakes. The computer, not so much.
This is a great question. You’re always going to be making trade-offs. Some things need to run fast. Some of them can’t use up much memory. Most of the time you just want to make your work easy to read, understand, and change or delete. Figuring out how to solve a problem within those limits take creativity.
Now, there are companies and people that may try to hand you a very detailed plan and say, “go do this,” assuming that you have that One Right Answer at the get-go. That you won’t learn anything along the way. Much better, I think, to set the constraints and then give the programmer as much freedom as possible in how they solve the problem. There’s such a thing as ‘too creative’, but there are lots of tools and processes out there to catch and address that before it becomes a problem.
The million dollar question. Kidding. Usually less than that. But you should be getting paid enough that you don’t have to worry about it, and enough to make sure your bosses won’t be wasting your time—
And the bell rang, right on schedule.