Well hi there everyone and welcome back, It’s been a while since I wrote some blogs but here we go again..
Today we are going to continue our exploration of alternatives to Clean Code, and A Philosophy of Software Design. Last time we wrapped up the series about A Philosophy of Software Design but we are by no means done yet with alternatives to Clean Code. There are many cool books to consider and today we are going to start diving into one of my favorite books about software development and its practices of all time, The Pragmatic Programmer by Andrew Hunt and Dave Thomas.
I read this book back in 2018, yeah I checked when I ordered it so I’m pretty sure. And I was pretty amazed by the content presented in it. There’s just so many, common sense, pragmatic advise in this book. The first though you will get when you read it is like; I know all this yet I do not practice it and it makes total sense. It’s like reading personal development books, you already know everything that is in the book, you just need someone to articulate it well and remind you of it. At least, that’s the feeling I get reading personal development books or leadership books. It’s all common sense, yet you need someone to remind you.
But yeah today we are going to start a new multipart series about the content in The Pragmatic Programmer. We will tackle this the exact same way as we did with Clean Code and A Philosophy of Software Design. I’m just going to read through the book and talk about all the chapters individually.
Although I have to say that, as Clean Code and A Philosophy of Software Design are more about implementation details and strategies, The Pragmatic Programmer deals more with behavioral and process like things. There are implementation details in there as well but it’s also about how your behavior as a professional software developer. We can compare The Pragmatic Programmer a bit with another Uncle Bob book called, The Clean Coder which is also a really great book and definitely worth a read if you have not done so yet. We might check the Clean Coder out in the future as well. But not for now since I want to have a more diverse set of literature. So content written by different authors so we can actually compare the differences.
But alright enough with the introduction of this blog series. Let’s dig into the material.
The book, The Pragmatic Programmer is written by two authors, two very well known authors in the software industry and they are Andrew Hunt and David Thomas. If you studied agile software development processes before, you have probably read these names before as well. Since both of them are original singers of the Agile Manifesto. They have written and published multiple books and the one we are about to look at was first published in 1999. The even have their own publishing company now called the Pragmatic Bookshelf and most likely, you have read or own some books published by them.
Both of them are very well respected guys in the software community so we are up for a real treat.
Oh and by the way. We are going to discuss the original version of The Pragmatic Programmer and not the 20th anniversary version of the book that was published in September of 2019. I don’t own that book and I think the content in the original is still solid. There might be some advise in there that’s dated but that also gives us some interesting insights in how they did things back then, in 1999. And it also allows us to better compare it to the content of Clean Code which is also considered dated.
So without further ado, let’s take a look at the preface of the book and explore the purpose of The Pragmatic Programmer.
In the first sentence of the book, the authors claim that this book will help you to become a better programmer. And I mean, doesn’t that sound exciting? That’s a daring claim right? I like it. They also define the word “pragmatic” which comes from the Latin word pragmaticus and means “skilled in business” and which in turn comes from some greek word I’m unable to pronounce, but it means “to do”.
They say, and oh by they, I mean the authors of the book; Andrew Hunt and David Thomas. But they say that The Pragmatic programmer is aimed at people who want to become more effective at their job. The book does not have all the answers but still it will make you more effective and it will increase your understanding of the entire development process.
Next up they list the 7 traits of a pragmatic programmer, which I really like. They say that pragmatic programmers are people who:
Are early adopters or fast adapters. You like picking up new technologies and trying things out. When given something new, you quickly try it and integrate it with the rest of your knowledge. I think this is indeed a good trait to have, especially in our industry. The game and software industry moves very, very quickly. New “stuff” is released day by day and you really must keep up with the state of the industry in some way. You don’t need to be an expert in everything but you do need some basic understanding about many topics. For example, even though we are game developers, it’s very useful to have some basic understanding of how cloud architectures work or some basic knowledge about machine learning because you will inevitably come in contact with this stuff, even as a game developer.
A pragmatic programmer is also someone who is inquisitive. So what the hell does that word even mean? It means that you are eager for knowledge. So basically, you have no problem asking questions. You like little facts. And you tend to ask neat little questions about implementation details like “how did you solve that pathfinding solution for this or that enemy”, or “how did you implement that particle system for souse dripping of the spaghetti monster’s tentacle” or “how did you implement the beer volcano?”. Those are important questions of course and you as a pragmatic programmer have a tendency to ask them.
Critical thinking is also a skill of a pragmatic programmer. Since you like little facts, you rarely take things without first getting the facts. You need a solid view of something before you invest time in it. So when a colleague says you need to do it this way, because we have always done it this way is not enough. There are probably more important reasons why they always done it this way and you like to know what these reasons are.
Next a pragmatic programmer is also realistic. You really want to understand the underlying nature of each problem you face. This sense of realism provides you with enough knowledge about how difficult things are. This is a great trait to have as a developer since it will help you making estimations. Which are still one of the most difficult things to get right as a developer. Trust me estimation is really hard if there are many unknowns. And even if you think you know everything, you might just miss that one small little thing but that will set you back on the schedule for 2 weeks. But your sense of realism will also help you stay motivated. Since you know how much work something is going to take you can motivate yourself to get the job done. If you simply work from surprise to surprise in the sense that all these unknowns slap you right in the face and slow you down, you might get demotivated.
And, a pragmatic programmer is a jack of all traits. You can be an expert in one single thing, or you can be someone who knows enough about many things to make him or herself effective in that particular technology or environment. So even though your job might require you to specialize, you invest time of your own to get a broader view of the playing field. You investigate new technologies, just enough, to know when to consider it and when or why to use it. This also relates to you being an early adopter, inquisitive. You are always ready for new challenges.
Then they also say that pragmatic programmers care about their craft. You as a professional game developer care about the code you write. You want to produce the best code you can, not just behavioural, but also structural. We have covered this in depth in the previous blogs about Clean Code and A Philosophy of Software Design.
And last, a pragmatic programmer is someone who thinks about his work. You think about what the heck you are doing and why you are doing it. It’s part of you being a critical thinker as well. You will call out things that are wrong in the design or maybe gameplay wise. You are not just come “code monkey” that works though all his or her tickets in Jira or whatever ticketing system you are using. You speak up and raise your voice when inconsistencies are found to improve the quality of the game you are building.
Next they have a very interesting section which is about being a pragmatic programmer in a large team. I’ll quote a little section and then discuss it so here we go: “Some people feel that there is no room for individuality on large teams or complex projects. Software construction is an engineering discipline they say. That breaks down if individual team members make decisions for themselves.”
Isn’t that interesting. I do feel like in large projects it’s really nice to have some general consensus about what the architecture of the system aught to be. But individual opinions are certainly great to have since they introduce different perspectives. The authors think so too by the way and they disagree with the section I just quoted.
They say that the construction of software should indeed be an engineering discipline however, that doesn’t preclude individual craftsman ship. And oh boy, this is such a brilliant line. And they are so right. You can have a team of individual craftsmen or women forming a team that constructs the software. Each crafter brings special skills to the table which are combined to make the best team. I never though about it this way. The example they give in the book is really cool too. They say that a long time ago during the middle ages these huge cathedrals were built in Europe. I’ve seen some, they are amazing to look at. The level of craftsmanship is huge in these things, all the little statues, ornaments and glasswork is just amazing. But they were build by huge teams of craftsmen over decades.
I just really like this analogy. It really makes you respect the individuals in the teams for their specialized or broad skill set.
Another important aspect of all this is that as building some great medieval cathedral, software is also a continuous process. Software starts out small and gradually but steadily grows into something larger as it starts fitting your requirements more and more. Uncle Bob talks about this in Clean Code a lot as well. And a similar concept is described in a Philosophy of Software Design. Prof. Ousterhout talks about how maintaining complexity is the most important aspect of software design because once you let it slip away, complexity will only ever increase. So keeping complexity creep in check is fundamental.
The preface ends with some information how the book is structured and acknowledgments so we’ll skip this and continue with chapter 1, next time.
I hope you enjoyed it and learned something.
Cya!
#end
01010010 01110101 01100010 01100101 01101110
Recent Comments