One of the things that I always forget to do when I set up a new computer is to install all of the special fonts that we use at Corgibytes. In the past, I've found the process to be tedious and time consuming. But recently, I've found a really nice way to install fonts from the command line if you're using macOS.
During a recent Legacy Code Rocks virtual meetup, a community member shared that a senior colleague had recently rejected a request to change a variable name. I used to encounter resistance to refactoring all the time, but since starting Corgibytes, I don’t come across it as often. But I’m curious if there are others out there who have encountered this sentiment, and I’m especially curious about how they’ve dealt with it.
I often encounter software projects that have absolutely no automated tests. This is rarely because the development team feels that authoring tests is a waste of their time. It’s most often the case that the team would love to have automated tests. If you feel like your project or team is stuck when it comes to automated testing, then I’d like to provide some guidance and specific techniques for how to get started.
Software systems can find themselves in a state of "rock bottom." When we encounter projects like these, we need to channel our inner monk. Start where you are. Eliminate the shame that goes with having a messy codebase. Embrace that your system is worth investing in and start making it better from where you are today.
About one year ago, on Monday, November 19, 2018, I said goodbye to my dog Ein. Ein was my Corgi and the original inspiration for naming my company Corgibytes. I want to take a few minutes to tell you about Ein, what she was like as a dog, how she touched my life, and how sorely she’ll be missed.
Occasionally, software developers get involved in discussions about what a good goal for code coverage is. What's the right answer? Well, clearly it's 100%. After all, why wouldn't you want to have all of your codebase covered by automated tests?
What if you could prove to your team that one of your commits didn’t change any behavior? And by any, I mean any. It doesn’t add a new feature; it doesn’t fix a bug. It’s nearly impossible that any behavior is altered by the commit. If you could do that, how would it affect the way your team operates?
Over the years, we’ve seen a bunch of projects in different states of disrepair. We approach each one of these projects with the assumption that every person who touched it did their best at the time with their given constraints. This is the embodiment of our first core value Act With Empathy.
Several months ago, I got a notification to upgrade Docker for Mac to version 18, and there was a note in the recent changes that caught my eye.
Wouldn't it be great if there were a documentation tool that's directly tied to the source code (so that you can always access information that's relevant to the code you're looking at), that doesn't clutter up the code itself, that's carefully and automatically timestamped (so that you know how current its information is), and that's guaranteed to be updated whenever the code is? Oh, wait. There is.