Interview: Do the right thing with Nicolaj Græsholt, Eficode

Nicolaj (00:05):

Software is so much less about coding than it is about working with people. Because if you are just building software yourself, you have anything in your head, you have to be building a small library that's like how much can you possibly maintain. And if you're not building a small library, you're building a platform, you're building 1000s of microservices. You're collaborating with so many people and you need to spend some effort on communication and on understanding each other, so you are not building in different directions.

Lauri (00:54):

How are you today?

Nicolaj (00:55):

I am very good actually. Just came from a customer and I was just able to solve two problems really quick that one of the people at the customer had. So that was great.

Lauri (01:09):

That's a wonderful start.

Nicolaj (01:10):

Exactly. I was afraid of running late. But then it was just extremely simple.

Lauri (01:18):

Did you actually go there?

Nicolaj (01:20):

I didn't. We are all remote, so it's nice that I've been able to do it remote and I will probably continue to do it remote for quite a while. But it would also be interesting to actually meet them in person. We actually had a laptop shipped up here, so that I could get on their internal network and our salesperson in Aarhus, he was going to a sales meeting down there. So he went to get it and he was parked in the parking lot. And then a person from inside came with the laptop and put it in the back of his car. And then he drove away.

Lauri (02:01):

Hahah! Contactless.

Nicolaj (02:02):

Yeah. Exactly. Not not suspicious at all.

Lauri (02:08):

Yeah, that's how laptops are delivered nowadays.

Nicolaj (02:12):

Exactly, right?. Yeah, that was, yeah, funny.

Lauri (02:18):

Wow.

Nicolaj (02:19):

Funny stuff that happens sometimes.

Lauri (02:21):

Yeah. But first of all, thank you for taking your time to join and talk to us and talk to the interesting audience.

Nicolaj (02:29):

Thank you for having me.

Lauri (02:30):

You used the term do leader when we were working on this idea. The do leader, you borrowed that term from somebody, was it so?

Nicolaj (02:42):

I think I've definitely borrowed it from someone. But the idea just comes from all of this talk about being thought leaders and how you become someone that people look up to and how you have these thoughts. I think they come from doing stuff, like learning by doing or showing by example. And then I stumbled upon a talk by Scott Hanselman from 2012, "It's not what you read, it's what you ignore." Great talk about how to escape notification fatigue and all of these signals coming in from everywhere. And in the description of the talk, right above it, it actually said, "Let's stop thinking about how we can be thought leaders and start being do leaders." And I found out about that just very recently, but it's a talk from 2012. And I think it's cool that he was thinking about this nine years ago. And, apparently, we still have a lot of people who are just striving to become thought leaders, so we're apparently not done yet.

Lauri (04:02):

Yeah. It's not that long ago, I stumbled upon the history of the word thought leader. And if I'm not mistaken, it has been first used in literature in 1893. And interesting you said that the dual leader, yesterday, as I was browsing the LinkedIn, I came across Walt Disney's quote, whose quote is, "The way to get started is to quit talking and begin doing."

Nicolaj (04:40):

That is beautiful. That's beautiful. Great. Let's just run with that.

Lauri (04:47):

Exactly. So how about we start with the first one, the importance of (good) documentation? So good in parenthesis.

Nicolaj (04:58):

So good in parenthesis. So the idea is that anyone can sit down and write documentation in free form, and you can just be rambling and going along. But that is not necessarily helpful to anyone. Which is why I wrote the importance of good documentation. So step one is to get started and then improving on it. The way I like to start a project is with a good README. And if it's a software project, what are the prerequisites for running this project? How do you build the code? How do you run the code? How do you run the tests? And that means that anyone can just take the project and get started with it fairly quick. I don't know at the beginning, probably what all of the prerequisites will be or how you will be running it in advanced ways when it's integrating with other stuff. But, at any point in time, I know how to run the project in its current state, or build it or test it. And, yeah, so what have we done? Because this doesn't just relate to software development, it can relate to meetings as well, like the document, what we're working on, how we're working, the things we have done, where we intend to go.

Nicolaj (06:28):

So a to-do list is a good example of a documentation for where you intend to go. You can scribble notes about where we left off when you leave for the day. You can scribble why you are doing this in the first place, so you have the intention with you, if you should later question this. Write down decisions that you make, so that you know why you made the decision when you made the decision. So you know when to change the decision later, if your assumptions are suddenly changed. And the thing about documenting meetings, I don't think the meetings are for the people having the meeting, I think the meetings are for the company employing the people. Because the company picked up the people in order to do a piece of work, something should come from that. But by people just having meetings, they're not actively working on the project, so what are they actually creating? Well, they're creating knowledge. And if it's not persisted anywhere, then after the meeting, it's just dead knowledge, nothing has come from it or other than the things people are literally carrying in their hands with their limited memory outside of the rooms and holding on to for dear life, until they maybe get to implement it or immediately get disturbed and drop the ball.

Lauri (08:08):

I recently came across an expression that the essence of agile is not to do better planning, but it's to increase or improve the feedback cycle. I'm happy to hear what do you think about that statement? But, I think, assuming that is true and the follow-up question is, how do you build documentation that builds on itself? And the reason I'm asking that is we have recently tried to embrace blameless post-mortems, or blameless retrospective. So we asked ourselves three questions. One is, what went well, what went wrong, and how do we improve? And we use pretty rudimentary tools for that. We can use Google's Jamboard, or we use just Google Docs to have three slides. What is not so clear is how to build a feedback cycle between individual postmortem sessions and then between the documentations that comes out of it. So there's a discontinuity between taking the time to reflect and then putting in place those practices resulting from that reflection. But we use Confluence for documentation. So that's for sure. But how do you approach this sort of you need to do agile agile in the documentation?

Nicolaj (09:32): 

I really liked the thing you said about improving the feedback loop. So everyone's talking about a different model for working with software or they need to have a DevOps model. And, jokingly, I did a state diagram that just had a ball that said DevOps and then an arrow going out of the ball and into the ball against, because it's about making this feedback loop faster. And if people need a model for everything, then, "Please, here you go. Here's the model for how to do it." I was at a customer where we did a lot of retrospectives and I thing that worked really well is that during the retrospective, we looked at the last retrospective that we did. And we tried to see whether we had dropped any of the things that we were supposed to be working on, or why we didn't implement the actions? So sort of like a backlog, we kept revisiting which actions came out of the last retrospective, have we acted on them? And if we haven't acted on them, be brutal. And think about, is it something that should be acted on, or is it something that we are not going to do now?

Nicolaj (10:52):

Because our assumptions changed, or the world has changed. The world's changing all the time, it might not even be relevant anymore. So definitely keep revisiting what you do. People are sometimes afraid to make decisions because they're afraid of being wrong. I think you can come up with very few examples of decisions throughout history that hasn't ended up being wrong later. Make a decision, make it fast, make changes with it. And then when it becomes wrong, update your decision.

Lauri (11:30):

Yeah, really good one. And it's a very seamless transition to our next topic, which is making explicit decisions. Because documentation, blameless post-mortem, decisions building on them, of course, they are intertwined. And that's how it should be. Maybe I give you a floor first to make your case about making explicit decisions and then I start building on that. Because I've got something to say about that.

Nicolaj (11:58):

So my idea is just that I don't really want people to be walking around blind or walking around in the dark about which decisions have been made. "If we are adopting a new tool, when are we going to adopt it or what is the intention for adopting this tool? Or have we decided on the tool? Is it still up for discussion?" It can be very helpful for people in terms of direction, if you can lead them by making decisions, and if you can show them, "Hey, we've decided these things and that's the way things are now. If you have input, please let us have it and maybe some of the input, some of the decisions, we're not going to change them right now. But we would like your input," because like I said, no decision is probably correct forever. So when we make the choice of making the decision, when we have a good enough argument for changing. But until then, we are collecting the arguments, but running with the decision.

Lauri (13:18):

And if we follow the line of thinking from the previous discussion about documentation that, "Okay, don't improve planning, improve feedback cycle," then it would not only be make explicit decisions, but you would say, "Make a lot of decisions and make decisions fast."

Nicolaj (13:43):

Yes.

Lauri (13:43):

Because the faster you make the decision... This is somehow counterintuitive because I remember a conversation 10 years ago with my then boss who was running the team, and he said that, "Whoever gets to delay the decision the longest is the winner."

Nicolaj (14:00):

Yes.

Lauri (14:02):

But then again, you say, "Whoever gets to make the highest number of decisions building on the previous decisions is the winner."

Nicolaj (14:12):

So I guess it's sort of a... what is the term for it when you're just stalling each other? It's a war of attrition if you're just waiting for the other person to get increasingly tired with their arguments and, finally, they will succumb to your idea. I don't think that's a very good way of making decisions. But I like the idea of making a lot of decisions and making lots of small decisions. And considering who do we need to make this decision? Another story from back in the days, this is one of my colleagues, he just started at our company and he was creating a small piece of software, and he was wondering about a certain design decision. And for this, he brings a couple of colleagues into a meeting room and they start discussing this thing. And then a fourth colleague enters the room randomly at one point and asks, "I'm sorry, what are you discussing in here?" And they tell him the problem.

Nicolaj (15:22):

And the fourth colleague just says, "This is not a huge decision. It is impressively easy to change at a later point, should we choose to. Why do we have three consultants sitting around discussing this? Just do something, write what you've done. We'll change it if it doesn't work out." So also think about the size of your decisions.

Lauri (15:51):

I think Amazon uses the term one-way door and two-way door.

Nicolaj (15:55):

Yes.

Lauri (15:57):

So this is a kind of a decision you can reverse, and this is a kind of a decision you cannot reverse. That's a cool concept. You can always come and revisit your hypothesis. And I think the documentation and decisions going hand-in-hand is good. Because once you have documented the premises by which you have made the decision, then it's easier to go back and evaluate, "Okay, have the premises changed? And if I would still make the same decision if the premises were the same?"

Nicolaj (16:28):

Exactly.

Lauri (16:30):

There was one podcast about the decision-making. There was a wonderful framework for engaging people for the decision. And there were, basically, three questions. So, basically, the concept was disagree and commit.

Nicolaj (16:43):

Yes.

Lauri (16:44):

But there were three questions. One was, imagine that the two of us were to make a decision, and I was the one who is bringing the proposal on the table. So I would have three questions to you. One is, have I shared enough information with you so that you understand what I'm thinking about this and what I know about this matter? The second question is, do you feel that I have heard you? And the third question is, if I were to make the following decision, even though you would not make the same decision if you were me, would you be able to live with the outcome?

Nicolaj (17:25):

I think that's a great framework, it sounds very polite to work with and it sounds like something that could be a pleasant experience when you are having a meeting and you are to make a decision, actually asking people, "Is this a decision that you could live with?" I have another example of a framework. So this is from the book, The Five Temptations of a CEO. I think it's called by Patrick Lencioni.

Lauri (17:53):

Yep.

Nicolaj (17:53):

And one of them is the fear of making a decision, and the framework he proposes is to listen to people's opinions and then make a decision. So when you are there as a CEO, you are supposed to be the tiebreaker. We're not necessarily there to have the people make the decision. They're there to give you all of the best information. And, of course, you can put it to a vote, but the idea is that you're there as the tiebreaker. So if it comes out as a tie, make a decision. Because if people have been hear, they understand that, "Okay, we're not going to run with my idea right now. We're going to do something else, but we're going to do it together." And then at a later point, if it turns out it was a bad idea, we change it, we adapt and we evolve.

Lauri (18:58):

I once had a colleague who had worked at Intel and he referred to the Intel's Expression, which was, if remember that verbatim, "I think your idea is crazy, but I will help you make it."

Nicolaj (19:13):

Oh, that is excellent. I said that to a friend not long ago, actually, who was pitching your idea to me.

Lauri (19:20):

Oh, really?

Nicolaj (19:20):

And I told him, "That sounds absolutely insane. I'm in. And I can't see the end of this, but you've identified that I can help you some of the way. And that's true. So let's just get started with that and see where it goes."

Lauri (19:40):

Yeah, yeah. Super. So documentation decisions.

Nicolaj (19:45):

Yes.

Lauri (19:46):

The third topic you had in mind was quality or to be more specific, demanding quality.

Nicolaj (19:53):

Yes. So sometimes when I visit organizations, I see this fear of demanding quality from the software developers. And I think that's very unhealthy behavior, because the software developers are there as extremely intelligent people. They are not there as frightened kids, who are on the first day of work and they don't know how to do anything. You can actually set expectations and talk to them. And so while the word demand sounds a bit strong, it's just manage your expectations of quality with your software developers. Tell them, "Hey, I need you to document these things properly, because your colleagues are going to use them as well. I have noticed that on Jenkins, all of the jobs are red. Why are we not fixing that? It looks like the tool is on fire right now."

Nicolaj (21:14):

But the behavior I have seen when I come out is that, "I don't feel like I should be telling them how to do their thing," or, "It'll probably be difficult for them if they have to start documenting this in a new way or in a new tool, and I don't want to make it too complex for them." And what ends up happening is that you just have this extremely simplified, naive way of working, where none of the tools are being utilized, because that's hard and, yeah. But it's software developers, they're learning new stuff all the time. I'd be fairly surprised if they weren't able to start a new process with documenting or things like that.

Lauri (22:09):

Is it the same with software development and software developers than it is with... Well, I know product marketing, technical sales, pre-sales, sales development, that when you are there doing it yourself, you know in your heart when you are not doing the best you can?

Nicolaj (22:31):

That's an interesting question. I think not all the time. Because sometimes you can be carried away, when you're working on software. I do this all the time when I'm hacking on projects during the weekend, I know that I have a bunch of features that I want to implement, but then one of them starts to have all of these cool angles, and then I dive into that. And it's not until I maybe look at the result of that, that I see, "Hey, this is super cool, but also, I've actually violated a couple of principles that I wanted to have as other features. So I'm actually going to have to backtrack and change this. But it was cool at the time." So I think with software development, being a creative process, it's creative problem solving, otherwise, we would just have robots doing it. I don't think you always know when you're going in the wrong direction. But sometimes you have to know that what you're doing isn't the best work.

Lauri (23:45):

I think there's a difference between in getting the best possible outcome. Because that can be simply that you don't have enough information. You cannot get to the best possible outcome, because you haven't acquainted yourself with the details intimately enough to give you the best possible outcome. So you are limited by the fact that you just don't know everything or you just don't know enough. But I didn't mean that, that you are inferior in level of knowledge. What I mean that you are inferior in the level of ambition. And in marketing and sales, my experience is that if you somehow for reason or another you are you don't end up doing the best you can, you know that. When you look at the outcome, you know, "I could do better." And I remember some circumstances in my own career where I had been guided somebody. I was doing the job and they came to review that. And they simply said, "Not accepted." As simple as that, like "This not good enough." And that is demanding quality.

Lauri (25:10):

And there's a there's a great anecdote from McKinsey, where a junior consultant went to McKinsey and he was asked to write the business proposal. And then he wrote the business proposal and he brought it to the partner, and then the partner, basically, asked the person, "Is this the best you can do?" And then the junior was like, "No. I could improve here and I could improve there." "Okay, go back and revise." And then comes back two days later, and then leaves the next version on the inbox or whatever. And then comes back and ask again, "Is this the best you can do?" He's like, "No, but it's pretty much getting there." And it's get a bit aggravated on that feedback. And then the third time, sends a third version and goes back to the partner again, and the partner says, "Is the best you can do?" And he's like, "Yes, this is the best I can do. I really have put my A-game." "Okay, then I will read it."

Lauri (26:11):

And it tells a story of a culture. I don't think that's a culture that is built on faster feedback cycles and longer planning. So I think my question is, if you don't want to go to this kind of world and in this example, attributed to McKinsey, how do you build iteration in quantity, because you don't want the first version to be so far out in the future that it will not appear. Because the only, I think, one of the ways to improve quality is to improve the feedback cycle.

Nicolaj (26:48):

Right. So one way we improve feedback cycles is to actually talk about the stuff that we are working on, or the stuff that we are doing while we're doing it or when we're about to start it. So I know that some people do stand ups at work, 10 minutes in the morning, morning, you just say, "Today, I'm going to work at this. The intention is it's going to solve this problem. I am not impeded." Or maybe you are and you need help from someone. And then that should pop a red flag somewhere if someone else is working on the same thing, or if someone else is working on a different thing, but the things are in conflict, which you should, of course, then discuss after the standup. But the idea is just to be explicit about what we're working on and any direction that we're going in.

Nicolaj (27:46):

Then another way of having faster feedback is to actually work with people when you are doing software. Literally sit next to each other and create the software through pair programming. That is a very fast way of getting feedback from a colleague in terms of is the software maintainable? Then in terms of is the software doing the right thing? You would ship small features to your QA or your testers? If you have continuous delivery, then every small feature, if it passes the tests, then it will go to the end user. And you'll use some monitoring and logging to figure out, "Did I just break the entire platform? Or have I actually supplied something valuable? Are the users using the new features that I implemented? Can I start working on something else?"

Lauri (28:44):

So tell what you're working on, work together. You said, basically, deploy fast. And I think there is a correlation between the size of an increment and the deployment speed.

Nicolaj (29:07):

Yeah, I've been at customers where they were using Git us the version control system. They had branches that were just living forever. This is not a unique story. And they have just drifted so far from the main line. They were still useful, because the stuff that had been developed on them could be used for some incredibly specific tests of a piece of hardware, but it had drifted so far from the main line that they were in active development almost as a separate product that you needed to pull stuff from the main line onto. Even if it was just supposed to be a feature version of the main line, it had become almost its own product. So, yes, make small increments. I had a teacher once that said, so that was in terms of test-driven development, "Write small tests, run the tests, implement the code, see that it works, or make the changes, and then do the next small test." And he said, "If you are pole vaulting your problems, it looks amazing when it works. But there's also a great chance that you will fail. And if you just take the stairs, you're just doing it one step at a time. And you are going to get there, slow, but steady."

Lauri (30:36):

Yeah. Last April Fool's joke from us. Do you remember what that was?

Nicolaj (30:42):

Oh, yeah, it was the keyboard that would deploy on every key press. Yeah, that really had me. That was a good one. But you do have this as a testing exercise. It tests your code every set interval. It can be one minute or five minutes or things like that. If the tests are passing, it will commit the code and if the tests are failing, it will re-roll to the last working commit. And it forces you to write incredibly small changes. Because if you are hacking on something for five minutes, and it's still not working, then everything will be removed.

Lauri (31:36):

So demanding equality, we put that to bed. And we have three more to go. And the next one, it sounds so obvious that I'm curious and look forward what you have to say about that. Use versions.

Nicolaj (31:51):

Right. Yeah. Use version control. It's something that allows you to make experiments. I had a job working as a student, it was at an ad bureau. We made a website and when I entered the bureau, the website was alive in two places. It was alive on the internet as a website and then it was backed up on their single developer's laptop. So they had a running version, and they had a backup, which was great. But then when I entered, we were suddenly two developers that had to work on the thing. And in order to figure out who had done what, and to have a source of truth, we started using Git and use version control. It is so easy to get started with. It's very easy to get better at it. There is a tons of great resources online and it will just make your life so much better. Yeah, version your software, use semantic versioning. That's the standing job in software development with romantic versioning, where you tried to make the version number have some emotional value. So we won't go into version 1.0, before it's perfect. Or here, we will only bump a patch until every quarter where we increase the minor version.

Nicolaj (33:34):

So you don't version the software in terms of which features you've included, you just version it however you feel like to some of the made-up rules. And versions will help you deprecate things you don't want to maintain. It's okay to deprecate software. Do it thoughtfully. If you're non-stop deprecating your API, your software will probably be unusable to your end users. Do it thoughtfully. But it will allow you to deprecate things you don't want to maintain. I often go out to organizations, we talk about some of their platform, we talk about some of their integrations, or maybe they use, Jenkins is my great example. You can use a shared library, which means you can reduce a lot of the code in your pipelines, which is awesome. But it also means that now your code is suddenly alive in so many places. And if you make changes, they will impact a lot of people.

Nicolaj (34:41):

And then the shared library becomes this sacred thing that you're not really allowed to make changes to and you should be really careful with it, because we haven't versioned it and people are just depending on the latest version. And, again, circling back to demanding quality from your software developers, "We don't want to tell our developers that they have to use a specific version, because dependency management is difficult. And that will be a hassle for them. It will be annoying. And then they won't get all of the new features automatically," which they don't need, because they already had all the features in the library that they needed.

Lauri (35:27):

I remember back in time, before my times as a marketeer, that there was a lot of conversation about dynamic linking, aesthetic linking. But isn't it so nowadays that practically everything is statically linked?

Nicolaj (35:40):

Sure. Today, when we work with containers, we bundle everything as this nice package in an image. And then we shipped that off, and then we put versions on the image. So it's not even just the compiled code, it's the entire... I don't want to say runtime, the entire file system that will be the environment of our application. And we put a version on that. And that means we can run it now, we can run it in 10 years and we know, hopefully, exactly how it's going to be running.

Lauri (36:16):

Yeah, it's a long time ago, because it was... well, I'm revealing something about my history by going back and talking about static and dynamic linking. But let's leave that as a secret between the two of us. Two more to go.

Nicolaj (36:35):

Yeah

Lauri (36:36):

Make work, make pretty. This is the enigma. I want to hear this.

Nicolaj (36:41):

Yes. Make work. Make pretty. It's something I've been saying for years. I can't imagine I came up with this. And it's obviously a version of ways of working. But the idea is just you have a problem that you're trying to solve, figure out a solution. And when you have the solution, start improving on it. I was at a talk a couple of years ago by a woman from The Guardian, who was talking about how they develop software. And she said, "Don't let perfect be the enemy of good." So don't strive for perfect, don't spend too much time making stuff perfect. Just ship good stuff. And so that's the other version of it, make it work, then make it pretty. But I still have the make pretty part, because I think once you have the solution, you should revisit it and figure out, "What am I still missing here?" And then when you've looked it over and you've improved it in different ways, you should think, "Is something still missing? And then you should document what your solution was. So make something work and make it pretty.

Lauri (38:13):

Okay, now I get it. Because it was mystery for me when I read it first time. First make it work, then make it pretty.

Nicolaj (38:22):

Yeah. So when I, again, go out and help organizations, a lot of the time, it just feels like firefighting. And we have some issues, and we're supposed to fix them, and we're supposed to fix them fast. And then once they are done with these fixes, it's just duct tape everywhere and we have the machinery running again. People just put down the tools as if we're done. But we haven't made the underlying solution any better. We've just immediately made sure the solution isn't currently on fire and then we go on to other features or things like that. And then I try to stress that, "I don't think we're done here. I think someone made that in the first place and I think they made it with the best intention, and it's been working so far. But I've also identified a number of places where we could make this thing better, and then avoid having to firefight it in a week or a month."

Lauri (39:35):

Yeah. Going back to my ops times when I was building a lot of... well, it would be called automation, nowadays. They're, basically, building scripts for developer purposes. And there was a clear transition between making something work and making something pretty. And it was when you moved something from a buffer to a file. I enjoy when you get to the state that you forget the passing of time. And it's just you don't care what those tools are, you are just so immersed in trying to solve that problem. And when it works then you breathe out and breathe in again, and then you start making it pretty using your own terms.

Nicolaj (40:23):

Exactly and you have the experimentation process and the phase in the beginning where you might have no idea how to solve this. You're just hacking along in the buffer and trying to build something that works, and then when it works, you backtrack and you format it nicely, so that your colleagues can use it as well. And you write the documentation for "How do I run this?" "Are there any assumptions about the system?" "Do I need to export a token before the CLI connects to somewhere?" If you started out documenting every step of your experimentation, you would be doing science, which is also valuable, but you need to think about the purpose. Are you currently documenting the process of software development by example, or are you actually solving a real problem and then documenting the solution of the problem?

Lauri (41:27):

Yeah, yeah. Make it work. Make it pretty.

Nicolaj (41:32):

Yes.

Lauri (41:33):

That's cool. Yeah. Last one. Investing in people and their skills.

Nicolaj (41:39):

Yes.

Lauri (41:39):

And this was the part where in my introduction I said, "I'm not sure if that can be only about our digital sales, or should we also talk about our non-digital sales," but talk more about that.

Nicolaj (41:55):

Yeah. So I wrote about yourself. So when you are developing software, when you are firefighting, you're just fixing something for today right now that's on fire, but you're not thinking about how is this going to be used in the future, because that's not the problem you're trying to solve. In terms of which tools we use, you might use all the tools that you're familiar with, because they will get you started fast, but they won't be the best tools, if your problem scales are when your assumptions change. So an example could be a small flower shop. They will be selling flowers to a very limited number of people, so they can build with that assumption. But if they know that, "We will be scaling very soon," then maybe you can add to that to your actual list of beginning, assumptions that maybe we should use different frameworks that allow us to scale in the future.

Nicolaj (43:09):

And doesn't just have to be software. You can think of it as a building, "Should we prepare for one door or four doors?" So are you developing for yesterday, or are you developing for today, or are you developing for tomorrow? It's completely fine to do either, but you need to make an explicit decision about it, and think about, "Are we developing for yesterday, today, or tomorrow?"

Lauri (43:37):

Sometimes you don't know that.

Nicolaj (43:37):

Right?

Lauri (43:38):

Sometimes you just plowing away and you end up learning something, you think, "Oh, I have to learn this thing." And then you come back five years later and you thank yourself for taking the time five years ago.

Nicolaj (43:57):

Yeah. But you work with the assumptions you have and then you still make a decision to develop something, otherwise you are just in a continuous experimentation phase, and you never get to document any of the solutions, because you are constantly just hacking along. At some point you need to look at the experimentations you've done, and then wrap into a nice small iteration and say, "This is work that I did with an explicit intent. It solves a small problem. And it works as a unit." Then you continue with your next experimentation phase and you iterate on it.

Lauri (44:41):

If you think about your own career, what has been some of the most important moments for you to learn something that you have thanked yourself later?

Nicolaj (44:58):

Hmm, that is a very deep question. I think it's been learning how to listen to people and hear what they are saying. But also asking the people, "Have I understood you correctly? Is this the direction that we're going?" Software is so much less about coding than it is about working with people. Because if you are just building software yourself, and you have anything in your head, you have to be building a small library that's like how much can you possibly maintain? And if you're not building a small library, you're building a platform, you're building thousands of microservices. You're collaborating with so many people, and you need to spend some effort on communication and on understanding each other, so you are not building in different directions.

Lauri (46:08):

It is a deep question, but also I think it's another way of asking, "What do you think is important that you might not know is important today?" Because you only know that in retrospect. And some people who are not where you are with your career progress, they can learn from what you have done and I think that this is a wonderful tidbit or a wonderful insight to share. To become better in software development, learn to become better in working with people, simple as that.

Nicolaj (46:39):

And about communication, when you are working with so many people, a way of doing asynchronous communication and a way of doing it not one to one, is through documentation, communicating explicit intent. "What have you done?" How are you working? Where are you going? How do you use this piece of software that you've written?" That's been eye-opening to me, how much value you can get from documentation, even for yourself. I have this experience where I was, like any good software developer, I have thousands of projects running. And I had a fairly large project that I put down for nine months, because life. I was busy doing other stuff. And then, nine months later I thought, "Hey, I actually did some progress on a thing back there. Let's see if it still works. I have a couple of hours this afternoon. Can I do something with it?"

Nicolaj (47:53):

And I took down the code, I opened up the README, and within a couple of minutes, I had it running, and within the first 30 minutes I had made a substantial change to the application. And I could just ship that into the repository, where it will be living forever. But putting something down for nine months, and then immediately being able to work with it and contribute to it, that has to be my shining example of why I do documentation and why I still do it. Because I had that experience and I thought that was so cool. I want to be able to work with this.

Lauri (48:45):

Wow. It definitely wasn't Android programming, because you would still be waiting for Android Studio to upgrade and Gradle to be upgraded.

Nicolaj (48:52):

Oh, yes. Wonderful tools, if you know how to work with them. Very steep learning curve.

Lauri (48:59):

Yeah, yeah. This has been a fantastic discussion and thank you for joining. I have only one section remaining for you and that is the rapid-fire questions.

Nicolaj (49:12):

Yes.

Lauri (49:13):

So we take the rapid-fire questions with every one of our audience or the guests. And I just asked you to respond without thinking for too long. Number one, fill in the following sentence, DevOps is...

Nicolaj (49:32):

Awesome when done with thought.

Lauri (49:37):

Number two, what three questions do you ask to tell if a company needs your help?

Nicolaj (49:49):

What problem are you trying to solve? How do you think I can help you? And how many people are you going to allow helping me help you so that they can maintain what we've done afterwards?

Lauri (50:08):

Super. Number three, you are called to help your customer with DevOps, what's the first thing you do?

Nicolaj (50:19):

I suppose I would ask for their address. No, I would ask, "Where are you stuck? And what have you tried? How can I help you?"

Lauri (50:32):

What is something people often get wrong about DevOps?

Nicolaj (50:38):

That they think DevOps is a suite of tools, and they think that when you hire a consultant to help you with DevOps, he's going to show up and install the tool suite. And then he's going to leave and your software developers will magically know how to use all the tools and, furthermore, won't need to know how to maintain them.

Lauri (51:04):

What trends or new things you would like to see become mainstream?

Nicolaj (51:12):

I am a sucker for security. I think it's very important, the entire idea about shifting security left, but even simpler than that, just more documentation. Documentation done right. Just try doing that, then tell me it's boring.

Lauri (51:32):

What is your secret personal productivity tool?

Nicolaj (51:35):

Oh, you already know that. I just told the story about being away from a project for nine months and then instantly being able to contribute, just by reading the README.

Lauri (51:46):

A properly done README, yes, yeah. What book have you completed most recently?

Nicolaj (51:53):

That has to be The Five Temptations of a CEO by Patrick Lencioni, as an audio book. He is a wonderful writer and his business fables are great.

Lauri (52:08):

Yeah, I've read the Getting Naked, but that's the only one that I've read.

Nicolaj (52:13):

Yes. I can also recommend. Links will be in the description.

Lauri (52:18):

Yeah, yeah. The second to the last, what is something that brings great joy in your life?

Nicolaj (52:26):

I think being able to help people or teaching. So solving problems and just when you see someone and weight is just instantly being lifted off of their shoulders and they get an aha-moment like, "Oh, that was the solution. That is so cool." Or teaching, having people that want to learn, and having been given time to learn. And we are there just to learn some new cool tools and the aha-moments that they have when they see, "Oh, this is going to solve all of my problems." Then afterwards, telling them, "Oh, not all of them, but it is a cool tool."

Lauri (53:14):

And, finally, what is something that you are grateful for right now?

Nicolaj (53:22):

Something that I'm grateful for right now. I think waking up and enjoying what I do. I think everyone should be allowed to wake up and enjoy what they're doing, or find something that they enjoy. And I am, in terms of work, extremely grateful for my wonderful colleagues. Being surrounded by all of these geeky people that I can learn from and that I can help out, and that is so great, and I'm very grateful for that.

Nicolaj (53:57):

Hey, my name is Nicolaj Græsholt, I'm a consultant, trainer, and speaker at Eficode. I've been working here for almost four years, and I spend my time helping organizations to DevOps or upskill in different tools. And when I'm not doing that, I create some of our training materials or post the trainings and our customers.

Nicolaj Græsholt
DevOps Consultant and trainer at Eficode
Twitter: @figaw
LinkedIn: linkedin.com/in/nicolajgraesholt/