Colm Doyle A Developer Relations professional in Dublin, Ireland.

Flexibility shouldn't mean always-on

A desk with various items on it, including two notebooks, a MacBook and a pair of AirPods. One of the notebooks has a to-do list and a planner.

As parts of the planet, but not all, start to see light at the end of the COVID tunnel, many companies have started to formalize their plans for post-COVID working conditions. Technology companies in particular are considering a “hybrid” or a “fully distributed” model, whereby you can choose to either come into a pre-agreed company office for 2/3 days per week and work from somewhere else for the balance, or work in a location of your choosing all of the time, usually in line with some requirements around tax laws and local corporate entities.

But there’s another consideration being discussed in addition to location, and that’s when you work. Companies are recognizing that punching a clock and working a strict 9-5 doesn’t work for many, especially people with family commitments, or people who just like to keep a different schedule for whatever reason. There are benefits to this approach, especially when it comes widening the pool of people you can recruit, hopefully leading to a more talented and diverse employee base. But as we embrace the positives of this, we must also be cognizant of the potential downsides, so we can build protections into this new normal.

In a world where you’re measured not by the hours you put in, but by your output, how do we avoid creating a situation where you end up working significantly more than before because of unreasonable output expectations, especially across cultures and timezones.

The pitfalls of unlimited flexibility

The clearest cautionary tale in this regard is “unlimited” paid time off (PTO). On the face of it, unlimited PTO could be considered an extremely employee-friendly policy. No more counting your days, no more stressing about whether you’ll have enough left over if your kids are sick or whether you’ll have to work over the end of year holidays.

But time and time again, unlimited PTO has led to people taking less time off. People move from a model of earning time off that belongs to them and they spend as they see fit, to time off being in the gift of their line manager, and suddenly every PTO request feels like an imposition you’re placing on your team. Some teams that embraced unlimited PTO in the past have even moved to “minimum vacation” policies to counter this effect.

Now imagine that atmosphere of imposition, but applied to when you close your laptop for the last time in a given day. You can easily picture people feeling pressured to crank out one more thing because their team has unreasonable expectations, whereas before, knowing that it was around 5:30pm would have drawn a natural line under the working day and given you explicit permission to step away from your keyboard. Ask yourself, what cultural norms should you and your team establish to recreate that “time to log-off” mentality?

Your time, your ideas?

As I write this post, I wouldn’t consider myself “at work”, but I also know that I didn’t punch a time card and sit down at my desk this morning at 9am, because Slack isn’t overly concerned with the hours I keep. But who owns these words? Do I? Does Slack?

Intellectual Property clauses are a common feature of many tech company contracts and the traditional way to establish ownership boundaries over this sort of output. Frequently they suggest that anything you create using company hardware or on company time is the property of the company. Simple enough you’d think. But consider this - I’m writing these words on my personally purchased iOS device, using software I funded myself, and will upload them to my personal GitHub. That certainly seems to make them mine. But, content creation is part of my job. It’s what I’m paid to do, so arguably Slack could claim ownership under my current employment contract. And since Slack doesn’t demand I work set hours, who’s to say what’s company time and what’s my time?

Realistically I don’t think Slack’s legal team will worry about the ownership of this content, but someone somewhere is writing the next Google. Assuming that person is employed right now, I’d imagine that their employer would be very interested in that IP. For all concerned, this is another example of how agreements will need to evolve.

Use your mobility to shape your company’s approach

Those of us in the technology sector, particularly Product Managers, Designers and Engineers, have never had so many choices of where to work. There are few other industries where it is truly a job seeker’s market. And that means that employers, at least the good ones, are hyper-conscious of the challenge of retaining talented staff and will do what it takes to hold on to people. That’s a privilege that you should use to your advantage when it comes to influencing how your company will approach these decisions. As I said in Building for the new normal, the time to consider this is now.

Decisions […] need to be made before the industry starts to fall back on what worked in the past, even if it’s no longer fit for purpose.

Companies everywhere are currently discussing what work will look like in the future, and many are circling the model where the hours you put in are less important. I think this approach can provide many benefits, but we should all be careful that we don’t sleepwalk into a situation where in the name of flexibility, we end up ceding some protections - like the ability to own our ideas or to turn off our work devices - because as tempting as clearing a red notification bubble can be, that Slack message can probably wait for tomorrow.

Et tu, booth?

Attendees at a conference

If the move to virtual events over the last year has done anything, it has laid bare the fact that sponsored conference booths, both physical and virtual, are a waste for everyone involved. Don’t get me wrong, for in-person events, I actually enjoy staffing a booth. But I think the return on investment, particularly when you’re serving a developer community just isn’t there to justify the cost. Maybe, just maybe, it’s time to start thinking about how we can better spend that money.

So let’s talk about the real stakeholders when it comes to booths and how they’re involved in this mini-economy of sponsorship packages:

The sponsors

For the sponsors, a booth is an opportunity to aggressively market their wares to attendees, like the conference equivalent of a silk route bazaar, usually generating leads for sales teams to build on. The traditional measure of these leads is “badge scanning”, where sponsors are issued with scanners that are then used to read your conference badge, giving them access to the details you provided to the organiser when you registered. Badge scanning is a really easy way to measure the return on your sponsorship dollars, but it’s not a particularly targeted way to interact with your community, and in a GDPR world, god only knows if it’s being done in a legally sound way.

That’s not to say that some companies don’t do booths well, but they’re the outliers from what I’ve seen at events.

Mark Zuckerberg answering questions at a Town Hall
Web Summit, CC BY 2.0, via Wikimedia Commons

And there’s such variance in the booth experience. You have tiny startups sinking a relatively large percentage of their budget just to get a postage stamp of pre-built space, all the way to large scale companies who will (sometimes literally) build a bespoke small village of booths.

But for the most part, regardless of the size, a company will sponsor a booth to do one thing - get your contact details to sell you something now or in the future.

The organisers

For organisers, booths are basically a way to pay the bills, which we’ll give them the benefit of the doubt and say they’re using that income to lower the cost of entry, enabling a more diverse set of attendees, and that’s reasonable. Some percentage though are just using it to maximise profits. But I seriously doubt any conference organiser proactively wants booths. They’re a means to an end, a way to pay for all the stuff they actually want at the event.

I think the only exception here is when the booth is run by the organiser. If you’re going to the likes of F8, WWDC or Dreamforce, then having booths run by the various different product teams makes sense, because really the whole event is a marketing effort, and the reason you’re attending is probably exactly to meet with the people at that company. Outside of that specific use case though, I think the above holds true.

The attendees

That just leaves us with the final stakeholder, the attendees. These are people who the event is supposedly for, but as in this article, are usually the last folks on the list when thinking about the value of the booth. Have you ever met who bought a ticket to an event thinking - “I cannot wait to have an opportunity to share my contact details with companies who want to sell me things”? I certainly haven’t. Networking, sure, but signing up to be called by a Sales Development Rep? If you believe they do, can I scan your badge, cause I’ve got a bridge to sell you.

For attendees, the “expo area” - which is a fancy name for the booth village sponsors have built, is a place to go to kill time. It’s nearly impossible for organisers to put together a schedule of content where you’ll be engaged the whole time, so there are points in your day where you’ll have some free time. During that free time, most people will grab a coffee and head to the booth area to wander around.

And this is where we get back to virtual events and the role they’ve played in bringing down the booth ecosystem. If you’re sitting at your desk, or your couch, or wherever you’re working from that day, when you have downtime in between the content (usually the primary reason someone attends an event), would you rather go to a “virtual booth”, or would you, I dunno, do something productive like make some food or catch up on work.

The environmental impact of all this

And none of this even takes into account the environmental costs of booths. There’s the impact of flying in the staff, the materials used to build the booth, the materials to produce the leaflets, the swag, the shipping of all that to the venue, the time it takes to produce all those things and more. And for a lot of organisations, these materials are considered single-use, even the very booth itself.

On the Developer Relations team at Slack, before the pandemic put a halt to in-person events, we made the decision to cut down on per-event custom booths, focusing instead of something we could re-use. We also decided that when we gave out swag, we could give items that were extremely low impact, or at least somewhat useful. Nobody needs another company branded 50c pen in their life.

With in-person events starting to be planned, I think we’ll definitely see some large budget events, especially the self-organised types like Dreamforce or Google I/O, but society continues to quite rightly frown upon organisations who ignore their environmental responsibilities, so I don’t see my team’s approach changing here. If anything I suspect we’ll be more aggressive.

Be an authentic community member

If you’re trying to be authentically part of a community, you need to ask yourself what value are you bringing by having a booth at an event?

Maybe you’re doing it to give your community an opportunity to come ask you questions, and certainly once COVID restrictions begin to ease and it’s safe to do so, there is value in having real life face to face time with your community, but if spending money on a conference ticket in the hope that the right person is staffing a booth is the only way your community can reach you, then you might have much bigger problems with your outreach strategy.

If you really want to help the community, maybe the better approach is to work with a local community organiser to use what you would have spent on booths to fund their regular meet-up, the one that will continue long after the conference venue has been converted to whatever the next show in town is.

When you struggle to write

A cropped image of a mechanical typewriter

It’s staring at you, making you feel stupid. It’s an empty page, or a blinking cursor in a document of zero kb.

You want to write something. The will is there, but the idea just won’t come. You look back through your previous ideas, you voraciously consume content. Podcasts, other writers posts, your favorite websites. You seek out inspiration like a dry sponge, you wish for liquid. But it’s not coming and you’ve promised yourself you would write more, and you want to stick to your schedule. So what can you do to get going?

Tend to your ideas like a garden

I’ve said before that when I have an idea for a piece of content, as soon as I can, I write it down. Writing it down can mean many things. Sometimes it’s a paragraph or two, sometimes it’s some bullet points, but more often than not, it’s a single sentence.

I think of this like planting seeds in a garden. Some will grow almost instantly and be ready for publishing that week. Others may take weeks or months to bloom. It’s that garden of ideas that I visit whenever I’m stuck. If you don’t already, start tending to your own garden of ideas, and hopefully you’ll always have some content ready to harvest.

To produce, you should consume

If you’re in the business of creating content, you should also be consuming as much content as you can too. This isn’t a case of “good writers borrow, great writers steal”, but more that reading the work of others will help you form an opinion on topics that interest you, and from those opinions you’ll be able to write content that appeals to you and hopefully others.

I often say that when you can’t get a designer to help you build a visual asset, just do it yourself, because they’ll either be ok with what you’ve made, or be so horrified that they give you a better asset. Either way, you have the asset. Consuming other people’s content is kind of the same. You either find an topic you agree with and want to expand on, or you feel so strongly that you want to counter their opinion.

Give old content a new home

Martin Beeby from the AWS DevRel team has it absolutely right when he talks about assets and activities. In most Developer Relations work, creating new content doesn’t always mean writing a blog post. You speak on podcasts, you record videos or talk at events.

Sometimes the best way to getting out of a rut writing-wise is to take something that’s already been fully formed and look at ways to repurpose it. So try taking a blog post and turn it into your next talk. Or rewrite it into a script for a podcast episode.

When all else fails, just write about it

I was once involved in a conversation about the point of internal company hackathons, and a point raised by someone there really stuck with me. He said that we all have ideas we want to pursue that aren’t on the roadmap, or funded. They’re the kind of idea that if you just get started, you’ll be able to rapidly prototype it and make your case. But it’s finding the time to get the ball rolling that always blocked you, and that was were the hackathon came in. It gave you the space to get started.

Unlike regular hackathons, I reckon that writing about your inability to write something is probably a chip you can only cash in once, but when you do, you might find that everything else clicks back into place and you’ll have your 1% written. Now to just write the other 99%.

Building for the new normal

A shot of a video conference with a woman who can be seen smiling on screen. A man is sitting in front of the computer.

As the world starts to look toward a post COVID work environment, the commonly accepted wisdom seems to be that a Monday to Friday 9-5 routine in a central office is no longer the default expectation for knowledge workers.

Instead, particularly in the technology sector, a lot of companies are moving to either a fully distributed workforce, or a hybrid one where you spend only a small percentage of your time co-located with your team. And whilst most of the focus has been on what that means in terms of physical real estate and employee compensation, I think the interesting long term changes will be in the digital tooling that we all rely on day to day. A lot of these product and organisational trends have been bubbling under the surface for some time now, but over the last few months and in the coming years, those trends have started to accelerate, bringing about a new way of working that some believe were inevitable. In the past year, developers rushed to adapt tools to a fully distributed environment, but the challenge presented by the next twelve months and beyond is how to make those tools work in the hybrid environment many of us will inhabit.

So in a world where someone new to the organization can no longer learn how it works by sitting next to their teammates and tapping them on the shoulder, how should your existing tooling adapt and what new approaches to tooling does this new style of working enable?

Learning through discovery

The traditional model of your teammates explaining how a tool works, showing you how a tool works, and finally letting you try those tools for yourself will, I believe, fail to deliver.

Tools for this new future of work will need to focus not just on the initial onboarding experience, but will also need to work with existing collaboration tools like Slack, Teams and even email, to make usage of the tool visible in ways that allow people to learn the particular quirks of how their team uses it.

Let’s take code review for example. Imagine you’re a new engineer, and you’re in a project channel in your company’s Slack workspace or a Workplace by Facebook Group. It’s day one and you can see Pull Request notifications from the GitHub app, so you now know that your team prefers to do their code reviews there. Importantly, you didn’t have to already be subscribed to GitHub email notifications, because modern collaboration tools shouldn’t rely on outdated patterns like the information silos that are email inboxes.

When you click into the review, GitHub is already showing you what the CI/CD pipeline looks like because the list of checks are surfaced right beside the merge button. Some tools even post information like coverage reports directly into the pull request. And because Pull Requests are all about collaboration, you can get a sense for what matters to your team when code is being reviewed, because you’re doing it all together inside the GitHub UI.

You’re being guided through the whole process, from the pull request being surfaced in a group setting like a channel, all the way through to providing you with a list of CI tools that you’ll need to familiarise yourself with. It’s this kind of collaborative behaviour that needs to exist in all tooling.

Collaborative by design

I don’t know about you, but I’ve lost count of the number of times over the last twelve months that I wished I could just round up my team, jump into a meeting room with an actual whiteboard and some post-it notes to just figure something out.

Whilst Google Docs in particular has been held up as an example of best-in-class collaborative document editing, I’ve yet to see the experience of being “in the room” replicated well in a digital tool. It’s entirely possible this is just a function of my own personal working style, but I’ve had enough folks express similar thoughts to me that I know I’m definitely not alone or even in a small minority.

The tools that are needed for the next 5 years and beyond will have to weave online and asynchronous (or indeed synchronous) collaboration into the very fabric of their product, not as a mere feature or add-on.

The Room Where It Happens

Early in the second act of Hamilton, Aaron Burr laments the fact that he wasn’t in “the room where it happened”. As someone who has spent the bulk of his career working from Ireland, but with the majority of my teammates in a California HQ, I can definitely sympathize with how Burr felt.

How many times have you been the only person dialling into a meeting room full of people, and felt like you’re observing the meeting instead of participating in it? In one way, forcing everyone to work from home has been a great leveller in this regard because when everyone is on zoom, no one group dominates conversation. In the whiteboard scenario I mentioned, when you involve video conferencing, I think you have two equally awful choices - Either point the (inevitably poor resolution) camera at the whiteboard and hope the folks on the zoom can make it out, but then have no way to contribute, or you use some kind of online mind mapping software where everyone in the physical room has sit in front of their laptops and the folks on zoom have to choose between looking at the screen or seeing their colleagues. Google Jamboard feels like a step in the right direction, but not every company can afford to kit out a room with a full video conferencing setup and spend $5,000 on a fancy whiteboard.

Some changes that need to happen, for meetings in particular, will be larger, like the whiteboard collaboration use case, but others will be smaller affordances that make life easier for the people running the meeting. Today for example, when you get a meeting invite, your options are Yes, No, or maybe. Perhaps in the future, when you answer yes, Google Calendar would ask you if you’ll be attending in person or over Zoom/Hangouts. Then the system can ensure you’re assigned a meeting room that (a) is the correct size and (b) has the facilities you’ll need in terms of cameras / whiteboards and more.

Whatever the solution, the experience of dialling into a meeting will need to be re-imagined or the people who choose to work outside one of the company’s hubs will once again be relegated to the role of observers. And in this hybrid world, regardless of where we choose to work from, we all deserve to be in the room where it happens.

Seamless security

If you can’t rely on traditional security approaches like a strictly controlled office network, how do you secure tools? People will inevitably follow the path of least resistance, so the key as always with security is balancing the most secure route with the most convenient route, especially when you talk about data leaving an organization.

As an example of following the path of least resistance, you would be astonished at the number of people who conduct business over consumer messaging apps like WhatsApp or Signal. It honestly boggles my mind until you consider that the alternative for most people is email, which despite being the defacto standard for decades, is, well, not very good.

It lacks all sorts of features that people have come to expect from messaging, like the ability to leave or join a conversation, or inline attachments that actually work well, and just the societal expectation of a formal style of communicating when emailing.

So given that alternative, people chose what they were comfortable with. The path of least resistance. But the likes of WhatsApp or iMessage are, by their very design, consumer messaging tools. They lack features that are table stakes for corporate messaging, like e-discovery features to comply with legal requests, data loss prevention systems, audit trails and more. It was this gap that Slack leveraged when they launched Slack Connect.

Connect took the consumer level features that the every day user enjoys, with the enterprise protections that a company needs to protect themselves. And because sending a DM or creating a multi-company channel in Slack Connect only requires the other party’s email addresses, it’s pretty easy to create the connection, so there’s no real need to lean on your consumer messaging app of choice. Which is a good thing, because whatever about the company’s legal obligations, if you’re going to maintain a good work/life balance, it’s probably better not to mix how you talk to your friends and how you talk to your customers.

Flexible schedules, not 24/7 ones

When I talk about an entire class of products weaving something into their fabric, the most recent product shifts that come to mind are closely connected to each other - the adoption of “social” features such as algorithmic ranking, and the shift to a “mobile first” mindset. Both of these were transformative in the software industry, came within a few years of each other, and many would argue, haven’t been 100% positive.

The tendency in both these shifts was to chase engagement metrics at all costs, which led people to craft addictive experiences where success was based on how long you kept people in your product without considering if that cumulative time was a net positive for your user’s physical or mental health.

In the current shift, especially for the work based tooling I’m talking about, we have an opportunity to learn from these mistakes and create experiences that add value, but are respectful of the work/life balance of our users.

This isn’t about your product dictating work schedules to people, but instead creating new incentives that don’t encourage constantly checking in with colleagues. What you’re looking for is ways to give users control about how they guard their time, and from a cultural perspective, encouraging the use of those guardrails. You want to offer this flexibility, because in all likelihood, the schedules of your team can vary wildly, and employees will start to expect their work schedule to be flexible. As examples of tools that are already started to weave this into their design, you could look at Slack and Google Calendar.

Slack encourages users to tell it when they want to be available and when to leave them alone through custom “Do not disturb” schedules. Similarly, Google Calendar recently rolled out the ability to more granularly control your availability for meetings, as well as setting repeatable periods of “out of office” time, where they would automatically decline meeting invites without you having to be notified.

The digital water cooler

Perhaps one of the most controversial side effects of moving to primarily digital communication is the extent to which some companies want to, and can, decide what employees can discuss at work.

Obviously the notion of company policies around acceptable behaviour at work have been around for some time, but it’s the extent to which a primarily digital environment allows employers to actually monitor and enforce these policies that’s different now. It’s a lot harder to see what goes on “around the water cooler” vs in your company tools.

With all of our workplace communication flowing through those tools, the line between casual conversations with colleagues and what you’d expect to appear in a court document is blurring further and further.

Features that enhance user safety, or legally important things like e-discovery are usually less controversial, but the extent to which your tooling is perceived as enabling the suppression of speech in the workplace is a harder line to toe.

The time to consider these problems is already here

We’re now over a year into this forced global work-from-home experiment. What was previously a fluid pandemic mandated experience will soon become like poured concrete, setting quickly and hard to change after the fact. Decisions about the kind of tooling we want to create need to be made before the industry starts to fall back on what worked in the past, even if it’s no longer fit for purpose.

As the people who are ultimately building these tools for the future of work, it’s our collective responsibility to be sure that the products we design help to create the best possible environments for everyone. We owe it to ourselves not to dodge that responsibility.

Introducing Klokta

Klokta artwork - picture of a laptop and a notebook, heavily blurred, with the word Klokta overlaid

I’ve always had a bit of an on and off relationship with podcasts. They’re the classic “commute to work” medium and you can see why, especially in the days of the iPod. Load up your device in the morning while you have breakfast, then stick in your headphones and catch up on whatever takes your fancy.

They never really worked out that way for me, despite spending at least ninety minutes a day on trams and buses before COVID-19 forced most folks in the tech sector and office workers generally into a mass work-from-home experiment. To be sure I tried, but the issue was always one of distraction. I’d fire up the next podcast in my queue and start listening, but then I’d also fire up twitter/facebook/instagram/slack, and start consuming there too. Before I knew it, twenty minutes had passed and if you’d offered me a million euro, I wouldn’t be able to answer any questions on what I had just listened to.

That all changed with COVID-19. My “commute” now consists of walking from my bedroom to the room I use as a home office. But I did start to walk more. And then Dithering came along. A podcast that last 15 minutes was pretty much a perfect match for my attention span. It became a regular feature of my week and since then, I’ve started listening to all sorts of podcasts, even ones as long as The Talk Show with John Gruber.

Given my history with podcasts, it’s pretty reasonable to argue that I’m not the best person to start publishing one, but a few weeks ago, I wrote about how creating more content was an important practice for those of us who work in Developer Relations. As I alluded to in that article, resurrecting this blog was part of my own routine for creating more content. So despite having only really gotten into them in the last 12 months, I’ve decided to start publishing a podcast, which I’m calling Klokta.

What’s in a name?

Settling on Klokta as a name was a bit of a random process. I started looking for a podcast hosting service, and after looking at a few, I settled on using Anchor, which is the podcasting platform owned by Spotify. I’d heard it mentioned (but not exactly recommended) on Dithering, so I knew Spotify had some tooling in this area, and it’s been an area of investment for them of late, so I figured it’s a pretty safe bet.

Part of the signup process there is picking a name for your podcast. I punched in “Colm Doyle” and went through the rest of the setup, but the more I thought about it, the more I felt odd about sticking my name on it. It’s not like I’m some celebrity where my literal name has any brand value. Could you really hear someone saying “oh you should check out this podcast called ‘Colm Doyle’”? No, me either.

I let it rattle around my brain a bit, trying to figure out something that sounded right, before falling back on how I usually pick names for side projects. I picked a word that best described what the project was about….and then looked that word up in Irish. I’ve found this approach usually guarantees a certain amount of uniqueness, particularly in the field of technology.

So, cleachtadh is the Irish for practice, because I’m practicing content creation. But phonetically I couldn’t imagine a native english speaker getting that, so I took the lazy approach and recorded myself saying it, then asked my colleagues at Slack to spell it and so I settled on Klokta.

What will you be talking about?

Well honestly, at the start, I’ll likely be doing audio versions of the blog posts that I publish here, similar to how Ben Thompson records the Stratechery newsletter as a podcast. On a side note, if you don’t subscribe to Stratechery, you absolutely should, it’s a fantastic source of information around what’s happening in the world of technology and business. That and Dithering, they’re both superb and well worth the money if you can afford it. If your company offers any kind of professional development fund, you could possibly have it covered by that.

As I get into more of a routine, I’ll hopefully branch out the content, interviewing people who I find professionally interesting, so likely folks in the field of DevRel and technology more generally.

I don’t know how it’s going to go, but I know I’ll learn something, and I plan to share those learnings both here and on Klokta, so I hope you’ll join me by subscribing wherever you listen to your podcasts.

For those of you curious, here’s the technology that I’ll be using in relation to Klokta. Some of this overlaps with how I produce the blog, and where it does, I’ll highlight that.

  • Microphone: Like many others, I’ll be using the Yeti by Blue. Specifically I use the Yeticaster bundle, as I prefer to mount things to keep them off my desk as much as possible.
  • Audio software: For now, I’ll be keeping it pretty basic, either recording using QuickTime Player, or directly to Anchor.
  • Hosting podcasts: As I mentioned, I looked around and settled on Anchor to host the actual podcasts. I considered uploading them to S3 and rolling my own RSS feed for players to subscribe to, but honestly that sounded like a lot of effort, and whilst I don’t need a massive amount of metrics, I was curious to at least have a sense of whether anyone was listening, which more or less forced me into something off the shelf. Anchor pretty much works out of the box, doesn’t actually cost anything, and provides basic metrics, specifically play counts and an estimate on the number of people listening. If people choose to listen using Spotify, I’ll also get a rough idea of how long they’re listening for.
  • Cover Art: For the cover art, I didn’t want anything fancy or well designed, so I just stuck a stock photo with a permissive license into Procreate, added a text overlay, and that’s it. I also tend to use procreate for the images used on this site.
  • Landing Page: Anchor provides a landing page out of the box, but I decided I wanted to have something I could control better, so I’ve added a page on this site to serve that purpose. This whole site is Gatsby, so it was just a matter of adding a markdown file and a link on the side navigation. I tend to write drafts of pages (and posts like this) in iA Writer on my iPad Pro, before copying them over to Working Copy to commit and push to GitHub, where actions take over and deploy the site.