What do software engineers actually do?
People without engineering backgrounds are often a bit mystified by what engineers actually do. What are those coders talking about and why is it taking so long? As a software engineer, I've encountered this attitude pretty frequently.
So here's a primer for non-engineers about some things software application engineers typically do, and why projects can take a long time, and what engineers care about.
1. Design. Good engineering is about good design. Engineers have to figure out how to structure their programs. You can spend hours, days, or weeks doing this--depending on the scope of the project. For a fairly complex application, I'll probably restructure my program a few times. For example, when programming, you can make classes representing different kinds of objects. Classes can have child classes that inherit their properties. Imagine a clothing store application: you might have a class of Apparel, with child classes of Shirts and Pants. Or maybe you structure it another way. That's a simple example; the design decisions get more complex, and engineers have to figure out the optimal way to architect their program. (That's why we're sometimes so frustrated when plans or functionality changes midway through a project.) Certain programming languages or programming frameworks might come with limitations, and these need to be worked around.
What are some things engineers consider? We try to keep code modular--so bits of functionality are isolated and they can be removed or added from a project without breaking the rest of the code. We try to minimize repetition--and that means writing classes, functions, etc. in way that makes them reusable. In some cases, we need to optimize our design so our programs perform quickly. This might mean minimizing the number of instructions and loops in a program, or streamlining a database.
2. Research. Many practical engineering problems have been solved already, so engineers need to research available existing solutions, tools, and libraries to use. They also need to research what the best practices for a particular task are. For example, take web programming. There are tons, tons, and tons of tools to help engineers build web applications. Here are some examples of topics a web engineer might research:
- What web programming framework - Rails, Django, CodeIgniter, or something else - do I want to use? A framework is basically a set of pre-written code/libraries that make doing particular tasks (such as web applications) easier, but they of course enforce a particular way of doing things. All these frameworks come with pros and cons, and all have ideological fans and detractors, so the decision isn't trivial. Heck, maybe Wordpress is the way to go.
- What plug-ins do I need for my framework? Let's say you've decided to write an application with Rails. Well, there will still be many existing libraries to choose from for functions like searching or image management.
- How do I solve this problem with displaying dynamic non-standard web fonts? There are 10 different possible solutions, and I need to pick the best one.
- I'm building an e-commerce application. What security concerns do I need to worry about? How serious are these concerns?
- What's the best way to integrate Twitter and Facebook into my website?
- I'm expecting high volume traffic for my web application. How do I make sure it can withstand that load?
3. Trying things, realizing they won't work, and starting over. Sometimes we don't know how difficult a task will be until we research it and try it. So time can be spent chasing false trails and going down the wrong road. That's why experience is so valuable--you know the pitfalls and the best solutions.
4. Installing stuff. Getting the engineering environment setup. Believe it or not, but this can be a big headache. Sometimes installing libraries or programs you need can take an entire day if you run into a thorny issue. Engineers might also have to tackle difficulties with the tools they use--such as version control systems. An engineer might have their files in a version control system, screw up that system, and then have to spend hours fixing the problem.
5. Solving really stupid bugs. Projects often take longer than expected because of silly mistakes and bugs. A dumb bug resulting from a buried typo could take half a day to solve. Often, when working on a project, something will suddenly break. The engineer is mystified and needs to hunt down the culprit of the fault. Maybe this will take a second. Maybe it will take a whole day.
6. Refactoring and improving code. Your code can almost always be better. Engineers can therefore spend a lot of time changing around the code, restructuring things, optimizing an algorithm, clarifying a few lines here and there, tweaking a feature, so on, and so forth. It depends on how much of a perfectionist the coder is.
So, those are some things we engineers do and care about. That's not all of it, of course. And the main task is still simply writing code!