The Pragmatic Programmer EP.2 — A pragmatic concept

9 min readApr 7, 2022

Be yourself!

In the programmers’ world, in a company, some people may appreciate working in their roles whereas others feel uncomfortable with them. That’s because we have differentiated backgrounds. We commonly perceive one thing in different senses. Then, we must not push our sensations under the pressure to become the other people we don’t want to be, just follow our hearts. If you want to do something and you have to talk to the first one, but (s)he says no. Don’t worry, just move on and talk to another one instead. For example, if you want to use a work-from-anywhere basis and you think it is possible in your position, you may ask your manager. If (s)he declines it, let’s move to consult with your team leader. If (s)he is okay with it, he will suggest or give you some help to make your dream come true. It’s not possible that every people around you will always disagree with you. Anything is not right or wrong. It depends on yourself how you feel about it. So, it’s your life. Don’t care about the other things too much.

Accountable for errors

First of all, let’s talk about team trust. Whenever you are surrounded by strong trust, you will safely show your mind, and pleasure to share your idea. Team members count on each other. As we know, in the case that you break down your colleagues’ trust, it is hard to build it up again. Let’s imagine together, detectives take a whole year to assemble all evidence for a puzzle murder case. On a judgment day, you say “Sorry buddy, my Siberian Husky slept on it and I left it at my home”.

Turning on to the responsibilities, as a programmer, you just commit to ensuring that something is correctly working, but you do not control every aspect of that commitment, because, to do that, there are many uncontrollable factors even though there are solid working procedures, strong coding conventions, concrete testing pipelines. Something wrong may occur whenever and wherever. The thing that you possibly do is that don’t blame anyone, anything or make up excuses or tell shortly that it is late. You just tell your upper levels what happened, what you have done to solve the problems, what remaining things to do, and how much value your work. But, if you know that your thumb drive will be lost, it’s your fault if you have ever backup it and tell your boss that my husky has swallowed it already. Lastly, before letting your leaders know, tell yourself or your husky by those statements and think that what they will say, it is reasonable or not?. Remember, don’t be afraid to ask for additional things which contribute to your tasks successfully, such as more time spent, new techniques, or technology.

Software entropy

Entropy is a physics concept associated with the amount of “disorder” in a system [Wikipedia]. The higher entropy, the more messed up your software will be. It becomes “software rot”, or what some people called “software debt” or whatever. Psychology and project management culture are two factors that may contribute to software rot. One thing we can do to prevent it is to avoid living in houses with broken windows. This means that when we leave one broken window unfixed, the second one tends to happen and is also ignored. Then, we have to repair that as soon as possible and take action to block further damages. Moreover, don’t break any more windows even though there are many rush tasks, for example, deadlines, ad-hoc tasks, etc. Just keep in mind that you must not be the one making more additional damage.

Catalyst

Three soldiers came back home from war hungrily. They expected that all villagers should serve them delicious foods, but they found all villagers keep away in their homes because of lacking food. The soldiers decided to boil a pot of water with three stones. Amazingly, villagers came out and watch it. The soldiers described told them that it is a stone soup. One of the villagers told that carrots can make the soup tasty. Then, that villager ran out to get carrots. Another villager told that it should be great if we add potatoes. Then, he came back with a few potatoes. An hour later, the soldiers listed out all ingredients such as salt, beef, and herbs to the villagers. After that, the soldiers remove all stones from the pot and they finally enjoy the first large pot of soup after starving for over months.

The soldiers in this tale act as a catalyst — someone who brings the villages to produce something that they have not ever done by themselves. Now we can imitate the soldiers in the position of software developers. You may meet the comparable situations in which you know what you need and how to do it, but you need permission to build it, approval for budgets, or something complicated. So, you have to let someone involving see. Once they surprise by what you do, you can ask permission to add something you want.

Let’s move to the villagers’ side, it considers a software development team. All of us have anomalies seen happening things and we perceive all small changes. In the end, the system ran out of original specifications. This can be both positive and negative effects on team member’s feelings. Anyway, focus on the big picture, see what’s happening, not just personal tasks.

Good-enough software

Writing a good-enough program means good for users, good for future maintenance, and good for your own peace of mind. It makes sense to write a program to meet users’ requirements, standard performance, and privacy and security protocol. Have you ever asked how good the software is which users want?. A differentiated application for different purposes is commonly base on different requirements. For example; marketing applications have promises to keep whereas banking software must handle the correct amount of payment. So, we can turn all of these into systems requirements, and prioritize features by the requirements. Fortunately, nowadays, our users tend to reach a rough application rather than all-implemented ones. This will be our opportunity to improve the software according to users’ feedback. Nevertheless, don’t forget to see it from the top view of a solution, don’t be afraid to stop if you walk to wrong way, then start it again.

Knowledge portfolio

Our world changes every day. It surely forces us to learn new things habitually because your existing knowledge today is possibly obsolete tomorrow. This directly impacts our value and our implemented products. So, we must have the ability to update our knowledge portfolio to track new technologies or technicalities. It can be achieved by this guideline:

Invest regularly: Don’t care about the size of what you are investing, just take time constantly until it becomes a habit. Let’s see sample goals in the next section.
Diversify: As many people said, you are what you eat, trying to learn a variety of new technologies which are related and unrelated to your working project, including non-technical skills.
Manage risks: Don’t try to learn all things at high risk or all things at low risk. Trying to make it balanced is a good strategy, for example, partially learning a new programming language and partially updating new features and plug-in tools of a stable programming language.
Buy low, sell high: Learning emerging technologies before it becomes popular has more chance to get rewards than other people.
Review and rebalance: Perhaps the emerging technology that you have just started is already down. So, trying to review and rebalance it.

To comply with this guideline, we can set up the goals like this:

Learn at least one new programming language every year: A new language will allow you to use more tools than ever.
Read a technical book every month: Not only content in the books are benefits you, but also reading books on familiar topics will build you to love reading.
Sporadically read non-technical books: A soft skill is an important key for easily working with other people, especially in management areas.
Take courses: Taking courses may lead you to new interesting areas.
Participate in user groups: Face-to-face meeting is a classic approach to exchange opinions, not just go and listen, but try to participate.
Try different environments: If Mac always facilitates you, let Windows accommodates you to build something instead.
Stay updated: Keep in touch with a daily news or online post unrelated to your working areas. This will be the way you receive other people’s perspectives valuably.

Opportunities to learn

Seeking for solution: When you got a question that you cannot find the solution. Don’t let it go, but carefully think about it, google it, or eventually ask the ones who can lead to your answer. They feasibly give you further networks to obtain the answers. At that time, you may get a jargon of knowledge from them.

Ready to read: Preparing an e-book to spare whenever you have a short waiting time is a great opportunity to learn.

Critical thinking

To ensure that the knowledge you’ve got is correct or not, you may apply these questions:

Five “Why”: Repeatedly ask at least 5 times of “why” questions will let you understand the root causes.
Who does this benefit?: It’s indisputable that one who received the benefits will be the key to answers.
What’s the context or purpose?: Practicing by questioning to get core context.
When or Where would this work?: Thinking of the next second step what will happen, not just a next step.
Why is this a problem?

Communication

Developers seem to contact on many levels. Here is a list of ideas that may help to make a seamless communication.

Understand your audience’s nature: Before you begin speaking, it is important to ascertain your audience’s interest and wants to easily reach their points.
Plan what you want to say: You have to list out the strategies to present your ideas and plan what context you want to say.
Select the suitable time: Time slot affects the audience’s concentration. So, you have to ask for the right time that you think it is proper to speak about your topic, for example, avoiding Friday night for a serious topic.
Choose a communication style: A communication style should be appropriate to the level of listeners.
Well-prepared content: You must carefully prepare your idea and don’t forget to check the document’s spelling.
Review by audience: If it is possible, let your audience briefly review your agenda and content.
Listen to your audience: Engaging the audience by answering all their questions is very helpful and they will impress you.
Response to people: In the case that you cannot answer your audience’s questions, you just try to take notes and tell them that you will answer them later, not ignore their questions.
Documentation: Writing the documents to communicate your purposes is mandatory. For example, in the programmer aspect, commenting objectives for exported functions is a great idea, but it is not necessarily to write down what codes have done because codes do.

Thanks to The Pragmatic Programming book for above knowledge, if you are interested in reading this book, click here for more detail.