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
Let me introduce you to Malcolm. He’s my imaginary developer-friend currently working at Mega Enterprise Inc Ltd Corp. He’s been butting heads with the lead developer, Jack, for a while now. They don’t seem to be seeing eye to eye on a feature that Malcolm implemented. You see, Jack doesn’t like how Malcolm writes his code. Formatting is wrong and he uses way too long variable names, and he doesn’t write a single comment and…(list goes on)! Jack hates reviewing Malcolms code. Malcolm usually gets his code back from Jack, with a long list of TODOs. So Malcolm goes off to re-do most of his work just to give it back to Jack…When Jack’s finally happy with the code; It adheres to his preferred coding style and uses the correct enterprise patterns that have been decided upon. He allows it through the magic gates to master. 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.
I stumbled over a slightly different manifesto the other day. Or it was a legion actually. Developers taking up arms against a travesty of the C# language: #regions. You can read it at http://anti-region-legion.org. So what is the legion all about? Here’s the message from the website:
The Anti-#region Legion is a community for people who believe that the C# #region is an unfortunate part of the language.
I saw this and thought I was behind it completely, but decided to revisit my previous experiences and assumptions on the matter before concluding. Continue Reading
Update: I no longer recommend John Sonmez or his content.
So, you’re a software developer pushing boundaries and earning a living by writing code. You learn as part of your job or maybe by dabbling in projects or reading about the latest trends. You may be spending time, consuming content to learn awesome technologies and feel like you’re in a good place. But have you considered that consuming content as a way to keep up to date may not be the best way to learn? You most certainly will get to know about trends and technologies, but you won’t really be learning new skills. Continue Reading
The power of one
There’s nothing like being able to work on a project by yourself and having complete control of every single aspect of the solution. Everything from the front-end stack to the storage. Using the latest and greatest frameworks and libraries. This is heaven for any software developer. But regardless of any of the above technology-focused aspects, there is one major advantage being that single developer, namely: speed! But there are pitfalls when writing software alone. Continue Reading