In this blog, let’s unravel the human aspect in software development, why egoless programming is not given due importance in software development, understand what is egoless programming, and delve deep into the ten commandments of egoless programming.
Ego is the sense of self, and to an extent, the amount of self-importance that you can give to your abilities and talents; having an ego is excellent to push yourself forward in a competitive world, but too much of it can be a bane making you come across arrogant, stubborn and resistant to change.
What does ego have to do anything with programming? What is egoless programming??
Software engineering and development is deemed a very technical domain. It is assumed that the technical failures can be easily navigated by coming up with a few quick-fix solutions.
Software is developed by the people for the people, thus making it is impossible to exclude the human factors involved in developing software.
Many of us overlook the human aspect behind it, and why do we do this?
Say a software development project fails, the managers and the team involved can easily quantify and assess the extent of the failure and develop measures to mitigate upcoming issues. Still, human factors or soft skills such as emotions, leadership, teamwork, motivation, multi-culturalism, etc., tend to be unquantifiable and challenging to assess.
Many times, it has been noticed that several of the key software development failure difficulties boil down to just different human variables. Still, researchers’ or software practitioners’ lack of attention to these elements has pushed the influence of soft skills on programming to the back burner.
Searching for “egoless programming,” “psychology of computer programming,” or “software psychology” yields very few results on google scholar or google, but you can find thousands of results on cloud computing. We can find few research materials on the Psychology of Programming Interest Group (www.ppig.org), but studies are just the tip of the iceberg, and there is more left to discover.
Of the very little information in software psychology, a few thoughtful personalities have expressed the importance of the people aspect in software development: Gerald M. Weinberg, Edsger Wybe Dijkstra, and Tom DeMarco. Among them, Gerald M. Weinberg’s in his book “The Psychology of Computer Programming,” describes how programming is a social activity and more specifically explains the concept of egoless programming.
What is egoless programming?
The idea behind egoless programming is that the programmers must understand that their programs are independent of themselves and try not to reject any constructive criticism towards their program. The programmers must strive to treat their designs and implementations as independent objects and focus on the overall betterment of the final product rather than being stuck on high ground.
Egoless programming has also turned out to be a very misunderstood concept since everyone assumes that programmer ends up having no say in their program or participating without any interest.
This thought is a misunderstanding! Let me explain why
Ego is a person’s identity; entangling one’s identity with their program and clinging to it leads to many problems. Carrying less of their ego helps create a beautiful balance where the programmer is accepting criticism and, at the same time, is aware of their contribution to the code.
In recent years, Gerarld Weinberg himself has come out to clear the misconception associated with egoless programming; he mentions that those who disagree with the concept of egoless programming in software development have taken the term in its literal sense. Instead, it just means being open to the team members’ error reports and reviews and not viewing it as a personal attack or a question of their programming skills.
And it is no surprise that there is a lot of evidence to support that peer-reviewed codes produce codes that are free of error and reduce additional costs to an organization.
Team review approaches or pair programming with Extreme programming have been observed to provide better results. Thus, indicating that creativity, knowledge, and expertise that the peers bring in cannot be replaced by the mere use of technologies such as CASE tools.
One of the essential things that programmers have to notice is that software development is not like books where the authors are given final credit. Instead, it involves creating a foolproof product for the audience to use, so the programmer can’t stand in the way of development, stating that they are the final say in this program. There is no other option but to accept critique to create an error-free cost-effective program.
In the book, Psychology of programming Gerald Weinberg lays down the ten commandments of egoless for programming that serves as a roadmap for a software engineer, project manager, or any other stakeholder involved in developing softwares as an individual or as a part of a team.
Let us take a look at the ten commandments of egoless programming.
- Understand and accept that you will make mistakes.
- You are not your code.
- No matter how much “karate” you know, someone else will always know more.
- Don’t rewrite code without consultation.
- Treat people who know less than you with respect, deference, and patience.
- The only constant in the world is change.
- The only true authority stems from knowledge, not position.
- Fight for what you believe, but gracefully accept defeat.
- Don’t be the “coder in the corner.”
- Critique code instead of people, be kind to the coder, not the code.
1. Understand and accept that you will make mistakes.
Mistakes are part of the learning process for any activity in life, and it applies to coding too. Organizations need to understand that mistakes are a part of programming. To catch these mistakes, the organization must create a proper system by inculcating technical peer reviews and other best practices to evade such coding mistakes.
One way to avoid mistakes is to do repeated testing, ensuring that a minor mistake doesn’t get labeled to be a personal issue. Unless the program is built for safety-critical projects, the programmer and the organization must accept that a few errors are common. The faults are rarely deadly, and the organization will have a system in place before the code errors reach the production stage.
2. You are not your code.
First and foremost, a developer must understand to separate themselves from their code; they can achieve this by being open towards the criticisms directed towards the code. It can be challenging to implement this since the code reflects your ideas, thoughts, and creativity in solving a problem, and any flaw found can be a hit to the developer’s confidence.
There can be moments when you cannot implement a code due to bugs, but the developer must look at the larger picture and not get caught up in the loop of defending their code.
3. No matter how much “karate” you know, someone else will always know more.
As a seasoned developer who has spent long-time writing programs and developing softwares, you might come to a point where you realize that you know more than others and might even feel offended if someone brings up a different opinion or finds a minor bug in your code.
As stated in the above command, a developer must realize that everyone is on the path of continuous learning, and there is always someone who knows a concept better than you do. Developing a sense of humility in your coding life allows you to be open to diverse points of view and not dismiss them as irrelevant or inferior to your input.
4. Don’t rewrite code without consultation.
When you are entrusted with reviewing a code, you must understand that there is a fragile line between fixing code errors and rewriting the code entirely. It is important to note that you must refrain from completely changing the code to make it better.
There is a tendency for programmers to think why he did it this way and rewrite the entire code, thinking they can write it better, but they fail to understand the basic law of programming that reading a code is more complex than writing it.
So, when the programmer starts rewriting the code, they must realize it will not be better than the previous one; instead, it is just going to be messier. Therefore, it is best to make stylistic changes to the program where required rather than rewriting the entire program from scratch.
- Treat people who know less than you with respect, deference, and patience.
As part of the software development projects, developers are constantly interacting with non-technical personnel as well as new developers; in a scenario such as this, there can be a clash of cultures, expertise, style, or preferences.
The best way to deal with a varied set of opinions and behaviors is to be open and inclusive, and this encourages everyone to share their inputs without the fear of being dismissed.
If you treat everyone involved with respect, deference, and patient, there are chances that you can break the negative stereotypes associated with the software developer by bringing in productivity, equality, and knowledge sharing within your team.
6. The only constant in the world is change.
Change is inescapable, and this rings very true in software development. The field is constantly bombarded with new processes, tools, and upgrades. Though it can be overwhelming at times as a developer, it is essential that they accept this change as part of their learning process and embrace it.
A programmer must accept every new challenge as a stepping stone towards learning a new skill rather than looking at it as an obstacle that hinders them. It might be easier said than done, but embracing new challenges can help you stay ahead of the curve in the job market and prevent you from being outdated.
7. The only true authority stems from knowledge, not position.
Cultivating knowledge is the best way to survive in an egoless environment. A show of your authority can only take you so far in achieving your peers’ respect. As a programmer, one should note that gaining knowledge goes a long way in attaining the respect you deserve and growing the circle of influence in your field.
It is preferable to improve your skill-set and aid others along the road rather than resorting to bad-mouthing, office politics, and so on; in the long run, knowledge has the power to offer you the authority you deserve.
8. Fight for what you believe, but gracefully accept defeat.
Often, other people’s ideas will be preferred over yours; in such cases, you must articulate your beliefs and stand up for what you believe in.
Even after stating your thoughts, if your colleagues do not agree or your management is considering a new direction, it is essential to abandon your proposal and recognize that software development requires the ideas of the entire team, not just you.
In the long run, if you find out that your idea turned out to be a valuable suggestion, do not turn around and say “I told you so” or be vengeful.
9. Don’t be the “coder in the corner.”
Programmers tend to work alone and become detached from their colleagues in the process; being that guy in the corner who does not collaborate with anyone does not allow them to grow or learn.
Working in a collaborative environment, engaging in conversations can prove beneficial for a programmer to enhance their skills, build positive relationships and open their doors to endless career possibilities.
As a result, it is best to break free from the mold of being a lone programmer in the darkroom and try to thrive in a social setting.
10. Critique code instead of people, be kind to the coder, not the code.
When reviewing a code, a programmer must keep their comments positive, and all the comments must focus exclusively on improving the code. A coder must keep their ego in check by demonstrating empathy toward other coders and refraining from making personal remarks.
A reviewer can follow a structured format while reviewing the code to ensure that the comments do not turn into a personal attack on the coder.
Conclusion
Egoless programming in software development includes the best practices to tackle complex problems such as communication issues among the team members, promote a collaborative environment, improve the code, develop empathy towards each other and ultimately value the code first and not the coder.
The ten commandments of egoless programming give a head start by assisting the programmers in dropping the traditional hierarchical setup and developing an egoless working environment.
You keep your softwares always up-to-date, right? Be informed about the IT & Remote work news and click on the link: https://mailchi.mp/rolloutit/newsletter
