SAM:  Hello and welcome to Episode 30 of ‘Cycles in Philosophy of Software, Common Principles with Different Names & Reference’. I’m one of your host, Sam Livingston-Gray and I’m here to welcome to the show, my co-host, Janelle Klein. Welcome Janelle.

JANELLE:  Hi. Yes. That’s me and I also like to introduce, Rein Henrichs.

REIN:  Thank you so much. I am excited. This is my birthday so this is like a special birthday podcast for me because I get to introduce Tom Stuart. Tom gave us what he calls a standard boring conference bio which I will nevertheless read, which is that Tom is a computer scientist and programmer. He has lectured on optimizing compilers at the University of Cambridge and written about technology for The Guardian. He co-organizes the Ruby Manor Conference and he is a member of the London Ruby User Group and London Computation Club.

Tom is currently writing an e-book called How to Write a Web Application in Ruby. His previous book, Understanding Computation was published by O’Reilly in 2013. Now he did tell us that he is in fact not actively writing that book at the moment because, ‘it turned into a slog,’ which to be fair as someone who has developed web applications in Ruby for the better part of a decade, it is sort of a slog to do so. I can understand that. Tom, thank you so much for being here.

I guess, I like what you also included after the standard boring conference bio which is that you get a lot of enjoyment out of programming and that you want to share that with people and better communicate some of the mathematical or computer or scientific aspects of it to help people get more enjoyment out of those. I’m big fan of that.

TOM:  Right. Thanks very much for the intro and happy birthday. I feel very honored to be here on this special day.

SAM:  We, sometimes like to start the show with superhero origin story where our guests talks about what got him into this whole technology thing. You are welcome to either do that or skip it as you see fit. What do you think, Tom?

TOM:  I’m happy to give a superhero origin story. I guess what got me into technology in the first place was when I was a kid, my dad was a teacher and he taught computers among other things. From an extremely young age, there was always a computer around the house so it’s always been a normal part of my life. It’s not something that I chose to get into something. I was just exposed to from a really young age and it was always very normal for me to have a computer to play with. I was incredibly privileged and this is in the 80s and home computers were a thing but they were expensive but because my dad was a teacher, we could borrow computers from school and stuff like that. I was very, very lucky to have access to the BBC Micro. That was one of the early home computers in the 1980s, in the UK and I learned to program on that.

All through school, while the other kids were outside playing sports and stuff, I was indoors writing little programs in BBC BASIC and figuring out how things work and typing in computer programs from magazines and taking them to pieces and trying to figure out how they worked and then that just naturally continued into my adult life. I still basically do that. I still spend a lot of my leisure time and evenings doing stuff relating to writing computer programs.

My job has become increasingly less and less oriented around actually writing code and more around of people-y stuff but I still have this real urge to tinker with computer programs and figure out how things work. I get involved in a bunch of meetups and go to events and just spend some of my time in the evenings hacking on stuff and building little things on the weekends for my own enjoyment. Sometimes for some of the meetups that I go to organize, I build fun little tools and visualizations and things like that so there’s the through line from my origin story to right now is I suppose that I’m really fascinated by computer programs and by computation and by these all mathematical underpinnings of that stuff and I just get a lot of joy out of fiddling around with them and figuring out interesting new things to do with programs. It’s not much of a superhero but that’s me.

SAM:  Being able to persist and focus on difficult technical topics is most definitely a superpower.

TOM:  Cool.

REIN:  Short aside, was BBC BASIC, the one that didn’t require parenthesis around the function arguments?

TOM:  I can’t remember. Possibly.

REIN:  Would that entirely explain your later interest in Ruby?

[Laughter]

TOM:  Are you saying that Ruby is like the BBC BASIC of the 90s?

REIN:  I think they’re [inaudible], sir.

TOM:  Okay. Fine. All right, well, birthday prerogative.

[Laughter]

SAM:  With that wonderful base, shall we talk about people?

TOM:  Lets.

SAM:  One of the things, Tom threw out as a topic when we were setting up this episode was this idea of the differences between ‘junior’ and ‘senior’ people and what differentiates the two. But before we get into that, I would really like to talk about nomenclature a little bit.

I hesitate to label people as junior and senior because I feel that it implies that this assessment we’re making of their technical skills applies to them as an entire human being. It reminds me a bit of when I was working in a law firm earlier on in my career and one of the things that I learned about legal culture is that it doesn’t matter what you’ve done before you came to law school. You could be a doctor or you could have been a bike messenger. The only thing that matters, at least in theory is how long you’ve been in law and how long you’ve been practicing and whether you worked your way up through the ranks.

At the time that struck me as a certain level of hubris that the profession is saying that ours is the only thing that matters in the world. I feel like labeling people as junior and senior developers sort of recapitulates that hubris. I like to borrow what Coraline has been saying about people who are early career or people who are more experienced in software development but I’ve been talking for way too long. Tom, tell us about early career versus experienced folks.

TOM:  Well, I completely agree with you on that. I also find that junior and senior naming to be probably at best, a little bit patronizing and at worst, potentially alienating to people. It is really interesting the extent to which experience in itself is a useful proxy for determining skills. I think increasingly as I’ve spent more time working with developers, both extremes of that spectrum, as I get more experience and the people around me, the people that I know of are becoming more experienced but also because there’s now a much healthier supply of new developers into the industry. Things like boot camps are producing a much healthier supply of lots of different kinds of people.

Some of those will be young people who are looking to do development as a first career but there are also a lot of people who are changing. They may be in their 30s or 40s or 50s and they want to switch away from whatever they were doing before. I’m getting exposed to a lot of different kinds of people who you might notionally want to put in that bucket labeled junior but it doesn’t really make sense for that to be the label. Also, people will come to the role of software development with a bunch of pre-existing skills, regardless of how many weeks or months or years they’ve been working.

As a software developer, in many cases, a lot of the people who I’ve met who are doing their very first software development job, they already have a very impressive array of skills that I see as being absolutely essential to being a developer. It may be that they have not spent very much time actually writing computer programs but especially if it’s at a previous career, they might have spent the last decade dealing with other people and learning how to communicate and learning how to negotiate difficult conversations or learning how to empathize with other people’s perspectives and things like that. Obviously, that’s just as important an aspect of being a developer as kind of memorizing the whole active record API or whatever.

There’s sort of an interesting thing that where it’s firstly difficult to know how much experience in each of those areas a person has because it’s not necessarily the case that someone who has only just become a developer, has also only just begun dealing with other humans or learning how to organize their time or learning how to solve problems in an abstract way. They might already have those skill so that’s one thing that’s problematic about judging people on this kind of one dimensional scale of experience.

I supposed the other one is ultimately what I’ve come to realize is that I’m actually not really interested in experience in and of itself. Experience can be helpful because it’s a simple proxy for other things that I care about. For example, one of the main things that I see more experienced developers doing is just having a slightly more bloody minded approach to problem solving. It’s interesting because I have seen it several times where a new developer has sat down and paired with a more experienced developer and the less experienced of the two quite often bring some expectations along with them.

I think it’s easy for them to assume that the more experienced developer is some kind of wizard and they are going to know all the magic spells and all the keyboard shortcuts and they’ll already have all of the answers to every possible question in their head so the less experienced person sits down and says, “I want to try and solve this problem. I may be tried it for five minutes and I hit a brick wall and I couldn’t figure out how and so I guess I’m just not smart enough to solve this problem,” and they’ll turn to the more experienced developer and say, “Please. Oh, wizard, can you tell me how to solve this problem,” and the more experience developer would just say, “I also do not know how to solve this. I don’t have the answer to this in my head but what I am going to do is show you that it is normal and fine for us to spend a couple of hours banging our head against this problem and it may be that we need to go search stack overflow or we need to go and look on Google or we need to go and read the Rails source code to figure out how the heck this thing works and the test we were trying to write is not even correct so we’re going to try and write a smaller test and when that doesn’t work, we can go figure out that we need to upgrade this dependency.”

The fact that software development in large part is just this kind of joyless slog through one problem after another is I think that it’s very, very difficult to internalize when you haven’t done it for a long time. It’s very difficult to teach to someone. It’s very hard to take someone who’s fresh out of a boot camp and say, “It’s fine for you to just spend a lot of time bashing your head against things and struggling and feeling inadequate because even someone who’s been doing software development for 10, 20 or 30 years feels like that every single day.”

I feel like that every single time I sit down and try to do something. I feel frustrated and inadequate and feel like I should know the answer but I don’t. The only difference is I know that’s normal and the number of years that I have been exposing myself to that experience has gradually built up a resistance to that sensation. Now, I don’t mind sitting down and struggling with something and actually I have — I think most more experienced people have done this — gradually developed a kind of arsenal of weapons against that feeling. It might be for example, that you always try to make the problems smaller.

If you’re bashing your head against something and you spend an hour or two trying to figure out and you can’t, then rather than continuing to bash your head against the same problem, you take a step back and you try to look at it from a different angle and you say, “Is there are a sub-problem that I can attack?” Or, “This test that I’ve been trying to make pass is actually testing three different things at the same time so can I make a more focused test?” Or, “This thing that’s currently a private method, could I expose that as a public method and try and write a unit test of that, rather than trying to test this off public method that actually calls into a bunch of private ones?”

Those are the things that I think are really important. Those are the skills that really matter in terms of how productive you can be and how much you’re able to multiply the productivity, this old generativity anything that you’ve discussed on this show before like how will you able to support other developers and being able to be productive and feel smart and feel able to attack problems. All of the skills that actually mattered there, none of them is the skill of having sat in a room for 10 years writing code. That doesn’t matter at all but I also don’t know a good way to teach people that kind of resistance to the day-to-day experience of problem solving with computers faster than sitting there and doing the job for a decade. There’s an interesting interplay there between, “I don’t want to care about the number.” It’s not about how many years that your butt been in that chair, trying to do this job. That’s not interesting.

But also, I would like to get better at figuring out. How do we teach those of what I’m characterizing as the really important skills of being able to be bloody minded and be persistent and have confidence in yourself and not constantly worry that because you haven’t immediately solved a problem, because you’ve failed and failed and failed, how do we get better at teaching people that is normal and fine and then maybe we don’t need to worry so much about how many years someone has done in the industry because if we can teach those skills in addition to the skill of knowing how to write individual lines of JavaScript code or knowing how to write tests or knowing how to deploy an application or whatever, then you have the same inherent value as a senior or more experienced person. After a few years on the job, just because we found a more effective way to teach in those skills directly, rather than hoping that they all develop independently by being in a painful situation year on year.

JANELLE:  We’ve got a few different problems here. One is with respect to defining things across this one dimensional spectrum and there being lots of other dimensions to what is experienced. We’ve also got this problem where you can have one person with two years’ experience that is capable in a way, from a problem solving perspective as somebody with 20 years’ experience is sometimes significantly better where you’ve got a huge lack of correlation because those things that you’re describing — these problems break down skills and things — are largely tacit knowledge and things that were not directly teaching at all.

Ultimately, we’ve got, from a hiring standpoint and from how much do I pay somebody standpoint, companies are trying to figure out a way to solve these problems. At the end of the day, we’ve never had any way to assess these skills that other than having a bunch of experienced people go and drill and trying to get a better feel for a person’s problem solving capabilities. But at the end of the day, we have these market problems that we need a way to solve somehow. Otherwise, this whole arbitrary ranking thing isn’t going to fundamentally go away unless we can solve the assessment problem, as well as the how do I transfer tacit knowledge into somebody else’s brain.

These things that you’re talking about are huge gaps in knowledge and we teach things in terms of follow the rules and follow best practices. A lot of that core knowledge that we’re just expecting people to come up with these new things through us most of us but what you generally see is people pick up the habits from the folks that they end up working around. If they’re working with somebody who’s religious about best practices but doesn’t have a lot of context of making tradeoff decisions or breaking down problems in those kind of things, we’re missing a lot of this core ability to just turn our tacit knowledge into explicit knowledge and make it teachable in our field so that we’ve got a huge expert-beginner problem in our industry.

TOM:  Yeah, definitely. I have been very pleasantly surprised by the stuff that’s happened over the last — I don’t know how many years — five years with boot camps. I didn’t know how to feel about boot camps initially. When they first started happening and I first started meeting graduates of boot camps, I didn’t know what to expect. On the face of it, the idea that you can take someone who has literally never written a line of code before and then in N weeks, make them a productive software developer, I wasn’t sure whether that was a thing or not. But now having met a bunch of those people, I’ve actually been incredibly impressed by how well the curricula of these boot camps are preparing people for the realities of software development. Particularly, drilling into them some of the skills and some of the craft of being a developer.

It’s not just about we’re just going to relentlessly drill you on APIs and on the syntax of programming but a lot of it is focused on ways of working. By that, at one end of the spectrum, agile in people to have stand ups and work in sprints and just like get a feel for what it is like to work in a small team of people who are all working on a thing together. At the other end of the spectrum is things like teaching people TDD from the beginning and presenting test driven development as just the way the software is written.

That approach to teaching people how to be developers is effectively leapfrogging years and years of struggle and failure until now of being an ordinary part and certainly was part of my thinking back to the 90s when I first started doing Ruby and I first learned about test-driven developments going into the 2000s and figuring out like that this is a thing and I need to figure out how to be good at it and it’s taken me like 15+ years to feel confident with those kind of things. Whereas, if I had had the same introductions to the world of writing software as people nowadays are having through boot camps and the like and not just boot camps but also online courses and all of the ways that you can learn to code now, a way better than they used to be and that’s partly because of this focus on, as you say, of previously tacit knowledge. Also, a hard won knowledge about not just how the computers work, how does computer programs work but also how do we work within these systems, how do we interact with a computer, how do we interact with other people in a team where we’re trying to build software.

I have a little bit of hope that trend can continue and that maybe now, it seems like a bunch of people have figured out how to teach that set of tacit knowledge and working practices to people who are new to the industry, can we project that line now into the future and say, maybe in another five years or 10 years, boot camps or online training courses or however people are professionalizing into the tech industry is also going to teach, somehow all of the other tacit knowledge of being bloody minded, being persistent and I didn’t mention this but also, I think a very important part is learning to work methodically, to be able to take the work at sustainable pace. Not thinking that it’s normal and expected to be jumping ahead and taking huge leaps. That’s something that I had to and I still learn every day.

Every time I try to do something, I am now getting better at quickly realizing that I’m trying to buy off too much and I need to dial it back, take a much larger number of much smaller steps, make sure that at every point I’m feeling safe. I’ve got to commit. My tests are passing. I don’t ever get into a situation where I type ‘git status’ and I find out that I’ve got like 30 files that I’ve changed and I can’t remember what I was doing. But all of that stuff is very hard to get beginners to do because they are de facto enthusiastic and because they’re new and because they haven’t been worn down to this little featureless, smooth surface of like, “I just know what working with a computer is going to be like.”

That enthusiasm that people bring to the job is incredibly powerful and valuable but it can also work against them because again, they don’t have this tacit knowledge. They don’t have this years of scars of like, “Every single time I’ve tried to do a big bang or try and drop a huge commit that change 5000 lines or whatever, a bad thing has happened.” I wonder whether we can keep pushing things in that direction so that gradually the boot camps and the other ways that people are learning stuff get better and better keep leveling up from that kind of TDD, Agile, good software development practices, how do we start turning out people to have all of these next level tacit skills. I don’t know if that’s possible but maybe it is and that would be fantastic.

JANELLE:  I’ve got a question for you. You’ve been developing software for a long time and seeing the industry go through a number of different changes. In developing software now, looks very different than it did 10 years ago or 20 years ago. Thinking about how software development itself has changed, how would you characterize your early experiences versus now? What are some of the major shifts you’ve seen in the industry, in terms of how that’s affected development?

TOM:  To be really honest about it, I think the biggest change that I’ve seen is just how people think about it as a job. It’s a little bit embarrassing to talk about really. When I first started working as a developer, again in the 90s, I’ve been writing software for fun for a long time before that. But when I got my first job as a developer, I feel at that time, I was very much playing into the stereotype of a programmer: programmers were the kind of people who just sit in the corner and either literally or figuratively, they’ve got the headphones on. They’ve just got a big black window with green text on it and it’s all scrolling by like in The Matrix and we don’t talk to those people. We know not to disturb them because they’ll be cranky if we do. You know, that whole kind of stereotype of basically what you have to put up with when you hire a developer.

I guess the flip side of that is also what you have to put up with when you’re working as a developer. You’re going to be working with a lot of people who are not smart enough to understand what it is that you’re doing and they’ll be constantly distracting you with their inane questions and you’ll just have to sigh and patiently deal with them. I hope that I wasn’t like that but it felt like that was the prevailing industry narrative of what it meant to be a developer.

Whereas now, I think that we’ve got tremendously better at that as an industry. I think we still have a long way to go in a lot of areas and there are loads of things that could be dramatically better again but comparing now the expectations of someone who is working as a developer and the expectations of other people who are working with the developer, to the expectations that those people had 10 or 15 or 20 years ago is just like a night and day difference in terms of dysfunction, I suppose. Certainly, the places that I have worked and I’ve been very fortunate to, more or less be able to say yes or no to various jobs. When I’ve seen there’s an organization that I might not want to work with, I just not have done that. It’s a massively privileged position but given that kind of selection bias, I’ve been very lucky to work with lots of people who are very grown up and very, very adult in their approach to doing the job of being a software developer and people who take a much more holistic view of it, just the very existence of this podcast is evidence of the fact that we now take much more seriously the idea of people being at the center of the work that we do as technologists.

This is not a technological answer to your question but I think that this is more significant than anything technological. We could talk for hours about trends in programming languages and things like that but ultimately, I think the important thing that’s changed is the way that we think about our roles as technologists and what kind of responsibility do you have. If you’re building algorithms to do things to people’s lives, then how do you do that in an ethical and responsible way.

Not everyone has got answer to that question but I think at several orders of magnitude, more people are at least thinking about that question than they used to. The biggest difference that I have seen — for a variety of reasons and some of them are just like raw economic factors — is now not really economically viable to be a fully evil employer or to be a fully evil employee. Those things, it feels like when you watch films in the 80s, they are about corporate greed and money and always be closing and stuff.

There was a narrative in the 80s of greed is good and the more unpleasant you can be, the faster you’re going to be able to climb the corporate ladder and be successful. I know that recent events don’t necessarily put a light to that notion but within the tech industry, I think we’ve got a lot better at it so we’ll say no. As an employer, you can’t just tell your developers that they have to work late every night and come in at the weekends because that’s unreasonable.

As a developer, you can’t expect everyone else in the business to automatically understand all of your technobabble and you can’t tell them to never interrupt you because you’re working with the pure thoughts stuff in your head and if anyone comes and pricks that bubble, then it’s all just going to evaporate. We’ve got a lot better at that. I think that is fundamentally, incredibly important in turning software development from a kind of actually quite nascent, poorly defined job, like a new industry that we didn’t really know how to make sustainable and how to make something that we can actually attract people into. I think we’re getting better at that and that’s really important to me and I think it’s really significant.

I can see the changes happening already in the industry, in terms of the basic diversity of people who are interested in it. We are now much better at including a much wider range of people and it’s much less likely, although still more likely than it should be, the people are just going to be turned off immediately from the whole notion of working as a developer because it so fundamentally unpleasant. I don’t think it is as unpleasant as it used to be. That being said, it could be a lot more pleasant and I’m super interested in ways that we can make that happen too.

SAM:  Yeah, a lot of work we could do in that area but the fact that we’re talking about it at all is, I take that as a sign of progress.

JANELLE:  I think the industry has changed so much and just looking at unpleasant versus pleasant, it’s again another one-dimensional spectrum to something that isn’t fundamentally one-dimensional. One of the huge things that’s fundamentally changed, since the dawn of the internet is we have this plethora of options and choices for everything and we’ve built abstraction on top of those abstraction on top of those abstraction.

Now, the software we built, as opposed to building something from scratch and having to figure out how to debug through our own code that we’re developing, now we’re in these days where 90% of our software is off the shelf parts. We get some funky error message on our screen through some magic code base that we’re using and we spend hours and hours of time debugging and trying to Google our way through stuff and then churn through our libraries and dependency chain stuff. You end up with stuff that breaks from upstream dependencies that causes all these problems downstream with integration.

Then suddenly, you’ve got this new family of problems of, “When I Google for something, all the examples and stuff online are all out of date so nothing actually works,” and Google-ability basically becomes a big part of usability of the software itself. Those dependencies that fundamentally changed in the skills that we need also changed with it and being able to learn things quickly in this rapidly changing world and being able to find what the library that you need or the example it’s going to work.

It seems to be more shifting toward ability to identify the information you need quickly and being able to track that down in addition to there’s this tacit knowledge side of development and then there’s this whole new family of learning skills that we need. I don’t even think those things are really being taught in boot camps at all.

SAM:  Well, maybe to some extent, they are but that to me harkens back to something that Tom was saying about memorizing the entire active record API, which I have not. I have been working in Rails for 10 years and I still don’t know all of the API of active record. But there was a time like I had the GW-BASIC manual with the computer that I had in my house when I was 14 and I could have sat down and memorized it end-to-end and know everything there was to know about that programming language. That is in no way possible for anything that we use now.

REIN:  One thing I was going to mention is that it’s a legitimate problem for languages to use a lot of symbols and operators and other symbols that those things can’t be Googled.

SAM:  Yeah, I was thinking about that. There’s the Sapir-Whorf Hypothesis that our language shapes the way that we think but there’s something else about how the tools that we use like Google and its complete disregard for punctuation changes the way we interact with our programming languages.

REIN:  I know that hypothesis is more or less been discredited but I think it’s probably hard to argue that our language shapes the way we communicate with other people, which is almost as important because it’s not just about having an idea. It’s about sharing ideas.

SAM:  Right, which is why you have to type ‘go lang’ anytime you want to search for anything from Google’s programming language.

JANELLE:  I’m wondering if the language itself just creates bias in this discussion. You all are in Ruby world, right?

SAM:  Uhm-mm.

JANELLE:  So that’s something that is fundamentally different. My background is Java so the challenge of having this proliferation of options for ways to do everything has its own bag of problems with it. I’m just wondering if just being in more of a bounded box with Ruby on Rails world, you have a lot more scope on options.

SAM:  I’m not sure I follow.

JANELLE:  With Ruby on Rails, you have a community around Ruby on Rails and sort of an isolated box of places to go to find answers for things with respect to Ruby and at least the Ruby world is smaller than the Java ecosystem, I would say. Is that an accurate –?

SAM:  That’s probably fair. It seems big to me but that’s my own myopia probably.

TOM:  I think if you went to JavaOne Conference or something like it with 10,000 people. It’s kind of scary.

JANELLE:  I mean it’s just a huge mess of problems related to dependency management in a lot of different spaces. Just a whole new class of problems that we have to figure out how to solve with respect to collaboration because all the complexity these days is falling into the wires and the dependencies and when things blow up from something like five levels deep abstraction-wise, having to figure out how all that stuff works when a lot of the code isn’t yours. I realized to some extent, we all have the same problems but at the same time, there’s this effect of the bigger the ecosystem is, the more choices and options there are. The faster the infrastructure itself is churning, the more painful all of these dependency management-type related issues are of trying to figure out how all this is supposed to work together.

SAM:  Right, and they suppose there’s a co-editorial effect of like, “I’ve selected these different packages to do what I want to do and nobody else has chosen that particular thing so I’m on my own integrating them.”

JANELLE:  Yeah and it’s much easier to get into that position, especially in JavaScript land, where everything is churning so insanely fast that it’s like, “Oh, that’s so last year.” Then the community just disappears on you, and then what do you do?

TOM:  I think you’re right and it ties back into an interesting point you made earlier about how the actual nature of the work is changing. I think that’s a really, really good point and I hadn’t really thought about it until you said it but it’s a smart way of thinking about what does the actual day-to-day work of writing software look like and what does it consist of? I think that necessarily has changed over the last, say 20 years.

As someone who works in a high-level language, if you are writing JavaScript or Ruby or Python or C# or whatever, I think that you do have a different experience of what are the challenges of writing software than someone 20 or 30 years ago, trying to write probably lower-level software or at least a less sophisticated computer or less sophisticated operating system. I think you’re right that a lot of the work the developers do nowadays could be classified as being… I don’t know what the right word is… I kind of want to say janitorial. That sounds bad but like you said, connecting the pipes together and making sure they’re correctly connected.

It’s actually not the same as writing lines of machine code and there’s no value judgement there about one or the other being more useful or more difficult even. They’re both difficult and they’re both useful in different ways but I think it’s true that at the moment, a lot of the work that people do probably is more to do with dealing with the complexity of systems. Having to employ these kind of system thinking skills to reason about something that’s complicated and trying to figure out, “I don’t know why it’s not doing the thing you want it to do,” or how to make it do a new thing that you want it to do.

Those are the problems that are present in the minds of most developers these days, I would say. Whereas I’m sure that there is some point in the past where people were more thinking of, “How do I get this frustratingly simple system to do anything?” That seems like less and less the kind of problems that we’re having to deal with now and it is more of this information overload, so many choices, how do I even pick a library to do this thing? I can see that there are 50 different ones and how am I meant to pick one? Do I just pick the one that’s got the most GitHub stars or do I pick the one a friend of mine said is really cool? Those are really, really difficult problems and there are a lot more kind of human scale because they’re just as much about society and our culture as an industry and the politics of open source software.

There are so many difficult things to think about and actually, I would hazard a guess that fewer of those problems are fundamentally technological. They’re all related to technology but I think the hard problems and the difficult end of the decisions that a developer who’s just getting into the industry will needs to figure out now are probably more to do with those kind of everything that you said, “What’s the community like for the language that you’re using? What’s the ecosystem like? What are the third party libraries like? What’s it like to use the tooling? How do you keep up with the fact that the tooling might change daily or weekly or monthly? What’s the new hotness and how do I make sure that my skills remain relevant?” Those are really challenging and difficult and it’s a full time job just dealing with all of that stuff and figuring out which of these Google results do I trust, which of these stack overflow are just seems correct. That is difficult work and it takes a lot of skill and judgment to be able to do that stuff effectively but that’s, more or less what the job is now.

REIN:  It’s interesting specifically with package managers. I think a lot about package managers because they’re biggest force multiplier for any language that wants to build a bigger, denser, more connected ecosystem or enable people to solve harder problems by building on previous work. The package managers is what enables that. It’s the most important part of any ecosystem.

The hard problem technically in package managers is the dependency graft, the transitive closure operation of get me all of the dependencies of the dependency of the dependency, etcetera, in a way that list them out so I can install them. That’s a hard problem but it’s also solved. The hard people problems are discovery, getting signals for the quality of the packages that we can use to determine which one is fit for our purpose or things like that and those are less solved.

SAM:  Are there ways that we can teach people how to, at least get better at solving them?

REIN:  I don’t know. Although I will say, step one is get a package manager, looking at you, [inaudible]. I love you. Get a package manager.

TOM:  I think it is difficult to teach these skills to people. I don’t know a better way of doing it than spending time with them. I would love to find a way to scale up this thing and figure out how do we teach the world how to be better at these things but because part of what we’re talking about here is to do with confidence and judgment and with more methodical/bloody minded approach to work. If I need to teach those skills to someone, I really need to spend some serious time with them. I need to sit down with them. Ideally in the same physical space so they can see my face and they can hear the tone of my voice and I can see how they’re feeling about what it is that they’re trying to do.

It sounds very touchy-feely but it’s fundamentally an emotional journey to develop these skills because it is all about how do I go from a position where I don’t know what good looks like. I don’t know what’s expected of me as a developer. I think there is just all this arcane magic out there in the world and I’m just going to need to memorize every single page of the spell book before I’m able to participate in this society. This isn’t an answer, this is just a question like how do you get those people to level up and feel more confident and feel less like the constant failure that they’re experiencing as part of they’re trying to do. A job as a developer is any reflection on them.

The fact that they’re failing, the fact that it’s difficult is intrinsic in what they’re trying to do. The systems are complex, the problems are hard and the only mechanism we have for approaching hard problems in complex systems is to persistently poke at them and try to pick them apart and try to allow them to go through periods of organic growth and then periods of pruning back where we figure out like this software has developed over the course of the last six months and we bolted on a bunch of features. Now, it’s time to step back from it and try and figure out is there a better underlying domain model here? How do we use all of the mistakes we’ve made over the last six months to help us to refine our understanding of the problem we were trying to solve?

If I could send some information back in time, what would I tell myself six months ago that would mean I didn’t make a bunch of these mistakes and how do I re-organize and re-design the software so that my construction, those kind of mistakes can’t be made. All of those skills, I don’t know how to teach them other than just being patient with people and telling them upfront that I want them to get better at them. I think there’s a problem with people who are new to software development don’t really know what is expected of them. They know they want to get better but there are not very many high-fidelity, high trust sources of information that are telling them what that means and how to do it.

Whenever I find myself in that mentorship position, I’m always trying to begin by just being as upfront as possible with people and saying, “I’m going to lay some stuff out for you. None of this is intended as an implied criticism of you.” This is what I tell everyone. Everyone that I sit down with and try and help them to get better as a developer, I say to them, “However bloody minded and methodical you are right now, you need to be more so. However, patient you are right now, you need to get more patient. These are the skills you need to build up. You need to slightly set aside the notion that this job is all about just memorizing APIs or becoming super good at one particular programming language.”

All of those craft level skills of just knowing your tools better are valuable and that’s something that does differentiate more experienced programmers from less experienced ones. Obviously, if you know all of the Git commands and you know exactly how to reorder commit so you know how to pull that one commit out or you know how to split that one commit into two or you know how to do an interactive rebase so it will automatically runs your tests for every commit or whatever, that is going to save you a bit of time. You will get 10% or 15% faster at your job if you’re able to internalize all of that muscle memory of how do I use Git, how do I use Vim, how do I write a test, what is the API of this thing look like?

Those are valuable skills but they are not as valuable as those of meta-cognitive skills of how do I approach a problem. How do I not just get defeated by the experience of trying to write software? For me, the best way to communicate that to someone is just to sit with them and talk to them and work through a problem together and always be reflecting back to them and saying, “I feel a little bit frustrated now. I was hoping that that line of code we wrote was going to make the test pass but it didn’t make the test pass. Why do you think that is?”

Then, they’ll be looking at the error message and then they’ll be confused and they’ll say, “I don’t know,” and they’ll look to me and expect me to have the answer. I’d say, “I don’t know either. Let’s look closer at the error message.” Or, “Let’s go and reread the test.” Or, “Let’s go and look at that line of code that we write.” Try to keep pushing people towards that realization that all you got to do is just grinding away at it. I don’t want to make it sound bad because this is the stuff that I love. I could do this all day every day. I absolutely love this process of grinding and leveling up and playing this never-ending, open worlds, RPG of trying to get better as a developer. I find it fantastically rewarding. I love spending hours and hours trying to get that one ridiculous test to finally pass. It’s very satisfying but actually communicating why it’s satisfying and communicating but that is the thing that you should be trying to do is in itself like a big job to someone who is new in the industry.

As far as they’re concerned, they have a completely legitimate motivation which is they want to be good, they’ve got an app they want to make or they’ve got a job that they want to have or they’ve got a salary that they are aspiring to earning and they just want to know how do I get there? How do I build that app? How do I progress as fast as possible? How do I absorb the skills of more experienced people? It’s a real challenge to steer those people in the right direction because it’s the opposite of what they want to hear. They want to be told like a listicle, “Here are the seven tips to being an awesome developer and like number five will shock you.”

I don’t think there is that list of things other than each of the things in my own personal list. That’s kind of boring and don’t sound fun because they’re all about —

SAM:  Refactoring.

TOM:  Yeah, like patiently refactoring and methodically progressing through the problem and always stopping to reflect on your own understanding of what you’re doing and what is the story that you were trying to deliver here? What was the thing that you originally started researching? Have you gone down the rabbit hole? That stuff is actually quite hard to teach and the only mechanism for communicating now, I think is to have this honest dialogue about it and say, “I find this difficult,” or, “I find this stressful,” or, “I feel defeated in this situation but let’s go get a cup of coffee. Let’s take five minutes away from the computer. Let’s talk about what we watched on Netflix last night and then let’s come back to it and take another run and I promise you, we’ll have cracked this by the end of the day.”

What seems to get people closer to being able to do it independently is to see someone else who they think knows the secret. It’s kind of tell them that there isn’t a secret and they can do exactly the same thing as you if they’re prepared to just grit their teeth and power through it.

REIN:  Can I suggest that there’s one other thing that I think is related that as someone who has had great mentors in my career, I think for me, aside from that the most useful thing which is having someone tell you what’s next. As someone who’s trying to learn programming, there is this giant undifferentiated mass of stuff I might want to learn. There are hundreds of programming languages. There are thousands of books, millions of blog posts, hundreds of different things. There’s so much to learn. In any given point in your career, a lot of those things aren’t going to be useful for you or they’re not the right thing for you to focus on.

SAM:  — In your point, I can learn 0% of the things that are out there so which 0% should I pay attention?

REIN:  Yeah, and just having someone tell you, “Given where you are in your career, here are some things that will help you progress from here. Here are the things that should be next for you,” and they don’t have to be right but they’re better. I mentioned this last week, they’re better than just guessing what you could learn next. It’s better than selecting that thing by chance.

JANELLE:  Maybe there’s something that could be done. I think, to your point Rein that there’s this custom problem of that everybody is on their own path and has a different set of experiences and mentors and things that they’ve learned in gaps that they still have: bad habits or whatever. Maybe, if we could come up with a way to understand where people’s gaps are in the moment and recommend what’s next thing. Again, maybe breaking down that problem of how do you get better, what does better even mean and how do we assess where somebody is at, well enough just so that we can answer that what’s next question.

REIN:  Yeah, I was going to say think about the level of connection and almost, I guess I can say intimacy that you need with a mentor to really understand where you are, what your goals are, how your learning process works to really be able to give you the best advice on, on how to proceed. A good mentor is a very important and well-connected. It’s a close part of your relationship to learning. We talked about senior developers and how they should be mentors and I don’t think people understand necessarily what that means.

TOM:  Yeah and I think there’s a risk that the people think that it is just about teaching the more obvious skills is just about I’m going to pair with you and I’m going to tell you and there’s a method to enumerable module that will do this for. You don’t need to write a loop there like I’ve memorized the thing —

SAM:  Then I’m going to teach you. This one weird Vim tracking.

TOM:  Right. Again, that stuff is cool and it’s fun and it’s useful but it’s not the essential bit of what we’re talking about. I mean the conversation that you just had that reminds me of my personal hobby horses which is this idea of trying to help people to focus more on what I consider to be the fundamentals. I’m not going to disappear down the rabbit hole and talk about computer science because that’s not what I mean by fundamental. I just mean something like I’ve seen a lot of people struggle with learning React and I think that’s unfortunate because React is fundamentally a simple idea.

The actual implementation of it is increasingly complicated but I don’t think there’s anything in that a beginner developer can’t quite easily grasp. It’s just goes back to this problem of ecosystems and incidental complexity of if you sit down and try to learn React, you will find yourself also trying to simultaneously learn several other things at the same time. You’ll be trying to figure out what is ES6 and what is JSX and potentially things like what’s a Promise is or what is the DOM.

There are so many things that people try to learn simultaneously and I think this is related to the issue of what do people learn next is kind of where do you start. How do you find a beginning thread for someone to start walking along and figuring out what’s the first thing that I can learn? What’s the first thing that I can understand? Then once they’ve understood — this is opinionated — what is the most important fundamental idea that you need to grasp to be able to make progress with this technology because that something that a beginner is fundamentally unable to determine from themselves. From outside, they’ve got zero basis for judging like which of these 10 things that all seem to be piled together into these tutorial are actually important and which ones are things that I could ignore.

As part of mentoring someone, I feel like one of the things I’m constantly doing is giving them feedback on what aspects of what they’re trying to learn are actually fundamental and which ones are incidental. That might be something as simple as someone’s asking about like how do I write this test and might be what they’re looking for is some kind of biblical revelation about a magical matcher in RSpec that will do all of this for you and sometimes they get frustrated with me because I categorically refused to tell them about those things. I am much more likely to say, “Let’s not even install RSpec. Let’s just write a file of Ruby code where every time we want to test something, we’ll just say ‘raise unless foo.bar=42.'”

And they’re like, “But what about the testing framework?” And I’m like, “We’ll get to that later. That is a thing that will level you up. Once you’ve got to level 10, learning RSpec will take you to level 11 but we need to get you from zero to 10 first,” and I know that’s sometimes can be frustrating for people because usually people do just want to learn the cool things. For me, to be sitting down with someone and saying, “I’m going to teach you about React but actually, we’re not going to get to use Babel and ES6 and JSX. I’m just going to show you this Bare Bones of how do we use React just with ES5 and we’re not going to use JSX and it’s going to be so Bare Bones. We’re just going to concentrate on these two methods that are part of the React and React DOM APIs.”

Sometimes, they’re a bit like, “This seems boring and not the thing that I wanted to learn.” I feel like I have to help people to, at least I have to try to persuade them that are like, “Just trust me. This might not feel like the cool thing that you wanted to learn but I have some degree of faith that if we can get through this fundamental stuff, what that’s going to give you is enough of a mental model to be able to start making your own decisions about what’s next.”

If all you’re doing is just constantly relying on other people to tell you what’s interesting on what’s worth learning, you’re never going to be independent. You’re always just going to be at the mercy of how convincing a blog post or how entertaining a conference talk you just saw or read. Whereas what I want people to do is to feel like they have technological self-determination where they’re like, “I’ve got the basics of this down. Now, I think what I would really like is to not have the right react.create element all over the place,” and at that moment, if they learn that JSX is a thing, they can be like, “Perfect. That’s the solution. That frustration I was feeling, now it’s time for me to go and learn that thing and that’s going to be a bit of incidental complexity but now I understand why I should learn it and what the utility of it is,” and like trying to bootstrap that process in people’s minds.

Another hobbyhorse I’ve got is like people feeling overwhelmed with object-oriented programming and how many potentially conflicting pieces of advice there are out there about objects and how to do object-oriented design all over that thing. Whenever I’m trying to help people with OO stuff, I’m always trying to focus in on one idea or two ideas and just say, “Let’s start with a very simple premise here and then we can gradually work our way out through all of this advice that’s in books and blog posts. You can gradually learn to find your own path through that advice because you get it fundamentally from the beginning,” and I think that’s a thing that’s very difficult for anyone to do without someone else to, at least who they trust to like find them a way in so they can begin that journey for themselves and have enough support from someone else to be able to keep nudging them in the right direction, even if you’re not spoon-feeding them the answers at every stage.

SAM:  I think you’ve just touched on another one of the fundamental skills that in my mind differentiates earlier career from people who are more experienced. This is just the ability to form a mental model to be able to look at an undifferentiated mass of stuff and figure out what categories of things are in there, what buckets of functionality are in there and how can I start separating those things out. Just looking back at my own career, certainly for the past six or seven years, most of what I’ve learned has been essentially how to be more disciplined about no ‘this goes here and that goes there and never the twain shall meet.’ Maybe there’s a way that we can help people figure out that ability to form a mental model. It’s a thing you need to figure out soon and maybe help them practice it a bit.

REIN:  I guess for me, mentoring falls into two buckets. One is there are, I think general global problem solving tools and techniques that can be taught and the other has to be finding out where they are and what they want to learn, where they want to go, how they learn best and coming up with a artisanal hand-crafted plan to get them there.

SAM:  There is one announcement that we do need to make on the show, which is that we have a new idea for a thing that we would like to do with you, our listeners and our community, which is we love the movement and the ideas that are coming out of this show and we love the messages that we’re sending but there are only 52 weeks in a year and we can’t podcast every day, although obviously we wish we could, we do have jobs.

We want to open up opportunities for anybody to be able to submit blog posts about what it means to be greater than code. If you have experiences or stories or anything that sends a positive message to the community or help somebody learned something useful, we know that some of you have your own blogs. In fact, I do not. I shut mine down years ago but many people don’t. Maybe you think you don’t have enough content to justify your own blog. That certainly what keeps me from starting mine up again. We want to give everybody a medium where you can share one-off ideas and maybe generate some discussion around them. If you have something you’d like to write a blog post about, please get in touch with us.

REIN:  I also want to mention that you get access to an excellent editor which if anyone has tried to write a book, can tell you having a good editor is very important and really makes the process much more feasible.

SAM:  Yeah. We have more stuff that we would like to talk about but unfortunately, Janelle has a hard stop today. We’re going to take a moment and Janelle, if you have any reflections that you’d like to share about today’s show or any closing thoughts before you drop out, now is your chance.

JANELLE:  Probably the biggest thing that stuck with me that Tom said was just about looking at things as multi-dimensional problems as opposed to one dimension. I think that applies to so many different situations where we boiled down the world into this one-dimensional spectrum, whether it’s junior or senior versus how much of something there is. It doesn’t seemed to matter what problems. We have a tendency to look at the world in these simplified dimensions and almost everything we deal within software is a multi-dimensional problem and multi-dimensional tradeoffs.

While walking away, I think probably the one thing I’m going to ask myself is when I’m just recognizing that if I’m ever boiling something down into a single dimension to just take a step back and think about, “Are there actually multiple dimensions to this that I’m ignoring and blind to because I’m boiling down the world that way?” I think that’s the biggest thing I’m going to start thinking about differently now. Thank you, Tom.

TOM:  Thank you.

SAM:  All right. Tom, you had a bunch of ideas that you shared with us. One of them had to do with your experiences coming out of helping Sandi Metz as teacher, practical OO design in Ruby classes. Do you want to talk about that a little bit?

TOM:  Sure. Last year, I co-author that class with Sandi. She does a lot of teaching. Some of the teaching, she needs other people in the room to help out because of the number of people there. I don’t want to misrepresent that. It’s still basically Sandi teaching people but me being in the room and being able to help out with people and answer questions and stuff was really fun. It’s great to just spend time hanging out with Sandi and all of the other great co-instructors that worked with her.

But it’s also useful to keep re-exposing myself to either beginners or people who are trying to get better at various ideas. It’s a great way to have a different conversation with people than you would normally have as part of your day to day work because it’s quite often the case that when you’re working with some other developers trying to solve a problem and you are also talking about it in kind of developer-speak and you already know that the main language and you know the problem space and you’re going deep on all of these ideas, you don’t necessarily get a chance to question your fundamental assumptions. Going back to this point I made about thinking about the fundamentals of what you’re doing.

One of the things that I go out of teaching those classes with Sandi was just giving myself the chance to think a bit more clearly and a bit more separately about object-oriented design because something that is so implicit in a lot of the work that programmers do is trying to plug objects together and trying to build systems that are easy to change and have a low-cost of change and have a low chance of containing bugs and stuff like that. But it’s nice to have the opportunity to talk to people who don’t already know how all of that stuff fits together and they have lots of questions about what the point of this stuff is and there’s so much advice out there about how to do object-oriented design and how am I supposed to learn all of it and synthesize all of it. I found it very helpful to have those conversations.

It’s, I guess a bit of a cliché this thing about you don’t really understand something until you told it to somebody else but it’s true every time. Every time I do teaching or I run a training course or I’m mentoring someone, I feel like it’s such a massive learning experience. There’s something about a particular groups of people who are interested in getting Sandi to come teach them about OO and just a really interesting audience to teach and not an audience that I would be able to attract on my own. One of the great things about that is spending time with a room of really motivated people, really smart people, people who really care about their work and they’re doing the best thing they can think of to level up and to learn more about stuff. They’re the most self-motivated and interested learners you could possibly hope for and being able to have conversations with those people about what are objects, why do we have them, what’s the point of them. It was a really eye-opening experience for me, for someone who’s been doing object-oriented programming among others.

For what I feels like a very long time, I was a Java programmer in the 90s and then I became a Ruby programmer in the 00s. Although I do a bunch of programming in other languages and Ruby in particular, makes it very easy to not think about objects some of the time. It’s just as easy to write a functional style program and not even define any classes or whatever and doing most of closure style maps and lists and stuff.

I still work with objects a lot of the languages I use. I have got some notion of objects even when I went through academic periods of my life. In the mid-2000s, I was doing a lot of programming in OCaml, which is a functional language but the ‘O’ in OCaml stands for ‘objective’ but because it’s got objects in it. It feels like one of the unifying themes of the last couple of decades of my programming career has been thinking about how to work effectively with objects. I’m trying to figure out how to distill some of the thoughts I had down into a way that might be useful to people. I supposed that the simple thing has become increasingly clear to me over the last decade but it was only really last year to co-teaching with Sandi a couple times that it gave me the time and the space and the opportunity to have conversations that really brought it into sharp focus for me.

There’s only really one important idea in object-oriented programming which is — I want to try and explain it without using any buzz words — the idea that you can call a method on something but you don’t know which implementation of the method is going to be triggered by that call.

[inaudible] any way that would be saying that the one important feature of OO is you get subtype polymorphism. This idea that you’ve got an object, you know something about the type of it. I’m not talking about static types here. I’m just saying that you know that it is an instance of some subclass of a thing. It matches some interface or whatever, even if you don’t have static type. If you’re just thinking about duck typing, I know that this object implements this method or I know that it will respond to this message or whatever but the fact that you’re able to program — guess what one of the things that Sandi would say is — to a role. You’re not assuming anything about the actual concrete implementation of that thing.

That is what allows you to segregate knowledge in your program and that’s the most important thing. The fact that you’re able to control which bits of your program know stuff, rather than just saying, every line of code, every class, every method, every bit of this software project has got maximal knowledge of every other part. That’s when it becomes impossible to change and maintain your software. It’s this very gradual dawning realization for me that although when I learned about OO, I was taught like a bunch of different principles.

For example, cost is a very important and inheritance is very important and the idea of having private members and an object being an encapsulation mechanism for hiding information. I think all of those things, they’re all things but I don’t think any of them is necessary or sufficient to have the benefits of OO. This is the thing, if I was sitting down with someone, I haven’t been in the situation but if I was sat down with someone who was saying, “I’ve never used an object-oriented programming language before and I want to start learning one. Can you give me a summary of what the point of this is?”

I think I would probably begin by talking about this, by saying, “The point of an object is a piece of data that carries operations around with it but because we identify operations by names,” because languages have a concept of binding and because either through message passing or some other [inaudible] or mechanism or whatever, we have some way — I’ll probably find a more friendly way of explaining this — of dereferencing names into operations. We are able to refer to operations on objects by their name and that means, we don’t know what implementation of that operation we’re actually going to get.

That means that something in a very distant part of your program can make a decision about what thing it’s going to make. There’s going to be a factory somewhere or there’s going to be a method that’s going to say, “I’m going to instantiate the foo class rather than the bar class or maybe there aren’t classes at all.” Maybe you’re just manufacturing objects and you’re creating a completely new implementation of this operation for every single object that you instantiate and then at that point, those objects become data and they flow through your program. Those values travel around your program and they bring that knowledge with them and the bits of your program that they reach, don’t know anything about. All they know is there’s an operation called ‘foo’ and they can activate the operation. They can execute it and whether there’s one underlying implementation of the operation or if there are a million underlying implementations is completely unknowable to the part of the program that is saying it wants operations to happen.

I think that’s the fundamental thing. That is the strength of object-oriented programming. There are a lot of problems with those as well and people are quick to complain about it and I sympathize with those complaints. But I think unless you’re aware of this idea of values carrying operations with them and you not having to know what that operation is apart from just knowing that there is an operation called foo and it’s going to be attached to that value, that’s what lets you segregate the knowledge in your program in a way that makes it more likely that you’re going to be able to change and maintain it.

To me, that’s the underlying theme of a lot of the stuff that Sandi teaches, what she wrote in her book and what she says in her talks. Also for me, it provides a bit of a unifying theme for all of the advice that I read about OOPs, things like the solid principles and various other blog posts and conference talks. Now, when I go back and reread those things and rewatch them and try and look at them through the lens of how is this advice a consequence of the importance of this subtype polymorphism by dynamic dispatch in OO. It also makes sense to me in that way.

I don’t think I would have got quite as much clarity on that without having an opportunity to talk to lots of individual people who were curious and smart and they had questions about how does this work, why is it important, why do we want to write programs like this. Fundamentally, why do we want to attach operations to values? Why is that a thing? Why can’t we just have data and then have operations that inspect the data and make decisions at the point of views, as opposed to this thing where you can make a decision that the value is created and only much later on, does that decision have an effect when you actually call the operation called foo and finessing that conversation with individual people who are curious and interested to understand it better, like massively improved and [inaudible] my own understanding. That’s very valuable.

REIN:  The way that I’ve said this for a while, which is quite a bit less nuanced is that object-oriented programming was invented because we wanted to write programs by having things talk to each other and more importantly, tell each other what to do.

SAM:  Yeah. It seems to me as you were talking, it really helped to clarify this idea in my head that there are several blind alleys in the way that we teach OOP. I think the first one that many people like I think the first level of unlearning the bad things that we learned about OOP that many people encounter is the idea of inheritance being important. I think at some point, people realized that it’s not necessarily inheritance that matters. Just the idea that you may have several different types of a thing and they all have the same interface.

But then, we talked about encapsulation and data hiding and I feel that even the way those are presented, an object to protect access to its own instant variables, we think that the contents of those variables is specific values or what is important where as I see it now, what really is important is the idea of hiding where we make decisions about those things so that if you are looking at a number and if you’re deciding that if it’s 42, it means one thing and if it’s 17, it means something else. That information about that knowledge about what those things mean should live in that object or they get scattered throughout your system and then everything depends on everything else.

REIN:  It’s interesting that this has been said in a variety of different ways, by a variety of different people, including Alan Kay when he originally came up with the idea which is that the thing of importance, the thing that you should be focusing on in an object-oriented system is the messages and not so much of the objects.

SAM:  Right.

TOM:  That’s the punch line of all of this, I suppose. Nothing that I just said is new information. We’ve understood this for decades. Again, it’s kind of going back to the previous discussion about incidental complexity and how hard it is — no matter how experienced you are and how much time you spend with the thing — to retain that focus on what is the thing that’s actually really important? As opposed to all of the other stuff around it or all of the other ideas that stuck on to the fundamental idea or all of the advice you’ve heard and how can you use threads that you battled through of people saying, “That thing is awesome,” and another person is saying that it sucks.

It’s very difficult to keep your head straight and to keep focusing on what is fundamentally the important thing here. What is the guiding principle that I’m using to make decisions? Am I trying to memorize a thousand different slogans that I’ve read in a thousand different books and heard in conference talks? Or am I just trying to cultivate this very clear and straightforward mental model of why something is important and use that as my guiding principle to make all of those decisions for myself? Whether that is understanding in full detail or at least in some detail, what’s the underlying model of something like Git?

This is another example of a thing that if you try to get good at using Git, just by memorizing every single command, it will probably gradually just zap the life out of you because fundamentally, the way you make progress in that problem of I’ve learned like three commands that allow me to do some basic stuff but I keep finding myself in these situations where I’m getting a weird error or it says that it’s not happy or it says my head has become detached or something and I don’t know what that means. It’s not until you sit down or someone sits down with you and draws you some pictures of, “Here’s a miracle tree,” or, “Here’s some notion of we got this content addressable database.”

We’ve got a bunch of things that we put into it and they’ve just got references to each other and we gradually building up this depend-only data structure and these things that we call branches are just like sticky notes that stuck on like individual commits and that’s what allows you to then kick starting judgement. You can’t have an opinion about what the right way to use Git is, until you have that mental model and then you can start using that mental model as a basis for making informed decisions about whether something is a good or a bad idea.

I think there’s an equivalent of that in the world of OO programming or functional programming or any kind of software development work where the fundamental thing is figuring out what’s the principle that I believe in here. I don’t mean to imply that what all of that stuff I just said is objectively true. This all is just my opinion. I have found that for everything that I want to be good at, or I want to teach other people about, I need to crystallize and clarify what I think the organizing principle is there and that what allows me to then, when someone shows me a page of code and asked me what I think of it, I’m not just like shooting from the hip with some completely irrational gut reaction. It’s more that I’m able to go back and reinspect like what are my principles? What are the things I care about? What do I think is the foundational model here that allows me to make judgments and make decisions? Then I can give them so meaningful and actionable feedback where I say not just like, “I don’t like the way you’ve invented that function definition,” or, “I don’t like the tense that you used in the name of that local variable.”

Maybe I do think those things but I can wind it back to some kind of, why do I think that’s a bad name for the local variable. Well, let’s try using in a sentence or let’s imagine that local variable in a different context or let’s imagine someone coming in looking at this code and not understanding what that thing is used for and they’re just looking at one line. Being able to provide that context in that case, in that example, the foundational principle is we’re writing code for other people to read so that’s why names are important. The computer doesn’t care but ultimately, this thing that you’re writing is going to be read by someone in a week or a month who is tired and angry and frustrated and by the way is probably going to be you so let’s start from a position of maximum empathy for that poor person and try and figure out what decisions can we make now to make their life easier then.

Having those kind of principles to go by and iteratively refining those principles is a thing that I think is really important and a big part of why I get so much enjoyment at teaching and mentoring and coaching people is the purely selfish desire to keep tightening the screws on all of those things that I think are true. The more I can believe in them, the more I’m able to use them to drive all of these other decisions. When people ask me for advice, I’m always just going back to the same of like, “You’ve asked me a question about OO design. I’m just going to try and answer it just based on this one thing that I think is important.”

REIN:  This actually goes all the way back for me to when we’re talking about teaching and mentoring and I mentioned that there are universal skills and then there are the specific things that are useful in this situation. The most important universal skill for me, by far is being able to use system models, be able to build a mental models of the thing you’re trying to understand, to test it against the thing you’re trying to understand, to validate it, to use it for understanding and to make predictions and learning. If there’s one thing that I, as a mentor try to impart on people, it’s how to use mental models.

SAM:  And not just about your software but about the processes in your own head or the interpersonal things that happen on a team. You need to be able to use those skills at that level as well.

TOM:  Yes, very important to be able to have an accurate model of other people’s mental state. This is a thing that most children at some point in the first few years of their life, they go from being a completely oblivious entity that doesn’t really have any theory of mind and most children go through a process of gradually developing that theory of mind and then beginning to understand these other blobs of meat around you actually have their own internal life and their own internal states and I think continuing to level up in that area.

When you’re working in a company with five or 10 or 50 or 1000 other people, on some level, you are running a little simulation of everyone else’s what do they know, what do they believe, how are they feeling right now and using that to guide your interactions and your discussions and like, “I’m going to review this pull request and I’m going to try and give this person some feedback but I also know that having a hard time at the moment or I know that they’ve only just learned this thing,” if you don’t have that mental model of what is going on in other people’s minds, then you don’t stand a chance of being able to be constructive and consider in your interactions with them because you’re just going to be treating them as the median human, which no one is.

Everyone reacts differently. Everyone has different ebbs and flows of their moods and what they’re worried about and what their energy level is and what they feel confident about. It’s a lot of work. It difficult to keep that whole spreadsheet and constantly maintained in your head but it’s just as important a skill as having mental models of OO or of Git or of testing or whatever. That’s the depressing truth, I think about being really good at software development is you get me to get really good at that meta-cognitive skill of having very high-fidelity mental models of all the things and that is a lot of work.

SAM:  Although looking at it a different way, to some extent being able to maintain mental models of what’s happening inside of other people’s head is what we were evolved to do. Some of what I’ve done in my own career is just collect ways of mapping abstract software problems onto pretending that I’m thinking about people so I can use those parts of my brain that have evolved to do that.

TOM:  That’s a good mind hack.

REIN:  I just had realization. You know how a lot of people say that object-oriented programming is good because it’s such a close mapping onto how the real world is and then cats are animals and cars are vehicles and that’s how the world is and that’s how classes are. That’s good. I think they’re right but I think they’re right for the wrong reason. I think the reason that object-oriented programming does in some ways model real life is that object-oriented programming is basically what I said before, which is trying to get other people to do things without knowing anything about how they’re feeling or what state they’re in or how they’ll respond to your request. The only thing you can do is say, “I want this. Can you do that?” and then sending that message.

TOM:  Wow. That’s a good link.

REIN:  Nailed it.

[Laughter]

SAM:  Well, before we move on, I’d like to take a moment to remind everybody that this is a 100% listener supported show. The way that you can support us, if you like what we’re doing and you would like us to do more of it is to go find us at Patreon.com/GreaterThanCode and give us the money. Any contribution at any level will get you access to our wonderful Slack community which is full of dozens upon dozens of wonderful people with interesting things to say to one another and who are interested in providing emotional support, which is just really great.

One of those people who has joined us recently is Kira McLean. Kira on Twitter describes herself as a Canadian software developer from the East Coast. She loves travelling and politics and she says, “I’m doing what I can to spread reason and quickly realizing how screwed we are.” On that wonderful, cheerful note, thank you Kira for supporting us and welcome to our community.

REIN:  Reflection segue. I am going to get back on my horse and recommend Gerald Weinberg’s book on system models, An Introduction to General Systems Thinking. It is the book that really led my awakening, if I’m going to use a slightly suspicious way of describing it, in terms of understanding the world through my mental models of the things I interact with. It was hugely influential in my own growth as a software developer and as a person so I’m going to give it a plug.

SAM:  Cool. One of the things that I’m really going to take away from this conversation is just a renewed appreciation for the importance of the skill of meta-cognition. It seems like you can’t get better at any of the other things that we’ve talked about without being able to examine your own internal processes and see and evaluate what you’ve been doing and how you might be doing those things better. Thank you, Tom for making me think about that for so very long today.

TOM:  Oh, you’re very welcome. I guess that feeds into my reflection. I have two reflection, sorry. One of them was that I found very interesting Janelle’s point about how the work has changed of being a developer and that point about how now is more about learning to cope with the complexity and learning to deal with complex systems and wiring things together and understanding how the big picture fits together. That’s something I’m going to go and think about some more.

Your point, Sam, it makes me think of — this is an obvious recommendation — Nonviolent Communication book by Marshall Rosenberg is great for this automatic cognition issue. It’s a book all about how to communicate effectively with someone but my interpretation of the content of that book would be that it’s all about how to build and communicate about the underlying reasons why you are saying or thinking or feeling a thing. It’s all about improving your own mental model of your own self and also improving your mental model of other people with whom you might be disagreeing, by finding a way to communicate about you tell me what’s in your head and I’ll try and tell you what’s in my head and maybe we’ll figure out why we’re disagreeing or maybe we don’t disagree and we’re just both reacting to something external to the two of us. I found reading that book really helped me to refine that picture I have in my head of my own behavior and the reason why I do things and it helps me to understand why other people do things as well. I think that’s a nice companion to Rein’s recommendation.

SAM:  Thank you for bearing with us through the end of an epic Greater Than Code and we love you all and we’ll talk to you next week