The Clean Coder
a.k.a. "Software Professionalism"
I recently read Uncle Bob’s “The Clean Coder”. I have to say, this book slapped me in the face. There’s so much to discuss.
How to perform a good code review
Reaching agreement from a bunch of code
I recently wrote about how to create a good pull request, this is, how to make your code changes easy to review and discuss. Now we’re going to talk about the second part: reviewing someone else’s code. This puts you on the reviewers side, and hopefully the person submitting code did follow our guidelines to make your life easier.
There are several approaches you can take to review the code, but we’re going to enumerate a checklist that you could use to minimize the usage of your time and the efficiency of the code review.
How to create a good pull request
A meta-guide for creating easy to review requests
This has been a common question and a subject of debate since everyone has their opinions on what good code is and what bad code is. Regardless, the pull request is not about the code itself but about the actions of reviewing, adjusting, discussing and assimilating (merging) code, which may be good or bad in itself.
This will be later followed by a set of notes on how to perform a good code review.
Without further ado, let’s start with what is going to be a long article about sending a good pull request.
Death to Singletons!
Singleton.Instance.SelfDestruct();
No, I’m not talking about those that can’t find someone to be with. You’re ok in my book.
One of my favorite question to ask at technical interviews is “Can you tell me advantages and disadvantages of the singleton pattern?” I get varied responses, but while almost everybody can think of the advantages, nobody mentions the problems that come along with it. I’m going to quickly explain what singletons are and then roast them good.
Testability vs. simple design
Testing requires decoupling
You may know I’m a proponent for simplicity. I believe that if a particular feature can be achieved with a single if statement, then that’s all that needs to be done. I’m also a proponent of testability, that all code should be easily testable so that we can make sure that it works. As it turns out, these two don’t usually go hand in hand. (Spoiler alert: that’s not true.)
Taming your tools
Have you ever met a carpenter that would pick up a wrench and hit a nail with it? Probably not, and if you saw that, you would probably be thinking in taking your business elsewhere. And if you wouldn’t, then you should. Here’s why.
How to find the problem
Applied skepticism
User minusSeven from the StackExchange community asked a seemingly uninteresting question that happens to be really deep and meaningful: How do you learn programming when you’re stuck and without access to the internet? All the answers there are really good and useful, but I think there’s an underlying theme worth discussing: how a methodical approach should be.
Code Complete, Second Edition
Aspects of software construction, deconstructed
Code Complete is like the reference manual of software development, regardless of the technology, industry or language you’re working in. And there are really good reasons for that. Let me tell you what I thought of this book.
Automatically logging your timesheets in JIRA
Having the tedious work done for you
A while ago I explained how I use Google Calendar as my time-tracking system. I did mention, but did not explain, how I made this into an automatic system of timesheets for JIRA, the system some companies I work for use for time tracking. It just involves Google Docs and a little bit of JavaScript.
Software Security
MOOC by the University of Maryland
Yes, I continue to go on courses. Now I just finished the Software Security course, from the University of Maryland.
As usual, let me give you a quick review of what it was about, what you need to get into it and what you can get out of it as well.