ASK AN ENGINEER! – What do Engineers Do Day-to-Day?

Jam's picture

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
less money.

• 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.

Comments

Android24's picture
Android24
0

Oh, this is really interesting! I'm a freshman engineering student down here in the States (I'll be entering into the Computer Engineering program this fall, maybe then I can help out with this Q&A!), and it's cool to see how Comp Sci works in not only the work place, but right here in the University, too.

Also, from the few Comp Sci classes I've had, Kimberly is definitely right about the rush of relief after getting a program to work.

Xelmon's picture
Xelmon
0

Great write up guys, much appreciated to see what goes into engineering!

Redherring's picture
Redherring
0

Wow! This is amazing, thanks guys! Its always good to know that there are professionals out there doing a good job.

Bea's picture
Bea
0

Even for an engineer, it is so nice to see all sort of things we can do !  I work with research in Refrigeration, and it's sooooo different from everyone above ;D

The Ask an Engineer panel is a wonderful idea ! Keep'em coming !

wasc14's picture
wasc14
0

This panel was really good. It reminded me again why i decided to go into an engineering field and made me think of what about engineering made me squeal with excitement both a as a child and even now as a recent high school grad. I love the thrill of digging into a hard problem and finding more and more levels of complexity to it until finally i understand it and solve it. Thanks for this as it has provided a form of encouragement to me in my journey for an engineering degree!

Embry-Riddle, Daytona Beach campus, Aerospace Engineering '14!

morpheus's picture
morpheus
0

Nice to see they are not the "idea-amateurs", like some "fruits" from essay written company. 

luckymax5000's picture
luckymax5000
0

Nice post, thanks.

купить iphone

 

wiliiammi's picture
wiliiammi
0

Our commitment is to provide our customers the best shopping experience possible with our personalized customer service at a safe and secure environment. We proudly stand behind the quality of products that we sell because we believe in providing our customers the best quality and affordable fine watches together with excellent customer service
Watches for men
Watches for women
Watches brands in Pakistan

fyook's picture
fyook
0

A Diesel Watch might be the classic, staple accessories for a man’s wardrobe, but it is anything but typical. From the retro stylings of the ‘70s & ‘80s-inspired digital watches to the artistically futuristic look of the LED display face, they are diesel watches taking watch-wearing to a whole new fashion level.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.