Lone Wolf vs Team Development

I am sure I was in the same shoes as many of you. You understand that automation and NetDevOps is the future. You spent some time learning the fundamentals of Python, the structure of Ansible playbooks, and took the time to stand up an instance of NetBox at your organization. You can probably do some basic configuration changes, gather network information, and put together some reports.

However, just like me, you were at it alone. I didn’t have a team of network automation engineers that I could ask questions and bounce ideas off of. I was learning by trial and error. Google and blog posts were quickly becoming my best friends. Now, I get to work with an amazing team of people that I can learn from. Going from developing on my own to developing on a team has been a big change for me and I’ve learned a lot.

In this blog post, I will talk about some of what I’ve learned and hopefully give some words of guidance to others wanting some insight into the differences between developing alone versus with a team.

I was not as good as I thought I was

When I say this, I am not calling myself bad or incompetent at programming. What I’m saying is that working with others highlighted my own mistakes, weaknesses, and bad tendencies. This could be something as small as not following PEP 8’s guidelines to keep your lines to a maximum of 79 characters, or something more crucial such as keeping your code DRY. Being able to ask someone to review your code, bounce ideas of them, and have exposure to high quality code, especially in the context of NetDevOps, is invaluable.

Once I realized I was not as good as I thought I was, I needed to be open to constructive feedback. Asking someone to review your code doesn’t do you as much good if you just shrug off the recommendations they have. You need to take those to heart. Ask them why what they suggest is better than what you did. Take those reasons and strategies and apply them to your projects in the future.

I had the realization that other people will be reading and using your code

This can be a very scary thing at first! When writing things for yourself, you may not put much effort into the readability of your code. This is a bad habit I had. You need to always be in the mindset that someone else is going to be reading (and using) your code. A few of the bad tendencies I had were:

• Using single character variables like i in for-loops. While you may know what it is, anybody reading your code will have to do a lot of extra work to figure out what your ‘i’ variable represents. Make sure to name your iterator variable appropriately.
• Doing too much in one line. Below I update a dictionary using the update method. While it works, a lot is going on in one line.

  chassis_obj["chassis_index"].update({ 1 : {"role" : "master", "mac_address" : "AAAA:BBBB:CCCC", "priority" : 3 }})

We are updating the original dictionary with a nested dictionary, looking up variables, and casting them to an integer all at the same time. That could make your code difficult to read and understand. Sometimes it’s okay to do what you need to do in more lines of code if it means it would be easier for someone else to digest. Here is an example of that one line broken up.

    
slot = int("1")
role = "master"
mac_address = "AAAA:BBBB:CCCC"
priority = int("3")
chassis_obj["chassis_index"].update({ slot: {} })
chassis_obj["chassis_index"][slot].update( {"role" : role, "mac_address" : mac_address, "priority" : priority })
  

• Being inconsistent with the use of single quotes and double quotes. When you develop on a team, you need to be more aware of smaller details in your code. Adopting the standards of the team, even ones as minute as single and double quote usage, will ensure your code can easily be digested by others.

I also realized that it is now a necessity to read and digest others’ code

I’ve realized that reading and integrating other peoples code is a skill in and of itself, and that I did not get to practice it when I developed by myself.
Now, I take every chance I get to look at others’ code and try to fully understand what is happening. One invaluable way to develop this skill is to try and fix a bug in an open source project.
You will find that to understand the bug, you will need to understand what the code is really doing. Just like anything else, the more you practice this, the more quickly and more efficiently you will read and thoroughly understand other peoples’ code.