Books/The Mediocre Programmer

From Wiki

Author: Craig Maloney

Most programmers are trying to be great. The author says that in order for a programmer to be great, they must pass through the mediocre stage first. This books is all about going from a novice programmer to a mediocre programmer.

This is not a technical book. It is mostly about life experiences of the author as a programmer and his advice for programmers.

Mediocre Programmer.png

Skill gaps

The tools of the trade are constantly changing. A programmer is expected to keep up with them. There will always be gaps in knowledge and skills required to accomplish the task at hand. The author advocates for a measured approach of learning as much as you can at a steady pace.

Performance anxiety

We compare our backstage with others' performances. "If we strip away the barriers of perceived rank and meritocracy we can better engage with and learn from each other."

Mistakes

Programmers should engage their curiosity. They should give themselves permission to make mistakes and learn from them. Recording our mistakes and their fixes in a journal is a good way of maximizing the learning process.

Community

Joining a good community can help you become a better programmer. It is not always easy to find the right community. Sometimes, you might have to start one yourself. A good community usually has the following:

  • Code of conduct
  • Moderators
  • Spaces for questions and guidelines for questions
  • Joy
  • Compassion and empathy
  • Kindness

Productivity

The machines we work with are tireless, so we adapt to keeping them busy all the time. We aren't giving ourselves the time to relax and reflect. We don't have to be "on" all the time. These are feelings of inadequacy. Periodic breaks are required during work that involve doing something without a computer. The break can be a short one, but it should be a full context switch.

Our desire to meet arbitrary productivity targets is a form of chasing deadlines too. These deadlines can be eliminated as they can cause undue stress. The author talks about a technique that worked for him called "focus containers". A focus container is a short amount of time that you are going to spend on the task, just doing it, not chasing a deadline. It helps get rid of inertia to start a task and also eliminates the stress of completion. Keeping distractions at bay and focusing using containers can lead to stress-free productivity.

The changing technology landscape

Change is the only constant in the field of computer programming. We cannot keep up with the umpteen tools, languages and frameworks coming out every week. This is a losing proposition. We should instead learn how to learn. We should have a deep understanding of our own learning patterns.

Have dedicated learning time everyday. Pick something interesting and learn it well. It should be something that sparks joy. Start with the materials at hand instead of hunting for the best possible materials.

Learning is not like filling a cup. It's more like peeling away the layers of ignorance. Notice your feelings during the learning process and adapt as required to be more engaged in the learning process.

Having a positive mindset towards learning is important. It helps you to not give up too quickly and stay with the subject. Enjoy the journey rather than worrying about whether the skill is valuable in the job market. But it is also okay to give up learning a certain thing sometimes if it brings you no joy. keep the curiosity alive. Don't let Enterprise Java kill it.


Emotions

I felt that the 7th chapter is the most important part of the book. I've read it multiple times. It is an exploration of what leads to programmers burning out.

Programming is usually thought of as a logical, emotionless activity. But there are many emotions going through a programmer's head while programming. There is fear, doubt, insecurity, guilt and shame. There might be a strong sense of the "impostor's syndrome". Programming is itself taxing enough and we have these emotions to deal with as well.

There are many emotional drains.

  • is the work purposeful or futile?
  • is the work engaging or boring?
  • are you awake and active or tired and running on fumes?
  • our desires and our current mental state might be at odds with each other

We should be aware of our mental state. We should learn to be mindful of our emotions, well, to the point that they are not overwhelming or causing PTSD.

We are always telling ourselves a story. We are the central protagonist in this story and our actions determine the fate of the world. But this kind of stories are hardly true. We should focus more on the present and stay aware. For example, we might tell ourselves that if we take a break from our project, it will have such a negative impact that the whole company might go broke. But the reality might be that there will be a dip in team productivity, but people will find ways of working without you. Sometimes the stories can get so worse that we might start doubting our decision to be a programmer in the first place. They are fueled by fear. Snapping out of our own stories takes a lot of practice.

We have to be able to observe our feelings and be curious about them. Your emotions aren't here to work against you. Give them space and try to understand them. Sometimes, professional help might be necessary.

Burnout

We are quite good at bug triage. We should also do emotional triage. It's a form of emotional self-diagnosis. It is your primary weapon against the complicated morass of feelings that burnout is composed of. It is not easy to identify burnout unless you have some practice in noticing your own feelings.

Things to do to alleviate burnout:

  • Realize that we are burned out
  • Examine where our emotions are coming from and their triggers
  • Re-negotiate the current commitments
  • Take some rest
  • Examine if this is truly how we want to live our lives

We have to learn to say "No" to things that are not priorities to us, otherwise we will drown in other people's priorities. Experiencing burnout in a programming career is quite likely, so invest in the necessary preparation beforehand.

After examining our emotions, asking for help is a good next step. Having at least someone to talk to can help whether we think they are capable of solving our problems or not.

Giving up

In the worst case that we realize that there is no more joy left for us in programming, it is okay to give up. It should not be seen as a negative experience. This could in the form of a sabbatical with the intention to come back to programming or a career change. Ignore the sunk-cost fallacy and move on with life. We shouldn't be afraid of the identity change that follows and learn to live with it.

Conclusion

The author wishes that they had this book when they were confronted with the issues in the book. To me, this book feels like it was written by an older version of myself who has survived long enough in this field. My feelings resonate with most of what is said in the book but there are things that I haven't experienced myself yet.

Every programmer's journey is unique. The journey itself is more important than the milestones. One programmer cannot experience everything there is to experience in the world of computer programming. We will find fellow travelers on this journey. We will learn from each other and improve each other's joy and curiosity.


References

1. Book website (full text available)
http://themediocreprogrammer.com