Continual Professional Development - 2022

The cover image for this post is by Unsplash user Ryunosuke Kikuno

This blog post was written by Jamie.

Introduction

I’ve always been a believer (and supporter) of continuous professional development in all industries, and have pushed for it wherever I’ve worked. After all, it can be so easy (specifically in our industry) to fall behind if you don’t at least try to learn something new. So when I came on board at RJJ, I brought my love of CPD with me.

I take great pride in the fact that we encourage our colleagues to continually learn by offering them resources, training, and a budget for self-directed learning at RJJ. And over the last few years, I’ve been posting about the books I’ve been reading as part of my own CPD journey

you can read through all of my CPD posts here.

I like to do this because I’m all about transparency (where possible). But I also think that it can be useful to see what everyone is reading and learning. And unlike previous years, I’m giving my homework away, too - check the end of this post for details.

So without further ado, here’s a subset of the books that I’ve read this year, and the goals that I had in mind when reading them.

Note: Only a few of the books that I have listed here were actually published in 2022, but they are all books that I have read this year.

Each book will be presented with reasons as to why I picked it, but if you want to “skip to the end” and see the list without the reasons then you can here:

The 2022 List

1. Lean Software Systems Engineering for Developers
2. Managing Humans: More Biting and Humerous Tales of a Software Engineering Manager
3. The Unlikely Success of a Copy-Paste Developer
4. The Mom Test: How To Talk To Customers & Learn if Your Business Is a Good Idea when Everyone Is Lying to You
5. Daring Greatly: How The Courage to be Vulnerable Transforms The Way We Live, Love, Parent, and Lead
6. Leaders Eat Last: Why Some Teams Pull Together and Others Don’t
7. Think Again: The Power of Knowing What You Don’t Know
8. Talent is Overrated: What Really Separates World-Class Performers From Everybody Else
9. Building a Second Brain: A Proven Method to Organize Your Digital Life and Unlock Your Creative Potential
10. Anger: Buddhist Wisdom For Cooling The Flames

Clicking on a book title will take you directly to the section of this blog post about it.

These books are presented in an order which will (hopefully) provide a narrative through-line to my learning; not necessarily in the order that I read them. The hope is that if you were to read these books in the order that I’ve presented them here, you should be able to see how they are connected.

I’m also going to link through to each book on The Story Graph so that you can learn more about them. In previous years, I’ve linked through to each book on GoodReads. There’s nothing wrong with GoodReads, I just prefer The Story Graph’s UI and feature set.

Book 1: Lean Software Systems Engineering for Developers by Doug Durham

I wanted to start with a software development book, because I figured it’s always important to keep our technical skills sharp. And Durham does a fantastic job of teaching a huge number of lessons in this book without leaning into any specific technologies - there are a handful of very small examples in .NET, but the majority of the book is technology agnostic. And this book was actually part of a software development bundle on Humble Bundle this year, too. So it cost almost nothing at the time that it was purchased.

Regardless of the price that was paid for it, this book is full of fantastic lessons for developers. In fact, this book has the most annotations and notes in my 2022 commonplace book

more on that later

It has 53 individual annotations:

% find . -type f | wc -l
      53

the above code snippet is a count of the annotations files that I have for this one book

So what makes this book a great place to start? Well, firstly it has such depth of knowledge from design patterns to leadership, and from communication to how to pick the best tools for the job - after all, when all you have is a hammer…

I really liked how Durham was able to focus on way more than coding in his book; there are a lot of technical books which focus on the “hands on keyboard, headphones on, lights off, hood up, typing until dawn” part of software development, but not that many (that I’ve found at least) which focus on the business and (more importantly) manufacturing of software. There are a lot of books out there which look at a lot of theory around computer science or split hairs about SOLID, Agile, CUPID, RAD, and a whole bunch of other terms without actually giving much in the way of advice. But this book is chock-full with practical advice for all devs.

And one of my biggest topics of this year (empathy) comes up a lot in this book. Durham posits that we need to understand both the “what” (the application or service that you are building) along with the “why” (why the user needs this to exist) in order to build it as close to spec as possible

we’ll come back to "why" later, actually

One of my favourite quotes from this book relates to the thought that productivity (or slinging code) is seen as the number one task of a development team, but it actually isn’t:

Somehow, being productive in software development has been equated to the time our fingers are on the keyboard. Any other activities are looked upon as a hinderance to being productive. Output has been the focus. But, just as we would never start manufacturing an airplane without first performing the critical thought around planning for the design, development, and maintenance of the aircraft, we should be equally disciplined in how we approach software - that is, software engineering.

Durham is completely right with this. We cannot engineer stable, scalable software without knowing what we are trying to build in the first place. in fact:

There are people who will tell you that spending a lot of time trying to understand requirements before coding is wasteful and should be avoided. They argue that we should embrace the idea that requirements will "emerge" as we begin producing working software and the users start providing feedback. We will be blunt: this is a naïve and dangerous protion to take.

emphasis is mine

You can read more about Lean Software Systems Engineering for Developers by Doug Durham at The Story Graph.

Book 2: Managing Humans: More Biting and Humerous Tales of a Software Engineering Manager by Michael Lopp

Taking more of a leadership angle, Lopp’s book is a collection of essays written whilst “figuring out how to manage what I once was.” Lopp is software engineer who became a manager of software engineering teams, and who wanted to share the wisdom that he picked up along the way

similar to an entry in the Honourable Mentions section by Sarah Drasner, who has taken the same journey

Lopp shares his learnings with both deep honesty and biting satire. He talks about having one-to-ones with his direct reports on a very regular basis (at least once per iteration), even if they are only 15 minutes long; he talks about having to step away from the keyboard and let his engineers do what they do best; he talks about fighting for his engineers and protecting them from the rest of the business

we’ll come back to this ideas soon, too. Here’s a spoiler: what Lopp is referring to is a "Circle of Safety"

He talks about connecting and communicating with people across the business and in your team of reports:

When personalities are disconnected, you don’t know how to communicate.

and

I trust that, like me, you are an optimist and you believe that everyone in your company is busily working on whatever they do. I also believe that because you don’t understand what they do, you are automatically biased against them. You believe that because you understand your job intimately, it is more important than anyone else’s.

Without being able to connect with the people you work with, you can’t empathize with them. And empathy (as we’ll see as we work our way through this list) is one of the most important things when building up a company culture and ensuring that everyone can work together.

Lopp’s advice isn’t just related to the “soft skills” - a term that I really dislike, because it can imply that these skills are not as difficult or important as any others - he also talks about code, too. Here’s my favourite quote about how long your code will live for:

Code lives forever. Good code, not only lives, it grows as those who value it make sure that it doesn’t become stale.

The most interesting thing about this quote is that there is something that Lopp isn’t saying here: Bad code also lives forever. And at some point, someone’s bad code (yours or someone elses) will be maintained by you and your team. So make the bad code bearable or remove it, by having PRs and code reviews.

You can read more about Managing Humans: More Biting and Humerous Tales of a Software Engineering Manager by Michael Lopp at The Story Graph.

Book 3: The Unlikely Success of a Copy-Paste Developer by Iris Classon

It’s time for a work of fiction

although only slightly so, according to the author in my interview with her

Whilst it’s fiction, The Unlikely Success Of A Copy-Paste Developer is one of the very few fiction books which tell a story about development from a developer’s point of view. Sure, The Phoenix Project was about software development and DevOps, but it was from a management point of view. Classon has written a story here (based on real experiences) about someone who is rocketed to fame in the open-source community through (essentially) messing something up and losing their job.

Classon’s writing here is humorous, as she tells a number of stories that we all know well (coding late into the night, and living on pizza and coffee early in our careers) and some stories that only a few of us will know (I’ll leave it up to the reader to go get a copy of the book and find those stories). Along the way, Classon makes fun of both the computer hardware industry and development practices:

Devices were modernized years ago to only require one - maybe two - ports. A sleek and elegant design, promoting simplicity in a complex world that could only ever by useful when paired with a gigantic box of dongle Lego pieces so one could make the device useful. And because the binary father hates the ordinary, he made sure to always alternate which dongle would fail to work, just to keep people on their toes. Never forget, Apple started it.

and:

You might not know but being Agile is a must for software developer companies. You don’t have to be Agile, claiming that you are is enough. It’s like those participation trophies you get as a kid, or golden stars for doing [stuff] you should do without golden stars, it’s just something you must do to be considered a good boy. Or girl. We don’t collect golden stars, instead we collect fancy words and abbreviations, and those can be traded in for real currency. Extra valuable if you are a consultant because you only trade with make-believe words when getting hired for a project.

I’ve censored a word in the above quote, but I feel like it’s both funny and true without the original swear

Classon has written her story with a genuine humility and a truth that I’m sure all engineers will have (at least) some experience with. I also really liked that the story is written in such a way that the gender identity of the main character is hidden from the reader until it’s actually required for the reader to know it

you’ll have to read the book to find out what I mean by that

There’s also this, too:

Did I ever show off that my copy of @IrisClasson’s book The Unlikely Success of a Copy-Paste Developer is signed? Its a great book, by the way..

— dotNetCoreShow (@dotNetCoreShow) Dec 29, 2022

You can read more about The Unlikely Success of a Copy-Paste Developer by Iris Classon at The Story Graph.

Book 4: The Mom Test: How To Talk To Customers & Learn if Your Business Is a Good Idea when Everyone Is Lying to You by Rob Fitzpatrick

Before we talk again about empathy and how important it is

it’s that important that it’s the subject of a talk that I gave a few times this year

I’d like to circle back to communication. Whilst the main point of Fitzpatrick’s book is the focus on asking the questions which help you to gather information on whether your business idea is a good one or not, he also talks a lot about connecting with people and communicating with them.

Connecting and communicating are both things that I’m very keen on, and something I’m practising on a regular basis. Last year, I read a very important book on the subject, and I’ve been keeping up with a great podcast on the subject too. And Fitzpatrick’s book contains some fantastic lessons on both:

It’s not anyone else’s responsibility to show us the truth. It’s our responsibility to find it. We do that by asking good questions

You might be wondering why it’s important to communicate with people. If so, you might be shocked to realise that most of our day-to-day work as software engineers isn’t spent “hands on keyboard, headphones on, lights off, hood up, typing until dawn,” but actually spent talking with other people - sometimes we talk to customers, clients, and even users. So you could say that the skills we need in order to communicate effectively with them are quite important. And you’d be right.

Fitzpatrick’s goal in this book is to make it easier for you to get a business or side hustle going by finding out whether the app or service that you’ve come up with is a good idea for its intended audience. He also focuses on the techniques required to get really specific about what users like and dislike about your idea, and how to iterate on your idea quickly so that you can get it to market as fast as possible.

But along the way, Fitzpatrick teaches you the core skills you need in order to:

• gather specifications
• weed out weasel words in those specifications
• ask for, and deal with, very specific feedback
• ask for ideas for apps and services that you can build yourself
• ask for very specific detail in bug reports
• communicate with colleagues (both in written and aural forms)

I would argue that these are the most important skills for any engineer to have. Remember: we don’t work alone, but in teams; and sometimes with people we’ll never even meet in person. So being able to communicate with them, hear what they are saying

and I mean REALLY hear what they are saying

and work with them should be the goal of every software engineer.

You can read more about The Mom Test: How To Talk To Customers & Learn if Your Business Is a Good Idea when Everyone Is Lying to You by Rob Fitzpatrick at The Story Graph.

Book 5: Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead by Dr. Brené Brown

The title in Brown’s book comes from a speech that Theodore Roosevelt gave in Paris in 1910 called “Citizenship in a Republic”

the speech is often called "The Critic" or "The Man in the Arena"

In the speech Roosevelt talks about how it’s not the critic who deserves credit but:

The credit belongs to the man who is actually in the arena … who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat

Brown used this quote to talk about her research on shame and empathy in both our personal and professional lives. In her book, Brown talks about how vulnerability, sharing, humanization, and boundary setting are important in our lives and work, and how the use of blame and shame can destroy a company’s culture.

Shame, Brown posits, is one of the worst things that a company can use, as it causes people to cover their own backsides and point out the flaws in others. It can lead to a lack of trust, failings in team cohesion and synergy, and promotes apathy and distrust whilst removing all empathy and compassion. Without empathy and compassion in your team you cannot be vulnerable, and without vulnerability you cannot build trust and wont have the belief that your ideas can be shared without ridicule; and not sharing ideas leads to a lack of innovation.

There is nothing productive about blame, and it often involves shaming someone or just being mean. If blame is a pattern in your culture, then shame needs ot be addressed as an issue

I’m sure we’ve all worked for different companies where it has been claimed that there is no blame culture. I’ve only ever seen it truly achieved, in real life, twice - and I’ve been a software engineer for 15 years at this point. Blame culture, and it’s destructive nature, is something that came up quite a lot in my reading this year; Brown covers it, Geoff Colvin covers it in Talent is Overrated, and so too does Simon Sinek in Leaders Eat Last

more on those in a moment or two

When the spam really does hit the fan in your organisation, what actually happens? Do you all come together and fix the problem, or is there a lot of belly aching over who caused it to happen? If you’re wasting time investigating in order to assign blame, then you’re not focusing on the important part: something is wrong and we need to fix it.

If you’ll allow me to use a metaphor for a moment: suppose you’re a commercial airline pilot and a problem is found in an engine, mid-flight. Do you:

• do what you can to land the plane safely
• waste time blaming the technicians and maintenance crew

You do what is needed to protect the people in your charge. And that’s what we must do in our teams, too. If there’s a blame culture, we wont ever be able to create the Circles of Safety

more on those in a moment

which are needed in order to allow our colleagues and reports to innovate and truly accomplish great things. And that’s why I feel like Brown’s work is always important in our industry; in fact, I posit that if you read any of her books, you’ll be a much better software engineer and person regardless of which book is it of hers that you read.

You can read more about Daring Greatly: How the Courage to Be Vulnerable Transforms the Way We Live, Love, Parent, and Lead by Dr. Brené Brown at The Story Graph.

Book 6: Leaders Eat Last: Why Some Teams Pull Together and Others Don’t by Simon Sinek

Leaders Eat Last is a fantastic continuation point from Brown’s Daring Greatly. Whilst Brown dominates the discussion on empathy and why it’s important from a humanistic point of view, Sinek brings a little neuroscience to the fore and talks about “selfish” (endorphins and dopamine) and “selfless” (serotonin and oxytocin) chemicals and their affect on our social structures, including work (which Sinek calls “the modern tribe”).

In a team where selfish acts are allowed to happen freely, we will feel a lack of trust with those around us. And a lack of trust will destroy any chance for a Circle of Safety to grow and flourish.

A leader who takes care of their people and stays focused on the well-being of the organization can never fail.

So what is a Circle of Safety? In every team there is a leader (or “alpha”), it is the job of the leader to protect the team and help provide for them. When you are put first by your leader, you immediately feel trust for the leader. This is how civilisation evolved: by putting the needs of others ahead of our own and switching from an “I vs Them” to an “Us vs Them” mindset. By being selfless, those around us get a shot of the “selfless” chemicals (serotonin and oxytocin), these chemicals are designed to promote cohesion and bonding.

Those who work hardest to help others succeed will be seen by the group as the leader or "alpha" of the group. And being the alpha - the strong, supportive one of the group, the one willing to sacrifice time and energy so that others may gain - is the prerequisite for leadership.

Sinek mentions throughout the book (and in a recent podcast episode with both Dr. Brené Brown and Adam Grant) that this cohesion through selflessness is nowhere more apparent than in the attitudes and behaviours of those in the military. In the book, Sinek recounts meeting with Brigadier General Michael Dowley (whose call sign in the Air Force was “Johnny Bravo”); in their discussions, Downley talks about how having empathy for his colleagues literally saved their lives, and how his colleagues having empathy for him will have saved his live multiple times. Empathy, he says, is, “a second by second, minute by minute service that [we] owe to everyone if [we] want to call [ourselves] a leader.”

And we don’t have to actually be in a position of leadership to be a leader, too. By having even the tiniest amount of influence on a team or team member, we are leading them in some way. At a previous workplace, I used to send round a sub-set of blog articles every few days

it was often referred to jokingly as "Jamie’s Dev News"

I was sharing those articles for no other reason than I thought that they were interesting and could help everyone who read them to learn about a new thing - perhaps a new technology, library, or technique. I had an influence on the education and skills of some of my colleagues by doing his. I was also helping to keep the Circle of Safety strong (though I didn’t know it at the time), by allowing those around me to learn about something without having to be vulnerable (in asking about it). In fact, when I left that job, I was told by several of my colleagues that they would miss my “Dev News” links and they thanked me for helping them grow as developers.

This is something that Sinek points out, too:

Leadership, true leadership, is not the bastion of those who sit at the top. It is the responsibility of anyone who belongs to the group. Though those with formal rank may have the authority to work at greater scale, each of us has a responsibility to keep the Circle of Safety strong. We must all start today to do little things for the good of others… one day at a time.

So you may be reading this and thinking, “but I’m not a leader.” Both Sinek and I say that you don’t need to be a leader to have an influence on those around you or to help maintain the Circle of Safety.

You can read more about Leaders Eat Last: Why Some Teams Pull Together and Others Don't by Simon Sinek at The Story Graph.

Book 7: Think Again: The Power of Knowing What You Don’t Know by Adam Grant

Grant takes a pretty heavy subject (questioning your thoughts, opinions, and biases) and uses humour to talk about how it’s OK to rethink through those preconceived notions that we all hold. The majority of the book is written from a point of view of questioning your knowledge and experience, however since the book was written very recently (during the middle of the recent pandemic), Grant also writes about those who question the efficacy of vaccines and such. I bring this up only to point out that, whilst Grant talks about why someone might or might not believe something in the face of evidence, he does do in a very contemporary way and with light-hearted humour and as an example of the empathy and compassion required in allowing us to see someone else’s point of view

I have a feeling that the chapter of the book that I’m referring to could end up ruffling a few feathers; but I ask that you read that chapter with the spirit in which is was intended: not to bash anyone for their beliefs and opinions, but to teach us to be more caring of other people because of them

So what is rethinking?

Rethinking is a skill set, but it’s a mindset. We already have many of the mental tools we need. We just have to remember to get them out of the shed and remove the rust

It turns out that rethinking is something that we already know how to do; we do it all the time. Whenever you have a thought, opinion, or belief about something and you allow someone to challenge it in a friendly way, you are rethinking both yours and your friends thoughts, opinions, and beliefs. The real power in rethinking comes not from arguing with someone about strongly held beliefs or thoughts, but from accepting that you have differences and trying to see the other person’s point of view. Perhaps they have knowledge or experience that you don’t have, and you could grow from having them share it with you - or vice versa.

Rethinking allows us to use the Socratic method to gain knowledge and experience from someone in a way which avoids conflict, but also gets to the heart of the matter whilst applying critical thinking methodologies. At its heart both rethinking and the Socratic method are about connecting and communicating with someone, and allowing their knowledge, experience, and beliefs to come into safe conflict with your own; allowing them to mingle, and allowing you to grow.

Outdated facts are mental fossils that are best abandoned

It could be that a thought or idea that we have is based on some old evidence or experience which is no longer valid. A friend of mine used to tell me that, “.NET will never be as fast as C or C++ code running natively,” and whilst at the time (this was around 2008) they were right, their point is slowly getting less and less valid. Not only do the benchmarks for .NET operations show that it is getting faster with every release, our computer hardware is getting faster and more powerful with every iteration. So whilst it may be true that an application written in C and C++ might be faster, smaller, and more efficient than one written in C# and .NET, there’s not that much in it these days.

And that’s just when the weighing up the binary. I would posit that there will be a percentage of developers who are more comfortable with C#’s more modern, less laconic syntax and impressive amount of free libraries (and functionality built-in to .NET itself). but I digress

and, of course, I may be wrong. And if I am, I will rethink my opinion

Rethinking is crucial to our industry, as we are required to do it on a daily basis when we have faulty assumptions (likely based on misunderstood requirements or task definitions). And when we make a mistake, we need to be able to honestly, and frankly look at what happened, why it happened, and fix it. Without blame or fear of reprimand:

In psychologically unsafe teams, people hid their mishaps to avoid penalties, which made it difficult for anyone to diagnose the root causes and prevent future problems. They kept repeating the same mistakes

Which is precisely what Dr. Brené Brown talks about with both empathy and shame, and what Simon Sinek talks about with Circles of Safety. If there is no Circle of Safety and no empathy, but only shame and blame, then people will hide their mistakes. And hiding mistakes is the antithesis of being and effective engineer.

I have always preferred to focus on effectiveness rather than productivity

And a culture of shame and blame can cause career atrophy:

When we see people get punished for failures and mistakes, we become worried about proving out competence and protecting our careers. We learn to engage in self-limited behaviour, biting our tongues rather than voicing questions and concerns

You can read more about Think Again: The Power of Knowing What You Don't Know by Adam Grant at The Story Graph.

Book 8: Talent is Overrated: What Really Separates World-Class Performers From Everybody Else by Geoff Colvin

You might think that Colvin’s title is hyperbolic, and it might be too. The idea that Colvin is getting at with the title (and thesis behind this book) is that someone who has a talent for something can easily be supplanted by someone else who has the drive and willingness to learn what needs to be learnt. If you’re someone who has relied on your talents alone for a long time, that’s probably not a great sentence to here; but it might be true.

Essentially what Colvin is getting at here is that “just” having a talent for something and never growing, or pushing yourself to grow, will not get you very far:

The differences between expert performers and normal adults reflect a life-long period of deliberate effort to improve performance in a specific domain.

“Deliberate effort to improve” is another way of saying deliberate practise. And deliberate practise matters; it matters a lot.

Without deliberate practise

finding the skill which lies outside of your comfort zone and pushing, full steam ahead, towards it until you attain it

you don’t grow. And growth is how you will stand out from the crowd of thousands (if not hundreds of thousands, or even millions) of other people in your niche. And if you don’t stand out, you may not get that job or promotion that you’re looking for. You certainly won’t get the sale or customer that you want. You really need to be world class, in every sense of the term:

"World class" is a term that gets thrown around too easily. For most of history, few people had to worry about what world class was. But now that’s changing. In a global, information-based, interconnected economy, businesses and individuals are increasingly going up against the world’s best. The costs of being less than truly wold class are growing, as are the rewards of being genuinely great.

And deliberate practise is more than just remembering by rote. It’s when you step out of your comfort zone (where you are comfortable with a skill or knowledge set) and into the panic zone (where you push yourself to learn something new). But what you choose to learn must be planned out meticulously, you need to know what you need to know next, and you need to push towards it with all of your might. Not just know, you need to understand deeply:

The best computer programmers are much better than novices at remembering the overall structure of programs because they understand better what they’re intended to do and how.

Colvin’s book is one of the best I’ve read on how to instil deliberate practise into your learning journey. And you need deliberate practise when you are studying something, because if you fail to plan then you may as well have planned to fail. Pairing this book up with the next on the list (Building a Second Brain) and Ultralearning (see the “Honourable Mentions” section) will lead to you becoming an unstoppable learning machine. I’m sure of it.

You can read more about Talent is Overrated: What Really Separates World-Class Performers From Everybody Else by Geoff Colvin at The Story Graph.

Book 9: Building a Second Brain: A Proven Method to Organize Your Digital Life and Unlock Your Creative Potential by Tiago Forte

Forte’s book is one that felt like it ended up on my radar organically, but I’m not so sure any more.

It was published this year (2022), so it’s really recent. But the strange thing is that a lot of people that I know seem to have read it, even though they can’t remember when or how it was recommended to them

a Mandela effect, but in book form perhaps?

The strangest part about Forte’s book appearing on my radar as if by accident is that I finished it the day before I saw my friend Luce Carter give a talk called Productivity++… which was about how she had used Forte’s ideas to plan out her life in Notion. I had just started using Obsidian as my second brain (and it’s how I wrote this article, actually), after having been recommended it by Dan Clarke, too.

Very strange, indeed.

Forte posits that our brains are really only useful for having ideas in the moment, not really for long-term storage of things like birthdays, events, projects, and information we’ve learned whilst studying. He says that by having a “second brain” (somewhere to store all of this information), you can free up your cognitive processes for the important tasks of being creative.

The ultimate purpose of a Second Brain is to allow your own thinking to shine.

You likely already use a specific type of second brain: your calendar.

The idea is that by storing things in a second brain using a system called PARA (Projects, Areas, Resources, Archive), you can keep all of those important things to hand and call them back when you need them.

A project which has a specific deadline or end date (perhaps a book that you’re writing or an app you’re building) is stored in Projects, whereas those without a definite end (perhaps life goals) go in Areas. Resources are all of the media that you consume (books, articles, tweets, podcasts, videos, etc.) that you feel some kind of intrinsic connection to; the idea is to keep them around for research purposes. And an Archive is where you put things (Projects, Research, etc.) when you’re done with them.

You can absolutely do this with pen and paper, but Forte says that by keeping it digital you have all the benefits:

• search
• easily editable
• cloud storage
• syncing across devices

By having your second brain stored digitally, you can access it anywhere. In line at the bank, and it’s taking a while? Pull up your research folder and read that article you’ve wanted to read; and while you’re there, take some notes on what you found interesting about it. Or as Forte calls them “knowledge assets”:

A knowledge asset is anything that can be used in the future to solve a problem, save time, illuminate a concept, or learn from past experience. Knowledge assets can come from either the external world or your inner thoughts.

I’ve been using a second brain to store annotations from and thoughts on the books that I’ve been reading this year, and I’ve found it to be a wonderful thing indeed. Whilst I’m reading, I make highlights (either by using index tabs in physical books, or the highlight tool on my eReader); and when I’m done reading the book, I go back and collect those highlights in my second brain. Reading back through them, I get to think about why I highlighted that passage and what it means to me. I’d recommend this process to anyone.

I’ve yet to use the PARA system, but I can see how it would be fantastic for keeping things in order - after all, we all love using Kanban boards and such. Plus, I love the idea of turning my Archive into something that my friend Jay Miller calls a “Brag Journal” - a list of all of my completed projects, and a selection of nice quotes from people about me - that way, when I’m having a bad day, I can read through it to get a little ego boost.

You can read more about Building a Second Brain: A Proven Method to Organize Your Digital Life and Unlock Your Creative Potential by Tiago Forte at The Story Graph.

Book 10: Anger: Buddhist Wisdom For Cooling The Flames by Thích Nhất Hạnh

OK, let’s talk about our emotions for a moment. Creating working software to precise specifications can sometimes be quite tough, especially if those specifications aren’t well understood or communicated. And it can be doubly tough when the code you’ve written should work but doesn’t and you can’t figure out why.

In those moments, it’s entirely possible to get angry, frustrated, mad, or even yell.

As much as those emotions exist for a reason, and as cathartic as it can be to imagine taking a lump hammer to your computer, they’re not them most helpful of thoughts or emotions in those moments. Sure, if you’re under attack or being chased by a ferocious tiger, then being angry might help; and so will being afraid. But when we’re staring into a screen, wondering why the characters we just typed aren’t being magically transformed into the thing we want them to, getting angry with your computer won’t help. After all, it’s only doing precisely what you told it to.

When we suffer, we always blame the other person for having made us suffer. We do not realise that the anger is, first of all, our business. We are primarily responsible for our anger, but we believe very naively that if we can say something or do something to punish the other person, we will suffer less.

I’m not saying that it’s easy to let go of anger, but it’s something that’s worth a try. Because otherwise, you’re just taking your own anger out on another person (or thing). Imagine if you told me specifically how to do something, but left out some important step: you’ve told me not to deviate from the plan, yet there’s a step missing. This means that I’m going to get it wrong, but to respond to me with anger for something that you caused is not the way.

Consider the peanut butter and jelly sandwich challenge:

The challenge is simple: write down the exact steps required to make a peanut butter and jelly (or jam, if you’re from the UK) sandwich, but all of the steps have to be exact.

In the above video, the father is taking the role of a computer, and the children are taking the roles of software engineers. Does the father respond with anger when the instructions are unclear? No. He reacts with kindness, love, humour, and compassion.

Anger is beaten with compassion, and compassion requires us to be in the present moment and accept that the present moment is all that there is; the future hasn’t happened yet, and the past has been and gone. Anger has two directions: inward and outward. Anger at ourselves can only cause us harm, whereas anger at others causes harm to others but also that same anger - when pointed outwards - harms us, too.

This does not mean that anger is pointless or something which we should do away with. We should approach our anger with loving kindness (I prefer compassion, but I absolutely understand why Thích Nhất Hạnh chose those words); by embracing anger with compassion (or loving kindness), we nullify anger’s affects. And when we nullify anger’s affects, we can focus on the message behind the anger: the why of the anger.

You can read more about Anger: Buddhist Wisdom For Cooling The Flames by Thích Nhất Hạnh at The Story Graph.

Honourable Mentions

The above isn’t the entire list of books that I had read this year (as part of my continual learning, or leisure reading). As such, I feel like I need to mention a few other titles that I have read this year:

1. Engineering Management for the Rest of Us by Sarah Drasner
2. Hackers: Heroes of the Computer Revolution by Steven Levy
3. Dare to Lead - Brave Work, Tough Conversations, Whole Heart by Dr. Brené Brown
4. How to be Perfect by Michael Schure
5. Start With Why by Simon Sinek
6. Solo: How to Work Alone (and Not Lose Your Mind) by Rebecca Seal
7. Ultralearning: Master Hard Skills, Outsmart the Competition, and Accelerate Your Career by Scott H. Young

Something New

One of the things I’ve been doing this year is working on my second brain (my listing Tiago Forte’s “Building a Second Brain” was not a coincidence), and decided to keep a commonplace book with all of my annotations and key takeaways from the books I’ve read this year. It was a great help in writing this blog post, actually - I was able to go into more detail and pull direct quotes from some of the books because of my commonplace book.

I’m not bringing that fact up to brag

OK, maybe just a little bit

but to let you know that I’m offering up my commonplace book for 2022 for free… ish. That’s right, you can get my homework and do what you wish with it (typos included at no extra charge!). I’m only asking that you make a single charitable donation to whatever charity you prefer and send some form of proof to me, and I’ll forward the PDF version of my commonplace book to you.

You can get in contact with me either by our contact form or by sending a DM over on Twitter to @podcasterJay, and I’ll happily send it on over.

In Closing

As with previous years, using the time and budget that RJJ provide for training and continual development, I feel as though I have been able to touch on a number of topics which lie slightly adjacent to development, then apply them directly to my development and engineering practise. And I think that there are two key points here:

• the need to continually learn
• the need to look outside of one’s industry

By continually learning we can ensure that the knowledge we already possess is backed up and refreshed with new knowledge, we also build on that knowledge and are able to move in new directions because of it. By looking outside of our industry, we are able to see familiar problems in a completely new light and are able to appreciate novel (to us) solutions to those problems.

I always recommend that developers continually learn, and look outside of their industry (or there section of it) as there’s always something to learn and bring back to your work. After all, that’s how the DevOps movement started: applying the Toyota Production System to software development, via the lessons taught in The Goal (by Eliyahu M. Goldratt) and Kaizen (by Masaaki Imai).