It was around 2005 when I sat at my job and didn’t like it. I was head of web development at an agency in London that covered huge web sites and government portals. The pay was great, my team was top-notch and the products interesting. What I didn’t like was that my computer was a mess. I dealt with various products each with their own stack. Early .NET (with state stored in a hidden form field) here, Java Spring there, PHP on another. Flash generated from Apache Turbine from XML to use XSLT to build the HTML fallback. Everything was complex. I had no idea what all these files on my machine were and the hard drive was always 95% full causing blue screens.
There and then I opted to even more moving from random things on the backend to a standardised front-end. It makes sense to know what you use and to leave a lot of the weird things to the browser. It is an exciting task to cover the basic use case and enhance with more capable environments to run your code in.
Things couldn’t be simpler, right? Well, yes, but we don’t embrace this enough.
Yesterday I found an excellent repository listing useful resources. I had written a few that fit the bill of this project. So I thought I’d go and contribute them. The project was on GitHub and there were clear and friendly instructions how to add mine.
So far, so hoopy. I forked the repo, I pulled the project. I ran the NPM command to get a CLI wizard to add my projects.
Then the project pulled down 670MB of dependencies. This included a full build of chromium to create a screenshot of my projects. Then my node/NPM setup needed updating as I had it left for a few weeks. Another few megabytes and install steps.
Now, I was in the Microsoft office when I did that, so – hey, whatever. Even at home I have 250mbit downstream, so that’s OK, too. My Mac has a 1TB hard drive, so no worries there…
But here’s the thing. For generating a 10 line JSON object that describes a web resource I spent all this time. I have truckloads of code on my computer I have no idea what it is, how safe it is and if I should keep it up-to-date to be safe.
Imagine me being a much younger, much more eager and gifted developer in a different place. A country where connectivity is at a premium, slow and costs an arm and a leg. An eager person that wants to prove themselves and has a lot to contribute. I can’t. I won’t. And I’d feel terrible for not doing so. I’d feel like I don’t belong. I’d feel like I am not good enough – no matter how much skill I have.
Back to 2005. I have no idea what’s filling up my hard drive. Complex setups are in the way of me contributing. I am not happy. That’s what anyone not as privileged as me would feel like.
We should be better. There is nothing wrong with trying things out. We should use experimental and complex technologies on fun projects. Not much is at stake, they are good for us to play with things.
But – we should not put up random barriers for people who could have fun with us and help us along the way. A small part of us puts a lot of dedication into improving the performance of our projects for our end users.
When you go open source, developers are also users. We should put as much effort into making it easy and fast for people to contribute to our projects. Unless we do so, we will not have any diverse and inclusive community. Let people show their skills – don’t force your devops needs unto them.
I attend a lot of conferences and have done so for the last ten years or so. I just moved and had to pack and unpack a lot of things I accumulated over the years. Sifting through piles and piles of T-shirts, hoodies, stickers, connectors, leaflets, tote bags, bottle openers, phone chargers, memory sticks, lanyards and so on made me think.
I understand that I am in a massive position of privilege as someone who can attend a lot of events and speaking at them. I am also aware of how cool it was to attend my first event (PHP conference 2004, Amsterdam) and get a PHP plushie elephant, T-Shirt and stickers. I also understand that for companies giving out swag at events is a good marketing strategy. Sensible swag is a great thing. I do use my totes to go shopping. Some of the power plugs and phone chargers I got at an event saved me from running out of battery.
The problem though is that a lot of the things you get at events don’t have a long time until they are obsolete. I have a few powerbanks that are woefully under-equipped for today’s mobile needs. I have charger cables that don’t connect to any of today’s electronics.
Often there is a hoarder mentality taking over and when we go to events, we grab as many things as we can. Once the rush ebbs down we sit at home in our hotel room looking at the loot and wondering what the hell we did take this for. When I go to conferences I tend to make it worth while by adding a few days for office or customer visits. It is depressing to go through a big hotel and see cleaners throw away piles of branded things from the conference the day before. We should do better.
Now, I am not a conference organiser. I organised one and that was hard enough to avoid being wasteful. So I am not putting the blame on people as many are want to do on the internet. There may be valid reasons for things being the way they are. Talking to conference organisers I also heard that attendees expect a few seemingly superfluous things. Without a T-Shirt you’re never going to wear again it wasn’t a good conference, right?
There are a few events that do better. I am a big fan of Beyond Tellerrand. Marc, the organiser makes sure of a few things each time:
That the T-Shirt looks great and is something designed for you to wear outside of our little world.
That swag given out by conference sponsors are sensible, reusable things.
That there is a bin for swag that people don’t want on the way out
That you can leave your lanyards for re-use
That there is a sticker exchange table. If you have some left over, you can bring them and someone who will get excited about them can take them
A few other conferences have taken on similar approaches. Halfstack has a pub quiz at the end of it where prizes are often swag from older editions or other conferences.
Speaking of which, there is a real issue with re-use and what to do with swag you have. Most clothing collection points are not that interested in conference T-Shirts as they don’t keep the homeless that warm. And most second hand stores don’t want anything with a company logo on it that isn’t a clothing brand. I used to give out lanyards to local schools for the kids to keep their keys on. This also ceased as schools don’t want branded things.
When I left England, I did a goodie table at State of the Browser with old conference and company T-Shirts. This went down well, a lot of attendees took them away and marvelled at the design of 2006 del.icio.us and Flickr shirts.
This week I went to the office and made a swag table for people to take what they fancy.
This also works, but it is all damage control.
I started doing a few things that may also work for you:
I bring my own lanyard to conferences.
I take a photo of my badge and keep it there for recycling (if the conference offers that)
I don’t take shirts unless they are really cool. I do ask around the office if people want some when I go to a conference though.
I don’t take goodie bags without checking first what’s in them. Most of the time I skip them. Again, I am privileged. This is not an attack at people who enjoy their bags for the one conference they attended.
This may not save all the issues of the planet. But the way we as conference attendees act can inspire organisers to offer recycling and sponsors to think harder what to put their logo on.
I feel weird about this. I know people put lots of effort into giving us extra value at the conferences we attend and for some attending that tote bag or backpack is the best thing ever. To me, however, I don’t want to have more things I don’t need and I can’t give to others. So don’t be offended if I skip on the goodie bag or the speaker gift, I don’t mean to offend, I just want to live with less things to carry.
“Thou shalt not forget about the agenda or deviate from it”
It’s a lot of work to stay up late (or early) and dial into a meeting. An agenda published at least a day before makes it worth while. If people can’t attend, they can add the info you need from them to the agenda.
“Thou shalt not cancel meetings shortly before they start”
This isn’t “giving people back the time”, this is “annoying people who stayed up late to have this meeting”.
“Thou shalt not all speak at the same time”
Nothing is more grating when you are sitting at home late night and have a cacophony of people for the first 5 minutes talking about what the cafeteria is serving. Sure you can mute, but how would you know when to tune in again?
“Thou shalt not keep your mic on when you are typing”
Look, we all love some breakbeat and drum and base. But not while trying to follow a meeting. This also applies to heavy breathing and sneezing. Or eating.
“Thou shalt not abandon the chat”
Anyone who has trouble connecting won’t be able to tell you. But often you can already type something in the chat. As a person not in the room it is also daunting to try to interject, so often people leave feedback in the chat instead.
“Thou shalt not assume people can see your presentation clearly – or at all”
Bumping up fonts, not presenting intrinsic and detailed flowcharts is the idea. Imagine blurry things all over them. Even better: a shared slide deck so people can see it on their own machine.
“Thou shalt not scribble on whiteboards and assume people can follow”
Digital meeting systems are sophisticated and whilst Teams f.e. can make handwritten notes readable and even “see” through people blocking whiteboards, taking notes in the tool on screen includes everyone.
Posted in General | Comments Off on The seven sins of meetings with remote participants
This is a write-up of my talk at DotJS Paris this year. The video is also out.
We obsess about coding, creating automated workflows and optimising. And yet our final products aren’t making it easy for people to use them. Somewhere, we lost empathy for our end users and other developers. Maybe it is time to change that. Here are some ideas.
I’ve been doing web development for a long time. Over 20 years. When I started it was literally all fields. Interaction in web sites meant that we needed to send forms and deal with the logic on the backend.
When JavaScript came around all that changed. It enabled us to build interfaces with much higher fidelity, but that seemed not to be enough. We wanted to differentiate ourselves as something better than “web developers” – a term belittled by “real programmers” back then.
JavaScript, DHTML, Unobtrusive JavaScript, Flash/Air/Flex, DOM Scripting, AJAX, Comet…
We coined a lot of clever technology terms like DHTML and AJAX and touted them as “de facto standards”. We also called anyone not professional for not embracing them. Over the years we kept going in circles. We kept over-relying on JavaScript and proprietary technologies. And then we told people not to do that.
Being a web developer in the past was interesting. You had to learn about the platform. But there was also a different side to it. As the platform was not standardised there was a lot of trial and error and hacking around inadequate tech support. You had to know how HTML and browsers work to get started.
WYSIWYG editors didn’t result in usable web sites. It was a competitive advantage to know about browser bugs and how to work around them. Was this a professional work environment? Questionable, but it was a creative one. We developed a lot of best practices and named – for example – a lot of CSS tricks to create different designs in pretty inept browsers.
It all kind of kicked off and we learned a lot more about our job when debugging tools got better. It started with Firebug and continued into in-browser developer tools and dedicated IDEs for web work. We got insights not only that things went wrong, but also why they did. We also got visual tools to tweak settings and see what it takes to make a CSS layout work.
Then we added abstractions…
The differences in browsers in the past was a hindrance to quick development. That’s why we built libraries and frameworks to take that workload off developers.
When this resulted in bloated and slow products, we created build processes to automate a lot of the work. We wrote more code to undo unnecessary code and untangle complex dependencies. This is natural for developers to do – we want to automate boring and repetitive tasks. But doesn’t it feel a bit over-engineered? What if we didn’t add too much code to start with?
These days things are different. We say we develop a lot, but we do something else much more.
We depend on third party products to develop our products. This is OK, as most dependencies are open source and shared with a community, but it also means there is an overhead. Maintainers and new people coming into the market get split into several communities. They need to learn the abstraction and the platform and often our end users get much more code sent to their devices than necessary.
Our debugging tools are incredible these days. But they often fail to help us when the problem is the abstraction code we rely on to make it easier for us as developers.
We get excited about the dependencies. We keep losing sight on how the platform itself is developing. A platform that has never been in a better state and many abstractions are not as useful as we think they are.
We seem to be caught up in our own excitement of doing things new and different rather than embracing what matured quite nicely over the years.
Maybe it is time to be more humble about our role as developers. Our job as developers is not to make it easy for us. Our job is to build things that make it easier for people to do things. All kinds of people. With bad connections, unreliable hardware and disabilities and problems of all shades.
The products we build now are our legacy. We will be measured by how useful our products were, how inviting and how easy it was for the next generation of maintainers to take over from us.
If we want people to remember us fondly, we need to build products for people. We need to consider the effects our products have on their lives and keep them safe from harm. Harm that may be based on our arrogance or an over-reliance on third party dependencies.
To ensure that, let’s take a step back from the how of technology (what platform, what framework, what code methodology du jour…) and look at the needs of our users.
In order for our products to deliver what people need they must be available in less capable and unreliable environments. They must be accessible to people of all kind of levels of physical and mentally ability. They must be secure and not allow our users to shoot themselves in the foot. And they need to be mutable to the needs of the end users. This means support for assistive technology and also to things like high contrast mode or reduced interaction mode.
Once we covered the basics we should add more nice-to-haves. These include enhanced performance by preloading upcoming content. Extended availability with offline-first architectures. And customisability to the wants and not only the needs of our users.
Another “want” of our end users is making full use of the platform in a safe manner. Like allowing for biometric logins on on-device payment solutions. They have these devices, they know how to use them. So why do we force another interaction flow on them?
We should build interfaces that allows people to make mistakes and not throw them back at them. A telephone number with parenthesis and spaces is not a hard thing to parse in our code. Why ask people to write it in a certain way or get stuck? Using natural language processing we can allow users to enter human search queries. Let’s not force them to click through complex interfaces to get a search result.
Making end users happy is by far the most important part of our work. However, developers are people, too. And demanding from them to know everything is not sensible.
People expect far too much of developers. As what we create affects the end user and everyone else in between in the process of delivery a lot of best practices assume that we have infinite time and wisdom to do everything right. And that doesn’t even include the pressure we put on one another. You encounter a lot of non-sense demands what constitutes a “professional developer” spanning from knowing different platforms by heart and understanding how every single new and hot abstraction works.
A lot of our work as developers is having faith in third party products. Frameworks, NPM packages and services is what we trust to make us more effective. These help us create more in a shorter amount of time and often we rely on them to help us with the important parts. The problem is that historically these tools don’t create accessible, secure and maintainable products. They are built for speed and convenience, not with a user centric approach in mind.
Currently if feels like we are missing out on a lot of opportunities. Developers don’t keep up with the one thing they can not demand their end users to change – the web platform. Instead we use and learn about abstractions that promise an easier way to develop. This is understandable, but often based on prejudices of more seasoned developers still suffering from bad memories of the web of old. Abstractions are a great way to build a lot in a short amount of time and – to developers – easy to maintain products. However, this is a problem when the abstractions themselves become a roadblock.
A tale of fixing a typo…
The other day someone asked me to help them with a project and take a look at a single web document. Nothing fancy, one document with a bit of text and some design. No interaction, no special ”app” needs. I looked at the page and I found a typo. Normally I’d write a report of what could be done better. But I thought I’d be a good web citizen and go to GitHub, fork the project and do the changes myself adding comments why I did so. I also thought it a sensible thing to run the project locally to see the changes.
As it turns out, the project used not markdown or HTML, but a templating engine. Building the project locally meant downloading 150 MB of dependencies. It then failed because I tried it in my Linux shell on my Windows machine. Some of the dependencies flat out expected a Mac without any information about that.
In the end, I fixed the typos directly on GitHub using the raw view. I encountered some waste of time and effort and I am OK with that. However, now imagine me being a person that just wants to help out an open source project. A non-affluent person on low-level hardware on an unreliable or expensive connection on the web. Not using the web interface of GitHub would mean I am blocked and I paid the price of downloading 150MB for it.
We should be better than this. There are lots of articles on how to make our products perform well for end users. But what about the technical, cognitive and monetary efforts we expect from contributors? Shouldn’t it be easy for anyone to participate rather than just those with the fastest computers and the best connections?
We have amazing tech, and yet nobody is happy.
It is extraordinary to see what’s going wrong at the moment. We have users of the web who get incredible browsers. Our apps and sites have functionality that in the past was only available in apps that came on DVDs. Yet users complain about browser updates as too much work. There is also a general feeling that native apps feel more convenient and secure. The web has a bad reputation as a wild west playground.
We have developers who have great tooling and get lost in looking for the next big thing. They have no time to keep up with what’s happening. Instead there is a feeling of repetitive complaints about problems of the past. And citing these as a reason for the lack of quality when it comes to delivering great products. Far too often you hear the “but browser X doesn’t support it” argument. Most of the time browser X is an outdated version not used by anyone in the audience of the product at hand.
Newcomers to the web find the stack exciting enough. They don’t put much effort into learning it though. Which is no surprise. The people they look up to don’t mention its benefits. Instead they praise libraries, frameworks and already built components as the best way to start.
It is not the fault of the technology or the platform. It is our lack of focus and a general “clever laziness” that may have gone too far.
As a whole, we’ve become a group of full stackoverflow developers. Instead of learning how things work, we apply them and hope for the best. When something goes wrong, we go to help channels like Slack, Twitter or Stackoverflow and we ask for a fix. The speed and voting nature of these platforms favour the quick and results-oriented over the explanatory. In other words, people explaining why something doesn’t work and that it may even be a bad idea get downvoted. Those who give you a “copy and paste this and all will be fine” get celebrated as effective and great developers. The learning aspect is not what we want to have – we only want an answer that works.
Many things are to blame for this state of affairs. Maybe you don’t even see it as an issue. There is no denying though that we could be better. We should be a serious as a part of the job market and not a place where money is burnt. We need to become more inclusive if we want to keep growing both in size and impact. We have to find a way to make this less of a competitive rat race. I’d love the world to see software development as a place where people of all kind of backgrounds can grow in. And you grow most by learning.
So let‘s take a look at where we use up a lot of our energy and what we could do about it.
When you open developer tools in browsers you get a huge amount of options. I am pretty sure the design and marketing department woud not be happy if this were a commercial product. It is overwhelming to get this as a first experience. This is not a personal feeling. When you look at the usage stats of in-browser tooling 2-3 tools are always in use. All the others are only looked at on a need basis and even then by a small group of experts. Yet we added them all and made them immediately accessible. It is the proverbial kitchen sink. It stops people from embracing advanced debugging on the web. Want proof? Ask people how often they use breakpoint debugging. Most of us still prefer a – much less superior – console.log().
We work in several contexts and keep switching them, which is bad enough. But instead of wondering how to fix this we celebrate it. We love to talk about and tweak our editors. We fight what is the best browser. We all have a pet resource to look up information. The most baffling of all is that we see the terminal still as the most professional of all environments.
Knowing about all these tools is a full-time job in itself. Jumping from one to another is a cognitive overhead we keep underestimating.
We edit a file, we jump to the browser and its developer tools to see if it worked and tweak it if needed. We fail to see why it doesn’t and we go to some documentation to find out. Once we fixed the problem we go to the terminal to do our version control and publication.
This is exhausting and feels unoptimised.
Let’s rethink our tooling. We switch from one context to another to find out what went wrong. We also switch to move along on the delivery process. Wouldn’t it be better if our tools prevented us from doing things wrong in the first place? What if we embedded the learning part into the other parts of the process? Tools should tell us what is going wrong and why it is wrong. Not only flagging up that there is something that needs fixing. We should consider a more holistic approach to developer tools. Instead of a steep learning curve the tools should come with sensible presets. Instead of giving us the kitchen sink they should offer contextual functionality. We have these opportunities. Development tools these days aren’t black boxes we pay for. Most are open source and encourage contribution or at the very least feedback.
A lot of excellent editors are web based and can either run in a browser or on the computer inside an Electron shell. This means that you can hack around on the editor. Visual Studio Code, for example, is written in TypeScript. Extensions to it use a heavily documented API to build interfaces. More importantly, it also means that you can install an editor on your server and run it for your users. That means they don’t need to install anything on their machines. They can open it in their browsers and start coding or tweak settings. GitHub has a basic editor included and even full IDEs like Visual Studio now come as an online version.
This also allows you to preconfigure the editor on the server. Contributors can use abstractions like TypeScript or Sass without having to install them. Online editors like CodePen, Stackblitz, Codesandbox, JSBin and others do this and are a big success. They don’t only allow people to code, but also to collaborate on code and try things out without much overhead.
Browsers aren’t unknown entities created by only godlike developers either. The most used ones are based on open source projects that invite and allow contribution. The same applies to developer tools inside them. You can write extensions for developer tools in case there is something you are missing. For browser makers extensions are a great opportunity to try out new functionality.
Most browsers can also be remote controlled. This means you can automate a lot of the processes historically done by hand by testers or end users. Headless browsers allow you to open a URL, render the page, create an image of it and compare it to others. This is an excellent way to automate testing of your products. In other words, you have remote access to the browser and its inner workings. And you can also use parts of the browser in other products instead of having to re-invent them.
Documentation of web standards and browser functionality is also open these days. In the past each browser maker controlled and duplicated these efforts. These days, the Mozilla Web Docs have become a place where every big player of the web contributes. As it is an open wiki it also is easy to keep up to date. Can I use is another excellent resource. It gives you up-to-date information on browser support of certain features.
Both these resources are not only products on the web. They come with APIs to get the content and use it in other products.
The open nature of tools these days allows us to be flexible in how to get developers to learn their trade. You can’t know everything, and that is a problem. So why not make the tool tell you when something is wrong? Using the open documentation we have now we can offer something new: In-context documentation and linting – you learn while you code.
Word and other text editors put red squiggly lines under spelling mistakes. Code editors like Visual Studio Code using information from Mozilla Web Docs can do the same. The above screenshot is the webhint extension running inside the editor. Some elements have squiggly lines under them, meaning something is wrong.
For example, the extension flags up that a button element is exactly what it says. What you might not know though is that to make it work across browsers, you also need to give it a type attribute of “button”. This is where webhint complains. Now you know, you probably won’t forget to add the type next time.
Webhint also knows about cross browser compatibility problems, like the output element not being supported by older versions of Internet Explorer.
The validation works live while you are typing. For example, an image without an alternative isn’t accessible. So when you close the img tag without adding at least an empty alt attribute, you get a squiggly line.
What about the problem of context switching?
What about the problem of context switching? As both Visual Studio Code and Edge are based on Chromium, we can do something about this. Imagine you write some Sass, and switch over to the browser to see if the outcome works. You tweak some settings in the visual tools until the problems are fixed and then go back to the editor. That’s where it gets tricky. You fixed the generated CSS but you still have to find out which Sass generated that. Using the the Elements for VS Code extension, you can embed the developer tools of the browser directly in the editor. The editor fires up an instance of the browser and hides it in the background. That way you can use both the editor and the visual tools in the same context.
Now we looked at a way to get documentation and best practices into editors. We also found ways to fix content switching even more by adding browser tools to editors. But what about the problem of the full stackoverflow approach? There seems to be no way to stop people from randomly copying and pasting code that works without considering the consequences. It is just too easy and rewarding to do.
If copying and pasting code is a thing people do, why should people do it? Computers are much better at analysing the performance of code and finding patterns. What you can see in this screencast is an experimental feature of Visual Studio Online called AI-assisted IntelliSense. What it does is use a machine learning model that has been trained on the most successful open source projects on GitHub that did similar tasks to what you’re creating. It then gives you the most likely results from that as an autocomplete option in the editor. In essence, this is copy and paste with a lot more computing smarts.
Another example of seeing a pattern what people do and automate it and make it safer. Randomly copied code from a forum can’t get checked for possible security issues. This can.
I don’t have all the answers we seek to make development a simpler task. But I think we are well on the way. With an open mind, open ears and open source we can fix a lot of the things that both tire us and make our market appear less appealing.
People are worried about automation and computers taking their jobs. They also are worried about large tech companies ruling the world without opening the doors to people who haven’t got the same education and experience as the ones working in them.
By changing our tools to be more all-encompassing and making our accumulated knowledge part of the development process we make a good start to changing that. And we make it easier for the next generation of developers to focus on delivery, not on knowing all about the toolchain.
Posted in General | Comments Off on Develop, Debug, Learn? A time to re-think our tooling.
The other day someone asked me to help them with a project and take a look at a single web document. Nothing fancy, one document with a bit of text and some design. No interaction, no special ”app” needs. I looked at the page and I found a typo. Normally I’d write a report of what could be done better. But I thought I’d be a good web citizen and go to GitHub, fork the project and do the changes myself adding comments why I did so. I also thought it a sensible thing to run the project locally to see the changes.
As it turns out, the project used not markdown or HTML, but a templating engine. Building the project locally meant downloading 150 MB of dependencies. It then failed because I tried it in my Linux shell on my Windows machine. Some of the dependencies flat out expected a Mac without any information about that.
In the end, I fixed the typos directly on GitHub using the raw view. I encountered some waste of time and effort and I am OK with that. However, now imagine me being a person that just wants to help out an open source project. A non-affluent person on low-level hardware on an unreliable or expensive connection on the web. Not using the web interface of GitHub would mean I am blocked and I paid the price of downloading 150MB for it.
We should be better than this. There are lots of articles on how to make our products perform well for end users. But what about the technical, cognitive and monetary efforts we expect from contributors? Shouldn’t it be easy for anyone to participate rather than just those with the fastest computers and the best connections?
Nobody thrives in complex and demanding environments.
Most of our work on the web these days demands us to have a local server or local workflow running. In the past, this was a sensible thing to do. I can’t remember a time when I didn’t have an Apache, Tomcat, Resin or PWS/IIS running on device as being online wasn’t the norm.
It is still sensible to have a local setup running of your product. It becomes less so when we spend most of our time downloading, configuring and fixing that setup. We deal with an increased complexity of our toolchain. And that can block out a lot of potential contributors, learners and beginners when their first experience mirrors mine.
What’s the alternative?
What I did made a lot of sense to me. Editing in the browser, still writing good comments and sending a pull request. We’ve always belittled online editors as last resort solutions. Things changed though. These days they do not only give us a good editing experience . They can also prevent people from installation and configuration frustrations. If I want to play with TypeScript as a language, why should I first have to set it up?
It is exciting to see how CodePen, Stackblitz, Codesandbox, JSBin and others empower developers day to to day to become creative and try things out without overhead. Development environments built into browsers become more capable each day and even high end IDEs like Visual Studio now consider an online version.
People like Ana Tudor work exclusively in online editors and her work is stunning. All she needs to get started is a laptop and an internet connection. And there are even extensions and tools to allow her to write offline in the editors she is used to.
I love how far the web has come and I think collaboration is the only way software can survive in the long term. We should make it as easy as possible for people to contribute. And that does not mean for them to fragment their computer with lots of complex project setups and configuration.
There’s lots of documentation and coverage of how to make our final products perform well for our users. Maybe it is also a good time to stop, look around and consider the performance of developer environments. And the overhead we demand from potential contributors.
