A lot of Oliners are overworked. You may already have observed this. The fact is, even though we don’t compete for class rank, we do keep up an atmosphere that glorifies the near-burn-out. We praise the over-achiever, and we marvel at how the people who pack everything in manage to pull it off. And it’s not surprising that we do so. But this is a reaction that occurs – and has in our past occurred – without proper scrutiny. And there are repercussions to this mentality, so it’s long past time that we take a close look at it. It’s long past time that we examine the ways that these choices are affecting our lives and the lives of those around us.

This article is timed specifically to incite a moment of thoughtfulness when you register for classes this month. I spoke with Jessica Townsend, the Associate Dean for Curriculum and Academic Programs, about the issue of students enrolling in too many courses, and our conversation spanned a variety of topics – describing common pitfalls of overloaded students; weighing the value of class-work to time otherwise spent learning; and the unexpected emergent properties of the system. Jessica summed up the conversation neatly: “Four classes a semester should provide you with a pretty fricking stellar experience. We designed our curriculum for 32 classes.”

Yet, Jessica sees the same narratives over and over. Students overload. They lose touch with the clubs and activities they enjoy. They perform worse in their other classes. They burn out and end up dropping a class, no farther ahead than when they started. I had these experiences as a student too. In my three semesters immediately after Pass/No Record, I took 61 degree credits in addition to clubs, co-curriculars, and passionate pursuits. Each and every semester, I had one ‘dump’ class that I barely spent time on, and hardly got any learning out of. I also couldn’t really delve into the material in my other classes – the ones I did care about. I remember, everything had a priority level, from assignments to friendships to sleep. I visualize it as running around, handing out spoons from a little jar – a spoon for every little task. But sometimes, you have too many tasks, and not enough spoons! Then you have to go off and do whatever it is you do to get spoons back.

This happens to all of us. This is the status quo. But it’s not a good thing. It isn’t a desirable thing. What if we each committed to change it? First of all, we’d be doing ourselves, our teammates, and our teachers a service in our other classes. Just because you’re enrolled in a class doesn’t mean that you’re really engaging with it. In classes you care less about, try to find something to connect within the syllabus instead of mindlessly chugging through the material. Talk to the teacher. Work something out with classmates. Work smart, and be happier. You are in charge of your learning. And we all only have so many spoons.

Now, many students are able to overload without running themselves ragged. But they still are making a trade-off in the sort of learning they are engaged in. Yes, Olin’s faculty is incredible and their classes are both innovative and intriguing. However, not all learning can, or should, come from the classroom. Jessica told me: “When I see the time and effort that people spend on academic teams, independent studies, passionate pursuits, research with faculty, personal projects… I see that Olin isn’t just about the classes. I think you lose the opportunity to engage in these activities when you take too many classes.” One alum a few years out told Jessica: “HPV was by far the most valuable thing I did at Olin.” And in my own experience, the time I spent outside of the classroom working on leading, coordinating, and empowering student teams brought me much more joy and fulfilment then my academic work did. After returning from my LOA, I stayed almost as busy as I was before I left, but this time, my work was almost entirely extra-curricular. Of course, I’m somewhat of an anomaly, since I knew that I wouldn’t go into engineering. But the point transcends disciplines. You will be glad to do what you love, and you will reap the rewards from it.

Of course, I know that there are certain realities that we have to accommodate. There are limited course offerings. There are scheduling issues. There are limited spaces in certain classes. Course registration isn’t always pretty, and occasionally, we feel that we have to try to scratch out a space to fill our needs. The add/drop process is a complex system, and as such, the behavior of the constituent components creates certain unexpected emergent properties. For instance, when students hedge their bets by signing up for five classes while intending to take four this puts pressure on the faculty to teach more sections of the fundamental classes (more commonly selected as extras than special topics). Certain faculty members get trapped offering these standard classes semester after semester, which a) is not so interesting for them, b) is bad for more specialized majors, and c) reduces the overall diversity of offerings. In any case, Jessica says that she sends a “don’t panic” email out every semester: Apparently “enough people change their minds about that 4th class” that students end up getting their desired course load without really having to game the system.

That isn’t to say there are no valid reasons to overload (achieving the sustainability certificate, applying to pre-med programs, preparing for study away, making up withdrawn credits, are the ones that immediately came to mind). And everybody’s situation is different. I grant this. Still, with so many forces pushing us to do more, more, more, it’s important to realize there is another side to the issue that I strongly urge you to consider: Do less. Do what you love. Do it well. You shouldn’t need to justify doing the intended amount. You should need to justify doing more.

So, please take the time to consider, when you’re signing up for classes during registration: You only have so many hours in the week. You can choose to spend your extra hours on an extra class. Or, you can spend them doing anything else that you care deeply about instead. This is the decision you’re making. This is how it works. Of course, at the end of the day, if you are happy with your choice, then I’m happy for you. Good luck with the semester – I hope you avoid running out of spoons!

When I came to Olin, I lost touch with a part of myself that used to be very important in my life, my religion. Practically from day one I heard people openly discriminating against religious people. My religion was not represented in the stand-up, diversity exercise in OIE. From then on, I never really got a chance to open up to people about that side of myself, because religion is something Olin students tend to shy away from talking about.

This has to change.

First of all, the discrimination against people who are religious has to stop. I have noticed this particularly with people of Christian or Catholic faiths. People see them as irrational, self-righteous, stupid, and ignorant for being part of their religion. And these ideas are all reactions to mainstream religions, not even to some of the more obscure religions. This itself is ignorance.

We have a relatively large population of Jewish people at Olin and I have noticed that everyone seems more accepting of Judaism. I think this stems from people viewing Judaism as secular, a culture more than a religion. This may be true for some or many Jews, but certainly not all. There are Jews at Olin who are religious, who believe in God, who practice Jewish traditions not just because they were brought up doing so, but because those traditions has deep spiritual meaning to them.

We as a community need to be able to have open, productive conversations about all aspects of life, including religion.

At Olin we try so hard to become great engineers, and great engineers can design for people of all religions, races, genders, sexualities, ages, etc. I feel like many people hold the belief that religious people can’t be scientists or engineers, but in fact there are some people who come to religion through science. Francis Collins was the leader of the Human Genome Project, and his book, The Language of God, describes how he became Christian because of the project. Pope Francis recently made a statement that the Big Bang Theory and Evolution are true and in line with the teachings of the Catholic church. He stated that “Evolution in nature is not inconsistent with the notion of creation, because evolution requires the creation of beings that evolve.” This belief may not be held by all Catholics, but it demonstrates how religion and science are not mutually exclusive.
We need to accept the fact that there are a number of people at Olin and in the greater tech community that believe in God, Goddess, many gods and goddesses, or in some higher power whether well-defined or not. I should not fear that people will think less of me if I am open about my religion, but that is how I have felt my entire time at Olin.

So here I am, writing to the whole school saying that I, Claire Barnes, am Pagan, more specifically, Wiccan. This article is about me, coming out of the proverbial broom closet.

Our culture and media perpetuate so many misconceptions of what Paganism and Wicca are; the words Pagan and Wiccan commonly evoke mental images of devil worshipping, curses, blood sacrifices, and flying around on broomsticks. I won’t go into the history of those stereotypes now, but I would be happy to discuss it with you if you want to hear my take on it.

Instead let me tell you what Paganism is to me – paganism is an umbrella term for any nature-centric religion. This is intentionally vague, because one of the main themes that Pagans believe is to practice what is right for you. There is no Bible, Torah, or Qur’ān of Paganism, no central book that defines the religion, and no figure of authority to preach it, so it is very different to each individual who identifies with it. I find great divinity in nature, which is the crux of Paganism; the rest is just details.
I won’t go into all the details here, but I just want to state that I do not sacrifice babies, virgins, or any animals. I do not worship any kind of devil, and I have never met a Pagan that even believes in any satanic figure. I cannot defy the laws of physics and trying to is not what my religion is about. I do not fly around on broomsticks or make love potions in cauldrons, though I can tell you a little about their symbolism as they relate to Paganism and Wicca.

A few other Oliners and I will be hosting a slightly belated Halloween/ Day of All Saints (or Samhain as it is referred to in some Pagan traditions) event at 8pm on November 4, so keep an eye on carpe if you are interested. I will try to host more events that showcase what Paganism is all about, and I encourage you to attend if only to create an open dialog about our beliefs.

Religion should not be a taboo topic. I challenge you to ask your friends about their spirituality and tell them about your personal beliefs. We should be open, understanding, and able to celebrate all of this diversity together as a community.

Last month, we proposed the question: What do regret not doing? The following are your answers.

I regret not going to a Comic Convention with all my friends in high school. And now I’m at college here, and they’re at colleges everywhere else. – Jennifer Anderson

Going to Brazil/Insper this semester. – Anonymous

I regret not getting to know my professors better – while I am friendly with most of them, I don’t think there’s that one professor I’ll be rushing to see when I come to visit Olin after I graduate. – A Senior

I regret nothing. – Anonymous Chloe

Study abroad! Do it, even if you don’t want to. – Anonymous

Be out publicly (as gay) in college. College is an important time for building relationships, and hiding this from people can really hinder relational growth. That doesn’t mean I can’t still make amazing friends here, though! :) – Anonymous

Breaking the six week rule as a first-year. – Anonymous

Next month we are changing things a bit. An open ended will be targeted at Faculty and Staff, to be published in the December 2014 issue. Stay tuned for an email to submit questions.

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.