Sam Beckham

The Quiet Tax

Tue, 03 Feb 2026 00:00:00 GMT

There's a moment I keep paying for.

It's the end of a hard week, we're approaching a deadline and we're getting ready to ship. I can already see the bug. It's not a bug-bug, it's the kind that eats trust. A small truth that seemingly only I can see. This plan won't work. The alignment is off. The scope towers over what little capacity (and appetite) engineering have left. We're about to close the week on smiles and promises that will both break after the weekend.

I feel it itching in my gut. The tiny friction of a sentence I don't want to say and no one wants to hear. The sentence forms in my mind, "This isn't going to work.". It moves to my mouth, but I roll it up and swallow it back down. Maybe I'm wrong, maybe it will all be fine. Maybe it's better left unsaid. I leave the meeting having said nothing. I'll pay the quiet tax.

The quiet tax doesn't feel like much in the moment; but it compounds. It's the act of not speaking up, of not pushing back, of letting things slide. Those small moments left unsaid, which turn into larger moments, then turn into catastrophes. All because we didn't speak up and say the hard thing in the moment that mattered.

The hard thing is rarely clever, eloquent, or groundbreaking. It's dull, brief and obvious. It sounds like:

"We don't have the capacity."
"We're solving different problems."
"This doesn't align with our goals."

It's not a speech, it's a door. You open it and a draft of honesty fills the room. It's not about being right. What follows is either agreement or disagreement, but either way, it's discussion.

How to say the hard thing

There are some rules to follow when saying hard things. Saying them out loud is better, but saying them so they can be heard is best.

1. Use your inside voice

Stay calm, collected. You're pointing out a truth that others may not have noticed. You're not campaigning against injustice. Theatrics are often met with more theatrics and conversation breaks down. Keep it civil.

2. Get to the point

Say what you need to say, then shut up. Don't over explain, don't fluff it up, and avoid the temptation to slap it in a compliment sandwich. I prefer my bad news gluten-free.

3. Own your part

Say, "We" not, "You". "We are not aligned" lands much better than, "You are wrong". It reframes it as us against the problem, not us against each other. We're looking for healthy discourse, not blame.

4. Close the loop

You've said the hard thing, you shut up and listened, now close the loop. Don't leave the meeting until you are aligned. At worst, schedule a time where you'll get that alignment. If you leave it unresolved, you'll still have to pay the quiet tax.

5. Don't overthink it

Saying the hard thing the right way is preferred. Not saying the hard thing because you're trying too hard to think of the best way to say it, leaves it unsaid. Ronan Keating is wrong; you say it best when you say anything at all.

Psychological safety

There's a counter argument, and it sounds reasonable, Psychological safety. As if safety and honesty sit at opposing ends of a seesaw and saying the hard thing threatens this safety. This is backwards. Safety is not the absence of discourse, it's the presence of trust. Minor discomfort delivered honestly will be forgiven long before the pain of a hard truth left unsaid.

The hard thing is not hard because it's mean. It's hard because you have to be the first one to say it. To spend a little bit of your credibility so the team can buy clarity. That's leadership. Pay the quiet tax less. Say the hard thing sooner. Leave the room lighter, and clearer, than you found it. What's the hard thing you need to say today? How can you avoid paying the quiet tax?

To Me, By Me

Tue, 27 Jan 2026 00:00:00 GMT

Over dinner, my wife asked a simple question: “So what are you going to do about it?”

I was reminded of the to me/by me concept from, “the 15 commitments of conscious leadership”.

A to me response would be, “I can’t solve this problem because Steve isn’t doing their job properly”. The thing blocking what you want is in someone else’s control. You are a helpless victim of circumstance. The by me response would be, “I should help unblock Steve so that they no-longer block me". It’s the same scenario, but reframed so that the control is in our hands. Blaming Steve feels good in the moment, but gets us no closer to achieving our goals.

Note: There are two further frames in the model, Through me and As me, but I’m focusing on the first two as they’re the most accessible and actionable.

Let’s look at another example. Your team is slammed with work, burnout is creeping in and mistakes are being made. A to me leader might say, “The team are making mistakes, my manager hasn’t given me the headcount I need, and product have given us completely unrealistic deadlines!”. A natural response, but staying there keeps you stuck. It’s all someone else’s fault. It’s all happening to me.

To take control of the situation, we need to reframe these gripes as a by me action. “I’ve accepted too much scope on too short of a deadline with not enough people and now my team are burning out and making mistakes. This is exactly the same scenario, the difference is, we can do something about it. We can more clearly see our levers. We can push back on scope, we can extend the deadline, we can request more headcount.

Of course, we could have done all those things regardless of how we framed our response. Nothing about our situation has changed, but our mindset has. We can more easily see our path towards fixing it. We’re not waiting for someone else to bail us out or change, we’re affecting that change ourselves.

I haven’t been writing as much as I’d like because I’m a new parent and that takes up a lot of my time. For the past year, I was seeing this from a to me point of view. By changing this to a by me point of view (which I wrote about last month) I have been able to find the time to write again without sacrificing any of the time I spend with my family.

The next time you catch yourself complaining about something that’s happening to you, try to reframe it to a by-you statement and the path towards solving that problem may become clearer.

Say the hard things

Sat, 27 Dec 2025 00:00:00 GMT

The most career-defining moment of my life happened before my career even started.

In my first year at college, I studied chemistry, physics, maths, and graphic design. I wanted to be a scientist and design was an “easy” fourth subject. One day my chemistry teacher sat me down and asked, “Sam, why are you in this class?” I explained that I wanted a good job, and hoped to become a forensic scientist. Her response has stuck with me ever since. “But you don’t enjoy it and you’re not very good at it.”

At the time, I thought this was harsh, uncalled for, and downright rude. I was stunned, but she was right.

I didn’t enjoy it and, whilst I might get a passing grade, I wasn’t good enough to make a meaningful career from it. We continued talking and realised my passion was in graphic design. So I doubled down on that instead. I stopped pursuing chemistry and dove further into design, which took me into the digital art space, then a degree in interactive media design, and ultimately the tech industry where I still thrive today.

If not for the candor of my tutor that day, I’d likely be stuck in a role that didn’t quite fit. Never fully enjoying my job and never being all that good at it.

The moral here isn’t about following your dreams, it’s to be candid with your feedback and to pay attention when people are being candid with you. Great feedback can change your life. I keep this memory with me when I need to deliver tough feedback to my team members. It can be hard to hear this kind of feedback and even harder to deliver it but the most crucial feedback is often the most difficult to deliver.

So thank you, Fiona, for telling me what I needed to hear, changing my career, and teaching me the power of candor.

Finding Time

Fri, 19 Dec 2025 00:00:00 GMT

I don't have the time to do the things I want to do anymore.

At least, that's what I keep telling myself. I don't have time to go for a run. I don't have time to play my guitar. I don't have time to write. I don't have time.

Except, I do have time. I have time to open LinkedIn for the 15th time to look at the notifications that I didn't need notifying about. I have time to flick through YouTube shorts and scoff at the AI slop. I have time to tap and scroll and tap and scroll and… I have time.

New year's resolutions are cliché, but here's mine for 2025. Every time I habitually open my phone, instead of starting a brain-rot session, I'm going to write. Whatever comes to my mind. Some of it I'll edit and publish. Most of it I won't. Maybe I will with this one though. Maybe, I do have time.

One to One Meetings

Fri, 09 Jun 2023 00:00:00 GMT

One to ones are the single most important meetings a leader will have with their reports. Here's some tips (and a free one to one template)

No One to One Fits All

One to ones are your main tool for building relationships with your reports. Like all relationships no two are the same. Every relationship has different needs at different times. For that reason, there's no one-size-fits-all when it comes to one to ones. Every manager, and every report, will have different needs from their one to one. The secret to finding those needs is iteration.

It's not your meeting

This is their meeting, not yours.

Spend at least the first half of the meeting talking about whatever they want to talk about. This could be an issue they're facing, a discussion about their career, or what they got up to at the weekend. If you have something you need to talk with them about, that's fine. You'll have time in the second half of the meeting.

Remember, this is their meeting, not yours.

If they need to reschedule it for that week, let them. If the scheduled time doesn't work for them anymore, move it. Better yet, give them the ability to do it themselves and operate a tell-don't-ask policy. "Tell me you're moving the meeting, don't ask me if you can."

Because, this is their meeting, not yours.

Don't let it devolve into a status report. If they want to update you on where they're at and discuss potential blockers, that's fine. When a one to one turns into a weekly status report, this is usually because it's what they think you want to hear, not because it's what they want to talk about. Try to steer the conversations away from status updates if you can.

One to One template

Even though it is their meeting, and each meeting is different, starting with a good framework is key. Here's the template I use:

<a href="https://docs.google.com/document/d/11ieq3d_um05a_Gb_vTQOw5KknAW8jqmEmG_zEU6tjzA/edit?usp=drive_link" target="_blank" class="button button--full">📄 One to One Template</a>

You can download it in any format and update it to suit your needs. If you copy the doc to your drive, you get my my automated meeting agenda script included.

We split the agenda into two sections; sticky info above the break, and weekly agendas below. Let's break them down.

Right at the top is the title. It's nothing special, but the order of the names is deliberate. Their name first, then yours. This helps set the tone and further emphasize that (say it with me) this is their meeting, not yours.

Below that are some useful links. In this template, there's a link to the meeting room and a brag document. These will be different for every report. They can include important issues, promotion documents, training, or whatever you'll reference often. Remember to keep the important things within reach.

The table below that are the focus areas. They're set up to keep the three main areas of focus front-of-mind. They can be performance goals, but I'd recommend decoupling performance targets from these. I use them as areas we both need to focus on to help them with their career growth. Learning a new topic, preparing for a promotion, keeping an eye on work/life balance, etc. By keeping them at the top of the document, you're less likely to forget them. Check in with them regularly, and if there's ever a lull in communication, they're a great ice breaker.

Next up is action items. This is where I like to store any promises we made to each other during the meeting. It's great for ephemeral tasks that like outside the usual issue/ticketing system. At the start of the next meeting, take a quick look at these and make sure you're keeping your promises to each other. Keep each other accountable for this.

Below the line break is the bread-and-butter of one to ones, the agenda. Make sure to have next week's agenda ready to go. When a thought pops into your mind during the week, you can drop it into the agenda to discuss at the next meeting. You can do this at the end of each meeting, or you can automate it if you're using Google docs. New entries get added at the top so you have a record of all the past meetings for reference. Be sure to take notes as you go. This can be a tough habit to get into (and something I'm working on myself) but your future self will thank you for it.

Informal by default, formal when it matters

Try to keep it informal by default. By having a formal structure, you can have informal conversations and still get things done. Sometimes conversations need to get more serious, but if you make them informal by default you'll both get a lot more out of them. One to ones are your best tool for building relationships, so use them to do that.

What do you like to include in your one to one documents? Let me know on Twitter!

Experimenting with AI

Fri, 02 Jun 2023 00:00:00 GMT

The world has gone crazy for AI. AI discussions are dominating keynotes, product releases, and Twitter threads. But what does building with AI actually look like? I wanted to learn, so I started small and spent a day experimenting.

A simple AI experiment

I needed an experiment that was small enough to be shippable in a day, but large enough to challenge me. I decided to update the recommendation feature on this blog. The previous algorithm suggested the three latest articles. It did the job, but wasn't too smart. It was the perfect target for my AI experiments. It was simple to understand, but would a deeper understanding of AI to get it done.

Getting familiar with AI

I wanted to create a some POCs (proofs of concept) to help me learn. The first step was to get the OpenAI API running in my project. I kept it simple and asked it to, "tell me a joke". After following the getting started guide (and some configuration) I got it a response.

"Q: What did the fish say when it hit the wall?

A: Dam!"

–'text-davinci-003'

By doing this, I learned that requests are made of tokens. Each token is a snippet of text, usually the length of a word. There's a limit on the number of tokens you can send and receive in each API call. The longer the prompt, the less room for the response. If you set this limit too low, or make the prompt too big, you get incomplete responses.

Proving the Concept

By updating the prompt from, "Tell me a joke", I could turn it into something useful. I passed a list of article titles and asked for the three most related ones. After some finessing, I landed on the following prompt:

const prompt = `
  Given the title of an article is "${article_title}".
  Which three articles from the following array of article titles are the most related?
  
  ${JSON.stringify(article_titles)}.

  Return your answer in the following JSON format:
  { "recommendations": ["one", "two", "three"] }
`

I learned that writing prompts like BDD tests is quite effective. The AI was more likely to understand the question if I laid it out clearly.

To make the result parsable, it was crucial to provide a format. Asking it to, "return the answer in JSON" was not enough. I needed to provide an example response to get a more reliable result. More reliable, but not completely reliable.

Here's what I got when asking for related articles for "Increase You Focus With Pomodoro":

{
  "recommendations": [
    "increase your focus with pomodoro"
    "automate your meeting agendas",
    "find what makes you productive"
  ]
}

Though it was obvious in hindsight, the most related article was the article itself. This was easy to fix by filtering it out of the list before passing it up. The POC worked well, but there were a few problems I wanted to address:

1. It wasn't reliable

Since this was chat-based, the outcome wasn't reliable. It worked 80% of the time, but often gave a poor response. It had a habit of adding extra text around the JSON, making it harder to parse. Switching from the text-davinci-003 model to the more chat-focused gpt-3.5-turbo model helped, but didn't completely fix it. I would need to write a more robust response parser if I were to move this from POC to production-ready code.

2. The recommendations weren't great

The recommendations were okay, but they were a bit naive. Since I was only sending the titles of the articles, we weren't giving the AI much data to work with. For example: "Running a Conference" would recommend, "Running the JamStack on GitLab", instead of the more obvious, "Starting a Meetup". To get better results, I'd need to give the AI more data.

3. There were too many API calls

The OpenAI API isn't free. Up to this point I had only spent a few cents, but at scale this could get expensive. Running this for every article—and passing more data per article—would increase costs. I needed to reduce and cache these calls wherever possible.

Using OpenAI Embeddings

After a bit more research into the issues above, I discovered embeddings. Instead of writing a prompt for every article, I could send them all to the embedding endpoint. This would return a multi-dimensional graph with all the articles plotted on it. The closer the points are on the graph, the more related they are.

To understand how embeddings work, we need to simplify what they're doing.

Imagine all the articles plotted on a standard 2D chart. On each axis is a different topic. There's "leadership" on one and "engineering" on another. We can plot all the articles on this chart based on how much the content within them relates to each topic. When we look at this chart, we can see the ones that are closer together are more related to each other. The ones that are further apart, will have less in common.

Comparing two topics doesn't give us much. To get more accurate information, we can add a third axis. This one measures the relation to "productivity". Since the axis needs to be orthogonal to the other two, we need to jump into the third dimension to visualize it.

We can still get the distance between points, but now we're comparing across three dimensions. OpenAI uses thousands of dimensions to create embeddings, but the concept is the same. The closer two nodes are, the more related they are.

This approach solves all our issues. We get more accurate, reliable, recommendations with one API call. Because of this, we can afford to send more data to make the recommendations better. Since this is no-longer chat based, the response is a structured data format. The embedding data may be different if we ran it again, but the data structure would be the same.

Sending the right data to the AI

We can send more data to the API, but which data do we send? We could send the whole article, but we would soon hit the token limit. Luckily, ChatGPT is great at summarizing and categorizing text. We can use this to our advantage and ask it to generate tags for all our articles. By sending tags instead of the full article, we send less data but still get the point of the article across. Because I was only doing this once, I used the ChatGPT app. This came with the added benefit of using the more powerful GPT4 engine that isn't available to us on the API.

Here's the prompt I wrote:

Given the following markdown article, please suggest five tags formatted as yaml:

{ARTICLE_CONTENT}

Notice I'm using the BDD test style again. I didn't provide an example response, so the results weren't reliable. Since this was using the ChatGPT app though, it didn't matter too much. It had the context of the previous chat messages so I could refine the result. When it returned the results in the wrong format, I would ask it to, "reformat the response as yaml" and it fixed it up. I could also refine the suggestions by saying, "swap {TAG_NAME} for another suggestion".

Here were the suggestions for this article:

- AI experimentation
- recommendation feature
- OpenAI API
- embeddings
- article tagging

It took a while to generate all the tags, but it was a one-time operation. Once I had all the tags, I wrote a script that fetched all the articles and extracted their tags. I then sent an array of these to the embedding endpoint and got all the data back to run comparisons against later.

{
  input: [
    "Experimenting with AI: AI experimentation, recommendation feature, OpenAI API, embeddings, article tagging",
    "Increase your focus with pomodoro: Productivity, Time Management, Focus Technique, Pomodoro Technique, Distraction Management",
    "Running a Conference: conference, event organization, sponsorship, diversity fund, speaker payment",
    //… 
  ]
}

Cosine similarity formula

Our brains can't handle graphs in dimensions higher than the three we live in, but computers have no problem with it. Using the cosine similarity formula, we can get the distance between two points in any number of dimensions. Letting the compute-cosine-similarity npm package do the heavy-lifting, made computing similarity a breeze. To get the recommended articles, I loop through all the articles and calculate their similarity to the current article. Then I sort the array by similarity, remove the first result, and return the next three. This is all done against the dataset we generated previously, so it's really fast.

Takeaways

This approach solved all the issues with the first POC. It's much more reliable since we're dealing with deterministic data. There's only one API call that's made once every few weeks. Most importantly, the recommendations are much better. They're not perfect, but they're good enough.

// For "Running a Conference"
{
  "recommendations": [{
    "title": "Starting a Meetup",
    "path": "/wrote/starting-a-meetup/",
    "similarity": 0.8543
  },{
    "title": "All Meetings are Optional",
    "path": "/wrote/all-meetings-are-optional/",
    "similarity": 0.8363
  },{
    "title": "Automate Your Meeting Agendas",
    "path": "/wrote/automate-your-meeting-agendas/",
    "similarity": 0.7954
  }]
}

Recommendations are a nice feature, but the point of this was to learn more about AI. I'm an engineering manager so I don't need to be a guru, but I still need to know what I'm talking about. By going through a practical application of AI, I'm better prepared for conversations with my engineers as we dive in to AI at GitLab.

If I've made any incorrect assumptions, or could have done this better, reach out on Mastodon, or Twitter and tell me about it. I'm always happy to learn.

Chief of Staff: 28 Days Later

Mon, 29 Aug 2022 00:00:00 GMT

I'm a third of the way through my Acting Chief of Staff to the CTO rotation. Here's what I've learned so far.

My day-to-day includes all the tasks listed in the job description. But to describe this role as a set of tasks doesn't give it justice. When asking folks what a Chief of Staff does, I got the typical, "it depends". This is a very self-driven role and you need to work out how to be effective. It's been quite freeing, though I do miss my usual team. Three months is a long time to be away, and not much time to on-board.

Giving CREDIT to our values

GitLab's core set of values drive everything we do. They spell out, "CREDIT" and stand for; Collaboration, Results, Efficiency, Diversity, Iteration, and Transparency. We live these values at every level. They are not just words on a (virtual) wall.

Whilst I look to these values in my regular role, they are much more important at this level of the company. If leadership expect the rest of the company to live by these values, they need to champion them.

Collaboration

A key aspect of this role is helping others collaborate. When one department or team member needs something, help them find where to go to get it. All whilst remaining as async as possible. This could be tracking training participants, raising awareness of an initiative, or anything in-between.

One of the tools we have for this is the Engineering Week in Review. It's an internal newsletter/document that anyone in the company can read or contribute to. My role is to promote and curate it so the right people see the right messages at the right time.

Results

Results are right at the top of our values hierarchy. With this being more of a supporting role, measuring results can be tricky. The "acting" aspect of this role requires a bias for action. You've only got three months in this job so if you want something doing, you had better start soon and move quick.

An example of this is the Engineering off-site. It's towards the end of the quarter, but requires a lot of planning. Rather than wait until the last month to start, I started in week two. I started by blocking out the time on everyone's calendars and iterated from there. By starting small, I got the ball rolling and made future collaboration much easier.

Start early and worry about the details later.

Efficiency

This role only lasts three months, so you need to be as efficient as possible. Automation has helped. I've automated agendas, created issue templates, and helped set up tracking for some OKRs. If a computer can do it faster than a human, I'm going to try to automate it.

My 1:1 meetings with the VPs are incredibly efficient. They're busy folks and sync time with them is expensive. It pays to be as async as possible and come prepared to these meetings. I have reoccurring items, focus areas, and actionables as I do with every 1:1. I just lean on them more and make sure they're up-to date. If there's nothing to talk about, we skip the meeting. It's a little different to what I'm used to with 1:1s, but efficiency is key.

Diversity, Inclusion, and Belonging

Collaboration works best when everyone is included and feels like they belong. We want to make sure everyone knows that they can voice their thoughts and concerns to the CTO. Eric (our CTO) is fantastic at this, and I've seen many contrarian questions asked in his office hours. They're always met with understanding and reason, no matter the topic, or who's asking. I love this, and want to showcase this more to folks in the company. I helped with this by re-wording the CTO office hours description with an emphasis on collaboration and inclusion. If you're a GitLab employee reading this, come join us in the next office hours and share what's on your mind.

Iteration

I've written about iteration before but it goes doubly so in this role. If I spend too long thinking about what to do, my tenure will be over and I'll have done nothing.

Organizing the Engineering offsite is one of my tasks as Chief of Staff to the CTO. It reminds me of organizing a conference, or starting a meetup. Just with much less marketing, and a much shorter time-frame. The only way to eat this elephant is one bite at a time. We started by finding a time that worked for all the attendees and blocked it on their calendars. Then we moved to looking for a city to host it in. Later we'll look at venues, hotels, flights, and the agenda.

One. Bite. At. A. Time.

Transparency

When explaining this role to friends and family, they expected I would get access to, "secret company information". This is not the case. Since GitLab lives by its transparency value, there's no information I have now that I wouldn't have had in my previous role. I just have the time to dig into it and look at it.

I'm being as transparent as possible throughout this process. Not only with posts like this one, but with most aspects of the work. If you want to see what I'm working on and continue to follow my journey, take a look at the public GitLab project. If you want to ask me any questions about the role, check the links in the footer and get in touch. If you work at GitLab and you're interested in doing this role yourself, register for it, or come speak to me.

Acting Chief of Staff to the Chief Technology Officer

Mon, 01 Aug 2022 00:00:00 GMT

Today, I take on a new role. A role with an expiry date. A role that has me working with the highest levels of engineering leadership at GitLab. A role with far too many words in the title. From August 1st till November 1st, I'll be the Acting Chief of Staff to the CTO.

What is an Acting Chief of Staff to the CTO?

It's an unusual title. It reminds me of Dwight Schrute being the "Assistant to the Regional Manager". Let's dissect it and talk about what it means.

A CoS (Chief of Staff) is often used in government and military, but has increased in popularity in the tech industry. They work with an executive (usually the CEO) to help them be more effective. This could be running meetings, advancing initiatives, solving disputes, etc. It depends on the skills of the CoS and the needs of the executive.

A good way to think of it is like the Hand of the King from Game of Thrones. Hopefully there's a few less beheadings, but the general idea is the same. A CoS is an adviser, liaison, and can (in some cases) make decisions on the executive's behalf.

The CoS role is usually to the CEO of a company. We have a permanent CoS (Stella) for our CEO (Sid). However, this particular role is, "…to the CTO…" and supports our Chief Technology Officer, Eric. Otherwise, everything else is the same.

Another key difference is that this is an "acting" role. I won't be "acting" in a traditional sense. In this instance, acting means, "temporary". I'll walk like a CoS, talk like a CoS, and do all the things a CoS does. But on paper, I'll still be an Engineering Manager. After three months, I'll go right back to my old role.

Why am I taking this role?

This role gives me insight into the upper levels of the company, and I get to see how a C-level executive operates. It helps me see if this level of management is where I want to end up. It allows me to build empathy for upper management and see how and why they make decisions. The role is quite new, so I get to help shape it, and grow it for the next folks.

The temporary nature of this role offers me a level of reassurance too. All being well, I'll have spent three months in one of the best learning opportunities to come my way. If not, I'll have lost nothing but time.

I have no idea what I'm doing

Once again, I've found myself in a role where I have no idea what I'm doing. But that's where I thrive. I'm far more comfortable outside my comfort zone than I am within it. I would encourage you to step out your comfort zone and do something that scares you.

As I usually do, I'll learn and share all I can. If you're a Chief of Staff yourself, I want to hear from you. If you know someone who is, please put them in touch. I only get three months at this, but I want to give it a good run.

Increase Your Focus with Pomodoro

Fri, 24 Jun 2022 00:00:00 GMT

The Pomodoro technique isn't novel, or complicated. It's simple, and it works. Here's how it helps me focus.

What is the Pomodoro technique?

The beauty of the Pomodoro technique is in its simplicity. You can sum it up in one sentence:

"Work on one thing (and one thing only) for 25 minutes, then have a five minute break."

There's a little more to it, but that one sentence gets you 80% of the way there. The key is to force yourself to focus on a single task for the full 25 minutes. No checking email, no responding to slack messages, no scrolling Twitter, nothing. Focus on that one task and that one task only.

It's surprising how much you get done by having sole focus on one task for a set amount of time. Spending precious brain power on context-switching slows us down.

After 25 minutes, take a 5 minute break. Not just a break from the task, but a proper break. Go make a cup of tea, stand outside, or get up and walk about. It's like a rest period at the gym. Do whatever helps your brain recover.

It's recommended to take a longer, 25 minute break after 3 or 4 rounds of Pomodoro. These focus sessions can feel intense. Don't burn yourself out.

It's not all-or-nothing

If you're inclined to do so, you can use the Pomodoro technique all day. Chunk your whole day into 25 minute focus sessions and work through each one. For some folks, this works wonders. For others, it doesn't. As I have mentioned before, everyone is different and your results may vary.

I use it more sporadically. It's a tool I use when I want to really focus on one particular task.

For example, I know I want to spend a couple of hours working on this post. So I'll dedicate four Pomodoro sessions to writing it. Two for the first draft, one for editing it, and one for publishing and making final tweaks. These won't all be back-to-back though. I like to have some time between the first draft and the edit to come at it fresh. Between the second and third Pomodoro, I'll work on something else.

Time-box the time-sinks

This technique not only helps you focus, but it helps to time-box certain activities. In writing this post, I know I only have the appetite to spend a couple hours on it. I have other things to do and don't want to spend all day on it. Time-boxing it to four Pomodoro sessions ensures I don't go down a rabbit-hole and while away at it all day. Knowing my own mind, I would start on this in the morning and before I know it I'd be looking up and it's the end of the day. Anyone who's played Civilization will know exactly what I'm talking about. Having a 25-minute timer helps to pull me out of my own head.

There it goes now, see you in five!

If you're struggling to get this working for you, these tips might help:

1. Do not disturb

Turn on "do not disturb", put your phone in the other room, or use a focus app. Do whatever you need to do to put a barrier between you and your distractions. These notifications will still be there when your 25 minutes is up. Don't let the pings, bleeps, and bloops distract you from what you're focusing on.

2. Block out time on your calendar

Block some time on your calendar for "focus time". This lets people know not to bother you during that time. Or, at the very least, tells them exactly why you're not responding to their messages. Take control of your own time.

3. Use a physical timer

It's called the Pomodoro technique because traditionally, it uses a Pomodoro timer. These are small kitchen timers in the shape of a tomato. Or, if you're Italian, a Pomodoro.

Sure there's a load of Pomodoro apps, but most require you to have your phone with you. See point 1 for why this is a bad idea. Plus, it's kinda fun to have a physical timer.

Egg timer in tomato shape for Pomodoro Technique by Marco Verch, licensed under CC by 2.0

4. Distracted? Start again

Find yourself distracted during your focus period? Maybe you let an email notification pull you in, or a passing thought took hold. Start the timer again. Whether you're 2 minutes in or 20. Start the timer again. This helps annoy you into focusing next time and not fall back into old habits.

5. Don't take it too serious

Counter to all the advice above, maybe the best way to get this to work for you is to care less. We're all different and for some people the pressure of being forced to focus is all they can focus on. There are no rules here; do what works for you.

Give it a go

Search for this technique and you'll find hundreds of Pomodoro apps. Don't bother with them. The beauty of this technique is its simplicity. Use what you have, find a task to focus on and set a timer for 25 minutes. Grab that old egg-timer out of the drawer, use your watch, or yell, "Alexa! Set a timer for 25 minutes!". Whatever gets you started.

As ever, I'm interested to hear your thoughts. Have you done this before and loved it? Did you hate it? Are you eager to try it? Give it a go and join the discussion below.

What's stopping you?

Starting small

Sat, 07 May 2022 00:00:00 GMT

The secret to getting something done is simple. <br/> Go ahead and do it.

Boring Solutions

At GitLab we embrace boring solutions. We look for the smallest possible thing we can ship that gets us on the right path. For an example, take a look at the Pipeline Authoring Group's Pipeline Editor. We wanted to build a new editor that would help users create, edit, and update their pipeline configurations. When we started discussing it, we thought big:

"Wouldn't it be cool if we could visualize the pipeline you were building in real time?"

"Imagine writing a pipeline config with syntax highlighting, auto suggestions, and all the other features our IDE's give us!"

"Could we build a pipeline visually and have the editor convert everything back into a yaml configuration file?"

"What if we had a library of common components that we could include right into our configurations from the editor?"

With all those ideas in our minds, we started thinking small. What was the boring solution? What was the smallest possible thing we could ship that set us on the right path to iterate towards all the great features we dreamed up?

Our boring solution? A text area.

We dialled everything back and introduced the feature as a readonly text editor that loaded in your .gitlab-ci.yml configuration. After that, we allowed you to edit it, then commit it those changes into your repo. It wasn't fancy, or groundbreaking. It had none of the awesome features we originally intended for it. It was everything it needed to be, and nothing else. It was boring.

Iterate

The key part of a boring solution is that it puts you on the path to iterate. Without this crucial step, our pipeline editor would still be little more than a text area. It's been a little while since we shipped our boring solution, and we've iterated on it from there. We've added a lot of the features we originally planned out and many more we hadn't thought about. It's now a key part of the pipeline experience in GitLab and is a truly awesome feature.

Starting small and gradually adding functionality offered several benefits: Firstly, there was something useful that we could start gathering feedback on after a matter of weeks. The more feedback we got, the more we added to it. The more we added to it, the more people used it. The more people used it, the more feedback we got. The more informed we were, the better our feature developed.

Little bits, over time. With something useful at each step.

Not just software

This idea extends beyond software. It's served me well in many aspects of my life and career. Another example comes from starting our meetup, Frontend NE. When starting Frontend NE, we talked about all the things it could become and everything we wanted to achieve with it. We talked about conferences, speakers, online courses, and all sorts of things. But we knew if we were going to start this thing, we should start small. So we started a Twitter account, rented a free back-room in a co-working space and had one of the organizers give a talk. The bare-minimum.

From there, we iterated. We got a better website, a ticketing system, a bigger room, better AV equipment, sponsors, merch, seasoned speakers, and more. Each part, gradually, over time.

Five years later and we were in a much bigger space with a regular turnout of 100 folks. We'd ran two sold-out conferences and had a semi-successful YouTube channel with (almost) all our talks recorded and uploaded. We would never have had this if we hadn't started small. We wouldn't have achieved the success we had if we hadn't iterated.

Throw it away

Another benefit of starting small is that it makes it much easier to throw away things that don't work. If we held our first meetup and no one showed up, we wouldn't have lost much. A little bit of time and a small amount of money, but nothing compared to if we started big and then realized there was no appetite for it. Starting small gives you a safer space to make mistakes and pivot.

Having small iterations allows you to test out ideas. Maybe you're adding a feature no one needs, or doesn't really solve the problem you thought it would. With small iterations, that's fine. You can remove it, or pivot on the idea with relatively little time wasted.

Don't be afraid to throw things away.

What's stopping you?

So where could a boring solution help you? What are you procrastinating on that you could just strip back and get started today?

What's stopping you?

Take Control of Your Calendar

Fri, 25 Feb 2022 00:00:00 GMT

I love async weeks, but they're a temporary fix.

They're the crash diet of the remote work world. Sure you lose the weight, but you gain it all back once you return to your usual routine. The healthier solution for the long-term is to change your meeting (or eating) habits.

I wanted to own my calendar and have more time to focus without feeling like I need to resort to an async week. I'll still have async weeks—we've committed to doing one per quarter—but I'd rather not need them.

Analyzing the Calendar

The first step in cleaning up my calendar was to assess the current state. When starting this process, my calendar looked like this:

I've removed the text to keep things confidential, but this is my actual calendar from a few weeks ago. It's a mess. There's a lot of meetings and they're all over the place. Some of those meetings were important and un-missable. Some of them weren't important at all and my non-attendance wasn't even noticed. But they all looked the same.

In Lara Hogan's essential book, Resilient Management she states:

"I began color-coding my calendar events based on the kind of brain I was going to be using during that time." — Lara Hogan

This exercise is helpful to see where you spend your time. You can also glance at your calendar and get a feel for the kind of day you're going to have.

I colored my calendar based on the following mapping:

<code style="background-color: #d50000">Red</code> – Interviews
<code style="background-color: #8e24aa">Violet</code> – 1:1 with reports/manager
<code style="background-color: #7986cb">Indigo</code> – 1:1 with peers
<code style="background-color: #039be5">Blue</code> – Group meetings I'm leading
<code style="background-color: #0b8043">Green</code> – Group meetings I'm not leading
<code style="background-color: #f6bf26">Yellow</code> – Optional group meetings
<code style="background-color: #f4511e">Orange</code> – Coffee chats
<code style="background-color: #a79b8e">Gray</code> – New events (default color)

This is a much more useful view. It's still a mess, but a well-labelled mess. I can more clearly see where I'm spending my time.

Looking at the week in retrospect with the colors applied, I got a few bits of information:

1. I had a few meetings too close to my lunch break

There's a couple of occasions where meetings sandwiched my lunch break. This usually resulted in me skipping lunch as I get wrapped up in taking notes, writing follow-ups, and prepping for the afternoon. If I did manage to get lunch, I often had to sneak mouthfuls in during the next meeting. That's not a good look.

2. I worked a 12 hour day on Thursday

I shouldn't do that. I was a zombie in the latter half of that day and for most of the next one. This was down to poor management of my interview schedule. To accommodate candidates in APAC (Asia-Pacific) timezones, I opened my calendar up earlier on Tuesday and Thursday. However, I didn't adjust the meetings in the latter part of those days to counteract this. Tuesday was a 10 hour day for similar reasons.

3. I spent 30% of my time in meetings, but it felt like much more

This is due to the spread of meetings. The largest block of uninterrupted work (excluding Friday) was 3 hours. After that, there's a couple blocks of 2 hours and the rest was 30 minutes here and there. That's not enough time to settle in and focus on deep-work.

4. There were a few meetings I didn't respond to

Most of these were company-wide meetings that I didn't attend, or plan to. They were optional and I'm sure my presence or response wasn't missed, but that's besides the point. It made it a lot harder to see the meetings I did have as they were often overlapping and taking up valuable space.

Fixing the issues

These observations gave me a good starting point to set up some rules to follow. They needed to be simple and memorable, as they will dictate how I organize my calendar going forward.

1. Longer lunch breaks

I won't actually take a 2-hour lunch break. But by blocking out 2 hours each day for lunch, I've given myself a lot more flexibility. It's scheduled in my calendar every day and no one can add a meeting on top of it. It also prevents me sandwiching my lunch between two meetings and skipping lunch as a result. Plus, if I need to take extra time on the odd day, I can do that.

2. No meetings in the morning

Most of the folks I work with are in AMER (North, Central and South America). Our overlap is in my afternoon so I can schedule all my meetings after lunch. This gives me all morning, every day, to get my focus work done and dedicate my afternoon to meetings.

There are some exceptions. Some of the folks I work with are in APAC and I'll have to meet with them earlier. Bunching them all on the same day will maximize focus time.

3. Group like-meetings together

Another benefit of color-coding the events is to highlight context-switching. In Resilient Management, Lara recommends:

"Try grouping meetings together to avoid context-switching, or scatter particularly draining events throughout your week." — Lara Hogan

Using the colors I applied earlier makes this a lot easier. Grouping events of the same (or similar) color together reduces context-switching.

4. Say "No" to meetings I'm not attending

This is common courtesy, but it also helps clean out the visual clutter from my calendar. Especially when paired with setting my calendar to hide declined events.

5. No meetings on Fridays

I already had this rule. In-fact, it's a general rule at GitLab. We call them Focus Fridays and they're awesome. I love this rule, let's keep it.

After applying these rules, and doing a bit of calendar shuffling, my calendar for this week looked like this:

It's stunning. Clear, focused mornings; walled off with a hefty block of OOO for a more flexible lunch. Followed by an afternoon of contextually-grouped meetings, with an easy start and end to the week.

There's 12.5 hours of meetings in there. This is down ~35% from the 19 hours of meetings in the other week. 10 of those hours are due to me not currently interviewing. The remaining 6.5 is from declining meetings I don't need to attend.

There's still a few things I'd like to iterate and improve on. I bunched my APAC meetings together, but they still go outside my usual working hours. They're also on a day were I have meetings right up until the end of my usual hours. This means that instead of being able to shift my day forward an hour on those days, I end out working that extra hour. This isn't a huge problem, but if I can sort it, I should.

There's also a bit of clutter on Thursday. The checkered meetings are ones I've responded with, "maybe". They're group meetings where I'll check the agenda 10 minutes before and see if it's worth tuning into or not. I should be more decisive here, but I'll see how it goes. At least I've responded with something on these events. I'm getting there.

Keeping it up

New meetings are colored gray to make them easy to spot. As soon as I see these, I should triage them. I need to respond, assign them a color, and consider if it fits my rules. If a meeting doesn't fit the rules, I should determine if I'm willing to make an exception or request we move it.

As with everything, this is an ever-evolving process. I will continue to experiment with my scheduling if something doesn't feel right.

With increased focus-time and less context switching, I'm ready to make every week (almost) as productive as an async week. I'd recommend you try it out and see how this works for you.

Remember; you own your calendar, don't let your calendar own you.

Writing to Your Future Self

Fri, 24 Dec 2021 00:00:00 GMT

We're coming close to the end of another year and it's time to self-reflect. How can we accurately remember all we did in the last year? What if we could reach out to our past-selves and ask them?

Whilst we can't travel back in time, we can leave something for our future-selves to discover. This is what I've been doing in 2021. I've been keeping a journal of my management journey. My accomplishments, my mistakes, how I'm feeling, and where I want to improve. It's hastily typed, full of spelling errors, and not for public consumption; but it's the most useful document I have.

I started this as a daily thing, but it became cumbersome and I'd go weeks without adding to it. So I iterated and came up with a process that prompted me to fill it in weekly. Every Friday I ask myself the following questions:

How do you feel about the past week?
What progress did I make on my top priority?
What is the top priority next week?
What was my biggest success or failure this week?
How confident do I feel as a manager?

They're all free-text and I can write as little or as much as I please.

Like most projects, I over-engineered it. I used bash prompts to answer the questions and auto-commit the file to a repo. Then I use GitLab pages to build out the repo into a private website (see public example). This process helps me focus and makes it difficult to do any real editing of the posts. It prevents me from spending too long poring over what I've written and trying to make it perfect. The entries are supposed to capture my mood in the moment. The less editing the better.

For your eyes only

Whilst I advocate transparency in most matters, this one should be confidential. It's a 1:1 with yourself and you should be comfortable to say what's on your mind. Keeping it opaque prevents you from overthinking and worrying about other readers. You can rant, rave, swear, and be as contrarian as you like. This is your document for you, and you alone.

With that said, I recently shared some select passages with another Engineering Manager. They are in their first year as an EM and I'm helping them through some of their challenges. Being able to share certain passages from when I was having a tough time helped to show them they weren't alone. It helped curb their imposter syndrome a little knowing I'd been through the same thing. This is a topic for another day though.

Reflect

As cathartic as furiously typing into the void is, it's much more helpful if you go back and read what you wrote. After all, past us went to all the effort to write it down, the least future us can do is read it.

Management is a long-game and it can be tricky to step back and see the whole picture. Being able to read back through your year (and beyond) gives you the opportunity to spot mistakes you made. You can watch yourself make poor decisions and learn how to better avoid them. You can marvel at your own resilience and pay attention to how you pulled yourself out of any pitfalls. The most cathartic thing by far, is watching yourself struggle with tasks that you now find simple. It's a great tool for seeing how far you've come on your journey and how you can continue to improve.

New Year, new you

If you didn't start doing this a year ago, there's not a lot to reflect on. But why not start now?

To make it easier to start, I've made the starter for the system I use public. You can have it as a Google Doc, or fork the over-engineered version I use. Use whichever will work the easiest for you and allow you to keep it within reach.

Do your future self a favour and start writing to them today.

All Meetings are Optional

Fri, 26 Nov 2021 00:00:00 GMT

I started to feel like I couldn't finish the work I needed to do because meetings were getting in the way. So I declined all my meetings for a week and went async.

When doing all-remote, async communication is key. We have to think about typically synchronous things (like meetings) in a different way. At GitLab, ~~all~~ most meetings are optional and have an agenda ready ahead-of-time that anyone can edit. You can attend meetings asynchronously and work on your own schedule. Turning the usual way of thinking about meetings on its head puts people back on a level playing field.

"The beauty of asynchronous is that team members can contribute to meetings that occur while they sleep." — GitLab's All-Remote handbook

Having an active agenda ahead of time allows people to contribute to the meeting asynchronously. This has been great for me as it allows me to contribute to meetings that occur outside my working hours. It allows me to hire and manage folks in APAC (Asia-Pacific) timezones, which I'm currently doing. It also allows me to focus on getting things done, without the usual meeting interruptions. That is exactly what I did last week. We call it an async week, and they're fantastic.

I'd still "attend" meetings by adding my points to the agenda and watching the discussions on the recording. I just don't have to be there at the exact time they were happening. Recording meetings felt weird at first, but you get used to it. Being able to watch them at 2x speed and skip the points that don't apply to you are absolute game-changers.

A crucial step with async week is to let people know you're doing it. You'll likely have a few meetings where you'll be missed if you don't show up. It also prevents people from scheduling meetings with you for that week. Let people know, and over-communicate your intentions. I did this with a cross-posted slack message and brought it up in my usual meetings the week before.

Next, it's the cathartic process of declining all your meetings. Clear, calendar, bliss. You can then plan your workload with ease and revel in all the free time you've given yourself.

I used this week to burn though my backlog, but it also gave me a new outlook on the meetings I do have. I couldn't do an async week every week, but there's a few meetings I don't need to attend as often, or at all. These meetings can pile up. My next step; get brutal with my regularly scheduled calendar events. But that's a topic for another day.

This wouldn't work without our company-wide stance of async-first communication. Huge props to Darren, Jessica, and our remote team for helping foster a culture that allows us to take weeks like this. Check out our all-remote handbook for tips on how to do this.

Side note: I made a desktop wallpaper to remind me that, "all meetings are optional". Check it out

Find What Makes You Productive

Mon, 01 Nov 2021 00:00:00 GMT

In my never-ending quest to find the secret of infinite productivity, I've realized one thing: No one method works for everyone.

I've read the usual heavy-hitters like, Getting Things Done, Eat That Frog, and The 7 Habits of Highly Effective people. I've listened to hours of podcasts, and talked with folks from all over the place. I've tried this, that, and the other thing. My mistake was thinking too prescriptively.

This was all good advice, but they were insights into what worked for the people that wrote them. I am not those people, and (most likely) neither are you.

The real secret to unlocking your productivity is trying different methods and picking the bits that work for you. Create your own franken-methodology then continually assess and iterate upon it. What works for you today may not always work as your life changes, your priorities shift, or you take on different responsibilities.

My (current) process

My current process is a hodge-podge of other methodologies that work for me now. It has changed a lot and it will change again. Use it as inspiration and look deeper and see what works for you. Build your own productivity monster!

I use todoist to collate all my tasks in one place. These come from GitLab issues, emails, conversations, and random thoughts in my own brain. To maintain my sanity I keep them all in one place; that place is todoist. The important thing for me is that I can add these tasks fast, from anywhere. I make sure to keep it within reach.

I triage my tasks according to the 1-3-5 rule. I plan for the week and iterate on that plan daily. I delegate some tasks and abandon the tasks that don't matter. The remaining tasks get a priority label (P1, P2 or P3).

Each day has only one P1 task. This is my most important task of the day. I do it first and Eat That Frog before moving on to my other tasks. If anything unexpected comes up in the afternoon I'll likely have already done the important thing that day.

There are three P2 tasks. These tasks are likely to get done, but can be pushed along a day or two if needed. If a task gets pushed along too many times, I will re-asses it. If it's important, I'll bump it up to a P1 and make sure to eat it first thing the next morning. If it's not important, it goes onto the backlog.

Finally, there are five P3 tasks. These are of similar importance to P2 tasks but are a lot quicker to do. If I have a spare few minutes between meetings, or I finish another task early, Ill pick one of these up.

All these tasks are time-boxed with a pomodoro timer. This helps me focus on the task at hand and prevents me going too deep into a rabbit-hole on some of the more open ended tasks.

I try to be as transparent as possible with my task-list. I created a web app that scrapes my todo list for the current day and displays it for ~everyone~ the whole company to see. The app also helps me communicate my task list in slack using our Geekbot standup.

This method seems clinical and prescriptive. That's because it is. In all honesty, I deviate from it more than I stick to it. But having this plan in place helps me stay on track, even if I need to wander off that track every now and again.

The Important Thing

The important thing to note is not what I do. It's that I've taken aspects of all sorts of different methodologies to build one that works for me.

I used to get distracted a lot and spend more time on tasks that interested me. I combatted this using Eat That Frog and the pomodoro timer.

I used to feel overwhelmed at the amount of tasks I had. I combatted this by collating them all into one place.

I used to agree to do things verbally, then completely forget about them. I combatted this by keeping my task-list within reach.

There's more I still need to improve on, but I'll do so iteratively. Experiment, iterate, and find what works for you.

Keep the important things within reach

Tue, 26 Oct 2021 00:00:00 GMT

The best advice I received when learning to play guitar, was to keep it within reach.

Don't put it away, in a bag, in a cupboard, or in a room you don't go in. Keep it to hand so that when you get a spare few minutes you pick it up and play it. Make sure there are as few steps as possible between whatever you're doing and playing the guitar. Do this and you'll practice more, learn faster, and be a better player.

This extends to my day-to-day life, especially at work. I need to make sure there's as few steps as possible between me and my most important tasks. For me, these tasks are usually:

Adding items to my todo list
Accessing my 1:1 agendas
Searching the GitLab handbook
Finding bookmarked GitLab issues or MRs

For most of these tasks I use Alfred. Alfred is a Mac app that predates the built-in spotlight search and offers many similar features. You can create your own workflows with simple flowchart based logic, or break out into code and make them as powerful as you need. The majority of mine fall into the former category as I'm a firm believer in the boring solution.

Adding items to my todo list

I have a regimented system for managing my todos. The heart of it requires me to add todos to an inbox for later triaging. Usually, I'm adding todos mid-meeting or mid-conversation. The faster I can do this, the better.

I used to use Alfred Workflow Todoist for this. It's a little buggy though, and the Todoist Mac app has a much nicer shortcut so now I use that directly. In a couple of keystrokes, I can start typing in whatever I need to do and send it to my todo list inbox.

Accessing my 1:1 agendas

I have automated the creation of my meeting agendas but I still need to access them quickly. This could be to add items to the agenda, look up past items, or have it open during a meeting. I tried handling this with bookmarks (which I still do for other things) but I needed even faster access. This required a custom workflow. Thankfully, Alfred has a built in List Filter method. I used this to set up a list of all my meeting agenda urls, making them searchable by title. All I need to do is type 11 che… and I get my 1:1 with Cheryl, or 11 auth… for the Pipeline Authoring group meeting. Hitting enter opens up the agenda and we're away.

Searching the GitLab handbook

The GitLab handbook is the source of all knowledge for everything GitLab. Unfortunately, the search functionality isn't amazing (though it is getting better). Fortunately, it's public so we can use the power of Google site search.

https://www.google.com/search?q=site:https://about.gitlab.com/handbook/ {query}

All we need to do is replace {query} with whatever we want to search. This gives us a Google results page scoped specifically to the GitLab handbook. Fantastic.

Alfred makes this even easier. I can run handbook {query} in Alfred and it opens my browser with the search results. It's simple and boring, but effective.

Finding bookmarks

I have a lot of links that are important to access quickly, but change on a semi regular basis. The planning, retrospective, and release post issues for the current milestone. OKRs, shared goals, hiring trackers, etc. They're all links that I'll need to reference several times, but not as permanent as a 1:1 or meeting agenda. For these, I use the browser's built in bookmarks feature. To make it one step lazier, I use Alfred Firefox Bookmarks. This way, I type ff {query} into alfred and get a list of all the bookmarks that match that query. As with most of the others, it's simple but saves me a lot of time.

All the others that I haven't named

These are my most used workflows, but they're not the only ones I use. I have one that controls Spotify, one that starts a pomodoro timer, one to search our org chart, and many more. The point here is not about the actual tools I use. It's about the practice of keeping the important things in reach and making repetitive tasks as quick as possible. Each task on its own will only save me a few seconds to a minute, but I average 50 uses of alfred a day. It all adds up.

Auto Generate Social Images

Sat, 23 Oct 2021 00:00:00 GMT

I've put a lot of effort into designing this site, only to share it on social media and be greeted with this monstrosity of a preview:

These previews are generated with open graph tags. Little bits of metadata that tell social networks (and other sites) about your site. They take parameters like, title, description, image, and a few others. There's a lot of uses for these, but social previews is the most common. I had a few set up for this site, but they were poorly configured. Which is why we see the hot mess in the above screenshot.

There were some configuration changes I had to make, such as the description being set to undefined, but the main thing I wanted was preview images. Images really make your posts stand out in a social feed. I didn't want to pair a generic stock image with each post; nor did I want to use the same image for every post. I wanted each image to be unique, and meaningful. Something like this:

Lovely stuff. It matches the style and tone of the blog nicely. It will stand out in any social media feed. It's entirely auto generated.

That's right. There's no Photoshop, Figma, Gimp, or any image editor of any sort used here. If I change the background color or title of this post, the image changes right along with it. It's all done using JavaScript canvas and generated at build time.

I cobbled this together after reading, "How to create and save an image with Node.js and Canvas". If you want to go more in-depth, I'd recommend reading this article. A lot of my code was ~~copy/pasted from~~ inspired by it. With this script, I can pass it a title and a background color and it will generate and write an image to my filesystem. I'll no-doubt tweak and update this over time so you can view the up-to-date source on GitLab.

Because I'm using Gridsome to generate this site, I can hook into the api.onCreateNode() lifecycle hook and make sure an image is generated for each post.

api.onCreateNode((options) => {
  if (options.internal.typeName === "Article") {
    const { title, background } = options;
    generateSocialImage({ title, background });
  }
  return options;
});

With a little tweaking though, there's no reason you couldn't use this node script on a regular node server, or as a serverless function. Jason Lengstorf has written another great atricle on a similar approach.

All that's left is to tell the social tags where the image is.

<meta
  property="og:image"
  content="https://sam.beckham.io/social_images/auto-generate-social-images.png"
/>
<meta
  name="twitter:image"
  content="https://sam.beckham.io/social_images/auto-generate-social-images.png"
/>

Now when we share this post on Twitter (other social media sites are available), we get a much nicer preview image. Why don't you share this article yourself to see it in action!

Automate Your Meeting Agendas

Tue, 05 Oct 2021 00:00:00 GMT

I've wrestled with far too many Google docs, for far too many meeting agendas, for far too long. There must be an easier way.

After a year or so in engineering management, I've run a lot of meetings. Every meeting should have an agenda, and every agenda should be filled ahead of time. For repeating meetings, I was copy-pasting agenda templates every week. Because this task is manual and I'm a lowly human, I often forgot to do it and frantically added the agenda 10 minutes before the meeting. It was a tedious, repetitive, and boring task; something computers are great at.

We use Google docs for our meeting agendas so everyone can contribute in real-time. This also means we can use Google scripts to introduce some automation. So that's exactly what I did. Better yet, I created a library so you can use it too.

How to use it

You can add this to any Google doc and it should work fine. The only thing you need to have in your document is a horizontal line separating the heading from the agenda section. If the code won't run, this is likely the reason.

Open the document you want to add the script to, then go to Extensions > Apps Script. This should load up the Google Script window and let you start entering some code. Before we start writing anything, we'll want to add the MeetingUtils library. Click on the + sign next to Libraries and enter the ID: 1ODNAyDAGqdLk1yfrkXOpoBLvO8OVvxie-xzCToiestMx8uBpCnaSjQD9.

After that, it's as simple as adding some variables, creating the function, and setting up a schedule.

For a 1:1 meeting, use the nextOneToOne() function. It takes the name of your report, your name, and the day of the meeting. This day is numeric where sunday = 0, but you can use the constants included in the library to make it a little easier to read. See the full range of options at the bottom of the post.

function addNextAgenda() {
  MeetingUtils.nextOneToOne({
    reportName: "Fred",
    managerName: "Sam",
    meetingDay: MeetingUtils.getConstants().WEDNESDAY,
  });
}

For a group meeting (or similar) use the nextGroupMeeting() function.

function addNextAgenda() {
  MeetingUtils.nextGroupMeeting({
    meetingDay: MeetingUtils.getConstants().WEDNESDAY,
    sections: ["Announcements", "Discussion"], // You can add as many sections as you like here
  });
}

Once that's done, make sure your function can run by selecting the addNextAgenda function (or whatever you named it) and hitting, "run". You may need to do the permissions dance to give the script access to edit your document. Now, whenever you run that function, it creates a meeting agenda item for the next selected day.

This is only semi-automated right now. To fully automate this, we need to create a schedule that runs every week. Head over to the triggers tab on the far left and add a repeating trigger. You can set it to run on all sorts of events, but the most useful one is the time-driven week timer. I like to set mine to run at midnight the night after each meeting. This way there's almost a full week for people to add their agenda items. Do what works for you though.

That's all you need to automate this boring task and get back to doing the interesting things.

Options

There are a few different options you can use. The defaults will work fine, but with a few tweaks, this script is much more versatile.

`nextOneToOne(OPTIONS)`

By default, this generates a typical 1:1 agenda in the format:

## YYYY-MM-DD

### Report Name

1.

### Manager Name

1.

| Option                 | Description                                                                                                                                  | Required | Default |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------- |
| `reportName`           | The name of the report                                                                                                                       | `true`   | -       |
| `managerName`          | The name of the manager                                                                                                                      | `true`   | -       |
| `meetingDay`           | The day of the meeting in numerical format where `sunday = 0`. The script uses this to determine when the next occurrence of the meeting is. | `false`  | `0`     |
| `useHumanReadableDate` | When `true`, changes the date format from `2021-10-11` to `October 11th 2021`                                                                | `false`  | `false` |
| `questionOfTheDay`     | When `true`, adds a randomly selected question of the day to each agenda. This is still experimental.                                        | `false`  | `false` |

`nextGroupMeeting(OPTIONS)`

This is a less-tailored version of the 1:1 template, generating an agenda item in the format:

## YYYY-MM-DD

### Section 1

1.

### Section 2

1.

| Option                 | Description                                                                                                                                 | Required | Default                           |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------------------------------- |
| `meetingDay`           | The day of the meeting in numerical format where `sunday = 0`. The script uses this to determine when the next occournce of the meeting is. | `false`  | `0`                               |
| `sections`             | An array of all the sections you want to include in the agenda. There's no limit to this.                                                   | `false`  | `["Announcements", "Discussion"]` |
| `useHumanReadableDate` | When `true`, changes the date format from `2021-10-11` to `October 11th 2021`                                                               | `false`  | `false`                           |

Owning my content again

Mon, 07 Oct 2019 00:00:00 GMT

Medium, we had fun, but you've changed. A beautiful reading experience tarnished by paywalls, advertisements, and popovers. I want my content back on my own platform.

Owning my own platform gives me freedom. Freedom to tweak the code and eek out those extra milliseconds of performance. Freedom to add whatever features I want, and remove those that I don't. But most of all, the freedom of knowing it won't ever change or disappear, unless I want it to.

It does come with a few downsides. The biggest two being discoverability and collaboration. I can write all the posts I want, but no one will see them unless they actively look for them.

With a couple of extra additions to this site, I may have solved these problems. I just had to use something old, something new, something borrowed, and something blue.

Something old

Back in the good-old-days we all had our own blogs. People were still able to discover our posts by using RSS feeds. You could subscribe to the RSS feeds of you favourite blogs and your RSS reader would collate them all. It's a bit like Podcasts. You subscribe to the stations you want to listen to. Then your podcast player displays all the new podcasts from your favourite stations. In fact, it's exactly like podcasts. Because RSS is what they use to manage this.

Unfortunately, using RSS for blogging died off a little in recent years. But as more and more people want to own their own data again, they're regaining popularity.

So, in the sprit of boosting RSS back to the top, I created a feed for this blog. This site is running on Gridsome which made it easy to add an RSS feed. All I needed to do was hook up gridsome-plugin-rss

module.exports = {
  plugins: [
    {
      use: "gridsome-plugin-rss",
      options: {
        contentTypeName: "SanityPost",
        latest: true,
        feedOptions: {
          title: SITE_NAME,
          feed_url: `${GRIDSOME_BASE_PATH}/rss.xml`,
          site_url: GRIDSOME_BASE_PATH,
        },
        feedItemOptions: (node) => ({
          title: node.title,
          description: node.description,
          url: `${GRIDSOME_BASE_PATH}/wrote/${node.slug.current}`,
          date: node.publishedAt,
        }),
      },
    },
  ],
};

I dropped in the default config, tweaked it to match my own site, ran yarn build to give it a test, and success! Sort of. The good news was, the feed was there and all my posts were in it. The bad news was, they were in a completely random order. After a little digging I realised they were all alphabetised on their UUIDs. A lovely order, but an entirely useless one. This was because gridsome-plugin-css sorted posts by node.date and my Sanity implementation doesn't have a date field. It's a little more granular and has _createdAt , _updatedAt , and publishedAt . The one I wanted was publishedAt , but there was no way to tell the plugin this information. Yet.

The best thing about open source is that everyone can contribute. I found a problem with the plugin and took it upon myself to fix it. A couple of changes to the codebase and I could pass in dateField: "publishedAt" which orders our posts by the correct date field. Joy!

The RSS feed is up-and-running. It's nothing fancy, but it gets the job done.

Something New

The best posts are the ones that spark a conversation. But how do we allow those discussions on a static site? I could add Disquss, or use FaaS (Functions as a Service) to let people post comments. But it's not quite what I want. Usually, I prefer using the boring solution. But this time I went for the shiny option. It's my platform, I'll do what I want.

The shiny solution here is a new standard called Webmentions. In essence, they're a list of all the places that "mentioned" your post. If you Tweet out your post on Twitter, that's a mention. If someone responds to that Tweet, that's a mention. If someone likes, or retweets that Tweet, that's a mention too. Then all you do is take that list, filter it, and render it to your site as "comments". This isn't just Twitter either. It works for other sites too, but for simplicity, I'll stick with Twitter for now.

Getting this list wasn't too hard. I followed the instructions on Max Böck's post to the letter. If you want them on your site too, I'd start there.

Once they were set up, I had to integrate them into Gridsome. Unfortunately, Max uses eleventy, so I could only use his post as guidance. There are also no Gridsome plugins for Webmentions yet, so I had to go alone on this one.

If you want to see exactly how I did it, I'd recommend looking at the Merge Request (that's what we call Pull Requests at GitLab). This whole blog is public, so you can dig in and have a proper look at the code. If you want the cliff notes, the whole thing was done in three steps:

1. Add the Webmentions feed into the Gridsome API

This is probably the most complex part. I needed to take the API provided by webmention.io and expose it on the GraphQL endpoint in Gridsome. This was done by adding the following code to gridsome.server.js

const axios = require("axios");

const API_ORIGIN = "https://webmention.io/api/mentions.jf2";
const { GRIDSOME_WEBMENTIONS_TOKEN } = process.env;

module.exports = function(api) {
  api.loadSource(async (store) => {
    const { data } = await axios.get(API_ORIGIN, {
      params: {
        token: GRIDSOME_WEBMENTIONS_TOKEN,
      },
    });

    const mentions = store.addCollection("mentions");

    for (const item of data.children) {
      mentions.addNode(item);
    }
  });
};

2. Pull the mentions into a `PostComments.vue` component

Once the Webmentions data was available on the GraphQL endpoint, I could pull it into the project. Webmentions collates, likes, retweets, mentions, and replies. But I'm only interested in replies for now so I filtered everything else out using wm_property .

query {
  comments: allMentions(
    sortBy: "published"
    filter: { wm_property: { eq: "in-reply-to" } }
  ) {
    edges {
      node {
        id
        author {
          name
          photo
          url
        }
        content {
          text
        }
        published(format: "MMMM Do, YYYY")
        url
        wm_target
      }
    }
  }
}

Unfortunately, Gridsome isn't able to pass javascript variables into GraphQL queries just yet. Which means I couldn't filter the mentions by post. This query returns all the mentions for all the posts. To get around this, I requested wm_target which gave me the url to the post linked to that specific mention. All I needed to do was filter out the ones I didn't need after I loaded the mentions. Then I had a nice, clean array of "comments" that I could loop over and render as I please.

computed: {
    comments() {
        return (
            this.$static.comments &&
            this.$static.comments.edges
            .filter(comment => comment.wm_target.match(this.postSlug))
            .map(comment => comment.node)
        );
    }
}

3. Re-build the site when new comments are posted

Because the comments get baked in at build-time, new mentions won't be rendered until I re-build the site. All I had to do there was set up a new pipeline trigger and pass the webhook URL to webmention.io. Whenever I get a new mention, webmention.io calls the webhook, GitLab triggers a build, and my site is redeployed. There's a potential 10-30 minute delay, but it's a small price to pay. Besides, the conversation is happening on Twitter, I'm just re-rendering it on this site.

Something Borrowed

The RSS feed is a great first step towards discoverability, but I want to get my posts in front of a bigger audience. This is something Medium gave me for free and one of the main reasons I switched to using it. But there is another way.

Dev. to is a similar platform to Medium, but with a lot of the junk removed. If I didn't want to own my own data, this would be the platform I'd use. But just because it's not my primary platform, doesn't mean I can't borrow it when I want to. Dev. to can automatically cross-post your items to their platform. All you have to do is pass it your RSS feed. It's a good job we've just added one of those!

If you're reading this post on Dev. to, then this process worked!

Something Blue

I'll be honest, this is where the analogy falls down. How about a lovely, blue footer?

I'm just getting back into writing again. I hope to continue to add little improvements to this blog and write about them as I go. If you end out using any of these techniques on your own sites, let me know!

Running the JAMstack on GitLab

Wed, 02 Oct 2019 00:00:00 GMT

The JAMstack has piqued my interest. Not because it's fast, secure, or totally hot right now. But because it got me thinking, "We could run that on GitLab".

These thoughts cross my mind a lot. GitLab is such a versatile tool that it has endless applications. I use GitLab to run a conference, keep track of my wedding plans, and even help create GitLab. It's almost definitely a case of Maslow's Hammer where, "…everything looks like a nail". But who cares, I'm eyeing up a JAMstack shaped nail right now, with my GitLab branded hammer in hand.

What is the JAMstack?

Before we dig into what I did, let's explain what the JAMstack is. The acronym itself stands for Javascript, APIs, and Markup. Which on its own, could describe almost any website. Here's a quote from the top of https://jamstack.org/ that explains it better:

A modern architecture —
Create fast and secure sites and dynamic apps with JavaScript, APIs, and prerendered Markup, served without web servers.

The key part here is "served without web servers". JAMstack sites are static. They do all the compiling at build time, not at runtime. It's often confused with isomorphic websites built with Next, Nuxt, or similar. But the concept is entirely different. We're not rendering pages on the server, then hydrating them once they get to the frontend. We're building the pages once (at build time) then serving up those static pages at runtime. This makes for a blazing fast website with little to no server costs.

Let's do this

If you hadn't already guessed, the project I created on the JAMstack is the blog you're reading right now. It looks and behaves in much the same way that it did previously, it's just a lot faster, and easier to update.

The first thing I needed to do was pick a static site generator. I had a look at Gatsby and Eleventy, but ultimately settled on Gridsome. It's based on Vue.js and integrates with GraphQL, which is something I've been wanting to look into for a while. This seemed like the perfect excuse.

With the site generator chosen, I needed to work out where to store my data. When this site was running on Jekyll, I used markdown files stored in the repo. Whilst this worked well enough, I wanted a little more flexibility. Something that required a CMS. I chose Sanity based on a recommendation from Jamie Bradley. Sanity is a headless CMS with a GraphQL output layer, a perfect fit for my needs.

With those two chosen, I had everything I needed to get started developing locally. I moved over all my old posts to Sanity, which was a lot harder than I expected. I wish there was an easy way to convert markdown to Sanity blocks (Sanity's rich text editor) but I had to do it all manually. I guess the one upside to my low output on this blog is that there weren't too many posts to migrate.

I already had a lot of the components of my blog written in Vue from when I tried to move it over to VuePress. A Vue based static site generator that ended out being unfit for purpose. I copied these components over, tweaked them to fit, and added my GraphQL layer. Then I was good to go.

Once I was ready to deploy, I copied the example .gitlab-ci file from Gridsome's documentation and pushed the site to GitLab. This triggered the build process on GitLab's CI pipeline and built out the static site to GitLab pages. After two painless DNS additions, I had my domain hooked up to GitLab pages with automatic SSL certs.

With very little set up—which consisted more of copy/pasting than any real hard work—I had my blog up-and-running. When I pushed a change to the master branch, GitLab's CI pipeline would trigger a build, regenerate all the static files, and re-deploy my website. This was the boring solution. The smallest possible change I could make to get my blog migrated to the JAMstack with GitLab.

Iterating on the Boring Solution

The boring solution was great, but are were a few small tweaks I could do make to make the process a little nicer.

Because my content was in Sanity, GitLab wasn't aware of any changes I made to it. The content publised on the website would be the content from Sanity at the time of the most recent build. I could manually trigger the pipeline after I published a change to pull in the latest data, but I'm far too lazy for that. I needed to automate this. Thankfully, GitLab allows you to create pipeline triggers that can listen to a webhook and start a pipeline every time it's used. On the Sanity side of things, you can call that webhook every time you publish a post. Now, whenever I publish a post, it triggers the pipeline then the website is re-built and deployed. It's not as instant as a usual CMS set up but it only takes a minute or so, and it only has to happen once.

I'm also a bit of a stickler for performance. The boring solution was fast, but still fell down on a few points. I've fixed them all now and it's blazing fast. I'll save the story of how I did that for another day. To summarise, I minify, lazy-load, pre-fetch, and cache all of the things. I also added in a service worker for good measure and that sweet offline first experience.

Serverless functions

Whilst this site has no need for serverless functions (Functions as a Service, FaaS), they are a large part of the JAMstack. Static websites are great for sites with little user interaction beyond reading information. But what if your site needed to be more complex? What if you needed to allow users to log in, make purchases, or post content? This is where serverless functions come in. They're API endpoints that (when called) spin up a VM, run some code, then disappear again until they're needed next time. There are a lot of different platforms that offer this service. AWS Lambda is the biggest right now, but there's also Azure Functions, Google Cloud Functions, and a load of other providers that offer functions as a service. All of these integrate nicely with GitLab Serverless should the need arise.

If you want a more in-depth look at how FaaS can be used with the JAMstack, take a look at this section of, "Are you being servered" by Phil Hawksworth. Then go back to the beginning and watch the entire talk. It's a great example of what you can do with the JAMstack.

Have a go yourself

If you want to have a go at building your own JAMstack website on GitLab, I've made this project completely public. You can look at the code, clone the project yourself, and even watch my pipelines. If GitLab's not your thing, head on over to staticgen.com, pick a generator, and get your site up and running in seconds on Netlify.

Edit

Since releasing this post, I decided that Sanity was not for me. It was an extra dependency that didn't always play nice with my pipelines and due to the nature of the JAMstack, I didn't always know when it wasn't working. Besides, for what I needed, markdown is fine.

I've removed Sanity and will continue to write my posts in Markdown.

Going transparent

Wed, 23 May 2018 00:00:00 GMT

As of today, I'll be going transparent.

I've started a new role at GitLab as a Frontend Engineer and will be doing all my work out in the open. Every issue, every commit, every comment, all publicly viewable on my Gitlab profile.

I use Gitlab a lot. I use it for Frontend NE, IHNIWID, and at Bytemark. You rarely get the chance to work on something you use every day. I'm very humbled to be given this opportunity. Not only is Gitlab's software great, but their values are too. They come from an open source background so everything is public. From all the code that makes up GitLab, to how they calculate employee salaries.

Being transparent comes with many benefits. As a new starter, I could look through the company handbook, see what my team is working on, and get a feel for the volume and pace of work. Going forward, it means my code will be open to scrutiny from my peers, the public, and Gitlab customers. Whilst a scary thought, it does mean that I'll be more diligent with the code I output. I'll put more thought in to the Merge Requests I make, and be more clear and precise in my issue comments. In turn, I'll become a better developer.

Unfortunately this does mean that I've had to leave Bytemark. They've been very good to me over the last couple of years and I'll miss them all dearly. They're hiring for my old job, so if you're a front-end dev looking for a new challenge, take a look, and tell them I said, "Hi".

Running a Conference

Tue, 01 May 2018 00:00:00 GMT

Running a conference is 24% blood, 62% sweat, 15% tears, and a pinch of being so overworked you forget how to count to 100. But it's worth it.

We recently wrapped on Frontend NE: The conference 2018, and I'm happy to say it was a resounding success. Speakers, sponsors, and attendees alike have said nothing but positive things, so we did something right. The mighty Christian Heilmann wrote a lovely article that sums up the day.

After running one successful conference I feel I'm totally qualified to write the definitive list on conference organisation… Just kidding. I still have a lot to learn, but here's what I've learned so far.

It's just business

A conference is a business, so run it like one. I'm not saying you have to wear a suit and explain to people what it is that you do here. But you need to do some basic things to make sure you're covered. Register your business, get an accountant, and have a separate bank account. You're going to be dealing with a lot of money from a lot of sources. Self-funding and working out the tax later is not going to cut it.

As soon as we decided to go ahead with the conference, we hired an accountant and started a Limited Company. We used that to open a bank account and hooked up our accounting software. Getting this all set up ahead of time was crucial. We could now pay people and take in sponsorship with relative ease.

Get some sponsors

You don't have to do this, but it helps. If you can get sponsorship early on, you don't have to worry as much about selling tickets to break-even. As long as you're up-front about what you're offering, companies will be happy to help out. Take a look at our (now outdated) sponsorship page for some ideas. We started with several sponsorship types, but in the end we only used one.

To price our sponsorship, we worked out how much money we needed to run an MVC (minimum viable conference) for 50 people. Then we split that cost amongst 6 sponsorship packages. That way, if everything went terribly and barely anyone bought a ticket, we were covered. This MVC consisted of, venue hire, A/V hire and speaker costs. Nothing more.

Pay your speakers

I shouldn't have to say this, but a surprising amount of conferences don't do it. Your speakers are the main reason people are attending your conference, so pay them. Pay for their travel, pay for their accommodation, and pay for their time.

At Frontend NE we paid all our speakers. Including travel from their door to ours, accommodation close to the venue, and a speaking fee of £1, 000. We offered every speaker the exact same package, regardless of age, experience, gender, or anything else. They could also donate some (or all) of their fee to our diversity fund.

Have a diversity/student fund

A diversity fund pays for tickets, travel, and accommodation for underrepresented people. This meant that anyone could attend the conference. Regardless of their race, religion, gender, education level, or financial status. We borrowed this concept from Remy Sharp's FFconf which explains it much better than I could.

Through our diversity fund, we managed to pay for several people to attend our conference. Not only did this help them, it helped make our conference a lot more diverse and welcoming. If you do one of these yourself, be sure not to label them, or give them "special" tickets. This could send the wrong message.

Don't have special tickets

Early bird, late bird, student bird, big bird, it's all too much. I understand the reasoning behind these ticketing systems, but they're not for me. As an attendee I feel undue pressure at the checkout. As an organiser, I don't like the cashflow problems it introduces. We pay the same per-head cost for each person that attends the conference. So with one ticket we know exactly how many we need to sell to break even.

Budget

Budgeting and being frugal are often confused, but are not the same thing. I'm not saying you should cut corners and spend money only when necessary. Just be aware of what you're spending and make sure you account for everything. The last thing you want is to be out of pocket at the end of it all.

I'm pretty terrible at budgeting. I leave that to my partner, both in life and in business (not the same person). Colin handled the budgeting for the conference. He was the man to ask if you needed to know how much we could spend on things. This budget saved our skin a few times, and helped a lot when negotiating prices.

No man is an island

That is to say, don't do this alone. Frontend NE is a three-man operation and we have other people that help out with various things all the time. There's just too much work for one person to do alone. We've been running a successful meet up together for three years now. Each of us has a slightly different skill-set that compliments each other's. We all have full time jobs, and some of us have families too. So having other people you can rely on is crucial.

Huge thank you to Colin and Martin for doing this with me and putting up with my bullshit. You're the best.

Ask for help

We had the benefit of having a meet up behind us. We knew a lot of people we could ask to come and speak, we had an audience to sell to, and we'd already looked at countless venues, caterers, and vendors. But running a conference is very different to running a meetup So we asked for help. We got great advice from other conference organisers up and down the country. We asked them to tell us about the good, the bad, and the ugly parts of running a conference. We asked them about what worked for them, what didn't, and what they'd do different next time. Then we asked them to try and talk us out of it. Thankfully, they couldn't.

Get insured

Back in December, the venue we had booked for the conference pulled out. They told us that they were no-longer honoring any bookings made for 2018 and we had to find an alternative venue. If we hadn't found another venue, the whole conference would have had to have been cancelled.

Then in March, the beast-from-the-east hit the toon. This was a fairly big snow storm, which ground a lot of the North of England to a halt. It also meant we had to cancel our meetup for the first time ever. If the storm hit a month later, we would have had to cancel the conference.

There are a lot of reasons why a conference would need to be cancelled. Taking out cancellation insurance can ease the financial side of things should the worst-case happen. If we did have to cancel, we'd be covered for the costs involved in rescheduling.

Make a run-sheet

You spend a lot of time planning everything out for the conference, but on the day you're going to forget something. To combat this, we made a run sheet. Everyone had their own tasks to be completed at certain times. No only did this help us in knowing what we had to do, it helped us know what othe other organisers were doing. This way, everything that needed to be done got done, and no one did anything that someone else had already done.

Have fun

In an almost contradictory twist to my initial point, don't treat this like a job. We don't rely on the conference to put food on our tables. We don't take any money from it at all. We do it because we love it. This means we can make decisions based on what we'd like to see ourselves, and not what would make us money. We ran the conference in a brewery, hired out a bowling alley, and rented golf carts. Not because they would sell tickets, but because we could afford them and they were fun. The more money we made from ticket sales, the more fun things we added to the conference.

Thank you

I've no-doubt missed off a lot of things in this post. It's been a very hectic year and a lot of work has been put in by a lot of people.

I want to end with a thank you. Thank you to Anthony Sterling and Gavin Elliot for their sage advice in conference organisation. Thank you to Val Head, Léonie Watson, Jack Franklin, Niels Leeheer, Sarah Viera, Ian Feather, and Christian Heilman for being amazing speakers and wonderful people. Thanks to Nick Murphy and Kaspars Žarinovs for volunteering their time to us every month. Thank you to Bytemark, Tombola, Scott Logic, Sale Cycle, Accenture, and Sage for sponsoring the event. Thank you to all the staff at the Wylam Brewery and Lane 7 for being gracious hosts and keeping everything running behind the scenes.

Most important of all, thank you to all our attendees, and the Frontend NE community. You're the reason we put these events on and seeing you get value out of them makes all the blood, sweat, and tears worth it.

So, who's up for a sequel?

Deep Copy and the Immutability Issue

Mon, 26 Feb 2018 00:00:00 GMT

In the latest episode of, "I Have No Idea What I'm Doing" I learned that everything I thought I knew about immutability in Javascript was a lie.

Okay, so I'm being dramatic. Not everything was a lie. But a fundamental part of my understanding was incorrect. After speaking to a few people about the issue, it seems this was a shared misconception.

This all stems from a subtle, yet fundamental difference in how we copy objects in javascript. Deep copying and shallow copying.

Deep copying is what we want for true immutable data. It is a copy of all the values of an object, and all the values of all the objects within it. Shallow copying—on the other hand—is a copy of all the values of an object, with references to all the objects within it. This is what tripped me up.

To understand the problem, we need to look at three ways of copying objects.

Referencing

Okay, so let's strip this all the way back. Let's create a mutable reference to an object.

const initialObject = {
  name: "Sam",
  twitter: "@samdbeckham",
};
const newObject = initialObject;

This is bad for immutability because any changes to newObject reflect in initialObject like so:

newObject.twitter = "@frontendne";
console.log(initialObject.twitter); // @frontendne

In this example, newObject is a reference to initialObject . So whenever we get or set data on either of these objects it is also applied to the other object. This is useful in a lot of different ways, but not great for immutability.

Shallow copying

This is the most common form of copying data in an immutable manner. We utilise the spread operator to create a copy of initialObject . If you've used redux before, you'll have seen this inside your reducers.

const initialObject = {
  name: "Sam",
  twitter: "@samdbeckham",
};
const newObject = {
  ...initialObject,
};

It's a subtle change, but the ... makes all the difference. newObject is no-longer linked to initialObject . It's now a copy of the data and an entirely new object. So if we make the same change we did earlier, we get the following result:

newObject.twitter = "@frontendne";
console.log(initialObject.twitter); // @samdbeckham
console.log(newObject.twitter); // @frontendne

Modifying the data on newObject doesn't affect initialObject anymore. We can go about our day, modifying newObject and initialObject remains clean.

But this is a shallow copy, and the immutability is only one level deep. To show this, we need an object inside our initialObject :

const initialObject = {
  name: "Sam",
  social: {
    twitter: "@samdbeckham",
    youtube: "frontendne",
  },
};
const newObject = {
  ...initialObject,
};

At first glance, this newObject looks like an immutable copy of initialObject but look what happens when we do this:

newObject.social.twitter = "@frontendne";

console.log(initialObject.social.twitter); // @frontendne

Sadly, the immutability is only skin deep. As soon as we go down another level, we're back to referencing values. If we were to open up newObject , it would look a bit like this:

const newObject = {
  name: "Sam",
  social: initialObject.social,
};

We can get around this issue by shallow copying one level deeper and defining newObject like so:

const newObject = {
  ...initialObject,
  social: {
    ...initialObject.social,
  },
};

This is how it's usually dealt with in redux, but it only adds one more level of immutability. If there are any other nested objects they will still be stored as references. You can see how (with certain data structures) this could get messy.

_Note: Object.assign() and Object.freeze() have the same shallow copying issues as spread. _

Deep Copying

Finally, we get to deep copying. Deep copying offers us true object immutability. We can change any value in an object—no matter how deeply nested it is—and it won't mutate the data we copied it from.

const initialObject = {
  name: "Sam",
  social: {
    twitter: "@samdbeckham",
    youtube: "frontendne",
  },
};
const newObject = deepCopy(initialObject);

newObject.social.twitter = "@frontendne";

console.log(initialObject.social.twitter); // @samdbeckham
console.log(newObject.social.twitter); // @frontendne

Hooray! We're immutable!

Unfortunately, Javascript doesn't have a function called deepCopy() so we've had to make our own; and it isn't pretty. There's no "nice" way to handle deep copying in Javascript. Das Surma wrote a article on deep copy which has a few good examples, here are some of the simpler ones.

JSON

This is the most concise and easy to understand method, and it looks like this:

const deepCopy = (object) => JSON.parse(JSON.stringify(object));

First we turn the object into a JSON string with JSON.stringify() then we convert that string back into an object with JSON.parse() . Stringifying the data throws out all references, making the returned object completely immutable. But, if there are any references we need to keep inside this object, they're gone. If we have any maps, regex, dates, or other special types; they're gone. If we have any cyclic objects inside the object (which we shouldn't) the whole thing breaks and throws an error. So it's not very robust.

Data Laundering

If you don't want want to deal with the issues the JSON parser brings, there are a few—albeit hacky—methods you can can use. These all revolve around pasing our data to a service, then querying that service to pull our cleaned data back out. It's like money laundering, only with data, and nowhere near as cool.

For example, we can utilise the notification API:

const deepCopy = (object) =>
  new Notification("", {
    data: object,
    silent: true,
  }).data;

This triggers a notification, silences it, then returns the data from that notification. Unfortunately, the user needs to be able to receive notifications for this to work.

We can also utilise the history API and the messageChannel in similar ways. But they all have their downsides.

What do now?

Deep copying is a bit of a heavy-handed approach to immutability. Being aware of the gotchas of shallow copying should be enough to see you through most problems. You can use the nested spread method outlined above to fix any problem areas. If this approach is starting to get unwieldy, you should aim to improve your data structure first.

If you absolutely need deep copying, then fear not. There's an issue on the HTML spec that hopes to address this, with the introduction of structuredClone() . The more visibility this gets, the more likely it is to be implemented. Until then, I'd suggest using a library like Immutable.js to handle your immutability. Or grab the cloneDeep() helper from the underscore library for a quick-fix.

If you're up for a challenge, try coming up with your own solution to deepCopy. My friend Niall had a lot of fun playing with some ideas on Twitter. I'd be interested to see what you all come up with.

I Have No Idea What I'm Doing

Thu, 30 Nov 2017 00:00:00 GMT

Everything we have learned is something we knew nothing about at some point. We all have to start somewhere.

When learning a new technology I often look for a getting started guide, read some docs, or watch a talk by an expert. Then I'll start playing with some examples, maybe make a demo app, and slowly pull it into a production workflow. This is a great way to learn, I have no issues with it. However it's a very solitary practice.

Recently I joined a group of people in reading Eloquent JS. It's a book I'd been meaning to read for a long time, but hadn't gotten round to. Each week we would read a chapter (or two), then discuss it in a dedicated slack channel. We'd share examples, help each other out, and talk about our own understanding of the chapters. This was true collaborative learning. I haven't learned in this way since I was at university and I forgot how much I missed the social side of learning.

This got me thinking. What if we learned by watching other people learn? Instead of watching experts tell you how to do something. We get to see common mistakes people make and how they overcome them. We get to see the thought process behind a concept. We get to see that AHA! moment as something finally clicks into place and everything makes sense. We get to learn through the eyes of another learner.

Watch me learn

I have decided to share my learning experience with the world. I started using Vue quite recently and I want to learn more about it. Specifically, I want to learn all about VueX. I used Vue to build a website way back in the olden days of 2015 but it's come a long way since then.

Every fortnight I'll be publishing a new video documenting myself learning VueX and creating my very first app with it. Episode 0 is available now where I talk a little about what I'm doing and pour over the VueX documentation. The video quality is poor, the audio quality is worse, and my presentation skills are lacking. But none of that matters. Like everything, they'll all get better with practice.

So join me on my journey. Come watch me fail spectacularly, then re-write everything once I know the correct way to do it. Comment on where I'm going wrong so we can lift each other up and learn together. I'm going to hold my hand up and proudly say, "I have no idea what I'm doing, yet".

Starting a Meetup

Thu, 29 Jun 2017 00:00:00 GMT

Last week I attended the Web Community Leaders Summit (UK/IE) at the Google offices in London.

I was representing Frontend NE amongst community leaders from the UK and Ireland. We talked about our meetups, the issues we faced, and how we overcame those issues. It was a day of sharing and a great relief to hear that most of them had the same challenges we did in running a meetup. The day inspired me to write this post: A story of how Frontend NE began, where it ended up, and where we plan to take it next. With all our failures and successes along the way.

The Set-Up

An Englishman, an Irishman, and a Scotsman walked into a bar…

After a Tweet from Colin (who isn't actually Irish) we met up at the local Brew Dog and sat down over a few beers. We had a long discussion about meetups—and the lack thereof—in Newcastle. There were a few that had come and gone, but we wanted better. We wanted a consistent meetup for Front end developers, with great talks and a better community. Several beers later, we decided to start our own.

Later that night we registered a Mailchimp account and set up a newsletter signup on a holding page. Then tweeted it out so there was no going back.

Right from the start we knew consistency was key. The original plan was to have it bimonthly, but that got confusing. Bimonthly means both, twice a month, and once every two months. English can be a strange language. We changed it to monthly and checked tech diary for clashes with other meetups. The first Thursday of the month was our new date and we drilled that date into everyone's heads. It's right after pay day, it's easy to remember, and it falls on Star Wars day once every few years.

Armed with our new date, we booked a venue. Campus North hosted a lot of meetups in the past, so we approached them first. They allowed us to use their back room, provided we showed a slide of their sponsors during the event. We set a date for the first Thursday of the following month, April 2nd 2015.

All we had left, was to find a speaker. We set up a typeform survey as a make-shift call for speakers and sent it out to our growing mailing list. We pestered anyone and everyone that would listen, and put links to the CFP anywhere that would let us. Then we sat back and waited for the proposals to come in. We got a lot of submissions. Some of them were spam, some of them were nonsense, but the majority of them were potential candidates. This allowed us to create a backlog and start booking people in for the first few meetups. We wanted to book as far ahead as we could so it wouldn't fizzle out.

Somewhere along the way (I forget the chronology of all this) we found some sponsors. As with the rest of this process, we leaned on our friends to help us out. Jamie Hurst agreed to pick up the pizza tab, whilst Peacock Carter brought along some drinks. We could never have gotten started without the help of these people and are ever grateful to them.

We had a date, a venue, some sponsors, and speakers. Now we could get into promoting the event. We designed a logo, ordered stickers, extended the website, and set up tito so we could sell tickets for the event. Every opportunity we got to talk about the event, we seized. Partly to promote it, but also due to our own excitement. We had wanted something like this for a while now and there was a decent amount of interest for it.

The First Thursday in April

We announced that we would be releasing (free) tickets a week before our first event. The room we hired could only fit 30 people comfortably, so we made 30 tickets available. We hoped for 20 people, expected 15, and would have been happy with 10. The tickets released at 1:00pm on the 26th of March. When we checked back 2 hours later, they were all gone. Every single one.

30 people may not seem like a lot, but it was far more than we were expecting. We certainly didn't expect a sellout. People were tweeting us asking for more tickets to be released. We realized we were on to something. People wanted this almost as much as we did.

The venue would only allow us 50 people due to the fire regulations. So we released another 20 tickets the following day at 1pm. An hour later, they had all gone again.

We packed out the venue. I had to stand outside the door to fit people in. We had two great talks, which we recorded by propping up an iPhone, on a beer bottle, on a ladder, at the back of the room.

The quality is understandably terrible, but you can see both talks on our YouTube channel.

Speedy, Solid, Semantic layout; with Susy - Martin Underhill
CSS to SCSS - Rob Walker

Conclusion

In writing this post I went back through my archived notebooks (yes, I archive my notebooks). I then realized how much we put into starting this thing up. None of it seemed like hard work at the time because we had a genuine passion for what we were doing.

If I could give three pieces of advice for anyone wanting to start a meetup themselves, they would be this:

Be passionate, and find other passionate people to help you

If you're not that into this, it won't get done. It's hard to find the time (and motivation) for the event, so having more than one organizer is crucial. They're there to pick up your slack and keep you motivated. Just be sure to pick up theirs too.

Be consistent

This isn't always possible, but having a consistent date for your meetup is important. If people know when your event is without having to be told, you're on to a winner. It also helps with planning future meetups. We can book up events as far into the future as we like because we know when every event will be.

Plan ahead

When we started Frontend NE, we planned the first two meetups at the same time. We were going through the CFP anyway, so we contacted a few people and got all the booking out of the way there and then. Now we go a step further and book up several months in advance. We're currently booked up until 2018, with March and April's slots already filled. Now we can sit back, and not have to worry about whether we'll have speakers for the next event(s). Leaving us with more time to sort out the fun stuff.

There's still a lot more of this story to tell. Attracting bigger sponsors, the ever evolving video process, the loss of our venue, and much more. But I'll follow up on all that in another post(s).

Till next time!

Greased Lightning

Mon, 18 Jul 2016 00:00:00 GMT

There's something satisfying about tweaking and refining a product. Over the last few years, I've been making my blog progressively faster.

It's been more of a passive, than an active task. I just chip away at certain parts when I find a new technique, or I feel a part of the site needs improvement. I've FLIPped my animations to make them more performant. I've set smarter caching in my nginx config. I even minified my HTML (every little helps). But recently I made a change that took my load time from an already impressive 600ms, and halved it. To put that in perspective, it takes around 350ms to blink your eye. It loads that fast that if you blink, you'll miss it. This gets even more impressive when you throttle the connection. On a regular 2G connection my site would load in just under 2 seconds. That's not too bad, but after my most recent update I got that time down to 300ms. Yep, 300ms on even the slowest of internet connections. In fact, to go one further, it even loads when the connection is so slow, it doesn't exist. 300ms to load the site, when you're completely offline.

If you hadn't worked it out yet, I've just added a service worker to my site. As far as service workers go, this one is pretty simple. Once it's installed, it caches the most used files on the site; the JS, CSS, and index.html. If you then visit any of the articles, it caches them as well. This allows us to design for an offline first experience. Let me show you how it's done.

Setting the right environment

First off, in order to run the service worker, we need to add SSL certificates on our website. I used let's encrypt because it was free and I could get it up and running relatively quickly. There are lots of other ways to do it, choose whatever works best for you. As long as we have an SSL cert and can serve our site over https:// , we're golden.

If you're just running this locally, you don't need to worry about this step. I would recommend using Chrome Canary as (at the point of writing this) there's a lot more tools for debugging the service worker. You'll find them all under the 'Applications' tab in developer tools.

Installation

So, we've got our secure environment set up, we need to install our service worker. Let's create a simple javascript file that notifies us of it's presence.

console.log("Service worker, reporting for duty!");

Next up, we have to install the service worker. Just pop the following block into your main javascript file and be sure to update the path to your service worker.

if (navigator.serviceWorker) {
  navigator.serviceWorker.register("/path/to/serviceWorker.js", {
    scope: "/",
  });
}

Include this script somewhere on your page and it should find the service worker and install it. Notice we've wrapped the function in an if statement. This just checks the browser supports service workers before trying to install one. If the support isn't there, the service worker doesn't get installed and the website goes about it's day as if nothing happened. Progressive enhancement, done.

If this is all set up correctly, you should see a message from your service worker in the console. If you navigate to the application tab in developer tools you should see the service worker ticking away as well.

We've installed our service worker, but it doesn't do a great deal. Let's hook into the install event and start caching pages.

self.addEventListener("install", (event) => {
  event.waitUntil(
    caches
      .open("static-v3.5.1") // Namespaced on site version number
      .then((cache) =>
        cache.addAll([
          "/scripts/vendor/modernizr.js",
          "/scripts/main.js",
          "/css/screen.css",
          "/wrote",
        ])
      )
  );
});

Let's break this down. First off, we hook in to the install event. event.waitUntil() tells our service worker to wait until all the actions inside that function are completed before finishing the install process and moving into the installed state. The installation we wish to perform is to store all the pages we want to cache. caches.open('static-v3.5.1') opens a cache named static-v3.5.1 . Using promises, and .then() I added my css, js and a couple of key pages to the newly opened cache.

That's the installation process done. Like any other installation process, it only has to be done once. If we reload this page, this process gets skipped as we'll already have all our files in the cache. This is where we run into our first problem, cache invalidation.

There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton

The plan for this service worker is to serve the files from the cache, instead of requesting them from the server. We haven't told it to do that yet, but it creates a problem that is best fixed early on. Let's say we update our site's CSS file. When we refresh the page, the service worker kicks in and loads the cached CSS file, which is now out of date. Bugger.

Luckily, Chrome has us covered. Just jump back into the service workers tab we were in earlier and hit, [] update on reload . This will cause Chrome to reload the service worker and re-install itself when you refresh the page, bringing the updated files into the cache. However, we can't set this flag on our users' browsers. This is why I used the version number of my site when I created the cache. Because I use semver, I can be sure that any releases to my site will have a different version number, and therefore a different service worker cache. When I update the site, you initially see the old one whilst the new one installs in the background. Then the next time you load the site, the new one is all ready and waiting in the new cache for you. This does mean we need to do a little housekeeping, but we'll get to that later. Back to the good stuff!

Request hijacking

The service worker is installed, the files are cached, our service worker is primed and ready. This is where the real magic of the service worker comes in to play. Normally, when a browser requests a file it goes straight off to the server. The server hears the request, finds the requested file, and sends it back to the browser. With a service worker, you can intercept this request.

self.addEventListener("fetch", (event) => {
  event
    .respondWith
    // Response goes here...
    ();
});

We start off by listening for the fetch event, then we hijack the response with event.respondWith() . At this point we could return anything and the browser will act as if the request went through as normal. Want to listen for all the image requests and swap them out with pictures of Nick Cage? You can. However, we need something more practical.

event.respondWith(
  caches
    .match(event.request)
    .then((response) => response || fetch(event.request))
);

caches.match(event.request) goes and checks our cache for the page that's being requested. If the cache has our page, response becomes truthy and we serve up the page from the cache. If the page isn't in the cache, response is falsy and we return the original fetch event for the page. This line may look a little confusing, but it's really just shorthand for:

.then(function(response) {
    if (response) {
        return response
    } else {
        return fetch(event.request)
    }
})

If all goes well, we should be successfully serving our pages from the cache. This is the key to making our site blazing fast on even the spottiest of connections.

Cleaning house

We tackled the majority of the caching issues earlier, but you'll soon notice a problem. After a while our caches start building up. We'll have the current version's cache, but we'll also have a load of obsolete caches from previous versions. We never access them, so it's only right we clean them up. It's rumoured that this is a feature that will be coming to service workers in the future, but for now we can do it ourselves:

const currentCache = "static-v3.5.1";

self.addEventListener("activate", (event) => {
  event.waitUntil(
    caches.keys().then((cacheNames) => {
      return Promise.all(
        cacheNames.map((cacheName) => {
          if (currentCache !== cacheName) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

This is mostly taken from Jake Archibald so all credit goes to him for this one. In fact, I'm pretty sure we can credit the majority of the service worker spec to him. If you wanna look into service workers, look into Jake.

Optional extras

This is all you need to get started with service workers, but there's a lot more you could do. I've added a few optional extras to my service worker, feel free to take a look at it. These work really well with a good manifest file and are the backbone of the progressive web app movement. As ever, have a play about with them and see what you can do.

A Sprinkling of Web Components

Thu, 30 Jun 2016 00:00:00 GMT

At UpFront mini last year, I spoke about sprinkling in Web components. It's a technique I used myself recently so I thought I'd share my experience with you.

If you missed my last post, I have recently started working at Bytemark. We're making a big hiring push at the moment and we needed an unobtrusive way to shout about this on our website(s). We toyed with a few ideas, but ultimately decided on adding a small, dismissible notification. I could have written my own markup, styled it with some CSS, added some javascript to trigger and hide the notification, test everything, compile, build. I could do that, but it's a lot of effort, and we developers are intrinsically lazy.

An off-the-shelf solution was what I wanted. Something robust, pre-tested and easy to modify. Web components were that solution. More specifically the <paper-toast /> element. It ticked all the boxes and it was a good excuse to start using web components in a production environment.

Adding it in

Thanks to html imports, adding in this web component was really easy. It's a three step process, with an optional fourth step. Download, import, use, and customise.

Step 1

The first thing we need to do is get the component. Polymer uses bower to serve it's components. It's not the most elegant solution, but it does the job. Fire up your console and run:

bower install --save PolymerElements/paper-toast

Step 2

Now we have the component in our repo, it's time to include it on the page. The <paper-toast /> element has a few dependencies, including polymer itself, but we don't need to worry about them. Thanks to the wonders of html imports, we just need to import the element.

If we want it to work in more than Chrome and Firefox, we need to include a polyfill. This polyfill gets installed automatically when we install the <paper-toast /> element. We just need to pull it into the head, above the html import for the element. Boom, browser support (kind of).

<script src="bower_components/webcomponentsjs/webcomponents-lite.min.js"></script>
<link rel="import" href="bower_components/paper-toast/paper-toast.html" />

Step 3

The element is in the repo, it's included on the page; it's time to use it. For one last time, here's our one liner. Blink, and you'll miss it.

<paper-toast id="careersNotification" text="We're hiring!" opened></paper-toast>

Okay, so it's in there, but it's not very helpful. Lets take the text out of the attribute and drop in some html:

<paper-toast id="careersNotification" opened>
  We're hiring, visit our
  <a href="http://careers.bytemark.co.uk">careers page</a> to find out more.
</paper-toast>

Step 4 (optional)

We've now done everything you need to get that notification showing up on the page. But what if we want to change the behaviour? Luckily, polymer and web components make this easy too. In our case, we wanted the element to be persistent and dismissible. Easy peasy.

<paper-toast id="careersNotification" duration="0" opened>
  We're hiring, visit our
  <a href="http://careers.bytemark.co.uk">careers page</a> to find out more.
  <a href="#" onclick="careersNotification.toggle()">close</a>
</paper-toast>

All we did was add a duration="0" attribute to cancel the timeout and keep the notification on the page. Then we added a link (though this could be any element). We gave the link a click handler that calls, careersNotification.toggle() . Which, unsurprisingly, toggles the notification.

There's a whole lot more you can do with this element. Just take a look at the docs to find out more.

Progressive enhancement

A lot of people worry about web components and progressive enhancement. But, the way I see it, this is a progressive enhancement. We have a website that works great without web components. If you're using a browser that can run them, you get a nice notification. If you're not, you simply don't get the notification. No harm done. This is a textbook progressive enhancement. Jeremy would be proud.

Playing with Polymer

Want to have a play about with some polymer elements yourself? Take a look at the Polymer element catalogue and start pulling something together. If it's not for a production app and you don't want all the hassle that goes with bower, then take a look at polygit. Just don't use polygit for production. You have been warned.

Changing Lanes

Wed, 01 Jun 2016 00:00:00 GMT

Throughout my professional career I’ve worked for agencies. I’ve been an employee, a contractor, and a freelancer. But always for an agency.

I’ve always felt like I’m doing someone else’s work. There’s a, “Push it out the door” feeling with agency work. It’s hard to have a sense of ownership and pride over what you do at an agency. It’s always someone else’s baby, you’re just the nanny.

What these projects usually lacked, was retrospect. It was rare that I got to look at a project I’d shipped and think, “How can I improve this?”. As a result, we skimmed over some important things. Performance optimisation, extensive testing, documentation, etc. It’s not that they weren’t there, they were just underdeveloped. In an ideal world, I could take it upon myself to look into these things, but in reality there wasn’t the budget.

So, almost a decade down the line, it’s time to move on. It’s time to move away from the agency model. It’s time to stop throwing things over the wall and forgetting about them. It’s time to move onto a different chapter and start looking at making stuff I can be proud of again.

Now I am a front end engineer at Bytemark. I am part of a team that will allow me to continually improve upon the Bytemark suite. I can look at performance. I can look at code readability. I can look at better testing. I can start fine-tuning everything I do. I’m excited about this new move; and look forward to creating awesome things, with an awesome bunch of people.

Automation

Fri, 02 Oct 2015 00:00:00 GMT

For years I’ve been fascinated by automation. Why waste time doing menial tasks when you can program a machine to do them for you?

My love for automation began, not with code, but with factory machinery. I would spend hours watching, 'How it’s made' on the Discovery Channel. In awe of machines crafting everyday items that are often taken for granted. Things like, springs, toothbrushes or pasta. I loved how, by running a series of simple tasks, complex objects could be created with ease. Now I port the same principals into my development workflow.

I automate everything I can; the creation of projects with yeoman, deploying websites with git hooks, even the setup of my Mac. Anything I’m going to do more than a few times, I automate.

Let’s take this website as an example. The first thing I automated was the cloning my Jekyll boilerplate with Yeoman, adding git-flow in the process. This includes a handful of grunt tasks that; compile and auto-prefix my (s)css, sprite my SVGs, lint my javascript, compile my blog with Jekyll, run a local development server, and watch that server for changes. This allows me to develop the site without having to worry about running all these tasks myself. I just type grunt in the command line and it all gets taken care of. It even reloads the page for me across any devices that are currently on the site.

When I’m ready to deploy, I start a release branch on git flow, run grunt build (which minifies, compresses and optimises the site) then push everything up to the repo. I have a deploy script running on my server that picks up that release and pulls the repo down automatically. I don’t even need to SSH into my server. I just push to my repo and my code takes care of the rest.

Using this type of automation not only saves time, but eliminates a lot of mistakes. When I automate things I put tests in place for that help me catch any errors before they go anywhere near production.

Give a man a fish and he’ll eat for a day; teach a man to fish and he’ll eat for a lifetime; automate the fishing process and you’ll feed the world.

Public Speaking is Scary

Fri, 02 Oct 2015 00:00:00 GMT

Alongside spiders, heights, and clowns; public speaking is one of the most common fears. The official term for it is Glossophobia, and it’s ranked as the 13th most common fear in the world. Which is even worse news if you’re triskaidekaphobic.

This fear is one that I share myself. I am petrified of public speaking. The idea of standing up in a room full of my peers and sharing my thoughts, terrifies me. At least, it used to.

At the beginning of 2015 I decided to face my fears. I wrote a talk proposal and sent it off to any and every event that would take it. I heard nothing but rejections for months. Then — in April — I was invited to give my talk at Scotland JS. I couldn’t believe it. Someone actually wanted to hear what I had to say. I was still nervous. But I consoled myself with the idea that it was only going to be in front of a handful of JS developers. Scotland JS sounded like the perfect little meet up to cut my public speaking teeth on. Unfortunately I had myself confused with Edinburgh JS. Scotland JS was not a small meet up. It was a two day conference. With over 300 attendees. Fuck.

But I’m not a quitter. I came close to telling them that I’d made a huge mistake and I had no idea what I was doing. But I wanted to be speaking at conferences eventually, why not jump in the deep end and see what happens?

Writing the talk

I spent the next few weeks researching. Not only the topic of my talk, but public speaking in general. I did an introduction to public speaking course on edX. I followed Zach Holman’s brilliant series of posts and videos on Speaking.io. I watched endless hours of my favourite speakers, taking notes on their styles and techniques. I wanted to be ready. I wanted to be more prepared than anyone had ever been for anything.

It was roughly a week till the conference and I felt good. I’d gathered enough knowledge to feel I could really take a run at this and come through on top. The only thing left to do now was write the actual presentation. I had the outline, I knew what I wanted to say. I just needed the slides. So I opened up Keynote and got to work. Six hours later and I had finished. The title slide. This was going to be harder than I thought.

I slept on it and asked around the next day for advice. It was around this time I stumbled across Slides. I had no idea Keynote was so bad till I started using Slides. I set up some templates, ported over some key phrases from my outline, and had a basic slide deck in a couple of hours. It used HTML, CSS and Javascript to create the presentation. As a front end developer, I felt right at home.

I also made the decision to avoid live coding entirely. Live coding is the soufflé of the developer world. Unless you’re a grand-master, don’t even try it. If something’s going to go wrong with your talk, it’s live coding.

A short while later my slides were done. I’d injected a little humour, sprinkled in some gifs, and managed to avoid live coding. All I had left to do was practice. I recommend getting screen flow and recording yourself running through your talk. It’s a little unnerving at first but it really helps you see how you come across to your audience. It’s also a lot easier to see if anything is confusing or falls a little flat when you watch it back. I found this to be an invaluable step in the whole process.

Game day

Let’s skip ahead to the day of the talk. As I walked in to the event, another fear of mine struck me; being in a room full of people I didn’t know. I stood nervously next to the biscuits, with a coffee in one hand and my phone in the other. I was doing that thing where you pretend to be texting. But really you’re just scrolling through your phone settings, trying to look busy. Then Peter (the event organiser) came up to introduce himself. He got me set up on stage, introduced me to the event team, and really settled my nerves. Cheers Peter, you’re a top bloke.

Here goes nothing…

It’s time. I’m set up at the side of the stage. 300 faces are staring back at me. The compare introduces me and I walk on to applause. I take a sip of water and begin, “Hello, my name is Sam Beckham and I’m here to talk about Polymer. ”

All my practicing had paid off. It felt like being back behind my drum kit in my gigging days. Going through the pre-rehearsed motions, knowing exactly what was coming and what I had to do. It didn’t matter whether there were 300 people or 3, 000 people. I just gave them the same performance I gave my webcam in the practice runs. I was facing my fear and loving every minute of it.

I’d like to thank the organisers of Scotland JS for giving me a chance to overcome my fear. They put on a wonderful conference and made me feel welcomed in Edinburgh. You can see all the talks from the event on Youtube.

If you want to get into public speaking yourself. Have a look on _speaking.io. _ There’s some awesome resources, tips and ideas on there to get you started. If you’re looking for somewhere to speak, have a look on Lanyard’s call for speakers page. I also run an event in Newcastle called Frontend NE. We’re always looking for people to share their experiences. Please, submit a proposal and overcome your fear. It’s not that scary once you’re up there.

CSS Parallax Effect

Tue, 17 Feb 2015 00:00:00 GMT

I recently discovered that one of my pens on CodePen is one of the most hearted pens of 2014. I'm stunned.

This is the pen in question: Firewatch parallax in CSS. Scroll inside the pen to see the effect.

Full disclosure: I did not design or illustrate any of this. If you haven't seen it already, this is a remake of the beautifully illustrated Firewatch website. I wanted to see if I could do parallax with just CSS and this is the best designed parallax effect I’ve seen on a website.

How it works

Parallax gets mis-labelled a lot in web design. Often, anything that moves as you scroll through a site gets called parallax. But that's not what it means. It's an effect that you probably see every day in the real-world and, when used correctly, can add a nice sense of depth to a website. The definition of parallax is:

The effect whereby the position or direction of an object appears to differ when viewed from different positions, e. g. through the viewfinder and the lens of a camera.

This gif by Trent Walton, illustrates the effect quite well.

In my pen, I used CSS3d transforms to give the scene some depth. When combined with some perspective you can get some really nice results.

How it's made

The pen has six layers, but for clarity we'll run through an example with three. We start off with our wrapper, or stage. Inside that stage we have our layers, one element for each.

<div class="parallax__stage">
  <div class="parallax__layer parallax__layer--0"></div>
  <div class="parallax__layer parallax__layer--1"></div>
  <div class="parallax__layer parallax__layer--2"></div>
</div>

That's essentially it for the HTML. We could add images inside them divs, but we'll keep it simple. Now, on to the CSS.

We want the stage to fill the viewport and we want each layer to be the same size as the frame. That's pretty easy.

.parallax__stage {
  height: 100vh;
  left: 0;
  overflow: auto;
  position: absolute;
  top: 0;
  width: 100%;
}

.parallax__layer {
  bottom: 0;
  height: 100%;
  left: 0;
  position: absolute;
  right: 0;
  top: 0;
  width: 100%;
}

Now that we've set the stage, we need to add our (p)layers. This is where the math comes in to play. We could use standard CSS here, but mixins make it much easier and extendable.

$parallax__layers: 3;
$parallax__amount: 1;

@for $i from 0 through $parallax__layers {
  $distance: -$parallax__amount * ($parallax__layers - $i);
  .parallax__layer--#{$i} {
    background-color: rgba(0, 0, 0, (1 + $i) / 10);
    transform: translateZ($distance#{px});
  }
}

This mixin loops through each modifier and pushes it back in the z-axis. The $distance variable determines the distance each layer goes back. I've also modified the color on each one so we can see them clearer later.

If all you can see at the moment is a screen full of gray nothing; don't adjust your set, that's what we're expecting to see. Let's add a little perspective.

.parallax__stage {
  perspective: 1;
}

And there it is, 100% CSS parallax. Well, not quite. You won't be able to scroll yet because there's nowhere to scroll to. Just add in an element below the stage and give it the following properties.

.content {
  background: rgba(0, 0, 0, 0.8);
  margin-top: 100vh;
  min-height: 100vh; // to make up for the lack of content
  position: relative;
  width: 100%;
}

Now you can scroll away and get all that parallax loveliness.

I've made a pen of this example so you can play about, fork it and create your own version. I really do like CodePen.

Differences

There are a few differences with the example and the Firewatch pen. Mainly, the Firewatch images I used were all the same size so I had to do some maths trickery to scale them back up. It's just an modification of the mixin we used to push them back in the z-axis.

@for $i from 0 through $parallax__layers {
  $distance: ($parallax__layers - $i) / 2;
  .parallax__layer--#{$i} {
    transform: translateZ(-100 * $distance#{px}) scale($distance + 1);
  }
}

I also did some re-positioning of the images, and placed a cover over the top, to stop the elements peeking through each other. It's all pretty straight forward though, and you can look at all the code on the pen, so I'll leave that as an excersise to the reader.

Don't fear the command line

Sun, 02 Mar 2014 00:00:00 GMT

Every developer fears the command line at first. It’s bleak, un-familiar and has the power to erase your entire hard drive with a few mis-placed keystrokes. I myself felt the same way until a year or two ago, until I dove in head-first. With a little help and guidance, my day-to-day now looks like a scene from the Matrix; and I’m completely comfortable with that.

Over the years, I’ve integrated it more and more into my workflow. I use it for committing code with git; I use it to compile, minify and test my code with grunt; I use it to set up my server; I even use it to install my applications. I’m trying to transition into using VIM as my go-to editor, but Sublime text is just far too lovely so I’m sticking with that for now.

This isn’t a how-to, there are already plenty of them around. It’s just a gentle nudge to tell you that the command line isn’t as scary as you might think. Once you get used to the power the command line gives you, you’ll wonder how you ever developed without it. Don’t fear the unknown, embrace it.

Useful links

A great getting started guide from the folks at Treehouse Introduction to the command line
A Fun way to learn VIM - VIM adventures
A hands-on workshop from the brilliant Harry Roberts - The command line for beginners
Like buzzfeed, if it were for nerds - 40 terminal tips and tricks…

Generated Backgrounds With SVG

Wed, 15 Jan 2014 00:00:00 GMT

Just before Christmas I decided to have a play about with SVG on Codepen. It got quite a lot of attention and I was asked to write a post detailing the process; here is that post.

This idea was born because I needed a way to generate isometric backgrounds on-the-fly with a set colour palette. I decided the best way to do it would be to use a formula that would write some SVG code and apply it to the background of an element. The problem was, I’d never used SVG before and I had no idea what I was doing.

Polka dots

I decided to start small and get the basics down first. If I could get something simple generated in SVG first then I could move onto writing the formula that would generate my shapes. I created a random polka dot generator that was surprisingly simple.

I've outlined a - simplified - breakdown of that code below.

var width = (dotSize + dotPadding) * dotsWide,
  height = (dotSize + dotPadding) * dotsHigh,
  radius = dotSize / 2,
  background =
    "<svg xmlns='http://www.w3.org/2000/svg' width='" +
    width +
    "' height='" +
    height +
    "'>",
  color = "#09c",
  x,
  y;

First I define the variables I’m going to use and generate the opening tag for the SVG (assigned to the background variable).

for (x = radius; x < width; x += dotSize + dotPadding) {
  for (y = radius; y < height; y += dotSize + dotPadding) {
    background +=
      "<circle fill='" +
      color +
      "' cx='" +
      x +
      "' cy='" +
      y +
      "' r='" +
      radius +
      "'/>";
  }
}

Then I loop through each circle/dot in the image and append the SVG code to generate it to the background variable.

background += "</svg>";

Once each dot has been added, we close the SVG tag.

var b64 = "data:image/svg+xml;base64," + window.btoa(background),
  url = 'url("' + b64 + '")';
$("html").css("backgroundImage", url);

Finally I base64 encode the image before applying it to the background as a Data URI.

Isometric grid

The polka dot demo proved to me that I could do this. All I had to do now was write the part that generated my isometric triangles. There’s a few ways to do this but I found this way to be the simplest.

My plan was to generate this bow-tie shape and fill it with a random colour, chosen from a pre-defined array. I would then repeat this shape so it tessellates. The problem I encountered with this approach is that they didn't stack correctly, and I had with a line of diamond-shaped gaps.

for (i = 0; i <= settings.trianglesWide; i += 1) {
  for (j = 0; j <= settings.trianglesHigh; j += 1) {
    v = i * settings.triangleSize * settings.skew;
    w = j * settings.triangleSize;
    x = v + settings.triangleSize * settings.skew;
    y = w + settings.triangleSize;
    a = v + "," + w;
    b = x + "," + w;
    c = (v + x) / 2 + "," + (w + y) / 2;
    d = v + "," + y;
    e = x + "," + y;

    background +=
      "<polygon fill='" +
      getColor() +
      "' fill-opacity='" +
      settings.opacity +
      "' points='" +
      a +
      " " +
      c +
      " " +
      d +
      " " +
      "' />";
    background +=
      "<polygon fill='" +
      getColor() +
      "' fill-opacity='" +
      settings.opacity +
      "' points='" +
      b +
      " " +
      c +
      " " +
      e +
      " " +
      "' />";
  }
}

Gives you…

As you can see, the bow-ties don’t line up quite right but this is fixable. What we need to do is offset every second row by moving it up and along by 50%. I decided to utilise the modulo operation (j % 1) to differentiate between even and odd rows. This operation will return a 0 when the number is even and a 1 when it’s odd.

for (i = -1; i <= trianglesWide; i += 1) {
  for (j = -0.5; j <= trianglesHigh; j += 0.5) {
    v = (i + (j % 1)) * triangleSize * skew;
    w = j * triangleSize;
    x = v + triangleSize * skew;
    y = w + triangleSize;
    a = v + "," + w;
    b = x + "," + w;
    c = (v + x) / 2 + "," + (w + y) / 2;
    d = v + "," + y;
    e = x + "," + y;

    background +=
      "<polygon fill='" +
      getColor() +
      "' fill-opacity='" +
      opacity +
      "' points='" +
      a +
      " " +
      c +
      " " +
      d +
      " " +
      "' />";
    background +=
      "<polygon fill='" +
      getColor() +
      "' fill-opacity='" +
      opacity +
      "' points='" +
      b +
      " " +
      c +
      " " +
      e +
      " " +
      "' />";
  }
}

Adding this in allows us to offset the v coordinate by 1 on every second row which pushes that row along to the correct point.

You might notice that instead of starting the for loops at 0 I start them at −1 and −0. 5 respectively. This is to make sure the pattern starts outside the bounding box so we don’t get jagged edges.

Colours

Another big part of what I wanted to do here was to use random colours from a selected palette. To do this I wrote a simple getColor() function.

var colors = ["red", "blue", "green"],
  getColor = function() {
    var hex = colors[Math.floor(Math.random() * colors.length)];
    return hex;
  };

This shouldn’t need too much of an explanation, it returns a random entry from the colours array when it’s called.

Plugin

Whilst this is not intended to be a jQuery plugin, I wrote it in that manner to allow me to generate several different backgrounds. Have a play about with the settings at the top of the page or check out the demo on Codepen to see just how versatile this can be.

Public APIs

Wed, 20 Mar 2013 00:00:00 GMT

Millions of people share their photos, thoughts and data online - and now we can access it easily with public APIs.

A brief introduction

If you've ever used a Twitter widget to display Tweets on a website - like most developers have - then you've already used an API. An API (Application Programming Interface) is a way for programs to communicate with each other, generally using simple request and response messages.

In the case of the common RESTful web API it’s as simple as sending a http response, eg.

http://api.flickr.com/services/rest/?method=flickr.photos.getRecent&api_key=b5b0a30288a8cc21468d22e22c3255ac&format=rest

This will return a JSON file that we can pull information from and use on our website or app.

4 pics 1 word

In the example at the top of this article, I have used the Instagram API to pull in four images tagged with a pre-defined keyword. That keyword then becomes the answer to the puzzle - much like the 4 pics 1 word app that's doing the rounds at the moment.

This is an example of what can be achieved quite quickly with an API. You get a fully functioning app without the headache of having to source and store the data yourself. You can have a look at the code on GitHub.

OAuth and request limits

Nothing good ever comes easy. When Twitter first launched their API in 2006 it only required basic authentication to access an unlimited amount of data. Three years later they brought in a 20, 000 requests-per-hour limit on that data and have continued to throttle it ever since. Today that limit stands at a mere 150 unauthorised requests per-hour and will very shortly need Twitter’s OAuth service to make any requests at all.

OAuth is a bit of a headache at first - especially for us front end devs - but luckily there's plenty of help out there to get you started. If you are writing a new app or widget that uses the Twitter API - then I suggest going straight for the OAuth approach with API 1. 1 because its going to be a huge pain in the ass when the big switchover happens in June.

Web Wars

Fri, 04 May 2012 00:00:00 GMT

A long time ago in a galaxy far, far away…

If you wanted interactivity on a website that went beyond scrolling marquees, blinking text and hover states - you had to use Flash. However, Flash was not without its faults.

A New hope

Now there are a number of alternatives to Flash. HTML5 is the latest to step up to the plate.

The HTML5 Vs Flash debate has gone on for some time now. A web search for “HTML5 vs Flash” will bring up thousands of results, some in favour of Flash and some for HTML5.

A lot of people fear the arrival of HTML5, but fear is the path to the dark side. We should embrace new technologies. HTML5 has a very good community that will happily help you out. I believe sharing our knowledge is a wonderful thing and is the key to moving the web forward.

Of course nothing is perfect - HTML5 has its faults as well. But it is still in its infancy and will continue to grow.

The Empire Strike back

In April 2010 Adobe were dealt a large blow to their battle for web supremacy, as tech giants Apple announced that their mobile operating system wouldn't support Flash and would instead favour HTML5. Since that announcement the iPhone user base has grown exponentially and the iPad - using a similar OS - has dominated the tablet market. That means a lot of people can't use Flash on-the-go.

Web developers have realised this and have started to move away from Flash in favour of HTML5. Flash may still be used on around half of the world's top websites but this figure is dropping quickly.

Return of the Jedi

There are still a lot of developers that favour Flash. They know it works and it can still do a lot of things that HTML5 can't, yet.

If you've only used Flash I would suggest learning HTML5 as soon as you can, as Flash may not be around forever. As a great Jedi once said, "Always in motion is the future. "

Super Mario

Wed, 04 Apr 2012 00:00:00 GMT

I like Super Mario and I love CSS3 - so I decided to create an experiment that combined the two.

The Cicada Principle

The Cicada principle was coined by Alex Walker after being inspired by a documentary on the Cicada. I won't go into all the details as everything is covered in the original article - which is definitely worth reading.

The basis of this principle uses prime numbers - along with the new multiple backgrounds feature in CSS. By using image sizes based on prime numbers (3, 5, 7, etc) they don't repeat in sequence and create an - almost - infinitely large image.

At the top of this page I have used 6 images with widths of; 16px, 208px, 272px, 304px, 368px and 496px. All of these numbers are multiples of 16 and a prime number. This creates a tiled background that's exactly 5. 023x10^13px wide.

With only 33kb worth of images that's quite a feat!

Browser support

As you can tell if you're viewing this page in an older browser - the support isn't the best. This will however continue to improve.

If you are having trouble viewing this page, I recommend downloading Chrome or Firefox.