An Incomplete List of Techniques to Level Up Your Career

This article was originally published on .cult by Honeypot by Ryan Latta. You can see the original article here, and check out some of our other stories!

* * * * *

At some point, you’ll want to try out some different techniques to strengthen your abilities as a developer. I say techniques because it is often in the process a developer follows, that they unlock more potential than from reading.

Reading is important, but the methods a skilled developer employs are what allows them to internalize and deepen that information and skill. Therefore, below is a list of techniques you can use to help you do just that.

1. White-boarding

While this may seem a bit like not much of a technique to master, it matters more than you’d think. Think about how many times you’ve seen another developer or leader in front of a whiteboard drawing out an idea, and how quickly people got the gist of it?

That’s the idea behind white-boarding. Going to a whiteboard and drawing will create shared understanding.

There is more to it than standing up and just drawing what comes to mind. There are usually competing needs that you have to contend with.

So, get intentional about practicing white-boarding. Look for an excuse to grab some people while you whiteboard your next idea for your code design, interface, desk layout, or anything you can. Your ability to communicate and create shared understanding is key to enabling your entire team to be as effective as they can.

Here are some questions that you can think about as you hone your white-boarding abilities:

What level of detail does this audience need to see?
What elements are critical to communicate?
How do I communicate the same aspects while remaining flexible at the board?
What ways can I draw that provide contrast beyond lines and boxes?
What data do I have that I can attach to my drawing?
What questions can I ask to see if we all understand?
How can I incorporate other people’s ideas and suggestions?

2. Test-Driven Development

Test-Driven Development is one of two well known yet, controversial practices that exist in software development. At this point, I have been using TDD as a primary technique for over six years, and I’d say this technique helped my ability to write software more than any other I’ve tried.

At the core, TDD has three basic steps:

Write a failing test (And see it fail)
Make the test pass (As simply as you can)
Refactor (Code and tests)

These steps are called the Red-Green-Refactor loop. Its simplicity is also its power.

By writing a test first, you have to create the basic design and interface for your code based only on your intent or wish. See it as if you are designing your code as a literal consumer. Approaching it from an outside-in test perspective encourages straightforward design.

You have to see your test fail at least once. If you don’t see the test fail, you don’t know if any of your changes mattered. Seeing it fail lets you detect changes as you code. As an interesting aside, if you’re using a statically typed language, compiler failures are a test failure.

Next, you need to make the test pass. Make your test pass by doing the simplest thing you can. If that means all your code does is return a hard-coded value, do that! The reason you do this is to keep your solutions minimal and distractions at bay. Solve only the part of the problem right in front of you. Solve more when you write your next test. The next test you write will force you to build a more complete solution.

Last comes refactoring. Ever feel like there is never a chance to go back and clean code up? Got those tech debt and refactoring work items that never get prioritized? Well, refactoring is incorporated into TDD. This way there is always time to clean up your code and test it hundreds of times a day!

Admittedly, there is a lot more to Test-Driven Development than this, though it’s a start— so if you’re curious, I recommend getting in a room and experimenting with it on a small, simple problem. Alternatively, find someone experienced to show you what it looks like.

3. Pair-Programming/Mob-Programming

Next on the controversial, yet highly effective, list of techniques is; mobbing and pairing. Those are fancy words for working together.

Pairing and mobbing work on the basic concept of leveraging more than one person’s brilliance to create something better than one could alone. This seems to make sense intellectually to folk, but they rarely try it.

Most developers like to protect their time, their style, and sense of, “What works best.” I agree that people need time alone to think, yet I disagree that working alone produces the best results.

One fascinating thing that comes from working as a pair or mob is seeing how other people solve problems. This deepens my problem solving and gives me alternatives. Which I would never have if I didn’t sit with other people.

At some point, most developers will find themselves in a room working hard to finish features and bugs prior to a big release. Worse yet, they are trying to recover from a release that didn’t go well. It’s strange that in these critical moments teams decide they should be together. They never split off and work alone when the stakes are high. So why not capture the benefit from these high stake moments yet without the stress.

To get started, I recommend setting some boundaries. For pairing, keep your sessions to no more than 45 minutes at a time with at least a 15-minute break in between. Need help getting someone to pair? Try asking, “Hey, could you help me with this for a bit?”

When you work together, pay attention to the roles. There is a driver who is at the one keyboard typing. The navigator is the other party who is reading, thinking, and suggesting what happens next. There are variations of these rules, but that is the basic configuration.

Want to mob? Get everyone in a room with one keyboard, and everyone tells the driver what to type. Swap people every few minutes. Mobbing is easiest to start when teams are first getting started.

Summary

There are about a million things to learn in software development. Take your pick: You could learn about architecture, design patterns, AI/ML, Blockchain, and so on. While these are all worthwhile endeavours, focusing on the techniques and processes you use with the information is what will separate you from everyone else.

Think about what technique or process you want to focus on, and try it. Be patient with yourself as you acclimate, and share what you’re experiencing with your team. It could be the start of something incredible.

* * * * *

Visit Ryan's dev.to site: