Humans of Computer Systems: Frenchie

Programming

How did you learn to program?

I was lucky that our 5th grade (age 9-10) teacher knew how to use the computers in the school. I learned a little bit of BASIC on a Thomson MO-5. Then I had other hobbies until high school, at which point I joined a semi-formal programming class hosted by a math teacher. That's where I really cut my teeth with Pascal and x86 assembly. Later I got a degree in software engineering.


Tell us about the most interesting/significant piece of code you wrote.

I would mention two. 

One is a critical component in a distributed system: several thousand lines of code, highly concurrent, performance sensitive, high risk (data corruption), lots of tests, months to get it right, years of refinements (optimizations, new use cases). Very valuable. It is far from perfect in several ways, but it worked very well in production for many years across many customers. An invisible part of a complex system.

The other is a short script (a couple hundred lines), a mix of shell and awk. It barely changed after one year, but users kept using it for over a decade. Fun to write, easy to use, with human users.

The first thing paid my salary several times over, it was deep, important work. The second was invisible to the business side but very useful to operations, and very fun to write and to use, and I got to help users solve their problems with it. I wish I could spend more (all?) of my time writing such small, useful programs, and not just large, complex systems.


Who did you learn most from about computer systems?

Most of what I learned, I learned reading stuff written by many on the internet. But I think I learned at lot of fundamental things, and in more pleasant ways, from programmer friends in high school and college.


Who is the greatest programmer you met, and what is impressive about them?

Probably this guy who could write high-performance HP48 assembly code for a stunning video game, at a time when we should both have been 110% busy with academic duty (and the guy got outstanding academic results).


What is the best code you have seen?

I'm not sure what I would call best. But I was somewhat impressed by CGEN, the system in GNU binutils that, based on a CPU ISA specification written in Scheme, generates almost all of the C code for an assembler, a disassembler and a simulator.


What do you believe are the most important skills to be successful in your field?

Some level of optimism and self-confidence, because you need to pick up new tech skills as time goes by. Paired with curiosity, because (almost) nobody is going to tell you what to learn next.

A good command of oral and written communication, because you cannot work alone all the time: at a minimum, you work for someone, you must learn from someone.

Personal management, like time management, idea management, note taking, drafting (to put ideas in writing, but not necessarily in code). Having a sense of what needs to be done now, later, or never. Don't be a mouse constantly running in a wheel, without a sense of direction.

Debugging, because very early in our journey, and then time and again, we reach the limits of our understanding, and must stay on top of the systems we create and manage.

Some amount of problem solving in general, some CS fundamentals (data structures, complexity, basics of OS, hardware and language).


What quality or ability do you value most in a computer systems person?

The ability to understand or design complex systems, where components interact to solve the right problems without creating (too many) new problems.


Personal

Which of your work/code/accomplishments are you most proud of?

I reinvented distributed tracing from first principles (then read the relevant papers), promoted the idea, designed and developed a working implementation. I was very proud that I came up with the idea on my own.


What comes to you easy that others find hard? What are your superpowers?

I tend to spot a lot of concurrency bugs. It's rather depressing, because it reminds me that there are so many incorrect programs out there, crashing or corrupting the data!


What was a blessing in disguise for you? What seemed like a failure at the time but led to something better later for you?

My very first project was not the one I was hired for; turns out, I made most of my career from the expertise acquired then.


What do you feel most grateful for?

As a seasoned programmer, I probably never will have a hard time finding a job with a decent pay. Since I graduated, money has never been an issue.


What does your perfect day look like?

Hear about someone's itch, find out I know how to solve it with a small piece of code, write it, give it to them, make them happy!


What made you most happy in the last year?

We got vaccines for COVID.


Work

What was your biggest mess up? What was the aftermath?

A script I wrote had a bug that corrupted data. The first engineer who used it was careful in rolling it out, sensed a problem, mitigated the issue, notified me: I fixed the bug, tested better, helped the engineer restore the data, and no data got lost in the end. But I felt quite bad for a few hours, and lucky that I worked with a smart guy.


What was your most interesting/surprising or disappointing interaction at work?

Some people appear way smarter than they actually are: that guy could juggle with a lot of advanced concepts and lingo, he could write a lot of code very quickly, but his systems were full of glaring holes. Any objection to his designs, he would counter with a proposal adding extra complexity that nobody really understood. Eventually I learned to laugh at the absurdity of the situation, but it took me years.


What do you like most about your job/profession?

The medium (code, data) is infinitely malleable.

The need for decent programmers gives us a lot of bargaining power, so we can enjoy good pay and flexibility that most people can only dream of (which is unfair).


What do you dislike most about your job/profession?

The field is so new that companies are immature and inefficient (and sometimes plain dangerous), and there is so much demand and money that companies get away with it.

Some days I think that a moderate amount of frugality would set certain things straight. Then I remember: it also makes people cut more corners.


What would be the single change that would improve your work environment most?

A healthy management structure: people managers who actually know how to manage people, and execs who understand systems of people, and know how to set up culture, incentives, and feedback loops between cooperating humans/teams.


Technical

What do you think are the hardest questions in your field?

What problems should we solve.

What should we build, what should acquire, what should we discard.


What are you most disappointed about the state-of-the-art in your field?

Most computer users have extraordinarily complex and mature apps to help them do their work.

Most programmers are stuck with ancient text editors, debug with print statement, design with MS Word, test with a few unit tests, and just try to guess what would be valuable to users. Our entire toolbox feels lame, at least in most companies, compared to e.g. a CAD suite or video editing.

Why can't I make good systems like others make good spreadsheets?

We should be using more: simulation, model checking, profiling, data viz (for perf analysis, or debugging).


What are the topics that you wish received more attention? What do you think is a promising future direction in your field?

Modeling in general is great, model checking in particular is a game changer.


What is your favorite computer systems paper? Why?

The first that comes to mind is the Google Dapper paper. It exposes a simple, not new, yet very useful idea, it has useful charts and screenshots, it shows great feedback from field use. And when I read it, I felt a lot of validation for my own findings.


What are the most interesting blogs/twitter accounts you follow?

But I really recommend reading books, because books can take you so much deeper.  I liked those:

  • How to solve it, by G. Polya: problem solving for math, applies to other domains
  • The mythical man-month, by F. Brooks: a (somewhat dated) view of management issues at IBM in the 70s. Still some good parts, mostly the questions it asks.
  • High output management, by A. Grove: a view of management at Intel by their star CEO. Biased towards large companies, still some good practical advice for small entities.
  • Thinking, fast and slow, by D. Kahnemann: how our brains trick us into thinking the wrong things (cognitive biases).
  • Range, by D. Epstein: how generalists beat experts in many ways (I am prone to glorifying expertise, and found this refreshing).


If you enjoy reading this seriesconsider taking 10 minutes and submitting a response. All questions are optional. You can skip most, and tell a lot more on other questions you choose. 

Comments

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?

My Distributed Systems Seminar's reading list for Fall 2020

Read papers, Not too much, Mostly foundational ones

Sundial: Fault-tolerant Clock Synchronization for Datacenters

Linearizability