Look at any sportsman or woman, any expert in their field and they have something in common, they practice, they practice a lot and they are always trying to get better at what they do.
Continuous improvement should be a huge part of what we do and we mustn’t get overlooked as an important state for us to be in. Hey that’s why we do retrospectives at the ends of our sprints, we recognize that there isn’t a perfect sprint and there is always room for improvement. This comes from Toyota who take a kaizen approach to improvements. Making small changes regularly and constantly adapting their processes.
Just as Toyota reflected that no process is perfect and it can always be improved so do other industries and individuals. You can’t imagine Usain Bolt ever saying “That’s is I’m the fastest man in the world, I don’t need to train anymore, there aren’t any areas I can improve on”. How about Andy Murray thinking “Well I’ve won Wimbledon, I must be perfect, no need to improve or make changes, becoming number 1 will be easy now”. What about Arnold Schwarzenegger? After winning his first few Mr Olympias, oh he kept training, harder and smarter. Also at the same time working on his real estate business and acting lessons!
Ok you get the idea, just because we finish work at 5pm and put in a hard days work doesn’t mean we should just stop there. Just because you’ve been a developer for a number of years doesn’t mean you should sit back. Think you know everything about Agile? Believe me there are no perfect teams with perfect processes, just people trying to improve on what they have done before.
So here is list of workouts you can do as a software developers wanting to improve themselves and become better a programmer. Try doing some of these things a few times per week if you can and see the improvements to your code, how you think and your general skill levels.
1: Perform the FizzBuzz code kata (for info take a look here: FizzBuzz Kata) Do the kata anyway you like with your language of choice. Pick a language or IDE you have not used before for an extra challenge.
2: Search for a project on github in your language of choice. Fork the code, clone the repository and see how they have developed it. Goto the unit tests first of all and see how the code works. This is a great way to see patterns that other people use in a familiar language.
3: SOLID principles. Familiarise yourself with these principles again. Watch some youtube videos about them, find some blogs and read up. If you have Pluralsight or some other training sources then use them to learn about SOLID. I can recommend the following video on Pluralsight Pluralsight SOLID principles course
4: Learn about FP (functional programming). Even if you’re not using a functional language there is a lot to learn from functional programming and you can apply some principles to your current language. Have a go at Haskell or F#. Watch some YouTube on this subject.
5: Perform the FizzBuzz code kata again. This time you must perform the kata using TDD. Strict TDD that is, no writing tests after the code. Drive out the design with your tests. As a suggestion time how long it takes to do this with and without TDD. I think you’ll be surprised at the results.
6: Today lets answer some questions on stackoverflow.com. Language of choice or other if you can answer another topic. Its a good community to be active in and you can learn a lot from here. Ensure you answer with good explanations and code examples where appropriate.
7: Clean code. Take some code you’ve been working on or an area of a system you’re not complete happy with. Come up with 5 ideas on how to clean up the code. Think back to the SOLID principles? Is test coverage good enough? Is it readable? Could it break in anyway that would cause unhandled exceptions? Are there loads of comments?
8: Object calisthenics day. Take a look at this Object Calisthenics. Apply these rules and write some code. How about applying these rules with a code kata? I can assure you that once you’ve done this exercise a few times you will write far better code. Smaller functions, no primitive obsessions ect.
9: Concentrate on the D in SOLID. You can take a look at some DI containers or perhaps familiarise yourself with the stairway pattern. Learn how to write loosely coupled code as this will help you be more agile and make changes to your systems.
10: Investigate unit test frameworks. If there is one you always use, try another. See if there are any plugins to your unit test frameworks which could improve them. There are lot of frameworks out there, some that add some syntactic sugar to your tests and make them more readable. See if there are ways to make your tests cleaner with test cases, better helper functions etc.