We have SBOMs for dependencies and signed commits for authorship. Why don't we have provenance for AI contributions?

Here's a thing that's been bothering me.

Every engineering team I talk to is using AI coding tools. Claude Code, Cursor, Codex, whatever is hot next week. The output is impressive. The velocity gains are real. But when I look at how we review that code, we're still pretending it was written like in the olden days.

A pull request lands. The diff shows what changed. The commit message says why. But the thing that actually drove the change — the prompts, the iterations, the back-and-forth with the AI tool — that's gone. The sessions have closed, the context is gone, and the reviewer is left reading output with no insight into intent.

This is a gap, and it's getting wider fast.

CircleCI's 2026 State of Software Delivery report, published in February, puts numbers to it. Across 28 million workflows, average throughput increased 59% year over year — teams are writing more code than ever. But main branch success rates fell to their lowest level in five years, and recovery times are climbing because teams are struggling to debug code they didn't write and can't trace back to its origin. The median team saw feature branch throughput rise 15% while main branch throughput fell 7%. More code is being generated. Less is shipping. The bottleneck has moved from writing to understanding.

We've solved this problem before

When open source dependencies became the backbone of modern software, we built SBOMs — Software Bills of Materials — so you could answer "what's in this build?" When build reproducibility became critical, we got SLSA attestations. When authorship mattered, we got signed commits.

Each of these followed the same pattern: a new input to the software development process became significant enough that teams needed a structured, shareable record of it. AI-assisted development is that next input. But right now, there's no standard way to record which parts of your codebase were AI-assisted, what prompts produced them, or what the AI tool had access to when it generated the code.

What this means in practice

A code reviewer looks at a function. It's clean, it passes tests, it looks reasonable. But was it generated in one shot, or was it the result of fifteen prompt iterations? Did the developer ask the AI to optimise for readability or performance? Did the AI have access to the full codebase or just a single file? These questions change how you review. They change what you trust. And right now, there's no way to answer them.

For engineering leaders, the question is broader: what percentage of our codebase is AI-assisted? Which tools are our teams using? Are we developing institutional knowledge about effective prompting, or is every developer starting from scratch? Without structured records, these questions are unanswerable.

Introducing WHENCE

I've been working on WHENCE — an open standard for recording how AI contributed to a codebase. The name is the question every code reviewer asks: where did this code come from?

WHENCE records prompts, tool metadata, and code context (what files the AI saw, what diff resulted), then links those records to Git commits using Git notes — which means no pollution of commit history.

Traces are shared by default, because the whole point is that reviewers and auditors can see them. Sensitive content is redacted at write time, before it enters any Git object.

The standard is tool-agnostic: a trace from Claude Code, Codex, or Cursor should all be valid WHENCE. And the data format is deliberately separated from the linking mechanism — the spec currently defines a Git binding, but future bindings for GitHub, Bitbucket, or GitLab are architecturally possible without changing the core format.

The reference CLI is git-whence, and it's designed to fit into existing workflows: prompts accumulate in a local queue during development, and you attach them to your final commits after you've rebased and cleaned up your history. CI verifies that traces are present and valid. If a commit was co-authored by an AI tool that self-identifies (like Claude Code's Co-authored-by trailer) but has no WHENCE trace, that's a policy violation your pipeline can catch.

What I'm looking for

WHENCE is at the draft spec stage. The format is defined, the edge cases around rebasing and secret redaction are handled, and the spec has been through multiple rounds of technical review. What it needs now is feedback from the people who'd actually use it — engineering leads thinking about AI governance, DevEx teams building internal tooling, and developers who want their PR reviewers to understand what they were trying to do.

The spec is here: github.com/zmarkan/whence/blob/main/SPEC.md

I'd particularly love input on the CI integration story (what policies would your team actually adopt?), the code context fields (what would make traces useful for your review workflow?), and alternative bindings (if you're on Bitbucket or GitLab, what would a native integration look like?).

This is early-stage work on a problem I think every engineering team will need to solve. I'd rather we solve it with an open standard than with fifteen proprietary formats.

Standards

xkcdAbout

Have you ever wondered how much greenhouse gas emissions can you save by deleting your unused data? 💾💨And what if your entire country did it?

I recently discovered that Slovenia is running a new community initiative titled "Digital Cleanup Day", where the goal is to delete data that's sitting idle and unused on our devices, and in cloud services. They have some big backers from the industry and even the Ministrstvo za digitalno preobrazbo / Ministry of Digital Transformation is on board. It’s part of a wider Digital Cleanup Day initiative. If you’d like to take part, the day to mark on your calendar is 16 March 2024.

The idea behind the initiative is to boost awareness of how digital waste contributes to CO2 emissions as well, even though we don't regularly treat it as something physical, or even real (it's all in the cloud, innit).

While the website - https://digital.ocistimo.si - tends to liberally mix the costs of RUNNING a website (roughly 0.03g CO2 emitted per page view of their own site) and the initiative is all about deleting your data AT REST (and I’m bothered by such discrepancies), I find the idea behind the initiative to be generally sound. More importantly, it got me thinking about what savings we can reasonably expect to see, especially if everyone did in fact chip in.

While you can scroll to the end of the post to see my final figure, let's crunch some numbers! 🤓

You can also find my calculations in this spreadsheet: https://docs.google.com/spreadsheets/d/1CqD5QuKVwIVnkuZlSKtLY_Hoz5vxfLYYwPU_Q5GFb10/edit?usp=sharing

Now, before you grab your pitchforks, I have some notes and disclaimers:

Notes and disclaimers

This article is intended to entertain and to get you thinking. There are edge cases I haven’t considered, and I simplified a lot to make it short and concise. Think of it as Google’s ping pong balls in a bus question, but with CO2 emissions. At the very best, I used some quick and dirty back-of-napkin math.

I also ignored the fact that any operations we conduct such as deleting the data will undoubtedly also emit CO2.

We also don’t take into account how much of the savings will persist, and when will the data just be filled with some other digi-rubbish, most likely AI generated.

First, let's figure out how much data we can feasibly delete.

How much digital waste data can a nation delete?

Let's say that every single one of the 2.1M residents of Slovenia deleted 50 gigabytes (GB) of data.

Maybe that's a bit generous, but I have deleted movie libraries, games and LLMs way bigger than that, not to mention the collection of terrible photos I have stored on Google. 50GB is also roughly 10% of the entry-level Macbook Pro storage as of early 2024, so we’re going with that as our figure.

Let's also assume that all of that data is deleted from cloud services, and not from your local devices, so that we can calculate running costs for all that data in the cloud.
Local data has a running cost close to 0 because you're probably using your phones and computers regardless, and likely don't use your devices just for data storage. And if you hit the storage limit on your devices, you’d delete that digi-crap regardless of whether it was the Digital Cleanup Day or not.

2.1M residents x 50GB of data gives us a total tally of 105 petabytes (PB) or 105 million GB or 105,000 TB - you get the drift.
Now, we need to figure out how much energy a datacenter consumes per unit of storage.

How much energy does a datacenter consume?

On the site cloudcarbonfootprint.org it is estimated that 1TB of HDD storage in a datacenter uses roughly 6.5Wh. Let's multiply by 3 to cater for the replication factors (I’ve taken the value for AWS S3) which gets us to 19.5 Wh/TBh.

We're interested in yearly tallies, which, multiplied by 24 and 356 brings us to 170.82 kWh per TB-year. That's less than our house’s solar panels produced so far this year, by the end of February in the famously blue-sky-shy London.

Putting the two numbers together, and multiplying our yearly data center consumption by 105,000TB of data we'd hypothetically be deleting, gets us a whopping 17.49 GWh of energy that Slovenians would save in a year, were it not for that pesky digital waste.

For a single person deleting 50GB of data that would mean an annual saving of 8.33 kWh.
Finally, for the fun part, let’s calculate the CO2 emission savings from all that deleted digi-garbage.

Calculating the CO2 emissions savings for deleted data

Staying close to home, next to my hometown of Velenje there's a rather sizable thermal power plant - Šoštanj Power Plant. It’s the one in the header photo in all its glory. It burns lignite, which is like coal but less energy efficient and more polluting, and accounts for between 20-30% of Slovenian electricity production.

What if all of the energy saved came from that power plant, as a worst-case scenario. Coal is, after all, terribly polluting. Luckily, it belongs to a state owned utility company that produces reports. Here’s the annual report from 2021 (in Slovenian).

The TL;DR is that in a year, our power plant produced 3,137 GWh of electricity from burning 2,833 kt of coal, which produced 3,266 kt CO2 emissions in 2021. It also produces municipal heat from some of the coal, so I had to work out the CO2 emissions just related to electricity production.

Our projected savings of 17.49 GWh from deleting all that data would therefore translate to a reduction of 18,214t of CO2 emissions.

That figure shocked me. That seems like a lot of emissions, especially once you imagine how much CO2 by volume 18.2 kilotons must be. it’s 9,940,933.5 m3 or just under 3977 olympic swimming pools, if you like swimming. A lot. That's of course the best (or worst, depending how you look at it) case scenario, where all the electricity came from burning the most CO2-emitting source of energy.

Looking at a single person deleting 50GB, they would reduce the emissions by 8.7kg. To put it into perspective, it's a bit more than a large Thanksgiving Turkey in weight, or roughly 1.4 Cybertruck cargo bed spaces worth’ of volume.

Conclusions (it’s not that bad, really)

Now, companies operating data centers are usually very proud of their green credentials, and, if they can avoid it, they will probably not buy energy generated from coal, let alone lignite.

Instead, they will purchase their energy (or generate it) from renewable sources, meaning the actual emission reductions are likely much lower, in some cases probably also close to zero.

AWS for example boasts that 90% of their data center consumption comes from renewables, including 100% for a lot of their US data centers (yes us-east-1 is there). https://sustainability.aboutamazon.com/products-services/the-cloud?energyType=true

Google on the other hand has a plan to go fully carbon neutral by 2030 - https://www.google.com/about/datacenters/cleanenergy/

So, here you have it. How much CO2 could a small nation save by deleting a handful of files each?

Somewhere between 18 kilotons and zero, I guess.

Still, if you want to participate in the digi-trash cleanup day and delete some of your e-junk - check out the site: https://www.digitalcleanupday.org to learn more.

And if you want to look at how I worked out the numbers - here’s my spreadsheet: https://docs.google.com/spreadsheets/d/1CqD5QuKVwIVnkuZlSKtLY_Hoz5vxfLYYwPU_Q5GFb10/edit#gid=0

For all its tragedy, the Covid crisis has created some interesting opportunities. One of them is a large scale trial of remote working. We have proven that it works, and it can be done.
I believe that places such as the European Union should now enshrine this into law as the Right to Remote for every citizen, regardless of where they live and work.

The proposed Right to Remote will let every employee who can reasonably do their job remotely (every office worker) choose to do their job from anywhere in the EU. It offers many benefits to the economy, the health of our democracy, equality, social mobility, and the planet as a whole.
In this article I present, and advocate for the Right to Remote, how it could be applied, regulated, and what benefits it brings to the EU.
While this article is written towards the EU, it should still be applicable for other countries.

Disclaimer: I am an EU citizen, and I live in London, UK. I'm one of the 3 million people, who moved here when it was still firmly (and proudly) one of EU capital cities.‌‌‌‌

While the UK and London unfortunately aren't in the EU anymore, in my mind and heart I still consider London as an European city, as it was when I moved here several years ago.
Some examples in this article will mention London in that context, so understand where I'm coming from.

Why focus on the EU specifically?

First of all, it applies to me personally. I'm a EU citizen who benefited by the four freedoms, and I'm proud to be one.
I also know Europe best. It's home, and I understand my fellow Europeans more than I can ever hope to understand Americans, Bolivians, Chinese, or any other nations.

Finally, I think that something like Right to Remote can be implemented here, should be implemented here, and must be implemented here - for the Union to continue and to thrive.

Today, 9 May 2020 is also Europe Day, and the 70th anniversary of the Schuman declaration that marked the beginning of the integration process that we now know and love as the EU. We have many problems, but we have proven that we're at our best when solving them by integrating.

The EU is in trouble

EU is in peril, facing the greatest recession (if not depression) it has ever faced. I think the post-Covid era will be harder than post World War 2 - for one, we don't have a big America-shaped buddy with loads of cash on hand ready to help us get back on our feet.
There are however futher challenges that EU is facing beyond Covid, and these are rooted both in our politics, as well as our economy.

The EU is terrible at PR. We're just not united enough for a common identity to be strong enough to matter to most. This makes us prone to propaganda coming from all sides, both externally and internally.
We didn't help Italy fast enough, and then China jumped in. Although EU donations have been much more prominent than China's, it's China who's in the news as their lord and saviour. Great PR on their side, and a massive failure on ours.

There are more fundamental problems the EU faces, such as the discrepancy between "winner" countries and "loser" countries. Winner countries benefit the most from the integration, tend to have well balanced budgets, and are desirable targets for educated migration. Loser countries don't benefit as much. They face brain drain, aging population, as well as running high deficits.
Besides the winner and loser countries, there's even starker divide between cities and surrounding countryside.
The cities tend to be more developed than the rural areas, running a higher surplus, and sheltering a "metropolitan elite", yet they are also facing much greater levels of inequality, high costs of living, pollution, and overcrowding.
The rural areas have a lower cost of living, but also less opportunities for career progression. This regional divide has helped foster the rise of populist movements, and a "us vs them" mentality in many European nations and the world.

Economically, some countries are heavily reliant on tourism. When thats decreases for whatever reason, they are in deep trouble. Some other countries lean on their manufacturing muscle. Even Germany, our economic engine, faces great challenges. German economy runs on internal combustion, yet as we as a society try to move away from burning dinosaur bones in order to hit our climate targets (so we still have a planet to live on a hundred or so years from now), that industry is leading the world at producing pretty much obsolete technologies. Not enviable.

Combine these economic troubles and internal divisions with the bad PR, and we have even more dissatisfaction everywhere.

Why the EU is great

For all its shortcomings, the EU has many things going for it; The EU started in the mid 20th century as a project to bring its long time enemies together and stabilise a continent otherwise known for its discord. It has, in many ways, achieved this. Where once were borders with walls and barbed wire, there now exist bridges and welcome signs.

The EU as a whole has also been one of the rare beacons of democracy and global progressivism. This is especially true during the last few years and decades, where many of the world's nations have sunk deeper into authoritarianism. We are a family of countries with the strongest social and worker's rights regulations on the planet. We are most committed to clean energy and conservation. With GDPR, we also have the strongest privacy regulations.

EU is indeed the world's regulation powerhouse. Through our trading deals, we are also able to export some of that regulations to other parts of the world, be it animal welfare standards that regulate our food production, or consumer and privacy protection laws that prevent fraud. The process to pass any regulation on an European level is meticulous and relies on consensus building. While lengthy, and by some perceived as overly bureaucratic, it is designed to leave no stone unturned, and no voice unheard.

Our present remote reality

There is no way to say this nicely - Europe, and the world in 2020 is a terrifying place. Between the UK, Italy, and Spain we've nearing a hundred thousands dead. By the time you read this it'll likely be way over that.‌‌
In addition to all the dead, unforeseen numbers of people have lost jobs and their livelihoods - either as a direct result of COVID-19 related lockdowns or companies downsizing due to a lack of demand or rightfully predicted global recession that the world is rushing into. ‌‌The "outside and leisure" economy has stopped - bars, restaurants across Europe and the world have largely gone deserted, tourism doesn't even exist anymore - all due to a pandemic of COVID-19 that's currently ravaging through the land. With the exception of a handful of people deemed key workers, best we can do is stay at home as much as possible.

Yet, there's another exception - for us lucky enough to be office workers who kept our jobs, our work hasn't stopped for the most part. We switched whole industries to online-only, not just online-first. All meetings, all communication went from 'get people into a room' to 'get people into a Zoom room', seemingly overnight. My own industry - developer relations, used to rely heavily on live in-person events, and yet has managed to switch our focus to online, become leaner, and even more inclusive in the process.

Where in the past IT teams have blocked work outside of office for security reasons, these same teams have now revised their policies, rolled out VPNs and trainings, and enabled us to all work from home. Even things that were unheard of, such as parliamentary and cabinet sessions have made the shift to remote. What's even more remarkable, all of this seemingly happened overnight.

Work continues, and industries have undergone a digital transformation in days where before they had botched it for years. This shows what is possible to achieve, when there's a will, and an urgency. As a whole, we have proven that such a switch is possible, on a global scale. That's a great, irrefutable data point.

Now, imagine what we could achieve, if we continued that in "normal" times? How we act now will influence our readiness to combat the next. The climate crisis didn't go away. Our unemployment is even higher, democracy is eroding, and Europe still lags behind in the sheer health of our economy.

The proposed Right To Remote

I propose a new European regulation that would allow any "on-site office" worker to choose to work from anywhere within the EU. I call it the Right to Remote.

It would on one hand eliminate location from the equation, bringing benefits to both employees and employers, further increasing a pool of available talent for businesses, reducing their office costs, and at the same time bring greater flexibility to workers across the EU.

Embracing this new reality is the best thing Europe can do to ensure our own economic prosperity, our citizens, and the planet.

Let's break down the specifics:

Who can chose to work remotely?

By "on-site office worker" I mean anyone whose job can be reasonably conducted in a distributed manner.
That's last part is the caveat. Remote work cannot be (and isn't) applicable to every job. In fields such as healthcare, manufacturing, agriculture, fishing, construction, retail, hospitality, and many others it is still required for many jobs to be done on-site. However, things like technology, administration, accounting, and many services jobs can be done remotely, as we have proven in the last months.

Who pays (and collects) the taxes?

Right now, employees pay income taxes in the country they live. This should continue. If you live in Croatia working for a Czech company, your income taxes should go to Croatia. We already have this system in place for people who currently work remotely, either as sole proprietors, via umbrella companies, or similar. They pay the taxes where they live, and as they live where they work - that's a rather easy calculation.

How would employees opt-in?

This should be a right of each employee to choose whether to work in a provided office, or not. Companies couldn't enforce office work anymore, as they aren't able to now. The choice should be presented at the offer of employment, and the offered remuneration shouldn't differ.

For example, if a Munich-based company hires a worker who lives in Munich, they would of course still be welcomed use the office as a working environment, but if that same company hires a worker from Madeira, Malmo, or Maribor, they cannot force that employee to relocate to Munich (they can of course opt to relocate, exercising our right of EU citizenship).

Can employees work remotely one day and in the office the next day?

No. Right To Remote doesn't mean that employees can be remote one day and in the office the next day (unless their contract explicitly says so).
Once an employee has chosen their preferred way of working (from an office or remotely), that becomes part of their contract, and should let companies plan resources accordingly. In case their life situation changes, they should be able to change that (office to remote, or remote to office).

A similar situation arises if an employee decided to move between countries. Due to differing tax and national insurance regulations across countries, each move will likely still go through HR and accounting processes (yet will likely become much more streamlined).

Is this a quick change?

No. This is a transition that will take years to implement. First, this proposal needs to be considered by the EU to even debate it, then go through all the usual steps required to pass any EU-wide legislation.

Likely will be first implemented on a country by country basis, before being followed by a true international approach, and done so with a generous implementation period. 10 years is a more likely timeframe.

Is Right To Remote a ban on offices?

No. It's just a choice given to employees. I see it as a convenient way to reduce operating expenses of businesses across the EU, while expanding their talent pool to the entirety of the EU. Offices can still be offered as perks, and local teams can still choose to work from offices if they desire to stay together.

Reasons and benefits of Right to Remote

I see many reasons for implementing Right to Remote, covering all aspects of our society - from benefits that impact us as citizens of Earth, to benefits to individual countries, and cities - large and small. There are also several good benefits for global cities that currently draw all the jobs, and the businesses that create all of them.

There are four main categories, and I'll go into detail for each of them:

1. It's our best chance to reduce our climate footprint
2. Higher equality across the continent
3. Bridging the regional divide
4. Advantages to business and competitiveness

1. It's out best bet for reaching of our climate targets

Europe is trying hard to become the first climate-neutral continent in the world. It's an incredibly ambitious target for sustainable economy, and requires us to entirely decouple our economic growth from resource usage. Europe is already leading the green revolution, but we can, and should, do much more.

The COVID lockdowns have proven that as people commute less there is an immediate and substantial reduction in greenhouse gasses and pollution we produce. The Right To Remote is a great way to continue on that trend. Without it, we'll be back to "normal" as soon as the continent is out of the lockdown, and people travel en-masse to work again.

There are further benefits beyond the climate‌‌

Climate benefits brought by Right to Remote will have the greatest impact on the planet, so they deserves to be put first, yet reduction in carbon output and pollution that comes along with it has many other beneficial factors. ‌‌Our cities will be cleaner, and population will be healthier - both phisically and mentally.

Right now, our cities are massive population magnets, as most people shift in and out of them on a daily basis. All this traffic results in heavy pollution. Areas of London usually reach the allowed pollution tresholds in the first week of the year!‌‌ With the Right to Remote millions of workers could opt out of daily travel to some of the most polluted areas of the continent, making them healthier, and in turn reducing the strain on our health systems. ‌‌We could reclaim hundreds of millions of hours from commuters across the EU each month, increasing potential productivity and creativity on a truly continental scale.

Finally, our cities would become more resident-friendly. I think we can all agree the the most pleasant parts of our global cities aren't the American style CBDs. If anything, these centres are deserted during weekends - a terrible waste of space and expensive real estate. Wouldn't it be nicer to instead prioritise more affordable residential space, walkable new high streets and parks, and community centres instead of CBDs?‌‌ Moreover, this shift is already happening - Barclays bank's bosses already predict a shift away from office towers, and I believe many more will follow.

2. Higher equality across the continent

Right now, our largest cities (and metropolitan areas) have an increasing advantage over the rest of our countries. They offer more jobs, more people, more money, more economy. Because of all that, they tend to draw even more people towards them, in turn concentrating even more jobs, more people, more tax money, accellerating these differences in a perpetual cycle.‌‌ At the same time, the rest of Europe is falling behind. Towns and even smaller cities have little to no chance of competing with our top cities (capitals, more often than not). The same goes for countries to the south and to the east.

I myself am a good example of that cycle. I'd left my home town and country behind, drawn to the more cosmopolitan life in a global metropolis. Admittedly, not just because a much better financial situation I'm in now, but also because of access to the world's greatest museums and transport connections.

Better income and wealth distribution on all levels‌‌

Right to Remote would take some of the pure economic factor out of the equation, and let us put a pause to that cycle, by giving smaller cities and regions a fighting chance. While many struggling cities and countries still wouldn't be able to compete with largest cities in culture and amenities, they could compete on living standards, food, weather, and smaller crowds - the quality of life stuff.

As high earning jobs get distributed more evenly, so will the corresponding taxation income, and spending power. Countries in the European south, most heavily dependant on tourism, could now expect to gather some extra tax money from their residents' income taxes - who work in the services sector. Conservative minded readers might find it compelling that this would require no particular handouts, just their warm weather, good food, great vibes and working environment.

Larger cities on the other hand might see a dip in their taxation incomes, but these will be countered by reduced spending on transportation, utilities, healthcare, and social services required by fewer people and due to reduced pollution.

Reduced and reversed effects of brain drain‌‌

Another common result of good education and struggling local economy is brain drain. Students get educated in their home countries, and then move away for better opportunities.

With Right to Remote, fewer people will leave their home countries because pay is better in Germany, the Netherlands, or Ireland.‌‌ If you're Italian, Latvian, or Slovenian like myself, who studied for free, only to pack my bags and move out you know what I mean.

3. Bridging the regional divide

With accellerating economic and social differences resulting of people moving to large cities in prosperous countries, there's another massive problem occuring. Look at a recent election results and think about what you see? Largest cities tend to lean progressive, whereas the countryside tends to be less so - even bringing up the rethoric from the 1930s and 1940s, the worst times in European history.

Less us vs them politics‌‌

This divide is accellerating, seemingly even more rapidly than the economic divide mentioned in the previous section. Our discourse is becoming more and more populist, and geared towards a "Us vs Them" mentality. I am frankly scared of this division. Coming from the Balkans, I was born in what was then still Yugoslavia, and grew up up in the aftermath of a violent breakup of that union. Croatian and Bosnian wars, the siege of Sarajevo, and Srebrenica genocide were all happening a few hundred kilometres away from home, and were commonplace in the news.

I am publishing this article on 9 May 2020, Europe Day and the 70th anniversary of the Schuman declaration that gave this union a start. A day before we celebrated the 75th anniversary of VE day, and the end of World War 2 in Europe. The timing of this blog post is not a coincidence.

The way Right to Remote would stem this divide is by letting more progressive folks who are currently city dwellers move out, which could help bridge that divide. It would shift the electoral bases enough to matter, and bring us to a more civilised, centrist discourse. The same goes for the increasing Chinese and Russian influence and propaganda which tends to find fertile ground outside of large cities and "western" countries. We could, and should stem this by forcing open our sociogeographical echo chambers.

Increased mobility through freedom of choice‌‌

Freedom of movement is one of the fundamental rights that EU citizens enjoy. I can recall first hand how it has literally brought down borders with the Schengen agreement. Yet, it's a double edged sword. I don't think that people right now can really move unless they have the means to do so. As usual, it boils down to the basic economics.‌‌With right to remote, people will be able to move even more freely, and live wherever they please. You like German system of universal childcare better than the one in the Netherlands? Good, move there. Need to move back to your hometown care for the elderly relatives? Great, your job will let you do this.

Or consider the great programmes such as Erasmus, that have enabled students across the continent to study and live in a new city and country, increasing their exposure to other european cultures, and improving the sense of European citizenship and belonging. Ask any Erasmus student about their experience and they will pretty much all tell you how great and valuable it has proven for them. Right to Remote would offer more of the same, and expand it to everyone, not just to students.

4. Advantages to business and increased competitiveness

Finally, let's talk about the impact of Right to Remote on our European economy. Besides the potential direct savings in office space and any travel benefits offered by companies, I believe Right to Remote will have a positive impact on European competitiveness.

Take technology. While our industrial sector is decently developed, we currently can't compete well with large US technology companies. With more and more of us moving our lives almost exclusively online this shows our reliance on the US companies even more. This shouldn't be the case.

Pan-European talent pool‌‌

Right to Remote would make it even easier for companies to hire from anywhere in the Union. No more location specifics, no more expensive office clusters, just direct access to the best talent in Europe, bringing to fruition the REAL single labour market.

With Right to remote companies would be forced to innovate more, as they adapt to the new remote reality. The global shift to remote work is happening already (right now, it's more of a temporary trial), but we could be ready for when this goes global, and lead.

The need (and opportunity) to develop world-leading technology‌‌

Often the greatest inventions arise from the greatest need to solve a problem. Right to Remote would force on us a new big problem - collaborating effectively across distances, on a continental scale.

Of course, there are already the Zooms and Slacks and Microsoft Teams of the world, but honestly - who likes these? They're passable at best, and horrible at their worst. As European companies are forced to make Remote work, there will be new companies and tools popping up, made by European entrepreneurs, who will solve that problem - and ready to export this technology when the rest of the world catches up.

In addition to that, we'll have to ensure that the infrastructure is in place for Right to Remote to truly be possible (and effective) across Europe. This will require both public and private invesment in more fibre lines everywhere, as well as high speed mobile network connectivity.‌‌Infrastructure investment is often a pre-requisite for rapid economic development, which will put us in an even better position for the next 30 years as technology progresses.

Requirements, challenges, and drawbacks

Of course, implementing a change as profound as Right to Remote will not come without its challenges. Compared to Right to Remote, GDPR is a minor regulatory hurdle.

Avoiding an accounting nightmare‌‌

A concern I saw on Twitter from a small business owner was due to the excessive regulations and processes of salary payments across the 27 countries of the EU. That can be seen as a considerable challenge, yet we've solved similar problems already.

A few years ago, a law came into effect that required any product sold online to be charged VAT to the buyer's country. 27 different tax agencies, with almost as many taxation levels. Yet, the businesses adapted. Most platforms that let you sell across the EU now charge the right tax automatically, with almost no extra work for the business.

I can see the labour laws and taxation around Right to Remote solved in a similar way. All we need is some good accounting software that will solve for it, and we're good to go. Looking at my previous point to business benefits - this could be an opportunity for European companies to start rivaling Intuit or Xero.

Loss of jobs due to fewer people in cities

A friend of mine argued on LinkedIn that a full on switch to remote work would be catastrophic for businesses in the service sector. Not merely the hospitality sector that services our cities, but also the industires servicing our offices.

First off, the offices won't vanish. Making this change will realistically take years, possibly even a decade. That's plenty of time for businesses and individuals to adapt. Secondly, local businesses will thrive even more. While the largest cities might contract a bit, many smaller places will gain their workers and shoppers. As people spend less time commuting back and forth to work, and spending that time (and money) on leisure activities closer to home.

Infrastructure investment not equal across the board‌‌

Right to Remote will increase equality, yet it also requires equality. We need equal opportunities to partake in remote life in Europe - whether you're in Stockholm, Siena, or Sevnica.

I argued earlier that we will need to invest a lot in infrastructure required by Right to Remote. We are already investing in fibre connectivity in rural areas, but we'll need much, much, more. I can see a lot of these funds coming from centralized, EU-wide sources - either funding nationwide projects, private concessions, or a mix of both. What we need are clear targets, and a plan to achieve it.

What about Remote Worker's rights?

EU wouldn't be EU without our high standards of welfare, including labour rights. They tend to be better on average than any other place on the planet, and Right to Remote needs to ensure that. Our rights aren't equal however. In fact, they aren't even close to being similar. A questions presents itself in whose rights apply where?

It would make sense for the employer to make everyone align to the country where the business is registered - in terms of holiday, sick pay, etc... ‌‌On the other hand, as employees pay income tax and social benefits in the countries where they live, it would only be fair to receive the social benefits in accordance to local standards. This is the one question I'm not sure how to answer. Personally I'm leaning towards the latter options - apply the laws of the state where the employee currently resides, as it's currently the practice with companies that have branches in several EU countries.

Conclusion

To conclude, a global move to remote work is happening. With Covid we have been forced to try it out, and prove it's possible for all office-based work.

Today the European Union has a choice of either leading or lagging in this movement, by enshrining the Right to Remote work into law for every citizen, to work for any EU-based company, from anywhere in the EU.

Leading this charge will present us with many new challenges, but ultimately position us, the bloc, continent, and the world, much better for the future. It will allow us to help our people, our planet, and the profits of our businesses for many future decades.

Let me know what you think by either tweeting or emailing me.

‌Thank you for reading, and Happy Europe Day!

I love software development. I have been doing it professionally for over a decade -  starting as a full time developer at my own startup, a team lead, and now as a developer advocate. Throughout my career, the proportion of time I was paid to write software has varied a lot - I write a lot fewer lines of code than I used to, yet I still enjoy it. But why?

I haven't thought about it much in the recent years - development is just what I did, end of story. Until this past weekend, that is. I got thinking about things like what exactly makes people love software, and software development? Why do I personally pursue it still?

And why I started thinking about it? Because of a bug, of course. This is my story.

Over the past weeks I have been spending much more time hacking and building software than I had been in the past couple of years.
Maybe it's the new reality of being locked down, but I started having tons of fun just hacking again. Early mornings before work, late evenings after work, and weekends, just going at it, having fun building things.

It starts with a bug 🐞

One of the projects I undertook was revamping my blog. I also decided to add a subscription feature with email integration to it. Each time I publish a new article, I want to send an excerpt of that blogpost to my subscribers. Something something keeping me accountable for writing more.

While building it, I discovered that each published post triggered two emails instead of one. As a bug, this was rather straightforward to solve, but it got me thinking of how many options I had for solving it. From reasonable choices to absolutely batshit crazy this-should-never-work-but-does-anyway kind of options.

I haven't had this much fun writing software in years. I told the story as it happened in this Twitter thread:

Why we ❤️ software

There is a good reason why I am in this industry, and have been for my entire career. And it's not just the decent pay.  

I have always found something interesting when writing software. Is it all about being faced with challenge and overcoming it by devising elegant solution.

This fondness for challenge is universal. Applies to computer science as much as it does to real science, and to making apps as much as it does to making automobiles and airplanes. Making an app as much as it does making a bookshelf. Every single videogame exploits that to keep you engaged.

Then it occurred to me, what delights you depends mostly on your motivations, and your motivations can (and will) change throughout your career.

When I was learning the basics of programming in C and Python, I found great joy and pride in finding a great, optimal algorithm. Fewer lines of code. Faster execution, optimised for memory. Stuff big tech companies tend to ask about on interviews.

This however, didn't stick with me for long. While I have immense appreciation for every algorithmic guru out there, I myself am way more of a cowboy coder, with too little patience for that 🤠, and believed (and still believe) that done is better than perfect.

I discovered I enjoy designing elegant systems and tooling more than I enjoyed making elegant algorithms.  Seeing a system that is well tested, and has well automated builds that instil confidence is delightful. My measure for a well tested system? One that lets you deploy at 5pm on a Friday before confidently heading to the pub for a few pints with the team that just shipped🍻.

So later on, I found that what really delighted me was making (and shipping) great software products.  Features, apps, tools 🛠️, whatever. As long as people use them, find them valuable, and ideally makes them more productive.

Whether it's individuals, dozens, or millions. Nathan W. Pyle describes this well.

Delight in DevRel 🥑

I'm not a developer anymore. As a developer advocate, nowadays my job is primarily enabling developers. As I grew as an engineer and developer, I found myself becoming more and more passionate in empowering people around me to become more productive. On both an individual level, as well as on a team level. Seeing a team that grows as engineers - a team that becomes 10-X of itself in a short time. Now that's delightful.

This is something that has stuck with me when I entered the world of developer relations. My focus now is less on building software myself, and more about enabling others build better software. Developer advocacy is all about people - celebrating them and advocating for them. I love seeing brilliant folks devise awesome solutions, products, and hacks - ideally using the tools of the company that I'm representing.

Nowadays, my personal tool of choice is storytelling. Regardless of whether it's delivered on a stage, written in a newsletter, or told to an individual in a Zoom call. I find great enjoyment in inspiring people. It's amazing when folks reach out to me and tell me they learned something from my talk, or that my article had sparked joy. To me, that's pure, unabashed, delight and what keeps me going, excited for what tomorrow brings.

Coming full circle ♻️

As for the story from the beginning of this post, the little bit of hacking that I have been doing in the past few days was fun. It certainly has rekindled some of my enthusiasm for building and shipping things myself.

In particular, what I found the most inspiring was how many ways I could come up with to solve a particular problem - good, bad, but especially the terrible ones. I don't think they ask that in Google system design interviews, but it's fun.

In my tirade on Twitter, I counted 4 ways to solve my bug. Later, I counted some 5 more (yet I couldn't top my very worst one, and believe me, I tried.).

This freedom of choice, choose your own adventure is extremely powerful. It gives us control over the machinery that runs our world. All you need is a computer and an internet connection, and the World is your oyster.

If you find one takeaway from this, think about what delights you with that you do? Have a ponder, and pursue delight, deliberately.  

Oh, and don't forget to smash that brand new shiny subscribe button if you enjoyed this story 👇

I enjoy writing. As a developer advocate, communicating is at the core of what I do. I write blog posts, talks, technical docs, proposals, and everything in between. My content is aimed for both external and internal audiences, and folks with varying backgrounds and levels of technical proficiency.
Being able to write productively and write well is what makes me good at my job. In this post I will share the method that helps me write - Starting with a series of sincere sentences.

I've been using this method for about a year, but what prompted me to write about it was an excellent blogpost by Swyx about his method of writing that he calls mise en place writing. The terms comes from professional chefs and describes how they prepare their stations for cooking.

swyx Writing | Mise en Place Writing

How to write more, faster, and better by decoupling writing from pre-writing

Mise en Place Writing

The idea is that you prep everything in advance, before starting to write your article (or blog post, or chapter).  I see my method as an extension of mise en place writing.

After deciding on a topic, and doing my research I start by writing a a series of short, factual sentences about the idea or ideas I want to convey in the piece I'm writing. I write as many sentences as possible, each telling a single idea or truth of what I'm trying to write, and then rearrange and reduce them until the end product emerges.

This writing technique has helped me write most types of content, including technical documentation, thought leadership blogposts, tutorials, marketing copy, talks and presentations, and everything in between.

The devil in the details 😈

Before starting to write, I often have an idea for an article or a blog post. That's my end goal. Thinking about the end goal my frst objective is to put all my knowledge and thoughts in a document, before starting to polish it.

The key is to start creating content without worrying about the details. Over-focusing on details often leads me to unfinished content, which doesn't help anyone. In the past, I would often spend a long time writing the perfect introduction, or a single chapter, before losing patience and energy (and starting my PS4 and forgetting about it).

Start with Several Sincere Sentences 📜

So, to avoid stressing about details, I instead just let my creative juices flow and write a bunch of sentences.

I stick to a few guidelines when writing the sentences:

• Once idea per sentence
  Sentences must be atomic, and only express a single point. I write them one in each line. As sentences express a single idea, it will make them much easier to arrange in a narrative in a later step. The first sentences in this list are a good example of atomic sentences that express a single point each.
• Sentences must be sincere
  You need to agree with them. If writing technical documentation, every sentence needs to also be correct, and supported by facts. If writing an opinion piece, they need to support your narrative.
• There is no upper limit of sentences
  While sentences must be correct and atomic, you should write as many as you can. The order isn't important. The more you write, the more options you will have, and the easier it will be to produce the end result.
• Analogies are encouraged
  This is an extension to my previous point on there being no upper limit of sentences. If you can write analogous sentences supporting your idea, you should. They will give you even more options when you are crafting your final product, and let your writing be more dynamic.
• Sentences must be sincere, yet counter points are encouraged
  All good writing must also explore counter arguments. If there's a possibility for someone to disagree with your idea, you should accept that, just make it clear in the sentences you write which ones are exploring the counter arguments.

Following the above points, I often emerge with dozens, if not hundreds of sentences about the topic I'm planning to write about.
We are now ready to let the story rise from the chaos.

Clusters, Sections, and Chapters 📦

Once I have written what seems like enough of ideas - it's time to start clustering them. This means arranging them into a logical groups talking about the same general idea. If this seems familiar to you - it is. Every single retrospective, brainstorming, and ideation session has the same basic idea.

Once I have my clusters of sentences, each of these represents a section or chapter in the final product. Ideally, I can pick a sentence from each cluster that serves as the section title, or take bits from several sentences. I'ts also perfectly fine to reword them, whatever serves the story best.

At this point I might also look at the clusters and decide on the ordering, as it will work in the final story, and let the narrative emerge. I often also select a few sentences across all chapters that will serve as ideas to use in my introduction and conclusion. Here is why the analogous sentences help a lot - as you don't need to repeat yourself, yet still get to repeat the idea.

The final stretch 🦉

By now I often have have a clear idea of the narrative, section split, and what to want to convey in each of the sections.

This might be a good time to review the sentences in each section again, and remove what isn't necessary. Less sometimes is more, and throwing away is good and lets you focus on what's most important to the story.

Finally, all that remains is turning the sentences into actual prose. The content is there, you just need topolish and mold it into something pleasant and meaningful - by merging, tweaking, and rewriting.

Or, as the old adage goes - drawing the rest of the fucking owl.

Conclusion

Starting with a series of sincere sentences is my riff on mise en place writing method. Prepare your content, and add detail later.

I've been writing this way for over a year now, and applied it to everything I write - from technical documentation, to blog posts (including this one), and even my talks and presentations and emails. It has definitely helped me overcome writer's blocks on several occassions, and let me produce more content of higher quality.

If you found this useful, and you start using this technique, or have any remarks about it, do let me know!

Happy writing! 📝

Last night I had the pleasure to participate as a guest on a podcast by my friend Matteo Doni of Tech Travel Geeks, talking about one of my passions - Craft Beer. We had a lovely chat with Alana Harris and Matteo - all from our respective cities  and countries - like good little social distancers!

The pub style debate ranged from Brewdog (of which we all are shareholders!), and our (other) favourite craft beers, beer styles, gluten free, non alcoholic beer, favourite advertisements, and deep thoughts on what makes craft beer...  craft.

You can watch the video recording right here - or on Tech Travel Geeks' YouTube channel. Cheers! 🍻

This post was originally published on DEV.to.

A while back I took part in a lunch & learn session at work, where we discussed the paper Serverless Computing - One step forward, two steps back. It was an excellent discussion, and if there weren't any time constraints I'm sure we could have talked about it for the rest of the week, not just our lunch hour.

Note: In my eyes, serverless is not just AWS Lambda functions. Or Azure, Google, or IBM/Apache Openwhisk. It's all the other technologies that work well alongside it - databases, queues, event-driven computation, and technologies that make it super easy to configure and deploy new services in code.

What made it such a great discussion is the fact that while most technologies are polarizing, only a few are as deeply polarizing as serverless.

The Serverless Hater's greatest hits include:

• serverless has servers
• I can't use it for machine learning or [insert obscure academic research topic here]
• It's more expensive than renting your own EC2 instances and running your own servers!
• Vendor lock-in!
• It's slow!
• I can't run it on custom hardware!

All of these… are true in their sense. Not all use cases are well supported by serverless technologies (or at all).
My argument is just that… it doesn't really matter. There are two main reasons for it.

Reason 1: The new liberal computing 🗽

Most profoundly, serverless is just a marketing name (yet a pretty good one - it certainly has that Marmite quality…) for a new computing paradigm - an idea.

It's the idea of writing some code and letting the vendor deploy it anywhere without worrying too much about the where, how, or how much maintaining it is going to cost you, as you only pay per invocation. Serverless is about making it simple and fun to experiment. It's what Heroku was, but more.

The Serverless framework (with a capital S) makes most of your configurations portable between vendors, and opinionated frameworks like Architect make it great for quick productivity.

Tools like Glitch, in addition to being beautifully weird, lets you tinker with deployed code from users of the whole platform, directly in your web browser, like GitHub without any of the git.

To paraphrase Paweł Ledwoń, our CTO at Pusher - "Serverless might be this generation's PHP".

That's awesome. PHP made a whole generation build things.

Just like PHP did back in the day, serverless is opening doors to programming to the new generation of app developers (also known as "kids these days").
Returning to my earlier point, as of why the arguments against serverless (mostly) don't matter? As long as serverless (or any technology, or computing paradigm) is able to lower the barrier to entry to, the playing field has expanded enough, so that it has free rein to take up a bunch of new market share. As the market grows, the earlier arguments merely become fringe or niche concerns.

And the kids? They are the ones who are going to build the future - The kids are alright.

Reason 2: Birth of an ecosystem (of ecosystems), and mash it like it's 2005 🕺

The idea of "just" liberalizing computing was mostly true for the first generation of serverless, way back when Lambda was new. In 2019, serverless is also liberalizing how easy it is for services to interact with one another. It's increasingly being used to extend the functionality of existing services with whatever you really wish to create - flows, extended logic, you name it.

Webhooks are everywhere, and let you integrate and glue services together, with ease.

Zeit Now lets you make any app serverless, and deploy it in seconds, with one command. They have also launched an integration marketplace, that lets developers connect other services, and manage them from Zeit.

We also we have Netlify Functions -they let you add dynamic components to otherwise static sites that deploy in seconds.

Or Github Actions, to create complex flows based on what's going on in GitHub, taking ops to the next level.

Or Auth0 has their rules that extend the log in functionality of their services.

Cloudflare workers deploy and execute anywhere in the world - and execute nearest to your request.

We're seeing an ecosystem of ecosystems emerge. Want to handle a webhook? Build a chatbot, even? Serverless makes that really, really easy.
Just add JavaScript ✨.

What the new generation of serverless reminds me of is actually fulfilling the promise of API mash-ups.

For the younger generation, API mash-ups were the idea from circa 2005 (or when Twitter wasn't a thing yet) - of making dynamic and fully-featured websites by calling on different APIs and connecting their results on your own site.

API mash-ups never really took off in the mid noughties, because the tech just wasn't there at the time. The ecosystem wasn't there. But now, I believe it is here, and serverless is the glue. The JAMstack (JavaScript, APIs, Markdown) is a prime example of where we currently are, and it's amazing.

To summarize, I am a huge fan of Serverless. I believe serverless is a paradigm that greatly lowers the barriers for getting into software programming, and will see serious adoption and development in the next few years.
It's also showing itself as a great "glue" technology, connecting various service ecosystems, and making them work well together. These two benefits greatly outweigh any naysayer arguments.
More, and together - that's progress, and I'm sure that amazing things will happen. 🚀

This article was originally posted on my DevRel Medium blog.

It is a snapshot of my life and work, at some point in my career.

So you’re a developer evangelist. What is it that you do in a typical day?

Every time I get asked this question I freak out a little, impostor syndrome kicks in, and my brain goes into overdrive. I really want to give a good answer to this question - same as for any technical or product question I get. I am here to help and answer questions. I even enjoy it. So naturally, I’d answer with…

“It depends.”

More often than not I’d blurt out something like that. It’s 100% accurate yet just about as useless.

One of my favourite things about the developer relations industry is how greatly the work we do often varies on a day to day basis. DevRel is an interdisciplinary field that often spans work across different departments within an organisation, as well as community outside of it of course. That tends to spark a little confusion here and there, and recently I’ve been getting asked what my typical day looks like… almost every day.

Unfortunately, I cannot tell you about a typical day, as I don’t think that one exists. I also hate to give a lacking answer to anyone — on anything, and finally, I believe that no-one wants to hear a condescending sigh, followed by an irate “there’s no typical day” answer (see also — “It depends”).

I believe there’s a better answer, more accurate, and much more thorough hiding in there somewhere. That’s why I’ve taken the liberty to turn the question around and started answering it in two parts. In my head I read the question as something like:

“What is it that you do as an DevRel practitioner? Can you describe some of your activities so I get a better understanding of what your job is like?”

It has roughly the same meaning, yet I feel it’s much more easy to digest. I can do this now. 💪

So, to answer the new and improved question —i n the first part I tend to explain our objectives as the DevRel industry, and in the second part list a few of my activities from a longer period of time, could be last week, month, or even a quarter or a year, to best showcase what I really do.

I believe that at the core, all of our work can be boiled down to enablement. We help others do their work better and more effectively. Either developers in the community outside our company, or our colleagues. We answer questions. We break down complex problems.
While our methods, activities and scope — they can all differ (and they definitely do), this single objective of enablement still remains front and centre.It’s the most we can achieve by being outside other people’s scope of work.I’ve written about it on one of my previous articles — Developer Relations is Developer Enablement.

Once I’ve established enablement as the core objective, I can move on to less fuzzy things, like listing a few of my activities from the previous few weeks. I like to start more fine grained and concrete in the short term, and move onto more bigger initiatives in the medium term (but that might just be how brain works).

So, to give you an example, here’s something I’d say in early February 2019:

Currently I’ve been working with product marketing on our Chatkit product in order to help better explain the proposition and its value to both our commercial teams and the external developers. I’ve also helped with a customer visit, written some documentation, built some demos and prototypes with our products to share with the communities.

On the side I also help out wherever —either the community by answering questions on Twitter, Stackoverflow, GitHub or in person, or internally by connecting various departments of our own organisation with potential partners.

Every month or so I would also go to the developer communities themselves, by speaking or attending meetups or conferences that gives me a great chance to interact with people I’m trying to serve.

Every once in a while I would also be involved in large brand awareness activities, like the State of Kotlin survey and report we launched back in the summer.

Depending on circumstance I would of course change the topics I’m talking about to better explain it to the person I’m talking to, or expand on a detail. If I get talking to a fellow plane and travel nut, I’ll nerd out on that. I like my planes. ✈️

Moral of the story? When facing a question or problem that seems useless to answer, try looking for a root cause. The tangent might just happen to be where it’s at. In the meantime, enjoy your day.

P.S. the title of this article was inspired by this masterpiece by The Beatles. Have a listen below.

P.P.S. the header image is the OG Scream emoji 😱 painting by Edvard Munch. See it live if you’re ever in Oslo and like these sort of things.

This post was originally published on my DevRel Medium blog.

I’ve been thinking over the past few months that everything we do as developer relations practitioners is about enabling developers.
Our activities may differ, and so might departments and organisations, and of course our job titles, yet we all have this one thing in common.

Of course, developer enablement is far from being exclusive to DevRel, or even developer tools companies in general. (Or even software, but that’s a whole new can of worms). I would even argue developer enablement is crucial for all software teams to succeed. In this post I am going to expand on this thought, and explore how thinking about enablement can help us serve our communities better.

But what do I mean by enablement? It’s all the activities that help someone — enable them, to become better at what they are doing. It’s removing the unnecessary obstructions that keep someone from being their best self. This will increase their satisfaction with the work, and in turn increase their output, and let them improve even faster.
And about that someone — could be a single person, or groups such as teams, whole organisations, or entire communities.

Enablement is not a zero-sum game, enablement means everybody wins.

The truth is that enablement is far from being new, and pretty much every team is doing it in some shape or form. How so? Take a software development team, for instance:

Enablement is onboarding a new colleague. Getting them up to speed with the systems faster. Introducing them to the rest of the team. Showing them where the good coffee is.
So is a senior engineer mentoring a team member, teaching them best practices and helping them hone new skills.
Enablement is also a line manager listening to her report and ensuring they get to work on projects they are most passionate about, use the tools they want to use, and ultimately grow in their career. I could go on.

And the enablees? (that is a word, yes) They can contribute higher quality code with fewer defects. They are able to ship features faster. As they see the fruits of their labour they are more likely to stay in the company for longer. They will in turn teach, mentor (and enable) others. It’s not a zero-sum game, enablement means everyone wins.

The same thoughts could be directly translated to DevRel as well. As a matter of fact, enabling developers is why we exist. Enabled developers are productive, less likely to churn, and better suited to champion our products and services inside their teams, organisations, and wider networks.

Incidentally, enabling developers and removing barriers is also everything that is in our power as advocates. Unlike dynamics inside of software development teams, we sit outside. We live part way between communities and the companies we represent. We can mentor, suggest, teach, and connect individuals, teams, and organisations, yet we cannot directly influence their actions. In that regard, pretty much everything we do, and what we can do, we do to enable people.

Writing documentation? Check.
Producing tutorials and how to guides? Yep.
Building prototypes and finding flaws in your onboarding flow? Naturally. Attending events, either just to interact with the attendees or to speak? (Mic) Check.
Answering questions on StackOverflow or Reddit? Upvote. Even on Twitter, for that matter.
I could go on, and on, but you get the drift.

The reach and intensity of our interaction can vary greatly. A one on one conversation with a developer at a hackathon is completely different in reach from a blogpost, yet an individual conversation can be also much more impactful and valuable to that single developer than a blogpost is to its tens of thousands of readers. Both can be examples of successful enablement, and both are valuable.

Developer relations is throwing stuff at the wall, and enablement helps us see if it sticks.

Another dark truth about our line of work is that finding new activities for developer evangelists or advocates is hardly a science. Every product is different, and every community has its quirks. Best way I’ve heard it described by several seasoned developer advocates and community managers was “throwing stuff at the wall and seeing if it sticks”. I see enablement as a good way to see if stuff sticks. Once we have tried a new activity or produced some new content, we can ask ourselves a few questions around enablement, that will help gauge its success:
In what ways have we enabled a particular community through our activity?
How does this help someone at their job? Does it help at all?
Have we greatly impacted a few individual people? Or have we helped a large number of folks a bit?
By putting enablement of developer communities as our goal, we get to ask all these questions, and more.

To summarise, enablement of developers is front and center of developer relations, and should be seen as the ultimate objective. It takes many shapes and forms, and that’s perfect. Every person and every community are different, and there are different challenges with each.
Enablement is also what we as developer advocates are best positioned to do, and also the only real power we wield.

At least it’s a superpower though. 🦸‍♀️🦸‍♂️🥑

This blogpost was originally published on my DevRel Medium blog.

Back in November 2017 I moved from full time software engineering work and started working as a developer evangelist. As this was just about a year ago, I decided to write this post as a retrospective of sorts on how I’ve come to see and understand the field of developer relations.

My work falls under the umbrella of developer relations — DevRel. This has come to cover many types of work with one major thing in common — working with external developer communities, enabling them, and bridging the gap between the “outside” and the “inside” developer worlds.

Professional enablement

I have come to understand DevRel and my work as all about enablement of developer communities. Enablement, as in — my output is making other people better.

I’ve come to find parallels between DevRel kind of enablement of external developer communities, and the “regular” technical leadership — the main difference is only the audience. Instead of enabling a small internal team to always improve be better, the “teams” we enable as DevRels are entire communities. The personal touch is not necessarily gone, I see it just more distributed across more people.

We sometimes use different tools, and some tools we use in different ways than before, but the core objective of enabling people is the same.

For example, as a DevRel I review a lot fewer pull requests on GitHub than I used to as a developer, yet on the other hand I create many more repositories with sample code and prototypes. GitHub — the tool is the same, yet the patterns are different. 🛠

Throwing stuff at the wall and seeing if it sticks

Open source, code samples, and prototypes are only one aspect of my work. Besides that I also write, speak, or work on larger projects or initiatives — mostly associated with brand awareness.

Figuring out what activities to focus on is pretty much a trial and error process. Come up with an idea for a project or activity, develop it, get some feedback, iterate and release it, or go and experiment with something else.

This year I did larger initiatives like the State of Kotlin survey and the DEV contest, that had me writing, speaking about, and project managing various aspects of the projects. These were the successful bigger projects, but on the other hand I also worked on some initiatives that didn’t really see the light of day.

We either decided to change course or decided the things weren’t worth doing at that time or in that situation. Changing course or dropping a project is just a nature of the work. ♻️

That “glamorous” jet-setting lifestyle 🕺🏻

Throughout the year I also spoke at a few events or conferences across Europe and the US. Some of it supporting State of Kotlin, and some of it other developer content. By my count I did some 15 events this year — between conferences and meetups, a lot of which required some form of air travel.

As much as I love speaking, hanging out with developer communities everywhere, and adore easyJet’s lack of legroom, I can’t shake the fact that this activity doesn’t scale for me. I alone cannot be at enough events to cover substantial ground and make meaningful impact.
Conferences tend to happen in “seasons” — with a lot of events clustering in the spring season between March and May, and the autumn season between September and November. Even having just a few speaking engagements can mean being away for a large part of a month.

The glamorous nature of DevRel travel is something along the lines of: plane, hotel, speaker dinner, 2 days of conference, plane. There is very little room to actually see the places you travel to outside of the conference venue, hotel room, and the airport lounge.

I would sometimes try to extend my trip with meetings with local communities — especially when flying long distance here jetlag is a thing, and there are substantial tech clusters in town, but more often than not I’m just in and out. In addition to everything I’ve mentioned, another downside of travel is that it can be damn tiring, traveling a lot can make you seriously prone to burnout which is bad. Very bad.

As my focus has been on other projects, I’ve seen conferencing as a nice to have, rather than a must-have. I feel that I’ve overdone it a bit this year, and in 2019 I’ll reduce my conferencing. Play to your strenghts, I guess.

I got quite good at packing though. 🧳💪

It’s only marketing (but I like it)

Pusher’s DevRel falls under Marketing. There’s been a lot of debate of where DevRel should sit within an org, and I personally believe that it doesn’t matter that much at all — or better, there are other factors much more important than the org chart.

On a daily basis I help and advise my colleagues on the best ways to interact with developer communities. I spread brand awareness through projects. We get stuff built. It works. 🚀

I also help our engineering and product teams with Android and mobile advice, by giving feedback on the APIs and the docs I’m playing around with, and also by having my ears to the ground in the communities I am part of. Same goes for Support and Sales — dotted lines everywhere.

Working within marketing has exposed me to a whole new skillset and way of thinking. Something I don’t think would have learned to appreciate enough if I stayed in engineering. 📊

DevReling solo

Inside the bigger marketing team, I work in a team of me, as the only DevRel in the company.
Would I love to have more DevRels to brainstorm with? Of course.
Is it a deal breaker? Not really.
Is it a strange thing to have DevRel team of one? No — many teams are like it, although large teams are becoming more and more common for larger orgs, the prime example being Microsoft.

Having no immediate team this forces me to talk to and be closer to people from not only my own department — getting the aforementioned dotted lines to work.

And the support network? The DevRel community is my team. There’s a Slack channel, meetups, conferences, and there are people I can meet up with pretty much wherever I happen to find myself.

You’re never really alone in DevRel. 🍀

The 🥑 tribe

Many DevRel folks have started adopting the avocado name and the avocado 🥑 emoji in their online profiles to describe their work. I believe it was this post by Mary Thengvall that started it all — Developer Avocados: The Good Kind Of Fat.

Starting from there, we’ve come to fully embrace the 🥑 banner, and there are now several Twitter lists, like this one from Quintessence Anx, as well as regular posts of avocado themed swag and gadgets floating around. Call it an internal joke, a secret handshake for the age of Twitter.

The DevRel community is fantastic, and definitely one of the most welcoming communities I’ve had the pleasure of being part of — if not the most welcoming one.
Something something folks who help other folks for a living tend to be nice folks. ✨

Onwards and upwards

And what’s waiting for me in 2019?

The main thing would be focus. In this year I’ve tried to cover every product we have. We started off with one product, and added two more throughout the year. In 2019 I will cover less ground and focus more on a single product.

I am not quite sure yet what specific activities I am going to be doing, but I imagine it’ll be integrated across various channels — be it written, spoken, recorded, with the emphasis on scaling the impact. I have high hopes for video as a channel. I’ll also be giving fewer talks — but most likely around 5 in the whole year. Not a zero, but way less.

Onwards and upwards, it’s going to be exciting 🚀.

Resources

DevRel Collective community — https://devrelcollective.fun/

Business Value of Developer Relations, book by Mary Thengvall: https://www.amazon.co.uk/Business-Value-Developer-Relations-Communities/dp/1484237471/

DevRel Avocados, Twitter list by Quintessence Anx: https://twitter.com/QuintessenceAnx/lists/avocados/members

Sympathy for the DevRel, talk by James Governor: https://redmonk.com/jgovernor/2018/11/23/sympathy-for-the-devrel/

Originally published on my DevRel Medium blog.

MASSIVE KUDOS to Mary Thengvall for linking to this blogpost in her excellent book - The Business Value of Developer Relations:

The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success: Amazon.co.uk: Thengvall, Mary: 9781484237472: Books

Buy The Business Value of Developer Relations: How and Why Technical Communities Are Key To Your Success 1st ed. by Thengvall, Mary (ISBN: 9781484237472) from Amazon’s Book Store. Everyday low prices and free delivery on eligible orders.

Mary Thengvall

I’ve been going to conferences, and submitting talks to them for over 4 years now. Over this period I’ve tried a few different approaches for submitting the proposals to several conferences and tracking my success (and failures). In this post I’ll explain my process of coming up with new proposals for technical talks at conferences (and, by extension — meetups), and how I like to submit my talks to events.

What I won’t do is explain how I prepare my actual talks — the content, slides, the lot. I also won’t give you the “12 tips to make your talk proposals accepted by ANY conference (you’ll be surprised what #6 is)”. That’s a story for another day.

My process 🛣️

In general, it goes something like this:

• I come up with a topic or title for a talk or presentation,
• turn this into a fully fledged talk proposal,
• which I then use to submit to relevant events.
• Wait, rinse, and repeat.

Coming up with a topic 💡

Sometimes this is just a title, or sometimes it’s a rough description of what I want to talk about.
Sometimes it’s a topic I’ve tackled or researched at work — most of my early talks on Android testing and architecture started that way. Sometimes I’m just passionate about a topic — I did a talk about political engagement a few years ago. Often it’s literally a shower thought, happens during a walk with my wife, or in a conversation with my colleagues. It can occur anywhere, at any time.

Depending on how your memory works, I believe it’s good to scribble it down. For me, that’s usually either email or Google Keep.

Doing the legwork 💪

I’ve got a topic, now I need to turn that idea into something compelling enough for conferences to accept.
I’m a big fan of puns and pop culture references, as well as clickbait titles, so my submissions (at least the titles) tend to have a certain Buzzfeed-like quality. Some of my talk titles are Library Development: Between a Pod and a JAR file, Tools that give you Superpowers, and Beyond Hacktivism — why #policymatters.

Most conferences require a title, a short abstract they can publish, and a slightly longer “proposal” part — something that is usually seen by their selection committee. Another common field is one for “notes” or comments — here you can put anything you think might be relevant, but you don’t usually need them.

I usually start by writing the title and proposal, and then turn that into an abstract. I feel that a title gives me focus, and the proposal gives me the freedom to explain my thoughts. The proposal can also contain a rough talk breakdown.
The abstract is just coming up with something between the two with some clever jokes thrown in. I also write a series of potential titles that would fit the bill, and select the one I like the most.

Something that’s hard to boil down into a tweet about is probably not a good candidate for a talk.

Where to write them? 📝

I like preparing these proposals, far away from submission forms for talks. Usually in a Google or Paper document, so I can copy and paste passages around. I also used markdown files versioned in a private git repository.
Some people like Joe Birch have also turned this into fully transparent systems: https://github.com/hitherejoe/PublicSpeaking
A living online document also allows me to have my bio and speaker profile picture ready for copy pasting .

I sometimes test the ideas on Twitter — just to get a feel of how they resonate. They can be titles, or they can be a few thoughts towards the idea. In general, what gives me some likes or retweets is good. Something that’s hard to boil down into a tweet about is probably not a good candidate for a talk.

Note that at this time, I do not yet create my talks in their entirety. I’m not a fan of creating talks before I know when and where I’m speaking. I also tend to tweak them until the last possible minute, even though I’ve rehearsed before. It lets me stay on my toes.
A 45 minute talk takes a LOT of preparation, and this is just the time I don’t have when writing a proposal.

Feedback

I like asking for feedback. This can be either my colleagues, or the people I know are potential audience for these talks.

Finding events 🕵️

After I have a serviceable talk proposal written, then I can start thinking where that talk might fit. What conferences could use it?

My thought process goes something like this: Am I speaking about a particular technology — let’s say Android? What Android conferences, mobile conferences, and general conferences am I interested in? Time to get Googling.
There are also several aggregators that help with my search. For Android, there is the conferences repo from AndroidStudyGroup. For JS, there is confs.tech.
I recently discovered Awesome Conferences — which is a more generic aggregator.

There are also fully fledged CFP solutions like PaperCall.io, that incorporate speaker profiles, talk submissions and reviews, as well as have a browsable event directory.
And for meetups, there’s the Auth0 Meetup Finder, and of course meetup.com.

☠️☠️☠️
A honourable mention is Lanyrd, which used to be the one aggregator to rule them all, that then got ruined by Eventbrite who bought it and put it in a “read only mode”. It was a great tool for tracking events, speakers, and organisers.
RIP Lanyrd, fuck Eventbrite. 🖕🏻
☠️☠️☠️

Submitting to events 📮

At this stage I have a shortlist of events that I’m submitting my talk proposals to. I start reading about their expected attendances — if an event has been happening for a few years they likely have an idea who to expect.
For example: 60% frontend developers, 20% tech leads, and 20% designers and product managers. This will obviously vary from event to event but it gives important clues of what they want to see in their talks.

Conferences also sometimes have a few preferred topics they would like to focus on — such as “apps everywhere”, “containerisation”, “the future of conversational interfaces”, or “testing”. This is either to ride the hype 🚂, or because their know their audience prefers specialised content.

I also usually look for the Code of Conduct — if a conference doesn’t have one it’s usually a bad sign. Reading it also helps me see if they are trying to avoid profanity altogether — I like dropping a few f-bombs here and there and it’s definitely a good to know in advance.

Finally, I check for when the conference is happening. Are they clashing with anything already in my calendar — maybe it’s the vacation I have planned, or with an all-hands event at work? If so — the conference is out.

Knowing all of the above, it’s time to fine tune my proposals. Often the title can stay the same, and I just get to explain my talk in a way that better corresponds to the conference’s specific audience and needs.

Scheduling shenanigans 📆

Conferences usually happen in 2 distinct seasons — Spring and Autumn. The spring season goes roughly March-May, and the autumn season goes around September-November. Of course, there are some exceptions, but I’ve noticed that most events tend to fall into these dates. Most also tend to favour days on either end of the working week — either Monday-Tuesday or Thursday-Friday.

What I’m getting at is, if you are applying to a lot of conferences (and across different disciplines), then you will inevitably see that events are overlapping. If you are extremely lucky, they will overlap and also be in the same city.
If you are not, they will be on a different continent.

As I submit a proposal to a conference, I have no accepted talks at the time of submission. If I learn that one of my talks has been accepted and I am confirmed as a speaker then I inform the overlapping conferences I submitted my talk to (that haven’t yet come back to me), that I need to withdraw my proposal. Most conferences accept their speakers in batches, and usually take a few weeks to finalise all proposals after the CFP has closed and selection has begun.

Tracking

I currently track all of my submissions in Google Calendar where I have a dedicated Events calendar. I enter them as full day events (or multiple days), and add corresponding labels Submitted, Rejected, or Talk confirmed that corresponds to my talks, as well as colour code them. I put the talk titles I submitted to each event in the descriptions. I also list the events accepted alongside the proposals themselves, so I know immediately what got accepted where from that side too, and helps me manage any scheduling conflicts.

Exceptions rule! 🤘

The above steps explain my usual process for submitting my talks to events. Funny thing about conferences and talks is that the best ones are one-off, and between different talks only a few things stays the same.
Maybe my bio, that only sees dramatic changes every year or so 😂.
I find it that the more I submit, the more I’m likely to tweak a talk. Especially after I’ve given it once or twice, gathered feedback from participants, added new parts and turned them around. Even if the title stays more or less the same, and the talk will change and evolve dramatically — that’s the beauty of it. It’s always possible to go back to the “drawing board” and rewrite the abstract or proposal points.

Rinse, repeat, recycle ♻️

I never have just a single talk to give. I submit 2 or 3 different talks to most conferences I’m applying to. I usually write and tweak my proposals in the off-months (before the conference seasons kick in), and have 3 to 5 proposals ready to go at any given time.

Conclusion 🏁

This is a system that I currently have in place. It works for me, and my hope is that it will help other budding conference goers to start thinking about their involvement in a more systematic way.
Maybe also start a debate around our processes — how do you plan your conference talks?

This was originally published on my DevRel Medium blog.

I’ve been doing public speaking for a few years now. I enjoy it a lot, for several reasons: I get to learn a ton when preparing talks, it helps clarify my thoughts, and I feel like I’m always improving. Probably most importantly however, is the fact I get to meet a ton of amazing people from all over the world, many of which I’m now happy to call friends.

This blogpost is a retrospective of where I spoke last year, and about what, and where I want to be in a year.

2017 in numbers

• 8 events spoken at in 4 countries (UK, the Netherlands, Slovenia, and Turkey).
• 5 of them were conferences, and 3 were meetups.
• I gave 4 different talks this year — Android Testing Support Library — the Nitty Gritty, Library Development — Stuck between a Pod and a Jar file, 10-ish Things about Android Library Development, and Tools that give you Superpowers.
• My presentations were created using 3 different pieces of software — Keynote, Google Slides, and Deckset. One of them also involved a foam sword.
• 1 conference attended— DevRelCon in London. It was fab. You can read my writeup here.
• 1 meetup organised — The Dev Shed.
• I met m awesome people in this time. Looking forward to meeting lots more, from new faces as well as old friends.
• I also gave n lightning talks and demos at Pusher.

I’ve spoken at 7 of those events within 90 days between March and May. That was more intense and exhausting than anticipated, especially as this was just something I did on the side, besides my full time dev work. Pusher was awesome in supporting me there 🙌🏻.
I decided to slow down after that, and only spoke at Droidcon London in the 2nd half of the year. Pacing is hard.

Plans for ‘18

• Double that number, speak at at least 16 events. They can be meetups, conferences, or something else, either UK or abroad. I want at least one of them to be in the US.
• Expand from mobile focused events into something involving JavaScript, TypeScript, and/or Node. I’ve grown to like these a lot in the past year, and now feel comfortable enough to prepare some nice content.
• I also want to do at least one talk that involves live coding. This scares me, and that’s precisely why I want to do it.
• Prepare something with Nic Jackson. A kray kray double feature that is over the top. This needs to happen.
• Continue looking for the best effing presentation tool in the Verse. On the TODO list are Slides.com and GitPitch.
• Restart the Dev Shed meetup we host at Pusher. It’s a shame we only had it once, as it’s a great opportunity to bring the community of people making products for developers together.

Onwards & Upwards! 🚀

This was originally published on my DevRel Medium blog.

On Wednesday 6 December I attended the annual DevRelCon London — a conference for people working in developer relations, developer experience, and related fields.

I met lots of people, gained tons of insight, and over all had a great day. I also won a prize! 🍾

The basics

This was a DevRelCon. It is organised by Hoopy, a Developer Relations consultancy. The idea of the conference is to bring people working in DevRel together in a dedicated conference in order to share all of the knowledge. People came from across the globe, from the US, Canada, UK, Europe, all the way to Japan.

The event took place in the Barbican Centre — with one large area designated as the community area, and 2 rooms for 2 tracks — named after the sponsors Github and Nexmo.

The pre-event meetup was in Electricity Showroom 3 minutes away from our office, and the after party was in Runway East, 3 minutes in the other direction. I’d say Pusher’s Shoreditch office is optimally positioned for DevRelCon 💪.

Swag-wise, we got an Auth0 branded luggage scale — which I think was brilliant, especially considering how much time most DevRels spend in the air and hauling luggage around. Super thoughtful. My computer was also adorned by 9 brand new stickers, and I brought a ton back to the office.

There was also a for-sale T-Shirt that I absolutely had to get. Oh, and they used a Square terminal to make the sale. First time I used one in Europe, and although there was some tech difficulties setting it up — so it’s great we had Tristan Sokol from Square who could lend a helping hand 😅.

The tracks

I mentioned there were 2 parallel tracks at the conference, with keynotes and lightning talks shared in the same room. The tracks also changed from morning to the afternoon, so there was really 4 different themes going on in one day, which was quite impressive.

The morning tracks were Developer Marketing and Developer Experience, and in the afternoon there were the DevRel Strategy and Developer Documentation, but there was enough time to change before each long presentation (there were 2 formats, lightning and full-length talks).

I attended the Developer Marketing and DevRel Strategy tracks, as I felt they’d be most valuable to me just starting out.

I will walk you through the talks and insights I found most valuable or interesting.

1. You can start a talk at 9.30 with the word “Epistemology” and survive, as Erin McKean from IBM and Wordnik explained. She also went on and explained that as we deal with dispersing knowledge we are just applied epistemologists.
   Her talk was about adding more value to the content we produce by making implicit things explicit — for example, showing the nitty gritty bits of authentication instead of hiding it away, as that will be a real-life scenario everyone will have to deal with.
2. Next up was Ade Oshineye from Google, taking us through his journey on to become a Developer Relations lead and managing a team of people. As with any other type of work, it’s good to be a human.
3. In the Developer Marketing track I loved the presentation by Martin “Gonto” Gontovikas from Auth0. He was talking about their experiments with different approaches to content, with the goal to increase their sign-up numbers. Some of which was super similar to what we’re doing with our Guest Writer Program at Pusher. I loved the focus on actual numbers and the trial and error approach. You can read a recap of his talk on devrel.net blog.
4. Another talk in Developer Marketing track was Melinda Seckigton from FutureLearn talking about the Art of Slide Design. Some great insights here, and has all the content in a series of blogposts explaining everything she went through on her website. Read it here.
5. After the break we reconvened in the main auditorium where Caroline Lewko from WIPFactory presented preliminary results from the 5th annual DevRel Survey. Some interesting insights they will doubtlessly be made public in a few weeks’ time.
   For the time being it’s still running and you can participate here: https://www.surveymonkey.com/r/WIPDevRel17
6. In the DevRel Strategy track Matt Bernier from Sendgrid talked about how Developer Relations and Product people can coexist, collaborate, and thrive together.
   Each side has unique advantages that the other lacks, and vice versa. DevRel people have easier access to developers “in the wild” (otherwise known as the customers), while product managers know the product roadmaps far more in-depth.
   https://devrel.net/craft/five-tips-harmony-dev-rel-product-teams
7. Github’s Joe Nash talked about how GitHub scales their community efforts around the globe by running a Campus Experts programme.
   GitHub supports interested students worldwide with training, swag, as well as financially when they organise hackathons in their local communities and universities. As a result, there are several people willing (and capable) of giving a talk on meetups and conferences on the behalf of GitHub.
   https://devrel.net/community/training-community-leaders-2025
8. Jessica West from Algolia talked about being proactive in our DevRel efforts, how to optimise for impact, and most importantly with invaluable lessons from history — namely that Napoleon would have killed it in DevRel.
9. The headliner of the conference was Anil Dash, CEO of Fog Creek, the authors of Glitch 🎏.
   Glitch and a few other things you might have heard of. Anil talked about a Developer Relations Bill of Rights, a topic he first introduced a few months ago. Read the original points in detail here: https://medium.com/glitch/a-developer-relations-bill-of-rights-21381920e273.

Tracks I missed

Due to constraints with quantum entanglement technology of our time I could not be at 2 tracks at once. I observed the developer marketing and DevRel strategy tracks which meant I missed the tracks about documentation and developer experience.

I’m looking forward to watching these talks when their recordings are posted online:

• Christiano Betta (Work Betta & Hoopy) — Live API Teardown
• Jenny Wagner (SpotHero) — The UX of DX: User Testing in the Invisible World of APIs and SDKs
• Adam Butler (Nexmo) — Steering towards better documentation

The cool things

I won a book! 📘
There was a raffle going on that you could enter if you visited all three sponsors and got their stamps on your “passport”.

• GitHub also sent attendees vouchers for a free T-shirt. Pretty neat.
• Spotify has Developer Advocates for their SDKs and APIs. That’s pretty neat too.
• And the stickers. I already mentioned them, but here we go again.

Looking forward to the next years edition! 🚀