Hooray, Goto conferences just released the video of my talk on Developer Tools.
If you want to play along with the examples, they are available on GitHub.
First of all, congratulations. You managed to kick off the next step of computer and human interaction evolution. Of course we’re in the middle of a hype, but there is so much good in AI generated content and conversational interfaces, it’s pretty safe to say all things “computer” will have some part of this included going forward.
You have an issue though: relevance. Or, as some call it, hallucinations. Systems fed with lots of data that wasn’t quite quality controlled that manage to make even erroneous data sound like the best thing since sliced bread could turn out to be disastrous in the long run. Just because something sounds clever, doesn’t make it good.
Here’s the bad news: the wisdom of the masses will not save you. As someone who worked on products with millions of users and highly visible interfaces like browsers I can tell with great confidence that people will not downvote and report wrong results.
The idea of increasing the weight of results that were the end of a conversation is also flawed. It’s like asking your obviously miffed partner what’s wrong and they answer “nothing”. This is not the end of that conversation.
Dissatisfied users do not put an extra effort in to downvote the wrong result – they just leave as they feel that they already wasted enough time with your product.
How to make that better? Well, one way is to give your systems context and limit it to that one. GitHub Copilot for docs is a great example of that.
The other, and here is where I come in with my pitch, is to consider editors, writers and tech experts to flood your product with great solutions, downvote obviously wrong ones and annotate others to explain that whilst this is a solution, it may come with a caveat.
The great opportunity you have right now is that the market is saturated with laid off people who have some time on their hand. These are experts in certain fields: programmers, designers, product managers and many others. Ironically, you will also find a lot of technical writers to work with right now as they have been laid off as part of an overreaction to your success. Who needs authors when the machine can generate lots of text for free (or pennies in traffic)?
Of course, creating a community of experts to talk to your machines takes time and effort. Guess what? A lot of community managers were also laid off when companies closed their tech communities.
As an expert editor or “GPTeacher” I could get in addition to the upvote, downvote and copy icon also one that allows me to edit the response. This would go into a review process with two others and then back into the system.
As a developer known to you as a “GPTeacher” I could write code examples on GitHub and tag them with a special tag #gptfodder (or, whatever), and again, after a peer review with others it’ll get more weight to be shown in a higher frequency in conversations people have with your systems.
I know, all of this feels a bit old school and Wikipedia-ish. But, it worked in the past and it scales much better than hiring a lot of people in outsourcing markets to clean up things that are obviously wrong.
We are at a crucial point here. Some governments already work on laws to block your systems as there is no attribution or licence information in your results. It would be a shame if we let machines educate people the wrong way because we were not interested in giving the system human supervision when it was needed.
Want to know more? Let’s start a conversation and build a community of enthusiastic experts that are OK to teach the machine to do better rather than hoping people will be able to see the flaws in the conveniently offered, clever sounding solution.
I am currently looking for a new job. One thing that keeps happening is that people get my CV, are impressed but then ask me that I seem to be focused on the front end a lot and what my experiences with backend and full stack development are. It seems to me that we’ve come full circle back to when I started as a web developer and had to sell and explain the notion of a front end expert as a real, full-time job, 21 years ago:
Here’s the deal: a frontend developer isn’t a mediocre coder that only dabbles in “easy” languages like HTML, CSS and JavaScript. A frontend developer is someone who made a conscious choice to build interfaces for the unknown with a laser sharp focus on the end user’s experience.
The web isn’t just another compilation target. It’s a platform that allows the user full control over the look and feel. It’s also the only platform resilient enough to weather any change you throw at it. The web works on desktop, android and iOS. And it can do that with one codebase. If you have dedicated developers who know what they are doing and don’t just expect to find a plugin or extension that will magically make your product accessible to all and perform well.
Here’s the not so dirty secret: no matter what platform you choose, what language you write your code in or what framework or library you use – the final thing that arrives on your web users devices is HTML, CSS and JavaScript.
Each (with HTML to a small degree) can cause performance problems, cross-browser functionality issues and become a barrier for users on sub-par connections and platforms or with different abilities. Slow performance is known to lose you end users and being inaccessible is a legal and compliance issue that can get you sued.
I’ve worked on the biggest web sites on this web (yahoo.com, bing, Microsoft…) and on the Firefox and Microsoft Edge (Chromium) browser. Browser makers want one thing: not being blamed for being slow or showing things “wrong”. So we work with lots of internal and external partners to see why their products are misbehaving. This could be extension providers, framework creators or development teams. In these “performance clubs” both in Mozilla and Microsoft we kept running into the same issue: web products with tons of senseless HTML, mostly unused CSS and an absolute avalanche of JavaScript sent to the end users with no benefit to them. All the benefits were for the convenience of the developers and the flexibility to build whatever with a framework that promised optimised output.
The move to full stack development caused us to build a bloated web that loses you customers and costs you a lot of traffic that simply isn’t necessary.
There is of course another reason why our web products don’t deliver: componentisation without big picture planning.
Web products these days aren’t build as documents, sites or even includes. They are built as independent components, each flexible enough to be applicable in many different contexts. That’s grand, until people assemble them nilly-willy and as many as they want to. At times we found 20 different, highly customisable button components that did the same thing.
Here’s where a frontend developer would smell that something is amiss immediately and could trace the waste.
Frontend developers are:
We truly are the shape shifters of the market. So to say that someone who is “just” a frontend developer isn’t flexible enough means first and foremost that most people still don’t know all the things this job requires.
The argument that CSS and client side JavaScript isn’t real coding is nonsense, too. It’s especially ironic that people who claim that also don’t want to touch CSS as it is “too hard and strange”. CSS isn’t about colours and padding any more, with grid, subgrid and flexbox it’s a fully fledged layout system. And it does animation and responsive rendering. With media and container queries you have amazing flexibility and with cascade layers you even have control over how browsers should render the current design.
It is your choice. You can hire frontend developers to build your product, or make it happen somehow and later on hire performance and accessibility consultants to fix what doesn’t work properly. Bear in mind though that the further down the production you are, the harder it will get to optimise and fix a product as you will also clash with new feature work.
When people ask me why I am “just doing frontend”, I can happily explain these things and proclaim that I am proud to be a frontend engineer.
The defence RESTs, POSTs and GETs your feedback.
Addendum: This is also applicable to all the other jobs we have in the market. A good database engineer can save you seconds of loading time, a great cloud engineer can lower your bills and a great backend engineer make sure your servers only do the job they should and not run optimisation pipelines for a huge pile of unused frontend code. And with all the big players right now trying desperately and shortsightedly to please stockholders in times of inflation by laying people off rightsizing, the market is awash with talent. And maybe you can afford three experts for the price of one 10x full stack ninja rockstar who lives in a city where 80% of their income is their rent.
And that’s a wrap. I recorded my last video in the German LinkedIn Learning video course on “Browser developer tools for non-developers”. My favourite stumbling block over the course of the last few days was me starting a sentence with “Und hier verwenden Entwickler:innen…” (“…and here is where developers use…”) and making a pig’s ear out of it by saying “Und hier verenden Entwickler:innen” (“and here is where developers perish”).
I will now do some demo recordings of an English version of the course we will offer LinkedIn US, so fingers crossed that this will be taken on. I think there is a lot of good in explaining the power people have over the web we are given if they know what they can do using tools built into their browsers.
We don’t need to click through annoying, redirecting overlays or wait for download buttons to become active in a minute’s time. We also don’t need to install dozens of extensions just to download some images or be able to control or download a video.
A lot of these annoyances can be worked around using browser developer tools. Where this gets problematic is that developer tools are obviously built for developers, so they are not the most user-friendly. But I think that if you explain the basics and show people how to use them, they can be a great help.
And maybe it is a good thing to ask non-developers to give browser makers more feedback that a design-by-committee, let’s-add-another-tool-why-not approach to developer tools design isn’t the best idea to start with. I’ve tried hard to make browser developer tools more approachable the last three years and we had some successes. Now we need others to follow suit and re-think tooling.
I am currently in Graz, Austria to record a video series of “Developer tools for non-developers” for LinkedIn Learning. We had a massive ride by car down here from Berlin as my partner isn’t too hot on flying.
The city is ridiculously pretty and we arrived on first of May which is the day of work in Europe. We ended up looking for a first of May celebration and ended up stumbling on one of the communist party of Austria, which was a massive surprise until I learned that the mayor of Graz is also a member of this party.
Anyways, I am spending my days now in the recording booth and I am confident that the material will be done by the end of the week. Here’s the demo pages in English, in case you are wondering what it all will be about.
I also really appreciated the swipe-in gadget at the office:
My personal highlight so far was getting continually stuck calling “Main Tools” (Hauptwerkzeuge) “Crown dwarf witness” (Hauptzwergzeuge). I guess it is a wrap for today.