![Sandworm](/content/images/size/w600/wordpress/2022/01/image_2022-01-25_175447-4.png)
![Sandworm](/content/images/size/w600/wordpress/2022/01/image_2022-01-25_175447-4.png)
![XP Explained](/content/images/size/w600/wordpress/2022/01/image_2022-01-25_134852-4.png)
![Rename AF Message](/content/images/size/w600/wordpress/2022/02/blog_proj-names-4.png)
![The Object Oriented Thought Process](/content/images/size/w600/wordpress/2022/01/image_2022-01-21_105322-4.png)
The Object Oriented Thought Process
This book was recommended to me by 2 different people. Several years ago Nancy recommended this book to me when I was first learning OOP. I generally trust Nancy’s recommendations (she has made some very good recommendations in the past such as XUnit Test Patterns and Continuous Delivery) and
![Innaugural GDevCon N.A. Recap](/content/images/size/w600/wordpress/2022/02/image_2022-02-04_161440-4.png)
![Premature Reuse](/content/images/size/w600/wordpress/2022/01/VIPM-4.png)
Premature Reuse
Premature Optimization
Premature Optimization is a phrase that is often heard in software engineering. It’s where you envision some potential performance bottleneck, so as you are writing the code, you go out of your way to create the most optimum code (ie written in a way that the compiler
![Re-Humanizing The Workplace](/content/images/size/w600/wordpress/2021/12/image_2021-12-07_145949-5.png)
![TLDR](/content/images/size/w600/wordpress/2021/12/image_2021-12-07_143942-5.png)
![More GitLab Runner Troubleshooting Tips](/content/images/size/w600/wordpress/2022/01/clear-runner-caches-4.png)
More GitLab Runner Troubleshooting Tips
I’ve been writing a lot lately about Continuous Integration and using GitLab Runner. It’s really nice when it works and it works 90% of the time, but issues do pop up occasionally. They can be a pain to troubleshoot. I previously wrote about how to run GitLabRunner as
![2022 Goals](/content/images/size/w600/wordpress/2021/12/MMT100-5.jpg)
![2021 in Review](/content/images/size/w600/wordpress/2021/12/IMG_3740-5.jpg)
![Checking for New GitLab Releases](/content/images/size/w600/wordpress/2021/12/GitLab-Autoversion-5.png)
Checking for New GitLab Releases
In my previous posts, I talked about automatic versioning and automatically creating releases. The next step is to create auto-updating code. By auto-updating I don’t mean code that automatically updates behind your user’s back ala Windows 10. You can do that if you want, but I believe the
![Automating Gitlab Releases](/content/images/size/w600/wordpress/2021/12/image_2021-12-06_170052-5.png)
![Automatic Versioning](/content/images/size/w600/wordpress/2021/12/Versioning-Ideal-6.png)
Automatic Versioning
At the GLA Summit recently minted LabVIEW Champion Felipe Pinheiro Silva gave a 7×7 on versioning. It was interesting. Be sure to take a few minutes and watch it when the video is released. I do things slightly differently. I learned my method from another LabVIEW Champion, Stefan Lemmens.
![Fierce Conversations](/content/images/size/w600/wordpress/2021/11/image_2021-11-02_174012-5.png)
![Its Already Hard, Don't Make It Worse.](/content/images/size/w600/wordpress/2021/11/Adirondacks-2007-Ron-29-5.jpg)
![Rituals](/content/images/size/w600/wordpress/2021/11/Rock-Climbing-07-013-5.jpg)
![Probably Are Gonna Need It (PAGNI)](/content/images/size/w600/wordpress/2020/02/tdms-typical-5.png)
Probably Are Gonna Need It (PAGNI)
YAGNI
Software engineers like acronyms. It makes it easy to remember and refer to certain ideas. You’ve likely heard the acronym YAGNI, which stands for “You Ain’t Gonna Need It.” The premise behind this is that as software engineers, we have a tendency to overengineer things. We often
![Practical SQL](/content/images/size/w600/wordpress/2021/10/image_2021-10-04_170949-5.png)
![How I use Test-Driven Development (TDD)](/content/images/size/w600/wordpress/2021/09/Example-Test-5.png)
![Finally GDevCon N.A.!](/content/images/size/w600/wordpress/2021/10/image_2021-10-02_204112-5.png)
![Fixing Legacy Code: Missing The Forest For The Trees](/content/images/size/w600/wordpress/2021/08/pexels-johannes-plenio-1567058-5.jpg)
Fixing Legacy Code: Missing The Forest For The Trees
Sometimes I wonder if we are missing the point by fixing legacy code. It’s not that we shouldn’t fix bad code when we encounter it, but it’s more a feeling of we’re missing an important opportunity. Let’s start with something that you may be familiar
![The New Jim Crow](/content/images/size/w600/2023/04/51nZ5MqeM8L._SY291_BO1-204-203-200_QL40_FMwebp_.webp)
![Legacy Code Testing and Requirements](/content/images/size/w600/wordpress/2021/08/image_2021-08-20_165035-5.png)
Legacy Code Testing and Requirements
One of the first traps you run into as a developer working on Legacy Code is to ask for the original requirements. It seems logical. Let’s figure out what the original designers of the machine intended. However for legacy code, that is a rabbit hole that will lead you
![Command Query Separation of Class Methods](/content/images/size/w600/wordpress/2021/08/image_2021-08-16_170035-5.png)