Hear from people who pivoted into engineering.
Coding is a new gold rush of sorts. With programming jobs growing 12% faster than the market average and a high average salary, coding isn’t solely the domain of computer science majors anymore. People from a wide variety of backgrounds, from writers to teachers to small business owners, are “rewiring” their careers and taking up coding, via code academies and self-instruction. And companies are recognizing that it’s not just coding skills that make a successful software engineer: they should also know how to communicate, to empathize, and to stick with tough questions. Those with the determination and curiosity to pivot their career are just the type for the job.
We talked to a few of Pivotal’s software engineers who took a less-than-traditional path into software. Here are their stories:.
Alex Basson
Location: New York, NY
Former Role: Teacher
Current Role: Engineering Manager, Pivotal
I had taken two trimesters of CS courses in college, but that’s it — I was a math major, and my MA is in math, as well. I had never contributed to any open source projects, I’d never worked professionally as a programmer, and I had never shipped an app of my own. In other words, there was no reason at all for a potential employer to believe I had any qualifications as a programmer.
I met my friend Tim while we were teaching together — he was a Cornell CS grad, and he taught AP Computer Science. He left teaching to become a professional developer two years before I did, and when he decided to move on from his job, he put in a personal word on my behalf with his boss and colleagues. He also gave me a programming challenge: to build an iOS app that consumed the Google images API and displayed the resulting images in response to a user query. His reference plus my demo app were enough to get me an interview.
Personally, though, I struggled to believe in my own qualifications. I had been programming as a hobbyist for years, but mostly during the summers and a bit on weekends. I didn’t think I knew enough to succeed in a professional setting, and I almost didn’t apply for the job for fear that I’d be laughed out of the room. Overcoming this took the support and persuasion of my wife, who convinced me that I had nothing to lose by trying, and she was right.
Teaching influenced how I write code in that I am always striving for easier-to-read, more obvious code. As a teacher, I came to appreciate just how differently every individual understands and comes to an understanding of the same idea, and a big part of my job was learning different ways to present the same idea so that it would make sense to different people. In other words, communicating complex ideas is a huge part of what teaching is all about, and that same effort — trying to express complex ideas simply — constantly informs the code I write.
The so-called “soft” skills I developed as a teacher to be immensely valuable in my work as a consultant. Working collaboratively, working with clients from a wide range of backgrounds and skills, working with people who sometimes have different motivations and agendas all of that comes into play as a consultant on a daily basis, and I honed those skills working with adolescents and their parents, along with my professional colleagues in education.
The advice I’d give to someone becoming a developer is to build software and ship it — even small, silly apps. To contribute to open-source software. In short, to get your hands dirty and develop your programming skills through practice.
David Edwards
Location: New York, NY
Former Role: Endangered language revitalization
Current Role: Software Developer, Pivotal
Much of what WAYK (a comprehensive method for revitalizing endangered languages and skills) does to help communities is teach techniques for faster learning and teaching. Community members use these techniques to more quickly acquire language, and then to more efficiently share it with other community members. But many of the techniques we use for learning and teaching language work just as well for other domains. So when I’m diving into a new tech stack that I haven’t worked with before, or explaining an advanced concept to someone I’m pairing with, or discussing at standup how we’re going to pair up on outstanding items of work, I have a host of specific techniques in mind that I can bring to bear to move faster. (Things like, “prove your understanding by applying in a new context”, “find three concrete examples”, “prefer pairing someone with just-enough-context and almost-enough-context to pairing an expert with a newcomer”.)
Endangered Languages and Soft Problems
My advice to people switching careers is that there is no such thing as magic, and talent is often overrated. There are tricks and techniques for effective software development, just like there are tricks and techniques for cooking or gardening or getting organized, and you don’t have to be any kind of mythical talented programmer to learn them. When it gets hard, don’t lose heart — the problem isn’t that you aren’t cut out for this, you just need to learn the relevant technique. As a corollary, never forget to pay attention not just to what you are doing, but how you are doing it. When you work with skilled developers, watch for the techniques they use to find solutions, not just the solutions themselves.
Elena Sharma
Location: San Francisco, CA
Former Role: Writer
Current Role: Engineering Manager, Pivotal
Since I was a little kid, I’ve been obsessed with reading and writing — I wanted to consume and produce stories. I didn’t immediately choose to study English, instead waffling over almost ten choices, but ultimately it seemed the natural choice since I felt that English, at its core, spanned everything. I’d be studying how to think, write, and speak — nothing seemed more valuable to me.
One of the reasons I vacillated for so long about what I’d major in is because I had so many different interests. Over my college years, I started to realize that I couldn’t only take courses where the outcomes felt highly subjective, such as “furthering a discourse”. I loved the logic of my philosophy classes, and the beautiful simplicity at the core of complexity in my math classes. I took an introduction to computer science class and realized that with software engineering, I could combine creativity, communication, and logical reasoning. I was hooked.
I think there are a lot of parallels between writing and software engineering. To start with, English involved writing academic essays: given a system and its set of data (such as a novel), the writer creates an architecture that works within that system (a thesis statement about how to interpret selected pieces of the novel), having to ensure that the architecture is logical, each piece building on the previous piece by passing along the right messages. Analyzing literature meant reading between the lines and finding hidden complexity. Talking about literature meant taking large, complex ideas and rephrasing them constantly, making sure you were being clear to the consumer of your information (the person you were talking to). Creative writing meant thinking about the intended audience for the writing/product; potentially a large amount of research (like Googling, or using StackOverflow); breaking down a concept and transforming it into executable pieces. I could go on, but mainly I think English/writing and software engineering have so much overlap because they’re both about thinking.
I tell people to learn how to be comfortable being uncomfortable — you can’t store everything in your head, that’s what computers are for. Trust your gut — if you love analyzing and solving problems, then keep at it. Engineering software is often highly complex, but everything can be broken down into small chunks of logic in the end that you will be able to understand. Most of all, have fun with development: play around with technologies, research different ways of thinking, explain to others what you’re doing — you’ll learn how to talk about software engineering, and how to think.
Andrew Wright
Location: Tokyo, Japan
Former Role: Financial Marketing
Current Role: Software Engineer, Pivotal
I wasn’t happy in the financial services industry. I felt like my work wasn’t helping anyone, apart from shareholders. I spent a lot of my free time reading tech industry news and programming on the side, so I decided to try and do what I enjoyed. I had a strong urge to build things. I studied mathematics at university and when I graduated, I didn’t know what I wanted to do. I applied for a large number of graduate jobs in a variety of industries. Investment banking just happened to be one of the applications that was successful. That got me started on that career path. When I realized I actually wanted to be a programmer, I was already several years into it.
I had a family that I was supporting, so I was nervous about changing careers because I knew it would be difficult, if not impossible, to start a new career with the same salary. Indeed, my first job as an engineer was at a startup in Japan where I started out making roughly half of what I was getting before. I couldn’t have made the career change without the support of my wife, who became the primary earner for the family for several years.
A big obstacle was convincing potential employers to hire me in a role that I had no experience with. I had done some programming at high school, taken some computer science courses at university, and done some programming, but I didn’t have any experience as a professional software developer. In order to demonstrate that I could do it and have something that I could show employers, I decided to build something. Every morning I woke up an hour or two before my wife and son and worked on an iPhone app. I had to teach myself everything. The app was called My Tokyo Navi and it finds train routes in Tokyo. I haven’t touched it for years, but it still makes a bit of money even now, perhaps because it works offline. After I released the app, I used it to demonstrate my ability and managed to get a couple of job offers.
I think everyone says it but few people do it enough: network. I got my break by attending the Tokyo iOS meetup and talking with someone there. Go to meetups of all the things that you’re interested in. If you can, try to build things to show people what you can do. I chose to build an iOS app but these days it feels like everyone has a hobby app so maybe other areas would be better to pique an employer’s interest.
Bebe Peng
Location: New York, NY
Former Role: Mechanical and Applied Sciences Engineer
Current Role: Senior Software Engineer, Pivotal
I first wanted to become a mechanical engineer doing FIRST robotics after school. There’s something invigorating about building something with your two hands and seeing it work out there on the field. I wanted to design and build those things from scratch. In the workforce, I realized there was a lot less creation in the day-to-day job. There were crazy feedback loops. For example, to procure a common replacement screw that you can buy off the shelf at a hardware store I would have to create paperwork, get that paperwork approved by my management, send it to the government for funds approval, wait for procurement to come through, load-test the screw, write a procedure to replace the screw, get that procedure approved by my manager, the also get approval from the government, walk the screw from the load-testing facility to the trade workers with the procedure, and then wait for the work to be signed off. Replacing a screw took about 3 months or longer from when the problem was reported, to when it was fixed.
A Day in the Life of a Pivotal Engineer
What attracted me to programming was that fast feedback cycle. I can code a line, and literally see the results on the screen within seconds. With CI/CD, I can release reliable production ready software as often as I wish. The bulk of my previous job was getting ready for the defueling and decommissioning of the USS Enterprise. As a part of that work, I had to write a lot of procedures for mechanical work nuclear systems. Procedure writing is a lot like coding. Coding is basically a written procedure for a computer. Well-written procedures are written so that another human can easily understand.
My advice is to take time and focus on quality, and you will keep learning on the job. It’s a good investment to focus on maintainability.
Check out Pivotal’s careers page for exciting opportunities!
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.
ReWired: Stories from the Indirect Path to Coding was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
