Today I wanted to write a script that I could execute from both *nix (using Bash or a similar shell) and on Windows (from a command prompt, i.e. a batch file). I found Max Norin’s solution which works, but has a few limitations, e.g. when run it outputs either the
word “off” when run in *nix or the word “goto” when run on Windows. There’s got to be a sneaky solution, right?
Here’s my improved version:
# Linux code here
@echooffrem Windows script hereecho%OS%
Mine exploits the fact that batch files can prefix commands with @ to suppress outputting them as they execute. So @goto can be a valid function name in
bash/zsh etc. but is interpreted as a literal goto command in a Windows Command Prompt. This allows me to move the echo off command –
which only has meaning to Windows – into the Windows section of the script and suppress it with @.
The file above can be saved as e.g. myfile.cmd and will execute in a Windows Command Prompt (or in MS-DOS) or your favourite *nix OS. Works in MacOS/BSD too, although
obviously any more-sophisticated script is going to have to start working around the differences between GNU and non-GNU versions of core utilities, which is always a bit of a pain!
Won’t work in sh because you can’t define functions like that.
But the short of it is you can run this on a stock *nix OS and get:
And you can run it on Windows and get:
You can’t put a shebang at the top because Windows hates it, but there might be a solution using PowerShell scripts (which use
hashes for comments: that’s worth thinking about!). In any case: if the interpreter strictly matters you’ll probably want to shell to it on line 3 with e.g. bash -c.
Why would you want such a thing? I’m not sure. But there is is, if you do.
My first post covered the first 128 days: starting from the day I decided (after 15 years of
watching-from-afar) that I should apply to work there through to 51 days before my start date. It described my recruitment process, which is famously comprehensive and intensive. For me
this alone was hugely broadening! My first post spanned the period up until I started getting access to Automattic’s internal systems, a month and a half before my start date. If you’re
interested in my experience of recruitment at Automattic, you should go and read that post. This post, though, focusses on my induction,
onboarding, and work during my first two months.
With a month to go before I started, I thought it time to start setting up my new “office” for my teleworking. Automattic offered to buy me a new desk and chair, but I’m not ready to
take them up on that yet: but I’m waiting until after my (hopefully-)upcoming house move so I know how much space I’ve got to work with/what I need! There’s still plenty for a new
developer to do, though: plugging in and testing my new laptop, monitor, and accessories, and doing all of the opinionated tweaks that make one’s digital environment one’s own –
preferred text editor, browser, plugins, shell, tab width, mouse sensitivity, cursor blink rate… important stuff like that.
For me, this was the cause of the first of many learning experiences, because nowadays I’m working on a MacBook! Automattic doesn’t
require you to use a Mac, but a large proportion of the company does and I figured that learning to use a Mac effectively would be easier than learning my new codebase on a
different architecture than most of my colleagues.
I’ve owned a couple of Intel Macs (and a couple of Hackintoshes) but I’ve never gotten on with them well enough to warrant
becoming an advanced user, until now. I’ll probably write in the future about my experience of making serious use of a Mac after a history of mostly *nix and Windows machines.
Automattic also encouraged me to kit myself up with a stack of freebies to show off my affiliation, so I’ve got a wardrobe-load of new t-shirts and stickers too. It’s hard to argue that
we’re a company and not a cult when we’re all dressed alike, and that’s not even mentioning a colleague of mine with two WordPress-related tattoos, but there we have it.
Role and Company
I should take a moment to say what I do. The very simple version, which I came up with to very briefly describe my new job to JTA‘s mother, is: I write software that powers an online shop that sells software that powers online shops.
You want the long version? I’m a Code Magician (you may say it’s a silly job title,
I say it’s beautiful… but I don’t necessarily disagree that it’s silly too) with Team Alpha at Automattic. We’re the engineering team behind WooCommerce.com, which provides downloads of the Web’s most-popular eCommerce platform… plus hundreds of
free and premium extensions.
There’s a lot of stuff I’d love to tell you about my role and my new employer, but there’s enough to say here about my induction so I’ll be saving following topics for a future
Chaos: how Automattic produces order out of entropy, seemingly against all odds,
Transparency and communication: what it’s like to work in an environment of radical communication and a focus on transparency,
People and culture: my co-workers, our distributed team, and what is lost by not being able to “meet around the coffee machine” (and how we work to artificially
recreate that kind of experience),
Distributed working: this is my second foray into a nearly-100% remote-working environment; how’s it different to before?
To be continued, then.
Onboarding (days 1 through 12)
I wasn’t sure how my onboarding at Automattic could compare to that which I got when I started at the Bodleian. There, my then-line manager Alison‘s obsession with preparation had me arrive to a
thoroughly-planned breakdown of everything I needed to know and everybody I needed to meet over the course of my first few weeks. That’s not necessarily a bad thing, but it
leaves little breathing room in an already intense period!
By comparison, my induction at Automattic was far more self-guided: each day in my first fortnight saw me tackling an agenda of things to work on and – in a pleasing touch I’ve seen
nowhere else – a list of expectations resulting from that day. Defined expectations day-by-day are an especially good as a tool for gauging one’s progress and it’s a nice touch that
I’ll be adapting should I ever have to write another induction plan for a somebody else.
Skipping the usual induction topics of where the fire escapes and toilets are (it’s your house; you tell us!), how to dial an outside line (yeah, we don’t really do that here),
what to do to get a key to the bike shed and so on saves time, of course! But it also removes an avenue for more-casual interpersonal contact (“So how long’ve you been working here?”)
and ad-hoc learning (“So I use that login on this system, right?”). Automattic’s aware of this and has an entire culture about making information accessible, but it
takes additional work on the part of a new hire to proactively seek out the answers they need, when they need them: searching the relevant resources, or else finding out who to ask… and
being sure to check their timezone before expecting an immediate response.
Onboarding at Automattic is necessarily at least somewhat self-driven, and it’s clear in hindsight that the recruitment process is geared towards selection of individuals who can work
in this way because it’s an essential part of how we work in general. I appreciated the freedom to carve my own path as I learned the ropes, but it took me a little while to
get over my initial intimidation about pinging a stranger to ask for a video/voice chat to talk through something!
Meetup (days 14 through 21)
I’d tried to arrange my migration to Automattic to occur just before their 2019 Grand Meetup, when virtually the entire company gets together in one place for an infrequent but important gathering, but I couldn’t make it work and just barely missed it. Luckily, though, my team had
planned a smaller get-together in South Africa which coincided with my second/third week, so I jetted off to get some
facetime with my colleagues.
My colleague and fellow newbie Berislav‘s contract started a few hours after he landed in Cape Town, and it was helpful to my
journey to see how far I’d come over the last fortnight through his eyes! He was, after all, on the same adventure as me, only a couple of weeks behind, and it was reassuring
to see that I’d already learned so much as well as to be able to join in with helping him get up-to-speed, too.
By the time I left the meetup I’d learned as much again as I had in the two weeks prior about my new role and my place in the team. I’d also
learned that I’m pretty terrible at surfing, but luckily that’s not among the skills I have to master in order to become a valuable
developer to Automattic.
Happiness Rotation (days 23 through 35)
A quirk of Automattic – and indeed something that attracted me to them, philosophically – is that everybody spends two weeks early in their first year and a week in every subsequent
year working on the Happiness Team. Happiness at Automattic is what almost any other company would call “tech support”, because Automattic’s full of job titles and team names that are,
frankly, a bit silly flipping awesome. I like this “Happiness Rotation” as a concept because it keeps the entire company focussed on customer issues and the things that
really matter at the coal face. It also fosters a broader understanding of our products and how they’re used in the real world, which is particularly valuable to us developers who can
otherwise sometimes forget that the things we produce have to be usable by real people with real needs!
One of the things that made my Happiness Rotation the hardest was also one of the things that made it the most-rewarding: that I didn’t really know most of the products I was
supporting! This was a valuable experience because I was able to learn as-I-went-along, working alongside my (amazingly supportive and understanding) Happiness Team co-workers: the
people who do this stuff all the time. But simultaneously, it was immensely challenging! My background in WordPress in general, plenty of tech support practice at Three Rings, and even my experience of email support at Samaritans put me in a strong position in-general…
but I found that I could very-quickly find myself out of my depth when helping somebody with the nitty-gritty of a problem with a specific WooCommerce extension.
Portering and getting DRI (days 60 through 67)
I’ve also had the opportunity during my brief time so far with Automattic to take on a few extra responsibilities within my team. My team rotates weekly responsibility for what they
call the Porter role. The Porter is responsible for triaging pull requests and monitoring blocking issues and acting as a first point-of-call to stakeholders: you know, the
stuff that’s important for developer velocity but that few developers want to do all the time. Starting to find my feet in my team by now, I made it my mission during my first
shift as Porter to get my team to experiment with an approach for keeping momentum on long-running issues, with moderate success (as a proper continuous-integration shop, velocity is
important and measurable). It’s pleased me so far to feel like I’m part of a team where my opinion matters, even though I’m “the new guy”.
I also took on my first project as a Directly Responsible Individual, which is our fancy term for the person who makes sure the project runs to schedule, reports on progress etc.
Because Automattic more strongly than any other place I’ve ever worked subscribes to a dogfooding strategy, the
woocommerce.com online store for which I share responsibility runs on – you guessed it – WooCommerce! And so the first project for which I’m directly responsible is the upgrade of woocommerce.com to the latest version of
WooCommerce, which went into beta last month. Fingers crossed for a smooth deployment.
There’s so much I’d love to say about Automattic’s culture, approach to development, people, products, philosophy, and creed, but that’ll
have to wait for another time. For now, suffice to say that I’m enjoying this exciting and challenging new environment and I’m looking forward to reporting on them in another 128 days