The Programmer's Apprenticeship - 01: The Art of Fighting Back

Reading Notes Reading Notes The Programmer's Apprenticeship

Word count: 2.2kReading time: 13 min

 2018/09/19

This is the first post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great (a compilation of Jeff Atwood’s posts). The author, Jeff Atwood, is one of the founders of Stack Overflow. His articles cover a wide range of topics. He is a seasoned programmer, manager, and entrepreneur. This book discusses many things beyond programming. Whether you are a junior engineer or a senior engineer, this book is worth reading. As your experience grows, every time you re-read this book, you will gain new insights. Just as the title “From Good to Great” suggests, the author points out the path for you, but whether you can succeed depends on your own cultivation.

I will excerpt some wonderful remarks from the book and sometimes add my own insights or experiences. The outline of the reading notes is consistent with the outline of the book itself. This is also a method I learned from another source and have been using: “How to Read a Book”. I record it for my own frequent review and for readers’ reference. Below is the The Programmer’s Apprenticeship reading note series:

To-Do Lists Are Unreliable

The author complains that new TO-DO apps are born every day, yet many people still can’t manage their time well. TO-DO lists are becoming thankless tasks:

The list gives you the illusion that you are making progress.
The list gives you the illusion of completion.
For those unfinished items, the list makes you feel guilty.
For those always-delayed items, the list makes you feel guilty.
For things you don’t want to do and haven’t done, the list makes you feel guilty.
You prioritize incorrectly based on the list.
Lists are not efficient enough.
Lists devour the joy of doing things proactively, making you feel that doing things has become an obligation.
In the long run, lists don’t make you more organized.
Lists make you lack initiative.

The author’s suggestion is: when you wake up every morning, if you can’t use the brain God gave you to think of the three most important things you need to do today, then you must first solve this problem seriously. You have to figure out what is most important to you and what can fill you with passion.

Tools are fleeting, but your brain will be with you for a lifetime. Trust it, train it.

You Can Slacking Off at Work Today

This section mainly discusses Google’s “20% time” theory: at Google, theoretically, you can use 20% of your work time to do whatever you want. many of Google’s great software products took shape during this 20% time, such as Gmail, Google News, Google Talk, AdSense, etc.

Whether it can really be implemented in a company depends on the company’s support:

Is the company’s project schedule loose enough?
Does the company culture tolerate “daydreaming”?
Is failure acceptable?
Are personal experiments respected?

It should be easier to implement in a company dominated by engineer culture. “Important innovations and improvements may come from anyone in the company at any time in a bottom-up manner—they won’t pop up by themselves at predetermined intervals according to a magical master plan.“

You Haven’t Persuaded Me

This section uses an example from The Last King of Scotland to illustrate the importance of persuading others. If you want to implement something, you can’t just express your point of view and wait for others’ judgment. You have to persuade others to accept your point of view: If you want to influence others, you must have the ability to persuade them.

For software engineers, what they need to know is not just how to write amazing code, but more importantly, how to sell their ideas and products.

The author gives a grassroots method specifically for persuading others:

Overall, his point of view is quite excellent.
His way of doing things is bottom-up, not top-down.
He always takes the lead in doing things personally to win the trust of others.
He has enough patience to wait for opportunities.

If you keep silent blindly and always look on coldly like an outsider, you can’t change anything. If you want to change your work and life, you must learn to persuade others. For some people (like me), they are often trapped by this. I summarized the reasons, which can be considered as areas that need to be strengthened in my future career:

Personality reasons
Lack of confidence
Insufficient preparation

Of course, to forge iron, one must be strong oneself. Recently, a sentence from an interview left a deep impression on me: A recognized cow (awesome person) should be:

You are capable yourself: Strong technical skills.
Others say you are capable: Recognized by everyone.
Those who say you are capable are also capable: Recognized by the industry.

Truly Failed Projects

Don’t be afraid of failure, and don’t actively seek failure; failure will come to you. No matter what project you are doing, do it with an attitude of learning and exercising. It is absolutely worth it. Compared with the result of the project, the process is the greatest wealeth.

If you haven’t learned anything from the process of a project, this is the truly failed project. So in real work, projects should be reviewed in time after completion to summarize experience and lessons learned, so as to prevent stepping into the same pit next time. Even in failed projects, there is a wealth of experience.

Passion Creates Genius

I really like this sentence: “I will dedicate the remaining 5 days of the course to making them smarter, rather than showing them how smart I am.” Whether doing training or writing a blog, you must have this mindset. You are not showing off how powerful you are, but letting those who read the blog or attend the training learn knowledge and gain real growth.

Don’t be intimidated by developers around you who are more talented than you. Diligence can make up for clumsiness; passion creates genius.

Don’t Call Yourself an Expert

The author uses Wikipedia as an example. Experts do not have more privileges. In front of knowledge, everyone is equal. Sometimes, precisely because you are an expert, more is expected or required of you.

As the ancients said: In a group of three, there must be a teacher for me; hearing the Dao has a sequence, and there is a specialization in skills, that’s all; nothing else, just practice makes perfect.

As an expert, the important thing is not to tell others what you know, but to be clear about what kind of questions you should ask, and to flexibly apply the knowledge you have mastered to solve the specific problems at hand. As an expert, your role is to provide intelligent, actionable direction.

Recently, the issue of experts was also mentioned in interviews. The author also introduced several stages here. You can check yourself against them using the following stages. Remember to abandon your domain, professional knowledge, fame, and reputation, and then reshape yourself according to the following stages:

Stage 0: I overcame carelessness
I understand now, I need to learn something.
Stage 1: I overcame fear
I think I can learn this subject or skill. I will become very knowledgeable about it, and will not be afraid of people who know more than me.
Stage 2: I became organized
I no longer feel like I’m pretending to know or incompetent. I feel I have the ability to participate in discussions or practice. I am confident in what I say.
Stage 3: I surpassed my own abilities
I now feel that I have higher requirements for myself. I no longer stop at “just getting by” and feeling complacent. I want to take some risks, be creative, keep learning, keep pushing myself to improve, and I want to work with enthusiastic people.

Ninety Miles is Only Half of a Hundred

This section is mainly about project management, including personal project management and team project management. If you always say “it’s almost done,” then you need to think about whether there is a problem with your project management. The author suggests: Encourage and force programmers to create a list of everything they have to do, then list sub-items for each of them, and include all sub-items as much as possible.

Here are specific possible measures. Use them in your project:

List everything you need to do in a large project, including infrastructure work, such as configuring branches for the source control system.
Estimate the time required for each item in this list. This initial estimate can help you see the approximate time spent on the entire project.
Look at how much time each item in your list will take. If an item takes more than one day, break it down into several smaller items. This way of breaking down large tasks into small tasks is a key step in solving the “only 90% complete” problem.
Find a way to present the status of tasks so that interested people can understand.
Track the progress of daily tasks, and put the original plan and actual completion time of each small task on the same table, so you can control the work progress.

There Must Be Trust in Management

Trust can solve the problems of managing large software, but trust cannot replace management. The two complement each other.

Boyd’s Law of Iteration

Boyd’s Law of Iteration: The speed of iteration beats the quality of iteration. That is what everyone often says: in the world of martial arts, only speed is unbreakable.

Ten Years to Sharpen a Sword

Gmail’s road to success was long. Many people didn’t think much of it at first, but after the product was released, user feedback was very good.

Legends of overnight fame are easy to lead people astray and are very harmful. If you plan to make something brand new, be prepared for a protracted war.

The author believes that success requires years of hard work. You must steadily spend several years polishing this thing. Wake up every day and start working, stick to it day after day, constantly get feedback, and do better every day than in the past. Even if you are occasionally unhappy or even lose the fun, these are all necessary to achieve success.

The author also cited the example of writing a blog. With day-after-day investment, it took the author 3 years to make his blog have a place in the industry. In this current impetuous environment, I believe that those who can calm down and continuously output knowledge will definitely have good results, as long as you believe: What you are doing is truly worth doing.

The Programmer’s Apprenticeship (or Building a Career in Software) is a compilation of the best articles from the Coding Horror blog. The book is divided into 8 chapters, covering topics such as time management, programming methods, web design, testing, user needs, the Internet, game programming, and technical reading. The topics selected by the author are all pain points in a programmer’s career. Many articles have high click-through rates and reply rates on blogs and the Internet. —— from Douban

Jeff Atwood founded the Coding Horror blog (codinghorror.com) in 2004 to record his thoughts and bits and pieces of his software development experience. Today, the blog has nearly 100,000 visits per day. Readers participate in comments, and various views and wisdom collide passionately there. —— from Douban

The writing style of The Programmer’s Apprenticeship is humorous, understanding, and caring; it is suitable for programmers at all stages from novice to veteran, and also suitable for students of computer science and related majors who are about to become programmers. The Programmer’s Apprenticeship can help readers pay more attention to the human nature and humanistic factors of technical work, thereby achieving a successful turning point in their programmer career. —— from Douban

About Me && Blog

Below is my personal introduction and related links. I look forward to exchanging ideas with fellow professionals. “When three walk together, one can always be my teacher!”