Background: I’ve been asked in a few applications for new roles to do written interviews. I thought it might be worth while to release some of my answers as posts as it was fun to reflect a bit on these things.

I’ve been a big supporter of open source from the get-go and worked at Mozilla for five years before moving on to Microsoft and spearhead the opening of new projects to the outside there. When I took on the role of Principal TPM of the Chromium Developer Tools in Edge, I established the repository and pushed to have all the documentation on GitHub with outside contribution.

One repo I started and maintained until recently is the Edge Developer Extension for VS Code and the Developer Tools themselves using GitHub for collaboration in the open.

The reason I pushed for open sourcing everything my team does were several:

• It keeps us honest, as you work in the open and can’t hide any shortcuts or “good enough” code.
• The contribution of everybody is visible. Large corporations often have the problem that you work for years on excellent products, but the outside world doesn’t know about it. You can’t prove your work when you apply elsewhere. With open source, this isn’t a problem. Even interns have their names associated with a highly visible product and get the kudos they deserve.
• User research is a lot easier – as people have access to your product, you can conduct quick surveys and offer previews in own branches.
• Community building is simpler, too. When people have access to the product rather than to slide decks, stickers and T-Shirts, there is a higher chance to get outside contribution.
• Hiring new people is easier. When people already work with and contribute to your product, they can hit the ground running when you hire them. And you already see not only how good they are as a developer, but also how they interact with other people. How well they comment, how readable and understandable their pull requests are and similar soft skills hint at how they could work as part of a larger team.

The CSS aspect-ratio property is pretty amazing. You can define a ratio of width to height and it will resize the element accordingly.

You can try it out in this pen :

See the Pen
CSS aspect ratio is awesome! by Christian Heilmann (@codepo8)
on CodePen.

Where this shines is videos, image content and embeds. No more hacks with relative positioning and percentages. Browser support is green all over, so, like me, it makes sense to upgrade your CSS habits.

Background: I’ve been asked in a few applications for new roles to do written interviews. I thought it might be worth while to release some of my answers as posts as it was fun to reflect a bit on these things.

One question was what practices I think help software teams build better quality products. And this is what I wrote:

There are a few things that helped a lot making my current team deliver quality products. The first parts are processes and technical setup.

• A development environment that involves linting, error and issue reporting while you develop using static code analysis in the editor. Any bug that isn’t written means less work for the QA department and less waiting for results.
• A version control system workflow that involves checks like tests, documentation, peer review, and automated security and data analysis.
• A code standard that is automatically applied on commit to the version control system. People can write any way they want to, but code coming from the repository needs to be in a predictable format.
• End-to-end tests. Code without any tests will not be allowed in the repository.

The other part is the team/human factors that ensure that we all follow best practices and learn from another.

• Peer reviews / team reviews of code with detection of best practices. Once these practices are discovered, they should be documented in and shared amongst the team.
• Presentations to the group of new and exciting tools and processes. I mentored and coached my team on those which also helped them with their communication in their own reviews.
• Learning days that allow developers to try something new or share information with others.
• Documentation days to catch up on missing write-ups.
• Bug bashes – we take a list of long-standing bugs and dedicate a day to fixing those instead of continuously working around them.
• Leaving ample time at the end of the daily stand-up for questions and answers when people are stuck.
• End of sprint reviews and sharing of learnings.
• Including engineers in design reviews and user testing. The former to ensure we can build what the UX team dreams of and the latter to give engineers a feeling of who we work for and that what is obvious to a technical person may not be understandable to others at all.

Another concept I’ve seen work extremely well in two companies so far is a developer rotation. Products get cut up into “work pods” and developers get assigned as needed to the pod depending on how soon that product needs to be finished or new features released. Engineers get assigned to pods on a rotation basis, which means that everybody in the team knows about the different work going on.

This means:

• People can get sick or take time off without the product being stalled.
• If people leave the company, they don’t take all their knowledge with them.
• Documentation and handover are a must as you are not the only person working on the product.
• Engineers learn from each other how their counterpart worked on the last iteration of the product.

Photo by Annie Spratt on Unsplash

Twitter has a list of interests you can define that affects what content you see on your home timeline. This is a list of 150 topics, most not chosen by you but considered something you should see. You can change these settings by going to:

More -> Settings and Privacy -> Privacy and Safety -> Content you see -> Interests

This is a UX nightmare and unchecking 150 boxes isn’t fun, so you can also toggle all 150 in bulk by opening developer tools, going to the Console and running this command:

$$('input[type=checkbox]').forEach(c=>{c.click()})

You can see it in action in the following screencast:

It may give you a “Twitter is over capacity” message, but that’s just temporary.

Here’s a quick video of me showing you the benefits of GitHub Copilot for docs:

AI powered chat interfaces are a great and fun way to learn about new technologies. The problem is quality and relevance. Chat GPT for example doesn’t tell you the source of the information. Bing chat does at times pull from sources that are highly successful, but not necessarily the best. Another thing is that it is sorely missing is a copy button for code results.

This is not a new problem. For years I’ve prepended any Google search with “MDN” to only get results from official documentation, written by expert writers.

GitHub Copilot for docs is the best of both worlds. It gives you an interface like ChatGPT to look up information of the official documentations of libraries, products and resources.

Right now, it covers GitHub, React, MDN, Azure, TypeScript and Webpack.

Once you picked a source, you can add filters to change your level of expertise and how well you already know the subject. You can choose to only get the answer to your question or more detail about the subject in general.

You can then ask your question, like “how do I use the fetch API” and get a result that has information and code examples. You can keep chatting with the system to dig deeper or you can copy the code examples to your clipboard.

Another thing that makes this tool great is that it gives you the source of the information. You can hover over any part of the text to find out where in the documentation you can learn more on this specific topic.

I’ve been using this tool for a few days now and I’m impressed. It’s a great way to learn about technologies straight from the source without of having to learn the hard way what result sounds good but is actually bad advice.

It puts the “fun” into RTFM.