Throughout my career (and life) I’ve been on many different teams. Obviously, this implies that I’ve been a teammate to others and had many teammates of my own.

I bring this up because yesterday I had an interaction with a current teammate of mine that made me think “Wow, what a great person to work with.” This led me to wonder if anyone has ever said this about myself. Then, I began to question what really is the hallmark of a great teammate. Someone that you look forward to working with every day and someone that you would be generally sad to see join another team.

As technical people it is so easy to get caught up in our work; problems are there to be solved and it is easy to shift your focus and neglect the world outside.  But becoming a great teammate can be one of the best ways to pave a great career path in the future.

So what makes an awesome teammate?

I think a good place to start when trying to answer this question would be to look back over the years of the people you know that everyone loved to work with. What were their qualities? Why did everyone like them so much? Why did youlike them so much?

Next, after you have a handful of people that you have determined were great teammates, think about the other end of the spectrum. Who were the people that you knew on teams that everyone avoided? Why did others dislike working with them? What made interacting with them so unenjoyable.

After asking myself these questions, I made a few observations.

Be positive, and have a good outlook.

This is pretty simple and should probably come as obvious.  At its core though is having a good attitude and looking at each day and project as an opportunity. Not just to get a lot done, but also to make steps at being a better person. This means not just having a good attitude when you’re haveing a great day, this means even in the face of very stressful situations – like when your website goes down, or there the system stops behaving correctly during a launch event – you stay positive and calm and work together with your team to provide a solution. Getting pissed and yelling at everyone never solved any problems (but I’m sure it has created a few).

The people I recognized as good teammates were generally happy, positive people. They recognized the best in people and situations; they pulled their own weight and were enthusiastic to help when  needed.

On the other hand, people that weren’t as great to work with were mostly the opposite. They had a negative attitude about the project or team or even the day of the week it was. They weren’t enthusiastic about helping others or getting out of their comfort zone. Even on sunny days when everything was going right, they still seemed to have a problem with something or somebody. Don’t be this person! Nobody wants to listen to Debbie Downer all day long.

Bring solutions, not problems

This one hits home big for me. In the beginning of my career, I used to work with someone that always had a problem with the way something was done or an idea that was brought up. This person was definitely a pessimist and if you brought up an idea or solution to him he would meticulously pick it apart and tell you all the reasons it wouldn’t work. This was especially unfortunate because he was the team lead of our project. Eventually, people stopped sharing their ideas with him in fear that it would get shut down and they would be ridiculed for bringing up such an absurd solution.

This finally got to me, and one day I asked him what he would do to address his concerns. I asked if he would start thinking about the problems from all sides, and start coming up with ideas rather than shutting everyone else’s down. Eventually, he started coming up with a list of things that could be done to mitigate the problems. Just coming up with some potential solutions makes the conversations much more pleasant.

Next time you want to tear down someone else’s idea, remember that they at least came up with an idea to try to help solve the problem (you didn’t). Unless you have something that would work better as a solution, try to find a way to mold their idea into something that could work rather than picking it apart for all the reasons that it won’t.

Always take the blame, but never take the credit.

This has been called out in Jim Collins book “Good to Great” and for good reason. This is one of the most important aspects of a good teammate and a good leader.

Everyone wants to be liked. I know I do. If you understand this about people, it can really empower you to be a better person all around.

When you achieve success, generally it was through the help of many people. Making sure you recognize this fact and never slight anyone is very key. Make sure to use “We” instead of “I” when talking about any of your accomplishments. Even if you were the one that did 99% of the work to complete a project, praise Joe for the 1% that he completed! I can guarantee that it will make a world of difference to him, and if you don’t he might even hold a grudge against you for it. People want to be appreciated, even if it is for the tiniest of tasks. Let them know that you recognize the work that they have done and are glad to have them helping you.

On the flip side, if a project fails or a major bug gets released into production, always take the blame. There is something to be said about having full ownership with everything you do in life and understanding that there is no reason to blame anyone else. Take responsibility and learn from your mistakes, even if your mistake was hiring a developer that didn’t understand that he should encrypt credit card numbers in the application and sent them over the wire in plain text…(uh-oh!).

While it may be mostly someone else’s fault, standing up and owning your part prevents others from feeling slighted.  Plus, people want to work with people who own their mistakes and failures.  Of course, a key part of this is also addressing the cause, or mitigating it in the future.   Regardless, don’t blame other people or point fingers, real leaders and great teammates take ownership and then strive to do better next time.

(For more on taking full ownership, read this great book written by retired Navy SEAL Jocko Willink –> http://www.amazon.com/Extreme-Ownership-U-S-Navy-SEALs-ebook/dp/B00VE4Y0Z2/ref=tmm_kin_swatch_0?_encoding=UTF8&qid=&sr=)

These are just some of the most important qualities that I believe makes a great teammate. When you thought about the people you enjoyed working with the most, what qualities did you find? Let me know in the comments!

If you liked this post, please share it with others! That is the biggest compliment I could receive. Please subscribe if you are a technology enthusiast!

SPOILER ALERT: Yes.

Code without tests is such an old idea that in his book “Working Effectively with Legacy Code” (written in 2004!) Michael Feather defines “Legacy Code” as code that is not accompanied by unit tests.

This should be common knowledge by now in the software community, but I still am running into developers that do not see the incredible importance of unit testing.

Like many folks, I have long admired parts of “Uncle Bob” Martin’s work. While I disagree with him, sometimes strongly, on some of his views, there is no question that a meme he has long pushed is absolutely spot on: Checking in code without accompanying tests is unacceptable.

I’m not here advocating Martin’s larger solution (test-driven development), but rather acknowledging the rectitude of his fundamental position. To be fair, Martin is not the only person, nor even the most prominent, to advocate the value of checking in code and tests at the same time. Kent Beck, Michael Feathers, and many of the exponents behind continuous integration and DevOps have long articulated this position. But Martin has tirelessly championed it and, in large part because of his efforts, most diligent developers today reflexively understand the importance of writing tests that immediately exercise their new code.

J. Timothy King has a nice piece on the twelve benefits of writing unit tests first. Unfortunately, he seriously undermines his message by ending with this:

However, if you are one of the [coders who won’t give up code-first], one of those curmudgeon coders who would rather be right than to design good software, well, you truly have my pity.

Extending your pity to anyone who doesn’t agree with you isn’t exactly the most effective way to get your message across.

Consider Mr. T. He’s been pitying fools since the early 80’s, and the world is still awash in foolishness.

It’s too bad, because the message is an important one. The general adoption of unit testing is one of the most fundamental advances in software development in the last 5 to 7 years.

For anyone new out there or someone not familiar with Unit Tests, let’s first get a formal definition so that we are all on the same page. Kapeesh?

What is Unit Testing?

Essentially, a unit test is a method that instantiates a small portion of our application and verifies its behavior independently from other parts. A typical unit test contains 3 phases: First, it initializes a small piece of an application it wants to test (also known as the system under test, or SUT), then it applies some stimulus to the system under test (usually by calling a method on it), and finally, it observes the resulting behavior. If the observed behavior is consistent with the expectations, the unit test passes, otherwise, it fails, indicating that there is a problem somewhere in the system under test. These three unit test phases are also known as Arrange, Act and Assert, or simply AAA.

A unit test can verify different behavioral aspects of the system under test, but most likely it will fall into one of the following two categories: state-based or interaction-based. Verifying that the system under test produces correct results, or that its resulting state is correct, is called state-based unit testing, while verifying that it properly invokes certain methods is called interaction-based unit testing.

King presents a list of 12 specific ways adopting a test-first mentality has helped him write better code:

1. Unit tests prove that your code actually works
2. You get a low-level regression-test suite
3. You can improve the design without breaking it
4. It’s more fun to code with them than without
5. They demonstrate concrete progress
6. Unit tests are a form of sample code
7. It forces you to plan before you code
8. It reduces the cost of bugs
9. It’s even better than code inspections
10. It virtually eliminates coder’s block
11. Unit tests make better designs
12. It’s faster than writing code without tests

Even if you only agree with a quarter of the items on that list– and I’d say at least half of them are true in my experience– that is a huge step forward for software developers. You’ll get no argument from me on the overall importance of unit tests. I’ve increasingly come to believe that unit tests are so important that they should be a first-class language construct.

Obviously, writing testable code requires some discipline, concentration, and extra effort. But software development is a complex mental activity anyway, and we should always be careful, and avoid recklessly throwing together new code from the top of our heads.

As a reward, we’ll end up with clean, easy-to-maintain, loosely coupled, and reusable APIs, that won’t damage developers’ brains when they try to understand it. After all, the ultimate advantage of testable code is not only the testability itself, but the ability to easily understand, maintain and extend that code as well.

I encourage developers to see the value of unit testing; I urge them to get into the habit of writing structured tests alongside their code. That small change in mindset could eventually lead to bigger shifts like test-first development — but you have to crawl before you can sprint.

If you liked this post, please share it with others! That is the biggest compliment I could receive. Please subscribe if you are a technology enthusiast!

References: http://www.drdobbs.com/testing/the-embarrassing-costs-of-not-testing-yo/240162967

http://blog.codinghorror.com/i-pity-the-fool-who-doesnt-write-unit-tests/

https://www.toptal.com/qa/how-to-write-testable-code-and-why-it-matters

If you know me personally, you know that I love to read. It started in grade school where the elementary school I attended offered points and prizes for those who read (and passed tests on) the most books every month.

I remember I graduated with the 3rd most points in the history of the program (something like 10 years). However, the reason that I grabbed a book and started reading so much wasn’t because of the points and prizes that the students were rewarded with – it was because getting lost in a series like “The Lord of The Rings” or reading an autobiography by one of history’s most famous individuals (“My Life and Work” (Henry Ford)) was so much more entertaining than watching a quick movie or a TV show. The latter mediums just couldn’t capture magic the same way a book could.

This continued into college, but by then, I really became most interested in non-fiction books (though TLOR will always hold a special place in my heart). I kept reading biographies of people that inspired me or read books written by those that I respected or wanted to imitate in a particular skill or expertise.

I always found it interesting that so many people rely just on what their professors, teachers, or parents educate them about, instead of supplementing this education with some of the work of the actual masters of a particular domain.

I think that it is incredible that any average human being can pick up a book written by a world expert for only a few bucks! This luxury that we have should not go unappreciated. If you learn how to self-educate yourself by reading and, more importantly, putting what you have read into practice, you will gain a much more robust education than even the top schools could ever rival.

For this reason, it is my goal to read about 100 books a year on topics that I either want to improve on or just find very interesting. Education should never stop once you have finished school. In fact, this should be just the beginning. Through schooling you learn how to learn and the discipline of learning. Now that you have that, you are set free to study the great works and wisdom of the most influential and successful people of the world! Exciting isn’t it??

I think so anyway.

This last year I read a lot of great influential books that impacted my life. Many people think that I only read computer science books because that is my career and one of my passions. However, I find that since I code for my day job 8 hours a day (and have to read a lot of technical literature for that), I get a lot of this knowledge just from experience. Sure there is a lot I still don’t know in this domain, but there is so much more in the world that I could master that would pay much higher dividends.

What I really like to read about falls into twelve broad categories:

1. AUTOBIOGRAPHIES/BIOGRAPHIES
2. BUSINESS & ENTREPRENEURSHIP
3. GETTING THINGS DONE
4. HAPPINESS/MINDFULNESS
5. HEALTH
6. INFLUENCE & PSYCHOLOGY
7. INTERNET MARKETING
8. MARKETING
9. MONEY
10. PHILOSOPHY
11. RELATIONSHIPS
12. SUCCESS

These categories were chosen because I believe these are some of the main areas in life that one can improve on and can learn from the people who have proven they are the best and most knowledgeable in their particular field.

As the title of this posts implies, these books below have changed many different aspects of my life and I try to take at least one main principle from every book and apply it to my life. This has resulted in a much happier, productive, healthy, and successful me!

I promise if you read the books on this list, it will change your life as well. 

Without further ado, the list!

THE LIST

1. Steve Jobs
2. Made In America
3. My Life and Work (Henry Ford)
4. The Autobiography of Andrew Carnegie
5. Pour Your Heart Into It
6. Losing My Virginity
7. Total Recall
8. The Everything Store
9. The Snowball
10. The Score Takes Care of Itself

1. The Power of Now
2. Peace Is Every Step
3. Loving What Is
4. The Happiness Advantage

1. The Story of the Human Body
2. 50 Secrets of the World’s Longest Living People
3. The Primal Blueprint

1. Influence
2. Secrets of Power Negotiating
3. Introducing NLP
4. Predictably Irrational
5. The Believing Brain

1. Dotcom Secrets
2. 80/20 Sales and Marketing

1. Breakthrough Advertising
2. The 22 Immutable Laws of Marketing
3. Positioning
4. Purple Cow
5. Scientific Advertising

1. The Richest Man in Babylon
2. Rich Dad, Poor Dad
3. Money: Master The Game
4. The Warren Buffett Way
5. Financial Intelligence for Entrepreneurs

1. On The Shortness of Life
2. Meditations
3. Letters from a Stoic
4. Ralph Waldo Emerson’s Essays

1. How To Win Friends and Influence People
2. The Go-Giver
3. Difficult Conversations

1. Think and Grow Rich
2. The Slight Edge
3. Outwitting the Devil
4. The Magic of Thinking Big
5. Psycho-Cybernetics

Well, that is the list (for now)! All of these books can be found on Amazon and I believe all of them are affordable ($10-$30) which is crazy for how much value they have brought into my life.

Read them, learn them, love them, LIVE THEM!

If you have any other books that you believe should be added to the list, PLEASE LET ME KNOW IN THE COMMENTS!

If you liked this post, please share it with others! That is the biggest compliment I could receive and encourages me to keep writing.

Please subscribe to this blog if you are a technology enthusiast!

Have a great day!