Oh no, is it… already? Holy cow, what time is it? How much time left for me, gosh, three minutes. Rise and shine. Somebody, please save me from leaving the bed today. Maybe I’ll call it sick? Naaa… it’s not fair, I don’t feel sick, it’s probably a laziness. Or maybe not, maybe this is some new, unexplored disease or some lesser known one? I have to see the doctor, but maybe I will google it first…?
You recognize anything? Does it sound familiar to you? Have you experienced any connection with what you’ve just read? Were these words spoken or they just sounded? Was it just an inner voice coming from your soul? Voice of the passenger who actually drives a bus from the backseat. He gives a sense of here and now, so you can experience time and space. A reminder, that Mother Nature and Father Time always go together but also a container full of you. Your believes, opinions, experiences, taste, reactions, character, it’s all there. Being mixed and constantly formed, they are your ego’s fingerprint. This is what makes you special, unique, one of a kind.
The Art Of Being Artist Engineer
Being a programmer, a software developer, is quite specific way of making a living. If you look closely, you may find it similar to being a poet. A poet, you say? Exactly. First, you write. Not for the machine, but for the other people. Computer will not analyze if your code does something stupid, simple, complex or necessary. Its job is to make sure the code is syntactically valid, if so, change its form to something digestible by the CPU and run it. It doesn’t care if particular instruction drops whole database or just sends and email. It won’t complain about function or variable name, from its point of view business rule is completely abstract idea.
Just like a poetry, writing programs is about sharing your ideas in such way, so other developers get them quickly and have a good time reading it. Just like romantic souls taste every line of their favourite poems, so should other programmers when going line after line through your composition. And just like every writer, poet, musician or artist, you are attached to your work. The more it costed you, the stronger your affection is. You put your heart and soul to make it as good as possible, you carefully named variables and functions, architecture is flexible and open for extension. No matter how business requirements will change, thanks to loosely coupled and highly cohesive modules, the code is future-proof and easily replaceable. All this comes from the deepest part of your soul. The experience, the knowledge you have gathered so far, lessons you’ve learned (sometimes the hard way). Memories of every failure having bitter taste together with a sweetness of every small and big success - it’s all there, written down using some mysterious, colorful language.
Peer Review
So, this is it, the time has come to present your work of art to the audience. No matter how seasoned you are, how many times you went through this, it always carries some dose of uncertainty. You know you did your best, but the driver is getting anxious. Some artists feel hurt when their art is not appreciated. They tend to take it personally when facing criticism, even the constructive one. The same goes with programmers. I will even risk the statement, that most humans, whose creation is a matter of a public debate, become more sensitive and vulnerable when they get feedback. You will receive yours in a form of comments left by your coworkers in your pull request. Depending on how many folks are involved in this part of quality assurance, the usefulness of their opinions will vary. Some of them will be accurate and right as rain, the others - totally of-the-wall. It is likely that reviewer will need some clarification, because some aspects may be unclear, so be prepared to answer some questions.
Resolving doubts and dealing with random comments usually doesn’t make your heart beat faster, your ego is on hold. The critical moment comes when you need to respond to flaws found in your commit or request to change your architectural decisions. Your self-awareness awakes and starts inner debate. The result of this discussion will determine the course of the action you will take. Will you try to convince reviewer to ignore defects found in your solution, saying this is an edge case, or you will fix them without an argument? In my opinion, all security, miscalculation, additional network throughput and memory-related issues, when spotted, should be fixed without unnecessary discussions. But what about architectural choices, design patterns used, naming and code readability? The way codebase grows may have some serious impact on the future development, so it’s always worth to talk it over, the same goes with design patterns. Naming is extremely important, but it often leads to endless discussions, sometimes focused on a single variable, so if changing it would break convention or consistency of your solution - fight for it. Not tooth and nail, but rather try to explain your vision to the rest of the team, it is likely they will eventually agree with your point of view. Lastly, the code readability mostly rely on some defined and agreed rules, which are guarded by static code analyzers.
It’s Not About You
The reason why we make a mutual checks of our work, is to deliver value to the project and, eventually, to the company. Every team member should be aware, that we build something what is about to solve someone else’s problems, not ours. Let’s say our team was asked to build a house. Nothing fancy, three bedrooms, two bathrooms, living room and the kitchen. You all agreed to use bricks for the walls and concrete for the ceiling, it will make construction solid and stable. Client accepted price and materials, so you and your team have started development process.
When foundation together with walls and ceiling were ready, your task was to provide a roof, but instead of tiles you decided to use wooden boards. When you were done with covering the roof, you have asked your colleges for the review. In their opinion, soft and vulnerable wood is not a good replacement for hard and durable tiles made of clay. They also pointed out, that such solution is not a common practice in construction industry. It became obvious, that project would not satisfy the client, instead of solving his housing problems it would give him headaches and even more problems to deal with.
Now think, how would your ego respond to this feedback? Do you feel attacked, under the siege? Your idea was criticised, nobody accepted your solution. You thought it would be smart to save client’s money and recycle some materials, but the way you reasoned about it, was totally declined. Finally, what is more important here - your “smart” idea or the project and your company’s reputation? Could you accept the fact, that some poor man and his family are living in the house with leaking roof, just because your ego told you to get your own way? Remember, code reviews and other QA activities are not here to blame or judge anyone. It’s all about the solution, not the author.
When This Is About You
Being a leader means constant struggle for hearts of your herd. Leaders are not designated by some higher authorities, it’s about the group who put them on the pedestal. To keep a leading position one must give an example and make everyone sure, that he or she is the right person in a right place. When debating about leadership ego-wise, there is generally one rule: keep it at bay. Your team decided to follow you, because they saw something in a way you deal with people, not because you are exceptionally smart, or they have been tricked to think so. Sure, your knowledge and experience are important, but there are many people on this Earth who shares the same level of proficiency with you, just saying.
Summary
What does it mean to take an ego on a trip? Generally speaking, it’s about a state of your mind when you don’t feel important enough. As a consequence, you are driven to make things which purpose is to satisfy your vanity and make you feel powerful. Just stop for the moment and think - does your team, project or company need your insecurity and low self-esteem? If you have this honor to be chosen as a captain, it’s likely you are important and kind of special for your crew. You don’t have to remind them why they choose you, because they already know it. They expect you to give an example of honest and professional work, something what eventually help them to become leaders themselves in the future. People focused on their own needs are contradiction of good leaders, because good ones are always focused on their people, they serve the team, so everyone can keep up with they everyday tasks in safe and protective environment.