I’ve grown to really appreciate code reviews. Like testing, code reviews allow you to catch bugs and improve code quality. But they also help teams find better, alternative options, and transfer knowledge between team members.

What follows is a list of non-technical practices to keep in mind for conducting effective code reviews. Some of these I want to start doing, some I already do, some I do but do poorly.

1. Agree to a standard for reviews with the rest of the team. This is critical. If everyone on the team has different standards then reviews will be tough. A style guide and best practices document that the team creates is a huge help here.
2. Remember, you are not your code. It is so easy to take criticism personally but do you best to avoid this. Everyone, no matter the skill level, has areas to improve on. Accept that and thankful that you have a team that can teach you things.
3. Be kind. Don’t let the lack of face-to-face communication cause you to be harsh. It’s easy to fire out “you’re wrong” in a review and be harsher that you would face-to-face. But that is a great way to make someone defensive and not be receptive to criticism.
4. Look for things people are doing right. Pointing out new an interesting things in a review is good way to encourage learning and build relationships.
5. Be pragmatic and keep code moving. Sometimes people have differing opinions and no amount of discussion is going to change that. In that case, defer to a third party or take a vote as a team. Don’t let reviews get stuck in the mud.
6. Give reasoning. Saying “change this” without a reason is not helpful and won’t prevent similar mistakes in the future. This also helps to keep reviews objective. It is too easy to let your personal preference come out in a review as the “right way”. 
7. Ask questions. I learn a lot through code reviews. Especially when we start using a new library or tool. If you aren’t understanding, ask the team to explain!
8. Have a good attitude and assume good intent. Remember, you are all on the same team and are trying to create high quality software. Developers aren’t trying to come up with bad solutions. They may just not be aware of a better way.

If you aren’t conducting reviews yet I highly recommend it. Both Bitbucket and and Github make it incredibly easy. Any any slight slow down you might experience by always doing reviews will be more than made up for in much higher quality code and team members that are far more aware of the what is going on in different areas of the stack.

I recently read the book The Secret by Ken Blanchard. It’s a book about leadership and it gives five principles to lead by in the form of an acronym: S.E.R.V.E. The premise is that if you are a leader that serves his or her team and practices the five principles outlined in the book, you’ll be a more effective leader.

The book is written in the form of a long parable. Although I was somewhat skeptical in the beginning, it ended up being an interesting story that very effectively made it’s points.

The story centers around Debbie Brewster, her team, and mentor. In the story Debbie’s mentor guides her through these five principles and helps her make a dramatic turn around with her team.

Overall the book was helpful in giving me some principles to keep in mind while leading my team. It is all too easy to live every day simply putting out fires and never spending time planning for the future or having any real goal in mind other than “survival”.

I’d highly recommend the book both to experienced leaders and those like myself that are new to the role.

Notes and Quotes

General

• Great leaders are great listeners
• Leadership has nothing to do with ones level in the organization.
• Question to ask yourself: Am I a self serving leader or a serving leader?
• You don’t become a great leader in a moment, month, or year, but rather one day at a time.
• Leadership is more about what others don’t see than what they do see.
• Leadership is like an iceberg. Above the waterline: skills, doing. Below the waterline: character, doing. The stuff below the waterline (i.e. lack of character) is usually what sinks leaders, not their abilities.
• What big and small things can I do to serve those I lead?
• Service alone won’t make a leader great. A person can service without leading, but a leader can’t lead well without serving. Must do the five prinicples outlined in S.E.R.V.E.

See the Future

• Creating a vision of the future and ensuring the team is aware of it and on board should be one of the top priorities.
• Must create a compelling vision and is one of the privileges and most serious demands of leaders.
• There’s a constant tension between ‘Heads Up’ work (planning, setting direction) and ‘Heads Down’ work (implementation). Time must be invested in both.
• The leader’s responsibility to ensure ‘Heads Up’ work gets done.
• Values are the beliefs that drive our behavior.
• A responsibility that cannot be delegated.
• Questions: - What is the purpose of your team? - Where do you want your team to be in five years? - How many members of your team could tell you what the team is trying to become/achieve? - What values do you want to drive the behavior of your team? - How can you communicate your vision of the future to your team?

Engage and Develop Others

• You must have the right people in the right roles, fully engaged, if you are going to accomplish the things you identified under See the Future.
• If you don’t have the right people in the right job it can be very expensive and time consuming to fix.
• Other people suffer when a poor performer is on the team.
• Must engage people’s hearts and minds and have them buy in to the vision of the future. You don’t want them simply to get work done.
• Should invest a lot of time trying get people engaged and buying in.
• Some people aren’t suited for a role they’re in. Need to find their strengths and weaknesses and find the role that suits them. Sometimes people just need more training if they’re underperforming or to have better defined responsibilities.
• Helping people leverage their strengths is one of the most rewarding parts of the leaders role.
• Questions: - How much time do you invest looking for talented people to join our organizations? - What are the key characteristics do you look for in the people you select? - To what extent have you successfully engaged each member of your team? - What are ten specific things you could do to engage individuals more effectively in the work of the team and the organization? - What have you done to suggest to them that when it comes to Heads Down implementation activities, you work for them? - How are you encouraging the development of your people?

Reinvent Continuously

• A healthy disrespect for the status quo.
• The best leaders are those that continue to learn.
• If you stop learning, you stop leading.
• The leader must model the behavior he or she wants people around to emulate.
• Critical so that we can keep up with competitors and the rate of change in the world.
• Ask questions like: How can we do the work better? How can we do it with fewer errors? How can we do it faster? How can we do it for less?
• Important on three levels: - Personal: How am I learning and growing? What am I doing to encourage others in my group to constantly learn and reinvent themselves? - Systems and Processes: How are we doing the work and how can we do it better? - Structural: What changes in organization or team structure could be made to become more effective and efficient?
• Questions: - Who are your mentors? - What are you reading or listening to? - What systems or processes in your area of responsibility need to be changed to enhance performance? - How could the areas under your leadership be structured differently to enhance performance?

Value Results and Relationships

• Profits and financial strength are the applause we get for a job well done.
• Better relationships leads to better financial results.
• If you don’t have followers, it’s very hard to get long-term results.
• Must have high expectations for results and relationships.
• High level of accountability, solved problems that negatively affected performance, celebrated success are all critical.
• Must make time for those you lead and genuinely care for them.
• Catch people doing things right.
• Listen.
• Each person has his or her own personality and temperament. Building meaningful relationships can never be reduced to a checklist of activities.
• Get to know people beyond who they are at work and what they do there.
• Find out their goals, dreams, struggles.
• Ask ‘Is there anything I can help with?’
• Questions: - How much emphasis do you place on getting results? - How many of your people would say that you have made a significant investment in their lives? - What are the ways you have expressed appreciation for work well done in the last thirty days?

Embody the Values

• Genuine leadership is built on trust. Living consistently with the values you profess will help to build that trust.
• Establish, articulate, model, and enforce core values.
• If you don’t Embody the Values, you miss and opportunity to shaped the culture of the organization, and you do tremendous damage to your own leadership.
• People follow leaders they can trust.
• You win or lose credibility based on how well you embody the values, but you also set the tone and the example for the team.
• Questions: - How can you better integrate our organizational values into how your team operates? - What are some ways you can communicate our core values to your team over the next thirty days? - How can you alter your daily activities to create greater personal alignment with these values? - How can you recognize and reward people who embody these values?

My team at work has recently started doing Test Driven Development. Prior to this we had tests but they were almost always done after the code was written and they weren’t comprehensive.

Now things have changed. Now we’re writing tests first and they are an important focus. It’s sometimes been difficult to get used to and change the way you think but in the end it’s been extremely worthwhile.

As I’ve started this process I’ve made some observations that are noted here.

• You absolutely need to make sure your tests fail after you first write them. Several times I wrote a test but didn’t ensure it was failing only to realize days or weeks later that the test wasn’t working at all and the the success what mistaken.
• It changes how you write your code for the better. Easily testable code generally seems to be better, more modular code. For instance, rather than make one very large function that is a couple hundred lines long, you’ll instead break it down into 4 smaller, simpler functions to make testing each individual part easier.
• You can write a bunch of stubbed out tests that serve as a to-do list of sorts for what you have left to implement. No more separate .txt files with a list of tasks.
• Once you complete your tests they serve as documentation for what you code should do. When you see a test that says should blink the screen red and black you know that the code being tested should make the screen blink red and black. This is really nice when you’ve been away from some code for a while or you are looking at another developer’s code. Since you’ll be updating your tests as you update your code, this form of documentation will always be up to date.
• After practicing TDD for a while you’ll find yourself going back and wondering why on earth you tested some of the things you tested. The fact of the matter is that it takes some time to develop the experience necessary to know what to test and what not to test. It isn’t always easy at first but if you keep at it you’ll get there and see the quality of your tests improve.
• You quickly lose confidence in untested code. Seriously. It’s crazy how fast it happens. Maybe a week after I started doing TDD I noticed that when I went to develop a quick feature without tests it didn’t take long before I was feeling very uneasy about the correctness of my code. If I had been building this feature a month earlier I’m not sure I would have given it a second thought.
• It gives you a sense of accomplishment. There is something satisfying about seeing a bunch of successful tests and, for me at least, is somewhat motivating.
• Don’t worry about testing everything. Instead focus on testing code that is mission critical or complex. For instance, if there is some core code used by the entire app it’s probably worth while to make sure it’s tested. But have an object that is only getters and setters? It’s probably not worth testing unless they have some complex logic inside.
• For the love of Pete please make sure you are running the tests all the time. At the very least run them before pushing any changes. It’s incredibly frustrating to pull the latest changes from version control only to have the tests broken. Don’t do that to your fellow developers.
• Keep the number of assertions in each test down. When I started out with TDD my tests would often have many assertions. When there was a failure though, it was difficult to determine what assertion was failing. It’s much easier to spot the failure if you have a limited number of assertions in each test.
• Don’t make your tests depend on other tests because it will make them fragile. You’re just asking for trouble if you do.