The Programmer's Apprenticeship - 02: The Way of Programming

Reading Notes Android Jank Reading Notes The Programmer's Apprenticeship

Word count: 3.3kReading time: 20 min

 2018/09/20

This is the second post in the reading notes series for The Programmer’s Apprenticeship: From Good to Great. 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:

Remember Not to Be One-Track Minded

Excellent programmers are good at programming. The way to become a more excellent programmer is to put aside programming. You must cultivate enthusiasm for everything surrounding programming.

Bill Gates mentioned in an interview in 2005: “The essence of work is not working behind closed doors. The most scarce talents are those who have super comprehension of engineering technology, can establish good relationships with core developers, and can act as a bridge between customers, marketing, etc.”

The wider your interests, the more competent you will be in your job.

The Broken Windows Theory

The Broken Windows Theory: If a window in a building is broken and left unrepaired, other windows in the building will soon be broken. A broken window that has not been repaired for a long time sends a signal that “no one cares,” which makes people feel that even if they break more windows, they will not pay any price.

From a programming perspective, the broken windows theory also exists, and you need to take timely measures: do not let “broken windows” (poor design, wrong decisions, or terrible code) go unchecked. Once discovered, they must be repaired as soon as possible. If there isn’t enough time, isolate them first. You can comment out these unpleasant codes, or display a “not yet implemented” message, or use fake data instead.

Programming pays great attention to detail! If you cannot master these details, you will have a feeling of losing control, and it is only a matter of time before your project goes out of control. Perhaps we should be cautious.

Love It or Leave It

The most outstanding programmers I know have a lifelong passion for what they do. They will never switch to other things because of a slight economic fluctuation.

For programming: Love it or leave it.

The Beauty of Simplicity

In the field of programming and development, it is easy for people to fall into the mindset of “newer is better” and forget that “ideas are often more important than code.”

The evolution of Forth points out the guiding principles Charles had when inventing and implementing the Forth language:

Stay firm
Don’t speculate
Do it yourself

Charles believes: Simplicity must be enforced, not just as an optional goal. In reality, many developers find it difficult to keep programs simple because they don’t say “no” when they need to make tough decisions. Instead, promising everything and compromising everywhere is much easier.

Many people look down on OPPO (phones), but OPPO’s system maintains the beauty of simplicity in design, so the system feels very light and comfortable to use. Even after long-term use, there are rarely stutters. Its performance on low-end devices is also much better than competing products. This also fits OPPO’s development philosophy: prioritize basic experience (fast, power-saving, stable).

Be Happy to Delete Code

If there is a piece of code you no longer need, please truly delete it instead of leaving it idle. The main reason is to remove noise and uncertainty. One of the most difficult things developers face is the noise or uncertainty of the code flow, because this will affect their future work efficiency. Useless code will trigger other developers to think:

Why was this code written like this before?
Why is this new code better?
Will we reuse the old code in the future?
What are our criteria for judgment?

In the current era where Git is rampant, you should not keep useless old code. If you want to see the previous writing, it’s just a few lines of Git commands. If you can’t have a good reason not to delete it, then deleting it is reasonable.

Are You Cut Out to Be a Programmer?

This section mentions that not everyone is suitable for programming. In fact, most people cannot learn programming. The deciding factor is their attitude towards meaningless things.

Formal logical proof, expressed in a formal system called a programming language, yields results by performing specific calculations. This is actually completely meaningless. To write a computer program, you must compromise and give the program some meaning, but no matter what you want the program to do, the computer will run according to these meaningless rules and get some meaningless results. In tests, those with stable mental models showed innate acceptance in this regard. They all have the ability to see the mathematical calculation problems behind the rules, and follow those rules no matter what. On the other hand, those without stable mental models always can’t find a clue.

Do You Follow the Rules?

I feel the title of this section isn’t great. “Xun Gui Dao Ju” (Follow the rules): Originally meant sticking to the rules and not daring to violate them. Now it also refers to sticking to old standards and not daring to make any changes. But the text talks about whether you follow basic rules.

This section can be interpreted as: Many things, including software development, have certain routines or basic rules. These routines or basic rules have been verified by everyone. When you want to do something, it is best to follow these routines or basic rules. For example, the author lists 12 steps to writing better code from a blog post:

Do you use a source control system?
Can you complete a software build in one step?
Do you release a build every day?
Do you have a bug tracking database?
Do you fix bugs before writing new code?
Do you have an up-to-date software development schedule?
Do you have product specification documents?
Do programmers have a quiet working environment?
Are you using the best commercial tools?
Do you have testers?
During the interview process, do you ask candidates to write code?
Do you do usability testing?

Although the above are all questions, the answers should be yes.

Core’s Law: Stick to One Goal

Core’s Law: Stick to one goal. This law is reflected in several core principles of modern human settlement development:

Don’t Repeat Yourself (DRY)
Once And Only Once (OAOO)
Single Point Of Truth (SPOT)

Core’s Law also tells us to consciously choose what your code doesn’t do.

The Most Awesome Coding Routine

Contrary to what you believe, simply burying your head in work every day is not true exercise – attending meetings does not exercise your interpersonal skills; replying to emails does not improve your typing skills. You must set aside time regularly for concentrated exercise so that you can do things better.

The above theory is also emphasized in two books I highly recommend, Deep Work and Peak: Secrets from the New Science of Expertise (if you haven’t read these two books, I suggest you take a look): Ten thousand hours is not repeating one hour ten thousand times, but putting your heart and soul into learning, thinking deeply, and summarizing every hour.

In addition, the author also mentioned “study hard”: constantly challenge things beyond your own ability. The main value of learning and training lies in discovering weaknesses and improving them specifically. “Studying hard” means often dealing with problems that are just at the limit of your ability, that is, things that have a high probability of failure for you. If you don’t experience some failure, you may not grow. You must constantly challenge yourself and exceed your limits.

The author listed some routines (those that can truly be implemented. Some are long, but I still copied all the items because I want to implement them myself):

Write your own resume. List all your relevant skills, and then mark those that will still be useful in 100 years. Score each skill, out of 10.
List the programmers you admire. Try to include those you work with, because you will gain some skills from them at work. Record 1 or 2 shining points about them, which are the areas you hope to improve.
Check the “Computer Science” section on Wikipedia, find the “Pioneers in Logic and Computing” category, pick a person from this list, read about their deeds, and open any links you are interested in while reading.
Spend 20 minutes reading other people’s code. Reading excellent code and reading terrible code are both beneficial. Read both, switching in turns. If you can’t feel the difference between them, you can ask a programmer you respect to show you what excellent code is and what terrible code is. Show the code you have read to others and ask for their opinions.
List your 10 favorite programming tools—those you think you use the most and can’t live without. Randomly pick one tool and spend an hour reading its documentation. In this hour, try hard to learn a new function of this tool that you were not aware of, or discover a new way of using it.
Think about it, what are you best at besides programming? Think again, how did you become so skilled and professional through exercise? What inspiration does this have for your programming work? (How to apply these experiences to programming?)
Take out a stack of resumes and stay in the same room with a group of interviewers for an hour. Ensure that each resume is read by at least 3 interviewers and given a score of 1 to 3. Discuss resumes where judges’ judgments differ widely.
Participate in a phone interview. Write down your feedback afterwards, throw out your views, and then chat with the person hosting the phone interview to see if you reached a consistent conclusion.
Conduct a technical interview, and the interviewee should be an expert in a field you are not very familiar with. Ask them to assume the audience knows nothing about that field, so ask them to start from the basics. Try hard to understand what they say, and ask some questions if necessary.
Have the opportunity to participate in other people’s technical interviews. During the process, simply listen carefully and learn seriously. While the candidate tries to solve technical problems, try to solve these problems in your own mind.
Find someone who can exchange practical problems with you. Every other week, exchange programming problems with each other. Spend 10 to 15 minutes trying to solve these problems, and then spend 10 to 15 minutes discussing (whether solved or not).
When you hear any interview question that you cannot solve immediately, hurry back to your seat and email the question to yourself as a reminder for the future. Find some time during that week to solve it in your favorite programming language.

In addition, the author also mentioned some suggestions listed by Peter Norvig:

Communication with other programmers. Read other people’s code. This is more important than any book or training course.
Write programs! The best way to learn is to learn by doing.
Take programming courses during undergraduate or graduate studies.
Find some projects to do, and cooperate with other programmers to form a team. During the project, learn to distinguish the best programmers and the worst programmers.
Work with other programmers on projects, understand how to maintain code not written by you, and learn how to write code that is easy for others to maintain.
Learn many different programming languages, especially those with different worldviews and programming models from the languages you are currently familiar with.
Understand the impact of hardware on software. Know how long it takes for your computer to execute an instruction, how long it takes to fetch a word from memory (with or without cache), how long it takes to transmit data over Ethernet (or the Internet), how long it takes to read continuous data from disk or jump to another location on disk, etc.

Finally, the author also expounded his own programming routine:

Write a blog. I started the CodingHorror.com blog in early 2004 as a form of my own effort to learn. It was humble at first, and later became one of the most important things I have done in my career. So, you should also write a blog. The people who finally “become famous” are often those who can write and communicate effectively. Their voices are the loudest; they are setting the rules of the game and leading the trends of the world.
Actively participate in famous open source projects. All the high-flown talk sounds good, but are you a brag or a doer? Don’t just talk, do it. This is very important because people will measure you by your actions, not your words. Try hard to leave something tangible and useful in front of the public, so you can say, “I contributed to that project.”

When you can write wonderful code and explain that code to the world with wonderful words, then I will feel that you have mastered the most awesome coding routine!

Being Alone is Shameful

I think the harm of programming alone expounded in “Creating My Own Personal Hell” cited by the author in this section is worth pondering:

Some people declare that “working alone” provides an excellent opportunity to establish their own workflow. However, in my experience, there is no process when the team has only one person. Nothing prevents you from being overwhelmed by a flood of work. When your code is too eager for success, no one corrects your mistakes. No one checks your code. No one guarantees that your code can be submitted on time, tagged well, and subjected to routine unit testing. No one guarantees that you follow a certain coding standard. No one urges you to fix defects in the code in time. No one checks whether you have marked an existing problem as “unable to reproduce”. No one reviews your estimates, or drags you back when you neglect your duty.

No one takes over your work when you are sick or on a business trip. No one helps you when your work is heavy. When you are deeply trapped in harassment calls, boring meetings, and trivial tasks thrown at the last minute (but need to be solved immediately), no one can give you a hand. No one suddenly has a bright idea to help you out of trouble. No one cooperates with you on design, architecture, or technology. You work in a vacuum; in a vacuum, no one can hear your desperate screams.

If you read this content, please take it as a warning. If a company only recruits you as the only developer, please think twice before agreeing. That is simply another kind of hell. If there is a chance, please choose those positions where you can work with other developers, so that you can at least get guidance in the process of working with others, which helps you develop your own skills and keep up with the times in technology.

If you can’t show it to others, what’s the point of beautiful coding skills? If you don’t contact other programmers’ different viewpoints, different methods, and different technologies, how can you learn more skills? Who can check your code and tell you that there is a simpler solution to that problem? If you are serious about programming, you should ask to work with partners.

Individual ability is always limited, it determines that you can only go so far in this field. Find some other smart programmers and work with them. Try to keep yourself humble and low-key, and then you will soon discover that software development is actually a social activity—its social nature is much greater than most people imagine. You can learn a lot from those introverted companions.

Just as we often say, one person can walk faster, but a group can walk further.

Do You Want a Programming Partner?

Under the influence of a healthy software engineering culture, team members improve their work quality and productivity through pair programming. They understand that the time they spend checking colleagues’ work will always be rewarded when others check their own deliverables in turn.

The author even gave data to illustrate the role of Code Review (a bit subversive to my cognition):

In terms of average defect discovery rate, unit testing can only reach 25%, functional testing can reach 35%, and integration testing is only 45%. In contrast, the average efficacy of design and code review can reach 55% and 60%.

There is a lot of fun in programming, one of which is: “You don’t have to do it alone.” So, who is your programming partner?

Software Apprenticeship

Many companies will assign a mentor to new employees. Through this 1-on-1 guidance, new employees can integrate into the company as soon as possible, which is similar to the apprenticeship system.

Studying theory at night and programming during the day — this combination is particularly effective.

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!”