Do you want to level up your programming game? How do programming professionals manage to keep up with the fast pace of the industry?
The tech industry moves a fast space and so should you. If you aren’t continually improving your existing skills and learning new ones, you’ll soon lose touch with the cutting edge, be unprepared for change, and narrow your resume.
Keep reading for expert tips on how to improve your coding skills, according to programming veteran and author of The Clean Coder Robert C. Martin.
Programming and Professional Development
The hours you put into your day job rarely contribute to your professional development because at work, you often perform tasks and skills you already know how to do. Therefore, to be a professional, you should spend 20 hours per week of personal time on improving your programming skills and learning new ones.
- (Shortform example: If you’re a front-end web developer by day, you won’t have any opportunity to practice working the back end, so you’ll need to learn those skills on your own time.)
Sometimes, your employer will contribute to your development, but you should consider this a favor, not something you’re entitled to.
- For example, your employer might provide you with a book or send you to a training conference.
Similarly, sometimes you need to learn something that would also benefit your employer. In this case, it’s reasonable to dedicate part or all of your 20 hours to it.
- (Shortform example: If you need to learn a new programming language for a project your employer assigned you to, knowing this language will open new career avenues for you, so it’s worth learning in your spare time.)
Putting in these extra hours won’t cause burnout—if you’re a software developer, you’re probably passionate about coding, so 20 hours of practice will feel like doing a fun hobby. (If you don’t want to put in this time, don’t call yourself a professional.)
Improving Existing Skills
A large part of improving your existing skills involves practicing them so you can perform them quickly and instinctively. The goal is to get the unconscious part of your mind to recognize a problem and your body to instinctively react to it (for example, by hitting a particular combination of keys). Then, the rest of your mind is free to focus on strategy and problem-solving.
Speed is particularly important these days. Decades ago, programmers didn’t need to be fast with their keystrokes or mouse movements because computers were the limiting factor—they took a long time to compile (transform human-readable code into machine-readable code) and debug. Today, computers are fast, and programmers are the holdup.
In The Clean Coder, Robert C. Martin gives advice on how to improve your coding skills via two practicing venues: 1) the “coding dojo, and 2) open source.
Venue #1: The “Coding Dojo”
The “coding dojo” is a collection of practice exercises that are inspired by martial arts (in martial arts, a dojo is a training space). Here are some of the exercises:
Exercise #1: Kata. In martial arts, a kata is a choreographed sequence of moves that would be one person’s side of a fight. The goal is to make the movements instinctive so that if you do get into a fight, your body does the sequence automatically.
Programming katas are similar—they’re choreographed sequences of keystrokes and mouse movements that solve a particular coding problem. The goal isn’t to practice solving the problem (for most katas, you’ll already know the solution). Instead, it’s to practice the physical movements required for the solution and to train your mind to trigger the appropriate muscle memory when it identifies a specific problem.
- (Shortform example: For example, a kata might be to write a function that prints out the numbers 1-100 and replaces any numbers divisible by three with the word “fizz,” any numbers divisible by five with the words “buzz,” and any numbers divisible by both three and five with the word “fizzbuzz.”)
Katas are good for learning:
- Navigation idioms and hot keys
- Problem and solution pairs
- Test-driven development (we’ll look at this in Chapter 4)
You should do one kata in the morning and one in the evening, and each should take around 10 minutes to complete. You should vary which ones you practice to keep them all sharp and you can find many katas at Code Kata. When you get really comfortable, try setting a kata to music.
Exercise #2: Wasa. In jujitsu, wasa is a two-person drill in which one partner acts as the attacker and the other as the defender. Each person performs choreographed movements, and then they switch parts.
The programming version is ping-pong—two programmers practice together. One programmer writes a test, and the other writes code that will pass it. Then, they switch jobs.
This can be done with a kata or a new programming problem. If using a kata, the partners can critique each other’s memorization and execution of the physical movements. If it’s a new problem, the test writer can control the difficulty level.
- For example, the test writer can write into the test that it needs to be completed within a time limit. The code writer will have to come up with a solution that doesn’t take the computer too long to execute.
Exercise #3: Randori. In jujitsu, randori is unchoreographed combat practice.
The coding version is more like group wasa. The first person writes a test. The next person writes code that will pass the test and writes a new test. And so on. This will help you learn about other people’s problem-solving methods.
Venue #2: Open Source
Open-source projects provide a great opportunity for practice because they have real stakes. The project has a real-world application and someone else cares about it.
Learning New Skills
Once you’ve learned to improve your existing skills, it’s time to learn new ones. The best two ways to learn, in order of effectiveness, are:
1. Teaching. Teaching forces you to translate your knowledge into something you can communicate (like words), which in turn forces you to internalize the information. (For more on teaching, see Chapter 6.)
2. Collaborating. Collaborating means programming and practicing with another developer. You’ll learn from her and she’ll help you notice your mistakes. (For more on collaborating, also see Chapter 6.)
You can also learn by reading, attending conferences, and interviewing people.
What to Learn
Now that you know how to learn, what topics should you tackle? You should learn:
1. Industry history. You should learn all the techniques, ideas, jargon, tools, and niches of the last 50 years (almost all of which are still relevant). At a minimum, you should be familiar with:
- Methods, such as Waterfall
- Design patterns, such as GOF and POSA
- Design principles, such as SOLID
- Disciplines, such as pair programming (when two people work together on the same computer)
- Artifacts, such as flow charts and Petri Nets
2. New developments. Keep on top of the cutting edge of the industry. Learn new programming languages.
3. Your employer or customer’s business and field. When you’re programming a tool for a business in a particular field, you should know about the field yourself. (Shortform example: If you’re building a system for a law firm, then you need to learn something about law.) That way, if the business, unaware of the nitty-gritty of technology, requests a specification that doesn’t make sense or will be ineffective, you can advise. Think of the business’s problems as your problems—your goal is to come up with whatever solution will actually help, not just to follow instructions.
4. Humility. Programming comes with some inherent arrogance—when you create something, you’re playing god. You should take pride in your work and be confident, but also know that you’ll inevitably make mistakes because everyone does. If you fail, accept the consequences and laugh at yourself. Never attack other people for making mistakes.
5. Error sense. Error sense is becoming aware of when you make a mistake. The faster you can notice your errors, the faster you can learn from them.
- For example, when Martin was learning to type blind (without looking at the keyboard), he started by typing up programs onto cards. Once he finished each card, he’d look at it for mistakes and if he found one, throw it out. After a few hours of practice, he could feel when he hit the wrong key, immediately throw out the card, and start fresh.
Professional Programmer’s Toolkit
So far, we’ve discussed some general tips on how to improve your coding skills. Next, we’ll explore the programming tools recommended by Robert C. Martin in The Clean Coder.
Source Code Control/Version Control Tools
There are two main types of source control tools, open source and “enterprise.” Open source tools are usually better than “enterprise” ones because open source tools are built by developers (who know what features other developers need). Enterprise tools, on the other hand, are usually aimed to appeal to business people, and often they have extraneous features but lack the features developers require, especially speed.
Martin recommends the following open-source tools:
- Subversion if you don’t need to branch
- git if you do need to branch. git allows developers to keep a local copy of the entire project and then merge copies later.
If your company has an enterprise system, you can still use an open-source system—use the open-source system during iterations, and check the source code into the enterprise system at the end of iterations.
Integrated Development Editors (IDEs)
IDEs all have their pluses and minuses:
- vi is simple, fast, flexible, and easy to use.
- TextMate is intuitive and easy to use. It’s slower than vi and less powerful than the editors below. Martin usually uses it for C++.
- Emacs is powerful and features an internal lisp model. Martin considers it the best general-purpose code editor.
- IntelliJ and Eclipse are powerful and have a good selection of features. They’re both better than Emacs for editing Java. The downsides: They’re hard to learn, they take a lot of computing power to run, and setting up a project is a lengthy process.
Issue Tracking Tools
Use issue tracking systems to keep track of both bugs and to-dos including new tasks. If your team is between five and 12 developers, you should have tens to hundreds of tasks and bugs, so you shouldn’t need anything particularly powerful. (If you have thousands of tasks or bugs, you don’t need a more powerful tracker, you need to go back and fix whatever got you into this situation.)
Martin recommends starting with a manual system first. For example, divide a bulletin board into labeled sections (for example, “not yet started,” “in progress,” “finished”) and write tasks on cards. Pin the cards in the relevant section and move them as the task progresses. This will help you figure out what kind of digital tool will best meet your needs.
Here are some of the options once you’re ready to move to a digital tool:
- Pivot Tracker is simple, allows for fast communication, and works with the iterative/Agile workflows.
- Lighthouse is quick to learn and easy to use, but not as powerful as Pivot Tracker.
- Wikis have a flexible structure, are easy to use, and are good for internal projects.
Unified Modeling Language (UML)/Model Driven Architecture (MDA) Tools
UML and MDA are tools that theoretically allow developers to build diagrams that an engine will translate into code, rather than writing the code directly. These tools don’t do this job effectively because the goal is to abstract away details, but removing detail is unhelpful for two reasons:
- Sometimes programmers need access to the details. For example, the two characters \n and \r both break a line of text, and over the years, one or the other (or both together in either order) were conventions. As a result, having the “wrong” one in a program can throw errors. UML isn’t detailed enough to solve this kind of problem.
- Diagrams have their own details such as syntax and rules.
———End of Preview———
Like what you just read? Read the rest of the world's best book summary and analysis of Robert C. Martin's "The Clean Coder" at Shortform .
Here's what you'll find in our full The Clean Coder summary :
- Why many don't consider developers to be "professionals"
- Why continued professional development is so important
- How you can develop the six qualities and skills of a professional coder