Software Engineering

By Shamus Posted Tuesday Jul 28, 2009

Filed under: Programming 44 comments

A student emailed me, asking about what I do for a living. Not just my job title, but what specifically the job entails on a day-to-day basis. You know, that’s an interesting question, because I had the same question myself at that age. I loved programming. I knew I wanted to do it a lot, which suggested it might be a good career. But I didn’t have a clear picture of what a day at work would really be like. Certainly the job is more than just writing code, right?

The answer is, annoyingly, “it depends”.

The term “software engineer” is pretty loose, and ends up being applied to just about anyone who writes code. (Which is probably incorrect. Like calling a brick layer a “civil engineer”.) Rather than argue over definitions, we’ll just go with the broadest possible interpretation of the word.

I work for a small company, and like most small companies everyone has very broad responsibilities. If I worked at a big company, a lot of my duties would be split between senior and junior members. The size of your company will have a bigger impact on your job than just about anything else. Microsoft and Apple might have a very different corporate culture, but they’re very similar compared to (say) working for a company with seven employees. Having worked at both a large company (over 100 people) and small ones (less than 10 people) I have to say I like working in a small outfit far better. Maybe I’ll compare the two in another post, but for now we can just simplify it by saying your duties will become more diverse as the company size shrinks, and narrower as it grows.

Keeping this variable nature of the job in mind, here is a list of fundamental duties that will probably be a part of any Software Engineering career:

Estimating a task

Someone will come to you with a software problem.

Tiny problem: “The daily reports don’t print the full date, which is causing paperwork confusion”.

Small problem: “We need a program to scan a set of directories and delete files older than X days or larger than Y bytes”.

Large problem: “We need our software ported to run on Macs”.

Gargantuan problem: “Write a full-featured operating system”.

Your job will be to draw on your knowledge and think about how long it will take to solve this problem. How many programmers will be needed and how much time will they need? I do this on a regular basis, although it’s the part of the job I hate most. In a larger company this sort of thing is generally given to the senior programmers.

Once you give your estimate, someone else (probably not an engineer like you) will look at the problem and the cost to solve it, and decide if it’s worth it. If it is, you’ll end up doing…


This part of the job varies greatly. “Design” might mean, “sit in your cubicle and think for a few minutes before you get started”. Or it might mean, “attend meetings with other software engineers, design charts, and do extensive planning”. Generally, the bigger the problem gets and the more people you have involved, the more formal this process is going to be. You can’t begin building a bridge until everyone agrees precisely where it will be and what it will be made from. And you can’t write software until you understand how it will work once it’s complete. You need to decide what tools will be used (perhaps even decide on a particular programing language) who will do the work, and how all the parts will fit together. Alice will build the interface. Bob will write the server. Carl will write the client. Dave will port Carl’s work to Linux. Etc.

Maybe you’ll talk to people that have expertise relating to the problem. For example, I know just enough about databases to get myself into trouble. When you need to store data in a database, there are dozens of ways it can be done. Some will be ploddingly slow or consume lots of storage space, and others will be fast and lightweight. A clueless programmer can make a mess without realizing it. Whenever I do anything with databases I ask someone who knows more about databases than I do. I describe the solution I have in mind and ask if they see any obvious errors to my approach.

Note that nobody can be an expert on everything. User interfaces, databases, web applications, client / server stuff, 3D rendering, etc. You’ll probably end up specializing in a couple of them and leaning on colleagues for the others.

Once you know how the system will function, it’s time to…

Write Code

The meat of the job. You sit at your desk and type arcane symbols and indecipherable nonsense. At least, that’s what it looks like to non-coders.

You’ll hear programmers talk about using an “IDE”, which stands for Integrated Development Environment. It’s basically a word processor for computer code. While not all programming jobs involve using an IDE, it’s certainly the most common sort. You’ll type code into it all day, occasionally running the your program to see how it works.

This is the part of the job I love. It’s solitary work, and the part of the job that requires the most intense levels of concentration.

Once you finish a feature or reach a major landmark, it’s time for…


In a big company with big software, this is done by a team of people. In a small company, it might just be a couple of people. In a really small project, you might do this yourself. The goal is to find bugs or design flaws. A bug is when the program does something that the programmer doesn’t intend, like always print January 1, 1970 for today’s date. Or crash. A design flaw is when the program is doing what you expected, but it’s still not satisfactory for some reason.

Tester: The program runs really, really slow on graphics cards with only 64MB of memory.

Programmer: I didn’t know you wanted it to run on graphics cards with only 64MB of memory.

In my experience, design flaws are usually the result of an oversight that happened during the “design” phase. You’ll end up going back to the drawing board and fixing problems you (or your boss) failed to anticipate. Sometimes this will be because you didn’t think the problem through. Sometimes it will be because you weren’t given clear objectives. Programmers and their managers blame each other a lot, and you can always find amusing or tragic anecdotes about friction between the two. This conflict is one of the ongoing themes in Dilbert. In truth, designing software is a big job and any decent-sized project is bound to have lots of misunderstandings like this.

And of course testing leads inexorably to…


The old axiom applies: “Programming is debugging.” Your program will fail in various ways that you never discovered, and you’ll have to fix these problems. This is the part of the job that requires the most intuition. Once your program goes through testing, you’ll be given a list of problems, errors, bugs, and crashes.

The trick here is that people will explain problems to you, and their description will often be confusing or misleading. They aren’t tying to annoy you, they simply don’t understand your job, which is fine.

Hey, when I select an option from the menu, nothing happens.

Hm. You try it yourself, and it seems to work fine. What’s going on here? You’ll spin your wheels for a while. Eventually you’ll go and try to duplicate the problem on the tester’s computer. You try it, and it still works just fine. You ask the tester to show you the problem while you’re looking. They do, and you notice that they’re using the keyboard to navigate menus instead of the mouse. Sure enough, highlighting an option and hitting the enter key doesn’t do anything. You forgot to set up the keyboard handler, because you always use the mouse for stuff like this.

This is where you’ll really get better with experience. A senior and junior programmer might both be equally smart, and (if they’re using a new language) they might both have the same amount of experience with the given language. But the senior programmer will be able to cut to the heart of a misunderstanding like this much faster. As in, the new kid will spend hours on a wild goose chase and the old-timer will perceive the root of the problem in a few seconds.

Do not scorn the older programmers. If you’re fresh out of college, you might be tempted to think of yourself as the New Hotness because you can work longer and faster than someone in their fifties. You might even have the hubris to imagine you’re “better” because you can output (say) twice as many lines of code. But I would urge you to keep your hubris in check. In college, they never teach you just how much you don’t know. You will spend the first few years of your career learning this the hard way, and it will help a great deal if you don’t make a fool of yourself in the process.

There are other duties that orbit these basics. Maybe you’ll dabble in hardware. Maybe (like me) you’ll end up writing a lot of documentation. Maybe (like me) you’ll be called on to take technical concepts and explain them to non-technical people. Maybe you’ll specialize in writing software for use by people in your company. Maybe you’ll write software that is sold to large clients. You might even end up working on software that gets put in a box and sits on the shelf at Wall-Mart. It all depends on where you end up and what they decide to do with you.

So that’s the job. After all these years, I’m still comfortable calling it “a good gig”. It’s not for everyone, but there are a number of people who can derive a lot of satisfaction from the work.


From The Archives:

44 thoughts on “Software Engineering

  1. That was a REALLY good description of what it’s like to be a “software engineer”. You are also an excellent wordsmith, Shamus.

    I jokingly complain to my husband all the time that his job isn’t sexy enough. Have you ever tried explaining to a nontechnical person what a SCM (source code management), build person does?

    I usually resort to, “He makes the audio system in your computer work properly.”

    Which, alas, still isn’t very sexy.


  2. Ian says:

    You don’t have to do customer support?

    Lucky, lucky you :).

  3. Arthur says:

    A friend of mine who works in software managed to get around the “not sexy enough” problem, because he ended up in a position in negotiating his contract where his employers let him choose his own job title, subject to their approval (so he couldn’t pick something wildly over-the-top or unhelpfully vague). He convinced them to approve “Shadow Architect.”

  4. Pederson says:

    Re: Debugging

    The most uncomfortable release cycle will be the one where you make a major change, it goes to QA, and QA never says a word. Now, if your testers are good, it probably works: hooray, you did a great job! But, cynicism is a job skill in engineering.

  5. Legal Tender says:

    Thanks for offering us a look into your daily routine, Shamus. I’ve always been wondering what it is exactly that you do that it leaves you enough free time to do all the amazing things you do here.

    I’m even more impressed now.

    It does sound very much like my job description. Except for the fact that mine doesn’t have anything to do with coding :p

    I’m an environmental engineer and my last couple of projects have involved taking all the tech stuff (process flow diagrams, energy and mass balances, etc.) for relatively complicated processes (e.g., combined cycle power plants)and make them easy enough for non-techs to understand everything’s that’s going on under the hood, so to speak.

    Right now I’m working with a USEPA modeling package (MOBILE6) that is in dire need of a decent GUI. That thing is…I mean, here we are in 2009 and you still have to make your own input file to make the thing go. Go programmers go! and make that thing a little easier to use (please?)

  6. Logicaly_Random says:

    As someone who hopes to become a programmer, that was a really good and concise description of what programming is about. I do have one question though, how much does college not teach you?

  7. rofltehcat says:

    Sounds interesting.
    Should I be happy or sad that I won’t have that much to do with the programming business as a mechanical engineer (well, when I’m finished studying).
    But I guess I’ll still have contact with developers some way or another I guess, after all machines need to be controlled.

    And then I will bug you with countless little changes, bug fixes and additions to your programs >:D

  8. Groboclown says:

    A really good summary, but one point you didn’t go into detail on was documentation. Most jobs require some level of writing up documents that describe what the system does, or what your code does, or how people can use your code, or (gasp) instructions for the users so they can use the software.

  9. Dave says:

    A born-in-the-USA programmer, programming, in the USA. How nostalgic.

  10. Groboclown says:

    @Dave: Even though your comment is a tad snarky, you do make a good point. There’s a move on “programmers” to take on more of a management side, in particular in the form of managing off-shore teams.

  11. Rutskarn says:

    Huh. Interesting.

    This is another one of those professions that I can tell, objectively, can be very rewarding and satisfying to the right person and would probably drive me insane in a matter of hours.

    To be honest, that’s a long list of professions.

  12. Spider Dave says:

    Man, now I’m stoked on finishing my degree. Hopefully the work experience program will teach me some of the stuff school missed out on.

  13. radio_babylon says:

    i hear you about that “small company, broad responsibilities”… i work for a 4-man company. and two of those men are the bosses. which means my responsibilities are “every damn thing except sign the checks and look good in a suit”…

  14. Jeremiah says:

    @1: Leslee
    I run into that all the time. I engineer monitor/control systems for utility companies. But that’s kind of hard to explain to most laypersons, so I usually resort to “I make stuff for power companies.” At least my wife can point to something on a shelf at Best Buy and say “I had a hand in that.”

    On the other hand, telling someone I get to trip 34.5kV breakers is pretty awesome sometimes. As long as it’s not an accident. For some reason power companies don’t like unexplained outages. Go figure.

  15. SireCh says:


    they don’t really teach you about the tools that you’ll regulary use, like really mastering your IDE, version control, bug tracking, …

    But that’s just infrastructure, and you’ll get that fast. Something that will help you a lot is improving the way you express yourself (both orally and written). Explaining a complex concept to other persons (that might not be programmers) is difficult, and the best idea will often get ignored if you can’t explain it to others.

    Other thing that you may not like is that big companies involve a lot of politics. I’m glad that I’m working at a small company right now.

  16. Reluctant DM says:

    I’m officially hold the prestigious sounding title of Senior Systems Analyst. At a larger company I would probably be working with clients to design systems. Here I am an end to end architect, designer, tester and support tech. I work with the clients to establish the scope and requirements of a projects. I then do some design work. Next I code. Then I test & debug. Next I release my code and then spend the next n years supporting it! :) My bottom line for perpective IT students is that the job title means nothing. Ask about the responsibilities where you are working. I love my job but someone who didn’t like to code (and just wanted to design) would hate it.

    Also, Shamus you should look into Agile methodologies. We’ve started using scrum here and have found that it has significantly cut down on the number of “design flaws” in the software.

  17. Dylan says:

    As a soon to be college (UK) boy. I am very interested in the idea of programming and am quite interested in the idea of pursuing it. But with not even on language under my belt I was wondering. Were to start?

  18. ChrisChris says:

    I’m currently studying to become a software engineer in Germany. Right now i’m not sure if this was a good choice.

    So after reading Shamus’ post and the comments i can’t help but wonder. What kind of person do you have to be to enjoy working as a software engineer?

  19. TehShrike says:

    In my opinion, college courses miss out on some of the really important aspects of programming.

    You may come away from a university a really smart coder, but you will quite probably have these flaws:
    * You will have never written code that was still being used/maintained 2 years later
    * You will never have had to work on a long-term project with a group of other people

    And those experiences are what make you a really useful developer (IMHO).

    If your only interest is in becoming a good coder, find a programming company and offer to work for free/minimum wage for a few years (as opposed to going into massive debt to go to college).

    You’ll work all those bad coding instincts out of your system, and have some real proof of skill to show future jobs.

    Or, you can spend lots of money and time at college, and then get out and have to do essentially the same thing :-P

  20. Doug O. says:

    ChrisChris asks “what kind of person do you have to be to enjoy being a software engineer.”

    Short answer: “One who enjoys puzzles, logic problems, and the occasional (!) randomizing event.” [“Hey, we wanted the exact opposite of what the spec calls for. Can you have that by Tuesday?”]

    I notice a call-out to scrum/agile, and want to second that. Test-Driven Development [write the test *first*, then write code that makes it pass. Don’t be afraid to refactor large areas, because your tests will tell you if you break something. When you have tests covering all the spec, you’re done, ship it. This was really too long for a parenthetical comment.] has utterly altered the way I work, and it’s a Very Good Thing.

  21. Hugo Riley says:

    Geez, you just described my job better then I ever could. I’ll just link here if somebody ask me about my job.

  22. mookers says:

    Excellent description Shamus. Except I wouldn’t call a 100-person company a large one. Maybe medium, but still bordering on smallish. A large company is a multinational with thousands of employees and entrenched bureaucracy where it takes four weeks just to get approval for a change in the code somewhere.

    And great comment about the young upstart bragging about lines of code written. One thing they don’t teach you in school is that (C-style shorthand obfuscation aside) more lines of code usually makes it harder to understand and more prone to errors. I am constantly trying to cut down on my code size, alas with limited success…

  23. RedClyde says:

    I’m with Hugo Riley, it felt like you were describing my job (although I’m still just an intern).

    I think a skill that you rarely, if ever, put to use in college but that is very important in the real world is understanding other people’s code. Code can be very confusing when you weren’t the one to write it, especially in big systems where you’re not familiar with all parts of it.

  24. Small problem: “We need a program to scan a set of directories and delete files older than X days or larger than Y bytes”.

    Sorry, but that’s not even a problem, it’s a one-liner in any Unix. The ‘find’ program supports those conditions and many others, so it ends up looking like this:

    $ find thedir -type f -mtime +X -size Yc -exec rm -fv {} \;

    With GNU find it’s even easier, “-delete” instead of “-exec rm -fv {} \;”

    I was very pleased to find my university makes this kind of shell problem solving a core unit for software engineering degrees.

  25. RedClyde says:

    @Dmitri Nikulin: Except it would probably go like this:

    Small problem: “We need a program to scan a set of directories and delete files older than X days or larger than Y bytes, on Windows XP“.

  26. Blake says:

    When I want to sound fancy I tell people I’m an Interactive Entertainment Software Engineer.
    Most of the time ‘Games Programmer’ is sexy enough that people don’t ask for more.

    I’ve only been at it a year (I’m only 22) but I can certainly say the job doesn’t differ much from your description.

    Probably the biggest thing is “Design Flaw’s” come up all the time as the publisher decides near the end of the project something might look better if we did it X way instead of Y way causing you to rewrite a system that took a while to put together.
    Then they say “actually put it back the other way”…

  27. SEGEEK says:

    I’d say the vast majority of stuff you do as a software engineer isn’t covered by school. But in engineering you don’t go to school to learn everything, you go to school to learn how to learn. Once you really understand the basics of computers and software you will get a feeling for how things work. Once this happens you will pick up new stuff very quickly, just don’t be afraid to experiment a bit and see what happens.

    In my mind one of the most valuable skills a developer can have is learning to look at the symptoms of an issue and logically deducing what could be the cause. This lets you systematically test each possible cause until you find the issue. This makes you much more valuable than the guys that have no clue how to troubleshoot issues.

  28. food4worms says:

    @Doug O.:
    I second that. Test-driven development is simply the best way to go. I got it through Extreme Programming (XP) — which is another excellent agile methodology, by the way. What I didn’t expect was how well test driven developent focused my object design. It was like when I put on my first pair of glasses and could finally see what the teachers were writing on the chalkboard….

    Another axis you young’uns should know about (besides the small/medium/big axis) is IT/Consulting/Software Development. And if I wasn’t fried from a roll-out right now, I might be able to explain the difference! ;-)

  29. Hipparchus says:

    This may sound weird, but that sounds a lot like plumbing.
    Older plumbers may not work as fast as younger ones, but they can get to the root of the problem faster through intiution. Plumbers also have to deal with customers who don’t know how to explain their problems, nor understand the solutions. So plumbers have to have a lot of people skills if they are going to be talking to their clients. And “debugging” is almost always necessary, as something may go wrong. And just one small pipe or valve can ruin a whole system, so it requires a lot attention to your work. Unlike programming though, plumbing has a time limit and a customer breathing down your neck. Oh, well.
    Interesting the similarities, aye?

  30. SteveDJ says:

    While you covered the area of Debugging, you could have also mentioned the whole process of “Bug Fixing”.

    In larger companies (and maybe small ones, too?), the list of bugs will first be reviewed by a group of developers, testers, and designers. They will look at the bugs, and decide “Yes, we will fix this one”, or “No, we don’t want to fix that one” (either due to lack of time, or they feel the fix would destabilize the code too much).

    It can be frustrating when you know exactly what is wrong with the code, and exactly what you’d do to fix it, but the bug is rejected anyway so that you aren’t allowed to fix it.

    Of course, when you are allowed to do the fix, sometimes your fix must be a bit creative (and not the direct fix), so that you don’t cause other problems with existing code. There is definitely an ‘art’ to some coding that you don’t learn in school.

  31. TehShrike says:

    @SEGEEK: if you don’t learn how to learn until college, you’re in big trouble. :-P

    I was homeschooled, and have seen plenty of peers who were homeschooled. The first few years of education (ages 4-6, mebbe) are for getting them in the habit of learning.

    The rest of their schooling is just using that skill to absorb knowledge and talents.

    The fact that most kids don’t get forced to study and learn until college is a pretty serious issue.

  32. Eldiran says:

    Thanks for the interesting read, Shamus (it feels redundant saying that because all the articles here are interesting). I’m in my second year of college as a CIS major, so talking about people who aspire to join the vague entity of ‘programming’ hit the nail on the head.

    Not that I haven’t experienced what you described — I’m currently the Flash-er of a website design company. (I need a better way to describe my job…) And my job there pretty much fits your description exactly.

  33. Zapata says:

    … but for now we can just simplify it by saying your duties will become more diverse as the company size shrinks, and narrower as it grows.

    In order to discourage the possible notion that larger companies might not be as fun to work for, I suggest the substitution of ‘team’ for company. My company has 120,000 employees, but I wear many hats on my current project. Other projects have had me doing the same thing over and over. It’s about project/team size, not company size.

    Also, regardless of size, seniority will affect how diverse your responsibilities are.

  34. MrPyro says:

    RedClyde: Export the directory as a share, mount it using Samba on a Unix/Linux machine, then you can use find :)

    TehShrike: one of the best projects we did during my degree was to form a small software house, with several programming teams that had projects that ran for the length of the university year. It was good experience of working on long-term projects in groups that hadn’t been covered anywhere else. The project was started because one of our lecturers started asking external employers what skills they generally had to teach new graduates before they were useful.

  35. Unconvention says:

    Your program will fail in various ways that you never discovered, and you'll have to fix these problems.

    1. Any program can be reduced in size by one line of code.
    2. Any program contains at least one bug.

    By reiteration, any program can be reduced to a single line of code which doesn’t work.

  36. Telas says:

    Thanks for the job description.

    I’ve worked for a large computer manufacturer north of Austin, and for a startup which went from 80 employees to 300 to back to 60 and up to over 500 during my time there.

    It’s not just size, but corporate culture. If the culture is good, you will enjoy working there; nothing is better than working with a bunch of folks you both like and respect. I was in the military, and it’s a similar feeling to being in a good unit. You swagger instead of walk, and you don’t hesitate to do whatever is necessary because you love your employer and fellow employees. If you haven’t been in a situation like that, it may be hard to understand.

    At that startup, I’ve put in 80+ hour weeks, worked over vacations, and asked to be rehired after being laid off (repeatedly), simply because I loved working there.

    But I quit that large computer company because they wanted me to work the early shift on both Christmas and New Year’s Day. It’s just not the same.

  37. Logicaly_Random says:


    print “hello world

    There. Can I work for google now?

  38. Bryan says:

    RedClyde / MrPyro:

    Install Cygwin. Run find. (Just be sure to get the Cygwin find, not the DOS/Win find, which is much closer to grep.) Done. :-P

  39. Cuthalion says:


    In my experience, writing a program to do it might be faster than installing Cygwin.

  40. Zapata says:

    print “hello world

    There. Can I work for google now?

    Nope, he was right. You didn’t specify the language and in any language I’m aware of, you’ve got a syntax error (which breaks the ‘cite’ tag).

  41. Logicaly_Random says:


    It’s not suppose to work.

    “By reiteration, any program can be reduced to a single line of code which doesn't work.”

  42. Bryan says:

    Interesting breakdown, and some very good analogies.

    On the hardware side, when I’m asked what I do, I tend to tell people that I’m a middleman.

    The circuit engineers do the physics and decide what the circuits need to do, but the fabrication people just want a picture of where the parts sit on silicon. I take the raw data from the engineers, figure out where the parts must go, hook them up in a CAD tool (Computer Assisted Drafting), test them to make sure they do the job, fix my mistakes and provide the picture that the fab people require. In many ways, the process is similar to yours, Shamus, although the means are different. Along the way I may write short bits of code, point out mistakes in the technical drawings and tools, or write documents about various design styles to teach others.

    Or sometines I just say that it’s like building a jigsaw puzzle with design rules instead of defined edges.

    EDIT: And every 2 years we draw the same stuff 30% smaller.

  43. Seneschul says:


    Small problem: “We need a program to scan a set of directories and delete files older than X days or larger than Y bytes, on Windows XP”.

    waRmZip.wsf for the win(dows machine)

  44. Unary says:

    Alright, I’m late to the party here, which is too bad.

    I went to college on a physicist scholarship.

    I graduated college with a secondary education degree (ie, qualified to teach high school).

    I’ve been working as either a programmer or a DBA for 10 years now (after spending 3 years teaching).

    So, all finishing college does, is show that you can finish something. I know how to learn, I can learn anything, if someone is willing to teach me.

    I loved my teaching job, I hated the disciplining part.

    A friend of mine told me (literally) , “You can think in a straight line. I can get you a job as a programmer. It won’t pay much, but can you start next week?”

    Over the next few months, I learned SQL and HTML and JavaScript and some Perl, and everything you need to know to develop/debug/troubleshoot an eCommerce engine from storage layer to presentation layer.

    I decided I liked the storage layer the best, and started to lean towards that. Now, I’m kinda the development group DBA…I make their queries run faster. This job provides the most immediate gratification ever…either the query is faster, or it isn’t.

Thanks for joining the discussion. Be nice, don't post angry, and enjoy yourself. This is supposed to be fun. Your email address will not be published. Required fields are marked*

You can enclose spoilers in <strike> tags like so:
<strike>Darth Vader is Luke's father!</strike>

You can make things italics like this:
Can you imagine having Darth Vader as your <i>father</i>?

You can make things bold like this:
I'm <b>very</b> glad Darth Vader isn't my father.

You can make links like this:
I'm reading about <a href="">Darth Vader</a> on Wikipedia!

You can quote someone like this:
Darth Vader said <blockquote>Luke, I am your father.</blockquote>

Leave a Reply to Ian Cancel reply

Your email address will not be published.