Writing

Feed Software, technology, sysadmin war stories, and more.

Wednesday, January 2, 2019

Feedback roundup: formal education, SWE, SA, or what?

Happy 2019, everyone. I really appreciate the feedback I get from people who read stuff I've put out here. It drives some of my posts, and this one is no exception.

A couple of different comments have asked similar questions about what got me going with this stuff, and what sort of education I may have gotten along the way. I'll try to answer them together.

"Did you ever get a formal education in CS/systems?"

Sort of yes, sort of no. I did start in a Computer Engineering degree (a mix of CS + EE) a long time ago when dinosaurs walked the earth, but I dropped out. What doomed me? Honestly, the higher math was not working for me. I failed Calculus II twice, one time with the evil "Who's John Elway?!?!?!" prof, and another with someone else. The more "mathy" bits of the science side of things, like Thermodynamics, also got me. That plus real life goings-on told me it was time to quit, and quit I did. I just went to work full-time at that point.

But that's not the full answer, either. I had been doing the sysadmin/programming thing for a good number of years prior to that. I had to learn it the hard way to keep the users up and running, and the boss(es) happy. There was a lot of "seat of the pants" slapdash system administration going on. I was all by myself, with no guidance, no mentor, and basically no budget.

Being gainfully employed in the realm you're supposedly working to enter with the degree while you're getting the degree is interesting. I saw a bunch of things from school which had no bearing on the "work" side of my life. I saw a bunch of things from "work" which never showed up in the "school" side.

I actually did a "postmortem" a few years after dropping out, where I found my old class schedules, figured out which classes I had managed to take, and wrote down my notes on what I remembered from them. It wasn't pretty. I'll skip all of the "core" classes here (English, Psychology, History, that sort of thing), because, well, I *liked* those. Those were good stuff. The actual "meat" of the degree, though? It was a mixed bag: some good parts, some bad parts.

"Intro to C++": we had this textbook which provided some source code. It was doing SOMETHING which made the thing throw a general protection fault (!!!) when the destructor ran. The prof said "oh yeah, it does that" and advised us to chop some bits out of the code, effectively removing the destructor. I wish I had that code now so I could apply my current knowledge to it to find out just what it was doing wrong.

"Calculus I": well, I managed to write a really crappy analog clock on my TI-85 during class. I guess I was bored, or frustrated from being lost, or both. Somehow I made it through this class only to later bomb spectacularly in part 2 about a year later. I think the curriculum shifted and left a huge gap in the middle and I never recovered. Plus, none of it ever really made much sense.

"Engineering Graphics": I can say I've actually taken a drafting class because of this. Plus I got to use a massive plotter to render my projects in order to turn them in. WHIRrrrrrrrrrrrr zip ZIP zip ZIP ZIP ZIP zip!

"Intermediate C++": Life without the STL for containers (map, vector, and friends) is terrible. I didn't know it then, but looking back on the labs now, it's clear: what they had us doing was ridiculous. Also, the whole multiple inheritance thing? Such incredible garbage to foist upon us. I never even got the final lab to compile, never mind work. I submitted it with a prominent README declaring my utter failure. Looking at it with fresh eyes all these years later, I see an obvious problem now: declaring variables inside a switch case is a spectacularly bad idea! Maybe that's what was going on...

"Electrical and Electronic Systems": Okay, this one was kind of neat, too. I got to play with an oscilloscope and was shown quite clearly that you can slap a resistor and a capacitor together and wind up filtering a signal with it. Mind blown. They showed us signal modulation, too. That's helped me a lot over the years. We talked about basic logic gates like AND, OR and NOT. Then we had a bit about simple state machines: we are here now, and then we transition over here when this happens. That changed the way I looked at solving problems in code.

"Discrete Math": the most UN-math class I've ever had. I liked most of it. It was like a multi-week conversation on how to group things and build graphs: circles with arrows pointing at each other. Happily, I took this the same quarter as the last one, so the state machine thing overlapped nicely. We also covered automata. One bad part: proofs. Somehow, they were only in the curriculum for one week and then never came back, and so my "ignore them and maybe they'll go away" actually WORKED. Amazing.

"Calculus II": as mentioned above, tried twice, failed twice.

"Digital Math and Logic Circuits": this one was pretty fun. It's where my traffic light lab debugging story comes from. I learned about one's and two's complement and the whole "wraparound" behavior of signed numbers I had already seen in computing finally made sense. We expanded on state machines and transitions, and got into sequential logic, with clocking. Naturally, my traffic light implementation had a 555 pulsing around 1 Hz and that pulse was ANDed with the "proceed to next step" condition lines. It was like writing code... on a breadboard.

"Data Structures": some early-C++ garbage, but not as bad as before. It taught me about binary trees, and I proceeded to foist those upon a great many projects for many years after that. Remember, this was before the STL, so I was rolling my own implementation every time. Terrible! But I learned it here.

"Microprocessor Systems": another fun one. This one basically took the silly little breadboarding projects we had been doing in earlier classes and had us wire up a tiny microprocessor to it. I did a display hack in there and enjoyed showing off a little.

"Advanced Computer Systems Design": this one was all design and no wiring. There was a big multi-week group project. We had to spec out an instruction list and it had to have certain features, like indirect addressing. It looks like I still have the actual file used for one of the papers I did. It's a WordPerfect document. Wow.

"Thermodynamics": a giant smoking crater, mentioned above.

"Compiler Systems": taught by the same prof as the Discrete Math class, who was kind of loopy and I liked the way he rolled. As described above, I liked this one, and it changed the way I looked at certain problem spaces. Happily, I managed to avoid going all "golden hammer" while solving problems after that. Number of programming languages I've invented since taking this class: still zero. Phew!

"Digital System Design": here's where I finally got to see what an EEPROM burning process actually means. There was more state machine stuff here, and it dovetailed with the compilers class nicely - they were the same quarter! This is also where I learned that actually reading the giant manual could save a LOT of manual cruft that everyone else apparently ended up doing. Use the primitives they provide and you'll probably have a far better time of it.

That's pretty much it. Going in, I expected to pick up a lot from the CS stuff and not so much from the EE stuff. It turned out that the CS stuff wasn't so great, and the electronics side of the EE stuff was quite interesting and fun. Maybe it was just the teaching staff?

...

"Would you describe yourself as more of a sysadmin type, or a software engineer type as an SRE? In your experience, is there a really a distinction or room for both?"

I've frequently reached for "sysadmin" when trying to describe some of what I do, but it's not really a good match any more. I mean, yes, I've run multi-user boxes for other people, which I considered the original definition. (That's where the "you're not a sysadmin if you don't have users" that folks like me used to tell home Linux kiddies in the 90s comes from. We were mean!)

I've come to learn that there are different degrees to which people can get involved with this stuff. Some folks are happy staying at the very highest levels, sticking to installing stuff from a DVD and/or clicking on buttons the OS/distribution provides for them. They do all of their "admin" work in graphical terms, and have no real idea how things work. If they break, they pick up the phone and invoke their support contract. They "run" these boxes, but mostly in the physical sense: keep 'em powered on and up above the water line when it floods, and so on.

Other folks add the whole "systems programming" angle to it, and that's more towards the world that I tend to inhabit. This plays nicely with my tendency to dig into strange problems and try to find out what's actually going on inside a broken thing. Still, that's not entirely it, either.

Then there's the people angle. People have problems, and those problems happen to involve computers. I happen to know a few things about a few parts of that giant domain, and sometimes I think I can help, so I try. I wind up helping them by doing computer stuff, but it's the helping that I'm there for. If I could help people without needing the computer angle, I'd be all over it. But, eh, this is what I'm actually good at, and it pays the bills, so I do it to pay said bills.

I run boxes and write programs to solve problems, but I only solve problems that exist for myself and other people. The whole "X should exist just because" angle doesn't do a whole lot for me. Those projects of mine tend to go nowhere, and I'm completely honest about it.

Give it a reason to exist, though, and look out world.

So, back to the question: am I a sysadmin, a SWE, an SRE, or what? Well, technically, I've been called all of those things at various points in different jobs. I was an actual SA-SRE at that place in Mountain View once upon a time. Then I interviewed for my own job (grrr) and became an actual SWE-SRE, changing castes as I went. So yeah, I've been an actual Silly Valley Software Engineer (tm), and a SRE, and a sysadmin too.

Not too long ago, I was a "production engineer", which near as I can tell is an overloaded title from another realm (actual factories) which was used at that company because "it's not SRE". Basically, it was a way for them to set themselves apart from Google (gasp!). (Aside: The actual name is strangely close to the name of the person who came up with it. Did anyone ever notice that? Mix up the letters a little.)

The title was a poor fit for the actual life I led while there, and I was completely open and honest about that. People would ask me "what's it like to be a PE at FB" and I'd say that I honestly didn't know, and we should go ask a real one. My life of wandering around from problem to problem was nothing like what actual PEs did, and what some still do. Also, the company has changed, and wandering is now a very bad thing to do if you value your career progression, promotions, bonuses, and so on.

Seriously, if you still work there, STOP WANDERING. Go read my post from March about this if this is new to you.

I still haven't answered the question, apparently, so I'll try again: I like to think of myself as someone who helps people with problems when I think I can be of assistance. If it means I resemble a this, that, or the other thing along the way, so be it. That's just a function of a few twists and turns in my life along the way, and I'm sure I could have gotten into something else entirely had things been slightly different.

A personal note: go watch Broadcast News. If I had gotten into TV production, I totally would have been Jane.