Development Process, Technical Leadership

Code Review Systems Are Harming Your Team

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Code reviews should be an essential practice in every software development team. As an industry, we are long past the discussions about whether to perform them at all, focusing on implementing them in the most effective way instead. As with many popular practices, some companies offer tooling that promises to lower or even eliminate the hard parts of it. You can tell from the title that I’m not a huge fan of those.

Problems with Code Review Systems

To be clear, I am writing here about systems that support offline (or ‘asynchronous’) code reviews. You send the code changes to another team member through the system and get their approval or suggestions back after some time. They are meant to save time by eliminating the need to meet and chase people, but they actually harm your development process in multiple ways.

Decreased knowledge sharing. Besides identifying code issues, another benefit of code reviews is an opportunity to share knowledge and experience between team members. And it works in both ways – the reviewer and the code author can give each other additional insight into a specific part of the system, technology, business domain, and more. It’s not something that would normally be entered in code review comments, many such things come up during a conversation between developers.

Communication issues. Teach your people to avoid talking to each other and you’re asking for big trouble. Giving ‘code advice’ is a very delicate matter, it’s easy to offend someone just by using the wrong tone of voice, and it’s even more difficult to control such effects in writing. Developers usually approach this in one of two ways: some avoid the possible confrontation by giving ‘standard’ comments, and others just directly write their opinion, not caring about how it will be interpreted. As you can guess, both ways cause problems.

fight photo

Lower job satisfaction. Many developers actually enjoy showcasing their work when they feel it was done really well – it’s like showing our precious baby to friends. Having it reviewed by someone offline is not really the same thing. You don’t hear the reaction or see the look on their faces while you guide them through your brilliant solution…

Less pressure for quality. I believe that most people (not just developers) do a better job when they actually have to show and explain the results to someone else. We all want to appear smart (or at least avoid humiliation), and we are often willing to give extra effort for that. Again, it’s a stronger effect when you do that in person.

Interruptions. Do you think you’re limiting the interruptions in your team by queuing the code reviews in a tool? Think again. What you are actually doing is replacing a small interruption with a larger one. In most cases, it’s just more difficult to shift your mind from one coding task to another, than from coding to reviewing (and back).

For instance, imagine a developer finishing a coding assignment. He puts the task into Pending Review status in the system and starts development of another feature, shifting his focus to a different problem. Then, after a few hours (or even days), he receives a list of required fixes from the reviewer. He goes back to the previous feature, possibly interrupting the new task. How much time will he lose to switch back to the original context? How many little details has he already forgotten about? How many issues it will cause? What is his motivation to change a feature he has already (mentally) closed?

The Good Kind of Tools

Having stated the above, I definitely support and encourage utilization of static code analysis tools, like FxCop and StyleCop for .NET developers. I believe such tools should be an important step in every mature build process. They give you multiple benefits without any significant drawbacks, and require only constant (i.e. independent of project size) time to set up.

Another scenario is audit documentation, e.g. PCI. It’s easier to keep code review evidence for such purpose in a system rather than on separate forms, but it should only be used as a means to document code reviews that were performed, rather than as a replacement for them.

Summary

For every automation opportunity you need to carefully review both sides of the picture. While ‘offline’ code review systems can save you some time in the short term, the long term results will vary from some missed opportunities at best, to significant communication and quality issues at worst. I’m not saying ‘don’t use them at all’, but if you decide to utilize such platform then make sure it’s not used for all reviews, and it’s not an excuse to avoid direct communication and important discussions within the team.

At this point, a valid question would be: if we avoid using code review systems, how can we make our review sessions effective? That’s going to be the topic of my next article.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Links

Leadership Links Mashup #1

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Every single day I read at least a few articles about topics which I want to grow in. When I was working as a software developer, I used to follow a number of technical blogs and websites. I found it to be a simple and effective source of programming knowledge – a great complement to books and practical exercise. Just spend an hour per day while queuing or commuting, and you soon become the ‘go-to’ person for your colleagues when they need an advice on which tool or method can be used to solve a particular problem.

In a manager’s role this approach was still very useful to me, and I naturally started looking for similar resources about leadership and related soft skills. While there’s plenty of such content on the web, it was very difficult to spot the really valuable articles among all the feel good/dream big/be yourself mumbo jumbo.

So after spending a lot of time myself, I decided to make it easier for others and publish a regular selection of the most interesting links I have encountered recently. I don’t want to commit to any particular frequency at this point, I will just post them each time I collect an interesting bunch. They will cover both general leadership skills, as well as topics specific to software development management.

Below you can find the first selection. Enjoy!

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Management, Technical Leadership

Why You Should Become a Technical Leader (Or Not)

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

For most software developers, there comes a moment in their careers when they ponder next steps. Should I continue in my current role, gaining more and more experience and eventually building more complex and challenging applications? Or should I follow a different career path, more focused on managing teams? What factors should you take into account when making such decision? Here are the ones that I consider to be the most important.

manager photo

Job Satisfaction

In general, are you enjoying your current role? It might seem obvious to answer ‘No’, as you otherwise wouldn’t be considering a career change, but think about it for a bit longer. Is your lack of satisfaction really caused by the role, or maybe it’s because of your current project, assignments, the people you’re working with or some other factor that can be changed?

When was the last time that you felt good about your job? When were you last excited about your next day at the office? What is different from then to now? Before you make a serious career decision, try to recreate that situation and see if you can feel the energy once again. You could discuss such options with your manager or coworkers, consider moving to another project or volunteer for additional tasks – depending on what made you happy the previous time. You should also consider other technical paths, like becoming a trainer or possibly an architect.

Once you are confident that this type of challenge is needed, a manager’s job can be extremely satisfying – if approached well. While you no longer have direct control over the results, it’s a great experience to see how your efforts bring benefits in the long term. Helping your team members grow and achieve their own goals is another source of fulfillment. There’s also a lot of room for creativity: team building, strategic planning, making decisions that shape your projects or even the whole company – all of that can turn out to be a wonderful journey.

Personal Growth

Leading a team requires applying more soft skills than technical work. Qualities and abilities such as:

  • Confidence
  • Effective listening
  • Delivering feedback
  • Building trust
  • Communication
  • Time management
  • Negotiation
  • Conflict resolution
  • Building engagement

are important for all employees, but need to be used to a much larger extent by a leader. So if you want to be good at this job, you are forced to improve on them. As a side effect, you can become a better person and enhance your behaviors in other areas of your life. If you approach it correctly, it can help you improve relationships with your family and friends, deal with personal problems more effectively, and so on.

Future Career

Have you ever thought about what you want to do in your 40’s? What are your long-term career goals, what type of job would you like to perform? If you intentionally want to continue in a programmer’s role, eventually getting onto more and more advanced projects – that’s perfectly fine. However, many software developers don’t even think about it now, which I see as a big mistake.

road photo

Some people have well-defined goals for their future, for example they would like to become a CIO, or even run a software company. If you belong to that group, becoming a technical leader is definitely a good step towards that goal, and will allow you to start gathering the required experience. Even if you want to run your own start-up, such practice can serve as a great foundation.

In general, performing a team leader’s role allows you to verify if a manager’s career is something you actually want to pursue in the future, without dumping all of your technical duties now.

Summary

The right motivation is everything in a manager’s job. Without it, you won’t be able to accept the increased amount of stress and effort, lack of direct control over results, additional (huge) amount of learning, and all the other factors that are required to perform well in this role. Make sure this is really what you want and need for your career and life, and don’t let it become an escape from your current work problems.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Management

Two Essential Qualities of a Manager

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

Apparently a great way to increase one’s blog post popularity is to place a number in the title, as in ’10 Easy Tips to Achieve Ultimate Happiness’ or ‘5 Guaranteed Ways to Have a Great Date’. However, it’s not the only reason I used this headline. I actually believe there are two main, simple to understand qualities that you have to develop in order to achieve great results as a manager (although ‘simple’ does not equal ‘easy’ in this context). In my opinion, all the other traits are built on the foundation of the two below.

office photo

Photo by Simon & His Camera

Ability to Execute

Let’s say your team has an assigned project, task, duty of some sort – and your task is to drive them to the finish line. You will face obstacles, have schedule or resource challenges, unexpected technical issues, and so on – but most of the time, your team will deliver. You will keep the team focused and motivated, help them get through difficult moments, negotiate with your customers when necessary, and do anything else that is required to achieve the final result. And you will do that without getting your employees or peers to hate their jobs… and yourself.

Sometimes the obstacles can be very tough, and caused by external factors. If someone analyzes them after your failure, they will clearly see that it wasn’t your fault. But guess what, it doesn’t matter. You’re no longer an engineer, you’re a manager – and you’re expected to get things done; excuses (even legitimate) don’t work anymore. Only the end result will be noticed – sad, but true. I guess that’s why so many software developers revert to a technical role after their first leadership experiences.

How to get there is an entirely different story with many books written on the topic. The bottom line is, you want to be the person that people describe as ‘making things happen’, rather than ‘whoa, that poor chap has a really tough project, sucks to be him’. The latter won’t get you anywhere.

Continuous Improvement

Let’s assume you are already good at execution– you deliver the results on time, creatively eliminate obstacles that show up, and so on. Does that make you a good manager?

I believe this is enough to be called an administrator of the team, but if you want to be a full-blown manager, you need to do one more thing: continuously improve your team’s performance. Enhance the development process, tools, knowledge, procedures – everything that can give a long-term benefit for the team and the company.

There are many possible approaches to do that effectively, and I will touch on that in future articles. The same with carving out time for long-term activities of this kind, as it is often difficult. For now, I want you to at least understand the importance of improvements.

What are the consequences of ignoring this aspect and only focusing on good execution of your day-to-day tasks? In the short-term it probably won’t get noticed, but after months or years, here’s what may happen:

  • Fires will tend to occur more often, as you usually focus on dealing with the immediate effects, rather than focusing on root causes.
  • Recurring problems will make your customers feel that they will never be resolved, which can damage their trust in your team.
  • Your employees will notice that they are not growing, which will make them worried, disengaged, and eventually seeking job change.
  • You will lower your chances to distinguish yourself among others in this position.
  • Your managers could see you as burnt out, and may stop considering you for the most interesting projects.
  • You yourself will feel stuck and bored, your work will be draining your energy instead of motivating you.

Of course, in order to have good results in improving your team’s work, you first need to have a vision and prepare a strategy, but also apply the changes in practice. That’s why I have described the execution skill as the first one to master.

So these are the two most important qualities of a manager, as seen by me. Of course in this area there are many different ways to achieve the same result – I wonder what is on your list? Please let me know by leaving a comment below.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Uncategorized

What Others Can Learn From IT

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

In my introductory post I wrote about how I want to help in filling the gap in leadership practices between Information Technology and other industries. I focused on practices that IT leaders could learn from other areas. In this article, I’ll focus on the counter perspective.

agile pm game photo

Photo by VFS Digital Design

There’s been an increased interest in Agile methodologies over the last few years. Agile was not born out of IT, but that’s where some of its applications (e.g. Scrum, XP, Kanban) have been widely adopted. Results were so great by comparison to traditional processes that other industries are now adopting Agile methodologies based on IT experiences.

One of the most interesting examples came from Joe Justice, the founder of Team WIKISPEED, who decided to apply Scrum to building… cars (yup – those with engines, 4 wheels, and everything else that’s needed for driving around). In doing that, he is utilizing a number of practices adopted from software developers. I strongly recommend watching his TEDx presentation (see below), where he explains details of the approach – I’m sure every developer will find them very familiar:

Several years ago, I experienced a similar situation myself, while attending a Scrum workshop. It turned out that only a fraction of the attendees had anything to do with software. I met a geologist, a publishing house PM, and lots of other interesting people who had nothing to do with IT. They simply came to the workshop to learn more about the topic that is becoming increasingly famous in the business world, to see in practice what all those geeks have been doing and how Scrum works under the hood.

People from both worlds, IT and business, can learn and benefit from each other. I trust the articles published here will be of use and value to the wider audience.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard
Uncategorized

Why I Decided To Write This Blog

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail

I’ve been leading software development teams for over 7 years now, and throughout this time, I’ve encountered great content published in the industry: books, articles, videos, presentations and lots of other stuff. Almost all of that knowledge was either purely technical (describing a specific technology or a set of programming practices), or related to particular software development processes. Unfortunately, there wasn’t much about the general aspects of team management in IT.

Sure, there are lots of blogs about Scrum, Kanban and other methods of driving software projects, but I’ve been always lacking a solid resource about people stuff – describing how to lead others, build your authority, manage relationships properly, coach team members, resolve conflicts, communicate feedback… Lots of the soft skills that other industries train their people in very early when they get the role (well, in good companies at least).

For an IT person, when they become a manager of some sort, it is difficult to shift the focus from technical aspects, and they are often left on their own to figure it out. The most curious ones will get to some general management resources – and there are many great ones, of course, but applying them in a quite specific IT environment may be challenging and could raise a lot of questions.

And that’s the gap I want to fill with this blog: gather the knowledge at the interface of Management and Software Development. Some of it will be from my own experiences, other pieces may come from various external sources. I am also hoping for lots of good discussion and knowledge exchange with all the development managers, team leads and lead engineers out there!

I would also like to help those who want to become technical leaders, or have recently started in that role. I still have much to learn myself, but I believe some of my experiences can prove valuable.

So let’s see how it goes – at the moment I have a number of ideas for articles, but I would love to hear topic suggestions from you, Dear Readers – please remember to mention them in the comments.

FacebooktwitterlinkedinmailFacebooktwitterlinkedinmail
Standard