Defending Computer Science & Engineering in a life raft debate

What is a life raft debate?

In the Life Raft Debate, we imagine that there has been a nuclear war, and the survivors (the audience) are setting sail to rebuild society from the ground up. There is a group of academic-types vying to win the coveted Oar and get on the raft, and only one seat is left. Each professor has to argue that his or her discipline is the one indispensable area of study that the new civilization will need to flourish. At the end of the debating, the audience votes and the lucky winner claims the Oar and climbs aboard, waving goodbye to the others.  

Maybe a discipline worth its own salt would  be able to built their own boat, no? Or a good discipline would have documented their findings so well and made itself a science rather than an art, so a practitioner is not needed to transfer information.

Which discipline do I think should be the discipline to go? Let me tell you, I would oppose having a computer science and engineering person on the boat before we make sure the boat has a doctor/nurse that can treat people and deliver babies. And a wilderness expert and a biologist. Maybe also an electrical engineer. I have respect for the hardware building guys. I am an ethical person (and looks like not a good debater). I think we should do what is right for the good of humanity.

Now I can make the case for a computer science and engineering for life raft. 


We are hackers

As a child I was a MacGyver fan. In our discipline, we get to act like MacGyver everyday. We figure out stuff, we make stuff, and we make things work. We are the hacker discipline.

We synthesize stuff, and get the work done. We have been working on diverse set of tasks. From cyberphysical to very virtual. We do everything. We are the perennial generalists and improvisers.


We are debuggers

The most important person in my gang will be a systems programmer. A person who can debug a device driver or a distributed system is a person who can be trusted in a Hobbesian nightmare of breathtaking scope; a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence. The systems programmer has written drivers for buggy devices whose firmware was implemented by a drunken child or a sober goldfish. The systems programmer has traced a network problem across eight machines, three time zones, and a brief diversion into Amish country, where the problem was transmitted in the front left hoof of a mule named Deliverance. The systems programmer has read the kernel source, to better understand the deep ways of the universe, and the systems programmer has seen the comment in the scheduler that says “DOES THIS WORK LOL,” and the systems programmer has wept instead of LOLed, and the systems programmer has submitted a kernel patch to restore balance to The Force and fix the priority inversion that was causing MySQL to hang. A systems programmer will know what to do when society breaks down, because the systems programmer already lives in a world without law.

In the chaotic world of survival, there will be many failures, and a lot of unanticipated corner-cases. We are the best debuggers on this planet, period. We can tell you gadzillion ways of how things can go wrong. A career in programming and dealing with distributed systems prepared us for seeing unanticipated ways things can go wrong.


We are abstract thinkers 

I would have loved to say that we are computational thinkers, and computational thinking will provide a lot of value. But, you see, we still couldn't figure out what that computational thinking is supposed to be yet.

I think a close proxy to computational thinking is abstract thinking: the ability to abstract things. It is still more of an art. But we are good at it, because we use practical abstractions every day. You would think mathematicians could also be the abstraction people, but they are too abstract that they are far removed from the real plane. 

Great CSE people are great at abstracting. After abstracting, we solve the problem at the abstract plane, and then transfer the solution to the real plane, implement it, and generalize it.


We are quick learners

We are trained and skilled at learning new languages/tools constantly as part of our daily work. We learn at a rate no other profession could even conceive of. It is not uncommon for job ads looking for experience with a dozen different tools/languages. It is not uncommon for a computer scientist to be told to deliver a project in one month in a language she didn't know before. 

How did we get ourselves in to such a predicament? If we were the philosopher type, it would be nice to ponder to sit and think about it. But ain't nobody got time for that. We have a dozen more languages/tools to learn for the rest of the year.


We are skilled organizers

If you are looking for people to bring project organization skills, we are again your best bet. There would be managers from business or management background that will try to coax their way into the life raft (they have very strong survival instincts after all), but don't let them deceive you. Software project management people would have the most experience with dealing with chaos, ever changing requirements, and aggressive deadlines. 

Comments

Unknown said…
Entertaining read! I appreciate the little reality-check at the beginning. While we software engineers/computer scientists are important, we aren't the most important. And I think you did a good job of distilling down what it is we really do as computer scientists. We abstract things, which we can then combine and layer to build some pretty cool things. It's a fun line of work!

Popular posts from this blog

Foundational distributed systems papers

Your attitude determines your success

Progress beats perfect

Cores that don't count

Silent data corruptions at scale

Learning about distributed systems: where to start?

Read papers, Not too much, Mostly foundational ones

Sundial: Fault-tolerant Clock Synchronization for Datacenters

Linearizability

Using Lightweight Formal Methods to Validate a Key-Value Storage Node in Amazon S3 (SOSP21)