Issue 4 - Growing "Soft" Skills and Empowering Learners

Happy April, friends. I hope it's been good to you all. The new job is taking up a lot of time and mental energy, and I've been dealing with some personal family things this month, but I'm excited to bring this month's newsletter to your inbox.

This month features two pieces. The first focuses on how people skills are critical to your success as a software developer in today's world. The second explores how you can shift from an instructor-centered approach to a learner-centered one when creating content.

Software is 20% code and 80% people

The days of the lone coder are all but over. Modern software development is now a team sport in startups and large organizations. You'll find that collaboration across teams is necessary to get anything done. This means that you'll spend a lot of your time interfacing with people. And since the workforce is more distributed, you'll do a lot more communicating than before, often in public spaces.

Now before I get too far along here, I want to emphasize that the 20% of code is still a crucial part of being successful. If you don't have this part figured out, you won't do very well as a software developer, and I don't want to downplay that. You can't be an effective software developer if you don't have those skills.

I also want to state that I don't like the term "soft skills" because I think they're just as challenging for people to become proficient in as other skills, and they require practice and feedback just like software development does.

Here are a few situations where a software developer has to deal with people:

• Providing feedback on a code review

• Participating in discussions around architecture.

• Advocating for a new process, library, or framework.

• Demonstrating your work at team or company all-hands meetings.

• Discussing promotions.

• Interviewing.

• Networking with other developers at conferences or online communities.

There are more examples, but I think you get the picture here. Handling some of these situations poorly can create challenging problems for you. I've lost count of the number of times a manager has said, "This person's a great coder, but they're difficult to deal with. They'll need to work on that to advance/get promoted/keep their job." This industry is surprisingly small; your reputation follows you around from place to place.

These skills become even more critical the further you get in your career. The more senior you get, the more time you spend with others making decisions around code and processes. How will you give that effective feedback? How will you share your ideas and promote your strategies? How will you make your points and state your case when you disagree with a peer or a leader without damaging your reputation within the organization?

The most effective software developers learn to do these things well. Note that I say they learn to do these things. While some people have a natural ability to communicate and collaborate, others have to spend time developing these skills. As I mentioned, providing empathetic feedback, speaking in front of people, writing proposals, advocating for yourself, and marketing your ideas all take deliberate practice. They're a skill that you invest in.

Here are a few resources I found helpful. Even if you feel pretty confident in these areas, one of these books might help you hone your skills.

• You're not going to get along with everyone you work with. But you have to be able to resolve differences and communicate effectively. How will you react when that person pushes your buttons? The book Crucial Conversations can help with this.

• Documentation is everyone's responsibility on a team, and that includes everything from user documentation to onboarding guides for your new team members or pages for your internal wiki. Level up your writing skills with On Writing Well.

• You may need to sell an idea to your team or your boss. I recommend the classic book Influence.

Finally, I recommend reading Emotional Intelligence: Why It Can Matter More than IQ to understand how self-awareness, self-discipline, and empathy can be crucial to your success.

Turn "What I did" into "What You Can Do" to make a great tutorial

If you're looking into doing more content creation, one place you can look for inspiration is at the problems you solve every day. A common piece of advice I see people share is "Blog about the problems you're solving or the things you're learning." It's good advice, and if you do this consistently, you'll have a lot of content in a short amount of time that will help build your presence online.

But if you really want to make an impact, shift from "What I did" to "What you can do."

In teaching, there's a concept of "instructor-centered" teaching and "learner-centered" teaching. With instructor-centered teaching, the focus is on what the instructor knows and how they impart that knowledge. It's the "I tell, and you learn" model. The instructor is the holder of the knowledge.

In learner-centered teaching, the learner is involved in the process. They're given direction, but they do the work. The instructor is more of a facilitator. It's about empowering the learner and helping them learn through discovery and application.

The facilitator I learned many teaching methods would always say, "You are the guide on the side, not the sage on the stage." When I'm creating learning materials like books, courses, or even small tutorials, that saying is always in my head. I try to stay as learner-centered as possible. Instead of telling the reader what I built and acting as a tour guide, I walk the reader through recreating the project so that they have a finished product at the end. They'll also have the experience they gained.

This week I found myself in a situation where I had a list of URLs, and I needed to get the page titles for all of them. My go-to for this is Ruby because Nokogiri is an excellent HTML parsing tool so I can do this task in a handful of lines of code. Processing a lot of URLs one at a time would be too slow, so I needed to do some kind of concurrent processing. I used a Ruby library called concurrent-ruby which I'd never used before, but it looked like a great fit. I was able to build a compact little program that scanned quite a few URLs in a couple of seconds.

With the task completed and the knowledge in hand, I decided to share it. But instead of writing a blog post that told a more extended version of the story you just read, I flipped the focus from me to the reader. I walked back through the steps I took, recreating the script in pieces and reflecting on the approaches I took.

The end result is the tutorial Getting Page Titles for URLs with Ruby.

In the interest of being a good teacher who models the behavior he wants to see, I will shift the focus from me to you. So here's a process you can follow when you find yourself in this situation:

First, reflect on the journey you took to solve the problem in the first place. What were you trying to solve, and what were you hoping to have when you were done? You can use this reflection later when you write your introduction to create motivation for the learner.

Next, retrace your steps. Go through the process of rewriting the code in a new project. Don't try to write a tutorial about it, but put the code snippets in order. Add some notes as you go about what you were thinking and why. Later, you'll use this to explain what you were doing and why you did it that way.

Then go back and turn that all into a draft that flows. Avoid using first-person language like "I" and focus on "you ."Replace the notes with sentences of text that speak to the reader. You can use the Code Sandwich approach, where you introduce the code, show the code, and then explain the code in more detail after.

By this point, you'll have a draft of the steps. Go back and add an introduction, using those motivations you reflected on. Tell the reader what they'll build and what they'll have at the end. Tell them what they need to be successful, like any prerequisites. Then move them on their way. Add a tidy conclusion at the end that recaps what the learner did. Give them some things to explore, like additional changes they could make to the project or other things they can read to help them learn more.

Finally, go back through and test your tutorial out. Read your tutorial and follow each step as a first-time reader would. Run every command and add every line. Make sure things work and that they make sense. Add any additional explanations you missed. This is also a good place to ask a peer to review your work. You might be too close to the work to catch everything.

Give it a quick spelling check once you've got it ready and ship it.

This is the strategy I share with authors I work with, and it's at the core of my teaching philosophy. You can see this in Build Web Sites with Hugo and even my book Automate with Grunt which was a []2014 Jolt award finalist](https://meshdynamics.com/documents/RethinkingJOLTAward2014Review.pdf) because of its concise and hands-on nature. It's been my experience that this process motivates learners and makes them feel empowered. They're proud to show off their work at the end, and if you're lucky, they'll share that work with you.

The next time you're thinking of sharing a process you used, think about how you can turn it into a process someone else can follow.

Parting Thoughts

Before the next newsletter, give the following things some thought:

1. What area of working with people do you wish you were better at? Who do you admire that does it well? What can you learn from them? Put together an action plan on how you can improve that skill.

2. Think of something you've recently learned. How can you turn it into a piece of content? How can you then turn that into something that takes the focus off of you and places it on the learner?

That's all for April. Thanks again for subscribing. If you found this useful, share this with friends and have them subscribe. And share your work with me on Twitter. I'd love to see what you're doing.

I'd love to talk with you about this newsletter on Mastodon, Twitter, or LinkedIn. Let's connect!

Please support this newsletter and my work by encouraging others to subscribe or by buying a friend a copy of Exercises for Programmers, Small, Sharp Software Tools, or any of my other books.