In the final installment of my interview with Doug, he provides some advice for aspiring software developers as well as those just getting started. He also offers some tips for conducting safe and effective code reviews. To read previous segments of this interview:
- Part 1 – Introducing Doug Bradbury and One World Coders
- Part 2 – One World Coders services and pricing model
- Part 3 – Cultural intelligence
- Part 4 – Apprenticeship
Walsh: What advice, based on your experience bringing people along, would you give to someone who might want to become a software developer?
Bradbury: I believe anyone who wants to become a software developer can. It is just a set of skills you can practice and learn. That’s kind of true of anything; if you are willing to practice, you can get there. That’s just what it takes. I would advise you that it is not a fast way to start a career. It is a big body of knowledge, but it is all attainable. One of the best things you can do to accelerate your growth is to get feedback on what you are writing. Put it out there, ask people to look at it. Let people tear it apart. That’s how you will learn.
Walsh: Along those lines, you published a blog post recently about conducting safe code reviews, and this seems to fit with the idea of getting feedback on your code. How do you propose making code reviews safe and separating the professional critique from the personal affront that sometimes can happen?
Bradbury: That blog was really an extraction of what I teach people when they are mentoring about how to give feedback to developers. As the person receiving feedback, the best and only advice I can give comes from Don Miguel Ruiz. He wrote a book called The Four Agreements, and his suggestion is to take nothing personally. The feedback people give you is more about the person giving the feedback than it is about the person receiving the feedback. That’s easier said than done. The advice I more often give is to the people who are giving the feedback. I tell them to give the feedback, not as judgments – not saying that this thing is good, or this thing is bad – but as reactions. “I read this code, and this is how I reacted to it. Here is how I experienced your code.” Instead of saying, “This is confusing,” say “I am confused by this. Here is where you lost me.” The things that we think, the feedback we want to give, is from our perspective, so we should speak it from that perspective. That prevents the defensive reactions from happening when somebody is commenting on your code. You can develop the skills of not taking things personally and learning from every criticism that you get, but the person giving the feedback can do better than just leveling criticism.
To learn more about One World Coders…
- General information: https://www.oneworldcoders.com
- Videos of weekly katas and other meetups on YouTube: https://www.youtube.com/channel/UCirIapVcTclvbyX_xUK2zcQ
- Facebook: https://www.facebook.com/oneworldcoders
- Slack Workspace: https://www.oneworldcoders.com/blog/one-world-coders-community-10-launches-in-rwanda