Technical Onboarding information category

Hey folks, been a while on the main blog. Got lots of stuff I’d like to talk about here at some point (like getting off twitter via buying another WP blog)! The one for today is borne of some work onboarding I’m doing for a new person on the other side of the world from me, which brings endless fascinating challenges, basically all of them good!! Was talking with my PyLadies besties (six of us ran the portland pyladies chapter for a few years and we have all stayed close) and we got to some interesting places as far as technical (and possibly other kinds that I can’t speak to) onboarding.

As I see it, there are four categories of information relevant to a new engineer*.

  1. What I expect you to bring to this role
  2. What I expect you to absorb and internalize *without* documentation
  3. What I expect you to read and reference from documented internal sources
  4. What is undocumented but which should be documented.

You’ll notice that three of these are pretty straightforward. Or at least, ideally they would be. Regarding item 1, what I expect you to bring to this role should be clearly laid out in the job req, and in our case in Data Center Provisioning, we wanted them to have strong networking, decent general command line ability (this can be switch-specific though – switches, like Cisco network switches and Arista network switches, and others, have their own structure that is NOT filesystem tree based, but which is somewhat cross applicable to ~Linux command line interfaces, which is my familiarity), virtualization experience, a little scripting, and if you have cloud ops experience and some programming, that’s a bonus.

Re the third (we’ll come back to the second), what I expect you to read and reference from documented internal sources is never as grand as you want it to be! It isn’t that we don’t have a ton of docs – we do, but as anyone in this field knows, it is a monumental task to keep it updated and constantly added to in relevant, searchable ways. We do our best and are always trying to come up with ways to incorporate this work into a regular cadence of attention and discussion.

Which brings me to our fourth category, what’s not documented but should be. This is a huge category, and it’s absolutely fuzzy with the second category! There is so much that I can CLEARLY state that should be documented, though, so even though there is gray area, there is such a huge quantity that is utterly black and white.

Finally, the category of what I expect you learn and internalize *without* documentation. I bristled at the idea of this earlier on in my career. Now, I am pretty sure that this is the secret sauce of any technical role, maybe any role period, and I believe that my success as a colleague-trainer depends upon clarifying this category over all others. The clearest examples of things in this category are, like, (in my field anyway) how to use code repositories, including how to submit your code for review and how to generally use a cloud remote tool like Github (that’s probably a pretty odd label for what GH is.. please forgive it). These are the kinds of things you would explicitly show a junior level person, or someone whose background is ENTIRELY networking or physical racking-and-stacking in datacenters, but at my job we generally expect that you have this.

The less clear pieces are harder to describe (no kidding lol). I think this is ultimately the category of company/job specific knowledge, that as you deepen your understanding, hopefully gives you tools and knowledge for future career as well. Some of this is historical context for your job, that you don’t really get until you’ve been there for a minute. The context that I have, having been at Fastly for 18mo now (not a long time but more than a flash in the pan), is a key part of the value that I bring, and the longer I’m in this job, the more valuable that will be (but not necessarily – there is an upper limit that is probably worth exploring in a “should you move on from your job” kind of post). Another piece might be, at least in my case, the unique design of what we build. Not going to get too specific in a public blog post of course, and while you can learn design generalities for what we do and make and provide, the specifics of our builds will not be known until you develop some working, repetitive knowledge. And then it will change subtly, over and over and over!

“But wait, Rachel, shouldn’t this stuff be documented?” This question is basically THE reason I felt the need to write this blog post. The answer to some of it is yes! The answer to a LOT of it is, “uh… kinda?” Like, yes, we have design docs, which are thoughtfully created and introduced to the relevant teams! And they apply to one version of it, or maybe one category of versions of it. But this one is different for pretty good reasons, and you can tell by looking at X and Y. And this other one is different for reasons we later discovered aren’t very good, and you can kiiiinda tell by looking at Z or W! I hope this is not too abstract. I’d like to get to a place where I can really define this category.

I think this second category is also partially the reflection of the fact that we simply cannot document everything. It’s not possible, and further, we got work to do folks! One of the common personal aphorisms I return to is that they’ve hired us here for our brains. This, and my last job, are not widget jobs, like my support engineer job from 2014-2016, which was extremely technical and demanding, but which 90% depended on a) ticket inflow and b) having TOO MUCH ticket inflow in order to never “overstaff” in this “loss-leader” department (a characterization I find short-sighted and even cruel – can you tell my feelings on this with what I’m putting in scare-quotes??). They need us to be finding and solving the continual edge-cases we encounter before they become major incidents or otherwise impede the function of our organization… and we are very lucky to be able to do that. Sometimes we’ll all gripe about some bizarre complexity or a decision handed down to us from a few levels up, but really, we’re all just trying to solve technical AND business problems, and it’s genuinely a rare and special thing to be given the freedom and the salary to do so with as much of your brain as you care to engage.

Quick side bar, I do think that a very technical job (to a point!! no ocean-boiling, that’s burnout territory) where you really are trying to solve problems and get shit done a little better each time, is rather a fountain of youth. Keep your brain sharp and you keep dementia at bay a bit better! No guarantees in this world of ours but cognitive function is a real thing that declines and like any muscle, the way to keep it going is to USE it!

So. Getting back to the categories of onboarding information… What do we do with this? Well, I’m working with it as we speak, and it’s HARD! It’s a bit know-it-when-I-see-it, and part of trying to write all this out was to personally try to be able to recognize the “second category” of information a little faster, so I can impart it better, so our newest engineer can internalize it more easily, so we don’t fall into the trap of trying to document something like “and then, type cd foldername…..”. And of course, the point of it all is to prepare our newest engineers on our team in the best possible way we can for themselves and for our organization!

Truly I’d LOVE to hear what you think about these categories, and if this reminds you of Some Book (or blog post!) I Should Read, please let me know!

* this isn't the place to discuss coder/programmer/sysadmin/noc/etc all having the title of engineer, it's fine, your opinion probably isn't wrong even if we don't agree, just not going to talk about it here.

Employment and Education

Hello friends! TIME HAS PASSED. But here you are again! This day finds me employed, after a long struggle. Really, I’ve been job-seeking since January, though well in advance of when I needed to, as my graduation date was March of this year. Believe me, I am still fuzzily post-graduation, extremely happy to have no far less homework than while earning my degree (en français, bien sûr !).

Understanding that confirmation bias makes fools of us all, about two months ago I changed my resume (do I write résumé? seems soooo new yorker snobbish, though it is correct) in what may have been a crucial way. My tech recruiter friend gave me some terrific and honest (read: intense) feedback on my R/CL and told me to cut out the “References available upon request” line, because duh, everybody knows that and it just takes up space. For a few weeks, I had it removed entirely. Then, I did something rather bold, and added the following snake-oil-style pitch toward the bottom of my cover letter:

“But don’t take my word for it! Just ask person_1, the leader of the free world, or person_2, the founder of Mars, or even person_3, the inventor of Post-Its! Every one of these folks is happy to -brag about- be a reference for me, so please, contact them!”

And I got a call, from an awesome company that I have always been too afraid of applying to, thinking that the folks that work there are a special kind of brilliant & that I wouldn’t have a chance in hell at actually working there. One of the reasons, other than my qualifications, that they said they called, was because of one of those people who I’d listed in that section.

Typically, references are a very late game process in the hiring world. Why bother calling references, a time-consuming and very personal (and personalizing!) process, if your candidate hasn’t even made it through a phone screen and an interview or two? In other words – why call references unless everybody is serious? But the fact that I put a few folks on there who wanted to vouch for me made a huge difference. And Portland is really so small and the scene is so focused that the names are fairly well-known. That wasn’t an accident, but I met these great people naturally, by getting out, participating quite heavily (and earnestly!) in PyLadies, and making friends with the people around me.

After two phone interviews, a task, an all-day interview, and a few (totally transparent!) hiccups, I was offered the job at Puppet Labs as a support engineer, and I feel so lucky, I have to keep from gushing about it. I left my stable, lifer career nearly four years ago to do ambiguously Better, and yes, Virginia, this is Better.

SO! Now I am LEARNING, learning learning learning! I’m still having a hard time reading the tickets that come in, but what I am able to do is parse Puppet code, and explain what it is and does, and how it’s an enormous, Neil Armstrong-style leap over previous (and still very widely used!) server management technologies. I’m pretty sure I’m in the right industry, guys, as this is really cool to me. Puppet is a company I am extremely excited to work for, for many reasons, not the least of which is getting to know the complex, technical, and awesome product. I keep a notebook on what I’m learning, and I fill several pages a day. Future blog posts will probably just focus on Puppet stuff, unless I get a chance to work on some recreational stuff. Woo-hoo!

And one last thing: if you know me, you know my absolute most highly recommended piece of advice to those looking for jobs: start a blog. Start a blog, start a blog, start a blog. Don’t wait til you code every bit by hand, don’t wait til everything is Perfect, just go to wordpress or blogspot or whatever, and start a blog. Nearly everyone I’ve interviewed with has mentioned it. Fear not about seeming stupid, because you’re brilliant.

Ok – going to cut this off before I get weepy/proselytizey/we-are-the-world-y. GOOD THING.

Aspirations toward Gittry

Over the last month, we’ve been working hard to finish up the coding and environment for, and finally the filming of, a series of tutorial videos. It’s something we’ve been working on at my job since, solidly, May, and but for a few release-based loose ends (“will our requirements.txt file really work with pip? why isn’t it working over … THERE?” etc etc), the project is over, and my contract is coming to a close. So I have a few projects I’d like to work on, AND NATURALLY, document for you!

First, let me point you to my website, which I have hugely upgraded. I’ve got a style sheet which I first applied just to the main page, then I applied it to the resume which I also updated, a bit, though it’s difficult since each position I apply for has a subtly different set of information.
therachelkelly.com
Regardless, I’m proud of the small, attractive changes I’ve made. Next up is to get a handle on some bootstrap and cherry-pick pieces of it, like the nav bar and a few other nice ideas.

Next, I’d like to run through another codecademy class, maybe the advanced web design one, but what’s more likely is the API-manipulation course. At some point soon I’d like to begin a project where I get a couple of the open APIs out there to talk to each other. My intention is not to re-invent the wheel, but to get a look at its inner workings myself!

I’m also about 60 pages through Jon Loeliger and Matthew McCullough’s Version Control with Git, 2nd ed, which is only about a year old, so quite up to date. As I’ve said, I want to be a Git wizard, and to earn that pointy, star-covered hat, it’s time to take a deep dive. It’s extremely exciting to me that I can read this book – when he (it seems like it’s mostly Loeliger’s game) says “The first number, 100644, represents the file attributes of the object… [and] should be familiar to anyone who has used the Unix chmod command.” which I am! I am familiar with chmod, Unix, and so much more relating to this topic! Wow! This is not to say that chmod is a particularly difficult concept, but that it is NOT a terribly entry-level topic either – I am rather beyond entry-level knowledge for many topics, and that is enormously gratifying.

brief aside: chmod refers to the the command which determines the level of permissions of a given file or directory. go here for more information. want to write more on this in the future, because I still haven’t found a super terse explanation.

So this Git book is great. They’ve already referenced someone that I KNOW, so that’s charming and a bit surreal. I suppose living in (the extremely small town of) Portland and being as active in the communit(y/ies) as I am, it’s bound to happen that I’ll meet or already know some People. But on to it – the book practically begins with SHA1 numbers, the hash number that Git assigns to a unique commit. Did you know that if your file is named yourfile and it says the same thing that my file, also called yourfile, says, then the SHA1 will be identical? WILD. Mind = blown. Apparently there is (very infrequently) a concern of “collision,” or two different kinds of commits yielding the same hash, but as the SHA1 has approximately 2^160 permutations (pretty sure I can’t use that word here?), that’s pretty unlikely.

So for now, the plan is to write about whatever I’m learning in the Git book, because the Git book is awesome. SEE YOU NEXT TIME!

Javascript first thoughts, mackatoots, & tutorialino

Hello again! I have been working and working and working, lately, and I have a few things up my sleeve!

First, my company, The Open Bastion, is working on tutorials in Python. Get in touch if you’d like to create with us! Note: paying gig 🙂

Next, though I know some Python, it seems that I need to keep going, so I am learning Javascript, now. Exciting! Something altogether new! So far, it seems like a friendyfriendly C analogue, based on the 50-odd pages of a C++ book I read back in the day, which makes web site and app creation a BREEZE. I know complications will come – I feel like I hear more complaints about Javascript than any other language, right now, but as with all new languages, I’m really enjoying learning the syntax. I’m doing the Codecademy interactive tutorial and it’s adorable and fast fast fast, so I feel like I am getting a lot done and learning learning! Note to self (and to youuuu!) to research later – why are semicolons sometimes required at the ends of lines & sometimes not? I wonder – is it more than just good style? With Cx semicolons are quite explicitly required, right?

Next, I’m working on a Mac, now. If you know me, you’ll know that this is, like, a huge deal for me. It’s just a work machine, AND it’s four years old, buuuuut it’s great for coding even if it’s comically bad at other things, i.e. file management (honestly does anybody EFFECTIVELY use Finder? my theory is that apple wanted to ensure that their file management system was different than windows’ [whose Explorer {directories, not internet} is superior to all others] and now they’re too bashful to back out???). The mouse pad, though, is a serious delight to use, the best touch pad I have ever operated on, and the keys are lovely to type on. It’s strange having no optical drive (it’s an Air) and the minimal number of USB ports can be frustrating, but of course, a $1300 machine is a $1300 machine, and a professional versus hobbyist (read: my perfectly delightful $600 2.5y/o windows/ubuntu machine) computer is going to be a vastly different user experience. I hate the fanboyism around macintoshes so, so much, though, that I probably will still never buy one on my own, but it seems you need to be comfortable with them to work in tech, at least in Portland. So here I am. A bit blech, a bit “oh this works really well.”

Lastly, I’m volunteering with a group called Chick Tech right now, which assigns mentors in industry to young women. It’s a very cool organization, and I can already see myself staying involved with them for a long time. I worry about this approach to solving one of tech’s many diversity problems, though – the problem, at this point, is not to interest young women in STEM, but to keep grown, adult women in tech once we are here. And here, we are, and I/we will demand equality. Jessica McKellar and Selena Deckelmann, a couple of fabulous tech luminaries whom I follow, both refer to the “leaky pipeline*,” – we can get them in, but we can’t keep them there. I think the following tweet from Jenny Thurman sums up the issue quite well.

So I will continue to think about this while I have a blast with my mentee, a motivated young lady whose trajectory I am excited to follow and encourage.

* the earliest reference I have found to this particular use of this term is from a paper from 1996, found here.

EOY Recap and 2014 Goals

I love end of year posts, like Scalzi’s and probably others whose blogs I do actually read but can’t think of, ha ha! This has been the year of transferring my nerdiness to generic pop-culture things like reading a ton of scifi and guzzling Star Trek, Doctor Who, Firefly, etc, to some real gritty stuff like some actual facility with computer systems. Very exciting.

I have made a zillion miles of progress and Big Life Decisions this year, and programming-wise, were and are incredibly impactful. My goal that I have been working toward for the last few years has been to teach high school math, I figure I have enough of an aptitude and teenagers are (don’t panic!) actually pretty cool to work with. And I knew I needed to be studying toward something that would get me an actual, adult, non-entry-level job, the contrast to which I worked in for four years, and let me tell you, hearing “well, we think you do deserve a raise, but there’s just no money” is pretty hard to hear/believe when you work for one of the biggest and most successful companies in the world, earning record profits quarter after quarter even in the most difficult of times (see 2009, when I saw coworkers’ 401(k)s slashed to 20-40% of what they had been).

Rant over, getting back to it, part of the coursework for the high school math teaching program at one of the graduate programs I was looking at included an introductory programming course. As I’ve mentioned elsewhere, this really struck me and I joined a ladies’ programming group and stuck with it. After hearing that one definition of a master is 10,000 hours of work put into it, I tried to come up with a figure of how much I’ve put into python and related projects, and I think I’m right around 250h, give or take. So I have a long way to go, but I’m very pleased with having allotted that much over the course of a year. It’s 250 more than I had by last year, and that’s the only metric that’s important right now!

And now, for your handy-dandy list-format of what I’ve started and accomplished this year, under the cut. Wahoo!

Continue reading

Lesson 24 and thoughts

Last week, I completed lesson 24, which was a “make sure you know how to do x, y, and z” exercise of no new material – a fine cap to the no-new-exercises triad of 22, 23, and 24. I am, to be honest, super bored by the idea of not doing new things while going through these lessons and have sped through these fairly quickly.

I am already planning what I’ll do next, after LPTHW. Probably pre-emptive, but there is so much out there and it’s hard not to speculate what I’ll want to do next. I like Zed Shaw’s style and might do the Learn Ruby The Hard Way module, but I might do Learn You A Haskell for Great Good! next because a) Haskell is apparently very sexy right now, and b) it’s probably a good idea to go through a different kind of tutorial than just The Hard Way. Though Ruby might be more career-helpful if I should ever want to make something of this (fairly long-invested at this point!) hobby, so we shall see.

Onward!

Lessons 22 and 23

Ok! These were sorta boring! 22 said “go back over everything and make sure you know it,” essentially, and because I am impatient, I went through all the previous lessons in around an hour, surprised at how much I have actually absorbed. Then I moved speed-quick over to the 23rd exercise, which says to look up code and see if you can understand it, so I did a bit of that, and now I am again quite anxious to get back to regular lessons. : )