Becoming a Great Developer
The day will come, probably not far from now, when some poor software guy will do some dumb thing and tens of thousands of people will die… and [the politicians of the world] will point their finger at us and they will ask the question, ‘How could you have let this happen?’
- Uncle Bob
Software is not absolutely everything, but it has become critical in how the world operates. Beyond being a writer of quality code, being a professional software developer is a huge responsibility. You’re in charge of code that is underpinning vastly complex systems. Websites, people, and businesses depend on your efficacy. And this is something that I had not seriously considered until entering the tech industry. Just because I am not a doctor responsible for a patient’s life, does not mean I don’t bear any responsibility or my actions do not have grave implications.
In essence — you can think of this blog post as my Hippocratic Oath, my commitment to being the best developer I can be.
I watched a recorded video of a talk given by Robert C. Martin (known in the tech community as Uncle Bob) about expectations of professionalism as a developer. He references the shortcomings of companies and agencies — including the space shuttle Challenger, which exploded a few seconds after launch — due to irresponsible engineering. What he taught us what that when something is amiss, it is not to just stand on the sidelines. Rather, we must go above and beyond our call of duty.
I was fascinated by how Uncle Bob challenges us to be better people, daring us to care about more than just ourselves — to the point of willingness to lose our jobs. And in becoming developers with such conviction, we must be ethical and honorable; we must unequivocally “take responsibility for knowledge.”
Throughout the talk, Uncle Bob positions himself as your personal CTO in a hypothetical world and talks about professionalism as a set of standards. Amid random lessons about gravity and GPS receivers, he highlights key expectations of you (his employees) that I’ve thematically grouped together. While some may be common sense, some of his ideas are also purely radical — like re-thinking QA not as back-end manual testing, but rather as a proactive tool to ensure quality code. I find that the most straightforward, common sense of lessons are the ones that need to be articulated often.
We invented software so we can easily change behavior of machines… I expect you to adapt to change.
Ship high-quality software. Code bases should be well-documented and tested; there should be no bugs. And there should be confidence among programmers that the code works. Nothing should be fragile and easily breakable if there are changes. If code is shipped, there should be no defects. And code should be written in a way that enables future changes because that is the nature of software and requirements will change.
Be fearlessly competent. One of my favorite expectations that Uncle Bob had mentioned was “fearless competence,” which is what I aspire toward. What this means is not being afraid of adding new features or refactoring, especially in your own code base. He encourages conquering this fear through test-driven development. As a career changer, as someone who sometimes lacks self-confidence — I have been challenging myself to be dive deeply, to be unfazed by the prospects of writing and re-writing large amounts of code.
Stable productivity. Uncle Bob warns programmers to not speed up at the beginning of a project, and then slow down due to the build-up of messy code. Rather, we should be continuously improving and getting better over time. We should, in fact, be getting faster.
Be a team. Whatever happens to your teammates, you should be able to cover for each other at any given moment. The only way to do this is to work together through pair programming and interacting with each other. Share knowledge of each other’s source code and test suites.
Be honest and frank about what you know and don’t know. One of the things that I’m working on, per my retrospective blog post, is being better at projecting deadlines. Uncle Bob says that an honest estimate is not a date. He encourages you to describe the shape of your uncertainty. One way to do this is provide three dates: one for the best case scenario, one for the nominal case, and one for the absolute worst case.
Always be learning, aggressively. What attracted me to the tech industry is its dynamic nature. Beyond 40 hours of work, Uncle Bob says that we need 20 hours of our own time to be learning and be a worthwhile software developers. We must continuously be reading, going to conferences, blogging, taking classes, and experimenting on our own time. Uncle Bob compares developers to other professionals, such as lawyers or doctors, and talks about how we typically uphold their characters to a high-level of standard. We should do the same with ourselves and other developers.
Teach each other and mentor. Uncle Bob understands the limitations of those who are new to the industry and underscores the importance of being trained. Nearly everyone has a consensus about mentorship, but I think few companies foster training through mentorship (whether formally or not). I also believe that mentorship is critical to diversity and a great work culture. This is one of 8th Light’s greatest assets and I hope to carry the torch of being a mentor one day.
