I started reading David Goldberg and Mark Somerville’s book, A Whole New Engineer last weekend, and it gave me chills. It’s a quick read (under 250 pages, with graphics, lists, and call-outs aplenty) and a riveting one. The authors have a simple message, and a call to action: Olin is implementing a better approach to teaching engineers, and there are easy-to-imitate steps that any faculty can and should follow.

The book starts off filled with familiar faces and ideologies. We follow Rick, Charlie Nolan and the rest of the first group of Olin employees, Mark Somerville, the founding faculty, the partners, and all of the rest of the highly intelligent and highly motivated people who poured their hearts and souls into founding Olin. I laughed out loud at some of the episodes from Olin’s early days. For example: After the faculty spent most of Partner Year struggling with the answer to the nebulous question “what should an engineer know,” producing scads of sticky notes, but little consensus, then-Provost David Kerns finally organized a several day long retreat in MIT’s Endicott house for five faculty and one partner. His instructions to them were “not to come out without a curriculum.” And it worked! Then there are other stories – the bouncy castle apology incident; the Rube Goldberg machine, the first design challenge (all key elements of Olin lore that I remember learning about in my first or second year here).

An interlude at the University of Illinois demonstrates a powerful illustration of the book’s premise: Educators who felt that change was necessary and that existing change mechanisms were insufficient were able to replicate the Olin effect in their institution. This really hammered home, for me, the worth of Olin’s partnerships with other universities like UTEP and INSPER, and the many visits organized by the Collaboratory. The iFoundry story of how they created a space for themselves inside a much larger and very rigid space was inspirational. It was the story of how educators outside of Olin learn about our methods, then find ways to bring our recommendations to life in their own programs.

The authors then explain the history of how universities were once aligned with businesses, but then failed to adjust to market pressures (brought on by entrepreneurialism, the pursuit of quality -leading to specialization- and, most significantly, the vast accessibility of information due to the internet explosion). This sets the stage for the book’s call to action for students, parents, educators, practitioners, and policy makers: change the way engineering is taught now. It may seem unnecessary, but the evolving economic climate is actually crying out for change – the right time was decades ago. It may appear like an unsolvable problem, but the results are as clear as they are commendable. And it may feel overwhelming, but Olin and the iFoundry have distilled down their years of expertise into actionable steps that any institution can take.

The rest of the book explains the process in more detail. I was amused by the extreme frequency of lists that dotted the text. I suppose it is the most effective way of structuring an argument, as well as being the way academics distil their ideas for quotation. Still, I noted them each down as I encountered them – inline, numbered, bulleted… and the lists go on! I counted 53, including Olin’s foundational ‘Bold Goals’, the original charges given to iTeam members at the iFoundry, the six minds of the Whole New Engineer, the pillars of educational transformation, and the three things that Oliners may pick two of, according to an early t-shirt.

The purpose of the book is to give insight on how to bring about change successfully, and explain and justify the necessary changes. These are captured in the five pillars of education transformation: ‘joy,’ ‘trust,’ ‘courage,’ ‘openness,’ and ‘connectedness, collaboration, and community.’ The authors propose that letting these pillars guide our instruction, we will produce the kinds of constructive education experiences that are necessary for tomorrow’s engineer. This should not be surprising to Oliners, because we live and breathe these pillars in all aspects of our lives. However, most engineering students are not so lucky. The authors detail simple and straightforward ways for teachers to alter their classroom behavior to demonstrate that they value these ideals. The changes are obvious and easy to implement, but they are extremely powerful.

All in all, it’s a great read, and I would suggest that any Oliner checks it out now, rather than in 8 months when it inevitably shows up in the shortlist for the summer book program. You’ll gain an appreciation for our college, for our methods, and for our mission. As an admissions officer, I’ve observed that the applicant world is split into two groups – those who have never heard of our mission, and those who are transfixed by it. The world is large, and Olin is small. We need to continue to spread our lessons. The college may be built, but the opportunities to build colleges are far from gone. Now more than ever, we need to tackle the nebulous questions: “What should an engineer know?” and “What can we do now to change the way engineering is taught?”

Olin’s curricular triangle is separated into Engineering, Entrepreneurship, and Arts/Humanities/Social Science. However, distinguishing between Anthropology, Entrepreneurship Capstone, and Dynamics from the class codes AHSE1199, AHSE4590, and ENGR2340 is difficult. By lumping entrepreneurship, arts, humanities, and social science into the ‘other’ category, we are simply left with engineering.

Instead of consolidating these other disciplines, we should strive to incorporate them into our engineering classes.

Though Olin is a school with no departments, there is stratification between many of the subject areas. The very idea of an AHS Capstone discourages integrated classes and urges us to stick to a single path within a narrowly defined subject matter. During out entrepreneurship foundation class, we struggle to come up with an idea in two weeks, when we could instead be doing this in parallel with UOCD’s market research. Rather than dismissively combining classes, we have an opportunity to meaningfully integrate them.

By simply asking for a change in the way that class codes are written, we can open up the discussion of potential changes to the curriculum as a whole. Olin is advertised for our innovative educational approach, and limiting the curriculum to a single field does not represent what we want to accomplish.

To everyone who has ever touched code at Olin – and that includes MatLab – I am here to tell you that we do not learn how to code at Olin.
This statement is slightly shocking. I imagine that many of you, at this point, are violently disagreeing with me. Hear me out.
There are two main criticisms I have of people who code at Olin. One, we don’t test our code. Two, we don’t design and refactor our code so that it is ‘clean.’ I didn’t realize how important testing, refactoring, and design were until I interned at software companies. I believe that Oliners should make an effort to incorporate these practices into our work.

Unit testing is ensuring that units of source code (often a function/class) work as intended when isolated from the rest of the system. For example, if you define a function that is supposed to calculate the distance between two points in the Cartesian plane, one unit test would make sure that the function returned five when given the points (0, 0) and (3, 4).

You may laugh at this example and wonder why you need to write code to test it. Isn’t it insanely obvious? Everyone knows the distance formula!
Here’s the thing, though – you are going to test this code anyway. How many times have you printed out the result of a function call in order to make sure it’s returning the right thing? How many times have you copied and pasted function calls with different inputs? How many times have you graphed the output of ode45 to make sure that your derivative is calculating the right thing?

Why not take your manual, laborious tests and save them all in a file so that you can run them on a whim?

The benefits of tests are numerous. You document your code with examples of how functions and classes are supposed to work. You become more confident knowing that each piece of your code functions as intended in isolation. Because your tests can be run at will, you save time whenever you change your code (renaming a function, say) and want to make sure that nothing has broken. Employers love prospective employees who understand testing.
Most Oliners never learn that unit testing exists. Did you know that MatLab has a testing framework? (How much could well-written tests help on Mech:E problem sets? Or in ModSim?)

However, even when we do discover testing, we usually don’t spend the time or effort to learn how to do it. The norm should be tests for every line of code we write. But it isn’t.

Why haven’t I learned this at Olin? Well, I did. Kind of. Allen Downey taught a class called Software Engineering my sophomore year, and I was the perfect example of an unwilling student. Allen told everyone taking the class that testing was important, and I believed him. He even went so far as to write tests for us on some assignments. However, it was too late for a professor to change my coding habits. I learned how to code at Olin, had settled on my own personal set of coding practices, and was stuck in my ways. Testing was done manually. I didn’t write tests for my final project. I suspect that a lot of my classmates’ experiences are similar.

Improving coding practices at Olin is not going to be driven by professors. We, the students, have to collectively decide that we care about testing our code. Without widespread adoption and enforcement by the community, Oliners will continue to treat testing as an optional activity.
Clean code is a much more nebulous concept. The most important thing to note about clean code is that it is a process. Rarely will anybody sit down to work on a coding problem and write exactly what they need on the first try. Refactoring should happen every time a new bit of functionality is implemented.

Writing clean code requires deliberation. The goal is to make code easy to read and understand, easy to maintain, and easy to modify/extend. This touches on a wide range of issues; everything from how long each line of code is allowed to be (79 characters is a good number) to making each function/class do only one thing (the single-responsibility principle) to the use of design patterns (common architectures that are reused in many contexts). I am not an authority on this subject, but I would like to learn more about the area with my peers.

Unfortunately, in my experience, conversations about designing code rarely happen on a level deeper than, “We have to do x and y to produce output z. Let’s start implementing x.” Ideally, everyone working on a coding problem would challenge each other with well thought-out arguments about the best way to do things in any given situation. Not only will everyone learn a lot about code design, but the quality of code will be higher. I know professors appreciate code that is easy to understand. You will appreciate your own code if it’s easy to understand, especially if you come back to it after a long hiatus. Employers also value programmers with a proven track record of writing high-quality code.

There are a few theories I have about why we code the way we do. The primary culprit, in my mind, is Olin’s “just get it done” mentality. The sad fact is that classes only run for a semester at a time, so most projects are roughly three weeks long. This often leads to frantic hacking. People view testing and refactoring as impediments to rapid iteration and development. “I want to get this working before we do it a different way” turns into, “It works, we should move on to the rest of the project because it’s due in two days.”

Another part of the equation is online documentation. Online documentation is broken into two sections; how to do things and how to test things. Anecdotal and personal evidence suggests that Oliners rarely stumble across the pages that explain how to test and quickly leave if they do. Worse, the documentation that explains how to do things rarely, if ever, embeds relevant content about tests. As a result, Oliners have a skewed perception of the importance of testing. In reality, testing is just as important as functioning code.

The last offender I’ll address is the notion that refactoring, clean code, and tests aren’t the sexy part of engineering. To many people, the neat part of coding is solving a difficult problem. Anything that happens after solving a problem is project overhead, a chore that has to get done. The most interesting decisions about software projects often occur after a bit of new functionality is created. The question changes from “How do we do this thing?” to “How can we write this in a way that anyone could understand and safely modify?”

Olin’s website says that “Olin ‘engineer-innovators’ envision and deliver products, services and systems that transform the way people live on this planet.” What Olin’s website does not say is that the process by which products are created is just as important as the actual work that’s done. We need to learn both sides of engineering, the process and the content.

So what can we, as engineers who care about processes as much as functionality, do to improve coding at Olin? I recommend reading books about coding practices. The Art of Unit Testing by Roy Osherove, Clean Code by Robert Martin, and Practical Object-Oriented Design in Ruby by Sandi Metz can all be obtained online and are excellent introductions to good code practices.

Short of that, talk to me or anyone else who has experience in these areas (Allen Downey is an excellent resource). If you’re writing Python, take a look at the unittest and mock libraries. Check out MathWorks’ page on writing unit tests in MatLab. Start learning about these tools. Start thinking about how you can write clean code.

I can’t evangelize good coding practices alone. Let’s start a discussion about better code at Olin.

The Sega Pico is a unique beast of a console. Released in 1993, it continued to be sold in stores until 2005, an unusually long lifespan for just about any single piece of technology. Part of its longevity was due to its target market; the Pico is an educational console, like the Leapster. Children do not demand the same quality of graphics that older gamers do, which meant that the same hardware could last longer. The Pico was not even cutting edge when it was released, as it used hardware based off of the Genesis, which was released five years earlier. However, the Pico was unique in its hardware input. In addition to five buttons, the Pico features a large touch pad that comes with a pen stylus. This is utilized extensively in its games, which often feature a doodling section. The games themselves come in a unique format, as well. Rather than a single simple cartridge, Pico games have several panels, or pages, that are flipped to change the action on the screen.

So if this console is so unique, lasted so long, and was made by Sega to boot, why have most people never heard of it? How could it last so long in that case? Well, it turns out to be a regional difference. The Pico did incredibly well in Japan, with more than 300 games released for the system there. However, overseas, it was much less successful. In the US, it was released in 1994, where it was given somewhat bizarre marketing and relatively little support. At the time, Sega was emphasizing its nature as an “edgy” video game maker to contrast itself with Nintendo. However, an edgy image is not helpful when selling a product for young children.

Considering the deep game library in Japan, the poor US sales performance of the Pico is somewhat of a disappointment. As a Sega system, it naturally had a few Sonic games, but it also had such diverse icons as Gundams, Winnie the Pooh, Mickey Mouse, and Pikachu. You read that right – a Pokémon game on a Sega console. Three of them, in fact. Suddenly those Pokémon iOS apps coming out these days don’t look so weird. Bringing Disney’s Pico games to the US would have raised the Pico’s fortunes substantially, but unfortunately the Disney content was never translated. Well done, Sega.

Those who want to experience the Pico’s deep pool of games have somewhat limited options. Due to the Pico’s audience of children, the emulation scene is not very advanced. The code of many Pico games has been extracted from the cartridge (a process known as dumping) due to the heroic efforts of a single group of people, Team Europe. Dumping a game means that the game survives the limitations of the hardware and becomes available to more people. Unfortunately, the number of games dumped is still a fairly limited set. The hardware shared with the Genesis means that some Pico games can be played on Genesis emulators, but there are major incompatibilities, which are different for each game.

Looking back at the Pico, it becomes clear that Sega was ahead of its time. Games for children using touch screens are coming back into vogue with tablets. The resurgence of the genre and the popularity of the Pico in Japan both show that Sega was heading in the right direction…. But, as was often the case, Sega messed up. The real lesson you can learn from this educational system is that contradictory marketing and a lack of translating the right content will sink a platform any time.

As I start this article on October 27th, I am celebrating my 22nd birthday (pardon me while I cry in the corner) and it got me thinking about a fun fact/wikipedia game I once saw. The premise: Google “died + (insert your birthday here)” to find out what famous person you are reincarnated as via the top wikipedia articles that appear. My top two results:

Allen R. Schindler, Jr. – a navy sailor who was brutally beaten to death in a bathroom for being gay. His case helped instigate the “Don’t ask, don’t tell” act. He was also 22 at the time of his death.

David Bohm – considered one of the most significant theoretical physicists of the 20th century who contributed innovative and unorthodox ideas to quantum physics, philosophy of mind, and neuropsychology.

Granted, I was born at 2am and my mother was in labor for 24 hours so time of their deaths comes into question.

Here are a few more from your fellow Oliners.

Margaret Lidrbauch,
Born 2 March 1995

Hugo Cole – a musician who played cellist for several orchestras, a writer/composer of seven operas along with a fair amount of chamber music, and musical critic of Guardian and Country Life

Vivian MacKerrell – a British actor who became an inspiration for Withnail, a memorable character in British cinema
Ray Moore – a right handed pitcher in Major League Baseball

Matt Wismer,
Born 22 May 1992

Last episode Jonny Carson did on the tonight show

Daniel “Dan” Enright – working with Jack Barry, he became one of the most successful game show producers in American television, producing several network game shows such as Back that Fact, You’re on Your Own, Tic-Tac-Dough, etc.
Antonino Joseph Accardo – (aka. “Joe Batters” or “Big Tuna”) a day-to-day boss of the Chicago Outfit who eventually became the final authority. He moved the Outfit into slot machines, counterfeit cigarettes and liquor tax stamps, and also expanded narcotic smuggling.

Elizabeth Mahon,
Born 19 July 1993

Newby O. Brantly – an inventor, engineer and entrepreneur who started the Brantly Helicopter company. Some of his patented inventions include a knitting machine, a pump jack, and a brassiere for female athletes.

Gordon Gary – a Scottish Cardinal of the Catholic Church and the first resident Scottish Cardinal since the Reformation.

Girilal Jain – an Indian journalist and editor of The Times of India (1978-1988), best known for his book The Hindu Phenomenon.

William “Bill” Warner,
Born 9 September 1994

William the Conqueror – (official year of death: 1087) the first Norman king of England whose “changes in the Church, aristocracy, culture, and language of the country have persisted into modern times.”

Jack Warner – (official year of death: 1978) president and driving force behind Warner Brother Studios and several of the hard-edged social dramas for which the studio is known today.

Mao Zedong – (official year of death: 1976) a Chinese communist revolutionary and founder of the People’s Republic of China. He is infamously known for ‘The Great Leap Forward’ (among other disasters) which lead to the death of 45 million people over a 4 year period.
Patrick O’Neal – a US television, stage, and film actor. His credits include: Night of the Iguana (broadway), King Rat, Stepford Wives, episode of Twilight Zone, etc.

Miles Beevor – a solicitor, pilot, businessman who fought in WW2 and later went on to be the managing director of Brush Group Lt. as the company pushed to produce diesel based locomotives in the British Railways to replace the regular steam ones.

All sources: Wikipedia

Special thanks to those who sent me their info.

Though Olin is marketed for our innovative educational approach, the curriculum and teaching methods are becoming increasingly stagnant. As an institution, we have managed to create a successful project-based and self-directed learning environment, which is well-renowned by many other universities. However, with this pressure to be a role model for other schools and have positive media surrounding us, we are stifling environments that are conducive to change. We are left with the choice to either model what we have done or continue progressing engineering education by making mistakes and figuring out what works.

Without this external pressure on reputation, we could begin experimenting with areas of the curriculum that are so often overlooked. We could think about fundamental changes to the three tenets at Olin and figure out where entrepreneurship and the arts and humanities belong. The introductory science courses could be replaced with integrated classes, and we could apply our own interests and passions to course material. As students, we could ask for the option to pursue non-accredited degrees from the school and have more of a choice in what and how we learn. We should not have to feel as if we have to sit through required classes, stay awake, and struggle to motivate ourselves. The professors here are incredibly open to change, and if we are willing to make sacrifices, we could make great advances in teaching and learning. There are so many ideas that are incredibly inspiring, empowering, and contagious that should not just be lost in the nuances of the system.

By marketing ourselves as a school with an innovative curriculum rather than a school that is constantly changing, we risk losing the very innovation that we are marketing. The students who apply to the school are beginning to change as Olin’s name grows. We are seeing fewer people who are eager to build from the ground up and attracted to an environment that is risk-taking. We are taught to reach far and stub our toes on our projects. We need to be doing the same with our curriculum. After a decade spent trying to perfect our original aspirations, we should pause and look at opportunities to innovate engineering education. We need to make sure that we do not stop innovating simply because what we have works.