Book Review: Working with Coders by Patrick Gleeson

Back to blog

August 17th, 2020, posted in #forfounders
by Vladimir

One of the most important factors and drivers of business is people. Their continuous development paves the way towards success. At UPDIVISION we started an initiative of building a library of books and courses that will help each team member grow and fulfill their potential as professionals in their field of expertise.


Today, I am happy to share with you my takeaways and a short summary for each chapter of the book that I read not so long ago -  Working with Coders: A Guide to Software Development for the perplexed Non-Techie by Patrick Gleeson. Being new to the IT field, I was looking for good resources that could help me understand how the software development process works and how to support it effectively. From the very beginning, Patrick Gleeson's book caught my attention and managed to keep me enthusiastic chapter after chapter.


Chapter 1: Introduction

The book is addressed to:

  • Project Managers
  • CEOs
  • Clients


The book is not about how to code, but rather is addressed to the ones that don't, but greatly depend on coders developing software for them. IT project managers, CEOs, clients - all the actors of the Software Development Life Cycle that have limited technical knowledge but are exposed to interactions with technical people. This book is not about how to code or an attack on technical people, it's purpose is rather showing that "Software development is illogical, counter-intuitive, and doesn't compare at all easily to anything else" and why.


Chapter 2: Why Writing Software is Nothing Like Building a House


As the title of the chapter suggests, this chapter explores why the classical approach of building something (“what to do, how to do it, and actually do it”) does not quite apply to software development. The author explains the three main challenges faced by the development team while building software:

The Imagination Problem - the customer never knows exactly what he wants, thus we have unclear objectives and specifications.


The Estimation Problem - the developers fail to take into account the uninteresting parts of the job as well as the unknown ones.


The Arithmetic Problem - two completely unrelated tasks are completed by two developers twice as fast. But when programming tasks are somehow related to each other, the gain of using more people starts to decrease, unless they communicate really well. A great quote that explains this problem is: "adding manpower to a late software project makes it later"


Chapter 3: Agile: A better, but still not perfect, approach to project management


The purpose of Agile is to deal with and smoothen the impact of the inevitable difficulties of the software development process. Difficulties which, as we`ve seen, are usually caused by the unknowns in specifications and estimations. By embracing incremental development and dividing the project into smaller deliverable milestones, software projects are de-risked. Even though the incremental development approach leads to more meetings and potentially code re-writing, most of the time it is an acceptable trade-off between succeeding inefficiently and rushing headlong into failure.


Chapter 4: What do they do all day?


This chapter takes a closer look at software development itself and the processes it involves. The software development process is composed of several big steps:


  1. What to build - before a coder can build anything they need to know what they are building.
  2. Spec it before building it - have everything laid down, in as much detail as possible before starting to write any line of code.
  3. UX details matter - if you don't want to end up with a piece of code that fulfills the technical requirements, but is virtually unusable - think about the user experience (flows, buttons, screens, etc)
  4. User Stories - functionalities are built to satisfy user wants and needs. So, in order to deliver good software, one should start by describing what the user wants to accomplish in any given situation.
  5. Code - OOP is a widely used programming approach, that helps developers with the abstraction problem and making the code human-friendly. Do code reviews and versioning of the code.
  6. Deployment - as a rule of thumb, the larger the release, the harder it is to get it up and running.


Chapter 5: The big green check mark


Since software is produced in most cases by a team or even multiple teams, there are lots of ways in which the production could be considered unsatisfactory. Trying to hire the best people to implement the software is not a good long-term solution to avoid this problem. The smart approach is to put in place processes to ensure quality. This chapter explores the processes by which software can be assessed and quantified, with the emphasis on the main ways in which a piece of software can be tested. The main questions to keep in mind when testing software are:


  1. Does it do what it says it does?
  2. Does it do what it doesn't say it does?


But, the author warns us that assessing the quality of code takes time and will slow the delivery. Therefore, sometimes it is more important to take the quick-and-dirty approach: get things done and worry about the consequences later.


Chapter 6: Taking the "arg" out of Jargon


Even though the reader is armed with a lot of information by now, after covering half of the book, it is still very likely that if I asked the developers what they are working on today, and tell them not to translate it into non-tech language, I will almost certainly get confused by the jargon. In this chapter, the author talks about the most common topics and tries to explain some basic terms and concepts that are likely to come up in the average software project. The four areas explored are Internet, Data, Security, and Coding.


Chapter 7: So you need to hire a coder


Starting from this chapter, the author takes a closer look at software developers, rather than the process. The author presents the readers with different aspects of how coders think, and what you should pay attention to when working with them. Specifically, the author talks about the hiring process, the fact that technical evaluation is tricky and there are no perfect solutions. When hiring a developer, we should be careful where to set the bar by trying to answer this question: Do I need someone fast, or do I need someone fantastic? If you're not pressed by time, keep saying no until you find someone who leaves you in no doubt at all.


Chapter 8: Programer preoccupations


For someone who manages one or more developers, it is important to understand how they work and how they think. As a result, this will help you make decisions that will make their lives easier, respond more intelligently to their needs and concerns, and avoid getting in their way.

The author explores multiple concepts like: developers` aversion towards particular tools and technologies and on the other hand the concept of "beauty in code" - which is nothing more than a well structured codebase, without unnecessary repetition and divided into smaller chunks of code. Software development can shape how a person thinks and it can lead to interesting attitudes towards the development process,  including what a beautiful code looks like. Understanding these attitudes can help people in charge better deal with problems when they arise.


Chapter 9: Keeping coders happy


Happy coders code faster. In this chapter, the author argues that it is important to keep the developers happy. Even though you can’t make all the developers happy, there are plenty of things a manager can do to minimize unpleasantness. One of the "tools" mentioned is the so-called "Joel Test", which is a set of criteria for what makes a good development team put together by Joel Spolsky. This test is made of 12 questions that assess the processes and practices of the team as well as their working conditions, each of which can be answered with "yes" or "no".  Some of the questions are expensive when trying to answer them with "yes", thus it is up to the person in charge to weigh up the benefits of having happy coders against those costs.


Chapter 10: When it all goes wrong


In this chapter, the author explores the 3 very unpleasant situations that are very likely to occur in any given project: 


  • When your team hate each other

  • When you're horribly behind schedule

  • When your product just isn't very good


Even though these situations happen quite often and when they happen there are no perfect solutions to them, there certainly are some factors that can be changed. Compromises can be made, so that the damage of these events is minimized.


As mentioned at the beginning, this book is not about how to code, rather it is addressed to the ones that don't, but greatly depend on coders developing software for them. It looks at different aspects of the software development life cycle, by bringing up the issues one may encounter as well as possible solutions in order to reduce the damage. One thing that the author emphasizes during the entire book is that there is no perfect solution to any challenge when building software because of its unpredictability and abstract form.


About the author


I'm new to this field but I enjoy it so much that I shadow those who speak "IT". I'm a proud father of a young boy, I like doing pull-ups and challenging our CEO, Andrei Iordache, to it. My work might seem challenging - but it's just as rewarding.

See more articles by Vladimir