Ironies of automation (Bainbridge, 1983) is a foundational paper on what has been learned from automating work, or adding automation to tools people use for work. Ironies of artificial intelligence (Endsley, 2023) adds new observations on how LLM-powered systems have both similar and also new kinds of issues and opportunities. I also explain my approach to designing LLM systems.
LLMs are helpful and should be used with intent. Use them as tools to enhance your abilities while deliberately maintaining the fundamental skills you need to perform when the automation fails.
Expert group for EU has published Ethics Guidelines for Trustworthy AI. The document specifies a list of requirements the systems should meet to be considered trustworthy. They also define a rough framework and an assessment list to offer guidance on practical implementation. The objective is to empower humans and offer them meaningful work instead of replacing them. Augmenting human abilities is an approach I'm happy to advocate for.
Increasing automation turns human operators from active participants into supervisors of the system. This creates serious problems in security-critical domains.
I have used Obsidian for two years now, and I'm ready to say it works for me. Most importantly, I have learned that my notes need to be in an open and clear text format from now on. Otherwise I'm unable to commit to using any tool (including paper and pen).
Remote work has different requirements and success factors than co-located work. Trying to mimic co-located work in a remote setting leads to inefficiencies and misses the potential benefits of working remotely. GitLab has published a Leading remote teams -course on Coursera and I went through it to get new ideas on how to improve my work, and they really do have some interesting ideas. Asynchronous workflows is one fundamental one.
PDF seems to be the best format to read books on iPad, and now I've started using it for reading web long reads as well. Being in control is the best part: You can decide how the website looks like, save it so it's yours to read and annotate however you like, and store it forever.
Author
Helsinki
Arttu
🇪🇺 🇫🇮 ❤️ 🏳️🌈
I'm a software development consultant from Helsinki. I write about software development, teams and AI.
I love it when people can work as an efficient cross-functional egalitarian team,
combining multiple perspectives and skillsets to solve complex, systemic problems.
I'm fascinated about how teams make sense of complexity, how tools can empower rather than constrain human
thought, and how we can build software that amplify the lives and work of humans.
I resolved a bug by politely requesting the LLM to refrain from returning literal "null" values as strings. I’m not sure how difficult it would be to explain this concept to myself from a decade ago.
Quite awesome C64 demo, I love the graphical style (and the story too):
It has been surprisingly common to see critique towards agile lately. I find it a bit odd, having seen the waterfall world and how much more humane agile has been. It can be easy to overlook how fundamental agile principles remain for surviving fast-paced, complex software projects.
My thoughts on agile, software development and consulting.
Estimating software work is difficult, as we usually are in a complex, not complicated domain, and we know what the solution will look like and how long it took to create, after it has been validated with the end users. Days, weeks, months -scale should be enough for estimation, and if you need more detailed than that, you should probably stop and think why, and how to change that.
Estimations made in the planning are forecasts and their reliability depends on both the experience and on the length of the time scale they cover. Using the word commitment can make planning more intimidating than it needs to be. The estimation itself is hard, and I don’t think I’ve ever seen it done too well, so it would be good to get all the stakeholders to understand that, and work towards better predictability together.
Situation awareness and distributed situation awareness are interesting concepts, but how does it map to the real world? How can we as designers take the concept and use it to guide our designs, to support rather than hinder the situation awareness of the end users?
Situation awareness has been an especially interesting focus area to me. I'm often building tools for professionals, and it's essential to keep users engaged and in the loop.
Situation awareness (SA) is a concept that describes how people stay entangled into events happening around them. SA model can be used to design systems so that they support users acquiring and maintaining situational awareness. Mica R. Endsley is one of the most cited researchers on SA, and has created a formal definition of SA.
An overview of the Distributed Situation Awareness model by Stanton et al. It looks at awareness as a property of the whole system, including both human and non-human agents.