Recently, I finally got a chance to sit down and relearn to code. It’s been a goal of mine for a while, going back to the holiday break last December, but that unfortunately didn’t happen then. When the quarantine started, I made it a goal again. Well, I finally started getting into it in the last couple of weeks – not just because I wanted to learn but really more due to necessity (long story, won’t go into it now).
For context, I haven’t done a lot of coding since years ago (maybe 2016?). What I’ve been learning now is also very unfamiliar territory (web services and apps as opposed to the Windows desktop software I was more experienced with). So it’s been a thrill to learn to do new things to a certain level of competence.
More than learning to code though, I’ve also learned a lot about the nature of coding based on how motivated I’ve been to do it recently – so much, in fact, that I haven’t really felt the same satisfaction doing other work since and didn’t really want to do much other than code. Side note, that sort of explains why I haven’t posted anything here in a while.
Throughout all of that, I came to realize that something I’d like to call “coder’s rush” is, in fact, a thing. The question is, is it a good thing?
Quick feedback loops, instant gratification
Reflecting on my experience the last couple of weeks, I realize the reason coding can be so addictive is the same reason why, let’s say, video games are addictive. In three words, “quick feedback loops”; in two words – “instant gratification”.
From the very moment your code builds successfully, you close one short feedback loop (maybe 30 minutes to an hour, tops). Once you test your code and it does what it’s supposed to, that’s another feedback loop closed. Then your deploy is successful. Then your product goes live. It goes on and on. And modern IDEs make the feedback loop even shorter with features like intellisense. When that squiggly red line disappears after you change something in your code, you know you’ve done something right.
Every closed feedback loop is instant gratification for a coder and triggers a satisfying feeling of success. Of course, it may just be interim success. Just because your code builds, it doesn’t mean it’s going to work as designed. Relating that to video games, an extra kill doesn’t necessarily mean you’re going to win the game. But it still feels good to have these small wins anyway.
That, to me, is the “coder’s rush” – the feeling of being in complete control of your immediate results.
Now, feedback loops are great and the shorter they are, the faster we can react, improve, and learn. But like any addiction, quick feedback loops and the feeling of control they create can easily become a crutch – a “comfort zone” for developers. This is when the coders’ rush can be dangerous. There are situations where feedback loops will inevitably be longer and the less we’re comfortable with that, the less effective we’ll be growing into other roles.
What does it mean for managers
This implies a lot of things when it comes to managing people and I believe how we work with this phenomenon may be significantly different depending on the levels of the people we lead. I’ll break it down here.
Beginners and novices
Quick feedback loops are definitely helpful for more junior engineers. Feedback is key to learning and the faster it comes, the faster beginners can pick up the essentials. At this stage, even a successful build in a programming language you’re unfamiliar with can be an accomplishment worth celebrating.
On the other hand, it’s important for junior engineers not to get too comfortable with the short game. It’s so easy to fall into complacency once you think the feedback loop is done (e.g. when your build succeeds) that you might decide to forego the tests or “let others take care of that”. As a manager, it always helps to remind younger team members that the feedback loop actually goes much further than what they might be aware of at the moment. That’s a good way to prepare them for higher level responsibilities moving forward.
Senior engineers transitioning to leadership
Now the higher you go up the ranks, the longer feedback loops are going to get. That’s just a completely natural thing and that’s part of what you’re paid to deal with. When you’re working with the architecture, for example, you might not find out the flaws until people have started coding within it for a while. When you deal more with products, it’s going to take a few months in actual use before you’re sure you built the right thing.
This can be especially hard when you’re transitioning to leading people. There’s no standard indicator that tells you you’re doing a good job and you have far less control than you’re used to in terms of creating a successful outcome. The successes or failures your team faces can’t all be traced to things you’ve personally done and that can get really uncomfortable for someone who’s used to the coder’s rush.
Managing humans who are in this position means making sure they get the feedback loop they need to learn and adjust to their new roles. This level is where management by objectives really makes the most sense – establishing objectives over shorter periods of time (let’s say, a month) can create the feedback loop your new leaders need. Of course, setting objectives with them is just one thing; on top of that, you shouldn’t forget to make time to let them know how they’re doing (i.e. close the loop).
Managers and founders (that’s you!)
Perhaps most important of all is managing yourself, if you’re in a position of leadership. In the past, I’ve personally struggled hard with the long feedback loops that comes with managing a team. But here’s the thing – your team’s success is your success, and you have to take that as it is and be comfortable with it. Don’t overthink your individual contributions to that success; that might be impossible to tell for sure, as what you do and don’t do are equally important at this level.
Adding to this, you might sometimes find yourself (like I did) in a position where you need to code as it’s what your company needs the most. In startups, that might not be an uncommon situation to find yourself in. If this happens to you, it’s important to be self-aware lest you get too carried away (like I kinda did) and end up with too little time to perform your actual role.
Remember, as a manager or as a founder, building a team is your calling and that’s what you should spend your time on. I hate to tell you this, but you’re just going to have to wait way longer than usual to get that feeling of success. I promise you it’s going to be worth it.
Dexter is an engineering manager at Synacy, a co-founder of ATeam Business Software Solutions, and founder of TechManagement.Life. He loves to share his experiences and thoughts on managing software teams and running businesses.
1 thought on “Why “Coder’s Rush” Is A Thing”