We’re software developers and we take our art form seriously. Our palette is the editor to which we lay down our beautifully crafted code. How we name variables, how we shape methods and how we format code, leaves its own unique DNA sequence that can quickly identify the owner. Even after running code through a standardized formatter, the author is not immune from detection.
Software development has always been a group effort. If you write code that is never seen by another pair of eyes, then you aren’t really a software developer. A hacker at best maybe. The worse thing you could ever find yourself in is being the only developer in the company.
I bet some of you are thinking that sounds wonderful. No one telling what to code, how to code, silly release procedures having to be followed, tickets to be created/updated, what language to use, the list can go on. However, how would you know if you are any good? How would you know if what you are creating is top quality?
The simple answer is you wouldn’t. Sure you can read as many forums, mailing lists and books on coding as you wish, but since no one is forcing you to follow any of the process, no one is keeping you in check and challenging your ideas and thoughts.
Developing software is like having sex – best enjoyed in at least a pair, if not more, but never a solo affair.
The best developers in the world have that one person in their lives that they can go do and have them say “yeah, that is not bad, but what if…” and leave you wondering if the solution you just designed was as good as you thought it was when you first presented it.
Challenges is what makes our designs great. A challenge will ask the questions we never dared to ask or even thought to ask. A challenge will let you tighten up areas that you assumed wouldn’t need any explanation (“I mean that section is obvious isn’t it?”).
If you write code that is never seen by another pair of eyes, then you aren’t really a software developer.
A challenge doesn’t necessarily have to be a complete interrogation under the spotlight. It can be as passive as a code review with a simple question “why did you do it this way?”. That question can quieten even the most hardened developer as they try to recall the reason they have constructed a method/loop like that because while it made complete sense at 2am in the midst of a caffeine induced coding marathon, 3 weeks later, in the cold sober light of day, it makes little sense now. What is even more baffling, is that it works!
Your code needs eyes. The more eyes you can get to look at it the better it will be. Who knows, you may have got it right it from scratch, but at least with more eyes looking at it, you will have that validation.
A good code review isn’t pouring over single line of code, determining if they have used the right method or API call – an experienced developer will be able to see that quickly with a quick glance. It isn’t about how the code looks in the editor either, chances are you should be all using a standard code formatting template that brings everyone’s code to look’n’feel the same.
A good code review is making sure all the components are put together in a logical manner that is maintainable, readable and flexible enough for the future requirements that may be made of the component under review. In most cases, code reviews will always result in code being removed, rarely added, due to the fact that developers have a natural tendency to over complicate instead of over simplify.
The next time you write a piece of code, or design a system, invite someone over to take a look at it and let you walk them through your thinking to see if they agree with your conclusion. If they agree with you, then thank them kindly and ask them to move along. You want to find that person that will disagree with you on at least one point.
Once you find that person, keep them close, they will make you a better developer.
alan williamson 