Key takeaways
|
Software developers use katas to learn new skills in software development. The way katas are used today is great for learning new skills or to improve existing ones but it doesn’t address the intensity we face at work when there is a raging fire such as a deadline, release date, fixing a bug in huge legacy code, etc. This article covers the skills of good developers and highlights the importance of changing your training approach to improve your skills for high-intensity and challenging environments.
Skills of a good developer
Which skills are important for developers? Every developer has a different answer to this question but if you think it’s only a set of purely technical skills, you'll be disappointed. Good technical knowledge is great but not enough. Some developers focus more on technical skills, others will spotlight agile skills, and so on. It depends on your understanding of the purpose of your job as a software developer. Try answering these questions:
- Why am I a software developer?
- Why am I developing this product?
- Why am I learning this new language/framework?
- What are the values/impact of my product?
If you did not mention the end users and their needs in your answers, it means that you are missing something.
Four major skills
Having the final user in mind is the first skill of a good developer. Make sure you know the problems of your end users. Make sure to know their needs. Then develop the product that solves their problems and fills their needs. Software development is all about that.
The second skill concerns the quality of what you deliver. Delivering with zero defects is a skill. Obviously, it is hard to reach — but it’s not impossible. We do love that tweet from Ed Weissman. This skill should be consistent, which means being able to deliver a zero-defect feature under all circumstances. Obviously, that also means that you do not break existing functionalities.
The third skill is about simplicity and not fearing inherent and accidental complexity. This skill is about decomposition and abstraction: your ability to break down complex systems/problems into smaller ones, contrast those smaller parts to make them independent, and organise those smaller parts to make them understandable at the right level of abstraction. During these steps, you have to ignore the inessential details to keep your focus on the right abstraction. We recommend John Maeda’s book, The Laws of Simplicity, which is a real source of inspiration.
The fourth skill is about putting all the previous skills together and adding speed without compromising anything, especially quality. Having speed without the first three skills is not the purpose. You are looking not only for a fast impact but for high-quality and fast positive impact. This is the most important point in the approach: embracing quality and intensity at the same time.
Rest up
To recover, renew, and regenerate, your body needs rest. Developers often do not give this sufficient priority. A lot of us take pride in spending sleepless nights, even the more talented and experienced among us. Think about that when you read Emily Beers’s article about athletes and rest.
We think that we can replace “athletes” with “developers”. “Retrospective bias” is a term used in psychology to explain why people tend to remember the past differently than it actually played out, often by romanticizing it into something it wasn’t. It might explain why we forget the lack of productivity and other negative consequences the day after we spend a sleepless night. Keep in mind that your body needs some time off and that sometimes putting your feet up will help you improve. The same thing applies to sleep. Good sleep (at least seven hours per night) and good rest are not options when it comes to productivity and high-quality work.
Two values to strengthen your skills
Beside these skills, we want to stress two values: no blame but no mercy and being inclusive.
“No blame” means that you should stop looking for a guilty party every time you find a bug or a defect. With “no blame”, you should always have a “no mercy” counterpart to avoid a problem of laxation. Instead of blaming, teams should strive to understand the reasons behind a defect, what may be wrong with the team’s practices, and how to prevent that defect from happening again.
We learned the value of inclusion from the SoCraTes unconferences. During our first, we never felt like strangers. Everyone welcomed us with a smile, even those we’d never met before. We and other new attendees immediately felt like we were fully part of this community. It was a great experience.
Apply this value to new colleagues. Pay attention to integrating them as quickly as you can. Help them set up their workspace. Don’t hesitate to pair with them. The goal is that they never feel like a stranger from the very first day. This applies not only to the human aspect of onboarding but also to the technical and work points of view. It means that the team should set up an onboarding environment that allows new people to take part in discussions and decisions on their first day. The same value should apply to interactions with other stakeholders. Don’t forget local skills related to your project. Our company, for example, uses a homemade framework, and being good on our team implies mastery of this framework.
This kind of attitude is important and can have an impressive impact on your work. If you have the chance to be part of a highly motivated, high-morale team, there is a great chance that you’ll have fun with your colleagues as you come up with great ideas and do some of your best work.
Skills are not only technical
The scope of the skills defined above is wide. There is a lot to learn from agile methodologies, XP practices, software-craftsmanship communities, and many other influences not necessarily related to software development. For example, serious games like Ugg-Tect, Derdian Game or the excellent Keep Talking and Nobody explodes could be an interesting practice for your team.
The following sections focus only on the technical side of the training. More specifically, they will look at how katas are used and what you can do to make training more closely resemble real life.
Add intensity to your training
Katas are today the most widely technical exercise used by coaches/developers to teach/learn the basics of software development (clean code, TDD, etc.). Katas can be valuable for the basics but are rarely sufficient for facing challenging situations that may be urgent (meeting a deadline, a release date, etc.) or critical (fixing a bug in a huge legacy codebase without testing or covered only by legacy tests).
Unfortunately, the first reaction of most developers when facing intense challenges is to try to work faster — but adding speed without preparing for it will negatively affect the quality of the work. Some developers see their job as art and not performance. Actually, software development is both. When you add intensity to your training, you can adapt to the onset of a challenge and you will be able to deliver high-quality solutions in spite of them.
Let’s see how to achieve that.
There are three phases to learning a new skill:
- learn the basics,
- consistency, and
- intensity
You have to make sure that you finish each level before moving on to the next.
Refactoring as an example
Let's take the refactoring as an example and apply a training plan to it.
Learn the basics
At first, you should know what refactoring means. What are the code smells? How you can clean these smells using the refactoring catalogue?
Martin Fowler’s Refactoring: Improving the Design of Existing Code is a must read. Another interesting read is Uncle Bob’s article, “The Transformation Priority Premise”. You can also find some interesting articles in the software-craftsmanship community. Adrian Bolboaca offers some good articles about the basic rules of refactoring and the refactoring rule of three.
You have to master the refactoring catalog of your IDE and learn the shortcuts because it saves time, saves brain processing, and helps you to avoid bugs. The goal at this stage is not speed. The goal is to learn how to correctly refactor and which tools can help you to efficiently do it. At this level, you should be able to identify code smells, to clean them using the refactoring catalogue, and to know the capabilities of your IDE for doing so. For this training, you can use katas. The Coding Dojo Handbook by Emily Bach sums up many interesting katas like Gilded Rose, Yahtzee, Tennis Kata and Racing Car.
Remember, refactoring is a process for improving your code/architecture while maintaining application behaviour by doing small, “automatic” transformations. When you are in a refactoring session, always keep in mind the big picture.
Consistency
The second phase of learning is to take what you learned in the first phase and consistently apply it to a new kata or to your own project. You can, for example, try the Trip Service kata defined by Sandro Mancuso or the Trivia kata defined by J.B. Rainsberger or apply the mikado method. At this stage, you are familiar with all the refactoring features of your IDE. You feel confident when transforming crud code to clean code, and you can apply that to a new kata as well as to your project at work.
Intensity
The third phase is about adding intensity. Before starting this phase, you must feel comfortable with the exercise. You must be able to complete it with a high-quality result. You must have some sort of feeling of mastery. When you have reached this stage, you can start to work on improving your speed.
You may achieve intensity by refactoring complex code. Another way to add intensity is to improve the time you need to finish your katas. In this case, don’t hesitate to compare your work with other developers. BeFaster looks to be an interesting way to compare performance and learn what makes someone faster. Another tip is to watch popular developers in action. The Codurance YouTube channel contains many interesting screencasts that every developer should watch. Remember, there is no point in improving your speed if doing so introduces errors: always choose quality over speed.
Tools for practising software development
One of the key ways to improve your software development is to meet, share, and exchange with your peers. They are a great source of advice, ideas, and feedback. Of course, it’s up to you to ingest any new discoveries.
Local meetups and events
The Global Day of Coderetreat that takes place every October an annual rendezvous of developers all over the world. You can check the website to know more about this event and to see if there will be a meeting organised near you. If not, do not hesitate to organise one. It’s awesome! There is a lot of material available on the website to help you.
You can look for meetups in your city. Meetups are a great opportunity to meet other talented developers, to learn new stuff, and to have fun.
Organise sessions within your company
You can also organise a meeting of 60 or 90 minutes with your colleagues during your lunch break or after your workday. Katas are a great way to present interesting discussions in a safe atmosphere.
Finally, we strongly recommend that you organise mob-programming sessions with your team at least once per week. Don’t use katas for this. Your production code is perfect for sharing ideas and using it encourages cohesion among team members.
Individual training
Individual training starts with practising, and that’s what katas were made for. This article has already mentioned several sources. Remember, to acquire knowledge, you must repeat it until it becomes a habit (and even better an unconscious reflex). Do not hesitate to repeat a kata several times.
If you want to learn a new language, which you should try at least once a year, Exercicsm.io is a good start. It provides several exercises ordered by complexity, with the appropriate unit tests.
If you want to have fun when practising coding, you should try CodinGame. It adds intensity that approximates that of deadlines of real projects: the Clashes of Code game is a good example. You can also have fun by resolving puzzles, whose challenges come not from time pressure but more from the inherent complexity of the problem to solve. CodinGame also organises contests for which it keeps secret the problem to work on until the start. It’s a kind of competition with a leaderboard. To make the most of CodinGame, you have to write clean and efficient code.
Use metrics to improve your programming skills
Developers have a complex relationship with metrics. They already use them, especially when working on performance issues. In such a case, it’s recognised that working without some kind of measurement is pretty much like playing a lottery. You can win but only by chance.
On the other hand, there are plenty of measurements and KPIs that developers hate, like timesheets and Gantt charts. Developers see them as a tool used to police and control or as boastful. As a result, when you discuss the use of measurements with developers, there is always suspicion.
Metrics as a tool
Fundamentally, metrics should be a daily tool that helps guide your decisions. Developers are engineers, so it is normal to use a rigorous, scientific approach. If you don’t profoundly understand your starting point and your destination, you will not be able to act effectively and consistently. Metrics are really a good tool to help you to understand your situation.
An example of metric usage
To improve your IDE skill, for example, one approach is to maximize the use of keyboard shortcuts. You can follow a process:
- The first step is obviously to learn those shortcuts. But that’s not enough, because if you do not use them, your skill will not improve. To measure this skill, you have to track your evolution.
- So the second step is to set up a metric. For this example, it can be the ratio between the number of direct uses versus shortcut uses.
- Using this metric, you can define an objective and observe your progress.
With this approach, you will be able to notice, based on objective facts, that your IDE skill has really improved. You will feel more personal satisfaction from achieving goals than you would if you relied on a “feelings” approach. As a side note, if you use IntelliJ, its Key Promoter plugin and productivity guide are very handy for such experimentation.
Convince managers to give you time to improve
It’s not easy to convince managers to give you time. Nearly all managers already know to some extent that training is a good practice, but backlog pressure often leads them to short-term thinking reactions. Learning a new skill becomes the kind of task that managers constantly de-prioritise. Another aspect of the problem, is the corporate dilemma, which can be simply portrayed as a dialogue between a CFO and a CEO:
CFO: “What happens if we train them and they leave?”
CEO: “What happens if we don’t and they stay?”
How can we break this phenomenon? There is no generic solution. There are too many factors involved (manager, company philosophy, etc.), depending on the situation. So what should you do?
Share a common mindset
An initial part of the solution is to remind your manager that the product is the reflection of the team. The product is the direct outcome of the team and therefore the more skilled people you have, the better product you get. Training becomes a win-win situation. You can find convincing arguments from an Internet search for the key phrase “The team is the product”.
Build your case
As you seek your manager’s support, build your case by speaking manager language. Make it easier for your manager to understand the rightness of your request. Your manager will probably have to use your own arguments to defend your case to his or her own manager.
There is a handy generic tool that can help you to structure your request: the lean problem-solving process. It can be described in a four-step iterative process:
- Describe a problem — what is the problem?
- Bring to light the consequences of not handling the problem — why is it important?
- Find a cause hypothesis — what is the root cause?
- Confirm by experimenting with solutions — what is the solution?
In our context, you first have to step back and think about the skill: why it is important and what is the underlying problem for the business. You can organise your step-one problem statement by describing its impact on the client, on the team, and on you. If you have some metrics, it’s a real plus. Managers love facts.
Here is a sample request that follows the four steps outlined above: “We had X bugs raised by the client over the last Y weeks related to the database, so the team had to spend Z days to fix them. The cause is that our stored procedures do not support the actual and future growth of our client. We do not have enough knowledge to produce a robust stored procedure. I suggest that we invest time in training on this topic.”
With this tool in your hand, it should be easy to convince your manager.
Make the training worth it
When you do get time for training, it’s just the beginning. You will have to organise your sessions to make the most of them. The better result your manager sees, the more likely you will get time for your next session.
Conclusion
This article discusses how to embrace speed and quality in software development. Some developers see software development as an art and not a performance but we believe that software development is both. However, the issue of performance is rarely as discussed as the art. This has always been a taboo subject. The majority of developers hate talking about speed or even measurement or metrics. We are trying to break this taboo and share our thoughts about that. We hope that this article and our talks on these topics help to provide an efficient discussion about this controversial topic.
About the Authors
Houssam Fakih is a developer and software engineer at Arolla. He lectures at French and European conferences including AgileFrance (Paris), Soft-Shake (Geneva), NewCrafts (Paris), I.T.A.K.E (Bucarest), SwanseaCon (Swansea, Wales) and Agile Tour London (London). He organizes the French version of the SoCraTes conference series and he has participated in the other versions since 2015. He facilitated Vienna’s Global Day of Coderetreat in 2016 and has decided to celebrate this day in a different country every year. In his work, he tries to bring high-quality and positive value to final users, to his team, and to his company. He aims to deliver zero-defect clean code.
Boris Gonnot is the manager of the feature-development teams at BISAM. Prior to BISAM, Boris worked at Allianz GI where he held various positions: software architect, head of the Java development platform, and architecture and engineering services. He holds a master’s degree in computer science.