Original work by Paul Isaris, licensed translation by New Frontend.
The preface
This article is part two of the “14 Habits of Effective Programmers” series. You can read the first part here or on my blog.
This first installment of the “14 Habits of Effective Programmers” series covers the benefits of habits in programmers’ daily lives, and how you can benefit from them by making simple but important changes to your work to become better programmers.
Different people have different habits, but forming good habits should be the common pursuit of everyone. Once these habits are established, we can effectively deal with the things in life that are holding us back, such as procrastination, exhaustion, boredom, and the occasional “slackness.”
If you want to excel at great things, you must first form the habit of doing small things. Excellence should not be a temporary thing, but a lasting attitude. “– Colin Powell
Habits make us who we are. Excellence, then, is not an act, but a habit. “– Will Durant
Good morality comes from habit. Just actions make us just, peaceful actions make us peaceful, brave actions make us brave. — Aristotle
Without further discussion, let’s explore 14 habits that can change your career forever and make you an “effective programmer” :
Accept well-meaning criticism
Our programmer’s thinking is a little different from that of ordinary people. We tend to talk about things that only we understand in ways that no one else can understand, until our work annoys the customer or the product/project manager, such as a feature not being implemented correctly, or we don’t understand the requirements of the project correctly. This is where our self-esteem comes in:
This is definitely not my pan! Can I make that mistake? Are they stupid! Do they hate me? Do they have any idea how long it would take to redo this?!
This is a common thought among programmers, but it doesn’t do anything positive, and it just keeps us from facing problems in order to preserve our self-esteem. Know that people don’t take you personally or your problems. If you think you have had a misunderstanding with someone, you should speak out and explain the matter. If you have a bug in your code, make sure you describe it, fix it, and test it. These qualities are essential to being a practical, professional programmer, and don’t let ego or imposter syndrome get in the way.
Your job is not just to be a good analyst, programmer, or technician, but to be an “expert” in your field. When your professional skills aren’t enough, your soft skills come in handy.
Leave camp cleaner than when you arrived
Derived from the famous Scouting principle. In fact, this principle applies to every bit of our daily life, programming is no exception. Many times we need to extend the functionality of a project, or write some new features, so we set up a good development environment, and pull the code from the version control system, and then open the project, only to find that can see is TODO and useless to the methods and variables, and hard coded values and string and unused dependencies.
At this point, we think, well, let’s clean it up, but we’re worried about causing more damage: what if the way I’m going to optimize the naming is used by another part of the project, or even another project? Determining the level of refactoring for a project is never easy, so we need to use unit and integration tests to help us find the affected parts, and of course handling the method scope helps.
If we want to modify a global method, we must ensure that all the places where the method is called are taken care of. Protected methods are relatively easy to change because we only need to check where they are used under the owning class. Private methods are the easiest to change because they have the smallest scope.
Responsible programmers can do much more than rename and refactor. They can also clean up commented out or unused code and unwanted files. In this process, many professional ides can quickly flag whether a method is being used. Also, don’t be afraid to delete commented out and outdated code, because keeping outdated code only adds more technical liability, and you can use version control to retrieve it from previous versions.
Don’t resist working in non-programming classes
A typical programmer’s job is to write code. Even when analyzing user stories, writing requirements documents, and designing database structures, the ultimate goal is to write useful, robust code that helps us implement functionality efficiently. But it’s equally important to get involved in unskilled work and develop your soft skills. Things like communicating with managers, testers, and customers may sound boring, but they can give us unexpected value.
Improving soft skills like communication and management can help you become a better expert, because you can better tell user stories or tell technical details to laypeople without resorting to industry jargon that makes us look like aliens.
In addition, if you can communicate well with managers and customers, you’ll be much more effective at analyzing user stories or estimating how long it will take to implement features. You’ll be able to ask better questions and gain a deeper understanding of the customer’s needs. : -)
Unfortunately, many people think soft skills aren’t important, but almost every employer I spoke with said they value them. The jobs you can choose from are so varied these days, but soft skills will always be an essential requirement.
Write a document
Adding and removing plug-ins, making assumptions, adding installation and build steps, and using a particular version of the command-line tool can be a hassle later if it’s not well documented. This goes hand-in-hand with the “Thinking for later Programmers” in Part 1: You want to make sure others can maintain or build your program.
Verification is as simple as cloning the code onto a brand new machine when the project is complete and configuring it as written in your documentation. Often this process is enough to find missing instructions in your document so you know how to improve it.
Set aside time for rest and exercise
Eight hours of sleep and a daily workout is a luxury most programmers can afford, especially when we’re used to killing time after work by watching TV shows and playing video games. At the same time, junk food has gradually become our daily life. However, it is important to know that a healthy diet and constant exercise have a positive effect on our mood and performance at work.
When you exercise, the blood flow to your brain increases, which helps you wake up and focus on the next project. Staying physically fit is a great way to increase your productivity at work, and exercise as a way to not only lose weight and reduce your risk of disease, but also improve your cardiovascular health and give you more stamina to face the day.
When you exercise, your brain releases serotonin to help you stay awake and do your job better. Serotonin is a neurotransmitter in the brain that sends signals to your body to trigger emotions.
In addition to exercising, a good night’s sleep prepares you for the next day. Often if people are too busy, have too much work to do, have an irregular work rhythm, need to go to school, or need to take care of a child, they will give up some sleep. But while these reasons may seem legitimate, they’re not nearly as real as the boost to memory and productivity that comes after a good night’s sleep.
If you can stay awake in meetings instead of acting like a kid who just stayed up late playing video games, you’ll definitely get your work done better and earn more respect from your colleagues and clients.
Don’t bring your feelings to work
This is similar to “accepting well-intentioned criticism” mentioned in # 8, but it’s not enough to just hurt “programmer’s ego.” In this article, we’ll learn how “experts” can keep their personal affairs from getting in the way of their work.
The first thing to be clear about is that customers who point out bugs in your product don’t really hate you, and colleagues who complain about design flaws and technical liabilities in your code don’t really think you’re a bad person or hate you enough to want to beat you up. Learn to accept other people’s opinions (even if you don’t agree with them) and do what’s good for the job and the project.
Of course, this doesn’t mean you should reduce your personality or accept what you’re told. You still have the right to argue back, but you need to know if your rebuttal actually makes sense. You need to be clear about whether your rebuttal is about pride or mutual benefit.
Make effective suggestions
The biggest difference between junior and senior programmers is their ability to make recommendations and conduct effective code reviews. When it comes to suggestions or code reviews, try to avoid your own biases and focus on the big picture and the “common good.”
Like a good superhero, a good programmer should be honest (not rude) when making suggestions. If you see areas that need refactoring, ask for them, and speak your “professional opinion”!
The key here is to ask yourself one simple question every time you make a suggestion or point out a flaw:
“How to improve?”
If your proposal doesn’t contain any improvements, it’s nothing more than a complaint. Make sure your suggestions lead to constructive discussion and always look at the big picture.
As a senior programmer, you should not only focus on your own advancement, but also care about others. Instead of keeping good advice to yourself, share it and you’ll improve as a team.
conclusion
Developing good personal and professional habits can help a person quickly become an expert in their field. Career development doesn’t happen overnight. It takes time and a consistent attitude. All you have to do now is practice as many of these habits as you can, and one day you’ll become a real expert!
If you have any thoughts on any of these habits, feel free to leave a comment below! : -)
Photo by Zan Ilic on Unsplash