Practice, practice, practice

\\n\\nLike most programmers, I am passionate about software development; it’s natural for me to want to get better at it. So, often I look up how to do that online.\\n\\nBut it seemed that everywhere I looked, people were saying: “Practice, practice, practice.” I thought: “Ok, so what?” Then, I looked some more and stumbled on things like: “write more code!”, “Code Katas are the way!” or “a programmer should practice programming by programming.”\\n\\nEver asked somebody about career advice and all you got was “Follow your passion!” It felt the same to me.\\n\\n“Practice is the key to success”\\n\\nWe’ve heard such trite expressions so many times.\\n\\nSuch kinds of advice lead us to exactly one place: nowhere land.\\n\\nI don’t know about you, but when I’m going out on a trip, I don’t want to start the journey without knowing what direction to take.\\n\\n

Have you actually read before how  developers should practice?

\\n\\nIn my quest for answers on how we developers can perform deliberate practice, I’ve had to read many books, watch many videos, and take copious notes from blogs.\\n\\nNow, I want to save others the same frustration through which I went. I’ve gone through all these notes and books and compiled some of the best ideas into a list that hopefully you’ll love and apply to your work.\\n\\nBelow you’ll find a 7-step framework that we all can try. You’ll then be able to incorporate your own tactics in addition to those I suggest.\\n\\nHere’s an outline of the framework:\\n\\n

\\n
1. Set up your measurable goals: know where you’re going.

\\n

2. Break the goals down into discrete skills.

\\n

3. Set up your practice plan: the operating procedure for you and your peers.

\\n

4. Integrate the skill: understanding others’ code.

\\n

5. Incorporate feedback: staying on target.

\\n

6. Reflect on your results: avoiding stagnation.

\\n

7. Apply the law of the vital few: what’s your 80/20 like?

\\n

\\n\\n

1. Set up your measurable goals

\\n\\nNever start an endeavor before having clear goals, especially on large scale projects.\\n\\nGoals should be made clear in your head so that they help you avoid getting distracted by less important work along the way.\\n\\nTo then achieve it, you need to have a sense for what the destination will look like.\\n\\nExample of a bad goal: Understand system X thoroughly by the end of the year.\\n\\nA better goal could be: Understand the 3 most used features, A, B, and C of system X by the end of the coming fortnight.\\n\\nNote a couple of things about this rephrased goal:\\n\\n\\n

\\n
1. Sub-goals are clearly defined: ‘thoroughly’ or ‘the 3 most important features’ are too vague unless these 3 are listed.

\\n

2. They have a deadline that is not too distant. It should be a time frame that you can reasonably estimate.

\\n

\\n\\nYour next steps can include consulting the architecture diagrams, looking at the user interface or asking a colleague for a walkthrough of the application. The idea here is to get a high-level sense of what you can expect to do on the project.\\n\\nColleagues will be particularly useful for you here: treat them as your software development mentors. Mentors can help you find where it’s more important to focus your energy and how to organise your practice sessions.\\n\\nWhen you have identified your high-level goals, make sure you understand how they all relate to each other. When goals follow each other, they will give you a sense of progress as you complete each one, and an overall direction on the project as well.\\n\\nTip: When you commit to goals, use the principle of consistency by making your colleagues aware of them, thereby making you more likely to keep up with them.\\n\\nFor a few other ideas on how to make this idea work for you, I invite you to read this article that’s based on the Influence book by one of my favorite authors, Robert Cialdini.  It shows you how you can apply one of the most powerful psychological forces in your own life.\\n\\nRemember the saying: You can’t hit a target that you can’t see. Therefore, make sure you know what you want to achieve beforehand.\\n\\nFor each goal, ask yourself these questions:\\n\\n\\n

\\n
• Is your goal measurable? How will you know when you complete it?

\\n

• Does it have a definite deadline?

\\n

• Is it clear and focused?

\\n

• What high-level documentation can you use?

\\n

• Whose help will you need to achieve your learning and practice goals?

\\n

\\n\\n

2. Break the goals down into discrete skills

\\n\\nAfter you have defined definite and measurable goals, you’ll need to identify what skills you need to achieve them.\\n\\nSmall and well-defined skills are easier to achieve and give you the confidence you need to pursue your goals.\\n\\nThis is where you’ll identify the libraries, frameworks, and even modules of the project itself.\\n\\nFor example: If you’re using Maven, consult the pom files to see them. If you’re using a major IDE, it should have a way to visualize it, e.g. here is an example of how to do it in IntelliJ.\\n\\nAsk yourself:\\n\\n\\n

\\n
• Which parts of the libraries/frameworks used should I learn right now?

\\n

• How are the libraries most frequently used on the project?

\\n

\\n\\n

3. Set up your Practice Plan

\\n\\nJust like a well-managed software project is broken down into specific deliverables, so should your practice sessions.\\n\\nNext you’ll write a document to comprehensively list all the skills, in what order you need them, and the expected time  each will require to complete.\\n\\nA side-effect of writing this document is that, just like writing the learning tests (see the next step), it is ready to be used by the new developers in your project without needing to repeat the whole process each time.\\n\\nThis will become the operating procedure to which your newcomers will refer and improve upon.\\n\\nKind of questions to ask yourself when writing the Practice Plan:\\n\\n\\nHave you listed all the skills you need?\\n\\n\\n

\\n
• Are the skills small and achievable within the time estimates?

\\n

• Will the next person reading this document have everything he needs to get up and running as soon as possible?

\\n

\\n\\n

4. Integrate the skill\\n

\\n\\nNow, you’ll learn how to practice this skill in context. Practicing in context will allow you to make progress faster because you will be learning how to  actually use the skill on the project and not just practice without any clear direction.\\n\\nDon’t try to integrate code and learn it at the same time; that will be quite hard. Explore it first and then integrate it.\\n\\nOne approach that you can try is to write “learning tests.”\\n\\n\\nIf there is a library with which you’ll need to be familiar, follow these suggestions to familiarise yourself with it in the context of your project (of course, you’ll still need to consult the reference for the library).\\n\\nThese steps are applicable to third party code as well as the project’s own modules:\\n\\n\\n

\\n
1. Look at some scenarios in which it’s being used in the project.

\\n

2. Write some tests that use the library in such scenarios.

\\n

3. Verify your understanding of the new concepts by making variations to the concept that will validate your knowledge.

\\n

4. Then, and only then, you should integrate the code in new code that you write.

\\n

\\n\\nIncidentally, following these steps will force you to think of the long run. The next developer will be able to get started more easily on the project. Learning tests may even help you catch backward compatibility issues that can arise when you later migrate to newer library versions.\\n\\nI first came across this “learning tests” gem in the fantastic book Clean Code by Robert Martin. In it, Martin explains: \\n\\n

“In learning tests we call the third-party API, as we expect to use it in our application. We’re essentially doing controlled experiments that check out understanding of that API. The tests focus on what we want out of the API”.

\\n\\nThe salient point here is to understand that the more your practice resembles new code that you’re going to write, the more effective your learning will be.\\n\\nSo, when integrating the skill, ask yourself:\\n\\n\\n

\\n
• Do your practice sessions resemble the kind of work that is expected of you when you’re actually going to use it?

\\n

• Do you repeat the maneuvers at which you’re the weakest?

\\n

\\n\\n

5. Incorporate feedback\\n

\\n\\nFeedback is the critical component to your practice sessions. You use it as a guide to help you know whether you’re on target or not.\\n\\nYou can receive feedback from several sources:\\n\\n

\\n
• People, e.g. your team mates/ mailing lists.

\\n

• Tests, e.g. via tests in your development environment, your continuous integration server, etc.

\\n

\\n\\nThe feedback loop is the path between doing something and receiving the results. To accelerate your progress, it makes sense to strive to shorten the feedback loop.\\n\\nThis is why automated test practices like Test-Driven Development (TDD) are effective; you can get feedback quickly and easily, whether in your IDE or your reports from your continuous integration server.\\n\\nHere are some other ways you can shorten the feedback loop:\\n\\n\\n

\\n
• Configure your IDE to run tests on save/compile. InfiniTest is a plugin for both Intellij and Eclipse that allows you to do just that.

\\n

• If you are writing front-end web apps, use a tool like LiveReload which will refresh your browser page automatically.

\\n

• Test or even run your code in REPLs as is commonly done in Lisp, Scala, and Python environments.

\\n

\\n\\nIf you’re a senior developer, consider tracking and rating your developers on how they successfully take action on feedback. Also, don’t forget that making feedback public can help your team build trust and encourage members to push their limits.\\n\\nWhatever the situation, what you need to keep in mind is that  there should be as little friction as possible between trying out an idea and seeing the results of it.\\n\\nAsk yourself:\\n\\n\\n

\\n
• Do you regularly receive and give feedback to your team members?

\\n

• Do you consciously set aside time to practice?

\\n

• Have you set up your environment so that feedback loops are kept as short as possible?

\\n

• Are you in the habit of writing fast automated tests?

\\n

\\n\\n

6. Reflect on your results\\n

\\n\\nThis step is primordial. Nothing kills progress as much as working on auto-pilot and stagnating on a plateau.\\n\\nAfter seeing your results, you need to reflect on them by asking questions like:\\n\\n\\n

\\n
• Why didn’t it work on your previous attempts? Why does it work now when you tried this particular way?

\\n

• How will you apply the lessons learned in this practice session in the future? Can you write these into a ‘Lessons learned’ document and share it with the team?

\\n

• Did you notice anything in the process that you can improve? Is there anything that you can add to the Practice Plan?

\\n

\\n\\nAlso, these tidbits from The Pragmatic Programmer can inspire you to find your own ideas:\\n\\n\\n

\\n
• Don’t code blindfolded. If you don’t understand the technology or the application on which you’re working, focus on familiarising yourself with the basics first.

\\n

• Document your assumptions. The Design by Contract allows you to do just that; so, consider giving it a try.

\\n

• Don’t be a slave to history; i.e. don’t let existing code dictate future code. If there’s code that needs to be yanked or refactored, be bold about it and make the changes required.

\\n

\\n\\nLike Clean Code, I highly recommend that you read The Pragmatic Programmer  too. Mr. Sonmez also agrees that this book is a must-read. Read his review about it here.\\n\\n

7. Apply the law of ‘the vital few’\\n

\\n\\nThis law, more commonly known as the Pareto Principle, essentially means that there is a small subset of all activities that yield the lion’s share of output.\\n\\nThis idea can be especially useful when you’re optimizing for performance (e.g by identifying the methods that are taking up the most resources in your application), but it’s also useful for your practice plan.\\n\\n\\nDo this in three steps:\\n\\n\\n

\\n
1. Identify the things that create the most value. When you’re just getting started on the project, these should be the things that you have identified in your Practice Plan. As you get more and more experienced, they could be a lot of other things. Identify some pain points that your team is facing by asking questions like:\\n
   \\n
   • Is there some area that is  known to be regression-prone or hard to maintain?

   \\n

   • Can I simplify the architecture in the most frequently used areas?

   \\n

   • Project goals change; so identify the new top priorities and follow the steps in this post again.

   \\n

   \\n

\\n

2. Practice them repeatedly. The key here is to repeat this as often as possible until you feel comfortable with it.

\\n

3. After every few iterations, identify and remove the things that create the least value, add the things that bring the biggest returns, and repeat.

\\n

\\n\\nAsk yourself:\\n\\n\\n

\\n
• Where does your team need help the most right now?

\\n

• In which areas are issues most commonly reported?

\\n

• What parts of the source code are known to cause maintainability issues?

\\n

\\n\\n

Your next steps

\\n\\nI’ve summarized the seven steps in a flow chart for you:\\n\\n

\\n\\nYou’ll notice from the key above that there is a central theme: being mindful about the craft. Don’t forget there is a ‘deliberate’ in ‘deliberate practice.’ Observe and extract the principles every step along the way.\\n\\n\\nIn the same way as traveling without direction will get you to nowhere land, practicing without intentionality will cause you to perform without it.\\n\\nTake action. Seeing yourself improve will inspire you to believe in deliberate practice even more. So, don’t leave practice to chance, practice and work deliberately.\\n\\n

Information alone won’t help\\n

\\n\\nIf you already knew some of these ideas, don’t go out looking for the shiny new tactic.\\n\\nYou don’t have to follow all the advice on deliberate practice out there (in fact, you shouldn’t try to). Just follow a simple framework and you’ll be fine.\\n\\nAs you get more at ease with practicing deliberately, you’ll have the opportunity to make changes to it and make it work best for you.\\n\\n

Taking this even further\\n

\\n\\nTurn your practice session from just an ‘ok’ one to a great one by adopting systems. Earlier I gave an example of one: your Practice Plan. It can serve as your blueprint for getting from a beginner to a master.\\n\\nThink of what parts of your work can be systemized. \\n\\n

Other recommended resources\\n

\\n\\n

\\n
• Some developers like to practice with “katas,” whereby they work on problems that exercise skills in specific areas. One site that has katas is codekata.com.

\\n

• If you would like to hear the “devil’s advocate” view, John has some mixed feelings about it. Watch what he has to say on the subject.

\\n

• Mastery by Robert Greene is one of my favourite books that examines the subject in depth.

\\n

• The Passionate Programmer by Chad Fowler. The title states clearly to whom it’s targeted 🙂 Highly recommended.

\\n

• Make It Stick by Peter Brown. Research-backed book from which I learned a lot about learning.

\\n

\\n\\nTo give other readers some ideas on how to take action, do share examples in the comments on how you’ll apply this to your work. I can’t wait to see what you think of!\\n\\nYou can also check out my course “10 Steps to Learn Anything Quickly” for methods to optimize your learning.