How to Become a Software Engineer

Bryan Turner has been a professional software engineer since 1998, although his programming experience dates back to 1989. Bryan earned a Bachelor of Science in computer science from North Carolina State University. He is also largely self-taught and believes that the biggest skill to be gleaned from education is learning how to learn.

He currently works for Cisco Systems in Raleigh, North Carolina. His most visible projects there were several versions of the Cisco VoIP phone. He points out that these were niche markets at the time, but nearly a decade later the phones are still present in department stores and waiting rooms.

What is a software engineer?

I believe that a practitioner of any engineering discipline is one who attempts to solve real-world problems with available resources, guided by scientific or experiential knowledge. While "computer science" tends to be about analyzing abstract properties of algorithms, "software engineering" tends to be about building systems or solutions that fulfill some need in the market. The computer scientist's research stretches the envelope within which the software engineers may practice their art.

Why did you decide to become a software engineer?

I always wanted to be a mad scientist. When I was young, the image of a scientist working at a bench covered in bubbling beakers, tubes, and smoking flasks came to mind. It wasn't long after that I began to explore computers, which my father had brought home. With so little software available, there wasn't much choice but to learn to program them.

Some years later, as a high school student, one of my friends described me as a "mad scientist of computers" -- "hacker" was not yet common parlance. I realized that description was not only fulfilling my childhood fantasy, but it was an apt description of the job.

Are there common misconceptions about your profession?

Nontechnical people perceive this job as wizards manipulating arcane secrets, crafting magic artifacts with wires poking out in every direction humming strange noises and blinking cryptic lights. I get asked questions about everything from why their favorite website is so slow to how to change format options in a word processor. I'm simply expected to know everything that could be considered computer-related because of my profession.

Aspiring software developers regularly contact me asking my opinions about training, certification classes, college courses, etc. I invariably reply the same: Get solid, foundational, theory-based education. Don't skimp. Don't go for the quick solution that teaches you just enough to get a job in the current market. If you don't make time to learn the foundation now, you will probably never make time for it later, either.

What is a typical day like for you?

A typical engineering day consists of writing code and tests for a software module; often only three or four test cases get written per day. This may only total 100 new lines of code and a couple dozen lines for the tests. This doesn't seem like much, but the complexity of large systems requires this careful pace. This is interleaved with work on side projects, documentation, and meetings.

Tasks vary greatly depending on what mode the project is in. During the research phase, weeks may consist of nothing but surveying papers and consuming them. Surveying 100 papers to find a half-dozen to read in-depth is not uncommon. There is usually a phase where the project is being "pitched" to backers inside the company. This phase is taken up with building slides for meetings, presenting to backers, building prototypes to show the look and feel of an interface or to show that integration between critical components is possible.

If the project is funded, engineering begins. We have meetings with customers to learn their needs, discussions for everything from GUI design, data structures, even selecting custom hardware configurations or fabricating ASICs. As a software engineer, I may participate in any of these conversations. Smaller projects would require more direct involvement at every level, while for larger projects I may only meet with developers working on my module.

It is rare for me to work more than 40 hours per week. Although I have a company laptop and can work from home, I find it more productive to be in the office and participate in the ephemeral "hallway meetings" that crop up. Most projects have multiple crunch periods where milestones are due or critical failures are discovered. Everyone pitches in to get things working, but no one loses vacation or sleep over the issue. A professional environment is not like the binges I read about in startups. "Slow & steady wins the race."

What are your favorite aspects of your job?

It provides a continuous source of new challenges, many of which I would not have been aware of if left to my own pursuits. Each new project and customer has a unique perspective and some twist on the constraints. It's like solving a new puzzle every day.

What are your least favorite aspects of your job?

The professional environment does not move as fast as my personal interests in technology. Large companies tend to have a lot of 'process' to get things done. As an engineer, this seems like too much overhead and not enough productivity. None of this is particularly odious; my coworkers are friendly, management is supportive, our tools and software are kept up-to-date and there is enough flexibility to get your work done your way as long as it meets the needs of the project.

Is there anything you would have done differently while studying to become a software engineer?

Almost 15 years after college, I can say I'm happy with my education and the path it has opened for me. I think the most valuable part of the college experience was access to the library. Given the right amount of self-motivation and a curious mind, the resources you have access to as a student outside of class are just as valuable as what you will be taught in class. Make sure to take advantage of it!

What classes did you take in college that are the most relevant to your job?

The most directly applicable classes were nontechnical ones. Presentation, technical writing, marketing, and accounting. These skills have served well, but I have had little need to build on them.

Oddly, the technical classes are not as directly relevant. Calculus, discrete mathematics, logic, hardware, and other foundational theory are needed for understanding "how it all connects." While later classes like database theory, networking, and software architecture are useful for bridging the gap between the earlier theories and the real world. You need both.

For my job, the most relevant classes have been mathematics (such as functional-algebra, vector-algebra, calculus, statistics, and logic), and software engineering (specifically database theory, networking, and software architecture).

Since I work in a variety of languages and can't imagine being successful in this field without it, I strongly recommend learning several languages of different "types." Learn multiple imperative languages, multiple functional languages, multiple logic languages, and multiple database languages. It is this variety that provides a base of knowledge you will need for tackling new challenges. Learning Java, C++, and Javascript may seem like variety, but they only give you one view of the world.

What personality traits do you think would help someone to be successful as a software engineer?

Motivation to learn new things, excitement at tackling challenges, an ability to visualize complex problems, and good communication skills. These are universal among the successful software engineers I know.

What personality traits do you think might hinder someone's success as a software engineer?

A proprietary view of knowledge. Someone who won't share what they know is quickly replaced in our industry. Good engineers share and collaborate freely, and are quick to highlight the contributions of others.

Poor communication skills. You absolutely must be able to discuss your ideas and argue your views in a professional, mature manner. Logic should reign, not emotion. Many teams will include members who don't share a native language. Clear communication across these barriers is critical to resolve technical issues or personal misunderstandings.

What advice, or words of caution, would you give to a student who is considering studying to become a software engineer?

I strongly believe that each student should find passion within themselves to seek out their profession. External motivations will not satisfy you. While any job will eat up your day and provide a check every month, it is an empty activity if you are not engaged by it. A career should be something you cherish, a goal to which you strive, and a guide for personal growth. If you cannot imagine this for yourself as a software engineer, I advise you to follow the path for which it does.