brand new travelogue, available now at Gumroad
We got so many amazing volunteers for our Ask an Engineer panel; from all disciplines and industries, all around the world! I’m amazed and honoured, so thank you to everyone who wrote in. I had to do some ridiculous editing to make this fit the blog, everyone’s full answers are worth a read and you can get them in this handy pdf!
Every month we ask our panel of engineers a general question from a reader. Have a question? Send us an email!
Joe asks via email:
What does an engineer do day to day? Is it mostly calculating stuff or designing things or a lot time spent in the field with things like data gathering and measurements?
MOST of what engineers do can fall into four categories: Analysis, Problem Solving, Planning, and Communicating. Every engineer's day will consist of a different mix of these functions, depending on their role, level, industry, and interest...
So I asked our panel: what is YOUR role, and what do YOU do in your day-to-day?
Jim - Cement Industry, Pennsylvania, USA
I'm a manager for engineering projects and feasibility studies. I use my engineering experience, but not in a well-defined way. I had a typical day last week and it went like this:
• on the phone with Teresa in Torino. She is not happy with the cost estimate my department gave her for a new plant that her office would like to build. We talked about ways to accomplish the project objectives for
• after phone calls with people in Milwaukee, Saint Louis, and Galveston, I decide that our barge full of new equipment for the Minnesota project should come up the Mississippi with its own tug, and not tie on to another string of barges headed the same way. The potential insurance liability outweighs the cost savings.
• for the rest of the day, met with Fred and Charles in our offices to debate various ways to design Teresa's potential new plant in Italy. This is a wide-open brainstorming session with no firm conclusions, except that
Fred will assign a couple of engineers to work with me to investigate a couple of options.
Scott - Semiconductor Industry - Massachusetts, USA
To put my job into a single sentence, I figure out how to arrange transistors and wires to make them perform useful work. I do that by writing code in a Hardware Description Language (HDL). Even though the HDL model is my main responsibility, I probably only spend 5-10 hours per week writing code for it.
The majority of what I do all day, every day is communicate. Most days have at least an hour of meetings plus a good hour or two of email.
The rest of my time is spent investigating problems found by HDL simulation. Once the cause is identified, a fix has to be designed, implemented, and tested. Doing these bug fixes involves working with one to ten or sometimes even more other engineers, depending on the severity of the problem and the amount of change required to fix it.
I just have one of many different jobs in microchip design. We all work closely together to deliver the components that go into your new phone, netbook, server, coffee maker, car, furnace, or pretty much anything else.
Dan - Diesel Engine Manufacturing - Illinois, USA
I work as a research and test engineer for a major engine manufacturer. Currently, my project entails a lot of engine testing, so I am mostly doing field work in the engine labs.
When the data collection is finished, I am the one who analyzes the results and puts them in a nice form using programs like Excel and MATLAB. Occasionally, we have a failure on the engine, and it’s my job to determine both why the part failed and what we have to do to ensure it won't fail again. If it happens, it quickly becomes the highest priority and ends up taking up all of my time.
A good portion of my day away from the test engine is spent sorting through the engine data for a variety of reasons. If I’m not staring at the data, I am discussing with my boss and overall group the data and how the testing is going. Fortunately for me, this usually isn't a lot of formal meetings, since we are a small group. As the project progresses, I also write the status reports on the engine and testing. I find that although this part of my day isn't the largest (in time), it definitely ends up being the most important.
Justin - General Contracting/Construction Management - International
My formal title is Project Engineer. In the broadest sense, I bring the knowledge and problem solving ability of an engineer into the field office at whatever jobsite I happen to be working on. I don't really do a lot of calculations or design; rather, I take the information I get from the superintendent or the subcontractor and relay it to the designers that did that work before the project began.
Day to day, an engineer in my position spends the vast majority of his time communicating. This can be as simple as a conversation with the field personnel talking through possible ways to perform the task to something as complicated as a formal meeting with minutes and presentations and the like. If there is an issue, the project engineer is the primary conduit through which it gets communicated to the designer and how the solution gets back to the guys performing the work. The engineer needs to have a solid grasp of the problem to properly communicate it up the chain and an understanding of the solution provided, both to determine if it solves the problem and to communicate it to the people doing the work.
One final thought to leave you with; the days of the solitary engineer working through a project or problem alone are gone. Today, 99% of all engineers work as a member of a team, whether made up of only engineers or a cross-disciplinary team of engineers, specialists and business people. Hone your skills at writing and get better at public speaking. These are skills you will need if you plan on moving forward in this industry.
Thomas - Software Consulting – Taiwan
My daily life depends on where my team is in the development cycle.
I. Initial Request- Here we are working with multiple external teams to hammer down requirements and discussing high level design with architects. We then draft technical documents explaining what our piece will do, what technologies will be required, and give a rough estimate of cost in developer hours..
II. Feature Implementation / Revision - This phase is where the bulk of my time is spent. We work from highest priority to lowest priority to ensure that in the worst case all essential modules are created. We are expected to finish cases in around 1 or 2 calendar days and have a desired quota of 4-5 cases per week. In Taiwan it is not uncommon to see workers voluntarily put in 14h days just to get ahead.
III. QA /Bug Hunting - In my company, every team of R&D engineers has a 1:1 mapping to a team of Quality Engineers. We churn out the product, they rigorously test it and find the bugs for us to fix. While I do hate the demanding hours of this phase, it is one of the few times I can get an actual "rush" from a desk job. The feeling of using all your combined training to solve the final issues with minutes left before a build must be submitted is addicting.
IV. Golden Master(GM)/Release - Since I am the only Native English speaker on my team I usually get the cushy job of proofreading documents and double checking UI spellings. Sadly, as with all good things, this phase ends fairly quickly and soon we are thrown back into a new project to repeat the cycle again.
Dyson - Mechanical Technologist - Yukon Territories
On any given day or week, I work in a supporting role. Large projects don't complete themselves and it takes someone to do the "heavy lifting."
Much of the time, the Engineer does the analysis, fundamental design, and working with the other consultants. At that point, I step in and really flesh out how we're going to put it all together. I do this by drawing the system components to scale and then fitting them together much like a jigsaw puzzle. Once that's done, I produce the drawings that will be used to put the mechanical systems together.
However, due to the small size of our enterprise, my responsibilities extend far beyond that. I also act as the construction engineer while the building is being built, witnessing (and designing) tests, inspecting the installations, keeping the contractors honest, and even altering the design mid-job due to unforeseen issues. All of this is done either with or without the engineer's involvement.
So, on any given day I can wear multiple hats: Analyst, Designer, Draftsman, Contractor, Diplomat, Inventor, Technician...etc. Some of these at the same time!
The moral (yes, there is a moral) of this was told to me by my boss, who said: "This business is what you make of it, you can do as much or as little as you want. You can even decide what you want to do, the possibilities are endless."
Johan: Software, Domotics Industry, Netherlands
My main responsibilities consist of designing and writing/implementing new functionality as the business or the customers require. This can include database design, process design or sometimes, no design at all.
When software is developed, contrary to what I know of Mechanical Engineering, the plans don't need to be fully done before the building process can start. This makes the software development process rather versatile and available on short notice.
The flip side of this fact is that software tends to grow almost organically. Oftentimes this growth is so fast that it's hard to keep the documentation up to speed with the actual development, so it takes a long time for a new hire to get familiar enough with an existing system to develop new parts of it without a good amount of time dedicated to figuring out how it works.
I expect that as I get assignments that require closer integration with customers' systems that I'll be doing quite a bit more communication than I'm doing now. I'm seeing things go that way already.
Bruno - Polytechnique - Junior Software Engineer - Quebec (OIQ)
My role in the business I work for is being a programmer-analyst. In the first few months of my career, I've been assigned simple programming tasks like changing a description in a file or correct very simple or even pre-analyzed bugs. These simple tasks were aimed at making me learn how the very complex software I program worked.
Quickly, the complexity of the tasks increased, and the indications were less detailed: I had to analyze the problems myself. By problems, I mean either bugs (I still correct a lot of bugs, but they are just more complex and especially not pre-analyzed by someone else) or whole new features we want to add to the software.
Of course, I have meetings with my group, sometimes presentations, sometimes discussions, over what we want the product to become over time. I also receive, like Jam said, a lot of e-mails.
Slowly, my job might evolve into a more client-oriented job (analysis with the clients, writing specification documents) or an even more technical job (larger and more important features, more analysis from my part, including analysis for others). I might even get a technical job in marketing (engineers have a lot of opportunities!). I haven't decided in what branch I want to work. At least, not yet ;)
Robert - Oil and Gas Industry - Texas, USA
I work for a well services company, specifically for the fracturing and stimulation portion of the company. After a well is drilled it doesn't automatically produce at the rate that the oil companies want. We increase the production rate of the well by opening cracks (or fractures) in the well, or by cleaning the well, depending on the situation. This requires the pumping of various fluids downhole, as well as sometimes pumping proppant to keep the fractures from closing due to the stresses exerted on it from the surrounding rock.
Right now I'm a field engineer trainee, so what I do is different from what the full fledged field engineers do. The field engineers need to be able to run and design the jobs: for that they monitor pressures, pump rates and they need to be able to read the lab reports.
In my company trainees learn by doing. So I help to rig up and rig down, do the jobs that the operators do, spend time in the labs, spend time in maintenance and basically learn by example: watching, listening and doing. I'm not expected to become an expert in any of the areas, however I will need to know what is going on so that I can confirm that everything is running smoothly, or troubleshoot a problem if there is one.
Kimberly - Computer Science Undergraduate - United States
My role as a Computer Science undergraduate is quite simple on the exterior: I'm a student! This means that on a daily basis I attend classes and do work. We often find ourselves in the Computer Science labs until midnight or later or working for 12 hours straight.
However, I think the reason why my peers and I work so hard is for the final rush of relief when it finally DOES work. The hoots, hollers, and dances of victory when your code compiled and ran successfully is really quite incomparable.
As an undergraduate, I receive homework assignments which often closely resemble "specs" or "specifications" found in the professional world. This means that a lot of the planning is already done for me - I just have to implement. In the professional world - depending on where you work - you may find that there isn't a specification, or that you're the one in charge of writing it.