In Part 1 of this series, Focusing on People, Not Technology, I talked about how technology should be used to solve problems for people. But I also stated that it is our job to know how to apply the technology. This part of the recipe will focus on how there is more than one definition of CI, traditionally continuous integration, and how continuous improvement is more important in the recipe for software development.
Part 1 of this series, Focusing on People, Not Technology, talked about how technology should be used to solve problems for people. But it also stated that it is our job to know how to apply the technology. This part of the recipe will focus on how there is more than one definition of CI, traditionally continuous integration, and how continuous improvement will improve not only ourselves but our overall solutions.
A great cook will tweak a recipe again and again, adding new learnings like: better ingredients, new tools, new processes, etc. Each time they learn from the successes and failures to keep improving.
Software development has been improving by leaps and bounds since its origins. It is more than just new languages or paradigms that cause improvements. So how can we continuously improve in our daily lives?
Having a learning state of mind is the first step to continuous improvement. If you aren’t learning, how can you hope to improve yourself much less, the team, solutions, culture, etc. This should apply to both your soft and technical skills.
Technical skills are usually straightforward for software developers to improve. Learn more about the languages you use. Find new libraries/services/etc. that can improve your implementations. Learn how other languages work and where they may shine.
Soft skills can be harder to improve. It is easy to focus just on the tech, but improving soft skills will allow a greater focus to be put on the people involved. Improving your communication and understanding of everyone will allow even more solutions to make themselves apparent. The most important thing to keep in mind with soft skills is to be mindful of yourself. See how your actions, communication, and thoughts shape not only yourself but those around you.
Improving both soft and technical skills is a great way to always be introducing positive change with our continuous improvement ingredient.
Having a mantra of always introducing positive change immediately takes advantage of those newly learned patterns. Whether they are technical or soft skills applying positive change has a huge impact on happiness, productivity, teamwork, and craftsmanship. These in turn have a huge impact on the overall success of the team's solutions.
I always try to leave the code in a better place than when I got there. Even if the improvement is minor. But what is “better”? Could mean many different things to different people. Some think high or low line count is a good metric, or maybe code coverage, or bug count. As many ways as there are to solve problems with code, there are ways to measure success. So it is important to choose a metric that is meaningful to your team.
For me personally, I measure success by how little pain I cause myself and the overall team when looking at what I have implemented. I am constantly checking my solutions for readability of code. This includes making sure that it isn’t too clever. Clever code can sometimes be a good solution, but sometimes it makes it a nightmare to maintain or enhance. Yes, I believe that KISS (Keep It Simple, Silly) is the best metric for developing solutions.
Simpler doesn’t just mean code readability either. The more business requirements there are, the more code explodes. Apply the 80:20 rule to not only keep the feature set targeted, but in everything else we do as developers. Working with the business team to find a happy place where both business needs and simple implementations work in harmony. This requires a healthy relationship between those involved and an understanding that we are working together to build the best solutions possible.
While I don’t think a low line count is the only way to go, I do think it is something to strive for. The less I write the less there is to maintain. When diving into a new feature, check for existing patterns or code that can be refactored to increase readability and simplicity.
Removing redundant, old, and unused code is also a good way to reduce complexity and allow for faster movement. Not only that, deleting code is a very cathartic process. Seeing that pull request bar has more red than green… oh man!
Having these thoughts of continuous improvement at the forefront of your mind will naturally cause better and better solutions to be built.
While the overall goal should be to focus on the people involved with the solution, the best way to accomplish that is to have a thorough knowledge of the possible technology that will best solve that problem. Not only that but always striving to improve the solution will leave everything in a better place for future eyes to implement change.
In part three of the series we will look at validating the solutions the team is coming up with and why that validation is important.