Picture the scenario: You are staring at the computer screen and scanning the lines of code that fill it. You scratch your head and think: Why?
You debug the code, step-by-step and see a method call that sticks out like a sore thumb. It’s doing an out of process call to another subsystem before the code has completed its job in this method.
Why is that out of process call made there? There’s no documentation explaining why. Moving it to the end of the method makes more sense, but then everything breaks. WHY?
As a software developer, you might have experienced situations like this. You’re looking to fix a bug or extend a feature and you stumble over code that just doesn’t make sense.
You can see what it’s doing, even understand how it’s works, but you just can’t understand why.
In this post I’ll show you why making the extra effort to capture the intent of the code is so important. Continue Reading
Working as a developer involves communication on many levels. We need to communicate with business stakeholders in a domain specific language, abstracting away much of the technical jargon. Team communication on the other hand is a lot more technical, and closer to our reality in code.
A lot of our communication is silent though. It happens through async tools like email, Skype or Slack. I’m sure that anyone that’s attempted communicating this way has experienced how easy it is to under-communicate, leading to a ping-pong of messages before the intent and understanding is conveyed.
The end goal of all this communication is software that delivers value to users.
Software isn’t finished when it’s been delivered though. It changes over time and with it loses its original intent. This leads to even more async communication, which can go over months or years. I’m talking about the communication that happens through the code we write.