People often asked me if I can make the Developer Advocacy Handbook available as an eBook to read on their devices. When Jens Oliver Meiert also asked me I told him there were no immediate plans, so he took on that task and converted the book. You can now purchase the eBook either on Amazon Kindle or on Leanpub.

As a reminder, here is what it is all about:

This handbook will get you on the way to be a great developer advocate for any product or company. Naturally, your approach may need tweaking for different markets and audiences—and in accordance with your own personality—but the main principles are the same for everybody and anywhere in the world. Developer Relations is a rather new market and there are many confusing messages out there what it means to do this job, In this book, the author documented 15 years of Developer Advocacy and how to deal with the demands of the job. Whether you are new to the job, or you feel unhappy in your current role, here you’ll learn how to get started the right way. For people on the job, it is a great way to remind yourself what’s important.

Dedication to your employer is a tradition in some cultures. My father was a dedicated coal miner and when the mine closed up he became a factory worker. He worked 40+ years in that factory in three shifts. He kept complaining about “those up there” in the hierarchy and yet the company was a big part of his life. He was always interested in what the company did even long after he retired.

One of the most surprising things I’ve seen him do happened when the company was in dire straits. They offered him a lump sum payment to go into earlier retirement. My father wasn’t someone dedicated or interested in math. But he took a pen to paper and calculated his odds. He found out that if he went on unemployment benefit for the remaining time he had more money after tax. So he got himself fired. I was very proud of my old man that day.

What about employer dedication in tech?

Now, what about our lives when it comes to our relationships with our employers? As a developer or the people surrounding them you live in a ridiculously fast paced environment. Keeping people for more than two years seems to be tough and for even longer is a rarity. I’ve always dedicated myself to my employers and I stayed on average more than four years in all my jobs. I’m weird. Maybe that’s a bias I inherited from my family but I always wanted to stay for the long term.

If you feel supported and your job nurtures, challenges and interests you, time can fly by quickly. And it feels good to reap the rewards of the early work you did years later. Seeing structures and processes in the company improve feels great. Seeing your products go live, take on momentum and become a household name is even better. Seeing people you hired or recommended improve and get promoted is also incredibly rewarding.

On the flipside, I also often caught myself staying in a job too long. I wanted to see a product come to fruition or a team to get what they deserved even if everything was against it. And it never played out. Sometimes you need to count your losses and realise that you won’t finish what you started. Often your doggedness is also the reason why the product isn’t getting done. You stopped being flexible and thus halted, for example, a possible incremental roll-out.

We got spirit, yes we do! Wait, do we have to?

Being dedicated to your company is a great thing. It often means that you don’t need to get lots of rewards, free stuff or perks. You already feel that your contribution is appreciated and that’s a very basic human need.

I always felt it getting weird though when company dedication and especially brand adoption is seen as a given. For example when people and companies bang on about the company being “a family”. This is rampant in US companies and I suppose it is a spill over from cheerleading and pep rallies in high school. I remember standing with my UK team at a Yahoo meeting in the Silicon Valley when everyone around us did the “yahoo yodel” and high fived without abandon. I also remember the almost physical pain on the faces of my colleagues as it did feel surreal to us.

We were proud of working there, and we loved being part of a big and impactful product. But no, this wasn’t a family gathering and nowhere in our contracts were we asked to do a song and dance when the company name is mentioned. Many a contract would have stayed unsigned if that had been the case.

Almost every company has a clever name for its employees. It gives a fuzzy feeling being part of a cool group rather than “wage drone number 1394”. This works and is fun to a degree, but it can come across tone deaf when things go wrong.

Take the letter that the CEO of Twilio released last month. A message that announced they cut 11% of their workforce kept talking about “Twilions” instead of employees. Imagine how this must feel for those who lost their jobs. Not only are you up for the chop, but you’re also kicked out of the cool family of “Twilions”…

Stock options – keeping it in the family

One way companies try to make you more part of a whole is by giving you stock options, especially as bonuses. With my background, I never understood much about stocks and probably left a lot of money on the table in the past. Stock options can be a massive incentive to the initiated. When things go swell they can also be a good way to make some quick money. But in general, I always saw them to be anticlimactic.

Stocks are a bunch of money I could get if I stayed X amount of years with the company. Hopefully by the time they vest that amount won’t be eaten up by inflation or the stocks having tanked. As it is not always your decision to leave a company they can be carrot that’s been dangled for a long time you won’t ever get to.

I understand it from a company point of view. Stock holders are part owners of the company and on paper are involved in the decision about the future of the company. This sounds like a great way to give employees a feeling of belonging and empowerment. Is a letter from time to time that asks you to vote for higher up people in your company you never heard of empowerment? Or does it feel like you have a small voice only on paper? A voice drowned out by larger stock owners who see your company as an investment instead of a place where you work. Drastic company changes happen because of fluctuations in the stock market or demands of high percentage stock owners. I could be wrong there, but I hardly ever heard the employees and small stock holders being the driving force.

It is however important to take stock option bonuses serious. The reason is that this is one of the main ways a lot of companies measure your impact in the company. So while they seem not as exciting as a promotion or getting a direct money bonus, seeing a decline in them could be a danger sign to your career.

You can’t choose a family, but you can who you work for

Families are great, but they can also be tough to work with. And you tend to be forgiving as it is where you came from and people you will have to deal with all your life. It is a complex construct, full of drama, weird relationship fluctuations and surprises. This should not be a thing that interferes with your professional work. So, no, even if that makes me sound like a party pooper, who you work for isn’t your family. Over time you will make friends and bond with people. You can build a network of contacts you shared successes with and learned from failures. But that’s not a family, and it will always feel forced and odd to me when companies use “Family” as a slogan or a way to show that they are “different”.

When machine learning assisted code completion came around in the form of GitHub CoPilot and the fast-follow Amazon Codewhisperer it was impressive to see just how fast new ideas follow the Gartner Hype Cycle.

• The first impression was that this would be the end of development as we know it and that it is yet another attempt of big corporations to benefit from free software and data on the internet.
• The next step was to bash the tool and counteract the hype. People found the flaws in it and generally jumped on the “computers do dumb things without humans” bandwagon.
• Once you used a tool like that for a while though, you start to realise that the original criticisms are largely based in not giving the system enough to work with.
• And the more you use it, the more you realise that the “write a comment, get the code” or “start a function name, get the best of StackOverflow” scenario of using the tool is a great way to show what it does, but in reality the least powerful part of it.

I’ve been using GitHub CoPilot from very early on and lately also got access to Amazon Codewhisperer and I came to the conclusion that this indeed is the future of incredibly effective development. And not only for single users, but even more importantly for larger teams.

Getting used to cruise control

Lately our car just gave up and we had to get a new one. We replaced the 14 year old mechanical monster with a fancy new one with all the bells and whistles. I know I am very late to the game, but for the first time I now have a car with cruise control. And it felt weird to use it. I turned it on, the car accelerated without me doing anything and not having to step on the gas at all feels like the “driving” has been taken away from me. However, it also means I get less tired, I can concentrate more on the driving rather than keeping the legal speed and it turns out I use a lot less petrol.

This is what I found ML assisted code completion to be when you use it for a longer time. At first it feels annoying, noisy and pushy to get code recommendations on each word you write, but you soon get used to it. What is even more interesting is that whilst the first recommendations felt not at all like my code, the system soon learned how I like to write things.

Much like your mobile phone gets used to your mannerisms of texting when offering you autocompletion options, Copilot realised that, for example, I do favour event delegation to adding event handlers to everything. Even more interesting is that it recognises context.

Context recognition

I had to write some demo tables of data for a project. I wrote an HTML table and defined “Name”, “Type”, “Width”, “Height” and “File Size” as table header cells. I then created a JavaScript array with demo JPG files, added a reference to the table body and defined an empty string called out.

This prompted Copilot to offer me a loop over all the array items and recognised the dummy data for each data cell:

In another example I wanted to create a “copy this” button and wrote a button element with a data attribute of snippet inside a list. By adding an event handler to the parent element, Copilot realised that I want to have an event delegation solution that checks for a button and reads the snippet data. It also inflected from the “copy” text of the button that I want to push this data to the clipboard:

Framing ML assisted autocompletion as a “give me things from the web for my task” isn’t what it is at all. Try it inside a bigger project and you will realise that the autocompletion recognises the workings of your product and offer you to call existing local functionality instead of generic, third party methods.

Detection of reusable code can lead to an automated code standard

Now, imagine a whole team of people using a system like that and feeding it older, established products that are to the quality standards your company expects. Accepting autocompletion that feels correct and accelerates the coding process and downvoting wrong offers and making them disappear will have an amazing effect. The system can automatically collate what makes your team most effective and thus establish a code standard and reusable code library that is automatically applied. I spent months of my life trying to detect either in code of my teams and even more frustrating months trying to get people to embrace code standards and best practices. If your editor automatically offers you things that look and work great, there isn’t even a discussion about this.

This is the cruise control idea. As developers we keep writing the same code over and over. Most of what we do isn’t create something from scratch, but instead use already existing libraries or write the same solution in slightly different ways. This should be automated and can be using ML assisted autocompletion.

Code explanation and documentation

One of the most arrogant and false things I keep hearing from people is that their code explains itself. It would be gorgeous if that were the case. It is true that clean, structured code is easier to grasp. And yet you keep finding yourself months after you wrote a certain solution looking at it not understanding why it actually works. Writing good code comments is an art, and one that has not many people following it. One of the big “wow” things we did with ML assisted code autocompletion is that it can generate code from a comment or a schema. This is great, but I am much more excited about the inverse use case. Copilot labs and GhostWriter AI Mode have a feature that allows you to highlight a piece of code and it will explain to you in plain language what it does. This is experimental, and we need to do a lot of “nah, that’s not it” for it to become really useful, but it is great to see that, for example, some CSS that is obvious to people who like to write it get a human readable explanation why there is a weird percentage in there.

Let’s cruise along…

There is a lot more in this, and I will keep writing about some of my findings here, but I for one am super excited about what machine learning can do for us as developers and I think the sweet spot really is in bigger teams rather than making the individual developer more effective in copying random bits from StackOverflow as I outlined 7 years ago in The full StackOverflow developer .

The browser developer tools Console is so much more than a place to log your messages. It is a way for you to programatically access the currently shown document and window, read out values and change them. On top of that, it has a powerful API of helper methods to make that easier than with vanilla JavaScript.

Over the years, I wrote dozens of helper scripts that I use in the Console or as Snippets in the browser to make my day to day work easier. And lately I started tweeting about them using a “Dear Console,…” moniker. People seemed to like that so I started to collect these links on a Dear Console,… web site.

On this site you can:

• see all the scripts with explanations what they do
• either click each of them to see the code, or copy them directly using the copy icon
• paste them into the Console on web sites you want to query or change and hit enter

Here’s what that looks like in action:

You can also filter the scripts by tag and you can use them in your own snippets .

The site is hosted on GitHub , and I welcome any issues and pull requests there.

When I wrote the developer advocacy handbook and advertised my new role as “Developer Evangelist” to my company one of the main points I made was how developers are an incredibly important audience for any company to covet. Not only do they build your own products, they are also influencers for other people. Developers are early adopters of technology and are often the people non-technical folk go to for advice what new computer/phone to buy or product to use. Developers are also on the more affluent side of the user spectrum and are OK to spend money on things they like and find useful.

Whilst many of these things are still the case, having managed a product that is solely for developers in 2020+ gave me a slightly different impression.

“Developers are influencers” doesn’t work in a consumer space

Over the last decade computers, the internet and mobile usage has evolved from a hard to grasp and not that desired thing to a commodity. Whilst computer literacy is still quite low, the need for it also became a lot less than it used to. Rampant consumerism doesn’t want people to tinker with products or even understand how they work.

Hardware is a closed, black hole that consumers are OK with.

Mobiles and laptops these days aren’t there for people to understand and customise. They are there for people to consume things on, buy things on and discard them when they get too slow. It’s pretty much impossible to repair or upgrade any of them and often you find that a 10 year old machine in pristine condition that would be “good enough” doesn’t even get the lastest OS upgrades.

This also interestingly seems to lead to developers not chasing the newest and coolest. I know many a developer that has skipped the last four upgrade cycles of phones and laptops as what we have now feels more developer focused than the newer machines you can’t even upgrade.

We also became weary of explaining things that aren’t developer centric at all. Apple does an amazing job getting people into their ecosystem and give them what they need without having to think about it. Even on Android copying content from an older to a newer phone is a breeze compared to the days of having to connect the phone via USB and finding a way to copy things over. In essence, the developer and consumer market has diverged a lot in recent years, and the saying that “if developers love your product they will tell all their non-techie friends about it” becomes a lot harder to prove. What makes end users happy – not having to understand any of the things their machine does – drives developers nuts as we feel locked out. In the past developers were much welcome experts to help you understand why something doesn’t work. These days as a developer you are as clueless, but even more frustrated as you know how things should work.

Browsers have become invisible

Especially in the browser market making developers happy was paramount. The story was that Google won the browser space because they made developers happy. They innovated the platform, they integrated excellent developer tools and the browser was ridiculously fast and small compared to others. The great news is that by now, the differences in browsers for the end user have become negligible. Most end users don’t even know what a browser is. Especially on mobile they often don’t realise that they don’t use “their browser” but some in-built browser of the app. On iOS, there is only one browser engine anyways – no matter what interface you put on it.

So whilst in the past developers were a good advisor for people on which browser to choose, this need has evaporated. Most of the time it is the browser that comes with the OS, or the one that people used for years anyway. There is a much deeper affiliation of users to the services browser companies provide than to the browser itself. It just feels natural that you use the browser of the same company that provides you with a great email and maps experience.

Sure, we now complain that “Safari is the new IE” as it isn’t as fast in adopting experimental technology and hot off the press standards. But if you look around what really ends up in products that people use then these standards have a 1-2 year adoption cycle and not the four weeks we have upgrading the browser.

Conclusion: making developers happy doesn’t automatically increase the number of end users

It is undoubtedly a good thing to make developers more efficient and give them the tools they need to find out how to debug and optimise the products they build. You can’t expect a great developer experience to automatically convert into a massive end user success though. You need to find other ways to measure and get support and investment of your company in developers.

A great developer experience of a tool only converts into more end users and more money coming in when you sell directly to developers. And even then you need to be lucky to hit a sweet spot of affordability and usefulness. There are other, less tangible or obvious ways in which you can measure success, and I will cover them later in this series.

In part two I will cover trying to increase developer adoption of a product and how hard that is to test and measure.