Today's episode is the second of a three-part Pragmatic Folks series and we are joined again by Dave Thomas and Andy Hunt, authors of The Pragmatic Programmer, to talk more in-depth about how you are in control of your own destiny even when it seems like you’re not. We discuss the tendency for some programmers to complain about the organizations they work for but their lack of proactivity around addressing these issues. Sometimes it is easier to complain than to actually do the difficult thing of either trying to change the company or to look for a company that is a better cultural fit. And no one can decide for you which route is best – you are the only one who can determine how the narrative goes from there. We also talk about the need for developers to keep learning new skills and languages, and for greater awareness around the ethical and social implications of new software technologies. Be sure to tune in for this next part!
Key Points from This Episode:
Transcript for Episode 257. Pragmatic Folks Part 2 - Own Your Environment
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast in fantabulous Chelsea, Manhattan. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.8] DA: Dave Anderson.
[0:00:10.3] MN: Today, it is part two of the pragmatic folks series. Own your environment.
[0:00:16.0] DA: Yeah, we’ve got our special guest, our very special guest back again, Andy Hunt and Dave Thomas and we’ll be resuming our discussion that we had from part one of our series and talking more in depth about how you are in control of your own destiny even when it seems like you’re not.
[0:00:35.3] MN: Right, whether it’s an introspectively on getting better in your craft or the kind of information and data developers now have and that environment is for you to wield and to use responsibly.
[0:00:52.1] DA: Yeah, it was a fun discussion. I hope you enjoy it. What about you, Dave? Do you have a favorite technique or a thing that you’ve ever visited in the book or something?
[0:01:00.3] DT: Let me think, there are a couple of things that I’m very pleased with in the book that are actually brand new tips and those are the first and the last tips in the book. The first tip came about because I quite often, both of us quite often go to conferences and people will say things like, “Well, that’s all very well but I can’t do that because my company…”
When you’re sitting past that, you realize what they’re really saying is, I can’t be bothered to make my life the way it should be. I can’t be bothered to try and change my company or I can’t be bothered to change to a different company.
I’ll just sit here and I’ll accept the fact that I’m doing second rate work and not liking it and I really look forward to going home back at the end of the day. It’s a miserable way to lead a life.
[0:01:55.0] DA: I guess my question, would you have that person make the change in the organization or look for another organization that follows their idea. What do you think is the better option?
[0:02:06.5] AH: That’s not our choice, right? That’s up to the individual. Martin Fowler has a famous quote saying, change your organization or change your organization. This is a very important theme that goes all the way through the book is that, at the end of the day, it is up to you, no one is going to tell you, yes, you should go quit your job or no, you should go charging into the CEOs office all full of fire and brimstone or what have you.
Whatever path you take, it’s on you, it’s your responsibility, it’s your power, it’s your freedom to do what you will with it but that’s on you. No one’s going to tell you what to do.
[0:02:46.3] DA: That really resonates with me especially since I was like early in my career I feel like I was in that situation and then I had that realization where hey, you know, if I want things to change then it has to come from me and you know, when you start digging into those ideas and bettering the world around you then it’s just very rewarding.
[0:03:06.3] DT: There’s nothing sadder than to be lying on our death bed thinking, if only. You know? It’s so pervasive, you know? You say to people, well, what new programming language have you learned? Well, we always use Java in our company. That’s not the question I asked, right? We are, as a profession, the probably the most fast changing environment that has ever existed and if we are to stay afloat as individuals, we have no option but to invest in ourselves and continue to learn new things and make ourselves valuable, basically.
That is a personal responsibility, it’s your life, you make those choices. If your company isn’t going to train you in the latest greatest, then okay, big deal, you’ve got time to do that, go and do it, you know? One less game of Half-Life, one more bit of reading.
[0:04:06.8] AH: There’s a really important kind of side comment there is a Jones about this all the time. We often as in our profession, we often over identify with whatever technology we happen to be using at the time. You’ll see folks who come up and identify themselves and say I’m a Java programmer. I’m a ski developer. I’m a whatever, JavaScript. No, you’re not, you’re a problem solver.
You’re using whatever, you’re u sing you know, the latest, greatest JavaScript framework, right? It’s Wednesday, they’ve been 34 new JavaScript frameworks out today, right? You’re not that. That’s one of the tools you use. Java is one of the tools you use. Elixir’s one of the tools you use. Rust, whatever it might be and you know, next week, five years from now, hopefully you’ll be using something completely different.
That’s not the important part. The important part is, you’re a problem solver and you know different paradigms, different ways of asking questions, different ways of solving problems, different ways of trying to get to the root of an issue, find out what the root cause is and not just, well, it must be this and coding the first thing that flips into your mind.
No, we’re problem solvers, that’s the kind of core skill that we really need to focus on.
[0:05:28.6] DA: Yeah, that’s like a really freeing thing to realize like that should be our super power. We should be very adaptable, we should be very willing to change ourselves and our surroundings and you know, by honing those skills as a programmer which are not like on the can, you don’t get that from a degree in programming like you get like rhythms and java skills and then it’s up to you to decide those things and –
[0:05:58.0] AH: Yes, but that’s a very low level way of looking at it, we have these tools, we have everything from assembly language up to you know, cloud base builds but you know, again, that’s just the tools, we have the power to take that and create anything. We’re creating entire ways that the worlds talk to each other. How they interact with each other. We’re creating the fabric of society if we’re not careful.
[0:06:24.4] DA: Yeah, that’s another discussion I guess right there where – I was joking but like, that’s a very large discussion to have where it’s like wait, a lot of times, you know there’s a move fast and break things kind of attitude but there does have to be a deliberative –
[0:06:44.1] AH: I do not buy that by the way. I think it should move deliberately and build things.
[0:06:48.7] DA: Exactly. To have the engineering mindset and have some safety factors and responsibility in mind for the ways that things will go wrong.
[0:06:59.9] DT: You were talking about the things I liked in the new book, right? The idea, the first topic in the book is this idea of it’s your life. Then, the very last topic in the book is kind of like the same but flipped on its head and it talks about the idea that because it’s your life and because you’re doing this like you know, your consciousness is driving what you’re doing, you have to take responsibility for the things that you do.
I think that was what Andy was eluding to and I think it’s a very important conversation, I don’t think it’s one that can be like just like left for later on because increasingly, we are as Andy said, we’re changing the world, you know? Who would have imagined when you know, they created this stupid little app that will allow people to type 140 characters at each other?
That it would be used to ferment a revolution and it will be used to drive people to suicide and how do you think about that? How do you manage that as a developer? What personal rules can you put in place to make sure that you’re comfortable with the impact of the stuff that you're doing?
[0:08:07.7] DA: Right, it’s almost like, the idea of like pollution or something, it’s a cost or a side effect of a thing that isn’t in the thing itself, it’s not in the 140 characters or like ability to like something, it’s something that is larger than that and you got to consider the way those things fit together.
[0:08:27.4] AH: Yeah, that’s one of those things that you know I think has really changed over the last 20 years, we went from you know, our biggest concern was dereferencing pointers.
Right, you know, how could this be used against me? How could this be used against other people, right? What I want this used on myself that that’s a really big change that’s you know, now a concern, you have to think about security, you have to think about all the bad actors that could misuse whatever you’re writing, whatever you created.
Again, you know, am I working on some project that I would be okay with it, okay using it or having it used on me. You’ve got some hard questions to ask yourself.
[0:09:08.3] DA: Although honestly, when you mentioned, do you represent corners, I have the visceral reaction as I did to the idea of just the general mess of security and implications of software.
[0:09:20.0] AH: You know what it is? This occurred to me the other day, we have – we are in a sort of a kind of a bad spot right now in terms of societal impact, in terms of security, in terms of these things that we’re not, we’ve created this level of tech and we don’t really have the infrastructure, the laws, the social norms to kind of deal with it and it’s like when you read about the early days of industrialization, right?
All of a sudden you took people who were used to a farm, a culture, a farm way of life and you threw them into the factory and there are, you know, just unbelievable horror stories from that period of tainted food supplies, tainted meat, the triangle shirt ways fire disaster, you know, people getting injured, getting killed. Children working on the equipment alongside you in the field, on the farm and that was accepted and it was perfectly normal. That carried over into the factory but yikes, that’s no, you don’t want to do that when you don’t have guards.
You’ve got running belts and blades and everything. It took a fair while for society to kind of catch up to technology and say okay, if we’re working around machines and we’re doing this, we need these laws, we need these guidelines, we need these different social customs, social mores to kind of make it work out so that you all didn’t get killed when a fly wheel broke. But it took a while, right?
We’re not there yet, we’ve got this information technology at this point and we are not good at handling that.
[0:10:56.2] DT: Not just that. I think that right now, all of the discussion about these issues is outside our field, so I’ve never yet come across developers having a long and earnest conversation about the ethics of what they’re doing.
I have definitely heard politicians and other people talking about that. I think as developers tend to focus on my – yeah, we could do this, right? We can do this, we can make a car drive itself. Yeah, that’s full of really interesting problems and we’d really like to solve them and work on this and wouldn’t it be cool. And all the conversations about if a car would hit somebody who is responsible, all those conversations are taking place in Washington and with lawyers and in bass but not in the programming environments and they should be.
Because, when we start having those conversations, then we’d also start thinking about you know, my god, I hadn’t really thought about that but maybe I should do this or that or the other to try to mitigate this or maybe even refuse to work on this until I’ve worked out some way of making it safe or whatever it might be.
[0:12:07.0] AH: That’s a really good point about development in general is, there’s this sort of fantasy that you know, someone can go of, come up with requirements and throw them over the wall and dump them to programmers and then it’s just speed typing and you create the thing and that’s not how it works, right? Development is an act of co-creation between the people doing the programming and whoever the sponsor is, the clients, the users, the people actually want this.
It’s a dialogue between them. Dave’s example just there of you know, thinking through these issues, talking to someone who is using it, going, well, if that’s the case, then I can make this decision or I should do this differently. That feedback loop is absolutely critical and it doesn’t have to be for a self-driving, not carry, what was the name of the car that went off and killed people?
[0:12:55.3] DA: Tesla?
[0:12:58.1] AH: No.
[0:12:59.9] MN: That’s too real man.
[0:13:02.6] AH: Christine, wasn’t that Christine the killer car?
[0:13:04.8] DA: Yeah the Stephen King, classic.
[0:13:06.8] AH: You don’t have to be dramatic but you know, even on a smaller more boring project. That conversation, daily conversation with the user of how’s this, is this right? No, I really needed to do this or this is more important to me now because this other thing changed. These absolutely impact every little decision you make as a programmer.
If you don’t have that access, if you don’t have that level of conversation, you will make wrong decisions. That’s going to cause rework, that’s going to cause bugs, it’s going to cause angst, it’s going to make the project late, it’s going to be responsible for all these horrific statistics we see of project failure.
Or, you can have a dialog with someone and actually get it right.
[0:13:52.8] DA: Even if you can’t have that dialog, if the customer is like kind of a larger – if people are like talking with a smaller group, more specific customer or at least having trend develop the empathy for who the customer is and what the implications are and working in that concept of like, the whole team in the XP. That’s like super important like the most exciting experiences I’ve had developing software have been in teams that are always thinking about those kinds of things.
[0:14:20.6] DT: I think that’s a really good point. It’s exciting to think about it and I think that keys in to – I mean, this is like amateur psychology hour but I think – one of the reasons that developers do developing is that I think as human beings, everybody is wired to want to do something, they want to contribute, to be useful I guess. If you're a skilled at drawing, then you can be an artist and you get your pleasure from doing your art, expressing yourself that way and if you’re a musician, you do that.
If you’re an athlete, then you can you know, run and get sweaty and enjoy that, god help you. If you’re a developer, then your means of expression and your means of helping people is by solving problems. If you solve those problems in a vacuum and you never actually get to see people using the stuff you’ve done, you're kind of missing the reward portion of your life and so being able to watch people use your code and see people benefit from it.
Have people say, you know, it’s kind of okay but I really wish this was pink and you go, I can make that pink and you make it pink. Those kind of things are where the real pleasure and excitement come from. When you see developers who are kind of like turning into nine to five zombies, what you need to do to get that back is to send them out there and get them to watch the people using their software and give them some skin in that particular game.
[0:15:53.2] AH: There’s a company near us down here that is widely known for having a large portion of their staff that are RIP. Retired in place, right? They’re sitting there in their cube farm and they’re going through the motions and they’re collecting their paycheck and they’re not engaged, they’re not –
[0:16:16.1] DA: Cozy, yeah.
[0:16:16.9] AH: Yeah, they’re just going through the motions and they’re not producing anything, they’re not producing business value in the lean sense, they’re not contributing to anything and from folks who have worked there, they tell me that you can watch the people leaving at the end of the day in their cars and it looks like they’re coming back from a funeral.
There’s no happy smiling faces there. You know, yes, it sounds on the face of it, it sounds like hey, that’s a cushy job, I can just sit there and do nothing all day and get paid for it but that’s really a very soul sucking experience as Dave started off, you want to be needed, you want to have some purpose while we’re here on this ball and that doesn’t do it.
Yeah, absolutely getting out, actually sitting and working with users at their place of work, using your software, seeing it from that side is really incredibly motivating technique because now you’re seeing the people who are using yourself as like I can make this better for you, I can fix this, I didn’t know that was a problem or you needed to do these steps in this order with this kind of task workflow, whatever.
That’s easy. Hell, we can fix that.
[0:17:28.0] DA: Helping the people who are on the other side of the table who maybe like, kind of asleep on their feet and just be like well, this is the crappy software that I have to live my life with, you don’t have to do that. In the case of enterprise software where people don’t have a choice.
[0:17:47.0] AH: I think yeah, you’re repeating yourself there, grab yourself.
[0:17:50.7] DT: No, that’s not true. Okay, that actually I’m going to jump in on that because I really dislike that kind of lazy, it’s enterprise therefore it must be bad. I think there are good and there are bad enterprises. I think that enterprises, by their nature face different problems and the idea of being pragmatic is not to do it a certain way, it’s to do it the way that works.
If you’re in a 40,000 person developer shop, then what works is going to be very different than if you’re two guys in a studio somewhere.
[0:18:30.1] DA: Totally, yeah.
[0:18:33.9] DT: I think you got to be very careful when you do the, where we all get together and go, enterprise and everyone laughs. You got to be really careful because that doesn’t help anyone, it doesn’t help the enterprise people, it doesn’t help people who are on the outside.
[0:18:48.7] DA: Yeah. Enterprise is interesting means like it’s really like about separation between the users and the choosers. The people who are using it may not be the one who are choosing what software is being used. They may not have the power.
[0:19:01.1] DT: That’s not a given for an enterprise.
[0:19:05.3] AH: It’s just the real underlying problem you’re getting at there is that as you scale up to a very large organization, all the problems get bigger, you’ve got a lot more different needs to try to fill, you’ve got, you know, different people in different areas of the company with different rewards structures, hard really fast. If you’ve got a small team of four or five people, communication is easy, it’s fast, you’ve got fast feedback loop, that’s great.
You’ve got 10,000 developers working on something for an air frame, that’s a whole different kettle of fish. You need an entirely different tool kit, different sets of techniques, just to manage the communication and the motivation and the drive across such a large group of people and it’s a hard thing. Obviously it can be done, there are some very successful folks that do it but it’s really hard. I think it ends up being a lot harder than most people realize which is why we get to kind of stereotypical knee jerk joke at it because it’s really easy to screw it up.
[0:20:06.3] DA: Yeah, totally.
[0:20:08.8] MN: There you have it, that’s the end of part two. You don’t want to miss part three, the part three will be the dogmatic developer.
[0:20:16.2] DA: Yeah, it’s like return of the Jedi. The best one. Arguably, if you believe.
[0:20:24.8] MN: Feel free to check that out, looking forward to it.
[0:20:28.1] DA: Okay, if we’re excited to get your hands on a copy of the 20th anniversary edition of Pragmatic Programmer, you can head o over to pragprog.com. The eBook is available right now and the hard cover will be available in late September or early October. If you buy the eBook on the website, you’ll got to keep on for half of on the hard cover which is kind of cool.
[0:20:53.9] MN: Awesome, yeah, I think they had mentioned that that was highly requested. People who purchased the book, 20 years, you had to wait for that hard cover, it’s crazy. I’m going to have to wait another 20 for the next edition.
[0:21:06.8] DA: For the steel cover.
[0:21:07.9] MN: Because it’s a steel cover. If you want to contact Dave Thomas, he is pragdave on everything including Twitter so you could follow him on Twitter @pragdave and Andy is @pragmaticandy on Twitter. Follow him there and if you want to find out what he’s currently doing, he has a blog, it is toolshed.com.
[OUTRO]
[0:21:30.9] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five-star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
