Taking a break is a great problem solver in the software world

When you are writing code encountering challenges and roadblocks is inevitable. Whether you're a seasoned developer or just starting your coding journey, hitting a wall in problem-solving is a shared experience. In these moments, the inclination might be to power through, burning the midnight oil to conquer the issue at hand. However, there's a powerful and often underestimated strategy that can make all the difference – taking a break.

Mental Fatigue and Productivity

Solving complex software problems requires intense focus and mental energy. Continuous engagement without breaks can lead to mental fatigue, diminishing your cognitive abilities and creativity. Taking a break allows your mind to reset, helping you return with a fresh perspective and renewed mental stamina. This can significantly boost your overall productivity.

At Kaz we are serious about taking breaks during work. Our work environment is designed so that there are spots where someone can just sit and relax or play a game to take their mind off work.

Gaining a New Perspective

When you're deeply immersed in a coding problem, it's easy to develop tunnel vision. Taking a step back provides an opportunity to see the bigger picture. A break, whether it's a short walk, a snack, or a brief diversion, allows your brain to process information in the background. Often, the solution to a problem becomes clearer when you're not actively focusing on it.

Preventing Burnout

Software development is demanding, and burnout is a real risk. Constantly pushing yourself without breaks can lead to exhaustion, decreased job satisfaction, and even long-term health issues. Regular breaks act as a buffer against burnout, preserving your passion for coding and maintaining a healthier work-life balance.

A great way to prevent burnout is to take a long break from work - like a holiday or even a short staycation. At Kaz we do our yearly anniversary party as the company-wide long break, where we go somewhere far away for a few days to just relax and not talk about code!

Creativity Flourishes in Downtime

Creativity is a crucial aspect of problem-solving in software development. Breaks provide the necessary downtime for your brain to make unexpected connections and generate innovative solutions. Some of the best ideas often come when your mind is relaxed and not fixated on a specific problem.

Improved Decision-Making

When you're stuck in a coding dilemma, the pressure to find a solution quickly can cloud your judgment. Taking a break allows you to step away from the urgency and approach the problem with a clearer, more rational mindset. This, in turn, leads to better decision-making and more effective problem-solving.

Physical Well-being

The sedentary nature of software development can take a toll on your physical health. Many tech companies are introducing standing desk as the cure for cancer for this, but it’s not really a proper cure, a great read is this article on Harvard Health Blog about standing desks. The truth is that you need breaks away from your desk and work. Regular breaks promote movement and help prevent issues like eye strain, back pain, and repetitive strain injuries. Simple activities during breaks, such as stretching or taking a short walk, contribute to overall well-being.

In the world of software development, the ability to navigate challenges and solve complex problems is paramount. However, it's essential to recognize the value of stepping back and taking breaks when faced with a programming roadblock. Not only does it contribute to improved mental and physical well-being, but it also enhances productivity, creativity, and overall job satisfaction. So, the next time you find yourself staring at lines of code with no solution in sight, remember that sometimes, the most effective solution is to step away and allow your mind the space it needs to conquer the challenge at hand. Happy coding, with a healthy dose of breaks! Remember those old KitKat ad? Where they used to say “Have a break, have a Kitkat”, that’s exactly what you need to do!

Code Reuse: Leveraging the Goldmine

Here’s a little fun comic we did a long time ago in Bangla, roughly translated it says, “Copy paste was designed by the programmers for themselves!” This was fun but there is an element of fundamental truth about this. Code reuse is one of the best practices in the software world if done right.

The importance of efficiency, speed, and cost-effectiveness cannot be overstated. As developers strive to meet tight deadlines and deliver high-quality products, the strategy of reusing existing software code has emerged as a powerful tool. In this blog, we'll delve into the myriad benefits of leveraging pre-existing code and explore how this practice contributes to the success of software development projects.

1. Accelerated Development Cycles:

One of the primary advantages of reusing existing code is the acceleration of development cycles. Instead of reinventing the wheel for every project, developers can draw upon the wealth of code libraries and frameworks available. This not only reduces the time required for coding but also allows teams to focus on the unique aspects of their project, leading to faster time-to-market.

2. Cost Efficiency:

Time is money, and in the world of software development, time spent on coding directly impacts costs. By reusing existing code, developers can significantly cut down on development time, resulting in cost savings. Additionally, leveraging open-source software and libraries eliminates the need to develop certain functionalities from scratch, reducing overall project expenses.

3. Quality Assurance:

Well-established, reused code has likely undergone rigorous testing and debugging. When incorporating existing code into a new project, developers benefit from the collective efforts of the original contributors, reducing the likelihood of bugs and errors. This enhances the overall reliability and robustness of the software, leading to a more stable end product.

4. Consistency and Standardization:

Reusing code promotes consistency and standardization across projects. Adopting a standardized set of libraries or frameworks ensures that developers adhere to best practices and coding conventions, resulting in cleaner, more maintainable code. This consistency simplifies collaboration among team members and facilitates knowledge transfer within the organization.

5. Community Support and Innovation:

Open-source communities thrive on collaboration and shared innovation. By reusing existing code from open-source projects, developers tap into a vast pool of knowledge and expertise. Community support can be invaluable when troubleshooting issues or seeking advice on implementation, fostering a culture of continuous learning and improvement.

6. Scalability:

Reusable code is inherently scalable. As project requirements evolve or expand, developers can seamlessly integrate new functionalities by building upon existing, proven codebases. This scalability not only streamlines the development process but also ensures that the software remains adaptable to changing business needs.

In the dynamic realm of software development, the value of reusing existing code cannot be overstated. Accelerating development cycles, reducing costs, ensuring quality, promoting consistency, and tapping into community innovation are just a few of the benefits that come with this strategic approach. By embracing the principle of code reuse, developers position themselves to not only meet the demands of today but also to adapt and thrive in the challenges of tomorrow. It's not just about writing code; it's about leveraging the collective intelligence of the developer community to build a more efficient and sustainable future for software development.

Disagreements and debate: the crucial elements in great software projects

In the dynamic realm of software development, where agility and innovation are paramount, fostering an environment that encourages debates is not just beneficial—it's indispensable. The idea of debating within a software project may seem counterintuitive to some, as the conventional image of software development often revolves around quiet coding sessions and collaborative problem-solving. However, embracing debates in the development process can lead to a plethora of advantages, from refining ideas and uncovering hidden issues to enhancing team collaboration and achieving superior project outcomes.

Innovation through Divergent Perspectives

One of the primary reasons debates are crucial in software projects is their ability to stimulate innovation. Divergent perspectives, often emerging during heated debates, can catalyze the generation of creative solutions to complex problems. When team members bring unique experiences, insights, and approaches to the table, it opens up avenues for exploring unconventional ideas that could be game-changers. This realization has led to many software leaders actively seeking a diverse software dev team in the hope of inserting divergence in perspectives in team decisions.

Debates force individuals to articulate their thoughts, challenge assumptions, and present evidence in support of their ideas. This process of intellectual rigor helps in refining concepts and ensuring that the final solutions are well-thought-out and robust. Without debates, a team risks falling into the trap of groupthink, where conformity stifles innovation and unconventional ideas are overlooked.

Identification and Mitigation of Risks

Software projects are rife with challenges, and potential risks can lurk beneath the surface. Debates serve as a powerful mechanism for surfacing these risks and addressing them proactively. When team members engage in discussions about project requirements, design choices, or implementation strategies, they are more likely to identify potential pitfalls that might be overlooked in the absence of scrutiny.

By thoroughly debating different aspects of a project, ranging from technical decisions to project timelines, the team can anticipate and mitigate risks early in the development process. This proactive risk management is crucial for ensuring project success and preventing costly errors down the line.

Enhanced Collaboration and Team Dynamics

Debates, when conducted in a constructive manner, contribute to a positive team culture by fostering open communication and collaboration. When team members feel empowered to voice their opinions, it promotes a sense of ownership and engagement. Additionally, debates encourage active listening, as team members must understand and respond to each other's arguments.

Moreover, healthy debates provide an opportunity for team members to learn from one another. As individuals share their knowledge and experiences, it creates a collaborative learning environment where everyone can benefit from the collective wisdom of the team. This learning dynamic not only improves the skill set of individual team members but also contributes to the overall growth and development of the team as a whole. One thing important in this area is the leadership style of the team leads in the software project. If the style of leadership is not open to a multitude of ideas then the benefit of enhanced collaboration breaks down and the debates turn into points of division within the team.

Refinement of Ideas and Decision-Making

In the crucible of debate, ideas are refined, and decisions are thoroughly scrutinized. This process is essential for ensuring that the chosen path is the most effective and well-considered one. Debates force individuals to defend their proposals, encouraging a deeper understanding of the implications and trade-offs associated with different choices.

Through this rigorous examination of ideas, the team can make informed decisions that are more likely to stand up to the challenges of implementation. The act of defending one's position in a debate requires a comprehensive understanding of the subject matter, promoting a culture of informed decision-making within the team.

Continuous Improvement and Adaptability

Debates are not static events but dynamic processes that unfold as projects evolve. In the ever-changing landscape of software development, the ability to adapt and iterate is crucial. Debates contribute to a culture of continuous improvement by encouraging teams to revisit decisions, reassess strategies, and incorporate new insights and information as they emerge.

This adaptability is particularly important in agile development environments, where the ability to respond quickly to changing requirements is a key success factor. Embracing debates as a means of continuous improvement ensures that software projects remain agile, resilient, and capable of delivering value even in the face of evolving challenges.

In the fast-paced world of software development, where the only constant is change, the importance of debates cannot be overstated. By fostering innovation, identifying and mitigating risks, enhancing collaboration, refining ideas, and promoting adaptability, debates play a pivotal role in shaping the success of software projects. Teams that actively engage in constructive debates are better positioned to navigate the complexities of development, resulting in superior outcomes and a culture of continuous improvement. In the vibrant ecosystem of software projects, debates are not just discussions—they are catalysts for excellence. We have a joke at Kaz that if only two people agree in a group of many we have a decision! The little comic here says that in Bangla :)

How to manage emotions in a software team

First, let’s get something straight: strong emotions are part of the human experience. And strong emotions can be both positive and negative for a team. We all have them in various degrees and that’s all ok. But let’s also accept the fact that strong emotions can sometimes be very detrimental to a working environment or team bonding. An episode of strong emotions where team members raise their voices against one another can affect team members' productivity and motivation for a very long time. It has the potential to do permanent damage. On the other hand, strong emotions can have very positive outcomes too - the team can be very happy about how well the product is doing, or be happy about a team member’s happy news, etc. It is specifically the negative emotion that every team lead is worried about and that is what this post is about.

Managing negative emotions in a software team is difficult. Recently we did a survey with our tech leads to find out what their best strategies for managing their teams and how they handle emotional outbursts (of the negative kind) and the like and here's what we came up with.

Encouraging Open Communication to Prevent Emotional Outbursts

One of the best ways to manage emotions in a software team is to encourage open communication. When team members feel heard and valued, they are less likely to experience emotional outbursts. As a manager or tech lead, it's essential to create an environment where everyone feels comfortable expressing their thoughts and concerns.

Encouraging open communication can be done in several ways. First, you can schedule regular one-on-one meetings with your team members. During these meetings, you can discuss any issues they may be facing and provide feedback on their work. Additionally, you can create an open-door policy where team members feel comfortable approaching you with any concerns they may have.

Another way to encourage open communication is to hold regular team meetings. During these meetings, you can discuss project progress, upcoming deadlines, and any challenges the team may be facing. You can also use this time to check in with your team members and see how they're doing both professionally and personally.

Finally, it's essential to provide opportunities for your team members to give feedback on the work environment and company culture. This feedback will help you identify areas that need improvement and make changes that will benefit everyone on the team.

By encouraging open communication within your software development team, you'll create an environment where emotional outbursts are less likely to occur. Team members will feel heard and valued, which will lead to increased productivity and motivation.

Setting Expectations for Behavior

In addition to encouraging open communication, it's also important to set expectations for behavior and emotional regulation during team meetings. This will help create a respectful and professional environment where everyone feels comfortable expressing their thoughts and ideas.

As a manager or tech lead, you can start by setting ground rules for team meetings. These rules should be clear, concise, and easy to understand. For example, you can establish that interruptions are not allowed during presentations or that everyone should have an opportunity to speak before moving on to the next topic.

It's also important to encourage emotional regulation during team meetings. Emotions can run high when discussing challenging topics or when there are disagreements among team members. As a result, it's essential to remind everyone of the importance of keeping their emotions in check.

One way to promote emotional regulation is by practicing active listening. When someone is speaking, make sure that you're fully present and engaged in the conversation. Avoid interrupting or dismissing someone else's point of view.

Another way to encourage emotional regulation is by taking breaks if needed. If tensions are running high, take a short break so that everyone can cool off before continuing the discussion.

By setting expectations for behavior and emotional regulation during team meetings, you'll create an environment where everyone feels respected and valued. This will lead to more productive and efficient meetings where everyone has an opportunity to contribute their thoughts and ideas.

Providing Training on Conflict Resolution and Emotional Intelligence

Emotional Intelligence: Why It Can Matter More Than IQ

By Goleman, Daniel

Another effective way to manage emotions in a software team is by providing training on conflict resolution and emotional intelligence. Conflict can arise in any team, but it's how the team members handle that conflict that makes all the difference.

By providing training on conflict resolution, you'll equip your team members with the tools and techniques needed to resolve conflicts peacefully. This training can cover topics such as active listening, empathy, and compromise. By developing these skills, team members will be better equipped to handle disagreements without letting their emotions get out of control.

In addition to conflict resolution training, providing training on emotional intelligence is also crucial. Emotional intelligence refers to the ability to recognize and regulate one's own emotions while also understanding and empathizing with others' emotions.

By developing emotional intelligence skills, team members will be better equipped to handle stressful situations without resorting to emotional outbursts. They'll also be better equipped to understand their colleagues' perspectives and work collaboratively towards common goals.

Overall, by investing in conflict resolution and emotional intelligence training for your software development team, you'll create a more cohesive and emotionally healthy work environment where everyone feels heard and valued.

Creating a Safe Space for Team Members to Express Their Emotions and Concerns

Creating a safe space for team members to express their emotions and concerns is crucial in managing emotions within a software development team. When team members feel comfortable sharing their thoughts and feelings, they are less likely to experience emotional outbursts or bottling up their emotions.

As a manager or tech lead, it's essential to create an environment where everyone feels heard and valued. One way to do this is by scheduling regular check-ins with your team members. During these check-ins, you can ask how they're doing both professionally and personally. You can also provide feedback on their work and offer support if needed.

Another way to create a safe space is by setting aside time during team meetings for open discussion. This time can be used for team members to share any concerns they may have, brainstorm ideas, or discuss any challenges the team may be facing.

It's also important to establish confidentiality when it comes to sensitive topics discussed within the team. Team members need to know that what is discussed in those private moments will remain private.

By creating a safe space for your software development team, you'll foster an environment where everyone feels comfortable expressing themselves. This will lead to increased trust among the team members, improved communication, and ultimately better results.

Regular Check-ins to Address Potential Issues

Regular check-ins with team members are crucial in managing emotions within a software development team. These check-ins provide an opportunity for team members to discuss any potential issues or concerns before they escalate into bigger problems.

As a manager or tech lead, it's important to schedule regular check-ins with your team members. During these meetings, you can discuss any challenges they may be facing and offer support if needed. You can also provide feedback on their work and address any areas that need improvement.

Regular check-ins also provide an opportunity for you to gauge the emotional state of your team members. By checking in regularly, you'll be able to identify any potential emotional outbursts before they happen and take steps to prevent them from occurring.

In addition to one-on-one meetings, it's also essential to hold regular team meetings where everyone has an opportunity to share their thoughts and concerns. These meetings can be used for brainstorming new ideas, discussing project progress, and addressing any challenges the team may be facing.

By scheduling regular check-ins with your software development team, you'll create an environment where everyone feels heard and valued. This will lead to increased trust among the team members, improved communication, and ultimately better results.

Encouraging Self-Care Practices

Encouraging self-care practices is another effective strategy for managing emotions in a software development team. As a manager or tech lead, it's important to recognize that your team members are human beings with their own lives outside of work. Encouraging self-care practices can help them manage stress and avoid emotional burnout.

One way to encourage self-care practices is by promoting the importance of taking breaks. Taking short breaks throughout the day can help team members recharge and refocus. Encourage your team members to step away from their desks, take a walk, or do something they enjoy during these breaks.

Another way to encourage self-care practices is by promoting exercise. Exercise has been shown to be an effective stress reliever and mood booster. Encourage your team members to incorporate exercise into their daily routines, whether it's going for a run before work or taking a yoga class after work.

Finally, mindfulness techniques such as meditation and deep breathing can also be helpful in managing emotions. Encourage your team members to take a few minutes each day to practice mindfulness techniques. This can help them stay focused and calm during stressful situations.

By encouraging self-care practices within your software development team, you'll create an environment where everyone feels supported and valued. Team members will be better equipped to handle stress and avoid emotional burnout, leading to increased productivity and job satisfaction.

Managing a multi-cultural remote software team

Remote work is the new normal, and managers need to be prepared to lead their teams in this new environment. And in today's globalized world, multicultural teams are the common remote teams. Cultural diversity is common in onsite teams too but the issues of miscommunications because of cultural issues are much more complex in remote teams. With the rise of remote work and the desire for flexibility among younger generations, managing a team from different cultural backgrounds has become one of the biggest challenge for managers. And this is an essential skill that all managers are picking up.

Since Kaz is a software development agency based out of Bangladesh and we work mostly with software companies based in the US or Europe. So the very nature of our work leads us to the remote cross cultural issues. And this not a new thing for us because of the recent rise of remote work. We’ve been participating in remote software teams for the past 18 years, and over that long time we’ve probably seen all the things that can go wrong in such cross culture, cross language teams and have devised strategies that solve those issue (or at least reduces to chances of them arising). We’ve also come up with a little poster for expressions in English that doesn’t translate well, that we sometimes give to our customers’ project managers as a cheat-sheet! So, today’s post is a summary of some of our best tips around this and that useful “cross culture expressions to avoid cheat-sheet”.

Understand that there is problem

This is important. Specially in the software world. We sometimes hear things like: “At the end it’s all code, and the language of code is the same so there will be no problem”. Although at the fundamental level that is very true, but to get to that stage of work and collaboration the remote teams still have go through layers of communications. That communications is typically in a language that isn’t a first language for at least one side and sometimes for both sides. And that’s where the start of the problem happens, and layer on top of that the cultural difference and the fact that cultural context changes the meaning of many expressions and mannerisms - you have a problem. So it’s vital for software managers to understand that there is a problem and it will need active strategies and process to solve that problem.

In this context, it is essential to recognize that cultural differences can lead to misunderstandings and conflicts. As the speaker in the video explains, even seemingly simple things like expressions about time can have very different meanings in different cultures. For example, in some cultures, "just now" might mean "in a few minutes," while in others, it might mean "sometime in the future." Without understanding these differences, miscommunications can easily arise, leading to frustration and conflict.

Create culture awareness in the team

To address this challenge of cultural difference and the need to work around such difference, it is important to invest in cultural awareness and sensitivity training for managers and employees. This might involve providing resources such as books or online courses on cross-cultural communication, as the speaker in the video did. It might also involve hosting workshops or training sessions led by experts in intercultural communication.

One key aspect of this training should be the importance of context in communication. As the speaker explains, even when two teams are using the same language, differences in context can lead to misunderstandings. For example, a phrase that might be intended as a compliment in one culture might be interpreted as criticism in another culture. Understanding these differences requires a deep appreciation for the cultural norms and values that shape communication styles in different parts of the world.

Create an environment of trust

Another important aspect of managing a multicultural team is building trust and rapport among team members. When people come from different cultures, they may have different expectations about how to build relationships and establish trust. For example, in some cultures, it may be important to spend time getting to know someone on a personal level before discussing business matters, while in others, business may be the focus from the outset. Understanding these differences can help managers to build stronger relationships with team members and foster a sense of camaraderie and trust.

We’ve written extensively about this in the past, as we feel that this is one that that makes thing much simpler to solve cross cultural issues. Some of our tips can be found in this article about how to build trust in your remote team by team gelling or this one about creating the right team culture for companies with remote teams.

Find what works the best for you

It is important to recognize that managing a multicultural team is not a one-size-fits-all endeavor. Different cultures have different expectations around communication, hierarchy, and decision-making, among other things. Effective managers must be able to adapt to these differences and find ways to accommodate the needs and preferences of each team member. This might involve using different communication tools for different team members, or adjusting work schedules to accommodate different time zones.

Careful about what expressions you use

It's important to be aware that expressions that you might use in your language or cultural context might not be understood at all or even worse understood with the opposite meaning by your remote team. It is vital for team managers (and team members) to consider cultural differences when communicating with people from other backgrounds. It's also a good idea to clarify the meaning of an expression if you think it may be misunderstood. Here’s our list of common English expressions that just doesn’t cross the language and culture basriers well. We call it the expressions to avoid cheat-sheet!

"Break a leg" - This one never works. In most non-English cultures, wishing someone luck by saying "break a leg" is considered bad luck or even offensive. Actually if you think about it really weird that this expression has the meaning it has, here’s the Wikipedia post giving it’s history.

"Bite the bullet" - This expression means to endure a painful or difficult situation, but in some cultures, the literal meaning of biting a bullet can be confusing or offensive.

"Spill the beans" - This expression means to reveal a secret, but in some cultures, the idea of spilling beans may not make sense or may be seen as wasteful. I remember once one of our customers used this expression in the context of asking his team not to reveal software features anyone and the look of confusion in the team was very interesting!

"Piece of cake" - This expression means that something is easy, but it almost always fails to translate well.

"Going Dutch" - This expression means to split the bill, but in some cultures, the idea of going Dutch may be unfamiliar or seen as impolite.

"Skeletons in the closet" - This expression means to have secrets or embarrassing information, but to someone not used to the expression the idea of keeping skeletons in a closet would not make sense at all!

"Costs an arm and a leg" - This expression means that something is very expensive, but in some cultures, the idea of comparing something to body parts may be seen as distasteful.

"Cat got your tongue?" - This expression means to ask someone why they are not speaking or responding, but this one never works either for obvious reasons.

"Let the cat out of the bag" - This expression means to reveal a secret, but the idea of a cat being in a bag may not make sense or may be seen as cruel for non English speakers.

Top 5 challenges of building an effective software team

1. Finding the right people for your team

This is without doubt the hardest challenge. Finding skilled software professionals is hard, but find the people who work can work together is even harder. Although this is the hardest there is no way around it. The success of any software project depends on one factor - how good the team behind it is. We know this from our experience in working with 100s of software projects over the past 18 years, but research and data in this area also shows this fact. In their comprehensive study of software project failures published in Software Development Failures: Anatomy of Abandoned Projects Ewusi-Mensah, K. showed that factors related team composition and team dynamics comes up very high in absolutely every single software project that has failed in their group. Similar connection with team related factors are found in other studies too. A good summary can be found in a paper titled core factors of software project success.

Table comparing softwre project failure causes from paper: https://www.researchgate.net/publication/330290988_Core_Factors_for_Software_Projects_Success

You need to focus both on the skills of the individual resources and the fit of the resource between each other to find the right team. A mix of skills is very important, so as you are composing the team work on looking at individual potential candidates and map out their skills - both technical and soft skills. Find a balance where you have various technical skills spread out along with the soft skills. An example could be that for a web development project in .NET you should look for people with core .NET programming skills but also add people with database, javascript, UI/UX skills. And again on the soft skills front you should have some members of the team who are good communicators, some who are good mentors and some who can run a debate well.

2. Getting your software developers to communicate effectively

Once you have the right team your next big challenge is to setup a system, a workflow and a culture where commutations happen in a flexible and free form way. You want multiple channels of formal and informal discussions. You’d want formal structures like team meetings and brainstorming sessions coupled with informal channels like a talk in front of the water cooler. At Kaz a great place for informal communications is the team’s own break space - we call them ip - interaction points. Sometimes it’s a veranda with some chairs where team members take their tea/cigarette break and has a chance to discuss something that’s bugging them (sometimes its about the the project too!).

It’s vital that your team should communicate effectively. Many a great software team has produced failure by the fact that the management made it too difficult to communicate - maybe with too many formal meetings or too few.

It’s hard to suggest a winning formula that works for every team as every team is different, every project is different. And add to that mix the WFH and remote work you have an even more complex problem. Work with your team to make sure there is effective discussions happening. Check back regularly on the health of that communications.

3. Developing a process that works for everyone on the team

Once you have the #1 and #2 sorted out you are half way there. The rest is pretty standard operations setup but it’s still super important to get things right. The top thing on the operations part is setting up the workflow.

A software development workflow involves all the nitty gritty steps of getting the software requirements, specifications, planning, distribution of work and then getting that work done in phases. The catchall word for anything related to software development workflow these days seems to be “agile”. But saying “agile” is not good enough. Setting up a workflow - if it’s driven by the concepts of the agile methodology that’s great - is important. Again, the thing to remember is that every team is different, every project is different and every company is different. The “agile” that’s right for you might be different from the “agile” of a different team or company. Plan the workflow that fits with your circumstances. For example, if you working on startup’s proof of concept project and entire future of the startup depends on showing this POC fast to it’s investors so that they can get some funding to actually build the thing - having a complex process for creating and tracking tasks that has to be reviewed at multiple steps is going to be a disaster. You’d want a process that is fast, relies mostly on verbal communications and commitments and almost no red tape. The opposite would be true if you’re working on upgrading an existing ERP that a large number of customers relies on it’s day to day work and single breakdown can lead to a lot of trouble fore everyone.

4. Creating an environment where every member of the team feels valued, respected, and included

In the mode of efficiency and engineering that software projects tend to push us we forge that at the end a team is a just another group of people. They are no different than other groups of people in our daily lives - each with their own needs and desires. It’s vitally important that in the hectic pressure of the the project, the need to find great resources and in creating efficient workflows we don’t forget the fact that the team members individually and the team collectively needs to feel valued and respected.

The worst offender in this space is the high handedness management teams sometimes use to operate with development teams. They somehow feel that they need to command and control the teams - which just doesn’t work in the creative and intellectual space that software development projects work in. It’s important to we aware of this danger of detachment from reality and keep honest reviews on the company’s attitudes and processes to make sure that the team feels happy and motivated. Remember that in software a demotivated team is directly equal to a failed software - there is no mid point in this equation.

5. Balancing what's best for your company with what's best for the team

The last point is a delicate one. You might have the best resources, you might have a streamlined process with a healthy team motivation in place but you are still operating within a business. A business has priorities and typically it’s about money and short term goals. These priorities will always clash with your team’s health. Short term goals will mean over working the team, it might mean a burnt out team and it also might mean that team members pushed around various things in their project (something that developers hate). It’s not an answer to say that I don’t care about the goals of the company - as those very same goals make the ends meet and get the funds for everyone to live. And on the reverse it’s also not an answer to say that we’ll sacrifice the good of the team to make the goals of the company work. There has to be a balance somewhere. The team will have to compromise on certain things (e.g. maybe a special impossible deadline for funding) and the company will have to compromise on others. If you get the balance right you’ll have a wonderfully efficient team in place.

OK, lots of heavy stuff. Let me finish off with a stolen Dilbert :)

How to motivate a remote team

Remote work is now the norm. This is one thing that the COVID has pushed us to and has proven that it works. Companies that never did remote work (including us at Kaz) are now fully functional and thriving with remote work. And remote work is here to stay as a work model - it’s very likely that every company in the world (including us) would keep some form of remote work in their process. Everything has a downside - and for remote work it’s the lack of the rest the team near you that starts having an effect. Over longer period of time motivation for work becomes a big stumbling block. And for manager and team leads it’s not an easy problem to solve. But we’ve found that it’s not an impossible problem either.

“77% of remote employees say they’re more productive when working from home”

— Survey by CoSo Cloud

You don't have to be next to someone's desk in order to feel the energy of a team that can work together and accomplish goals. As a manager, you can motivate and inspire your remote team just as well as you would if they were all sitting in your office.

Here are our top tips for motivating your team remotely.

1. Set clear expectations for your team

We are used to taking visual ques from all our interactions, these ques form much of our understanding in any conversation. A remote team misses a lot of these visual ques in an interaction over a zoom call or worse over an audio only call. So it's vitally important that common understanding of expectations is reached. We tell all our customers to set aside a slot at the end of every meeting to just go over the main points of the meeting and check that the both sides agree on what the expectations are.

2. Be transparent about what is happening

When your remote team feels out of the loop, they are less likely to want to engage. People are motivated by being informed about what is going on around them, so tell them! If they miss something, feel free to say "let me go over that thing" or "you should hear about a new development that is happening". This is especially true for software teams, as software development is typically a very collaborative effort and if the remote team feels that they are left out of decisions, changes in requirements etc. it will create a loss of motivation and just make the overall process of software development difficult.

3. Communicate regularly

The remote work experience will be a lot better if there are regular communication channels between the remote team and the office. Some ways to keep them in the loop is by having weekly meetings that are open to all members of the remote team, sending out emails with important updates on new features or scheduled changes, etc. Asking them regularly how they are doing, where they are on particular tasks or deliveries.

There are many other ways you can motivate your remote team. Some of them are time off or bonuses, but at the end it is about working with people who enjoy what they do - And if they are happy to work for you, you will get an effort that goes beyond the job requirements.

For small companies this might seem like a lot of overhead, but it is vitally important for the longer term.

“2020 has seen a 9% increase in Google search interest related to “team-building””

— www.thinkwithgoogle.com

Leadership in software development

I was recently reading an interesting post about various kinds of leadership styles in the business world. The author tried to distill the styles into the following:

• Autocratic Leadership - my word is only word good or bad style of a leader

• Authoritative Leadership - follow me (better version of the autocratic if the leader has a clear vision)

• Pacesetting Leadership - driven leader who sets a high standard and pushes people towards that standard.

• Democratic Leadership - consensus driven

• Coach-Style Leadership - a style that focuses on mentoring the team towards perfection

• Affiliative Leadership - people and their needs first approach towards work

• Laissez-Faire Leadership - hands off, I trust you to do the job style

Pretty exhaustive list, but while we are at it, I’d add some weird ones I’ve come across in my working life too:

• Bureaucratic Leadership - follow the procedure whatever the case style

• Transactional Leadership - tit for tat style, where your life gets better if you perform better. Money money money sort…

And of course the infamous

• No Leadership

This is great, although I would think in reality any particular leadership is a mixture of style. But I would also agree that in general there is a “style” that dominates in everyone. So the big question that comes next for us software people is:

What’s the best style for software teams?

There is no fixed answer to these type of questions except maybe the boring ones that start with “depends…”. But I’ll not go with the boring ones and try to answer this in a very specific way with our experience at Kaz Software. With more than 17 years under our belt, making and delivering software and more importantly surviving :) I’d say our way is a good answer as any. So much so that I’d say Kaz’s way i the only right answer and any other answer is wrong.

So here goes…

The answer is (imagine atmospheric background music here): Intrinsic Motivational Leadership

OK, that one isn’t in the list above and it’s kind of a made up name, but let me explain.

Intrinsic motivation is the motivation that comes from within. This is a opposite of the extrinsic motivation that is usually money or status. A leader who can create this motivation in his or her team is the only kind of leader who will excel and that software team will be the best at what it does. A leader with this style of leadership follows two goals:

Goal 1: Create a jelled teams

Such leaders know that in the business of software development teamwork is the highest priority. That is the only way to get reliable and reproducible results from a team. To create cohesive team that feels like a family is the biggest goal for such a leader. A team that feels like a family has a specific identity, specific way of doing things and saying things. All these together creates sense of loyalty and commitment towards the common goal at hand - be it the challenging deadline or fixing the impossible bug.

“Google users trust our systems to help them with important decisions: medical, financial and many others. Our search results are the best we know how to produce. They are unbiased and objective, and we do not accept payment for them or for inclusion or more frequent updating. We also display advertising, which we work hard to make relevant, and we label it clearly. This is similar to a well-run newspaper, where the advertisements are clear and the articles are not influenced by the advertisers’ payments. We believe it is important for everyone to have access to the best information and research, not only to the information people pay for you to see.”

— Google's 2004 founders' letter prior to IPO

It helps if the company’s long term goals are something to be proud about. A great example is Google’s “don’t be evil” which has been an unifying slogan for Google’s teams. Although it’s been slowly phased out when Alphabet formed.

Similarly Apple employees have almost fanatical following and identification with the company’s goals and aspiration with the famous slogan of “we are against totalitarianism”. A classic Steve Jobs move which started with the Mac ad in the 1984 superbowl directed by none other than Ridley Scot (of Alien fame). If you haven’t watched the ad, it’s a must…

So a leader whose goal is the intrinsic motivation, will need to do something that to creates an identity which leads to that jelled team goal.

Goal 2: Make information available

A software team is by it’s very definition a group of smart individuals. Software companies invest the biggest on their HR cost and that is all because of the smartness of individual members of its teams. A motivational leader knows that the best way to lead is not to rely on his or her own brain but rather to rely on the collective smartness of the team at hand. And to make that possible the leader has to do everything to make all information needed to make a decision available to the team. Thus, hiding some facts that are only available to the “management” is not an option for such a leader. She has to work with different parts of an organization to bring relevant facts and information out in the open for the team to decide what the next step is.

To achieve this goal a leader has to convince the management that openness is the right way forward - not an easy task. It’s difficult and sometimes almost impossible for business leadership to reveal the innards of an organization. A project that is running of funds, a customer who has negative feedback about a team, a marketing venture that lost a lot of money, etc. are ugly facts of running an organization. Hiding such information from the teams lead to statements from leaders like “I know things that you don’t know…” - which just doesn’t lead to intrinsic motivation goal. It also makes it impossible for smart software teams to come up with decisions that are based on facts and data. So a motivation driven leader will have to do all in her power to make such information available to the team and then empower the teams to make decisions. Collaborative decisions coming from agreement from the team leads to the most effective decisions and a leadership that focuses on such a strategy is always a winner in software organization.

I’ll leave today with that great video of the 1984 superbowl ad that Apple made… always a fun watch. While you are watching it keep remembering that this is an ad for a computer!

Atomic Habits - Great book for software professionals

We are starting a new series on great books for software professionals. The plan is to find books that help us become better professionals in the software development field. We plan to cover both technical books like programming, architecture, etc. and also non technical books that help with our people skills, improve motivation, that help us manage work and life better.

We start this series with one our favorite self help book - Atomic Habits by James Clear. A book that is for everyone. It shows in very simple and clear language with actionable steps how making small changes in our life leads to amazing improvements overall. This is a perfect book for software professionals as they deal with a huge amount of complexity in their work for which they have to constantly learn new things, manage their time better to improve and hone their skills. We’ve benefitted a lot from it and hope you will too.

Summary

Atomic Habits: An Easy & Proven Way to Build Good Habits & Break Bad Ones

By James Clear

When we want to achieve a goal, what do we do? We set the goal and work for it. But is that enough or does that truly lead to the goal that we want to achieve!

Here comes the big question, what does it take to truly achieve the goal? The simple answer is process. But when we hear about the process, we think of a long boring stuff that requires patience and persistence. So, is it really that tough?

What makes the difference between the winners and losers is action. When we set a goal and do nothing but watch the time passing by, in the long run become losers. On the other hand, who follow the system, make continuous small improvements, actually achieve the goal. Just like any particle is made of small atoms, remarkable results are also made of atomic habits. Habits that make the real difference. So, if we want to achieve it, we have to forget the goal and follow the system instead.

Changing Habits

Generally, habits can be changed in two ways- outcome based and identity based. Let’s draw a very practical example that can help us.
Suppose, someone wants to quit smoking, now if he is asked to smoke, he can possibly give this answer “Sorry, I am trying to quit smoking”. Now, let’s be honest, we all know it doesn’t help much. Here, the person is trying to improve but is not ready to change his identity. And this makes it harder for him to fight against the person who he thinks he is.

WHAT IF ….

He put a different answer instead? Like, “Sorry, I’m not a smoker”.

Anything that we do repeatedly, becomes our identity. Our every action votes for the person we want to be. Because no single action can change our identity. Rather the repeatability of that action can change our identity. When we confidently talk to someone, our identity as a public speaker gets recognized; when we influence others, our identity as leader gets recognized.  Hence, first we have to decide, what type of person we want to be and according to that, we have to keep voting on that identity. If you want to be a gentleman, then your behavior on the road, bus, train should be accordingly. Because we are changing our identity with our belief system.

Four actions

Our habits are generated through the following four steps-

·         Cue

·         Craving

·         Response

·         Reward

Cue is what reminds us of the reward. Craving pushes us towards get the reward and our response makes us to achieve the reward. And we want the reward because we will either have satisfaction from it or we can learn something. And if anything is insufficient among these 4 steps, changing any habit won’t be possible properly.

From these 4 steps, we can say that, we can follow 4 steps to build a book reading habit- 

• Cue: This should be highly visible. If the books are visible, then we can easily notice that, yes, I have to read books.

• Craving: Here we have to make the visibility attractive. For example- we can add bookmarks on the book so that we can easily know how much we have and where we had left.

• Response: This should be easy to respond. So that, it doesn’t become hard for me to reach them.

• Reward: Here we can choose the right book. So that, it brings a higher level of satisfaction for us.

Ways to remove bad habits-

·         Cue should be invisible

·         Craving should be unattractive

·         Response should be difficult

·         Reward should be unsatisfying

We can apply these 4 steps to remove any addiction like- smartphone addiction.

We usually imitate our habits from these three groups of people

The close, the many, the powerful. We are inspired by these three groups in general. Some people think that, they lack motivation. But actually, they lack clarity. They actually don’t know how to start things and how to proceed them. In real- environment is more important than motivation. For example- in case of buying a product, the things that are placed in front of a store, we tend to try them in the first place. So, in case of building a habit or leaving it, we have to setup proper environment for that.

People think that, self-controlled people are driven by their willpower and self-discipline. But actually they design their life in such a way that in order to be disciplined, they don’t need much of discipline. For example- if they think television is killing their time, then they will remove the television from their house.

And when we try to build a habit, we have to keep tracking that process that we are following and try to measure that progress.

To sum it up

We have to remember that, our brain loves challenges. That doesn’t mean it will like challenges that we can never achieve. For example- I love to play tennis. Now if I am put against Roger Federer, then very soon I will lose all my enthusiasm. And if I start to play against a little kid then I will get bored. So, the challenges should not be bored or overly challenging.

Atomic habits are the key to a massive change. So, rather than daydreaming, we have to develop a process and act on it.

Here’s a quick book review in Bangla…

Software team structures

A common question we get asked by new companies in our field is:

What’s the best team structure in a software company?

Our answer to this question had been an easy one: “as flat as possible” meaning a structure where there are that many levels - ideally no middle managers just the software developers or other technical roles reporting directly to the team lead who barely ever needs to report to anyone above.

This is a great answer. It takes away the biggest problems in software development companies and introduces creativity, ownership and most importantly collaboration. But this answer is by itself not good enough. As a company grows, as it takes in more and more projects requiring larger number of teams which then collaborates with each other the flatness that gave all the flexibilities in a smaller organization starts to introduce confusion and chaos. So some more structure is needed. What that ideal structure might be is a question that’s very specific to the nature of the company in question and the culture that it embraces. For us at Kaz it’s been moving towards more independently operating teams that operate under groups or wings of technology. We call them companies under companies under companies. This may not work for everyone. Today let’s go over some common software roles we hear about and try coming up with generalized views about what those roles are supposed to do. This might give us some ideas about what roles our own companies might require and where to fit them.

Common Software Roles

Some of the common software roles we see in the industry worldwide are as follows:

Chief Technical Officer (CTO)

CTO is a confusing role, it’s a role that requires purely technical skills most of the time but sometimes it needs to be as non-technical as can be. At startups, the CTO is often a technical cofounder and that role is all about jumping into coding and jumping out to join a marketing meeting. But the same CTO role is a large organizations is very different. A CTO at such an organization is mostly outward facing - looking at clients, product and marketing teams and giving a voice to technical angle on all business conversations. Rarely does a CTO at large organization ever dive into the code or even participates in technical architecture. They participate in business development meetings, frequently helping to land large partnerships or sales. Many spend a lot of time evangelizing the development activities of the organization to the wider world: sharing the company’s innovations and discovering opportunities in the market which match up well with the company’s core competencies.

VP of Engineering or Director of Engineering

The Director of engineering’s role is what most people usually think of CTO’s role. This role is frequently responsible for building the engineering team, creating work process of the technical team and establishing the engineering culture and operations. While CTOs often face outwards - towards business and clients, the Director of Engineering faces inward - towards the technical workforce, their daily needs.

The best directors of Engineering constantly monitor the team’s progress, process and culture. She encourages the technical staff to use the right tools, the right platforms, even the right programming libraries. She may have strong views about how the teams should operation, how the meetings should be run, hold specific kinds of meetings at specific times in order to foster better collaboration with fewer interruptions.

In smaller organization it doesn’t makes sense to increase hierarchy by having separate CTO and director of technology. These two roles can easily be fused together in such organizations but as soon as business starts to expand this is one role that needs to split first.

Chief Architect & Software Architect

The architects in a software organization are usually the uber geeks. They are the super star programmers who never wants to be in any kind of management role and want to stay as close to coding as possible. In small organizations, the chief architect is sometimes the technical co-founder who knows that she never wants the responsibilities of a CTO as the company grows. They are just not interested to take all the hassles of customer facing, project facing, investor facing and team management facing responsibilities that comes with the CTO or even the director of engineering roles.

The architect is the person responsible for selecting technology stacks, planning technical solutions, designing collaborations and interfaces between systems, etc. As the company matures, the chief architect may also need to work closely with the CTO and at many companies, the CTO also serves as the chief architect.

Project Manager

This is the big difficult role. Sometimes this is the role that everyone in company is looking at. In most companies this is the role where a technical staff decides the future of her career - does she want to stay in development and aim for architect roles or does she want to go more towards management roles.

A project manger is in charge of managing the workflow of an engineering team. She interfaces with both product leaders and an engineering leader such as director of Engineering or the CTO to manage the work backlogs, monitor the progress of tasks, create detailed progress reports, track milestone, manage burn down charts, etc. In smaller companies the project manager is the multi-hatted role of a director of technology and team lead.

Technical Lead/Team Lead

The Team Lead is the leader of a small number of technical staff that forms a particular team in the project’s workflow. Typically a team lead is a senior engineer who takes on the role of mentors and guides for the rest of the team. Usually, developers report to a team lead who then reports to the project manager to give a summary of what his team is doing. The team lead is usually coding all the time and the team lead role is a more a part-time role she has to take up when the time comes. In some companies she may be responsible for the team’s code quality, code reviews and managing the team’s output standards.

Various software engineering roles

At the team level are the real workers in a software company - the people who really make it all happen. Based on different levels of experience you have some of the following roles.

• Principal Software Engineer

• Senior Software Engineer

• Software Engineer/Developer

• Junior Software Engineer/Developer

• Trainee Software Engineer/Developer

These are the people who gets things done, who write the code according to spec, fix bugs and creates solutions to problems.

So these are some of the basic roles. But what happens when we look at the giants like MS or Google? With technical teams that are size of small towns obviously having just few levels in the roles isn’t enough. So for Software Development Engineering (SDE) roles there are hierarchies and more levels and structure. Just to get a glimpse, I’ll close it up today with a comparison of the software roles at our 3 giant friend’s.

The #1 software soft-skill

A common question we get asked is: what are the soft-skills that a software developer needs? The answer to that question can be pretty big and some of the candidates can be very surprising (e.g. marketing skills - for advertising yourself in the new job market where employers actually find you rather than you find employers). But if the question is rephrased to:

“What is the the #1 soft-skill that a software developer needs?”

The answer is super easy. There is no confusion here, the answer is:

“The ability argue with logic”

Why?

Because, the software profession is all about debating and arguing what the correct solution to a problem is. There are no final or perfect solution out there. What works for one problem doesn’t work for another. What works today for a certain situation may not work tomorrow. There are just too many possibilities and there are no silver bullets! Nothing is sacred in this space, if “normalization” was the one thing that everyone agreed on data storage strategies (aka databases) yesterday, “de-normalization” could be (and is) the flavor of the day today. We have to live with the possibility that everything we believe in is probably wrong! So the only way to find solutions in this sea of uncertainty is - debates. Rational debates where every argument is proposed with logic and countered with logic. From such an exercise, maybe, just maybe a consensus may be reached. Or, what is more likely the common situation, no consensus is reached but a decision is made one way or the other with the pros and cons of that decision clearly out in the open. This is the only way to make progress.

Emotion destroys a software debate

In this scheme of things the worst possible situation is a debate where arguments are not based on logic but on emotion. The classics in this area are statements like “Relational database is the only way” or “Nothing is better than Java and I don’t want to hear anything else”, etc. These lines and people who make these lines are detrimental to the progress of a software project. They need to be killed, erm sorry, I mean they need to update their soft-skills and learn how to control their emotion and fight it out with logic (and data where possible).

An unpleasant reminder

I was reminded of this recently in an unpleasant way. We run a series called the career booster on youtube - it’s planned as series of shorts in Bangla language about what to do to prepare yourself for a career in software. The target is mainly students and early stage professionals. The third video came out a few days ago and it had the unfortunate title of “Programming languages NEVER to learn”! By itself it’s a mistake to have a title like that because it’s plainly wrong in our field (every language including the dead ones have a place and need and people do need to learn them). The correct title could have been “Programming language not to learn as a beginner” or something like that. But the cardinal sin was that the “NEVER” to learn languages included the mother of all languages C/C++ and the other big god in the pantheon - Java! With a lineup like that a storm of protest was inevitable. The social media became buzzed with hate pointed at us (and at our idiocy). Several influencers picked up on this and we walked in shame. The hate was fully well deserved. We took the video down and tried to come up with various forms of apology and lame explanations.

Needless to say, a complete mess!

But in this huge mess at least something positive came out which is all about today’s topic about the art of making your arguments with logic. Among the literally hundreds of comments (I really mean hate messages here :) ) there were some clear patterns. Some were just awesome killer retorts that proved beyond a shadow of doubt that our video was totally wrong and why it was wrong. And some were irrational and emotional banter that added no real value. You could easily separate out the professionals from the not so professionals in our field just by looking at the comments. Let me go over some of the good ones here to highlight what works great in software. But before I do that that let me restate, the great thing to know is that:

the ability to argue well is a skill and it can be easily learnt.

So being aware that you need to pick up this skill and then practicing some caution to keep your emotion in control and your logic in hyper-drive you can hone in this skill.

Back to the comments. There were some super awesome comments. They were precisely worded, designed to hurt yet made with logic and data that is so undeniable that you can just cry and look at yourself in the mirror and try to remember where and when you lost your brain :) Here’s a particularly good example, and I’ll point out the qualities that make this such a good one:

Clarity: Notice how the writer takes a direct jab at our lame excuse of saying that we had a plan to start a debate with the video (actually partially true but very badly executed). The jab is very sharp yet it is cloaked in the wording of being helpful i.e. “… hurting people’s career, which is misleading.” Precise, to the point and without any strong emotion. The write is just expressing his concern clearly and the opposing side has to either answer back or just accept it as correct.

Supporting logic/data: Then comes the killer - data. If you have solid data as your proof for any argument it is the show stopper. The writer clearly shows that at least in the job site indeed.com Java and C++ jobs are at the top thereby proving that the main goal for our miserable video - career betterment was not met.

Suggested solution: Then comes what I think is the master stroke of any good technical argument - some suggestion on how to improve things now that crack has been identified.

I am awed by a retort like this. Software developers like this person will be an asset for any team where he works. He will make debates short by cutting out the fuss and the endless bickering. He will make his point strong and believable and thus acceptable to other team members including the opposing group (assuming they are not emotional or illogical). And he will suggest a solution and reconciliation that will help the team heal and move on. Awesome!

Here’re two more good ones in a different ways, one points out a clear issue and basically is asking us to address it. Important for any tech discussion where you throw a logical question to the other side and ask them to explain it. The other one in Bengali is purely on the solution space trying to turn the issue into something useful rather than bicker about what’s obviously wrong.

The Survey

We’ve gone over several Facebook pages and filtered out about 300 purely negative comments made by people with software background (as given by their profiles). Overall, on our rough survey only 20% or so of these comments would qualify in some way as a logical, data driven and solution driven argument. The kind of argument we love in technical debates. This is worrying but this data could be an unreliable metrics of the reality as people don’t always stay very rational or professional in a social platform like Facebook. It would have been interesting to run this on a professional network like LinkedIn and see what the data is like. But hey, that’s not going to be us! This was too traumatic and we are done self-mutilation for the year :)

Anyway, gotta go, have fun, stay logical and stay with C/C++ no matter what career videos say. btw, our next career booster video will be about this very topic but we can’t find our actor, he is in hiding after this storm… joking of course! Should come out pretty soon.

How to manage difficult software developers?

Software developers have a reputations for being “difficult”. But from my years of working with literally hundreds of developers I know that what is considered “difficult” is just a wrong way of looking at things. You can completely change the interaction and behavior of a “difficult” developer if you just adopt a few easy changes in your thinking and action. These “software people skills” are super easy and it’s really painful to see how many project managers or team leads don’t these. I’m going to do a series of software people skill going over them one by one. These are skills that are extremely easy to learn yet effective right away.

Instead of my usual of just listing them out, I’m going to make this series more hands on. I’m going to pickup pieces of conversation that are common between a manager and the “difficult” developer to show you the scenario and show you how you can completely change that conversation. You’ll notice that the manager will always be reasonable in his requests in the scenarios I talk about since I’m not talking about irrational or abusive interactions.

OK, to my skill #1

Software people skill #1: Always criticize code in private

Scene: Mr. Dev is in front of the his computer, Mr. Manager is standing next to him staring at the computer and speaking while pointing to the code. The last build of the product had some major bugs, most of the bugs on Mr. Dev’s area. Mr. Manger wants them fixed quickly so that they can meet the deadline (and also wants to air out his anger for the bugs hoping that the anger will make Mr. Dev create less bugs next time round). Other developers are within earshot.

Mr. Manager: Hey, there are way too many bugs in your part in this build. Can you please fix them asap so that we make the deadline?

Mr. Dev: You cannot blame it on me, I had way too many tasks, I told you they were impossible to finish and you are now seeing the result. So it’s your fault not mine and I’m not cleaning up your mess.

The mistake: Code is a developer’s craft. It is his creation, almost like his child and he will always identify with it. There is no way you can criticize his code and not get him emotionally affected and be defensive. And if you criticize in front of his peers and with his creation right in front of the conversation it is the worst you can make things for her. This will get you nowhere and will only make things worse down the line.

The solution: Know the sensitivity about criticizing a developer’s code. But that doesn’t mean you should not criticize or not take any action in the hope it will be sorted somehow. You just have to do it with some care.

• Make sure you have the discussion in a private space away from the peers of the developers. Ideally your office or a meeting space with the door closed. The developer will appreciate your care about keeping it private and also feel the importance of the need to address the issue.

• If the developer’s room is itself private, you should do the conversation away from his computer. This is purely from experience and a bit weird but there is definitely a psychological effect of receiving criticism right in front of the code that is being criticized.

• You should use inclusive language like “we” “us” rather than direct “you”. This gives the developer some relief that he is not the only one involved - because in a lot of situation he feels (and he might be right) that he was not the cause for the failure. Inclusive language moves the interaction to a feeling of working together to fix the issue.

• Softening the accusation a bit may help. This is case sensitive but the fact of live in software development is that people will make mistakes, there will always be some use case not thought out, some requirements will always be vague, etc. So once again if the language feels like you understand the complicated nature of a developer’s job, his reality of dealing with all kinds of unknowns and variables of a project, he will feel more understood and be less defensive.