Quantified Self: From Data to Actionable Dashboards • Felix Krause & Johan Abildskov

This interview was recorded for GOTO Unscripted at GOTO Copenhagen.
gotopia.tech

Read the full transcription of this interview here

Felix Krause - Creator of Fastlane & howisfelix.today & Security & Privacy Researcher
Johan Abildskov - Software Engineer at Uber & Author of "Practical Git"

DESCRIPTION
Software engineers are builders and problem solvers by definition. They leverage data and automation not only to solve work-related problems but also to make their life and the life of people around them simpler. Two software engineers that are passionate about what they do, Johan Abildskov and Felix Krause, examine the use and importance of transforming data pushes into data pulls and why dashboards and automation play a central place in the life of a software developer.

RECOMMENDED BOOKS
Johan Abildskov • Practical Git
Walter Isaacson • Steve Jobs
Liz Rice • Container Security
John Arundel & Justin Domingus • Cloud Native DevOps with Kubernetes
Pini Reznik, Jamie Dobson & Michelle Gienow • Cloud Native Transformation

Twitter
Instagram
LinkedIn
Facebook

Looking for a unique learning experience?
Attend the next GOTO conference near you! Get your ticket: gotopia.tech

SUBSCRIBE TO OUR YOUTUBE CHANNEL - new videos posted daily!

Transcript

Intro

Johan Abildskov: Hi, I'm Johan Abildskov, and I'm here at GOTO Copenhagen for "GOTO Unscripted." I'm a software engineer at Uber. And I'm here today with Felix Krause, and I'm looking forward to having a great conversation with you. So, could you say a few words about yourself?

Felix Krause: Looking forward also. I'm Felix Krause. I'm also a software engineer, recently been doing some privacy security work, and also some quantified self-work. So, I'm all over the place. I don't have an official title at the moment. So, I'm still experimenting, changing it every week on LinkedIn, and seeing, what people liked the most. But yes, originally a software engineer, and that's what I truly like doing.

Quantified self

Johan Abildskov: Nice. You say quantified self. When we got invited to speak together, of course, I tried to figure out who is this Felix fella. And I stumbled on how is Felix today, which is who proposes a quantified self, where you publish tons of information about yourself. Could you tell us a bit about that project then?

Felix Krause: It all started super randomly. Initially, I faced a problem. I moved to America, and I visited back home in Austria quite often. And my friends in Austria would often text me, like, "Hey, Felix Krause, when are you back in town? Like, let's hang out." And I felt like I always sent my travel schedule via messenger. So, I figured, okay, like, let's just buy a domain and call it whereisfelix. today. So, not how is Felix? Back then it was whereisfelix. today. And all it did, was show my travel schedule. It was showing, like, oh, flying back to Austria in December or something. It was a joke. And I sent it to friends, and they laughed at it because it was so funny, ridiculous. It didn't make sense. And it kind of grew from there.

It was initially just my travel schedule. And then I was already tracking my mood. I show my mood on that website. Then I was measuring my weight. So, I added my weight there. And now, for those of you who haven't seen the website yet, so now it is how is Felix today? And it includes, I think it's like 45 graphs about my life, everything from the number of steps over time, or like, correlations between alcohol and headache, for example, who would have thought? The next day. These kinds of things, and I decided to do all of this through the public. So, that's kind of, like, my quantified self-project.

Measure for impact

Johan Abildskov: It's very fun to look in there. And you also have a few analyses. Of course, we love graphs. One thing that at least in many organizations I've been in, people love measuring stuff. If they can get a dashboard they already find that to be a win. And one of my pet peeves is you shouldn't measure or visualize stuff if you don't intend to act on it. Right? So, do you have...? Is there anything where you're just like, "This is a surprising finding, let me do something different that came out of this project or...?

Felix Krause: Not so many, to be honest. I have to admit, the problem is that life is so complex that even if you quantify and track everything, realistically, you just don't have enough data. So, the simplified statement here is that I was tracking my data for around three years with no interruptions. But even then you end up with around 1,000 days, then when you wanna look into correlations, you would have to exclude all the days where you were sick, for example, or you need to exclude the days where you're flying somewhere and have jet lag, right?

Those days are different than normal days. What ends up happening is that you end up having a very low number of days that are meaningful for finding correlations and trends. So, the only solution would be to have more years, but then also life insurance, so you don't have a lot of more years. Or the other solution would be to have more people join it, but then you end up with like, what is it called? Like, medical study or, like, I forget what it's called. Then it will also defeat the purpose, because then it's not about you, but about humans as a whole. That's a whole different project.

Johan Abildskov: So, we don't want to introduce AI?

Felix Krause: No. What was your experience here with the graphs at work as in building a dashboard, and then you didn't want to act on it, or you didn't act on it?

Johan Abildskov: No, I think... So, I've been a consultant in the DevOps sphere for quite some time being around in many different organizations. One of the strong things that we can do as engineers are we can build stuff and can generate data. We can actually, not just argue, we can try to show some things. And then when we show graphs to, let's just say, the stereotypical manager, they go like, "Ooh, this graph goes up or goes down." And we also need to make sure this metric and this metric, how many deploys we have, and how many bugs are there. Whatever we might come up with in the madness of our minds. There are so many different things that we can measure. And then we end up with graphs that are up on large screens in our open office, right, radiating, going up and going down, and no one ever looks at them. Right? So, that kind of defeats the purpose of measuring or, like, at least the purpose of visualizing.

Felix Krause: One thing is acting, right? But the other thing is also, is it meaningful to track it? Right? I would feel like something like maybe tracking the backlog could be something that first makes sense to track the number of open to-dos, right? But then when you think about large software projects, that’s unlimited, right? There are always unlimited to-dos. So, is it meaningful to track a burndown chart of the backlog? Maybe not? Right? Maybe you have to do it for, what is it? PCs or P1s. It makes sense to have a burndown chart. But yeah, it's probably the same, right? Like, one is the acting, one is the, it doesn't make sense to visualize it?

The power of data visualization

Johan Abildskov: So, I think they're very tightly connected because if it makes sense... So, we can have two different ways. And I think, especially in big tech companies, we do have a sense of alerting or things like that. But in many traditional companies, maybe we're more focused on actually the visualization, and the human capability to spot trends. Right? And if I'm visualizing something that we continuously monitor as humans, but I don't have any action that I expect to be taking based on whether this metric goes up or down, whatever it is, like, what is my action if the number of backlog items increases? Right? We can have a sense of that.

Does that mean we close more tickets, or do we hire more...move more people to the team? What is the set of actions that we can take? If this goes in the direction we don't want it to go in? And if we don't have that, then maybe it doesn't make sense to at least visualize, because I'm all for over-gathering information, right? Because we don't know when everything breaks, what are we going to need? Right? We don't know that upfront. We have all been there after something broke, we added more metrics, right? Because then next time it breaks, we have more insights.

But that doesn't mean that we need to promote those metrics to an alerting series or main dashboard visualization on our board. And I think that's when we become aware of the actions that we're having. That's when we concretely say: "When this metric does this, if nothing else, I want to be notified such that I can figure out why did it go like this?" And I think we have an over tendency to just put nice graphs up because then the system feels live but it's just nice.

Felix Krause: I think with the graphs that look nice, they're also sometimes necessary, I think, for us as engineers. I feel like you may work on a project, and you know that this one step is, slow or inefficient, or whatever it is. And now you go to your manager, right, and you say "Hey, we should improve this." In large companies, especially you need some facts, graphs, or numbers to show that. And so, my experience, it was always, I remember one thing was at Apple when you upload a binary for the app store, they were doing some processing.

The beginning was like a half-a-minute thing that was fine, wait half a minute, and then the binary is ready. Over time, they added more and more checks. They added more and more stuff that is happening, like bitcode, verification, and so on. And it ended up that depending on the time of the day, it took up to an hour, right? And that was not acceptable to many engineers. But Apple internally back then didn't care. They didn't know the problem. They also don't use their system, right, because they don't build their apps through their app store. And so, one project that I worked on was very simple, which was, to raise awareness on the processing time of binaries. That was many, many years ago. It's all resolved now. But raising awareness, basically introducing a hashtag on Twitter was like iOS processing time or something.

And in Fastlane, while it was waiting so fast, there was the project that I worked on mobile developer tool. So, while it was waiting for the binary to show up, it was telling us like, "Hey, like, if you're interested, you can tweet this text." It was showing in the text, like, an estimated processing time of 60 minutes, and you could just copy and paste that, and tweet that. And people did that. People liked that. I think it helped engineers at Apple to go to their manager and say, like, "Hey, look, there's a hashtag about the system that we are operating." And people kind of make fun of that it's so slow. We should probably improve that. I don't know if you also had some experience there. But I think it's one of these powerful tools that you can use to get work done, yeah, with your team and with your manager.

Johan Abildskov: Yes. The dashboard can be let's call it a defensive dashboard. Like, as engineers, we get interrupted a lot on Slack... And you had the perfect example, right? People kept asking you, "When are we going to be home." So, you put up a dashboard, where your stakeholders could see…

Felix Krause: Sure. Yeah, it's a good way to put it.

Johan Abildskov: ...when your availability would be fitting, right?

Felix Krause: Yes.

Johan Abildskov: And it's the same thing. It's the service up. Well, go, look, don't ask me. And if you ask me, I will tell you to go look, because then I can use this communication, that I think we forget that every time someone comes asking us for some information, we are annoyed that we are being asked because we're being interrupted, we should think about how could I make that pool into a push?

Engineering around problems: automation

Felix Krause: Yes, exactly. I very much agree. There are people... I think a lot of engineers get annoyed easily about those things. You should always step back because there's always a problem in the process itself or, like, in the system itself. Like, I was doing a lot of support on GitHub for open source projects. You always get the same questions, right? If you always get the same questions, maybe you should update the error message to include more information. One thing we did with Fastlane was building a system where when it crashes, it will actually search on Stack Overflow through the API. And it worked. Sorry, I think it was like Stack Overflow and GitHub. It was doing both.

It worked well because people could just click on a link and see the discussion. And that worked better than somebody saying, like, "Before you submit an issue, please make sure to use the search in GitHub. Of course, people don't do that. And again, it's like I'm using... I'm doing the same. But if you show the error message in the right way, it helped a lot. I think the other way, this was one of the things I remember from the Steve Jobs, or the biography, biography back then, which was that there was this one engineer or designer, he was, like, tweaking the animations, I think of the home screen, or like, the layout or something.

And Steve Jobs was very particular, right, in how he wanted it. So, he was always nitpicking tiny, tiny things, right? And the engineer very soon was like, "Okay, we're always going back and forth. Steve Jobs always wants me to change those numbers." So he very quickly built a tool for Steve Jobs to have some sliders that he could play around with, right? And I remember he was, doing something, like, spending five minutes, changing all the sliders, tweaking animations, like, "This is how I want it." Like, this is pretty cool. So, I think it's a very good way for you to put it, it's like, instead of, instead of a push, it's like a pull, and you don't have to waste time. Yeah.

Johan Abildskov: That's a very genius way of doing it, and a very engineering approach, right? I have done this once, but now I have to do it twice. And that's annoying. So, I'll build a tool to do it instead. Right?

Felix Krause: Yes.

Johan Abildskov: And that's a very engineering-centric way of doing it. But one thing that we can also think about is that documentation is also a form of automation. Right? Because when you come to me to ask me to have something happen, of course, it's best if the system can just do it. But we're not there yet, then I have to do it. And that's annoying. But I could also just write down the document well, how to do it, and give you that, and then you might need a bit more help. And it might have been easier for me to do it, right? But I've scripted you.

I think because it's boring to write documentation, at least in the generally underappreciated, I'd say, and I think there's much value to be gained therefrom writing better documentation, from thinking a bit more about that. I think the phrasing of things, well, I'm using, not the public cloud, not Mechanical Turk, but I'm automating my stakeholders, right?

Felix Krause: Yes, that makes sense. And I think the topic of documentation, I have two things actually to add here. One is that I agree with the whole, writing documentation usually isn't shiny, but you can make it shiny very easily. One thing I like doing, I don't know where the term comes from, but it's the Readme Driven Development. So, the first thing I do on every repo is writing a Readme, at least a very rough version. So, I need, like, a name for the project. Usually, I change it later, because names are always terrible they come up with. But then you have the usage as one of the first things. So, one thing for this project I've worked on with Fastlane was how to create provisioning profiles. And the way Apple describe it was always from their respective, okay, we have this database, we have this data. So, this is how you should do it.

What I did was like, ''Okay, let's see what you as an iOS developer think.'' Like, ''Okay, you have an app, you wanna publish it, you have a code signing identity,'' so those are the things you wanna provide to the interface. You don't want anything else. And that was super helpful for me because it forces you to think about what is the actual flow, how would you arrive at this project, and how you use it?" And I think it was one of the success factors of this whole thing. So, Readme Driven Development. And the second thing that I liked doing, and I don't know how often it happens, was that I build a system to have tests for documentation.

What I did is, for example, with Fastlane, is fast inspect lowercase and italic in the docs, which is very specific. Usually, it's not lowercase product names, but it kind of stuck like this. We got pull requests, and Fastlane was always spelled uppercase. But as you mentioned, it's dumb for me now to spend my time adding a comment saying, like, please spell it lowercase. And sometimes people wouldn't update because they don't care, or don't have the title.

Then I need to take over the PR, but then maybe they didn't sign the agreement, like, very, very annoying. And I was the bad guy, right? I had to be the one who had to invest time. So, what I did is write tests. The tests did a few things. One was to check for some spelling that I specified or check for some potential deny words, like words you shouldn't be mentioning. Maybe, for example, everything around Apple, you might have to be careful in, like, how you phrase it. Like, for example, you cannot mention the beta software of Apple or something.

So, you had that. Then the other thing is all the code samples. It will see if it's a valid syntax. And so, for Fastlane, which is a Ruby file under the hood, it will actually... I have to think back now. I think it didn't run the Ruby configuration, because that would be dangerous running a third-party code on our CI, but it was parsing it and checking that the actual name wasn't misspelled, that the parameters are available, that the type matches, and so on. And so, the beauty was somebody submitted a pull request, they got feedback from a bot. I didn't have to do anything.

It wasn't marked on the screen until the tests are passing. Also from the perspective of the contributors, I got positive feedback, because they were much happier to update something from a bot than from a human. And my theory on that is that if it's a human, then you think, ''Oh, Felix is just being nitpicky? Like, he's annoying. He wants this, this, this.'' If it's a bot, then it's like, okay, these are the rules, the laws that were defined for this repo, right? There are laws, and they have to be followed by everybody, doesn't matter who. I'm not the bad guy anymore. That was a really fun project to work on.

Johan Abildskov: It's very cool. Also, there are so many things that... I think you're just hitting many interesting notions here. But to continue on the latest tangent, there's also something... It also translates into many different things like team dynamics. Like, if we on our team have agreed, some ways of working. We show up to meetings on time. Crazy, I know. We end our meetings on time, impossible, right? And if that's something that we can make explicit, such that I don't have to be the bad guy when I say, ''I'm sorry, the time's up," right?' Because there are eight people outside the room, trying to get in here. We've all been in that situation. But it just becomes awkward. And so, let's just make it explicit, like, you did with the tests. This is not discussable, or debatable. It's just the way we're doing stuff. We all agree that in this community, these are the guidelines, and they're written on the wall if you're in doubt, so I can just point and say, "We end the meeting on time." Then it's not on me, then it's on the shared policing.

Felix Krause: It is a rule that's written somewhere, but also you're not the person enforcing it necessarily, right? Because you have the system in place, be it CI, be it I don't know room booking system you use and stuff like that. Yes.

Johan Abildskov: And I think it's also very interesting the thing you say about doing Readme Driven Development. Making that a forcing function to think about what is the users' verbs? What are the actions that the user wants to take? Not what are the things that your system wants to do? But, like, doing that as an entry point, because it can be very hard because you have such a large mental model, you know exactly what you want your system to do, right? So, how can you trip yourself up, and cheat yourself into taking a step back and looking into that?

Building developer tools

Felix Krause: Yes, and it helps you build it, but it also helps you long-term because you have the documentation right there. It's super useful. I can highly recommend it. And it's fun. It really forces you to think like this. You already know what you have in mind, right? Then you build a new internal or external system. You already know the use case that you wanna build it for. You and I work with a lot of developer tools. That's the beauty of working on developer tools because the people who are gonna use our stuff are people who think very similarly to us, right? As soon as you build, like, a social media app for young people, let's just say, it's gonna be very different, right? You have to do all these interviews and conversations with potential users, and have to understand, ''Wait, so they don't use the camera app because we don't know. But people don't use the camera app, they use the Snapchat camera, stuff like that.'' For developers, I think it's easier if it is something you are working on. Yeah.

Johan Abildskov: Yes, so, I think one tricky thing about building things for people that have the same profile that you do is, especially for building tools that are empowering the users to do stuff, is that you probably even though you feel like you're in the same domain, you're actually not. Even though you might both be software engineers. You're working in different domains. And then as a developer, as a software engineer, building something for another software engineer, you probably assume much more expert knowledge on them in your domain, which can be very different even though you're both building software, and I think that's where things like Readme Driven Development, or making sure your dog food, your systems. But I think that a very real challenge in this sphere is making sure that you don't assume the skill level of the proficiency, or the users, or the users want to be experts in your system.

Felix Krause: Yes, they just wanna use it.

Johan Abildskov: They just want to use it, right?

Felix Krause: Yes, exactly.

Johan Abildskov: They don't care about your system. They care about their system.

Felix Krause: Yes, that's why the documentation Readme is easy to understand, having videos, gifts, as in showing the thing in action, good error messages... The good error message was the key of all to be honest. That was a game-changer. No, that makes sense.

Getting back in the “building flow” in large companies

Felix Krause: You mentioned you worked with a lot of... You also worked with many larger companies and stuff. And I think one thing we talked about was how can you as an engineer be better to, you know, go back to shipping if you feel stuck, because I think every engineer, at least when you work at a larger team, a large company, you feel like you go to this meeting, this meeting, you write this doc, but you don't get to build or ship anything anymore. Do you have some advice there? Or some experience?

Johan Abildskov: So at least one of my pet peeves is that, especially in large, traditional companies, things slow down, right? The concept of flow is non-existent, right? It's spending tons of time talking about doing rather than doing. And we need to make very sure that everything is okay, everything is correct. Politics is okay, we have the right checkmarks on our list. I think we could do a bit more civil disobedience. As engineers, we are the experts, we know what to do. I don't need to ask anyone for permission for writing a unit test, right? I don't need to ask anyone for permission for writing a small script that helps us. And I think we have somehow, as subject matter experts, as brilliant builders, shippers, automation toolsmiths, we can build our tools. We have somehow along the process, we have been taught, or we have taught ourselves, not to hand off too much responsibility for our core competencies. So, I think that we as software engineers, could ask a little bit less for permission and just do it.

Felix Krause: What about things, like, let's say you automate something, but then later, you realize someone else at the same company was automating the same thing?

Johan Abildskov: So, hopefully, we have both brought value to the local ecosystem, because large companies, like, with hundreds of thousands of engineers, there are bound to be tons of duplication. And I think that's okay. Because maybe we have learned the DRY principle, don't repeat yourself, right? That's a core, like, we need reuse. And we can overuse it. And, like, coupling by reuse, and using copy-paste as a decoupling mechanism, I think is underrated.

Felix Krause: Yes, I very much agree.

Johan Abildskov: I think I don't know if it's in the computer science programs or in the school of thought that has been previously, there's been so much about code reuse, that it's very instinctual to the average software engineer. Like, we want to reuse code because it's waste.

Felix Krause: Yes, I agree. I do think it's because we learn it in school, or university, where you learn it because it's technically the right thing, or the better thing to do, right? But I agree, like, depending on if you build, like, something smaller and be it automation or your little side project, most of the time, it's totally fine to do some copy and paste of sorts or don't, like, have all these classes, but you have one large file in the beginning. And that's perfectly fine.

Johan Abildskov: And if you create value, and it then becomes a problem that multiple sources create the same value, solve the problem then, right? We talked a bit about building stuff that doesn't scale. Because otherwise, I'm not building anything. I'm just sitting in meetings trying to coordinate with something completely unrelated to myself. How we will solve this tiny problem, right? And if we just both wrote the Bash script, and are happy, both our worlds are better, and we haven't wasted anything, we have improved things. And then it's, of course, I think the senior technical staff, whether that's staff engineers, Senior Software engineers, whatever, they should have that organizational awareness, what is going on? What are the things that we should elevate and promote to more central benefit?

Felix Krause: Yes, I think that's one thing, right, where people might fall into the trap you work at... You go to university, you learn that. You go to a big company, you again learn to follow the structure, the processes, right? And then you wanna build a side project or your own business, right? And then suddenly you feel kind of lost, because suddenly you're like, "Wait, I don't have that support network that's there. I spent all this time setting up this very complicated tooling, right? And reality, it would have been enough to have a single, like, PHP or Ruby file or something. And that will be perfectly fine," right? Because turns out your side project doesn't have 10,000 visitors every minute, right? You don't need the same scale that you need at your day job. It was kind of, like, two different worlds, right?

Johan Abildskov: Yes, and I think one of the things is that in the side projects, but it's also getting back into the habit of building and shipping stuff, right, whether it's just getting to Maine, and sharing your code with the team often or, hopefully, it's shipping to something, where the code and the systems come alive. Doing that often, like, reducing our batch sizes, either it's small, get feedback, it hurts, but it's important, I think we need to reclaim that shipping capability, even though we're in large organizations, or even though we're doing tons of stuff as an industry, as professional software engineers, I think it's so much more satisfying when we're able to ship all the time.

Felix Krause: And not only satisfying, but it's probably better for your product. You're here because you get early feedback, right? For one example you ship something very small, and you immediately get responses, right? Are people saying, that you get no responses, that's also feedback, right? Or you get questions, or there's some curiosity there, or you get literal stuff like, "Hey, this is amazing. Like, what's next? Like, what are you gonna do?" And I think that's so important. Like, also, with all the projects I've worked on, I try to follow this, like, building a public mentality.

So, depending on the project, and depending on the context, I release stuff, or be just screenshots or screen readers maybe as early as possible, like, even the how is Felix project we talked about in the beginning, in the beginning, it was, where is Felix? And it was just my travel schedule. Then it was the mood, then it was the weight, and now suddenly, it's everything. I think that's also one example where it just grew naturally. I never planned on building something this big, right, or this complex in the beginning. I mean, even now it's not complex, it's a static file, really, but, yes, keep it simple and get feedback early.

Outro

Johan Abildskov: Thank you for sharing this time with me. It's been an excellent conversation. Enjoy the conference.

Felix Krause: Thank you. Thank you.