Swe

This article summarises personal reflections and discussions with friends on how the advent of AI-generated coding has changed our work and which skills will become important. The craft of writing code is often compared to art. From the famous book “The Art of Computer Programming” by Donald Knuth to the hacker-identity-building folklore equating good code with poetry. For the latter, we can easily see the parallels, which include conciseness, structure, and coherence. So far, thinking about this has been a fun intellectual exercise. Now, I believe it will become a more essential aspect of our craft. ...

This article discusses approaches for making supply chains verifiable and secure. The primary audience are developers working on build pipelines and dev ops engineers. It is cross-posted from the Light Squares blog. Modern supply chain security needs scalable verifiability Modern software supply chains are complex. Dependency trees of modern software often contain thousands of packages across multiple ecosystems. This makes it challenging for any developer team to fully understand exactly what code is going into their build. ...

This article argues for the value of example code for software projects. The primary audience are software engineers working on libraries and open-source code. Executable example code is probably the most valuable artifact one can add to projects ranging from single-purpose libraries to larger frameworks. This applies from the API design phase of a library to maintaining them in the long term. The repositories of the Android libraries that I maintain(ed) typically include dedicated sample apps. For example, the sample app for the Sloth library or the sample app for the Spectrum library. ...

This article describes a technique that helps to become productive in a large code base quickly. When mentoring other engineers, I found this to be a very effective and teachable approach. The primary audience are software engineers and engineering managers. When I joined larger organisations, the on-boarding usually involved some sort of starter task: add a new metric to the dashboard, allow people to add a website URL to their profile, … . They are a great idea, but often new engineers struggle to make progress – paralysed by the complexity of the code base. Most are start working on a small subset (e.g. do front-end changes first) before understanding the big picture. This not only applies to junior engineers, the same is true for software veterans switching to a new company and auditors parachuting into a short-term project. ...

This article explains an often-overlooked effect that can distort metrics during feature roll-out. The primary audience are software engineers and managers working on infrastructure and libraries. I want to motivate this problem with a fictive scenario: Alex wrote a replacement for an old and inefficient component in their app. It took the team a few weeks to implement and they carefully measured on test devices that it improves all core metrics. It is faster, uses less memory, all the good stuff. Following procedure, Alex’s new code is bundled with the next release and they open it to 1% for an A/B test. ...

This article explains advanced A/B test concepts. The primary audience are engineers encountering such A/B tests for the first time. A/B tests allow engineers to validate fixes, test for regressions, and measure improvements. In most situations the standard approach is to create a control and a test group of equal size (e.g. both 5%). Users within the test population (e.g. 10%) are then randomly assigned to one of these. However, sometimes more intricate methods can improve the user experience and make deployment safer and more effective. ...

This article discusses how long-term survival rate of internal software projects can be improved. The primary audience are senior software engineers and engineering managers working in medium to large organizations. When searching for “maintainable software”, many articles ([1], [2], [3]) focus on good coding practices. And certainly, good naming conventions, readable code, continuous integration, unit testing, … are all very important. However, I feel that many discussions implicitly assume a caring person who is motivated and capable to take care of the required maintenance indefinitely. I found that this is often not the case. In a larger organization with considerable churn and regular changes in direction, it quickly happens that projects, which were once a great success, quickly fall between the cracks. ...