School vs. Work (by Carmen Parisi)

This is a guest post from Carmen Parisi of Fake EE Quips. He’s the first of many guest bloggers who will be popping in to Engineer Blogs on a regular basis to add their opinions and insight into the field of engineering.  

Though I’ve only just recently joined the workforce and am still a pretty green engineer, I’ve noticed some differences between school and work. The differences between the two aren’t necessarily good or bad; they just take some getting used to. From the outset, I can name my favorite aspect: being able to leave work (both mentally and physically) around 5PM. Knowing I do not have to slog through hours of homework once I get back to my apartment is a fantastic feeling. I’d almost forgotten what hobbies were!

The rest of the things I’ve noticed so far aren’t nearly as polarizing but still worth noting. Let’s have a look.

  • Pacing — School, at least in my experience, operated at breakneck speed all the time. Work hasn’t been nearly as fast paced. Don’t get me wrong, I’m still working hard at the office; but it isn’t nearly the same kind of work as school. Between homework, research for my thesis, projects, labs, and job hunting, my last year of school was a blur. Finding time to breathe–let alone actually relax–was a delicate juggling act. At work though, even if a project is high priority, the pacing is still seems much slower. There’s always time to go back and double check measurements to make sure you’re producing significant results and doing quality work. Hopefully it can stay that way for the foreseeable future. 
  • Documentation — Unlike the lab reports required during school, the documents I write at work will actually be read by more than one or two other people; at least I hope so! It’s not just the datasheets and app notes I’m responsible for (I’m sure those will touch millions, at least!). It’s also the standard engineering paperwork. Whether I’m designing a one-off board for a proof of concept or reporting measurement results in a meeting, decisions are based on the work that I’ve done. That kind of responsibility is a little scary at first, but it encourages me to continually pour over my work making sure I haven’t screwed up. Having good documentation to back up the work I’ve done is crucial. My lab reports at school may have helped contribute to my grade and taught me some concepts. However, I wonder how much more effort I would have put into them had I known what I was writing would influence decisions of my superiors.
  • Criticism — Not long after I started work, I completed my first schematic for an eval board. I remember thinking it would be ready for layout relatively quick as I sent it off to other members of my team for review. It was another week before I even began placing components on the PCB because the schematic had to go through several more revisions. My team members picked it apart! The were adding a feature here, changing a component value there and questioning many of the decisions I had made. Was it uncomfortable? You bet it was. It wasn’t easy seeing my design held to such scrutiny; but I quickly learned to handle their comments and listen to what my coworkers were telling me. In the end, I ended up learning a thing or two. By the time my next schematic was up for review there weren’t nearly as many changes. Back at classes at school, I received minimal feedback in similar situations. The usual sequence was: submit an assignment, wait for grading, receive the grade and then quickly move on to the next task. It was nowhere near as stressful as a full on design review with instant feedback.
  • Experience — The importance of experience has been talked about numerous times on this site be it through co-ops, internships, or a place to tinker. I was fortunate enough to complete several co-ops during my time at school and I came away with a lot of good experiences that made me a better engineer. Most of what I picked up was little nuances of the trade. Things like small techniques for taking a measurement; or ways I could make documentation more readable. These are things I would not have easily picked up in the classroom. Being at work has already taught me a great deal more practical experience. For example, where you aware that an IC smells different from an electrolytic capacitor when blown up? To be fair, none of these experiences taught me basic theory like nodal analysis or how to read a Bode plot, as I learned in the classroom. I was expected to know those skills on my first day of work and am grateful I learned them at school. Without them I would be spending my time in the real world floundering around and not truly grasping the meaning behind my new practical experiences.

With the exception of “no homework”, I can’t definitively say work is better than school or vice versa. I’m not exactly sure I want to make that distinction either; there are pros and cons to both in my mind and I’m thankful for the experiences each has offered me.

Though you might have just graduated or you might have graduated 30 years ago, what differences did you notice when you left school to begin working? Let us know in the comments!

Thanks to Yung GrassHopper for the apropos photo!

4 responses to “School vs. Work (by Carmen Parisi)”

  1. billswift

    >It was nowhere near as stressful as a full on design review with instant feedback.

    I found it the opposite. Quicker and fuller feedback is great. It allows/helps/forces you to improve better. And you don’t have this constant gnawing anxiety about what you might have goofed up on this time (it doesn’t make any difference how little I screw up, the fear is still there).

  2. Yous

    I’ve learned more in a week at job than in a year at school actually…

  3. State of the Fake EE Union « Fake EE Quips

    […] Back on December, 20 I had an article published over on Engineer Blogs about the differences between school and work. Chris and the other EB […]

  4. ferd

    “no homework”
    It is okay to take a breather, and get accustomed to your job, but DON’T assume “no homework”. To keep up with fast-changing technology you’ll have to do a lot of homework: finding new products and ways of designing things, keeping up with standards, learning new tools (test equipment and software), and recognizing trends. If you’re lucky your work environment will help, but it is too easy to borrow your head into a certain technology or project and wake up one day to find you’ve been left behind.

    Other things they don’t teach you in school:
    a) Merely doing your assignments, even if you do them very well, is not good enough to sustain a career. You have to seek out more responsibility and broader exposure. Otherwise you risk being categorized as “only” able to do specific tasks, and if the company decides to go in other directions you could be considered surplus.
    b) You must stay cognizant of industry trends and how your projects fit. You don’t have to jump onto every bandwagon, but you need to recognize if your assignments commit you to stale technology. Try to get assigned to projects that are cutting edge. Avoid getting assigned to maintain existing products, even if they generate good revenue. It is too easy to get labeled as “old school” and expendable when the company phases them out.
    c) Build a network of coworkers and associates (even competitors) in your field. They will be invaluable in keeping you up-to-date and helping obtain gainful employment in the future. Join social but work-related groups outside of the office.
    d) Expect non-technical managers and coworkers to dismiss your expertise. Also expect people to lure you into office politics. These are traps – let the quality of your work speak for you. Don’t be shy to claim credit for your triumphs, and to humbly admit and recover from your mistakes.
    e) Pay attention to the financial health of the company. Learn enough about business practices that you can talk to executives, accountants and project managers in their own language. It makes you appear to be engaged in the business and it can provide early warning of potential problems. If the dominant management considers engineering to be a cost center rather than revenue generator it’s time to reverse that perception or move on.
    f) Carefully read your non-disclosure, intellectual property, and non-compete clauses (if you signed any). Follow them to the letter, but expect everybody else to too. Do not discuss your personal projects at work, and if you discuss them with coworkers ask for secrecy. Do not use company resources for your own projects – even researching things on the Internet via your company PC during lunch. You want to avoid legal hassles with the company over things that you develop on your own.