Engineers - What things do you in your day to day jobs?

Miscellaneous and Personal Stuff I Must Share
1

I know there are a lot of different types of engineers, but I am curious about what engineers actually do for a living.

Lets say a company like HP or IBM or DuPont or similar hires you. Being an engineer you’re presumed to be a fairly intelligent person. What things do they have you doing during the day?

Is there some brainy super-engineer and you are all his minions, checking on his or her ideas and proving them out. Are you creating things or just checking out other people’s stuff. Is it interesting or mundane? What exactly are you doing to earn your daily bread?

What happens to the engineers who aren’t super creative geniuses. Is there plenty of engineering monkey work for them to do or do they get fired?

2

The engineers are busy fixing the problems caused by the “engineers” because the real engineers were long ago “promoted” to program managers and no longer do any real engineering.

3

While the ansswers to the OP won’t be mundane, it’s not really a GQ. Moved to MPSIMS.

samclem, Moderator

4

I’m not an engineer, but there are many in my company. As they move up the corporate ladder they do less and less engineering and more and more managing. The one I work with the most is being driven slowly insane by neverending budget meetings. She still has engineering work to do, but can’t devote her full time to it.

5

There’s coming up with new stuff, making tests for other stuff, and fixing problems in old stuff. I find it involves a lot of looking at squiggly lines.

6

I’m an engineer but I have never done the kind of jobs people who are not engineers associate with engineers.

A few years back, I showed to my brother a help wanted ad asking for an “Organizational Engineer”, a degree which had just been approved by the Spanish Ministry of Education: the first degrees of that kind had not been printed yet. Bro’s reaction was “but what the heck kind of specialty is that? Organizing is what us engineers DO!”

Bro is a mechanical engineer. For many years he worked in a stone company. He’d go to a construction site, measure the places which needed stone laid on them, then draw plans for the stone layout, including the shape and size of the pieces; he supervised the people who laid out the stone and met with the construction firm to measure the finished work so they could bill for it. Nowadays he’s a construction site foreman: he coordinates the work of the different tradesfolk and meets with folk to verify their finished work so his employers can get billed.

I’m a chemical engineer. For the first few years of my career, I worked in research in the US: first in a university (well, I was aiming for a PhD in Chemistry - but left with an MSc), later in a pharmaceutical company. Then I came back to Spain; two years of temp jobs ranging from “assistant to the logistics manager” (contacting suppliers abroad for ETAs on shipments) to “lab tech”, eventually a job as “lab tech, weekend shift” from which I got promoted to what I do now: organizational consultant.

There’s this management philosphy called “ERP”, which basically amounts to “in order to plan your work properly, you need to take into account all the resources you use: materials, machinery, people, etc.” There’s these “ERP Databases”, used to store all the data needed to manage a company. There’s companies which want to use “an ERP (database)”, but installing one isn’t just a matter of downloading a program and clicking on “Install”; the program needs to be adapted to the needs of the company, people need to be trained… and that’s what I do.

It’s always as part of a team: we analyze our customer’s processes (which is very much an engineery thing), then look for the best way to reflect those processes in the database, at the same time working with the customer to improve the processes (again a very engineery thing). We prepare training materials and train people (or at least, train the trainers).

Example of an improvement: when my boss at the factory where I was a weekend lab tech called me to tell me we were going to be doing this, I asked “does this mean the warehouse manager will not be calling every 15 minutes asking ‘where is my fucking data?’ any more?” and she said “oh my… oh God, YES! This is going to be worth it if only for that!” That was a very simple improvement which stemmed from having a single management program rather than half a dozen of them, but it got the lab folk rid of their biggest irritation. Other times we’ve managed to go from a process involving five people in three different systems, to three people (from different departments) in the same system.

7

I’m a software engineer, so for a moment let’s just pretend that’s comparable to “real” engineering :slight_smile: and I’ll answer your question.

I write new code (the real stuff, and many tests),
go to meetings as little as humanly possible,
research solutions for new systems we want to build,
write design documents (and review and comment on others’),
debate possible solutions with coworkers,
retrofit existing code to deal with changes in other people’s code we depend on, or just for maintenance/improving less-high-quality code, or because there’s a problem with a production system (worst case),
argue with product managers about why their ideas are dumb :),
read about new technologies/best practices/systems,
that kind of thing.

I’m very fortunate that I really like my coworkers and we have a good working energy on my team. We eat lunch together, we ask each other for advice a lot, we play the occasional videogame on Friday afternoons, shoot nerf guns at each other, etc. We get a lot of work done but also have a lot of fun. Not all companies, not even all teams at my current employer, have been so harmonious.

8

My first engineering job was tooling and fixture design at a Navy aircraft overhaul depot. Many of the aircraft we worked on were quite old and developing problems that had not been anticipated. In order for our machinists to fix the parts, they sometimes needed specific tools or fixtures, and that’s what my branch designed.

After a major reorganization, I was moved to an aircraft structural group where I did design work on the aircraft itself. We mostly designed modification based on changing missions, plus we modified some aircraft for foreign military customers. Some stuff I did involved special storage areas, new lavatories, new galley spaces, special racks for electronics gear, and once I even had to fit a three-level bunk bed in a very cramped space.

Along with coming up with the ideas, we had to ensure everything was documented with accurate engineering drawings and other operator manuals as necessary. As our designs were being installed in the aircraft, we were often called to deal with issues that weren’t obvious during the design stage, or with mechanics who sometimes didn’t know the difference between a radius and a diameter. :rolleyes:

Our more senior engineers were made project leaders, and while they got to do some design work, they mostly had to go to way too many meetings - how sad. I was a sorta project lead once - I was spared most of the meetings, but I had to make sure all the other engineers on the project coordinated with each other as necessary and got their drawings and documentation done.

In my experience, the best design engineers made the worst managers, but the ones who understood the process but don’t like the detail work did the best job in the front office.

My husband has worked in industry as a mechanical engineer and a plant engineer. As such, he was not only responsible for designing systems and machines to do the job in the factory, he also had to manage a budget, work with vendors and outside contractors, deal with regulations, and ultimately help his company make money. As an engineering manager, he pretty much did the same thing, but he had minions to do the parts he didn’t like, and he cherry-picked the tasks he wanted to do. Plus at times, he actually put his hands on machinery and turned wrenches himself or donned a welding helmet and struck an arc. He was a welder and a machinist/tool maker before he became an engineer.

9

I’m an EE. I’m 44 years old. Been an engineer for 20 years.

When non-engineers ask what I do, I am at a lost on how to answer. Seriously. I usually say something along the lines of, “I solve problems,” but this answer leaves most people unsatisfied.

Being an EE, I suppose most people think I design circuits all day. I wish that were the case, as design is my favorite thing to do. In reality it only consumes about 2% of my time. Most of my time is spent doing a myriad of other stuff, like:

electrical testing
environmental testing
analyzing & crunching data
writing code / designing spreadsheets
setting up tests
writing procedures
participating in meetings & telecons
reading technical documentation (TO’s)
offering technical advice
writing test & analysis reports
helping & supervising technicians
troubleshooting
reviewing specifications
writing specifications
traveling
hiring people
educating myself on a new subject
reviewing cost & expenditure data
writing & giving presentations
coordinating activities (logistics)
communicating with management & customers
ordering components & supplies
fluffing up the egos of engineers who don’t know what the hell they’re doing

These activities occur in a somewhat asynchronous/random/as-needed/chaotic fashion.

10

I used to be a Project Engineer with a civil design firm.

I did a lot of reading of regulations (State and Federal) and quite a bit of meetings and correspondence. All of that took up maybe 60% of my time.

Actual design work (crunching numbers, coming up with ideas to meet a situation, doing field work (site walk, soil tests, field measures after the survey), and any CAD work) took up the remaining time.

There really is a lot more management activity to engineering than actual “engineering” (number crunching/design).

11

There are different kinds of engineers:

  1. The geeky engineer. He or she genuinely loves the technical aspects of engineering. They may not dress well, and their writing skills may leave something to be desired, but these folks are the ones who do the ***real ***work. They are to be coveted, as they cannot be easily replaced. These are the engineers I respect the most.

  2. The blowhard, overly-ambitious, “I’m in charge” engineer. Hates engineering, and only went to engineering school to land a good-paying job. He or she always becomes a manager, is generally miserable, and feels insecure due to their lack of technical knowledge & skills.

  3. The affirmative action engineer. Has no idea what he or she is doing, is never challenged or criticized, and is kept on staff for legal and political reasons. This is an insult to the engineer (who would be better off doing something else) and a drag on the company, but their presence is unfortunately necessary in today’s PC climate.

  4. The lazy and/or incompetent engineer. He or she got pushed into engineering school against their will by their overly-eager parents. Is unhappy and has no real interest in engineering. Is assigned to do simple, boring, and non-challenging tasks. Quits after a few years.

  5. The academic engineer. Similar to the geeky engineer, but still thinks they’re in school. They love to go off on tangents and solve technical problems that have nothing to do with the project or the customer’s needs. They have no concept of costs, schedules, and deadlines. These people need to quit, go back to school, get a PhD, and teach.

12

Crafter_Man: you’re spot on! :slight_smile:

13

Drive the train.
What?

14

I’m an electrical engineer turned software engineer, and my specialty is troubleshooting. I figure out why things don’t work, and either fix them, or tell others how to fix them. I also write new code, but most of that code is actually test software, which is used to find problems in the actual product. I do my own share of the testing, and support several teams of other testers–when they can’t figure out why something doesn’t work, either in the product or their test code, they call me. When the engineers who write the actual product code can’t figure out why it doesn’t work…well, sometimes they also call me.

That’s not all I do, of course, though I’d probably like my job better if it were. I also create configuration files for our software that hold the “business rules” to make it do the things the customer wants. The configuration is complex enough that it borders on a programming language unto itself.

Then I do the really boring stuff, like writing documents and dealing with corporate bureaucracy.

Meet the Engineer