Alex Lakatos - JavaScript, DevTools & DevRel

Don’t be THAT guy

Fri, 28 May 2021 09:00:00 +0000

A little while ago, whitep4nth3r reached out on Twitter asking for support from men for a better future. I didn’t know why, but I signed up head first, because who wouldn’t want a better future?

I didn’t know what sparked the plea, but I could have guessed. Men being assholes, live on stream. I was watching her stream again today, when “THAT guy” striked again. Somehow, a dude thought it would be acceptable to compliment someone based on looks. I was stunned. My first response was eaten away by the obscenity filter in the chat.

I hate the fact that I live in a world where this needs to be said. And we’re all part of the problem! Because we don’t say it often enough - “Don’t be THAT fucking guy!”.

You know exactly what I’m talking about.

Not the kind of connection request I was looking to get on LinkedIn pic.twitter.com/Kxww7LZqTN
— Emma Bostian 🐞 (@EmmaBostian) June 21, 2020

THAT guy that’s going to “slide into your DMs”. Social media networks are not dating apps! If there were no dating apps left in this world, it still wouldn’t be OK to make unwanted advances in there. Or send dick pics. Tech isn’t there to enable you to be a bigger sleazeball.

Me: what he said was so sexist and racist

WM: it was so sexist

Me: and racist

WM: it’s misogyny

Me: and racism

WM: I didn’t see racism

Me: exactly bc if you saw it you wouldn’t be the star victim and are avoiding your own role and implication in these systems

WM: *cries*
— Tatiana Mac (@TatianaTMac) May 6, 2021

THAT “I’m not a racist” guy. The moment you spew some shit and then try to defend it with “I’m not a racist”, you are. Just don’t spew that shit. Forget about making excuses. No excuses are needed if you really weren’t making a racist comment.

it's wild to me how guys with 'learning how to code' in their bio get treated like experts and i get python 101 resources sent to me lol
— Ali Spittel 🐞 (@ASpittel) May 6, 2021

THAT guy that thinks only other dudes can code. I swear everyone has this thing called a brain. And I’m 100% sure brainpower is in no way connected to gender. Programming uses your brain but is also not a skill that in any way relates to gender. So why would you keep on assuming only other “dudes” can code better than neanderthals like you?

The list goes on, and there are so many instances of “THAT guy”. The post is triggering enough as it is. It burns my soul to write about all the shitty things “dudes” online do because they hide behind anonymity. Let’s all agree right here and now that if you wouldn’t say it in person, in front of a room full of people, just don’t say it online. FFS!

There is absolutely no context, online or not, where it’s OK to be abusive, misogynistic, racist or in any other way disrespectful to another human being! No, not even if it’s “a joke”. Seriously!

And even if you’ve read all this and think to yourself: “I wasn’t any of those guys”. Were you actually respectful? I know I’m not always respectful. So I pledge to do better, right here, right now! How about you?

We’ve all seen “THAT guy” regularly, you might even know that guy, but we somehow convince ourselves to not say anything. Because it’s uncomfortable. Or because we’ve convinced ourselves that it doesn’t really affect us. But it affects “someone”. It affects someone quite a lot! If you saw anyone being treated this way on the street next to you, you’d speak up, right? So why is it OK if it happens online? If the past year taught us anything, it’s that more and more of our life happens online.

Let’s all treat online with the same standards, especially when it comes to harassment, bullying and discrimination. I understand confrontation is hard. But reporting or education work just as well as confrontation.

If you’re “THAT guy”, but somehow you didn’t want to take my word for it, check out https://unbreak.tech/. There’s a lot of other people that would like to have a word with you!

How to Disable Notification Requests in Modern Browsers

Fri, 21 May 2021 00:00:00 +0000

I absolutely hate it when web pages ask me for permission to send notifications. Most often, the same web pages ask me for an email as well. That’s incredibly spammy. I understand their “Marketing” department is struggling, but this really isn’t the way to go. Browser notifications are all kinds of spammy, the same way push notifications on the phone are.

I’ve been ignoring the requests for the most part, but inevitably a few of them made it through. A lot of these spammy websites are using dark patterns in terms of where the buttons are placed. I inadvertently clicked in the wrong place at the wrong time. You’d think it wasn’t that big of a problem. Still, with me using 4 different browsers consistently (because I’m comparing their Developer Tools for a course), it did mean I now have multiple notifications for the same website popping up.

Well, I’ve had enough! I spent a little time figuring out how to block modern browsers from sending notification requests. And I thought I’d eventually need to block them again, so I should document the process. If it happens to be helpful to someone else, that’s even better.

Google Chrome

Go to chrome://settings/content/notifications
Disable Sites can ask to send notifications

Chrome has a softer option to use quieter messaging. It blocks notification prompts from interrupting you, but I haven’t been brave enough to try it. Let me know if you use it.

Mozilla Firefox

Go to about:preferences#privacy
Scroll to the Permissions section
Click on the Notifications Settings
Check the Block new requests asking to allow notifications box

Microsoft Edge

Go to edge://settings/content/notifications
Disable Ask before sending

Edge has a softer option to use quiet notification requests. It prevents notification requests from interrupting you, but I haven’t been brave enough to try it. Let me know if you use it.

Safari

Select Preferences in the Menu bar
Click on the Websites tab
Scroll to Notifications
Deselect Allow websites to ask for permission to send notifications

Brave

Go to brave://settings/content/notifications
Disable Sites can ask to send notifications

Brave has a softer option to use quieter messaging. It blocks notification prompts from interrupting you, but I haven’t been “brave” enough to try it. Let me know if you use it.

Have you found this article at all useful? If you did, follow me on Twitter. It would make my day! Oh, that’s where I also regularly share tips and tricks for getting the most out of your browsers 😅.

The Accidental Public Speaker or How I Got Over My Fear of Public Speaking

Fri, 14 May 2021 00:00:00 +0000

I’ve given over a hundred talks in the past few years. Why? Because I think it’s perfectly OK for me to be terrified, but it’s not OK for me to stay that way. My biggest fear? Same as you, same as everybody else. I was afraid to speak in front of people. A hundred talks later, I’m still terrified every time I go on stage. How did I ever get on stage, though? Well, here’s a little trip down memory lane, the series of unfortunate events that got me up on stage. I entirely blame Ioana and Marcela for this btw, if you want the tl;dr. 😅

Why did I do over a hundred talks, you might ask? Well, I do a bunch of things in this world. In my free time, I’m a Mozilla Tech Speaker. I also volunteer for the Mozilla Reps program, and I’m a Mentor in that program. Both of those programs are geared towards speaking to tech audiences and building communities. But I do like the idea of a paycheck and getting paid, so I work for Fidel as a Developer Relations Manager. And speaking in public is part of the job. I know, I must be a masochist. There’s no other explanation. 🤦

With Mozilla or work, I’ve met a lot of great people, Developer Advocates, Community Builders, and Developers getting over their fear of speaking so they could share their knowledge. Because there is not a lot to do in the “Speakers Room” at conferences, and because misery loves company, the question I always asked was: “How did you get here”. Everybody I’ve asked has a different origin story. There’s no common denominator, really. I will tell you a bit of my story, how I started out.

It all started about 10 years ago, there was an event called Open Source Open Mind in Romania, and I was working for Mozilla at the time. They asked our team to talk about Mozilla. Still, I was terrified of public speaking, so it definitely wasn’t going to be me. Ioana said she’d do it, but she was travelling to the US and didn’t have time to do the slides. I volunteered to do slides; that was the easy part; I didn’t actually have to go in front of 100 something people. So I did the slides. This was my first mistake. 😅

On the morning of the event, I was waiting at the airport for Ioana to land when she calls me to tell me her flight got delayed, so I should go to the event and stall; she’ll get there on the next flight. I get to the event. This was my second mistake. Marcela, the organizer, is a friend and a really nice person; she kept pushing our time slot later and later in the day. It came to the last time slot of the day. Someone had to go up on stage.

Marcela goes up on stage, looks for Ioana in the audience, but Ioana isn’t there yet. She then utters the words that sealed my fate: “And now, from Mozilla… Alex! Alex is going to come and speak about it!". It took me a while to process. I went up on stage, I put my hands in my pockets, I kept bouncing from one foot to the other, and it took a good minute until I started speaking. It was horrible. I couldn’t face my audience. I was looking halfway at my slides, halfway at the sidewall. Sadly, the experience is recorded and still up on YouTube. I still use it as an example of what not to do when I try to help other people get over their fear of public speaking. Luckily, the experience isn’t in English, so you can’t really understand how bad it was unless you speak Romanian. 😅

The problem was, once I started speaking, I couldn’t stop—no questions from the audience, no nothing. After I finished my presentation, there was a Q&A part. For every question I got, I kept stepping further and further into the audience space. At a certain point, when the Q&A portion was finished, I was literally in the middle of the room.

By the time I finished my talk, Ioana actually showed up at the conference. But the damage was already done. I had spoken in public without dying in the process. After that first experience, I was horrified, nervous and vowed never to do it again.

Two weeks later, I was doing it again, speaking in front of 50 other people. That’s how I got started into all this. Turns out, peer pressure is a strong motivating force, especially if done live in front of hundreds of strangers. I’m being sarcastic here. Please don’t do this to your friends. I highly doubt it’s going to work a second time. You might call me the “Accidental Public Speaker”.

The other hundred or so talks that followed, I have no excuse for those. 😅 In the meantime, I’ve learned a lot about things that help me get on stage and power through fear. I do some embarrassing things before I go on stage now. But they work for me, so I’ve learned to accept the process and don’t fix it if it’s not broken.

One of the things that work for me has to do with the “Psychology of Winning”. If I make myself believe I’ve “won” this talk before it even starts, there no pressure to hype my fear levels. It sort of takes the edge off enough for me to start. And once I start, and get through the first 2 minutes of it, practice and a lot of other things kick in, and it’s all the better from there.

How do I trick myself into believing I “won” something before it happened? Well, this is where the embarrassing things happen. The “Psychology of Winning” says winning is a state of mind that correlates to physical reactions to winning. The reverse is also true to some extent, so mimicking those physical reactions will induce a mild “winning” mental state. You see where I’m going with this.

Before my talks, I find a quiet corner at the conference or an empty bathroom stall 😳. And I do winning gestures, like pumping my chest forward, raising my fists in the air, jumping up and down, and screaming my lungs out. In case you’ve been at a conference with me before and you’ve “experienced” the ritual, I’d like to profusely apologize. 😅 I hope we can still be friends.

If this all inspired or convinced you to try speaking in front of people, reach out on Twitter. I’m putting together a list of other things I tried to get over my fear of public speaking, some of which actually worked.

Meet zx: A Better Way to Write Scripts with Node.js

Tue, 11 May 2021 00:00:00 +0000

Bash is great and all, but it’s not something I’ll pick up in a day. I was looking for something a little bit more convenient to write scripts in. While looking, I’ve stumbled upon this little utility from Google called zx. And it’s a better way to write scripts using JavaScript.

I thought I’d give zx a try. It comes with a bunch of things out of the box, like chalk and fetch. I know, Node.js already lets me write scripts, but dealing with a bunch of the crap around escaping and sanitizing inputs was painful.

The Script Way

Before I talk about all the great things zx promised, let’s talk about the basics of writing and using scripts first.

Scripts are all text files and need to start with a shebang at the top (also known as sha-bang, hashbang, pound-bang or hash-pling). The shebang tells the operating system to interpret the rest of the file using that interpreter directive, effectively starting the interpreter and passing the text file along as a parameter.

So, when scripts start with #!/bin/bash or #!/bin/sh, the OS actually runs $ /bin/bash /path/to/script behind the scenes every time you execute the script.

Before you can execute the script, you need to declare it in the system as executable. On Unix systems (macOS included), running $ chmod +x ./script.sh or $ chmod 775 ./script.sh will do the trick.

After you’ve given permissions to your script to be executed, you can run it with $ ./script.sh.

Bash Scripts

A Bash script starts with the bash shebang, followed by a lot of black magic. 😅 For example, to add two numbers that are given as command-line arguments, a script looks like this:

#!/bin/bash

echo "$1 + $2 = $(($1 + $2))"

To run it, save it as add.sh and then run the following commands in your Terminal:

$ chmod +x ./add.sh
$ ./add.sh 5 7

The output is going to be 5 + 7 = 12.

It looks pretty simple if you’ve figured out that $index is the command-line argument. I’ve had to look that up while learning shell scripting.

`zx` Scripts

Before you can use zx to run scripts, you’ll need to install it globally via npm, with $ npm i -g zx. Why didn’t you need to install bash? Because bash comes installed by default with Unix systems.

Similarly to all other scripts, a zx script will start with a shebang. This time, a little more complicated, the zx shebang. Followed by a lot of JavaScript. Let’s try to recreate the above shell script that adds two numbers given as command-line arguments.

#!/usr/bin/env zx

console.log(`${process.argv[0]} + ${process.argv[1]} = ${process.argv[0] + process.argv[1]}`)

To run it, save it as add.mjs and then run the following commands in your Terminal:

$ chmod +x ./add.mjs
$ ./add.mjs 5 7

The output is going to be /Users/laka/.nvm/versions/node/v16.1.0/bin/node + /usr/local/bin/zx = /Users/laka/.nvm/versions/node/v16.1.0/bin/node/usr/local/bin/zx 😅. And that’s because process.argv, another Node.js wonder, gets called with three extra arguments before you get to 5 and 7. Let’s re-write the script to account for that:

#!/usr/bin/env zx

console.log(`${process.argv[3]} + ${process.argv[4]} = ${process.argv[3] + process.argv[4]}`)

If you run the script now with $ ./add.mjs 5 7, the output is going to be 5 + 7 = 57. Because JavaScript 🤦. And JavaScript thinks those are strings and concatenates them instead of doing math. Re-writing the script again to deal with numbers instead of strings, it looks like:

#!/usr/bin/env zx

console.log(`${process.argv[3]} + ${process.argv[4]} = ${parseInt(process.argv[3], 10) + parseInt(process.argv[4], 10)}`)

The Bash script looked a lot cleaner, right? I agree. And if I ever need to add two numbers from the command line, a Bash script would be a way better option! Bash doesn’t shine in a lot of other areas, though. Like parsing JSON files. I gave up trying to figure how to parse JSON files halfway through the StackOverflow post explaining it. But this is where zx shines.

I already know how to parse JSON in JavaScript. And here is what the zx script for it looks like, using the built-in fetch module:

#!/usr/bin/env zx

let response = await fetch('https://raw.githubusercontent.com/AlexLakatos/computer-puns/main/puns.json')
if (response.ok) {
let puns = await response.json()
let randomPun = Math.floor(Math.random() * puns.length)
console.log(chalk.red(puns[randomPun].pun))
console.log(chalk.green(puns[randomPun].punchline))
}

Because I was fancy and used the built-in chalk module, this zx script outputs a random pun from https://puns.dev in the command-line.

Building something similar in shell had me rage-quit halfway through the process. And that’s OK. Finding the right tool for the job is what this post was all about.

How to Get Your First Job in Developer Relations

Tue, 04 May 2021 00:00:00 +0000

Hi, my name is Alex, and I’m an… Advocate. A Developer Advocate. With Developer Advocates being one of the most sought out commodities on the market this year, I thought I’d write up the answer to one of the questions that I answer frequently in my DMs - mostly because I read this thing from @swyx.

How did you break into Developer Relations?

If I knew what I did exactly to end up here, it would probably be an easy answer. But it isn’t because I didn’t wake up one day and decided this was what I wanted to be when I grew up. My idols and role models were Developer Advocates, and I didn’t think I was good enough to be the same. On top of that, I was a Senior Developer with quite a few years of experience under my belt. I didn’t feel like giving that up to be a “Junior” anything again.

If you ask other people in the industry - and I asked quite a few of them in a survey - everybody has a different story. Because Developer Relations is such a new industry. Even defining it is tricky because it depends on which side of the aisle you’re asking. Phil tried to define Developer Relations a while back, and when you look at it, it’s got so many roles that overlap. Evangelism versus Advocacy, Marketing versus Community, Technical Writing versus Developer Experience. And they’re all a part of DevRel, but the skills required for the role depend from company to company, not necessarily from role to role.

Josh said that not all journeys are the same, and I tended to agree with him. But then I got the chance to meet and interview many other Developer Advocates, Community Managers and Technical Writers, and some patterns emerged. Turns out, while not all journeys were the same, all roads lead to Rome.

I’ve spent some time identifying a set of skills each of us in DevRel had before joining the industry. Here’s a list that also tells you how you can acquire them now, outside of DevRel. Because it turns out you don’t have to give up your career progression and start all over, you can break in. Not a single one of us had all the skills we use today.

We’ve all started out with only one or two of the required skills and learned the rest on the job. So don’t worry, you can make do with picking up only a few of these skills!

Community Building

There are open-source programs explicitly designed for building community. I’ll share a list of my favourites, but I’m pretty sure most open-source projects won’t say no if you start helping out. It doesn’t have to be something as minor as code. It can be something truly helpful, like commenting on old issues to see if people still care about them. Or getting together with some people to test a project. For example, the Reps program even sponsored pizza or coffee for people to get together and help out around the Mozilla mission. Fedora does the same for its Ambassadors. I’m pretty sure I missed a few, so let me know on Twitter, and I’ll add more.

Mozilla Reps are passionate Mozillians who mobilize and develop functional and local/regional Mozilla communities. They are committed to educate and empower people to support Mozilla’s mission and contribute to the project based on Mozilla’s leadership agreements.
Fedora Ambassadors are responsible for helping to grow the contributor base and act as a liaison between other FLOSS projects and the Fedora community.

Public Speaking

With a pandemic, travel bans and no in-person events, public speaking is a different beast than when I started. There are different challenges involved in speaking in front of a live audience as opposed to a camera. Most learning communities there haven’t yet adapted to online speaking, so if you find yourself stuck while picking this one up, please reach out. I’m more than happy to have learning sessions. We’ve been training people online to speak in public for a few years with Mozilla Tech Speakers, happy to pick it up again.

Global Diversity CFP Day is a tech-wide cross-community event based on the successful workshops held in advance of ScotlandCSS and ScotlandJS in 2016. Over the years it has evolved into a focused 1-day event designed to help you go from an idea to skills and a talk ready to submit to a conference.
Toastmasters is a nonprofit educational organization that teaches public speaking and leadership skills through a worldwide network of clubs. While they focus more on improvised topics, it will get you comfortable to step up in front of strangers and try to keep a straight face while you’re talking about a random topic. This will later evolve into not being afraid of the Q&A session of your talks.
Mozilla Tech Speakers started as an experiment in 2015 designed by Havi Hoffman and Dietrich Ayala from the Mozilla Developer Relations team. They invited a handful of volunteers who were passionate about giving talks at conferences on Mozilla-related technologies and the Open Web in general to trial a program that would support their conference speaking activities and amplify their impact. It scaled to 100 people, but sadly in 2020, it was axed when Mozilla did their second round of layoffs. However, the resources developed for the program are still some of the best around, so check them out.

Technical Writing

I must admit, writing, in general, was something I struggled with. But new resources and communities for technical writing keep popping up. It’s getting easier to get started. What helped me was transforming the writing bit from a skill into a habit. I’ve struggled with writing consistently for 3 years, tried various things, but I think I’ve finally figured it out. For the past 189 days, I’ve challenged myself to write at least 100 words every day. And you (and me both) would think that’s not a lot. It seemed like a manageable quantity when I started. Turns out those 100 words add up when you do it every day. So far, it’s been 42687 words and 19 articles published in those 189 days. I’ve used Twitter as a way to hold myself publicly accountable, but there are other communities to help you be accountable while you learn or to help improve your writing style.

Write the Docs is a global community of people who care about documentation. They consider everyone who cares about communication, documentation, and their users to be a member of their community. This can be programmers, tech writers, developer advocates, customer support, marketers, and anyone else who wants people to have great experiences with software.
Blogging for Devs is both a free email course and a paid community. Whether you’re just starting out, trying to revive an existing blog, or want to get past a plateau, this course and newsletter is going to help.
Google has a collection of courses and learning resources that aims to help you improve your technical documentation. Learn how to plan and author technical documents. You can also learn about the role of technical writers at Google.

Event Organizing

The barrier to start organizing events has considerably lowered with the onset of the pandemic. Before, it involved finding a physical space, a speaker, an audience and a sponsor for the refreshments. It was a lot easier to find an established group and help out instead of starting your own. I went at it the hard way, starting a London JavaScript meetup with Chris and Simona. Chris and I convinced our employer to let us use the office during the weekend, and we asked our friends, like Simona, to come in and do free Angular workshops for people. After the meetup group got enough people, sponsors and venues started contacting us, so we didn’t have to run around looking for them. But with our attendee numbers multiplying fast, the three of us weren’t enough to get everything done, so we were always on the lookout for people to help us out. Be those people for other groups! I highly doubt anyone is going to turn you down.

If helping out a group isn’t your thing, you can always put on a show of your own. In the age of online events, you don’t need a space or a sponsor. You can do it with a Zoom call, a speaker, and an audience. If you’re looking for groups or a place to find your audience, here’s a list.

techtalks.io is a new tool for community building that evolved from the need for a better Meetup. I honestly think it’s the natural progression of Meetup. You can join a community of engineering, design, product and UX experts, organize, watch and discuss talks, get involved with a community and share your ideas.
Meetup is a platform for finding and building local communities. People use Meetup to organize events, meet new people, learn new things, find support, get out of their comfort zones, and pursue their passions, together.

Builders

I’m afraid I don’t have a lot of options here. The only thing I can tell you is to build things. What things? It doesn’t really matter. The goal is to pick up something new, experiment with it for a few days, and then tell other people what you did. It doesn’t have to be a next career move, it doesn’t have to be useful to anyone but yourself, and it doesn’t have to be maintained for years to come. Build things, and that’s it.

If you’ve stumbled upon my GitHub profile, you’ll see I’m part of a dozen organizations, most of them abandoned, and that’s ok. I’ve also got almost 100 repositories that are just there, with only a handful actively maintained. Some of them are so cringe-worthy, with hacked-together code, that I still haven’t made public. And that’s ok.

All these got me a valuable skill: I can build something with a clearly defined scope and throw it away as soon as it served its purpose. I don’t get overly attached to a piece of code or a project just because. And it doesn’t have to be perfect.

Can You Be a Junior Developer Advocate?

Yes, definitely, of course!

I know this might sound controversial. A lot of the Developer Advocates out there will tell you to be a Solution Architect before thinking about being a Developer Advocate. I’d like to formally and unequivocally call “BullShit!” here. Just because it took some people forever to get here (me included), it doesn’t mean it was right or that you should suffer. No! There are Junior Developer Advocates, Junior Community Managers. I’m not sure about Junior Technical Writers, but surely there are some, so let me know in the comments section below!

The quality that makes a successful devrella is being able to understand developers pain points. Sure, some slower people like me need to suffer first before we can understand the problems, so we can fix them. Some smarter people, like Mary, could figure out this one without going through the grind. That means anyone can get there, so Junior Developer Advocates are a thing! Next time you see an opening, don’t let the fact that you haven’t suffered in the industry for the past ten years discourage you from applying. This field needs a fresh perspective a lot more than it needs dinosaurs like me.

Bonus Round

As Shawn put it, “DevRel is a not generalizable skill, or rather, there’s such a thing as devrel-company fit”. You might have noticed this blog post was technology agnostic. And that’s because it requires a great deal of passion and empathy. Those skills are not as easy to acquire as functional skills. Try to find a product or community you’re passionate about or something you’ve used or been part of before. It’s easier to get your first job in Developer Relations for a company when you’ve already got some domain knowledge. There’s also some degree of credibility involved. I couldn’t get a job advocating for an iOS company, for example. You should try to get some experience in your space, really understand the domain you’re trying to break in as a devrella.

I also co-curate alongside Julia, a weekly email roundup of Developer Avocados 🥑 Call-For-Papers, resources and articles. If you want to learn more about DevRel, you should definitely subscribe to Developer Avocados 🥑 Weekly!

If you’ve read this far, or you’re considering getting into Developer Relations, reach out on Twitter! I’m always happy to answer your questions or help you land your first role in DevRel.

2020, Thank You!

Sat, 09 Jan 2021 09:00:00 +0000

2020 was kind of shit. Go on, it’s OK to admit it. But when I look in the mirror, 2020 was a lot healthier for me than usual. I’ve seen quite a few 2020 reviews this past week. It’s the fashionable thing to do. Hence this is my first yearly review. I’m going to try to use this as a sort of guide for next year. Now, whilst most reviews I’ve read highlighted the things people couldn’t do in 2020, or the exact ways in which it sucked, I made a conscious decision to try to find things that actually went well for me in 2020, and not even mention any of the negative shit 2020 is famous for.

It turns out, I didn’t have to look that hard for things to be thankful for. The DevRel life is full of chaos, so the fact that I didn’t travel for most of 2020 unlocked a lot of possibilities. A lot of those things that kept being pushed to “when I get a change” got done, so truly, thank you, 2020, you haven’t been all shit. And I honestly think I couldn’t have done most of these things if I wasn’t forced to stop travelling. I certainly couldn’t have stopped travelling on my own. My idea of “taking it easy” this year was to have a flight booked every two weeks, instead of the usual two flights a week.

First of All, What Happened in 2020?

💃The last 3 years have been a wild ride, I loved being part of the award winning #DevRel team at @VonageDev, I'm so proud of how much we grew!

🏄It's my last week here, and I'll miss every one in our amazing team, but I'm also super excited about the next adventure.

🙇‍♂️Thanks! pic.twitter.com/Ct6xbQFmVk
— Alex Lakatos 🥑🇬🇧 (@avolakatos) June 8, 2020

👷Switched Over to the Dark Side

There were no cookies🤷. I’ve moved from an individual contributor role at Vonage this year to a manager position at Fidel. And in true Laka fashion, I still refuse to manage people. OK, I did manage a few people for a little while, but I’ve since spent most of my time trying to make myself redundant. Instead of building a team of Developer Advocates, like it’s the fashion, I’ve spent the past six months building a DevRel Culture inside Fidel, trying to make myself redundant.

How it started: How it's going: pic.twitter.com/tFKsi3WQ3H
— Alex Lakatos 🥑🇬🇧 (@avolakatos) October 12, 2020

🏋️33% Less Laka

I lost quite a bit of weight this year. 52 KG (110 Pounds) to be exact, which amounted to 33% of my body mass. There were a few factors that contributed to this one:

I started looking at what I ate. No, it’s not a figure of speech. I literally take a picture of my food before I eat it. It forces me to pause, and figure out if what I have on my plate is right for me. I also used to send that picture to a random stranger I found on the internet and was paying to give me advice about my nutrition. It worked from the very first picture because I was so ashamed with the quantity on my plate, I took part of it off and re-did the picture. Didn’t put the food back on the plate afterwards. The only thing that kept me honest was the eye-watering amount of money I paid for the service, I wasn’t going to pay to cheat.
I started going to the gym. Maybe a little too much, and it’s turning into an addiction. I’ve got 3 sessions a week with a personal trainer, and another 7 without one. The PT sessions are all focused on functional training, while the ones without are all about burning fat in steady-state cardio, usually on a treadmill. Because that allows me to listen to audiobooks or watch things on YouTube, it feels less boring, and it’s currently my happy place.
I did the math. With lockdown happening, I started cooking all my meals instead of eating out. That made it easy to better track what I ate in MyFitnessPal. My Fitbit watch tracks my calories burned during the day, so I started paying closer attention to the difference between what I ate and what I burn. I try really, really hard to make sure I’ve got a deficit of at least 1000 calories a day.

🤔I gave up smoking two months ago, but I think I just traded that for a new vice. That's a lot of @audibleuk I've listened to in these past two months... #ThursdayThoughts pic.twitter.com/uCxJJqMbRS
— Alex Lakatos 🥑🇬🇧 (@avolakatos) October 1, 2020

💨Gave up Smoking

As we started going to the gym more and more, the cigarettes began to affect our training. Julia was the first to quit, her training program is a lot more intense than mine. But after a few months of smoking alone, I just didn’t get the same benefits out of it. The negative impact of being the only smoker in the house outweighed the stress release aspect of it. So one day I decided to quit, cold turkey. Of course, that didn’t happen. Just the idea that I was running out of cigarettes sent me into a mild panic attack. I think that’s been hardwired into any smoker out there so deep, that just the idea I was running low was too much to bear.

So I tried tricking the lizard brain inside and bought a fresh pack of smokes. Of which I smoked exactly 5 cigarettes over the course of 3 days. And those were the last I’ve smoked. But I still carry around that unfinished pack of cigarettes with me, everywhere I go. I can smoke any time I want to, I just choose not to smoke. I think that’s the trick that finally helped me to quit smoking. The other time I tried, I lasted a whole of 10 hours without smoking, after which I proceeded to make up for it. It’s been 5 months this time, and hopefully, this one is for good.

🥳For he's a jolly good fellow, and it's his birthday today, we thought it fitting today's #adventcado was @avolakatos.

🎂He talks about a lot of things in there, but what he really means is: eat more cake today!https://t.co/A7rsa2jSIC
— Developer Avocados 🥑 (@DevRelAvocados) December 12, 2020

As you’ve probably figured out by now, a year has a bit more than 36 weeks. 52 if you must be exact. Why am I celebrating this, though? Because it’s a hell of a lot more than 0. That’s right, in a shit year, with taking a month at a time off from the newsletter, we kept finding the strength and motivation to keep coming back to send it again. Eventually. While we technically made no money from it.

And the fact that we could still find passion in something pre-pandemic, that’s definitely worth celebrating in my book. Oh, and towards the end of the year, we found the energy to run an advent calendar with 24 Developer Avocados, which required us to get out of our comfort zone and reach out to people we haven’t met. Especially in a time when people can’t be expected to give a damn.

👩‍🎨It took a while, but https://t.co/6YcRBkfRXP finally has a new sexy look, all thanks to @hj_chen !

🦸‍♀️She did wonders with the CSS and inspired me to ditch Jekyll & GH Pages in favor of @GoHugoIO & @Netlify .
— Alex Lakatos 🥑🇬🇧 (@avolakatos) May 5, 2020

🎨Got a New Website

After 4 years, I’ve finally got the time to make a new website. Or at least, I had the time to stand there and look pretty while Hui Jing did all the work. But it’s happened, and it made me want to add more to the website, regularly. I’ve written more articles for it this year than any other so far. The new habit-forming routine I’ve got might have something to do with this as well. So far, I’ve got 73 days in a row of writing 100 words or more. “Science” says that if I got to 66, it’s a habit and here to stay. No matter the outcome, it has certainly helped me write more this year. I think my goal was 12 articles a year for the past few years, but this is the first year I’ve actually managed to do it. And then some. I think I managed to publish 4 articles in a single week, and that’s something I didn’t think I could do.

What About 2021?

😷Survive

Get to the next level, year, whatever. That’s it. That’s the resolution.

If survival seems too achievable, I’ve got a few other things I could try doing.

Create a best-in-class Developer Portal. Open-source it from day 1, so other people could easily use it. I’ll consider this a success if it’s as easy to deploy as it would be to do one of the static-site generators.
Publish every week. I’ve started early on this one. I’ve started writing a minimum of 100 words every day. You can follow along with my progress on Twitter. But I’m hoping that’s going to help me publish 52 articles this year. I’ll consider this goal a success even if it’s 52 articles, and not necessarily one every single week.

Creating a DevRel Culture

Sun, 06 Dec 2020 23:56:00 +0000

How big is your Developer Relations team? I’m betting it’s small, same as mine. Unless you work for Microsoft, Google, Amazon, Twillio or Vonage(The Artists Formerlly Known as Nexmo), it’s pretty hard to justify a double-digits DevRel team. And that’s OK; not everyone needs 70 people to do Developer Relations. It wouldn’t hurt though. Probably that’s why everyone is scrambling to justify their program right about now and to increase their budget for next year.

What happens if you work for a company that can’t afford 10 Developer Advocates? I happen to work for a startup with 60 people; it’s been tough to sell a big team to my CEO. And trust me, I’ve tried.

I talked last week about starting a Developer Relations Program, but it’s still a lot of work for a team of one. My challenge was scaling a DevRel program without increasing the headcount. I’ve achieved that by creating a DevRel Culture instead.

Yeah, you’ve read that right. And it’s not some HR hocus pocus. Creating a DevRel Culture turns out to be highly effective. While you probably can’t have anyone else inside your company that can do all the things you do, it doesn’t mean that you can’t find someone that is more suited to do a little slice of what you do. The trick is finding multiple people, each able to do one aspect of your job better than you. There are quite a few skills required of a Developer Advocate, but most of them are found in other roles within a company. So why not use those for help?

If you haven’t read about my journey to build a 1st-year DevRel Program, let give you some context. I’ve identified a few day-to-day activities that I should be doing, to make a difference. Let’s take a look at those activities, and then see where in the company you could find people to do a better job than you. Basically doing 20% DevRel for 80% of the impact.

Writing the Documentation and API Reference - The engineers writing the feature are good people to document it. Or the product manager that wrote the use case for it. Or the Quality Assurance Engineer that tested it. Depending on the size of your company, you might even have all three of those people to help.
Building SDKs - The engineers that wrote the code for the API can build the SDK wrapper for it as well. And since they write production code every week, they’ll most likely do a better job of it than you.
Create demo applications - You guessed it by now. If it has to do with coding, your Engineering department can probably do a better job than you.
Write blog posts - Anyone, and I mean literally, anyone in the company can write a blog post. Now, it might not come as easy or natural for everyone, but here is where you come in. You’re used to lowerering barriers to entry for developers using your product, why not apply the same principles for writing articles for your blog? No one can fake the authenticity of the people building your product, not even you. So why not have them tell their stories, instead of you? Sure, you’ll get enough pushback, everyone is afraid of writing. So make it easy for them. It’s your job to guide people in writing that first blog post. And try to make it as easier for them as possible. For example, I’ve used an interview format to get people to write their first blog post. I’ve had 30-minute calls with people where they presented their idea, and I’ve had those transcribed and edited into a blog post. I’ve also had people come up with their own ideas and writing them inside the week because they were passionate about it. But most importantly, I’ve bribed everyone involved with limited edition quality swag 😊
Sponsor online events - Your marketing team has probably sponsored a lot more events than you. They’ve been around longer. And their events cost a hell of a lot more than yours. They’ve got all that experience dealing with the event organizers. So ask them for help here!
live-stream on Twitch / Youtube - You’ve got another group of people in the company that are trained for speaking at online events, mainly webinars. And that’s your Sales team. So get them to stream some of their webinars live on Twitch, and see the magic happen.
Give talks at online events - Your CEO probably has a lot of experience pitching your investors. And they probably deliver a quarterly update to your Board of Directors. They’ve also probably dealt with the press before. So they’ve got all the training they need in order to go on stage and tell a compelling story, backed with data. If time is a constraint, you’ve got a backup here. Your Sales team is also used to speaking in front of small groups of people, with lots of slides. Get them to drop the sales pitch, and you’ve got a talk ready to be given, with a trained person ready to do it.
Answer support queries - Your engineers are the people you usually go to with the support queries. So why not eliminate the intermediary (yes, that’s you), and have the support queries go to the on-call engineers right away?
Have customer calls - Your Product Manager is the person you go to with feedback after each call. So why not save yourself the hassle, and have them join those calls to begin with? Sure, maybe they’re not trained to gather feedback, but you can help them out during the first calls, do a bit of handholding, and then take the whole thing off your plate. It’s going to help free you for other things.
Maintain the developer community forum - In here, most questions have to deal with using your product. Your Support people are probably your best bet. They are trained to answer questions coming from existing customers, they can do the same for people who aren’t exactly customers, but who have questions around your APIs.
Create a feedback mechanism between the product and developers using the product - This can be easily solved with technology. Changing the Developer Experience of your product to have a feedback mechanism will save yourself the hassle. The only trick is getting your Product Manager to actually read and action that feedback. I’m kidding, it’s not a trick at all, and they’ll probably thank you for making it easier for them to do their job.
Help with recruitment efforts - Your HR person is better equipped for recruitment purposes, so why not have them help?

I’ve spent the past 6 months at Fidel trying to help other people to do my job, basically trying to make myself redundant. And it’s worked brilliantly! It doesn’t mean I do absolutely nothing now, but it does mean that I provide guidance and review most things before we put them out, instead of trying to do everything, and badly!

I should also mention I come from a culture that relies heavily on… incentive. They’ve tried to legalize bribes a few years back. So I’m quite familiar with using incentives to motivate reluctant people.So if you can’t convince your coworkers that the satisfaction of a job well done is enough…. bribe them! I’m currently using swag as bribes, Rona is preventing me from using a more traditional approach: free lunches and a round at the pub.

If you need help figuring out how to convince people to help, or to introduce you to The Way of The Bribe™️, feel free to DM me on Twitter.

Building a 1st Year Developer Relations Program

Tue, 24 Nov 2020 10:05:00 +0000

Congratulations, you’ve just got a job as the first Developer Relations person in a company. It’s your job to build a Developer Program. Where do you start? When you try googling that, you’ll discover Google isn’t always your friend.

Fear not though, I’m here to help. I’ve been in the same boat this year, and I’ve had to figure it all out. I’ve joined the team behind the Fidel API in the middle of a pandemic, and I’ve started building a Developer Relations program. I’ll share my process, and I’ll tell you how I chose my blueprint. So bare with me. It’s going to be one wild ride.

First of all, when I tried to Google my way out of this particular bind, I found very little on the topic. So I started looking at what other people were using for their DevRel programs. Two contending models emerged, and they are fairly popular in some DevRel circles. AAARRRP and the Orbit Model. So let’s take a quick look at them.

AAARRRP

AAARRRP, also referred to as Pirate Metrics, comes from Leggetter. And Marketing, but we’ll not dwell on that too much. It’s an acronym for Awareness, Acquisition, Activation, Revenue, Retention, Referral and Product. And while they may be meaningless words on their own, they actually stand for both metrics and goals for a developer relations programme. If you look closely at the definition Phil has for them, you’ll notice they are highly generic because they are meant to fit different products.

I’ll share what AAARRRP means for me, at Fidel, so we’re all on the same page. By looking at Phil’s generalisation and my specific adaptation of it, you should be able to adapt them for your product.

Awareness stands for how many people have heard about our product. Or are aware of it. We consider blog post views, documentation, API reference, and social media views in this metric.
Acquisition is used to track signups.
Activation refers to people actually having used your product. Once. So we consider people that have created their first test transaction as activated.
Revenue means people are not just testing it, but using it, so we’re making money. People in the revenue band have gotten past the sandbox mode and are using the API live.
Retention comes from people that have used it for a while, and they aren’t switching to something else. This stage is where the model stops looking like a funnel.
Referral means people are telling other people about our product. This is one of the parts of the model that can happen at any previous stage. We don’t necessarily start measuring this metric only after people have passed the retention stage. Most of our customers become referrals even before they have left the acquisition stage.
Product refers to the feedback mechanism that makes our product better. We measure not only the amount of feedback we get but also the quality of the feedback we get. Again, another one that can happen at any stage.

This model is often referred to as a funnel, which is not accurate, it’s partially a funnel, with 2 pillars (Referral and Product) on the side. Because those metrics/goals can be influenced at any point in the funnel. The only metrics that fit in a funnel are Awareness, Acquisition, Activation, Revenue, and Retention.

Orbit

The Orbit Model, on the other hand, is a model for building communities. It was created by Josh Dzielak and Patrick Woods. It defines four main concepts and depending on where you get it from, the orbit levels are called differently.

Love is a person’s level of engagement in the community.
Reach represents the size of a member’s audience or sphere of influence.
Gravity is an equation of love and reach. Anyone in your community has a gravity defined by love x reach.
Orbit Levels are defined depending on the gravity number. They are segmented into 4 bands, closer or farther away from your product, depending on gravity. The closest ones are Advocates or Ambassadors, followed by Fans or Contributors and Users or Participants, with the ones furthest from you being Observers.

This model’s biggest selling point is that it’s not a funnel. But then again, AAARRRP isn’t exactly a funnel either. If you want to be pedantic though, you could correlate Orbit Levels to AAARRRP, where Observers account for Awareness, Users are Acquisition, Activation, and Revenue. Fans are Retention, and Ambassadors are Referral and Product. And the whole reason for segmenting your community like this is so you can interact with parts of it in different ways.

Orbit is a great model if you want to build your community, segment it, and create a strategy around that segmentation. But here’s my problem with Orbit. When my entire Ambassadors pool is 1, and my Observers are barely 1000, there is no statistical relevance I can use. Sure, it’s a great model when you have a huge user base or a vast community. But when you’re a startup with 1000 users, not so much.

What Did I Choose?

Drumroll, please! …I chose …Neither. Because AAARRRP is massive, hard to measure accurately across all in-person activities, and doesn’t really work for a one-person show. And Orbit doesn’t work for a small community. This was a bit anticlimactic, wasn’t it? And it probably didn’t solve your initial question either.

So what did I do, as someone who has a small team and a small community? I scaled down. Instead of using AAARRRP as my model, I trimmed it down to something I can achieve in this first year, with a small team. I went for a scaled-down version I call AARP. or Baby Pirate Metrics. It’s an acronym for Awareness, Activation, Referral and Product. I only chose the top 2 layers of the funnel, because the more significant the addressable audience, the higher the chances I can eventually impact the Revenue bit. And Referral and Product are what ultimately touch everything else in the model, so I need to take care of at least part of it in the first year.

Those 4 goals still have quite a few activities tied to them though, and it’s a tall order. Let’s look at some of those day-to-day activities and which of the 4 goals they help achieve.

writing the Documentation and API Reference (acquisition, product)
building SDKs (product)
create demo applications (product)
write blog posts (awareness, acquisition)
sponsor online events (awareness, product)
live-stream on Twitch / Youtube (awareness, acquisition, product)
give talks at online events (awareness, acquisition)
answer support queries (referral, product)
have customer calls (acquisition, product)
maintain the developer community forum (referral)
create a feedback mechanism between the product and developers using the product (product)
help with recruitment efforts (awareness)

It’s still a very long to-do list for a small team. It seemed way more manageable when there were only 4 letters, didn’t it? How are you going to do this all alone? Well, if you stick around until next week, I’ll tell you how I solved this particular conundrum in my next blog post. If you just can’t wait that long, feel free to DM me on Twitter.

10 Things I Wish I’d Learned Sooner After Being a Developer for 10 Years

Tue, 17 Nov 2020 16:30:00 +0000

Exactly 10 years ago today, I was starting my first job in the software industry. I’ve spent my career being a Software Developer in Test, Performance Engineer, Lead & part-time CTO, JavaScript Developer, Contractor, Entrepreneur, Developer Advocate & Manager. I’ve also worked for companies on 4 continents, on products that were used by hundreds of millions of people. You could say I did a bit of everything. But I would say my career was anything but boring.

I’m prone to reminiscing, especially while being stuck in the house in the middle of a global pandemic, so I sat down and revisited my greatest hits. I’ll always be grateful my very first job was working with Mozilla, that shaped the way I approached software development in so many ways. I’ve got my love of open-source from there, and my drive to always learn from the people around me. It did help that everyone I worked with was amazing! I’ve also thought about my 3-month stint as a CTO, after which I rage-quit on the spot because money isn’t everything. Or the nine months I spent with my partner, living out of a suitcase, through hotels and AirBnBs in Asia.

This trip down memory lane also made me realise, there are a bunch of things I wish I would have known before I started. Or at least I wish I would have learned them sooner than I did. I made a list with the top ten, but I’m fairly certain I could get to 100. So if you’ve read them and want to know more, ping me on Twitter, and I’ll oblige.

Everyone calls things not related to writing code soft skills. And here’s the most mind-boggling thing. It’s easier to teach someone a skill, like coding, than to change their behaviour, the way they communicate. And yet, communication is considered a “soft skill”. So when companies look for a developer, most of the time, the differentiator is in those soft skills. There are only so many ways you can code your way out of a tech test. When the field is narrow enough, it all comes down to those extra bits. Acquire as many soft skills as you can, it pays off more than adding another programming language or framework to your toolbox.

I come from a culture that values memorisation over creativity and problem-solving. Fuck that. To this day, I still Google how to bubble sort. I’ve probably used it no more than five times in 10 years—and that was because I had to pass some sort of interview test. It doesn’t pay to memorise everything, as long as you know where to get the answers from. In this day and age, that usually means Googling stuff. It’s not a weakness, even if some people are ashamed to openly admit it. With my memory not being what it used to be, I Google even simple things I’ve probably done dozens of times in the past. And there’s no shame in that!

This might have started as “Don’t be afraid to ask for help”. But that’s because I’m stubborn like that, and asking for help doesn’t come naturally in my culture. Again, that damn upbringing.

Asking for help is not something you should do only in dire need. Ask for help as often as you can get it. It frees you up to do the things you’re most passionate about. And the whole reason you work in a team and not on your own is so you can help each other! Hence, ask for help from day 1, not only when the shit hits the fan.

Like most things in this world, the realm of Developers, or “Software Engineers” keeps evolving. So you should evolve with it if you want to stay relevant. Or employable. Sure, you see the odd news about people looking for COBOL developers in 2020. But you have to think about it this way: How many COBOL developers are still doing COBOL 60 years later? So yes, keep learning new things.

It doesn’t necessarily have to be “work-related”. The purpose here is to develop a process for learning. Because as a whole, our learning mechanism (also known as the education system) is fucked up. I mean, most things you learn in school are thought by an average theoretician. And that’s supposed to give you the practitioner skills you’d need. It doesn’t work like that, especially in the world of Programming, where dedicated Experts are few and far between. But figuring out what method of learning works for you means you can literally pick anything up in a matter of time. You want that fancy new job? Start learning, acquire the skills you need, and get it! But if you don’t even know how to approach it, then the whole task of learning a new skill, any skill, becomes insurmountable. And you’ll find reasons to quit before you even begin.

What’s my way of learning? Well, I find someone who’s a bit further ahead than me, listen and then start asking questions. They don’t need to be an expert, just better at it than me. Eventually, those questions become discussions, and that’s when I look for the next person to help our discussions move along. Rinse, repeat, voila!

This is one I struggle with the most. And the reason I can’t seem to say No is because deep, deep down, I’m just a nice person. Or that I would like for people to like me back. Or that I love helping people. Or that I’m just a pushover, and I’m not confrontational. Pick whatever reason makes this more relatable to any particular situation. Not saying No has made me a lot of friends along the way, but at the same time, it has meant I disappointed just as many people as I helped along the way. And that’s because it was physically impossible to do all the things I agreed to.

It also meant I might have accomplished some irrelevant feats, in the grand scheme of things. For example, I’m a registered casino dealer. Sure, it’s a cool party trick, but I could have spent that summer graduating early. I could also have said no to writing a book for a project that died just before the book was supposed to be published (R.I.P. Firefox OS). In the same vein, I could have also said No to living out of a suitcase for 9 months, and missed out on amazing memories. But hey, you live, and you learn.

If you’re not familiar with the concept of T-shaped skills, or T-shaped people, don’t worry, most people are not. It’s an HR metaphor used to describe the skills of candidates. So if you think of your skills as plotted on a graph, you’ll notice you’ve got different levels in each. And if you unite those levels, you’d want them to create a T-shape instead of anything else.

For example, know a little bit of everything, with 2-3 core skills where you’d be considered an “Expert”. And there are quotes there because “expert” is a relative term. Relative to your other skills. For example, when I was a JavaScript Developer, the reason I kept getting job offers was because of my level of knowledge around performance optimisations, and Angular. So while I could do vanilla JS to a passable degree, I had a lot more to offer when it came to Angular applications and optimising the performance of most websites.

Now you’ll wonder. Why was I a JavaScript Developer, and not an Angular Developer? And that’s because I had more than one JavaScript skill under my belt, as opposed to just that one tool, Angular. Hence, I was a lot more employable because of that T shape.

In the world of Developer Advocates though, that also translates to building a brand. The same way you’re building that T, you can create a personal brand. Start writing about Angular and Performance Optimisations, and that would be my “personal brand”. If you follow me around the internet, you’ll have noticed I don’t do that, and I don’t have a personal brand though. I guess it’s something I have to work on.

Especially yours. So if you don’t tell people what you want, or what you need, then it’s pointless to get upset when they don’t give it to you. Because they can’t read your mind. You think you deserve that promotion? Tell your boss. You want to get promoted in 6 months? Tell your boss, and if they’re any good, they’ll tell you how to get it.

In most cases, people are more than happy to give you what you want, as long as you tell them. Most managers don’t really have a clue on what they’re doing, so they’re more than happy to get it done when they actually know what it is they need to get done.

This is one I’ve learnt late in my career. Turns out, when you don’t agree with something, you can always leave. Practically, voting with your feet. Instead of huffing and puffing, or worse, picking a grudge, it’s a lot better to just walk away.

Don’t like your new boss? Just quit. Enough people do it, and their boss will fix it. You don’t like your company’s policies around privacy, diversity, inclusion, human rights? Quit. In an industry where there is more demand than people available, you can always find a better deal.

There are such things as golden handcuffs, but if you’re part of the few that have them, you’ll understand that you can find them anywhere you go.

I’m not saying you should quit without a plan here, in a tantrum. That’s not voting, that’s rage quit. No, by all means, treat this as a rational endeavour, and not emotional. Line up the next gig first.

It pays to know exactly how much your skills are worth. Sure, you have a salary. But if you got that salary more than 6 months ago, it’s not an accurate representation of how much you are worth to your employer. And it probably means a yearly review is just around the corner. That’s the perfect time to make your compensation accurately reflect your worth. You could come up with a formula of how much an hour of your time is worth to your employer, make your case, and hope your boss can do something about it.

Or you could shop around. Maybe you’re worth more to the next employer. On top of the fact that interviewing helps you stay in touch with the market, it also helps you practice at it. Interviewing is a skill, same as anything else you do. It’s good to sharpen this particular skill, especially since it’s a significant factor for your initial compensation package. Without actually testing your newly acquired skills, and their relevance in the market, it’s hard to gauge your worth.

I know, I told you all about how to get paid more until here. But those skills also translate into options. The more you can make, the more options you have. And because of those options, getting paid more stops being a factor. I know, it’s counterintuitive. But after a certain amount, money doesn’t account for happiness just as much. You’ll value the mission, or the work-life balance, or the empathetic boss, or the cool team a lot more than an extra 10% on your yearly salary.

I’ve kept yo-yo-ing between high paid jobs and keeping my soul happy, and I’ve finally settled somewhere in the middle. Sure, I could make an extra 10% every year, but would that make me happier than working from home, on my own terms?

How To Add Image Processing to Your Hugo Website and Improve Performance

Fri, 17 Jul 2020 08:10:00 +0000

I’ve recently moved my personal website to Hugo, and it’s been mostly a pleasant experience switching over from Jekyll. I got tons of improvements in build time. But what didn’t work so well for me was the Hugo documentation. It all relies on the idea that you’ll install Hugo, create a new site, and then add a theme. Here is where the problem starts. I didn’t want a stock theme, it’s my personal website after all, so it should be an expression of myself, right? Well, I was lucky enough to catch Hui Jing in a benevolently, slightly bored, mood. She created all the custom CSS for it, with a fantastic Masonry layout.

But that meant from this point forward the Hugo docs were mostly useless. They are geared towards helping you either develop a theme or change your theme to accomplish something new. Mine wasn’t a very complicated Hugo website, to begin with, so following in Hui Jing’s footsteps, we made it work without docs. Now that the “MVP” has been released for a few months, I keep finding small, little things to improve with it. Or if you look at my web.dev scores, not so little. 😏

Before

I had my cover image in the post front matter, under the images list, because that was the Hugo way to automatically make that image a Twitter social card as well. Me being lazy, I considered that a win 🤦‍♂️. I also had my images stored in the static/ folder, because that made sense? I mean images are not exactly content or assets, right? Turns out it’s wrong, but more on that later.

That meant using images in my articles was easy. I write them in markdown, so adding an image was just a matter of putting the right path in there:

![I wish all my images had alt text 🤦‍♂️](/image.png)

For the layouts, that’s where things became tricky. Technically the front matter images are an array, even if it only ever had one element. That meant I had to cycle through those elements when I displayed them on the list layouts. Or get the item at index 0. So the code ended up looking a little messy.

<img class="post-image" src="{{ range .Params.images }}{{ . }}{{ end }}" alt="{{ .Title }}" />

There were a few problems with this approach.

I was too lazy to bother resizing all the images for the list layout, so most of them were quite big and loaded all at once on the home page. Slow was an understatement.
I couldn’t be bothered to resize images multiple times to do responsive images. Ideally 3-4 times. Hence the horrible performance score on Lighthouse.

There seemed to be a light at the end of this tunnel though. Skimming through the docs, it looked like there was something called Image Processing in Hugo, and that was supposed to help fix all my problems. I could resize my images at build time while compressing them and changing the encoding quality. It all sounded like an easy fix for my laziness. Except the docs are a bit on the slim side, and they weren’t really useful for a website without a Hugo theme. I’ve given it a try twice so far with no luck, but it looks like third time is the charm.

How to Add Image Processing to Hugo

The first thing I was doing wrong was the fact that images were in the static folder. Image Processing in Hugo works on Resources, and for it to work, the image has to be either a Page Resource or a Resource. Page Resources have to live in the same folder as the markdown file, so that was out of the question. There were way too many images to move around, and too many paths to change in every article. The other option, Resource, meant the images have to live in the assets folder, so that was an easy drag-and-drop. Didn’t even have to change the relative paths in the articles front matter.

First thing I did was to move my images into the assets folder instead of static. I changed my images to live from /static/img to /assets/img. Which meant my image sources in articles stopped working altogether. The assets don’t get generated at build time unless they’re processed. And even then, their file name is dynamically generated with every build. So I had to change all image occurrences in the articles and templates to use the Resource instead.

For that to work in my content files, I had to create a shortcode, it’s the Hugo way to have snippets inside Markdown. Here’s how mine looks like, I’ve taken the responsive images shortcode Laura Kalbag blogged about and changed it to suit my layout. And because I have animated GIFs in my DevTricks series, I’m not resizing those, just passing the relative permalink to an image tag. I’m also not doing anything to external images. Still, I figured making everything play nicely with alt tags would score me some Lighthouse points.

{{/* get file that matches the filename as specified as src="" in shortcode */}}
{{ $src := resources.GetMatch (.Get "src") }}
{{ if in (.Get "src") "http" }}
<img src="{{$src}}" {{ with .Get "alt" }}alt="{{.}}"{{ else }}alt=""{{ end }}>
{{ else }}
{{ if in (.Get "src") ".gif" }}
<img src="{{$src.RelPermalink}}" {{ with .Get "alt" }}alt="{{.}}"{{ else }}alt=""{{ end }}>
{{ else }}
{{/* set image sizes, these are hardcoded for now */}}
{{ $tinyw := default "500x" }}
{{ $smallw := default "800x" }}
{{ $mediumw := default "1200x" }}
{{/* resize the src image to the given sizes */}}
{{ .Scratch.Set "tiny" ($src.Resize $tinyw) }}
{{ .Scratch.Set "small" ($src.Resize $smallw) }}
{{ .Scratch.Set "medium" ($src.Resize $mediumw) }}
{{/* add the processed images to the scratch */}}
{{ $tiny := .Scratch.Get "tiny" }}
{{ $small := .Scratch.Get "small" }}
{{ $medium := .Scratch.Get "medium" }}
{{ $large := .Scratch.Get "large" }}
{{/* only use images smaller than or equal to the src (original) image size */}}
<img
{{ with .Get "sizes" }}sizes='{{.}}'
{{ else }}
sizes="(min-width: 35em) 720px, 100vw"{{ end }}
srcset='
 {{ if ge $src.Width "500" }}
 {{ with $tiny.RelPermalink }}{{.}} 500w{{ end }}
 {{ end }}
 {{ if ge $src.Width "800" }}
 {{ with $small.RelPermalink }}, {{.}} 800w{{ end }}
 {{ end }}
 {{ if ge $src.Width "1200" }}
 {{ with $medium.RelPermalink }}, {{.}} 1200w{{ end }}
 {{ end }}'
{{ if .Get (print $medium) }}
src="{{ $medium.RelPermalink }}"
{{ else }}
src="{{ $src.RelPermalink }}"
{{ end }}
{{ with .Get "alt" }}alt="{{.}}"{{ else }}alt=""{{ end }}>
{{ end }}
{{ end }}

To use this image shortcode in my content, I had to change the way my links were called from the default markdown syntax to something in between Hugo and HTML:

{{< img src="img/posts/web/hugo-performance-before.png" alt="Bad Lighthouse Performance" >}}

The output of the {{< img >}} shortcode looks a bit similar to this:

<img sizes="(min-width: 35em) 720px, 100vw" srcset="
/img/posts/web/hugo-performance-before_hu187b84b0088ba519b328cb2126b97350_79974_500x0_resize_lanczos_2.png 500w,
/img/posts/web/hugo-performance-before_hu187b84b0088ba519b328cb2126b97350_79974_800x0_resize_lanczos_2.png 800w,
/img/posts/web/hugo-performance-before_hu187b84b0088ba519b328cb2126b97350_79974_1200x0_resize_lanczos_2.png 1200w"
src="/img/posts/web/hugo-performance-before.png" alt="Bad Lighthouse Performance">

It looked like I could resize my images inside content. So why wouldn’t I be able to do the same in my layouts? Because somewhere in the fine print on the docs it says I can’t use shortcodes outside of content files. Still, the same functionality is available in layout templates via partial templates. As it turns out, I don’t need responsive images on my list views, I just need way smaller images. So I didn’t bother recreating the whole shortcode logic in partial templates. Instead, I had a less complicated, lazier approach. I get the image Resource, I resize it to 360px, with a quality of 85%, using a Box filter. It all translates to smaller, faster, poorer quality images on the home page.

{{ if .Params.images }}
{{ $image := index .Params.images 0 }}
{{ $src := resources.Get $image }}
{{ $small := $src.Resize "360x q85 Box" }}
<img class="post-image" alt="{{ .Title }}" src="{{ $small.RelPermalink }}" >
{{ end }}

After

With these changes, I was ready to test my Lighthouse score again. You can try as well, my website is alexlakatos.com.

You’ll notice my Largest Contentful Paint went down by about three and a half seconds. I’d call that a win. The Performance score also went up to 99, which I’d call pretty darn good. The fact that both my Accessibility and SEO scores jumped to 100 is because the new shortcode made me re-write all my image tags. I took the time to update them to have an alt attribute, so I wouldn’t have to go through them again.

Now if I wanted to do more, I would have to figure out a way to make Hugo’s Image Processing pipeline work with next-gen image formats. But that’s a story for another time. In the meantime, feel free to reach out on Twitter, and let me know if you’ve found this useful. Or at least mildly entertaining.😅