29 May 2018 Comments Off on Habits of Highly Effective Software Developers General Software Development
By: Jonathan Donkin
Recently as I was reading Seven Habits for Highly Effective People by Stephen Covey, it dawned on me that those same habits that Covey says he put together into Seven Habits actually applies to Software Development as well. So as an attempt to gather together my thoughts both from my own experience as well as from technical books I have been reading, I decided to stretch myself and write about the Habits of Highly Effective Software Developers as a monthly blog. As you read along, I look forward to your thoughts and feedback as to what you find to be your habits that have helped you as a developer.
If you haven’t read Seven Habits of Highly Effective People, I highly recommend you take the time to read that book. I personally see the teaching in that book to apply to far more than business. I have used the techniques in my personal life, relationships and to Software Development. As we go into each habit, you will see some of the development concepts repeated as they can be applied in different ways to each habit.
So to begin here are the Seven Habits:
- Be Proactive
- Begin with the End in Mind
- Put First Things First
- Think Win-Win
- Seek First to Understand, Then to be Understood
- Sharpen the Saw
What does it mean to be proactive? As a developer being proactive means that I take charge of my outcome. Okay, so what does that mean? In preparing to write this, I found myself reading three books which are The Clean Coder by Robert C Martin, The Software Craftsman by Sandro Mancuso, and The Pragmatic Programmer by Andrew Hunt and David Thomas. As I read each of those books, I would come across something that would jive with what I was thinking it meant to be Proactive and taking charge of my outcome. So far I have two main areas that I see developers being proactive in their work. Take responsibility for your software and take responsibility for your learning.
Take Responsibility for your Software
To me every time I write software whether it is my own personal project or a client’s code I take ownership of that code. It would be like a custom furniture builder only taking their time creating the best stuff for themselves while rushing their customer’s products through their shop creating a substandard product that they then deliver to the person who is paying for their product. Our software isn’t much different when we write our own code.
One of the best ways that we can take ownership of our own code is to test our code to make sure that it is functioning correctly. “Therefore, when you release your software you should expect QA to find no problems. It is unprofessional in the extreme to purposely send code that you know to be faulty to QA” (Clean Coder pg. 12). The section goes on in a moment to say will QA find bugs, and the answer is yes. We will test the code to our understanding, and then QA will test it to theirs which isn’t always the same as ours, and that is when they will find the things we didn’t think of initially.
How should we be testing our code? The easiest way for us to test our code is to write unit tests on each unit of work that is done. One other thing here that is important to note is that a great test is only testing one thing, not multiple things. Tools like junit and nunit allow for you to pass multiple parameters into a single unit test allowing for multiple scenarios to be tested against your method. While there is a lot more to be said about testing that is outside the scope of this article and there are currently plenty of articles and videos out there on unit testing. Another way I like to test is to simply run the code and manually make sure that it is behaving like I expect it to. For API’s I like to use Postman to hit my endpoints and for any UI, manually testing and using the chrome debugger tools.
Take Responsibility for your Learning
While we are all able to learn while on the job, I personally have found what helps me shine as a developer is taking control of my learning instead of waiting for my learning to come to me. This idea was inspired from reading the Software Craftsman by Sandro Mancuso who in chapter four asks the question “Who owns your career?” His point it seems is to point out that while most places should be an effort into your learning and training, it isn’t completely their responsibility. He even makes the comparison that if you were to hire a different professional such as a plumber or lawyer, they wouldn’t ask for you to buy them a book for them to do the job in which you have hired them.
I am of the mindset that writing a blog is a great way to learn as well. As I come across something that I need to learn in order to finish what I am working on either for myself or a client, I am inspired to do a deep dive on the subject and put together a blog post teaching what I have learned to others that may find it. For me, this does two things. First, it helps cement what I learned by taking the time to write out the steps needed to solve the problem and second, it acts a way to keep a record of what I did previously to solve the problem. I win and hopefully whoever finds this post learns from it as well.
The final thing that I love for my own learning is training videos that you can get from many places, but two of my favorite are Pluralsight and YouTube which have many courses to choose from. Ultimately there is more content than any one person can learn in their lifetime.