AFP548 Site News November 7, 2022 at 6:55 pm

Couch to 50k (CPE’s)

I’m going to ping pong between a few topics here, so to give everyone guideposts, here are the three main topics I’d like to stay with you, dear reader:
1. With 50k people in the MacAdmins Slack, it’s fine if you don’t want to be a Client Platform Engineer, but ~be a lot cooler if you did~ it’s a better time than ever to become one
2. If current CPE’s aren’t doing explicit outreach to under-represented-in-tech groups and investing in the growth of the motivated people out there, our standing in our organizations (and the future of our speciality) is the lesser for it
3. To grow/find those people, I have used the same interview questions which can be reverse-engineered into a bunch of advice for those still feeling like they have skills to acquire before being able to call themselves a CPE

What’s in a name?
As a definition of what *Client Platform Engineering* is, we’d be the team that ‘manages the life cycle’ of workstation platforms. In the day-to-day it would be less helping end users in real time, have less interactions with locked-down ‘appliance’-style mobile devices, but it’s definitely about making sure computers get patches, secure configurations, and groups can be identified that an appropriate environment is maintained on applicable devices.

Is CPE For You?

Starting at the beginning, why am I intending to encourage the talent pool of CPE’s to increase, and saying it’s both a great time to be one and ok if you don’t want to do this work (forever)? Years ago the MacAdmin community would lose talent to Linux sysadminery/devops-y folk. Then being fluent in Continuous Integration/Continuous Development supporting the building of iOS apps became prolific. Around the same time securing Corp meant pulling the people who know how to patch and inspect configs on the fleet (we even have the highest count of CPUs) into Security-dedicated roles. Now there’s enough of a gap in tooling from the MDM perspective that vendors are recognizing you don’t get better without people from the trenches with problem space expertise. Opportunities abound! (And we can get compensated accordingly – it’s valuable work.)

Speaking for myself, I’ve enjoyed making this my career. But one of my favorite quotes from a manager I’ve heard in passing was ‘this isn’t going to be your last job, so I’m hoping we can help you improve in the way you want to evolve’. My personality means I’ve followed Mac blogs since it was hard to blog, I’m a lifer for this work. But as a devops mindset and its topics crept in to how MacAdmins can get their job done, we (should be able to have) increased who can do this job. Tech workers are kept afloat in seemingly all economic conditions and are finally getting salaries to show proper respect for the breadth of skill we display across various parts of the IT ‘stack’. Apple’s continuous churn, breaking and giving us QA tasks for the disruption they cause ~being courageous~ ‘innovating’ means we also have to continuously learn and stay on top of change, more than almost any other tech discipline (besides I guess JavaScript frameworks).

Be You, Too

I, for one, don’t need people who religiously follow the blogs or Apple’s mercurial shifts, but I do want folks who know how important gitops and code review and visualization of metrics are and yeah, also happen to be able to deliver operating system/workstation platform lifecycle management. If it’s a given this will not be your last job, I have no problem eventually losing teammmates to other departments and fields that use osquery or devtools scripting or containerized GitLab CI/CD or web-facing cloud service delivery, as long as we get the mutual benefit of our time together in enough of the core CPE disciplines.

At (several, failed) Dropbox interviews I detected I wasn’t respected because I hadn’t gone to university, same due to my lack of ‘real’ Computer Science bonafides when I interviewed at Google (although they were still super nice about it). Some employers train interviewers on bias and explicitly call out ensuring qualified candidates get the consideration they deserve. At most interviews I can still fake a ‘culture fit’ for pampered people havens because I’m male-identifying and cis and have worked in places with unconscionable practices, with really bad personalities that provided cover for my own toxicity. I want us all to realize we should grow people that aren’t like the archetypes we can be perceived as having benefitted from in our careers. When we do that, our service delivery will get feedback from the widest customer base possible because our members will be that much more approachable. Any drop off of interest from the already slim subset of people who care about our IT product hits our respect as peers in an engineering organization, and the dynamicity of our team can only be assisted by showing better representation of the customer population as a whole.

The MacAdmins Foundation recognizing the need for a mentorship program (see #maf-mentorship) is a great space to watch, and I hope we can all find resources at our current employers to get experience both being mentored and mentoring so that we can get REALLY GOOD at investment in people as a community. (And I guess therapy/diversity training to unlearn some of the toxic aspects of how we had previously thought it was acceptable to operate would be a Good Thing™.)

It’s Dangerous To Go Alone, Bring This

Now we come to what I hope is AS REMEMBERED as the preceding topics in this post, which is the things someone with my career ‘bent’ would like to see people choose as aspects they can work on if they feel their skill set doesn’t yet match what a CPE team member should be expected to have. And admittedly it’s an unreasonably broad range of skills, but at this point I have well-trodden, go-to topics I’d like to see a passing familiarity with, and links to preferred resources to consult can hopefully get folks started.

Not just any scripting language, python is what I need people to be relatively fluent in, and Google’s online python class was what really challenged me but also provided a great set of resources to come back to about ‘what was that super basic thing again’. Being able to tool around in the interpreter is way more cool than fish shell prompt bling IMO. All of us who live or die by shell scripting know you hit a line length or complexity where it’s the wrong tool for the job, and I certainly learned by copy-pasting and modifying others code, but you need to reason with and solve problems from scratch ‘on your own’ with a language that intends to give you one good-enough common-case way to navigate a complex control flow. As a community, we benefit from a truly immensely valuable turn of events from over 15 years ago: Greg Neagle wanted to learn python, worked with Google engineers to add features to Munki, and writes well-commented, as straightforward as possible code with compact functions and not so much sprawl in either number of library files nor line length. Listing all the functions in Reposado and tracing the logic control flow (for a PSU MacAdmins presentation) was one of the best things I did for my understanding of solving non-trivial problems (in reality just tangentially related to the MacAdmin space) in python.

You may find other training resources that stick with you (I also liked the Coursera python class and like the Google resource above, regularly frequent the pymotw reference series), and hopefully you come across approachable problems to take apart. And THEN you should definitely put your flag in the ground and share what you’ve come up with, open source has been a huge part of what CPE needs at any kind of scale. I think running a high-ish visibility project has helped Greg find peers in the community that solve problems in different ways, code review is a hard discipline to be immersed in and we all start somewhere – reporting issues and writing documentation is super helpful and valuable! Similar to how I benefitted from having to present on the topic of Reposado and my blogging about various things, being able to reason about a stance you’re taking in text is a hugely valuable skill. Greg wrote literal magazine articles on MacAdmin topics, and as the length of subscriptions in MacAdmins Slack’s blog-feed list and infrequency of articles to AFP548 may indicate… there’s always readers in this space looking for cogent content and ways to reason about the challenges this work presents.

Show ‘Em What You Got

Contribution to open source online has to get slid through the perilous slot of version control, so yet another side benefit of sharing code has been it proves you can slay the git dragon. (VS Code will never get me, but the war was long ago lost for mercurial, good riddance svn etc.) API wrangling and glue code will never stop being a well-worn topic, so if you’re in search of where to show prowess, python modules that handle web and ‘process’ (read = wrapping command line tools to automate things) interactions are what you’ll be seeing for most of your career. (Built-in standard library should be preferred, but if a problem-space-specific pip module is trustable-enough, investigate that and come up with your own qualification criteria!) If you can do some or most of that ‘glue’ in a language like ObjectiveC or Go or Swift that’s all to the better, but these days pseudocode python when designing solutions feels like a common-enough language for design and discussion.

From a similar web and platform perspective, I want to interview people who know how IP subnetting and DNS records work enough and the basic moving parts to troubleshoot connectivity – I have no clue why this is overlooked so often. Getting at log files is another live-or-die skill for some, for me just being able to process large volumes of text across various formats (json, xml, etc.) to do basic analysis was a fun task that helped in other problem spaces over the years.

If I can be opinionated and brief (ever), don’t learn Jenkins, learn GitLabCI/CD or GitHub Actions and understand convergence time periods and document warranty’d behavior and engage with the pitfalls in both the dependency stack and network links that connect your automation from start to finish. (Also internalize why you should strive to never curl -k, ffs.) Likewise, document your entire DEP deploy process, all the things from an out-of-the-box Mac to the warranty’d Standard Operating Environment. Automation is a contract, put your name at the top of the wiki/notion page and own that you are responsible for what you said your engineering delivers. (It’s ok if the world has shifted before the ink is dry: the time stamp on the page is as much versioning as you need to be held to – just at least do it once for yourself/future you.)

Get Through The Door

More opinions! One (pdf) page for a resume SHOULD BE enough – anyone will help you whittle things down and format it well enough if you ask them, and a LinkedIn or Google Sites page with your entire history can fill in the rest of the details if you want to be verbose. Phrase achievements during your time with your previous employers in quantifiable numbers things like budget and/or time and/or complexity, impact-wise. Include stuff you have working knowledge of at least maintaining, don’t list alphabet soup. Do check the recruiter boxes in a job post! I want you to get past the recruiter pulse check, you’ll save them time if you include tangible experience with the tools we’re asking for familiarity with. Go ahead and tell me you have PHP or ColdFusion or Novell eDirectory or VectorWorks ~or trapeze~ or whatever other things may be considered inapplicable/passé experience as long as you delivered real value with it! Recruiters may not care, but I’ll be intrigued that you met the business challenges where they needed to be solved; demonstrate-able, broad excellence in anything is a great indication you can be good at Just CPE Thangs™.

In recent years ‘service delivery’ (meaning hosting Crypt or an MDM or monitoring or inventory or CloudFunction/Lambda/glue-y stuffs or whatever other platforms end up not being solely SaaS nowadays) has meant ‘the cloud’, and for some that has also meant Terraform (or whatever platform-specific way of delivering your needed infra to your cloud is). My recent dalliances with compliance also brings us back to the fundamental need and unique problem space configuration management tools like Puppet, Chef, SaltStack and Ansible address. I cannot overstate the importance of approaching high-stakes infra or config delivery with that mindstate: you must get as much of your setup into repeatable code as possible, and at least understand the off-ramp one must take when the workflow around basic scripts ain’t gonna cut it anymore. You’ll definitely be leveling up past where I’m at when you can reason about where ‘data’ and/or config-specific boundaries ‘naturally’ lie and can be dealt with separately in Infra As Code and server-full (or, even cooler, serverless+metrics) config mgmt deployments.


Ok, pardon that may have been a bit of a firehose. I write like I talk, and I’m a recovering New Yorker. Hopefully the whole audience sees things in this they can get value from, and I’m glad to discuss things further in the comments or Slack or elsewhere online! (No I do not has a WoolyMammothdon.) Best of luck!

Allister Banks

Allister lives in Japan, has not read the Slack scroll back, and therefore has no idea what is going on.

More Posts - Website

Follow Me:

Leave a reply

You must be logged in to post a comment.