How I Describe What I Do

Created -

To people outside of the software community, it can be hard to imagine what an engineer actually does. All they really have to work with is stereotypes (sitting at a computer in a windowless room/cubicle for hours on end with no social interaction) or characterizations in movies (i.e. The Social Network).

Most of my friends aren't software developers so I get tasked with explaining on a surprisingly regular basis what I, and other software engineers, do at work. Obviously there is no specific answer that will cover everything for this. Developing cryptographic applications is different than building a web app which is different than your casual weekend project. However, these can all be reduced to a common thread.

Basically, as a software engineer I get paid to solve puzzles.

Nearly everything in development can be boiled down to puzzles of varying complexity by identifying what you want to accomplish, what you have available, and what constraints exist.

For example, in Sudoku you want to fill a 9x9 box of squares with the correct number (1-9). Some of these are already filled in for you. You can only use each number once in a row, column, or 3x3 sub-group (there's probably a real name for this). You're supposed to use logic and work within the constraints to narrow down your options and gradually solve the puzzle, building up more clues as you fill in spaces.

You can apply the exact same formula to a problem in software development. Using Google as an example: you want to let people find web pages containing key words or information they specify. All you have to work with is the search terms they give you, plus let's say you have a list of all the sites to search. This whole thing must be fast, so you can't question every site about what info they contain every time someone makes a search.

Maybe if you had a directory of what information each site contained (an index)? How would you make this index? There are a lot of possible ways. Ask everyone nicely to give you information? Use a web spider to read every site in the world and take the information yourself? When you think you have a solution, you can move on to how to actually find, read, and display this information before a user will be happy.

You solve these puzzles by looking at everything you have at your disposal, think of different solutions, and picking the best one, just like you'd work through a Sudoku or crossword puzzle.

Nearly every company in the world these days touches software somehow, and as a result, everyone has puzzles like these to solve. They vary in how interesting or difficult they are, but they all need someone to solve them. This leads to companies hiring people like me or the large handful of other developers in the world to come in, analyze the puzzle, and give them a solution in the form of computer code.

I love this type of work because (despite the common stereotype of monotonous drudgery), what you do changes every day. I could solve one puzzle one day and face a completely different one the next. Some are hard, some are easy, some are downright impossible and require a lot of creativity to work around.

A lot of puzzles are too hard to solve by just one person. You talk to people a lot in software development (again, blowing away another common stereotype of the antisocial lone programmer). Another engineer may have actually just solved the same problem you're working on last week, so he could give you the answer. Even more commonly is needing to coordinate what you are doing to fit with what others are doing or what a customer wants. You are never working alone and your solutions will always end up being part of a whole product or feature.

The focus on logical problem-solving and analysis in defeating these “puzzles” in software development is why I am such a big fan of teaching math and programming at schools at a young age (see What Most Schools Don't Teach, if you haven't already).

While you may “never use calculus ever again” or “hate Java and never want to write code”, the art of solving problems is necessary throughout your entire life.

At some point your car's going to break down, and you'll save a hell of a lot of money if you can use these skills to figure out what the issue is yourself and how to fix it without dealing with a mechanic. Even if you can't fix it, you're a lot less likely to get ripped off if you can walk in to the auto shop and say “I hear a grinding when I turn the wheel, I think something's wrong with my power steering pump”.

I know this description of “solving puzzles” is an imperfect analogy for software development, but I've found it goes a long way towards clearing away some of the more incorrect myths about engineers as a whole. Less monotonous and antisocial, more creative and team-oriented.

Solving puzzles as a child was probably a very common hobby for people in this field. Now we get paid for it.


No Comments...

Add a comment

<< Back to the rest