Thread by @sarahmei

Hi, it's too early and my mentions are full of dudes being Very Annoyed that I said (again) that computer science degrees aren't essential.

So, a few things about that.

1. That's a pull quote from a talk I did yesterday that is mostly not about that.

The disconnect between what we interview for and what we actually do has bothered me since I took my first real job in 1998.

My interviews as a fresh CS grad were full of linked list cycles, string comparisons, and pointer arithmetic. All in C.

I did really well at them. I could analyze runtimes & trade off data structures. I figured I knew everything I needed to write software.

Then, I took an actual job.

I was writing COM in C++. I thought, great! I did a little C++ in school. No prob.

Except: there was a LOT of boilerplate. All my coding in school was in individual text files, not inside a framework like this.

Navigating the codebase was totally bewildering. The coding itself was easy - figuring out where to PUT my code was the hard part.

I had also never used source control before, unless you count directories full of tarballs with names like project_backup_01.tar 😅

I had also never used an IDE before. In school it was all vi - now I was staring down Visual Studio.

That first year, I spent maybe 5% of my brainpower on _anything_ I learned in school.

The other 95%:
- merging takes literal weeks, I should maybe just make tarballs
- these dudes aren't listening to my suggestions

- fuck where's my code, did the file get overwritten??? fuck
- whyyyy won't VS just show me the file tree

- the PM gets annoyed when I want to talk about his vague "requirements"
- oh well, I guess I'll make something up?
- OMG HELP

I thought it was the job. So I started interviewing other places. More whiteboarding pointer operations! I was back in my element.

Oddly enough the jobs were mostly for java (then the new hotness - think node today) and java didn't have pointers 🤔

You'll Never Guess What Happened Next

Like most bleeding edge stacks, writing Java was 5% coding & 95% "getting shit to work."

Fiddling with config files, reading sparse documentation, does this even run on apache?, ops dude won't help, says VMs are toys/a fad

The pattern across all these jobs: CS fundamental quiz as interview, then once hired, find the job needs a totally different set of skills.

There exist jobs that use CS fundamentals more directly. Just look at my mentions, dudes love to tell me about them.

But for most jobs, the CS fundamentals interview serves more as a tribal marker than as a test of anything you'll actually do.

Knowing how to find the cycle in a linked list is a shibboleth - an in group/out group determination.

I knew the secret handshake, so I got in. But someone who didn't know it could have still done the job.

Possibly better, given how long it took me to learn how to people.

We fetishize code, like being able to write correct, efficient code is the most important skill to have in a dev job.

We're kidding ourselves. Code is one skill among many that makes a successful developer.

Code (including CS fundamentals like data structures & complexity) is also the dev skill that it's easiest to practice & get better at.

It's much less straightforward to practice, for example, convincing your ops person to put the bleeding edge into prod.

Where's the wikioedia page or #basecs blog post for that? :p

So anyway. That's why I said yesterday in my talk:

External Tweet loading...
If nothing shows, it may have been deleted
by @editingemily view original on Twitter

In the context of the talk, this was one of a list of things that indicate to me that our whole model for software is wrong.

Others include: if what we're doing is engineering, why is nothing ever repeatable?

If what we're doing is like building something physical (a "product") then why is software never done?

Our current model for software is that it's fundamentally math or engineering.

Like any model, it leads us to focus on and value those aspects, while ignoring or devaluing others.

But don't confuse model with essence, like people do when they say things like "code is math."

I think the math/engineering model for software has outlived its usefulness to us. That's what the talk was about.

We need a model that explains our modern experience of software better.

We need a model for software that answers the questions I posed, including "why do CS fundamentals only come up in interviews?"

In the talk (which is called @LivableCode and has its own twitter account - that's branding™) I propose an interior space model.

It's an extension & elaboration of this set of thoughts: twitter.com/i/moments/8433…