Programming Yourself in an Engineering Career

Below are a few topics I feel needs addressed, some areas where you can go wrong very easily in the engineering workplace. Unfortunately for me, it has come from some of my worst observations working at different companies. Fortunately for you, you can take home some lessons or get you at-least thinking about issues discussed below.

1. Female engineers : Unfortunately the engineering world is male dominated, and in 9 out of 10 cases, the engineering offices you're dwelling in has one female , and she happens to be the receptionist! In 1 out of 10 cases, you might land in an exceptional company with a diverse workforce where a pool of bright women are leading project meetings or pioneering Six Sigma projects. And then you wonder what is wrong with the other 9 companies where approximately one half of our other population is missing in action? This is an extremely important HR issue that companies have to address not later, but NOW.

For those companies that do have a few females in the junior ranks, you'd be plenty surprised by the questions they ask, the speed with which they execute and how quickly they learn. In my experience, they have an equal penchant for technical matters and getting hands dirty. Therefore, as a male engineer, there really should be no place for sexist attitudes and indifferences towards women. 

As an engineering manager, or as a senior engineering colleague, you must take some time off on a weekly basis to sit with a female and encourage them to explore the different areas of interest within the company. Answer their persistent questions. If they are ambitious, show them where they could go forward in their careers in a few year's time. With time, start empowering them with tasks where they take the lead in chasing down engineering issues and closing out action items. 

Chances are, this female engineer is going to like working there and will most likely be successful at some point after learning the ropes. The is a potential that some of her juniors in college or just friends or cousins are going to see her enjoy this career choice and follow suit. This could bring in more women into the field and turn around the void in gender diversity that engineering is sadly notorious for.

2. Engineering Documentation, Reporting and Recommending Actions : Smaller companies, where you maybe working, perhaps don't have a culture of documenting work and storing it in a safe repository. Bigger companies tend to have excellent systems in this respect, where they believe that accurately capturing the "what was done" becomes not only a learning tool for those wishing to replicate the same successes in future, but also a tool to use in times when crap hits the ceiling. When hundreds of events happen every week, memory is a previous resource. People tend to quickly forget what they had done, what they stated, whom they talked to. Some will also tend to show selective amnesia. Therefore, my advice is to maintain a personal work diary at the minimum where work progress is documented by date and key findings are underlined. It comes to aid when you least expect it!

Something also has to be said about reading reports, especially test reports, which conveniently skip giving conclusions or recommendations based on the analyses. It often feel like the writer has led you down a road giving horror stories along the way and then traps you at a dead end. The difference between a good analyst and a mediocre one is made here, where the good analyst can use experience and expertise to provide a reader with strategies to minimize risks. A mediocre analyst knows how to use a software. And that's it.

3. Design Reviewing : One of the really cool things about engineering is this existential element of designing a variety of things while spending loads and loads of someone else's money. But no one said you should run away with that idea.

If you have ever heard history repeats itself, it couldn't ring more true in the engineering office where over and over again, the same mistakes get repeated and exorbitant amounts of money are spent correcting these issues. And then comes in the meetings, where they discuss the need for more checklists, more design reviews, more standards. Unfortunately, it's all talk and months later, there is still none of these in place.

When projects are in a financial or scheduling mess, the engineering office becomes an easy target for others to hurl blame at. As an engineer, you could be between a rock and a hard place if your name was on a drawing that you said you had checked before it got fabricated but the drawing was later found to contain multiple errors. 

What I would like to highlight is the fact that as an inhabitant of the engineering office, it is your duty to respect your company's finances. At the same time, proudly uphold the values of your profession and let no one else talk dirty about it. 

One way to ensure this happens is total quality control. Before something leaves your desk, you need to check it. How are you going to check it? Either you have a list of things to tick off against or you have a standard to compare a drawing or datasheet against. Don't hesitate to call a few experienced engineers in the room into a meeting and show "the plan" before you make the plan. Take some time off to do this immediately in some of the most common tasks and you'll thank yourself for the extra effort, especially when you see you've been personally responsible for saving lots of company money.

However, a more robust engineering situation is created when the design review gate is directly implemented into the department's engineering plan. This is a philosophy of Systems Engineering. Why engineering managers hold onto the old and tired ways, while failing to introduce this very simple step into departmental procedures, something that can have both time and cost benefits, is beyond me. If someone else likes to answer, please do.

4. In-house softwares : We all have, at some point, created some spreadsheet for personal calculations. Sometimes, we create them for someone else to use it. Years later, when you're long dead, some junior engineer will continue using this spreadsheet that sits loosely in a disorganized folder on the company's network drive.

There's a hornest's nest waiting to be stirred here. You can be extremely pleased with the results of your software without hardly taking the time to validate it. How can you ever be certain your program runs on a stream of inputs correctly at all times? The problem starts with this attitude of "machine complacency", that the computer is smart and knows what its doing, therefore it must be right.

Machine complacency pays negative results when the ISO auditor visits the office and asks the engineering manager to prove that these in house softwares are validated. If there's little in terms of an answer, the auditor smirks and marks you a point of "non compliance".

The point of this story is not to highlight the importance of scoring on audits. It is to highlight a very basic fact that engineers continue to neglect wherever I go. If its a spreadsheet you're developing, take the time to title the sheet and atleast provide the name and email of the author. Check to make sure cells are referenced correctly. Look out for division by zero possibilities. Run a range of values and see if the results you get agree with either theory or simple intuition. If it's a software that you're developing for others, ask those others if it's okay to try your program on their laptops in a meeting room. Observe them using it for sometime. You'd be surprised in getting back some of the areas you'd missed when developing the software. At the very least, you can learn something about what a proper user interface is!

5. Relationship with suppliers : If you've ever worked for a large OEM like I have, chances are that on more than a few occasions a month, a supplier wants to lunch with you while talking about their products and about your business.  

As a rule I like to follow, do not ever agree to consume alcohol during this lunch meeting, for which the worst consequence could be you running your mouth loose and letting out some facts about the company your supplier shouldn't really be knowing about.  On the same token, do not ever agree to accept cash gifts of any kind as an invitation to do more business. In the U.S, if you're caught doing something like this, you're committing an FCPA violation and you risk losing your job. If you don't know what FCPA is, do yourself a favor and look it up. 

In smaller companies where rules of supplier interaction maybe a little more loose, always keep in mind that it is no business of yours as an engineer to be initiating commercial discussions with any supplier. More often than not, this will tend to land you in unintended trouble. Talk strictly technical issues, those of specifications or drawings or how to solve a particular issue. Please leave commercial topics to the proper departments in your company. 

On the same note, whether you're at an expo meetup or in the meeting room of another company, you're first and foremost a representative of your employer. Second, you are part of the wider engineering body that has clear codes of professionalism. Therefore, always be ethical and sound in judgment and action towards your suppliers. This really means avoid the gamut of actions from kissing to threatening someone else's life!

6. English, Please! : I end with this serious note : The engineering office is not a place where you should feel free to exercise knowledge of different languages. Stick to English, please! The old and established senior engineer who refuses to address your concerns in English should basically be made to take a trip to the HR department and sort out his linguistic deficiencies. I have this funny feeling that it's only a matter of time before somewhere in the world, in an industrial plant, an HSE related concern is conveyed by one engineer to another another in a foreign language [insert favorite choice here] , but the intent wasn't captured, ending up in something critical not being done while something else was done instead and shortly thereafter ---> BOOM. 

There are lots of additional things I can add about programming yourself in an engineering career, but I will choose to devote another post to those. Thanks for reading!