J. B. Rainsberger offers practical advice on how to "get over the hump" of evolutionary design, and really, how to learn any new skill.
Solving big problems with small teams
Host: Previously on tiny DevOps,
Guest: What really Agile meant to be from the beginning, was exemplified by what's the least we can do and still deliver great results. Part of the point of evolutionary design like I said earlier, is to allow us to pretend that we made the perfect decision at every stage.
Host: You've convinced me that I need to get better at refactoring, and you explained why it's important. What's the next step on my journey to improvement?
Speaker 3: Ladies and gentlemen, the tiny DevOps guy.
[music]
Host: Now the exciting conclusion. You've convinced me that I am an advanced beginner, and I need to get better at refactoring, and you explained why it's important. What's the next step on my journey to improvement?
Guest: The big thing that's missing, the part of the reason why I think people get stuck in this, they fall into this chasm. It's funny, it almost feels a little bit like the Jeffrey Moore technology life cycle adoption curve thing where people fall into the chasm. In this case, it's not between early adopter and the majority, but it's between the advanced beginner and the competent level practitioner. I still feel uncomfortable with some of the label, the labels that [unintelligible 00:01:17] used, but they're not my words, don't hold your cards and letters.
I think that I hinted earlier that deliberate practice was part of it. I don't want to just say deliberate practice because if I say that then programmers roll their eyes. They're like, "When? I don't have time for that, blah, blah, blah, blah," that's a whole other discussion. I think you do. I'm going to try to make that case, but before we even go there, I want to talk about what I think is missing. Why people get stuck in that advanced beginner stage. I think what is missing is what psychologists call chunking.
Chunking as far as I understand it, and I'm just an advanced beginner at this myself, is a way of describing how we build knowledge. If you've read, Thinking Fast and Slow by Daniel Conman, then you're familiar with this system, one system, two designations. System two is your short term working memory. When you put in conscious effort to do something it's happening in system two, it's pretty low bandwidth. It's easy to forget things.
It gets crowded quickly but, it's very deeply and immediately connected to your conscious memory which makes it incredibly useful, because almost everything that you're thinking about right now consciously, is happening there. System one, sitting in the back of your mind is the one that's always on, always recording. It seems to have no organization system that the rest of our mind understands. The big problem with system one is that for all its bandwidth and it's fidelity in recording our experiences, system one does not know how to send messages reliably to system two.
That feeling you have when you are in the shower, and you get an insight or you bolt up right at 4:30 in the morning when you're trying to sleep, and then you can't get back to sleep because something just came to your mind, that's system one finally managing to send a message to system two, which is infuriating and unreliable, and you can't really build a strategy around that. What's missing for people is chunking, which you can think of as system two handing off some of its thinking to system one.
System one is really good at keeping the lights on, keeping things moving, it's how you breathe, it's how you walk, anything that you do that doesn't require conscious effort, system one has taken over, and that's chunking. Every time you take something that required conscious effort and move it so that it no longer requires conscious effort, where it becomes autonomic, not automatic, you're still in control, but when you decide to do something and your fingers know what to do, your legs know what to do, your face knows what to do, you don't have to think about how to smile. You just think, "I want to smile now and a smile comes." That's autonomic behavior.
Host: Learning to ride a bicycle concept.
Guest: Perfect example, walking, riding a bicycle, tying your shoes. I'm the barista in the family. I operate the espresso machine, and there's the old joke about, in the beginning I needed espresso in order to be able to make espresso. Like that's how hard it was for me to coordinate all the movements. Now I can pull two shots in eight and a half minutes from beginning to end. Honestly, there are mornings when I am in the middle of pulling the second shot, and I don't have a conscious memory of taking coffee out of the cupboard, and unpacking it, and pouring 37.4 grams of beans into a scale.
I can't remember that. Just like I'm told, because I don't drive, but I'm told that people who drive routinely have the experience of driving home from the office, back when we all used to do that, and not really having a conscious memory of driving home, you were thinking something else while you did it. That's autonomic behavior. Chunking enables autonomic behavior. I should say autonomic behavior is a manifestation of chunking. Why chunking is so powerful is that we can do it more or less indefinitely.
I don't think we have to worry about chunking so much that we run out of room in our brain. I think we're probably all going to die before that happens. Each of us individual. You can pretty much chunk as much as you want. Now chunking happens through repetition. It's the same way you learn how to walk, the same way you learn how to chew food. It's we never had to learn how to breathe, at least not most of us never had to learn how to breathe, but you could imagine that eventually those things you learned how to do through repetition, you were very bad at it until very suddenly you weren't.
Something happened in your mind, stuff went from conscious effort to unconscious effort. That's chunking. That happens through repetition. I like to say repetition leads to ease, ease leads to chunking.
Host: Okay.
Guest: That's the beginning of it. That's why, again, to go back to your earlier question about why does it seem easy for some and not the others. It's easy for the people who just did it a lot, who for whatever reason, right time, right place, right motivation, volunteered to refactor everything all the time. By volunteering to refactor everything all the time, they went through the repetition, they focused on, maybe they didn't do it intentionally, but they ended up doing same things the same way, often enough that chunking happened.
Chunking and ease I'm not sure whether chunking leads to ease or ease leads to chunking, but it it's nice reason. Repetition leads to ease, ease leads to chunking. Chunking then allows you to build up these increasingly rich mental models of how to refactor, how to move code around, which IDE key strokes, which editor key strokes, whatever it is, how those things work. Anyone who read the original pragmatic programmer book might remember that they had a section called pick one editor, and learn it well.
That's another example of repetition leading to ease, leading to chunking. You could eventually stop thinking about how to move text around, and can focus on why you're moving text around. That's really the first stage. Repetition leads ease, ease leads to chunking. Chunking allows you to build this rich mental model of not just how to move code around, how to rename safely, how to in line and extract, but to really understand things like, "Okay--"
This has been coming up a lot in the last couple of years as I've been working with people. If you extract methods, so I'll talk in object oriented terms, just because that's still quite common. If you extract a method that talks to only one field out of the object that it lives on, eventually that method is a candidate to move on to that class. If that field is some custom class, if I extract a method that only talks to that one member, and not to the rest of the object, that method is a clear candidate to move on to that class.
Someone who is in the early stages of practice will probably feel some compulsion to move that method now and will just do it and be done with it, and they'll feel better. Then they'll gather evidence whether that ended up being actually a good design choice, they might find out two weeks later that that was a bad idea, and they just go, "Ah, I was stupid," and move it back. If you practice long enough, the act, the mere act of extracting that method and seeing that it's talking to only one field is as good as moving it. In my mind it's already there.
I have the option to move that method onto that other class at the moment when that becomes obviously a good idea. For me, even extracting that method is as good as having moved it to the right place. I don't have to speculate about it, I don't have to look at it, I can just, at some point I'm going to realize, "Ah, it actually really does belong there," and then I'll just move it easily. Those are the kinds of changes in thinking that happen as we chunk.
It's very hard for me to have that thought. In fact, it's even hard for me to have the thought of first I extract the method and then it's safe to move to the other class. If I'm still trying to remember that Shift+F6 is rename, but F6 is move, and CTRL+F6 is change signature. when I'm forced, I tend to think of strategies moves micro steps and Nano Steps. Strategies are like when I work in Ruby I think about dynamic meta programming design solutions. When I work in PureScript or Elm then I tend to think of really relying on the type system to write tests that I don't need to write.
Those are strategies, that's really high level that affects not just whether I do evolutionary design, but how I do evolutionary design in those environments. Strategies are more like-- Moves sorry, moves are more like collapsing a layer, splitting a layer into two pieces, removing duplication at the edge of integration so that I can move code outside of the horrible outside world, and limit the amount of code that actually needs to use integrated tests to talk to the horrible outside world, or replacing type conditionals with polymorphism, because I'm working in a language that does polymorphism free of charge.
Why not let the language do it? Those are moves, micro steps are things like extracting a method so I can move it later, or removing duplication and noticing that there's three methods whose names half of the name is the same half of the name is different. The part of the name that's different is the implementation. The part of the name is the same is the method, and that's three implementations of a common interface. I'm going to now do that or replace inheritance with delegation, or any of those kinds of things.
Then the Nano Steps are like Shift+F6 is rename, CTRL+Alt+M is extract method. I can click in the middle of an identifier and just hit CRTL+W a bunch of times and expand the selection to, and it knows how Java works. At every level you can chunk, and you have to, if you are focusing on Nano Steps you can't think very well at the level of micro steps, if you are focusing on-- I should say if you're thinking of Nano Steps it's hard to think at the level of moves.
If you practice the Nano Steps, it's easier to think directly in micro steps, and then Nano Steps take care of themselves. if you then practice the micro steps, which are things like, "These four Nano Steps in a row makes this magic design thing change. This higher level refactoring is these seven steps in a row. Let's do the same seven steps the same way every time." As I chunk, it's not just that it gets easier to do the Nano Steps, it gets easier to do the micro steps, but chunking frees up space in your conscious, in your working memory.
If you don't free up space in your conscious memory, you can't think about moves and strategies. That's how people get stuck, they don't do enough repetition to get to the point of chunking. They're conscious, they still have to put conscious effort into the micro steps, and the Nano Steps. The only time they get to think about moves and strategies is by accident. Then they have this feeling like, "I'm just moving code around. I'm not really getting anywhere." Repetition leads to ease, leads to chunking.
What this allows you to do is to gradually graduate, as it were, from focusing on Nano Steps to focusing on micro steps, to focusing on moves, to focusing on strategies. As you climb the ladder, as you chunk more, it becomes easier to have these more abstract thoughts to move your thinking away from, "How do I refactor?" towards, "Why do I refactor, and how do I know that this sequence of refactoring is actually going to be better than that sequence of refactoring? How do I know that now is the right time to do it?"
The kinds of questions that a proficient practitioner and an expert practitioner would mostly concern themselves with. It has to start with some form of deliberate practice, and the people who got past that either were so gifted that they didn't need much repetition, or they didn't even realize that they were doing deliberate practice, and just did it accidentally. Most people who are really good at things were just single mindedly obsessed about it in their childhood, and fell into deliberate practice before they even know that there was a term for it.
The good news is if you know what deliberate practice is and how to do it, then it's not too late. You didn't have to be born with it. You didn't have to develop it at age eight, you can do it now. It starts with something that I like to call the casino technique.
Host: This sounds exciting.
Guest: Casino technique is essentially. I haven't actually, but many of us have maybe had the experience of walking into a casino with their friends, and as they are approaching the door to the casino you turn to your friend, and you pull out your wallet, you're reaching your wallet you take out $200, you put the $200 in your pocket, and then you hand your wallet to your friend, and you say to your friend with this really stern look on your eyes.
In your most serious voice you say, "No matter what I do, no matter what I say, no matter how much I beg and plead do not give me anything in my wallet, don't give me any of my cash, don't give my credit cards nothing. When this $200 is gone, my evening's entertainment is over. I don't care if it takes 10 minutes or 10 hours, but no matter what happens do not give me my wallet. Don't let me spend any more money than this."
Then when you leave the casino and you're 500 feet away from the door, then it's safe. "Okay, now you can give me my wallet. I promise I'm not going back," which is really just a colorful way, I hope of saying, "Becoming aware of how much time and energy and money you can afford to lose on practicing even if it doesn't get you anywhere." In the beginning deliberate practice is going to feel like it doesn't get you anywhere, even though what's happening is the initial stages of chunking. Chunking isn't something that you feel it just, you look back on it and it happened.
It can be really easy to give up before it starts getting good, and so one of the ways you can deal with that is just to use the casino technique, figure out how much time, energy, money you can afford to lose, and go for it. Now, most people have never tried this. One of the ways that you can get started is by guessing. If you are working on a project where the average task takes, I don't know, on the order of two to five days. You spend about two to five days where people know that you're working on task X, you're pretty much left alone.
Yes, you're giving status updates every so often, or maybe not but people are expecting you to work for two to five days. If it blows up to two weeks, they know there's a problem. Nobody expects you to be done right away. At that level you can almost certainly gamble for 30 minutes. I'd say there's a very good chance that you can gamble with 30 minutes. That if your task takes three days, and you finish in three days and 30 minutes, nobody's going to notice the difference.
You can spend that 30 minutes doing some form of deliberate practice. It can be as crazy as actual drills, like dojo's style, beginner martial arts drills. It can be things like, "Let me try to clean up this code for 30 extra minutes before I declare victory." I struggled to make something work. Maybe I did a little bit of refactoring while I was working on it. Maybe not, and I'm about to declare victory push before I hit push. Let me set the timer for 30 minutes, and just try to clean some stuff up.
I'm sure there's a mess here somewhere. Let me clean stuff up before I move on. At the end of 30 minutes I can make the decision. Do I keep that work, or do I throw it away? A lot of the times you throw it away early on, but remember what you're to do is create the conditions where you just allow yourself to repeat things, whether it's conscious drilling, or allowing yourself to do cleanup before moving on, they both set you up to start doing repetition.
If 30 minutes works, so let's say you do that. You spend a month at the end of every task you spend 30 extra minutes, at the end of the 30 minutes you're like, "Ah, okay, whatever," throw it all away, push the changes. "Hey, I've done my task, let me get the next one." You do that for a month and nobody notices that you spent the extra 30 minutes, then try an hour. If another month by and nobody notices that you're spending an hour, then try two, and just keep doubling it until either you feel really uncomfortable, that pain in your chest that you feel guilty about using all this extra time, even though really there's nothing to be guilty about trust me.
If somebody starts looking at you like this in a meeting, or if you all of a sudden see that there's a one-on-one invitation from your manager that's not your regular one-on-one, then maybe that's now you've found the limit. You found how much you can afford to throw away. For a lot of people it's some thing like two hours once a week, or two hours twice a week, you'd be surprised for some it's much more. That is slack. That's excess capacity.
If you are not the literal bottleneck on your project, then you do not need to go at full speed at full utilization all the time, and if you want proof go find Ellie Gold Rat's book The Goal and read it. In fact, if you like audio books I'm told that that is an excellent audio book. Very well produced.
Host: It is, I've listened to it. I can vouch for it.
Guest: Okay, there. Good, I'm glad that I'm not steering people wrong. You almost certainly have slack. I know it doesn't feel like it, but you almost certainly have time and money slack. You might not have energy slack. One of the nice things about deliberate practice, is that it can feel quite calming, and so you can recover a little bit of energy while you're doing it. If you do that long enough repetition leads to ease, ease leads to chunking. Then you start to notice maybe the most important thing, which is that as chunking happens, your resistance to refactor in an industrial-strength situation under real-time, pressure starts to decrease.
You start to notice situations where, "I think I know how to do this. I'm going to try now, even though people are waiting for this task to be done, I'm not going to wait until the 30 minutes or two hours or whatever is after, I'm going to find more opportunities to actually do this stuff as part of my day job, and not after my task is done." That gradually happens, you might not even notice it until it starts happening. This is when things really start to get good.
Repetition leads to ease, leads to chunking, but chunking leads to courage, leads to confidence. As you chunk, there's space in your brain, that frees up to think about higher-level issues. What starts to happen is you don't just think about how to refactor safely, how to refactor accurately, but you start to think more about, when is it a good idea and when isn't it? You start to look for, is it really improving the design or not? You find it free. You find it easier to have those thoughts, which means that you can then engage in conversations with your peers, with your mentors, with whoever, if you're in a training class, or if you're just in a discussion group somewhere where you can bounce ideas off fellow programmers.
It's much easier to think about those things after you've allowed enough time to chunk from Nano steps to micro-steps to start thinking about moves and strategies. For me, it probably took, I don't know, a year or two before I really felt like I was mostly not concerned with the Nano steps and the micro-steps anymore. As long as I was working in my familiar environment. Chunking then leads to courage, which leads to confidence, courage in the sense that you begin attempting to refactor, even when you're not sure it's going to work, even when you're not sure where you want the design to go.
Even before you have this picture in your head of what the right design should be, that you trust, not only that you know how to do the steps, but also trust some of the really fundamental principles. I use remove duplication and improved names. If I'm not sure what to do, there are three moves that always work, remove duplication, improve a name add a test. One of those three things will probably work. I might just have this vague feeling that this code is crappy.
I don't know exactly how I want to you improve it but I do know that if I either remove duplication, improve a name or add a test, there's a good chance that I'll take one little step in a good direction. When you're an advanced beginner, you don't have the feeling that this is going to lead to something good. You just have the vague feeling like, "I should try this and see what happens," but as you get to the point where you're no longer focused on Nano steps and micro-steps, when you can start to think about moves and strategies, because you've chunked, it's like you have this feeling that there's a road that you're going to travel, and the road is going to appear to you after you start walking.
The first few times that you do that, it feels weird and if you do it often enough, you begin to trust it. You begin to feel confident. Well, at least you feel courage to try to refactor even before you know exactly where you're going to end up. There are lots of times where you have this picture in your head and you say, "Now I know how to go from here to there in 114 really nice steps that are going to be reversible. I understand, and that most of them are obviously correct. The tests will help me if I make a mistake."
Eventually that turns into, "I don't even have to know where this design wants to go. I know that if I add a test, remove duplication or improve names, and if I do that often enough, the path will reveal itself to mem and I'll go in that direction. The code knows how it wants to be designed. Then it starts to feel weird. After you submit to that, after you give into that a little bit, and allow yourself to feel that courage and act on it, eventually you reach the point where, "I don't have to worry about how to design this code, because when the design decisions become important enough, the design will be right at the moment when it needs to be there, because I'm going to refactor the whole way."
Repetition leads to ease, leads to chunking, leads to courage, leads to confidence. By the end of that, you end up in a situation where you almost never worry about the design, unless it's a really genuine thorny difficult problem. Now you're talking about, "Oh, I'm not an expert in distributed systems yet, so I don't really completely understand the computer science of distributed systems to be able to understand what the architectural design constraints are."
I can focus on that stuff instead of worrying about how to organize code into objects or functions or modules, where should the abstractions go and what happens when I realize that these abstractions were a bad idea. Well, you just combine them or you split them apart. You don't think about how to do-- You don't feel the resistance to that anymore. You can effectively act on any thought you have about where you think the design should go. Then what really changes for the rest of your career is you get more and more sophisticated ideas about what means good design.
It really does start from that deliberate practice. It's the same at every stage. I think the difference is that maybe we've been relying on doing this deliberate practice, this is going to sound strange to say, but we've been relying on accidental deliberate practice, unintentional deliberate practice, incidental deliberate practice, the kind of thing that you do when you just throw the ball against the wall for four hours every night as a seven-year-old kid because you like baseball.
Not because anybody told you that that was the fastest way to build skill, but if you're in your 20s, 30s, 40s, I think it's worth understanding how this works. That repetition leads to ease, leads to chunking. That chunking is critical because not just to make it easier to do things, but to free up space in your working memory so that you can have more abstract thoughts, so that you can stop focusing on what and how, and think more about why and trade-off decisions.
People get stuck in this advanced beginner stage, because they feel pressure to have good judgment before they've made enough mistakes to develop good judgment. Good judgment comes from experience, and experience comes from bad judgment. If you make room for deliberate practice, if you never make room for failure, for experimentation, I don't even like to call it failure experimentation. Then you'll never get anywhere except by accident. I think that that explains why we have this constant state of advanced beginner-ness, is that we just don't do intentional truly deliberate practice.
Host: The question I'm sure every advanced beginner is asking, which of course doesn't probably have an answer, but I'm going to ask it anyway. How long does this take?
Guest: The classic answer of course is it depends, which everyone knew. There was no point in my saying that. It doesn't take weeks. It takes longer than weeks. It doesn't take decades. It probably takes months to years to reach the point where you trust your evolutionary design skills so much that you feel that ease, that lack of urgency to make the right decision up front as your default way of thinking. Now you can do a lot of great stuff before you reach that point.
Now how long does it take before the stuff starts getting good? I think stuff starts getting good at the point where you are struggling with the question of, is the design getting better or worse, rather than struggling with the question, how do I safely move code from here to there? I think that's when you start to turn the corner, I think that's when you leave the advanced beginner stage, and start to become competent on your way to becoming proficient.
Where you start noticing that when I'm working with this set of tools, if I do the steps in this sequence, then it's easier than doing it in the sequence that Fowler writes in his book, or where you notice that on this project with these people, we tend to think about those concerns more often, and these particular refactorings tend to help us more. I think that's months to a year or two, that's not lifelong practice. I think that if you give yourself a chance to practice deliberately, by the way, on your employer's dime, let's be clear.
I'm not talking about going home and doing stuff on evenings and weekends. There are some people who are stuck in a situation where they might need to do that. I'm not recommending it. I'm not endorsing it. I think that your employer is failing you if they're forcing you to do all your personal development on evenings and weekends. The good news is, you're almost certainly not the bottleneck, so you probably can use the casino technique, and find out how much time during your Workday. You can spend on this stuff. I think within months you can notice a significant improvement. The one downside, unfortunately is that, improvement seems to follow an exponential curve.
Anyone who knows exponential curves knows that it seems really slow for a really long time until very suddenly it goes fast. Determination becomes a bottleneck. One other thing that are really want to impress upon your listeners is not to try to do this alone. Now, I don't mean deliberate practice in real time with other people, although if you can do that, it can be fun. A lot of people probably benefit from doing the actual moment to moment deliberate practice on their own, so that they can go at their own speed or they can slope and slow down and speed up anytime they need to.
At some point you're going to do something that feels weird. You're going to try to follow somebody's advice and it feels weird, or you're going to be in a situation where the books tell me to do this. My gut tells me to do that. What does it mean? Those are the exact moments when you need to ask for help, and that's fortunately we've never had more access to help than at any point in human history. There are people out there falling all over themselves to help you. I'm one of them.
We freelancers live on your questions. That is how we do marketing. That is how we help people see how smart and lovable we are, so that they'll want to hire us, and feel guilty they're not paying us more. That's how we decide on subjects for articles and books and training courses. Now the downside is that there are more people competing for your attention than ever. You might have to stumble around in the dark for a while, before you find one or two or three mentors you feel like you can really trust.
I had it much easier 20 years ago, because the hundred people in the world who were interested in test driven development, all hung out in the same Yahoo group, and they were all there and I could trust them all. It's not like that anymore between Quora and stack overflow and personal communities and mentoring circles like even the one that I run. It's a very fragmented landscape. The only thing that I can suggest that you do is, just try people.
Ask people questions, and judge by how well you like their answers. If you're lucky, you'll find exactly the right mentor for you at the right time. You'll know because you trust them and there's nothing else that matters. If you trust them, then they're the right mentor for you, and if you don't, then they aren't and that's the end of the discussion. Don't panic. Don't worry. It's going to take some trial error, but please don't try to do this on your own. Start now, casino technique, ask for help and like I said, give it a few months to a year, and if it's really not working for you, we tried.
There's a very good chance that you're going to get to at least the first level of the really good stuff. Well, you're where you'll stop focusing so much on how to do it, and it'll become easier and more significant to think about why am I doing it now? Why this refactoring now? Is it really making the design better?
Host: Great. Well, you answered one of my questions. I was going to ask, what do you do if you don't have a mentor? The answer is find one. It's easy today. That's good. Suppose you are the tech lead or the manager of a team, and you recognize that you have some of these advanced beginners on your team, but you're not qualified to be a mentor, how can you help these people? Obviously we could give them that casino time they need, but what else can we do to help our colleagues, or our subordinates to improve in these areas?
Guest: I think there's two key parts of that. One of them relates to an article I wrote about 10 years ago, called the eternal struggle between a programmer in the business, which also spawned this talk called seven minutes, 26 seconds that I did at a conference where I essentially tried to lay out a mathematical pseudo proof for the claim that incremental product delivery doesn't work if you don't refactor. The joke, the punchline at the end was scrum doesn't work without XP.
Which was really just a funny way of saying that if you want to deliver products incrementally, refactoring is probably critical to that, because refactoring is what allows you to protect your capacity to deliver features over time. As a people manager, or a product manager, or project manager, you're probably concerned with some combination of investing in your people. Their growth, the servant leader-y things, and sustaining your capacity to deliver features.
I'm hoping that you're planning for your projects to last more than a couple of months. You actually care about that. If you don't, you shouldn't. If your projects last four months, and you just keep going from project to project, then you don't have to worry about the long term sustainability of your pace for delivering features. Throw that all away. That's fine. For those of us who don't want to live there, who want to be able to build version seven on top of version one, understanding the role that refactoring plays in protecting your capacity to deliver features indefinitely is critical.
Maybe as a manager, as a decision maker, as someone in a position of authority, it can help you to earn the trust of the programmers and the other frontline workers, programmers, testers, whatever they are in your organization, the people who are building the things, and preparing them for release, that do they trust you when you say, "I understand the role that refactoring and evolutionary design plays in the long term health of this project, therefore please do it."
That's one thing. I think that a lot of programmers don't think that their stakeholders understand what refactoring is for, and at very least I think programmers and those non-programmers stakeholders think they're sitting on opposite sides of the table when really they could be sitting on the same side of the table and saying, "It's not us against each other. It's not refactoring against features. It's refactoring to support features, so that it can be us against the market, or us against sales, or us against wherever the bottleneck is."
I think that understanding that if you don't understand that dynamic, understand it. If you do understand that dynamic, get better at articulating it to the people who are looking to you to give them permission to do these things, whether they should or not. The second part of that I think is, recognizing the role that chunking plays in being able to do that well. All the stuff that I've been talking about for the past hour plus, that understanding that that's not a quick process, but it is literally how we learn everything.
To pretend that people can learn something another way is denying literally billions of years of evolution, sorry. I don't know how to do that. I don't know how to learn anything another way. I have to let repetition lead to ease, lead to chunking, which eventually leads to courage, leads to confidence. If you're prepared for that, then you can make space for it. Part of your job as a manager in your organization and maybe then if you're also a leader in your organization is to do all the painful managing and leader-y things that go into protecting the people under you from the difficulties in the enterprise around you.
That's part of what you're signing up for. That's part of what your job is. It's not an easy thing to do. To recognize that that is an essential part of getting the results that you're hoping for from evolutionary design. Of course if you notice that they're having difficulty getting started, then you should buy them some training.
Host: Where can we buy that training?
Guest: Well, one of the things that I have been experimenting with over the last year, and I'm hoping to relaunch is something I'm calling refactoring workout. That is essentially, the training that helps support the message that I'm giving here. We're doing a refactoring workout workshop as part of the Def Eternity Conference in, December, 2021. For people listening 15 years from now, sorry, you couldn't make it. That is a nearly full day workshop.
It would be a full day if everyone were in my time zone where we can do a talk about deliberate practice, do some deliberate practice, combine some drills with some free practice, help people understand what kinds of areas do they need to put conscious effort, and so what should they practice? Part of this is to help individual people understand what requires conscious effort, and how do I practice that? That's part of what we'll do is suggest some drills suggest some exercises that are a little bit longer put you together with some people so that you can refactor together.
My hope is at the end of the day, you start to notice that some of the things that you're doing in the last hour felt easier than the things you were doing the first hour, so that you can already see just in the space of a day. What that feeling of conscious ease, of reduced conscious effort feels like. If folks need a more general introduction to test driven development then you might as well buy the best one in the world. Try the world's best introduction to test driven development level1@tdd.training.
It's a self-study course. A lot clients are starting to see the wisdom of letting people go through self-study training and then supplementing that with live sessions, whether that's two or three half day workshops in a row, or just workshops here and there, where they see how to practice it, understand how it fits into the larger picture, and can get started, and can figure it out at their own pace while still feeling supported, and having a place to to look for help.
Host: Wonderful. We've mentioned a bunch of books. We'll have links to all of that in the show notes for anybody who's interested, where can people get a hold of you if they're interested, if obviously you mentioned your course, but if they're just interested in reaching out with a question where can they get a hold of you?
Guest: Simple go to ask.jbrains.ca that's j-b-r-a-i-n-s.ca. not.com, .com is some consulting company in Japan. They got there first. You can always visit, ask.jbrains.ca and drop me a question. I'll make the same offer to your to your crowd that I make to everyone. If as long as you're willing to wait indefinitely for an answer, then that service is free. If you need a better service level agreement than that, then we can talk about how much that costs, and it's less expense than maybe you think.
Host: Great. Is there anything else you'd like to add JV before we sign off today?
Guest: Yes, one little thing. I think I really want to reiterate for people who maybe recognize themselves as being stuck in this advanced beginner stage of evolutionary design, or even of software design in general. What I really want to bring with this message is a message of hope that you didn't have to somehow magically accidentally learn this stuff in childhood. That maybe if you understand more about how you learn things, and what that process is like, that you can have some more patience with yourself.
Feel a bit more determined and to be able to stick with it long enough for the good stuff to happen. There's nothing that stops you. Well, I shouldn't say that. There's not as much that stops you from learning this now, as you might think. Certainly you won't know until you try. If you allow yourself to put some trust in the dual benefits of deliberate practice and chunking, I promise you it's very--
Well, I should say, it's very hard to do this stuff and make no progress. You have to wake up awfully early in the morning to do this stuff and make no progress, you can do it.
Host: Great. Thank you for the encouraging words. Thank you for the the challenging thoughts, new maybe new paradigm for some people, mental paradigm, it's been very educational. I've learned some new things, thanks so much for coming on, and we'll be in touch.
Guest: Thanks again, everyone.
Host: This episode is copyright 2021 by Jonathan Hall, all rights reserved. Find me online at jhall.io, theme music performed by Riley Dey.