Things They Don't Teach You In School
September 10, 2014
This is the transcript of a talk I gave at Howard Community College to Intro to Engineering students, September 2014
My name is Greg and I’m Vice President and Software Engineer at a small company. I went to University of Maryland with Mark [Edelen] and got my degree in Computer Engineering in 2002, so I’ve been out of school for about 12 years.
Instead of talking about any specific experiences in my engineering life, I wanted to talk instead about some of the things that I’ve found to be not just important after school, but surprisingly important. In other words, I want to talk about a few things that Engineering School doesn’t always teach you.
First things first, I don’t want to give the impression that I don’t think school is that important. It’s very important, especially in a discipline like engineering. The four years I spent at Maryland were inundated with new ideas, new math, new methods. School is just necessarily limited in focus. School takes a (theoretically) limited amount of time, with a goal to provide students both technical breadth and depth over a range of topics. And that’s a pretty tall order.
So I have four different subjects for you today that, in my experience, were undervalued in school but very important in the real world. I borrowed each of these four subjects from one of my personal heroes: Freeman Dyson.
Not too many people have heard of Freeman Dyson, but he’s a wonderfully free scientific thinker and he’s had quite an interesting life. Mostly, he’s known for coining the idea of a Dyson Sphere (which actually started as a joke but then became somewhat famous on Star Trek). He also did some amazing physics, working alongside Richard Feynman on quantum mechanics and QED. He’s written a lot about science, religion, biology, human rights and global warming.
So, here are my four underrated subjects for you.
First and foremost, you need to know the tools of your trade extremely well. School usually focuses on theory, and that makes sense because if you understand all the theoretical principles, it provides a foundation for any further work in the field. In the real world, when you are building things, your tools matter a lot.
Dyson talks about living through four scientific revolutions: nuclear energy, genetics, computers, and space science. Those four topics cover almost all of the progress of the 20th century. He points out that, after the initial theory and research that created these new ideas, the rest of the progress made over decades has all been because the tools have gotten better.
Computers and space science illustrate this best. The fundamental architecture of computer hardware and software has not changed since John von Neumann invented his version in the 40s. The only difference is that the tools we have are better, and so the machines we have are faster and more powerful.
Space science is pretty similar - we haven’t sent people any further than the moon for fifty years, but we’ve learned a lot about space - we’ve discovered hundreds of exoplanets, black holes, gamma rays, all sorts of things. None of this is new theory, we just have better tools so we can see and measure all of this cool stuff.
In my specific case, I’m a software engineer, so some more concrete examples might help..
In college I learned a ton about the fundamentals of software engineering like data structures, algorithms, computer architectures and operating systems. I learned the mathematical concepts around these things and I learned how to program them.
But I didn’t learn how to use a tool called version control at all. Version control, for those that don’t know, is a way to manage all of the changes that occur when you’re writing or modifying code.
When you’re writing a program by yourself, like you usually do in school, version control is nice to have but not vital. Anytime you have more than one person in a codebase, it becomes incredibly important to keep track of all the changes being made.
I also didn’t learn how to use an operating system well, or how to use a good text editor or IDE.
When I’m writing software, I do use some of the theory I learned in school, maybe a theoretical concept once or twice a month. I use version control, operating systems and editors every day, all day.
And just in case you’re interested in software right now, here’s some tools you should work to become a master in right now:
- Git for version control
- Linux as an operating system
- vim, emacs or sublime text for editors
- Ruby or Python for languages
For other engineering disciplines, I’d bet on Matlab as being an exceptional tool for A LOT of things.
For all of these tools, mastery takes years. There’s an article out there called ”Learn Emacs in Ten Years”. I’ve watched people edit text in ways that aren’t even possible in more normal tools so quickly and easily that I decided to switch my toolset on the spot. When you watch someone really good use these tools, after you pick your chin up off the floor, you realize it’s worth the time to learn them.
As a software engineer, I know 3 or 4 programming languages very well, and I could get by in maybe half a dozen others. That’s true for most software folks. So my next subject that you don’t always learn in school, but especially in engineering school, is English.
By far, the most important language I know as a software engineer is English. I think the most important skill of any engineer anywhere is the ability to communicate clearly. I specify English because it has evolved to become essentially a universal language across cultures.
Communication should generally be bi-directional, so there are two parts to why this is so important in engineering. The first is to be able to listen to your customers. This is a lot harder than it might sound, because your customers will very typically be wrong about what they want. That’s definitely different than school. I think if you tell you professor that their project definition is wrong.. you won’t get very far.
There’s an apocryphal Henry Ford quote about this you might have heard - he supposedly said “If I had asked people what they wanted, they would have said faster horses.”
The start of communicating well is being able to listen, to ask questions, and to extract what you hear so that you can build a useful and objective mental model of the problem.
The second part is being able to effectively declare and describe your ideas. Our job as engineers is to build things. All of the things we build have to start in our head, and then we translate them to the world, by equations, drawings, code, words, whatever.
And even the largest crystal palaces you build in your head are effectively worthless if you can’t share them with those around you. The best way to share them is by learning to speak and write effectively.
By speaking clearly, whether to a room of a thousand people or to your team of two people, you get to share your mental model, to test it against what others think, refine it, and uncover and fix gaps that might exist.
Learning to write is the last and most important piece. By learning to write well you can, as one of my favorite writers says, ”[not just] communicate ideas, but generate them also”. This is probably the biggest reason why learning English well is so important. Language is the medium by which we all express our ideas. That’s incredibly important, so I’ll say it again. Language is the medium by which we all express our ideas. If we can’t exercise mastery of the medium, we have no hope of fully expressing our ideas, no matter how wonderful they are sitting in our heads.
How to ask questions
For my third subject, I’ll move back to Freeman Dyson. For the 2nd topic, I had no real connection for Dyson to “English” except that he was born in Britain, and so of course he knows English extremely well.
Dyson loudly declares that he’s proud to be a “heretic”. What he really means by this is that he works hard to think differently. People can get awfully religious about subjects far beyond religion. Sometimes this can be called “Group-think” too.
How Dyson thinks shows in his work. He worked hard to convince the world of Nuclear Disarmament during the Cold War and he talks openly about science and religion in a way few scientists do. More recently, he’s been called “the climate skeptic with the highest IQ in the world”. By the way, he has some very insightful and well-researched things to say about the climate models used today. He’s not the classic idea we have of an ignorant global warming denier, he just asks some interesting questions that others haven’t asked.
Asking questions is an incredibly important and hard thing to do. First, you have to have the courage to stand up to the orthodox perspective, whether that orthodoxy represents your entire field or your 4-person team. Next, you have to have a sufficiently detailed mental model of the world to pivot around in your mind and pick at. Where are the problems? Why doesn’t it feel right? Finally, you have to be able to effectively communicate the inconsistencies in this model that you find.
School asks us questions quite a lot, and by coming up with the right answers we’re supposed to show what we’re learning. This works quite well to a point, but unfortunately, getting these answers is the easy part.
A good engineer can answer questions. A great engineer will ask new questions (and then, of course, help find the answers.) Don’t be afraid to challenge the prevailing lines of thought by asking questions. When you do, you’ll frequently stumble on new ways to see the answers.
Sidebar: For Dyson, he found that climate models did a great job at performing CFD calculations on the atmosphere and ocean, but did a poor job understanding the role the land plants and soil play in carbon exchange. This lead him to focus on traditional land management (forests, proper farming, etc.) as a viable solution to climate change. He also willingly asked the question, “is a warmer planet necessarily worse in the long term?”
How to be wrong
Which brings me to my final subject. I just said that school asks us a lot of questions. When we answer, they expect us to be correct. We’re graded on our “rightness” (correctness), and so we have it ingrained in our heads that our level of knowledge is directly correlated to how right we are.
In the real world, engineers are wrong ALL THE TIME.
Here’s two really good ways to be wrong.
- Leadership: Project or system leads are wrong all the time. When engineering projects reach a sufficient level of complexity, it’s impossible for anyone to know everything. A lead engineer usually has to have very broad knowledge to satisfy all their external interfaces (like customers), and so they have to sacrifice deep knowledge. The corollary is that they’ll frequently either be wrong or need to ask questions of someone with deeper knowledge of a specific topic. Leadership on engineering projects means learning how to do this effectively and modestly. In other words, it’s perfectly acceptable to not have all of the answers.
- Modeling: On very tightly constrained problems - like an easy math problem - it’s easy to focus on getting the right answer. But when you start asking new questions, you have to be wrong a lot before you start getting better answers. Iterating on ideas is your way of making better and better models of the problem you’re trying to solve. Think about the pedals and steering wheel in your car. We think of them as completely normal now - a big circle to steer, and then either two or three pedals: clutch, brake, gas. We’d think of anything else now as “wrong”. But in the early days of cars, there were all sorts of wild controls. It took a lot of iteration to get a consistent and general solution.
So don’t be afraid to be wrong.
Those are my four subjects. In having to write them down, it’s occurred to me that even though these aren’t always taught directly in school, there’s no reason any of you can’t start applying them right now. So here’s a couple of thoughts on how to do that.
First, figure out what the right tools are. Find the best people in your field and see what they’re using. Google is your friend - heck, Google is a tool in itself. Once you’ve found the right tools, start playing. I think that’s important, make sure you’re playing. If it feels like work, you won’t get very far.
The best tools are often hard to approach at first. I mentioned Git earlier. There are plenty of other version control tools - CVS, Subversion, Mercurial, Perforce. Right now, the whole software world is moving towards Git, and at first it is downright confusing compared to most of the other tools. Once you get over a couple hurdles, it really starts to shine.
I mentioned Matlab too. I know I’m biased - I’m a computer guy. I’d say that an engineer that is proficient at programming has a big advantage over one that doesn’t. I have a friend that’s a Supply Chain Manager at Under Armour that’s learning Python and getting his Master’s in Applied Math right now. He sees a big opportunity to use the tools of math and programming to advance his career and his company.
Matlab is where I’d start for any other engineering discipline. Do the fun stuff with it - make pretty pictures. Do loop-de-loops with some data. The fun stuff keeps you excited, and you’ll learn more about the tools that way.
Fun little projects are the best way to use new tools. A couple of years ago, I wanted to learn a couple new technologies, so I picked a project out. The Virginia earthquake had just happened, and it had taken a little while to find out all the stats about it, so I wrote a little Twitter app that tweeted out big earthquakes and locations. I called it OMGEarthquake. It was super simple, it just pulled all of the USGS earthquake data, formatted it, stored it and posted it to Twitter anytime there was a big one. A few hours of play, some cool new technologies, and I ended up with 500ish followers on Twitter. It was pretty fun to see it used, a few earthquakes hit in the Dominican Republic and I could see all the RTs and quotes from new people percolating the message from my little play project. OMGEarthquake is still there by the way, but USGS changed their data formats, and I haven’t had time to redo it, so it doesn’t update anymore.
The best way to practice communicating is by writing, which you can do right now. To some extent, it doesn’t matter what you write, just that you write, because practice works wonders.
The first few times will suck quite honestly, but practice will make you better, and you’ll start to feel a rhythm.
You should pick something fun and interesting to you. It doesn’t matter if it’s soccer, guitars or recipes. You should also let other people read it. Letting other people read it means that there’s some lower boundary for quality you’re holding yourself too.
If this sounds like a blog, that’s because it is. You should write a blog. Writing a blog is the best non-technical thing you can do for your career while in school.
Questions and Wrongness
In order to ask questions and be wrong, you have to be brave. Practice speaking up. Sometimes when people talk loudly and quickly, it’s because they’re hiding their ignorance. I can’t tell you the number of times someone has started with a simple, “I’m not sure about this part..” and it has unravelled an entire solution.
Just as important as bravery is identity. I said earlier that we have it ingrained that “our level of knowledge is directly correlated to how right we are.” It’s worse than that, because how correct we are or how much knowledge we have often gets wrapped up into our own identity. We identify with a solution or a piece of knowledge so strongly that it becomes a part of who we are. As you can imagine, it’s very hard to walk away “being wrong” in a case like that. I think this is why people so often cling to their opinions or ideas so long even after being disproved. So work hard at separating yourself from your ideas. Your idea can still be wrong while you can be on the right track.
I’ll leave you with one of my favorite Freeman Dyson quotes, one that I think encapsulates some of the things I’ve been trying to say.
You can’t possibly get a good technology going without an enormous number of failures. It’s a universal rule. If you look at bicycles, there were thousands of weird models built and tried before they found the one that really worked. You could never design a bicycle theoretically. Even now, after we’ve been building them for 100 years, it’s very difficult to understand just why a bicycle works – it’s even difficult to formulate it as a mathematical problem. But just by trial and error, we found out how to do it, and the error was essential.
- Freeman Dyson
Hi I'm Greg. Occasionally, I do things.