One of the things I always loved about the web is its immediacy. You write a piece of code, publish it somewhere and people can access it. No compilation step, no packaging and distribution, no listing on marketplaces or app stores – just a push of the button.

This gives people a wrong impression that this way of working should scale to products and large companies as well. Often it feels like fast and nimble startups that can “fail fast and often” are the ones that do it right whereas larger, older corporations feel like slow moving dinosaurs in comparison. It gets interesting when you look at the maturity of the products released. Products in “preview” or perpetual “beta” are quick to turn around, whereas full versions need to do a lot more than just provide the functionality.

The main difference is that full version releases in large companies have compliance to consider. Internal quality compliance, and – to a much larger degree – external legal compliance. When I started working in Microsoft and transitioned from developer to product manager I realised that a lot of work and effort go into things that need to be done before we could release a product.

• Security – is the product safe from attacks?
• Performance
  • Does the product run fast and smooth?
  • How much does it impact the overall byte size and speed of the possible parent product (browser, OS…)
• Maintainability
  • Does the product rely on third party code that may be unavailable in the future or poses a licensing problem?
  • Does the product require a platform or language that might not be supported in the nearer future?
• Privacy
  • Does the product record information that could make its users identifiable?
  • Where does the information go?
  • Are you using third party software packages that could also get that information?
• Compliance
  • Are users aware of their information that is being recorded?
  • Is the information retained for only a short amount of time or long term?
  • Can people opt out?
  • Is the product available in different markets in different languages?
  • Does the product adhere to local legislation?
  • Is the product accessible to all?

Each of these have a process you need to go through, dependent on expert departments in the company, review cycles and bug reports that need fixing. So whilst your product may work already, this normally adds at least a few weeks to the release. Worse even, every change to the product restarts this cycle.

Frustrating, yes – but incredibly important

This can be incredibly annoying to encounter and seeing a product that is code complete move from sprint to sprint because of unavailability of reviewers or bugs that are an issue but can’t be fixed is frustrating. I had to deal with a lot of accessibility issues that only appeared in third party software, for example Voiceover on Mac or Orca on Linux systems. And whilst my team did everything right, our products didn’t work with those. Filing reports didn’t make much of a difference, so often we had to make functionality of a product opt-in with it being turned off by default to work around these problems.

This was frustrating for all involved, as some of this functionality was a differentiator that could have resulted in lots of new users. But as it became an opt-in, this is already a surefire way to not get many users of this feature.

But the fact of the matter remains that everything we do as software developers has a direct impact on end users out there. It might be a shortcut for us to not cover all edge cases, but it may mean that our product can leak information of our users which can lead to their identities being stolen.

We could block users as we didn’t think that any person who can’t use a mouse would ever use our product. I spent quite some time making a colour picker tool available to screen readers. This feels not necessary, but the point is that not every screenreader user is unable to see at all. By making it easier to use and adding more labels, the tool became more convenient for all users.

In the end, what counts is the end user experience. And whilst iterating fast and trying out a lot of cool new ways to interact with information is exciting, it may mean that we lock out a lot of potential users who can’t change their setup, or – worse – what their bodies can do. And whilst some of the legal requirements like GDPR feel like overkill, they may be a good way for us to reflect on how much information we need from our users and what we do with it.

How can we move faster?

The great thing about compliance is that it is predictable. We will have to do it in large corporations and certain areas of publication. So we might as well plan for it as soon as we can – even in the design and planning phase of the project. The biggest non-news about accessibility, for example, is that the earlier to take care of it, the fewer work you have to do. Making an already existing product accessible is playing whack-a-mole with assistive technology support, cross-platform issues and framework support. Planning it to be as accessible as needed from the get-go, or using already tested, accessible components means compliance can be a matter of hours, not weeks.

The same goes for data we record and want to retain. It is not often that we come up with something brand new – often we just add a feature to an existing product. So the question is if it really is necessary to add telemetry to every interface element, or maybe dig into what we already get from the parent product.

I’ll dig more into this in another post, as there are ways to cater to compliance needs and still move fast. But for now, it is important to remember that developers in large corporations aren’t slower or less switched on than those in the wild. They just have to care about a lot more than just writing the code. And that – to me – is a good thing, as what we write can make or break the online experience of our users.

Photo by Glenn Carstens-Peters on Unsplash

Currently we are in a huge round of tech layoffs that are reminiscent of the first .com crash in the beginning of the century. Meta, Amazon, Microsoft and now Google announced layoffs in the 10k range and it seems no one is spared. New people as well as people who have been at companies for over 20 years all got the meeting we all dread.

I also got laid off and I am currently still in negotiations about the details, so there will be a different post on that. This isn’t my first rodeo, and I am in a lead position which is why I get a lot of requests from annoyed and desperate colleagues asking for advice. So here are some things I tell myself right now and others that may be of help if you’re affected or you know someone who is.

Leaving people in the unknown is the worst

Layoffs get a lot worse when there is inconsistency and unknowns. Giving a lot of people the sack with a generous severance offer and some safety packages like CV help is bad, but there is still a resemblance of care for the person rather than the employee number. Announcing that you lay off a certain number of people and then telling your staff that the announcements will happen over the next few weeks and months is just cruel. Sure, there are some legal requirements in certain countries that don’t allow for full disclosure until a contract is signed, but any company thinking that keeping people in the unknown – at any company decision – is a good way to get more out of them or save money is deluded. I once heard the term “mushroom management” – keep your employees in the dark and from time to time cover them in shit. Don’t be that company. If you are in this situation, I am sorry, but stay strong and do your job like you would have. Most likely you have fewer colleagues to work with now, so there is a big chance that there is a lot to do. If you already know that you are laid off, tell people who rely on you for information and sign-off that you are. Leaving any unknown, even the small ones, known is a good thing.

Don’t leave in anger

Layoffs suck. There is no winner. The people involved, of course, are the biggest losers, but it is also a massive toll on managers and HR folk that have to be the messenger. These layoffs right now are not about performance, how you networked in the company or what you work on. They are a knee-jerk reaction to a perceived recession and a band-aid to make stocks go up again. When your profitability per head is low, heads must roll.

Keeping that in mind, it is important to remember that the tech market, albeit being important and very rich, is also small. So don’t let your anger out on your colleagues. Don’t shoot the messengers and don’t go out in public and vent about your company in the spur of the moment and with inappropriate language and accusations. You will cross paths with many people you worked with again. There is also a big chance that your next company will work with your old one. And being a person that still has a foot in the door instead of having slammed it in many faces is something that can be a benefit to you then.

Leave a clean desk

If possible, leave a clean desk. Delete all meetings you own on the company calendar as they may show up as indelible ghosts for months afterwards. Document what you have done, where to find information and offer to do handover meetings with colleagues who are still around. I say “if possible” because in many, especially US environments that isn’t even a thing. If you’re laid off, you’re gone. A day later. This is borderline sabotage to your own company. People accumulate knowledge, documents, access to systems and many more things you don’t want to lose immediately. Not having access to a dashboard or a compliance form that needs to be filled out every quarter is going to be a lot of work for your team – a team that already lost people who are not getting replaced any time soon.

Brush up your CV and networking profiles

In order to get a new job, you will need a good CV. Go and write one and ask people you trust to review it. Also clean up your networking profiles like LinkedIn and ask for recommendations and reviews from people you worked with. This is quite a time to get a lot of “advice” on job portals on this topic and there are a lot of “CV expert companies” offering you their services. It is important to remember though that companies are flooded with offers from people and that HR folks have only a short amount of time to look at any CV. So the things that worked for me are:

• Have a PDF/Word document CV - nobody wants to go to a web site and look at 8 minutes of parallax effects and videos.
• List all your contact details and where you legally can work as the first thing.
• List what you are looking for.
• Have different CVs, catered to what’s important for the role in question.
• Prepare for having to copy and paste all the things into some company internal hiring portal.

Take as much as you can with you

If you live in a country with good work laws, then there is a period of a few weeks where you are on administrative leave. Take this time to look at perks your company offers and use them. In my case, I am going to look at a lot of courses and certifications we offer to third parties but I have never taken. You might also have access to cheaper hardware or software licences that are a bargain to take with you. And of course contact people in the company telling them that you are off and what you liked about working with them. This doesn’t only give them a fuzzy feeling but it is also a good thing for you to remember the good bits in a time of anger and confusion.

Don’t use company resources for personal things

Your work laptop, your access to company software packages and resources are handy to have but they are not yours any more. You will also soon have no access to them any longer. So get your own devices and use these to write your CVs and contact people from personal accounts. If things get messy with your employer beyond a clean severance, any use of company resources could be a problem for you.

Don’t allow yourself to get badgered

With all due respect and apologies to the poor HR people who have to deal with this, but there is one thing that’s incredibly important. Leaving a company in a round of layoffs like these is as much a negotiation as joining a company is. So don’t sign the first offer without getting enough time to look at it and check what it means. A big bunch of money does sound good but it also can get eaten up by taxes. If you have a union representative in the company, contact them and demand them to be in every meeting. If you can afford a specialist lawyer, send the papers to them and let them do the negotiations for you. Hopefully your company knows your worth and offers you what you are due, but I’ve encountered quite a few times that the first offer that “you have to sign in two days” is much lower than you should go for.

Another thing that drives me nuts is advice you get on social media from people who “love the hustle” and see every layoff as an opportunity to “do your own thing”. You have a right to grieve and reflect now. Don’t let yourself get stressed out by amazing things that could be if you act immediately. You’ve just been punched, it is OK to recover first before picking the next argument.

Don’t take it personally – it wasn’t you

This is easy to say and of course you feel like shit when you get laid off. It is also tempting to see the fault in you and get desperate about your future. This time, it is not. If you were laid off because of your performance any time in between these huge attempts to fix capitalism it might be a different thing. But even then it may have been that you have just had the wrong job or tried to tell you that you can do it because of a good paycheck although it just wasn’t your cup of tea. It is OK to grieve though. It is OK to reflect and look at places where you can improve. But it is not necessary to beat yourself up. Talk to people, go out, do nothing and especially nothing with computers and phones. Vent in ways that are good for you and don’t inconvenience others. Angry music with headphones works for me.

Be there for others

If you worked in a place resembling some human society, you will have colleagues that reach out to you and tell you how sorry they are. Take these moments and thank them. Also reach out to people who have been laid off and just offer to be available for a chat. These are annoying, frustrating and bad times, and there is period of flooded job markets and even more layoffs coming.

I am pretty swamped, but if you feel like a quick chat, you can send me an email or reach out on LinkedIn.

The web has replaced and outlived a lot of closed technologies because of its resilience. Its underlying technologies are simple and sturdy and one of its main design principles is to – no matter what happens – never punish the user for developer mistakes.

User needs come before the needs of web page authors, which come before the needs of user agent implementers, which come before the needs of specification writers, which come before theoretical purity.

This is why web technologies are forgiving. Enter some wrong HTML, and the browser will try to make sense of it and automatically close elements for you. Enter some invalid CSS, and the line of code gets skipped.

Endangered species: the indie web publisher

This is excellent for end users, but it always felt wrong to me when it comes to building things for the web. Sure, the web should be a read/write medium and anyone consuming it should also have only a small step to take to become a publisher on it.

But let’s be honest: most publishing on the web doesn’t happen by writing HTML and CSS, but inside other systems. You can still run your own server, set up your own blog and all that, but the majority of people who put content on the web don’t ever touch any code or own any of the infrastructure their content is published on. Whether that’s a good thing or not is irrelevant – we lost that battle. And whilst we are always smug when the likes of Twitter or other platforms get into trouble, it still means a lot of people adding to the web will go somewhere else. To another product, and not start writing HTML or hosting their own blog.

It works, why care?

My problem with a forgiving platform is that it makes it a lot harder to advocate for quality. Why should a developer care about clean HTML and optimised CSS when the browser fixes your mistakes? Even worse, why should HTML and CSS ever be respected by people who call themselves “real developers” when almost any code soup results in something consumable? There are hardly any ramifications for coding mistakes, which means that over the years we focused on developer convenience rather than the quality of the end result.

This happens in language design and implementation, too. JavaScript adds semicolons automatically to your code when you forget to add one at the end of an instruction. PHP, often the butt of jokes when it comes to consistency and code quality does not and flat out refuses to compile. I never understood why I wouldn’t add a semicolon, after all I also end sentences with a full stop. But people are loud and proud about not adding them and relying on the engine to do it for them. When ECMAScript got its standard discussions many “10x developers” were incredibly outspoken about not using semicolons as a sign of change and trusting the runtime to do these things real programmers shouldn’t worry about.

Another thing that irks me is that IDs in HTML automatically become global JavaScript variables. Developers relied on that convenience for quite a while instead of getting a reference to the element they want to interact with. This convenience also represents an attack vector to allow for DOM clobbering and it is not alone in that. The web is ripe for attacks because of its lenience in what developers can throw at it.

HTML and CSS are compilation targets

The main difference to the web development world of the past and the web of now is that most development happens with abstraction layers in between. HTML and CSS isn’t written by hand, but it is generated. JavaScript isn’t in some files, it is in modules and we use package systems to create bundles. What ends up in the final product isn’t the source code any longer. There are many steps in between. This adds another complexity as it gives developers the false impression that the optimised source code also results in great final products. In reality abstractions often result in generic, bloated code. Code that doesn’t look terrible to us, as it does show something useful and our fast connections and great computers show us a smooth experience.

It feels like we never embraced the alien that is the web to our software world. In almost any other environment you write code, and you compile optimised code to a certain environment. On the web, compilation wasn’t needed, but we ended up in a place where we do it. And we compile to the unknown, which in itself doesn’t work.

Compiling into the unknown

Let’s remember that no matter what we build our products with, what will end up on your end user’s computers is HTML, CSS and JavaScript. Or tons of JavaScript executing whatever code you want in Webassembly. The end user’s device, connection speed and the way they interact with your product are utterly unknown to you. That’s why our goal should be to create clean, lean and excellent web code that is resilient to any and all problems that could happen on the end device. Going back to the main design principle of the web where the user should get the best result and be our main focus. And not how easy it is to build a huge system in 20 minutes with x lines of code. Just because the resilience of the web means our code does not break doesn’t mean it works.

Tooling tells us what’s wrong – but who listens?

I work in developer tools of the browser which are excellent compared to what I had to work with when I started. I find myself often at a loss though what I could still give developers to make it even more obvious that what they are doing hurts end users. Open any web product and take a look at the issues tool in developer tools and you are greeted by a deluge of problems that can be a barrier for end users and – even more annoying – are easy to avoid.

You even see squiggly underlines in the DOM tree when something is wrong – much like Word shows when you are making writing mistakes.

If you use certain extensions in editors, you even get that live while you are writing your code with explanations why what you do is a problem and how to fix it.

And yet, what’s on the web is to a large degree terrible. Which brings me to the main question I am pondering: is the web development stack and environment too lenient? Should developers have a harder time making obvious mistakes instead of getting away with them? I remember when XHTML was an idea and a single wrong character encoding would have meant our end users can’t access a web site. That was a clear violation of the main guiding design principle of the web. But in a world where we do convert source code to web code anyways, shouldn’t our bundlers, frameworks and build scripts be more strict and disallow obvious issues to get through and become something the browser has to deal with? We do write tests for our code, shouldn’t a system that checks your final product for obvious issues also be part of our delivery pipe?

Should bad code be something we always expect?

Being lenient with developer error is incredibly ingrained in our work. Currently I am working on a JSON display in the browser. JSON was a much more lightweight and straight forward replacement for XML and it is in essence writing JavaScript objects. And yet, looking around for demo APIs to throw at our JSON viewer, I found an amazing amount of broken JSON. My team, seeing developers as our end users, kept looking for ways to automatically fix broken JSON to at least display something instead of just an error. We’ve been conditioned to expect broken code and invalid data and try to work with it. That does not sound like a good idea to me. Maybe it is time to take a stand and build systems that tell developers flat out when they are making mistakes that don’t have to be on the web.

I just wrote myself a small tool to get all the thumbnail images available for a YouTube video.

Say you have a Youtube URL, the ID is the last part: https://www.youtube.com/watch?v=GDukVqBDd3Q, in this case “GDukVqBDd3Q”. Just copy this into the tool and you will get all the images available. You can choose to get JPG or WebP images and you can click each to see it or right-click to save it.

If you feel like doing this by hand, here are the different URLs:

• Player Background Thumbnail (480×360):
  • https://i.ytimg.com/vi_webp/VIDEO_ID/0.webp
  • https://i.ytimg.com/vi/VIDEO_ID/0.jpg
• Video frames thumbnails (120×90)
  • Start: https//i.ytimg.com/vi_webp/VIDEO_ID/1.webp
  • Middle: https://i.ytimg.com/vi_webp/VIDEO_ID/2.webp
  • End: https//i.ytimg.com/vi_webp/VIDEO_ID/3.webp
  • Start: https//i.ytimg.com/vi/VIDEO_ID/1.jpg
  • Middle: https://i.ytimg.com/vi/VIDEO_ID/2.jpg
  • End: https//i.ytimg.com/vi/VIDEO_ID/3.jpg
• Lowest quality thumbnail (120×90)
  • https://i.ytimg.com/vi_webp/VIDEO_ID/default.webp
  • https://i.ytimg.com/vi/VIDEO_ID/default.jpg
• Medium quality thumbnail (320×180)
  • https://i.ytimg.com/vi_webp/VIDEO_ID/mqdefault.webp
  • https://i.ytimg.com/vi/VIDEO_ID/mqdefault.jpg
• High quality thumbnail (480×360)
  • https://i.ytimg.com/vi_webp/VIDEO_ID/hqdefault.webp
  • https://i.ytimg.com/vi/VIDEO_ID/hqdefault.jpg
• Standard quality thumbnail (640×480)
  • https://i.ytimg.com/vi_webp/VIDEO_ID/sddefault.webp
  • https//i.ytimg.com/vi/VIDEO_ID/sddefault.jpg
• Unscaled thumbnail resolution
  • https://i.ytimg.com/vi_webp/VIDEO_ID/maxresdefault.webp
  • https://i.ytimg.com/vi/VIDEO_ID/maxresdefault.jpg