Christian Heilmann

You are currently browsing the archives for the General category.

Archive for the ‘General’ Category

How does a changed market affect Developer Relations?

Wednesday, February 21st, 2024

Today, 21/02/2024, I will be opening a live event called Developer Program Leaders: Main Challenges in Developer Relations. Here’s the writeup of what I will be covering in 10 minutes:

What is Developer Advocacy?

According to the The Developer Advocacy Handbook written in 2009, here’s what a Developer Evangelist/Advocate does:

A developer evangelist is a spokesperson, mediator and translator between a company and its technical staff. Every day millions of dollars are wasted in companies because non-tech people and tech people either don’t communicate at all or completely miss each other’s points.

In other words: developer relations are as much an internal job in your company as it is an external role, being a contact person and representing your company.

Slide explaining this topic

Developer Advocacy internal tasks

The main tasks of a developer advocate inside your company are:

  • Optimise product docs to outside needs – find out what’s missing and write it/record videos/write demos.
  • Collect team questions and ideas – what do your developers need? What are they missing out on?
  • Find team frustrations and communicate them to the company – how can you convince management to improve processes and infrastructure to make the life of developers easier?
  • Coach and mentor team members to be a voice for the company – your job is to empower developers to speak on their behalf, not be on stage instead of them.
  • Find ways to keep the team excited about the product and working here – people should be able to concentrate on their work, not feel like they are missing out.

Developer Advocacy external tasks

This is the more common part of the role as it is much more visible. It’s also the dangerous one as it could mean you drift into marketing/sales territory and away from the people you should represent. In any case, the main tasks are:

  • Create product demand – explain your products in a technical manner, give access to sources and additional functionality to get developers to influence others to use your products.
  • Find developer needs – what do developers expect of your company? Documentation? Beta access? Open source access? Free developer accounts?
  • Explain product to various audiences – translate according to needs and wants.
  • Analyse competition – what’s brewing and how can it affect your company?
  • Find inspirational ideas – share great stuff with your company and your developers.
  • Find new talent for the company – getting people through the door is time consuming and expensive. A personal approach can avoid that.
  • Enable outside contribution and build communities – get people to not only use your products but become part of it.

What is in it for the company?

Slide explaining this topic

Here comes the big one. Developer Relations always has to find reasons to validate its existence in a company and – when done badly – can feel like a “boutique department” that doesn’t really bring much to the table. The benefits of having good Developer Relations people are tangible, though:

Internally, it is about:

  • Talent retention – developers who feel listened to, not miss out on market information and feel like they work on a great product stay in the company.
  • More maintainable products due to great documentation – by discovering outside needs and documenting your products not only a few people know how to maintain the product. Developers hardly ever have time to document what they do. Developer Advocates can do that for them with an outside view, which always results in better docs.
  • Market-fit product creation due to outside needs – by having a handle on what’s happening in the market, what excites developers and what the competition is up to you create better products. This should be backed up with user studies, too, but we all know that there’s never budget for that.
  • Less knowledge attrition due to sharing of outside trends and products – employees don’t hyper focus on the current state of affairs but keep learning when there’s a good Developer Advocacy in place. This eases tension and avoids the the “Am I falling behind by working here” feeling. It also allows the company to embrace new tech faster as someone is already trying it out.

Externally, things are pretty obvious:

  • Product sales – getting people to understand your product better means more people will use it.
  • Subscription sales – once established as a trustworthy technical company people are more likely to subscribe to ongoing offers.
  • Mindshare – being on the conference circuit and having an online presence as a technical source helps people remember your company, even if you are not one of the big players.
  • Already knowledgeable Applicants – people who already worked with your product need a lot less onboarding before they become effective.
  • Talent acquisition – DevRel goes where the developers are, so no need to find them in a pool of applicants and cold-call them.
  • Partner acquisition – finding similar companies and products can lead to great collaborations.

Things were good, but also weird…

Developer advocacy has become a normal thing for companies to do and when the market boomed the big players hired a lot of people to do advocacy. However, in a booming market our job as Developer Relations experts wasn’t always easy. One big topic to prove our worth to the company, talent retention, was one of the most problematic ones. When everybody is hiring and vying for the attention of tech talent, young and independent developers used “job jumping” as a way to get more salary and higher positions. When you work in larger companies, this becomes rampant. In Microsoft, we had a hard time keeping talent in the company as Meta and others, literally round the corner, offered much higher salaries. We also had people joining to have the name on the CV as a rite of passage into “cooler” companies. Sometimes the process was so broken that the saying was that in order to get promoted, the best way is to leave the company and apply in a different position.

Product/Subscription sales was another tricky subject in a world where people want everything free. Many companies use this as a business model – burn VC money to get known and then start billing people. That’s hard to compete with.

Lastly, the bigger you are the fewer valuable outside contributions you get. I spent a lot of energy to get Microsoft to release things as open source. I got that by promising a community to start embracing products that way and getting outside contributions to make the product better. The problem is that when you are someone the size of Microsoft or Google, people do not contribute as they expect that you have tons of developers better than them already working on the product. This isn’t the case, of course, as you also have to fight for resources internally, but it feels weird to do free work for the richest companies on the planet. As this didn’t work out, a lot of large players scaled down their developer relations efforts immensely. The dirty secret is that the biggest open source projects are maintained by a few people inside companies who are paid to do so.

Danger signs…

When all you meet at events are DevRel speakers, we don’t help our teams – Developer Advocacy is about making companies communicate better to the outside by allowing their employees to speak. Developer Relations should not be “voices for hire”. And yet, companies hired the loudest people on social media and sacked them a few months later when – oh wow – they didn’t deliver anything. Developer Relations became a role hired from the outside, not found and nurtured in the company.

A changed, humbler world…

Slide with all the benefits to the company not applicable right now crossed out

Right now, a lot of the benefits we as Developer Relations people bring to the company are not applicable. Hiring has slowed down, documentation teams are being laid off as “an AI chatbot can help users the same way” (insert eye roll here), and with not many people hiring companies are less inclined to bend over backwards to keep their developers happy.

All big tech companies we lost talent to are laying off, so there is no worry that you have to compete with them. Salaries are still much larger than elsewhere in the market, but job safety and work structure is terrible. It feels like the mass layoffs have opened the floodgates so companies take a “what can you do for us to prove your worth” stance. Talent acquisition and finding already knowledgeable developers becomes less interesting then. When I applied for jobs, I had to demand working from home and self-training to be part of my work time. Yet there is still a huge need for developers (no, AI will not replace them all), but companies focus on saving money instead of hiring. So our job as Developer Relations people is to be there to make this world work for the developers and the companies…

Interesting new focus areas…

To me, this means focusing on the “advocacy” part of Developer Advocacy. Instead of chasing the coolest, newest tech and trying to win social media, I concentrate on our jobs as a whole. Fixing the gap between job offers and CVs – why does this go wrong all the time? Bringing structure and safety to developer careers – why is there still a gap when you are principal developer and nowhere to go? Finding measurable data to define developer worth to the company (no, it’s not lines of code, Elon!). And trying to make retention and staying in a company a good thing and not a sign that you slowed down.

Lines of code – how to not measure code quality and developer efficiency

Tuesday, February 6th, 2024

Lately I have a person who pings me daily asking how many lines of code I have written today. The first time was on the weekend. My answer was “none, as weekends I concentrate on not doing computer things with my partner” which is an excellent idea.

However, lines of code are often seen as productivity or even quality of a developer. And that’s nonsense.

When Elon Musk took over Twitter he asked people to print out (!) the code they’ve done in the last few days to prove their worth. This lead to a lot of ridicule, and well deserved. This isn’t the 60ies.

This is Margaret Hamilton, lead software engineer of the Apollo Project. Here (left) she stands next to the code she wrote by hand that what used to take humanity to the moon. [1969]

When pressure rises in companies you often have to prove your worth as a developer. You also have to prove your department’s worth as a lead developer. And as lines of code are easy to measure, this is often the hammer used to hit the nail in the coffin of company trust.

The amount of lines of code is a weird thing to measure as there are several things that interfere with it:

  • If you look for a lot of code and equal that as efficiency, the code might actually be bloated nonsense to hit a goal of “x lines of code”
  • If you look for a small amount of code, it might be overly terse or use a lot of dependencies. I can write 5 lines of code that do the job, but under the hood include 3 libraries of 2MB each
  • We live in a time of preprocessors, bundlers, compilers and conversion for almost every code we write. So the original count of lines is pretty pointless. How much code gets shipped to the end user, is, of course, another story.

The amount of code necessary depends on a few things that can’t be measured in lines. Much like you can’t value the quality of an essay or book by the amount of words.

Code should first and foremost do the job it is written for. The outcome should be a product for the intended audience. For end users this means an app they use without any security and privacy issues that’s easy to use. For other developers, it’s similar. The code should play nice with other code, not have any performance or security issues and be easy to include. Often this means concentrating on the documentation, rather than the code itself.

So why do people care about the amount of code written? Well, it could be concerns about your developers not being seen as doing enough. It could also be a worry that your product has become bloated and hard to maintain. But often I think it goes back to finding one way to measure things. One way we learned in school. When students are asked to write an essay, the demand comes with a challenge of “at least x words”. That’s why. This has entered meme territory years ago.

Meme about replacing the word therefore with for this reason the conclusion can be drawn that there must be a direct, and obvious, connection between the two ideas so

An equivalent in code would be: “write a function that checks if a number is between 1 and 10”.

A pretty decent solution is:

function isOneToTen(number) { 
  return number > 0 && number < 10 
}

If LOC is your end goal, just do:

function isOneToTen(number) { 
    if (number === 1) {
        return true;
    }
    if (number === 2) {
        return true;
    }
    if (number === 3) {
        return true;
    }
    if (number === 4) {
        return true;
    }
    if (number === 5) {
        return true;
    }
    if (number === 6) {
        return true;
    }
    if (number === 7) {
        return true;
    }
    if (number === 8) {
        return true;
    }
    if (number === 9) {
        return true;
    }
    return false;
}

Both work, and you could argue that the longer one allows you to add more use cases. You could, for example, react differently to different numbers. However, we all can agree that this is not efficient code when it comes to writing and reading it as a human.

Interestingly enough, code like this can often perform really well. I remember working in very limited environments, like 8 bit computers. And there writing more often meant better performance as the code didn’t need expensive computation. These days are over though, and often micro-optimisations like these cost more time than they are worth.

What about keeping things as short as possible? Often you have competitions that measure the cleverness of code and skill of the coder by the terseness of their code. The first money I made with code was winning a competition in the “64er” computer magazine for a 20 line of code BASIC program that was a text editor in 1990. You also see one-liner contests and the like. Is smaller code always a sign of quality? I’ll write about this next time.

For now, please stop seeing lines of code as proof of worth for engineers. It just shows that you have no idea how building products with software works. Often the best code is the one that didn’t need to be written. Writing code is one task and doesn’t need to be the start. A much better investment is thinking about the product and what you want to achieve in the amount of time you have. Code can adapt, so can developers. Think about the needs of your users and validate features before creating them. The amount of code is only important when it becomes a performance or maintainability issue.

Using details/summary and colour coding on GitHub pages

Wednesday, January 24th, 2024

As CODE100 is coming to Amsterdam, we needed an archive of all the code puzzles we had so far. As the challenges are all on GitHub, it made sense to use GitHub pages for that. So I needed to fix two issues:

  • I wanted to have colour coding of code examples much like the GitHub own templates have.
  • I wanted to have collapsible and expandable parts of the page. I did not want to write an own JavaScript solution for that.

Here is how to achieve both. You can check the CODE100 puzzle archive to see this in action.

Adding source code colour coding to GitHub pages

In your `config.yml` file define kramdown as the markdown used and rouge as the highlighter.

markdown: kramdown
highlighter: rouge

This allows you to use code fences and get colour coding. You can add your own CSS to colour it any way you like.

Adding collapsible elements using detail and summary

The new(ish) HTML elements detail and summary result in collapsible document sections. The great thing about these is that they don’t need any script and work independent of input. Even better is that using in-page search also automatically expands sections. At least in Chromium based browsers. The problem is that there is no way in markdown to define these sections.

GitHub allows to use summary and detail as HTML inside their flavour of markdown. If you check the notworking.md file in the source repo, you can see it working.

Collapsing and expanding in markdown on GitHub

However, if you render it as GitHub Pages the content inside the `details` stays markdown and doesn’t get rendered (even when you add newlines). You can of course use HTML (as the second demo shows), but this defeats the purpose of using markdown.

Collapsing and expanding in GitHub Pages not working

My workaround was to use HTML comments and create an include to use in my page templates.

HTML comments are great because they don’t do anything in GitHub markdown. There seems to be no standard for Markdown comments, after all.

The `detail-summary.html` include is as simple as it gets:

{% capture summary %}<!-- summary -->{% endcapture%}
{% capture details %}<!-- details -->{% endcapture%}
{% capture endsummary %}<!-- endsummary -->{% endcapture%}
{% capture enddetails %}<!-- enddetails -->{% endcapture%}
{% assign newhtml = include.html |
 replace: summary, '<summary>' |
 replace: endsummary, '</summary>' |
 replace: details, '<details>' |
 replace: enddetails, '</details>'
%}
 
{{ newhtml }}

In my page template I need to use this as a pre-render instead of simply using `{{ content }}`:

{% include detail-summary.html html=content %}

And in my markdown files I use HTML comments:

<!-- details -->
<!-- summary -->
## Solution
<!-- endsummary -->
 
``json
 
 [
   0,0,0,121,231,143,195,118,216,
   195,54,223,195,182,216,121,231,
   143,0,0,0,3,15,30,97,155,183,
   49,153,179,1,157,187,3,207,30,
   0,0,0
 ]
``
 
Did you get it? Did you find a better way?
<!-- enddetails -->

This renders as a collapsed section with `Solution` as the summary.

Demopage in the browser

The nice thing here is that it enhances progressively. In the GitHub rendered readme it is just a headline.

Github rendered markdown of the file

If you want to play with this, I created a bare-bones version here.

10 print chr$(205.5 + rnd(1));:goto 10 in JavaScript

Friday, January 19th, 2024

Forget about the Vision Pro, or whatever Samsung just brought out, we all know that the pinnacle of computing fun has been released in 1982 in the form of the Commodore 64.

One of the coolest things you could show people when writing BASIC on it was the following one-liner:

10 print chr$(205.5 + rnd(1));:goto 10

Executed, this resulted in a diagonal endless maze:

What the one liner does is print a character with the PETSCII code 205 or 206 (or SHIFT + M and SHIFT + N) which are fat diagonal lines. It does that using the PRINT command and the CHR$() command which turns a number into a character, much like fromCharCode() does in JavaScript. Luckily enough, the CHR$() command doesn’t care if it gets integers or floats. without the CHR$() it would be a list of floats:

When you ended a PRINT command with a semicolon, the computer didn’t add a new line but kept the cursor where it was.

Michel de Bree also has a version of this that is even shorter using Assembler and the D012 functionality, which stores the current scanline of the screen. He also pointed out that there is a whole book about this one liner and others that use faux random designs on the good old breadbox.

Now, let’s try something similar in JavaScript. A classic approach would be nested for loops.

let out = '';
for (let y = 0; y < 10; y++) {
    for (let x = 0; x < 40; x++) {
        out += (Math.random() > 0.5 ? '\\' : '/');
    }
    out = out + '\n';
}
console.log(out);

This works, but doesn’t look good.

Maze generated with slash and backslash

The reason is that slash and backslash have too many pixels around them. UTF-8 has box drawing characters, which allows us to use two diagonals that have less whitespace, ╲ and ╱ respectively, or 2571 and 2572 in unicode.

Using this, and moving from classic nested loops to chained array methods, we can do the following:

console.log(new Array(400).fill().map((_, i) => 
    (i % 40 === 0 ? '\n' : '') + 
    (Math.random() > 0.5 ? '\u2571' : '\u2572')
).join(''));

We create a new array of 400 items, fill it with undefined and map each item. As the item is irrelevant, we use _, but what’s important is the index, so we send this one as i. We then add a linebreak on every 40th character or an empty string. We then use Math.random() and see if it is above 0.5 and add either ╲ or ╱. We join the array to a string and log it out.

This looks better:

Maze generated with unicode characters

However, it doesn’t have the WUT factor the original one liner had. Luckily enough the two unicode characters are also following one another, so we can use fromCharCode with Math.random() to do the same. JS is not as forgiving as BASIC on Commodore64, so we need to round to the next integer and as we use unicode, fromCharCode() also needs a ‘0x’ to work:

console.log(new Array(400).fill().map((_, i) => 
    (i % 40 === 0 ? '\n' : '') + 
    String.fromCharCode('0x' + '257' + 
    Math.round(Math.random() + 1))
).join(''));

Coding is fun. Let’s do more of it without reason.

Want to do it live with a chance to get to the finals of the CODE100 coding competition? We run another edition of it in Amsterdam on the 29th of February. Apply here as a challenger!

Rob Bateman and his journey to resurrect Flash content on today’s web

Thursday, December 21st, 2023

Flash has been a boon to the web and the bane of my work as a web standards advocate. Now defunct, it is great that people work on converting old content. I’ve been talking to Rob Bateman about his work on converting Flash games to run on today’s web in an edition of Coffee With Developers.

I met Rob again at Halfstack in London and if you are interested in more details about the work he is doing, his “An Emulator’s journey” is also available on YouTube: