- Who Owns Your Career?
- Keeping Ourselves Up to Date
- Know Who to Follow
- Practice, Practice, Practice
- Socialize
- Deliberate Discovery
- Work-Life Balance
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Practice, Practice, Practice
How it is done is as important as getting it done. If we want to be good at writing quality code, we need to practice how to write quality code. There is no other way. When practicing, the focus should be on the techniques we are using and not in solving the problem. Solving problems is what we are paid for and what we do at work. However, when practicing, we should focus on how we are solving the problem. For example, imagine you are trying to learn or get better at Test-Driven Development. This is a hard discipline to master. It is counterintuitive at first, and that is why we need to practice.
Do you remember when you were learning how to drive? I remember that every time I was driving up a hill I was praying for the traffic light not to go red. I used to think to myself, “Damn, I’ll need to stop, put it in first gear, release the clutch slowly, and be careful that the car does not stall or roll backward.” I also remember the first time I had some friends in the car and they were asking me, “Can you switch the radio on?” and I, nervously glancing between all the mirrors, firmly gripping the steering wheel, would tell them “no.” That happened because when I was learning how to drive, I was worried about the car. I was worried about the gear shifting. I was worried about the mirrors, other cars, driving straight and staying in the lane, not driving into the other lane when turning, and so on. I could not divert my attention to switch the radio on. Now, after a few years, imagine how you drive. We do not even remember we are in a car. We do not think about the mechanics of driving a car anymore. We just focus on where we are going, what we are going to do when we arrive there; we listen to music, sing along, have conversations while driving. Driving a car became second nature and the car is now almost an extension of our own bodies.
Technical practices and new technologies are the same thing. The more we practice, the more comfortable we become, to the point where we don’t think about them anymore. We just focus on what we want to do with them.
When practicing, we need to focus on writing the best code we could possibly write. If it takes us minutes or even a few hours, to write a single test but it is the best test we could have written, that is OK. We should not worry if we take a long time to name a variable, method, or class. As long as we tried our best to find the most appropriate name for it, we should feel great. We are practicing and when we do it, we should strive for perfect practice. With this approach, when facing the demands of a real software project, we can concentrate on finding a good solution to the problem and not on how to write tests or which commands to use.
Katas
Katas are simple coding exercises. They have a simple problem domain that can be understood in a few minutes and are complicated enough not to be solved too quickly. They normally take from a few minutes to a few hours to be solved and are a perfect way to try new techniques and approaches. An example would be a kata where we need to calculate the score of a bowling game or implement tic-tac-toe. We can use these katas to practice things we think we are not very good at, like Test-Driven Development, another language, or a framework.
Katas have been criticized by certain people in the Agile community, though. Some people say that it is plain stupid to do the same thing over and over again. Well, to a certain extent there is some degree of truth to it. Usually this is said because the term comes from martial arts and that is how it is done in karate, for example. We do the same movements over and over again. That was probably the original intent when we started using the term kata for a coding exercise. However, solving katas with our current toolkit (the techniques and tools that we are comfortable with) does not make a lot of sense.
When doing katas, the idea is that we stretch ourselves, using practices, techniques, and technologies that we are not very comfortable with, with the intent of getting better at them. After practicing these things quite a few times, you may feel ready or at least fairly comfortable with doing that in a professional environment. Think about musicians who practice for hours, days, and months before their live performances. That is exactly what we are trying to achieve here.
Katas can be very beneficial when the same kata is done over and over again but using a completely different approach or technique each time. That allows us to experiment and compare. The correct word to define this practice, according to martial arts, is keiko. However, as developers all over the world have already adopted the word kata, we should keep using it instead of introducing another term.
We can find a good source of coding katas at codingkata.org, codekata.pragprog.com, and kata.softwarecraftsmanship.org.
Pet Projects
Pet projects are for me, by far, the best way to learn and practice. A pet project is a real project but without pressure. There are no deadlines, they do not need to make money, you control the requirements, and, most important, you use the technologies and methodologies you want, whenever you want, wherever you want. You are the boss. In real projects, a professional software developer would first understand the problem domain, then make technical decisions and write code. We would speak to stakeholders, product owners, users, business, marketing, and whoever else is involved and could contribute to the business idea. These conversations, in a healthy Agile environment, should happen frequently throughout the project. According to what the customer wants to achieve and the scope of the project, we would then choose the most suitable technologies to develop the project. Pet projects are exactly the opposite. First we decide what we want to learn—practices, disciplines, methodologies, and technologies—and then we find a problem to solve. It is much easier to understand why and how we can or cannot use certain technologies if we have a pet project to try them out. Pet projects allow us to play, experiment, discover, and learn in a very safe environment, giving us the experience we need to apply what we have learned to real projects.
Another important thing about pet projects is that we can experience several aspects of a real project. For example, we need to come up with an idea. Once we have an idea, we need to start refining the features and preparing a backlog. Preparing a backlog means thinking about priorities, making rough estimations, writing stories, and splitting tasks. We also need to think about tests, how we are going to deploy the application, version control, continuous integration, usability, the user interface, infrastructure code, design, and databases. As soon as we start using the application ourselves, we start changing our minds about the features (business) and also the technology choices. And that is exactly what happens in a real project. We do not need to have all that in place, but we can if we want to. We can use pet projects to learn any aspect of a real project. We can even try to write a business plan for it if we want to learn something about that. Remember, we are the bosses and we do whatever we want, as long as we are learning something. That’s the whole point.
Above all, pet projects are meant to be fun. A common problem that developers have with pet projects is finding a good idea. The good news is that you do not need one. You are not starting a new business. I always advise developers to choose a subject that they are very passionate about. For example, if you like traveling, try to create a website about travel. If you like running, create an application that can capture your progress, display graphics, and so forth. If you feel you should be more organized with your own tasks, create a mobile app where you can track what you need to do. It does not matter if there are thousands of other applications that do the same. There are always different things you would like them to do. The advantage of choosing a topic you are passionate about is that you will never run out of ideas for features or improvements. Besides that, you will always want to work on it since you usually will want to use it as well. All these things will help you to be quite close to a real project, and practicing them will have an enormous impact on your professional career.
A common question is if we should transform our pet projects into a real business. The answer is, “It depends.” I normally would say no to that since if you want to have a business, writing code and learning new technologies should not be your number one priority. I would recommend that you find some good material and get yourself familiar with Lean startup concepts before writing a single line of code. The transition from a pet project to a real business can be extremely painful and full of disappointments. Believe me, I’ve tried it myself. Many of us get very attached to our own applications and code base, which can blind us to what the market really wants. If we feel we should transform our little Frankenstein pet project into a business, focus on the business first and be ready to throw whatever percentage of what you have written away if that is what the business demands. Detach yourself from the code, clean it up, and leave just the bare minimum to satisfy the business needs.
Open Source
Contributing to open source projects is also a great way to practice. There are thousands of them out there. Find a project that is related to what you want to learn or know more about, and download the source code. Start running and reading the tests, if any exist. Inspect, debug, and play with the code. If you want to contribute, start small: add some documentation, write some tests, check the list of bugs to be fixed or features to be implemented, pick a simple task, and give it a try. You can also propose and implement a new small feature to start with.
Open source projects tend to be very different from pet projects because they are usually, with few exceptions, very specific in scope. For example, it may be an object-relational mapper (ORM) framework, a library to make web service calls, transaction management, a social network integrator, and so on. Although all these things are extremely important, necessary, and useful, open source projects tend to be just one of the libraries your professional applications will use, so do not forget to look at the whole picture.
Another great thing about open source projects is to see great developers in action. Looking at how they code and solve problems can be a great way to learn how to code well. Besides all that, it is also a great way to raise your public profile.
Pair Programming
Pair programming is more a social activity than a technical practice. It enhances the team spirit and brings developers together. Many developers are afraid to try it or think they will feel uncomfortable when pairing with others. Many years ago, I used to think like that but I realized that, in reality, I was afraid to expose my own limitations. If that is how you feel, the best advice is to get over it. There is a limit to what we can learn on our own. Of course we can learn whatever we want because we are all very smart people, but the problem is the amount of time that it can take. In addition, we will always have a naive and biased opinion when we are doing things on our own.
When pair programming, we can learn how to use a new language or parts of the application to which we had no previous exposure, a technical practice like Test-Driven Development, a few keyboard shortcuts, or even a completely new way to solve problems. Pairing can lead to very interesting discussions. It can help us to validate our own ideas or have them challenged, forcing us to rethink why we do things the way we do. It also can be a very humbling experience. Usually, we think of ourselves as very good developers, and we like to think that all the other developers are bad. Other developers write crap code, not us. When pairing, we get immediate feedback on our code and ideas. Our pair validates whatever we type immediately. Whenever our pair does not understand what we are doing, or does not agree with a variable name, the use of an application programming interface (API), or a design decision, we have an opportunity to step back and reevaluate the decision. Instead of thinking that the other person is stupid (which is rarely the case), we should think that we are probably not as good as we think we are. A good developer is a developer who can write code that any other developer can understand. When our pairs don’t agree or don’t understand what we are doing, we should take this as an opportunity to have a good discussion. Use it to learn something new and open your mind to different approaches. If someone is questioning what we’ve just done, maybe it is because it’s not good enough and there is a better way of doing it. We should take opportunities like that to share what we know, making everyone around us better. When teaching, we are forced to structure our thoughts, making us really understand our quite often half-baked ideas so we can make someone else understand them.
Pairing with someone from our team or a friend is great, but pairing with someone that we barely know can be even better. Usually team members and friends, after some time working and pairing together, develop a common understanding and style of coding. When pairing with people we have never paired with before, we end up potentially exposing ourselves to very different ways to solve and think about problems. The best way to find different pairing partners is attending meetings organized by our local user groups or technical communities. There are also an increasing number of developers willing to set up remote pair-programming sessions in whatever we want to work with. There are plenty of tools out there that can make a remote pairing session very smooth.
We need to keep our minds open to new ideas when pairing. Sometimes we learn, sometimes we teach, and sometimes we do both.