I was away from my computer when I got a call from a junior developer I know. She was having trouble uploading a web application to Azure, and asked if I could help. I’ve never worked with Azure, but I assumed Visual Studio had a button which said something like “publish to Azure”. However, she couldn’t make heads or tails from the Azure tutorial, and while I was trying to understand where the difficulty was (other than the fact she wasn’t using Visual Studio, so the button I assumed was there was totally irrelevant), she said: “I understand the back-end has to go on the server, but where do the front-end files go?”
“Do you know how a web server works?”, I asked. “I guess not”, she answered.
If this seems stupid to you, this post is not for you. I give you permission to go read something else. This post is for me, setting up my first self hosted site about 10 years ago.
I was lucky to be in Dropbox’s headquarters when Kim Scott came to speak about her (then) new book “Radical Candor”. Dropbox was nice enough to hand out free copies (yay! free books!) so I actually ended up reading most of the book on the flight home.
Even though the book was written with managers in mind, I found myself referring back to it pretty often. Its insights proved quite useful in my daily work as a software engineer, especially in processes which require written or in person interaction with our co-workers. A little bit of Radical Candor can totally change how we do and react to code or design reviews, driving better results and higher satisfaction.
Radical Candor: Some Background
Before I share how you should use Radical Candor while creating software, it might be helpful to explain what Radical Candor is. I will try to keep this section as short as possible, since it’s just setting up the background for how to use Radical Candor in the context of software processes. If you’re already familiar with the framework you can just skip to the next section (titled Radical Code Review).
Radical Candor is about giving guidance that’s kind and clear, specific and sincere
A while ago I was telling a friend how I was frustrated at work. I had been adding support for a really important product feature, and our platform teams were making it impossibly difficult. It felt like every line of code required a month of negotiations to get approved. Let’s be honest here — I wasn’t telling, I was complaining. “Do they think we’re idiots?!”, I asked.
She was smiling with what I thought was empathy, until I was done and she said: “You are idiots”. Then she proceeded to explain that from her experience as a platform engineering manager, product engineers and platform teams live in a parallel universe. Finding common ground is quite a challenge. I believe at one point she used the words “silly baboons” (which gave this post its title).
I’m an engineer, but I also have an MBA and for this post I’ll be wearing that hat. I was seriously considering buying an actual hat with “MBA” printed on it, but some good people talked me out of it, so unfortunately it’s a metaphorical hat instead of a real one.
I often see engineers complain about recruitment processes: They are long, they seem totally irrelevant to the job, everything is stupid. We just don’t get it. Unfortunately, we’re probably right — some employers don’t have any idea what they’re doing, but does it really have to be that way?
One of the very best courses I took during my MBA was a course about recruitment processes and the research behind them. It left a lasting impression on me and affected my perspective on recruitment processes when I was hiring and as a candidate. When I hear these rants, I often try to explain the rational behind a good hiring process, and I think this is insight which can be useful for engineers and recruiters, which is why I’m writing this post.
I’ve never really had much of an opinion about error handling. This may come as a shock to people who know me as quite opinionated (in a good way!), but yeah. If I was coming into an existing code base I just did whatever they did before, and if I was writing from scratch I just did whatever felt right to me at the time.
When I recently read the error handling section in Clean Code by Uncle Bob, that was the first time I gave the subject any thought at all. Sometime later I ran into a bug which was caused by some code failing silently, and I realized it might be time to think about it a bit more. I might not be able to change how errors are handled in the entire code base I’m working on, but at least I would be informed on what approaches exists and what the tradeoffs are, and, you know, have an opinion about the matter.
After sharing in a passing that I had once written a business plan, I was recently asked to write a post convincing other women to join an entrepreneurship program.
My first reaction was “WAT”. I utterly failed at becoming an entrepreneur, I don’t know if my story is the best to share as a motivational story. But when thinking about it a bit more, I decided there’s nothing to hide. Being an entrepreneur is hard, and exciting, and utterly failing is part of the story. Failing is no reason not to try.
There is an age old debate: can programmers make do with just knowing how to code? Or do they need to understand some of their framework internals, basic data structures, and search/sort algorithms?
I have encountered many bugs created by being unaware of how hash tables are implemented. Or by a minor overlook which would have been a complete mystery to someone who didn’t know a binary search even existed. So you may guess that I’m of the opinion that you must have basic data structures/algorithms knowledge. I hope after reading this you will agree with me — but if not, you have social media to air your disagreement..
There is a traditional story that tells of a rabbi who comes upon a guy sitting next to a fork in the road. The rabbi asks the guy which way is best to get to the city, and the guy answers: That one is a short road which is long, and the other is a long road which is short. The rabbi chooses the short road, but soon arrives at a field full of thorns which he can’t get through, and must turn back and take the other road, which actually leads him to the city.
The moral of the story, other than wondering if this guy was the first troll in history, is that sometimes trying to take a short cut will end up being longer than just doing it the long way.