Samuel Taggart - The SAS Workshops Blog (Page 8)

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

Book Reviews

Practical SQL

I recently worked on a project where I did a bunch of database work. It had been a while since I had done any database work. I was feeling a little rusty. A while ago I had picked up a copy of Practical SQL. It was staring at me from

Unit Testing , How to , Coding Philosophy

How I use Test-Driven Development (TDD)

A lot of people out there are very dogmatic about Test Driven Development. There’s a lot rules and a lot of very strong opinions. If you don’t believe me, go check out Twitter. While on Twitter, I saw GeePaw Hill’s Ten I statements about TDD. It inspired

Conferences

Finally GDevCon N.A.!

Today is the start of GDevCon NA. As you are reading this, we are holding the first in-person LabVIEW conference since the pandemic started. We’ve got a great lineup of speakers planned. It is sure to be a great time. Thank you to everyone who made it possible! We

Coding Philosophy , Legacy Code

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

Book Reviews

The New Jim Crow

So what does a book about racism and criminal justice have to do with LabVIEW? Well on the surface, not a whole lot. Until you realize that all code is written by and for humans. Anything that helps us better understand ourselves and the human condition will make us a

Coding Philosophy

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

Coding Philosophy , OOP

Command Query Separation of Class Methods

In reading Micheal Feather’s book on Legacy Code, on page 147 it mentions the idea of command and query separation. A method should be a command or query, but not both. A command is a method that can modify the state of the object, but doesn’t return a

Book Reviews , Legacy Code

Working Effectively With Legacy Code

Several people have recommended this book to me over the years. I only recently got around to reading it. Software developers continue to recommend this 15-year-old book for good reason. It is quite useful because we all encounter legacy code and all of its techniques are still highly relevant. Thesis

Sam On Joel , Coding Philosophy

The Joel Test

The Joel Test is a classic. It’s been around for a while and is still increbibly relevant. It’s probably one of his most popular articles. I thought I would just go through each item and comment on how they apply to LabVIEW today. Looking at Joel’s list

Continuous Integration , How to

Trouble Shooting GitLabCI

I saw a post recently on LinkedIn by Jim Kring. He had some issues with a build hanging unexpectedly. They were running Jenkins under a system account and therefore it was really hard to see what was going on to be able to troubleshoot it. Jim then linked to a

Sam On Joel , Coding Philosophy

Back to Basics

So here is another article from Joel on Software. In this article, titled Back to the Basics, Joel talks about the importance of understanding how some lower-level things (like how strings are stored and memory management) work. It’s a bit of a rant. His conclusion is that you need

Book Reviews , Legacy Code

Legacy Code First Aid Kit

In general I hate digital only books. I much prefer physical books, but this one, like Dive into Design Patterns is worth making an exception for. Nicolas did a great job with this book. It covers 14 different tools to help get you started working with legacy code. If you

Kata , Legacy Code

Yahtzee Kata

The Yahtzee Kata is a common refactoring kata. You can see a version of it on Emily Bauche’s Github. As a refactoring kata, it requires some starting code. Emily’s page contains starting code for a lot of languages, but not LabVIEW. So I took it upon myself to

Book Reviews , Coding Philosophy

Peopleware

This book was recommended to me many years ago by a friend, but for some reason it took me a while to get around to reading it. I read it immediately after reading “Why Employees Are Always a Bad Idea” and a lot of the ideas seemed the same. Tom

Coding Philosophy , Book Reviews

Seven Transformational Training Assumptions

In the appendix of his book “Why Employees Are Always a Bad Idea”, Chuck Blakeman lays out his philosophy around training with 7 fundamental assumptions. Since we are all about training, coaching and mentoring here at SAS Workshops, I thought I would elaborate on his 7 assumptions and how I

Conferences , Announcements

GDevCon NA 2021 is on, in person!

GDevCon NA is now selling tickets! There are still some early bird tickets available. The date is October 20-21st in Boulder, CO. It’s going to be super exciting. We are also looking for more presenters and sponsors. You can get more info and buy tickets here: https://gdevconna.org/

Book Reviews

Why Employees Are Always a Bad Idea

Dilbert has been poking fun at corporate America for quite some time now. It wouldn’t be so funny if it did not contain some truth. Corporate America is broken and we all know it. “Why Employees are always a bad idea” explains why Dilbert resonates so much and what

Coding Philosophy

Code as Communication.

The code we write is a form of communication. We are telling the computer what to do, but we are also communicating with our colleagues. If we were only communicating with the computer, we could just simply write a bunch of 1s and 0s. That’s all the processor needs.

Coding Philosophy

Simplest Thing That Could Work

It seems like I have been giving the same piece of advice lately: Start with the simplest thing that could possibly work and only add complication as you need it. Sometimes our natural tendency is to plan for all eventualities. We get so caught up planning for what might happen,

Unit Testing , How to

A case for sets

Back in LabVIEW 2019, NI introduced both sets and maps. Maps became immediately popular. They should be. They are very useful constructs. However, sets seem to have gotten much less attention. In some ways, they aren’t as glamorous, but they do offer some advantages over arrays. To me, these

Coding Philosophy

Forget the word but

In improv, there is this idea called “yes and”. The idea is that the first person goes and starts telling a story. The second person (and everyone after them) picks up with “yes and” and then continues adding to the story. What you want to avoid doing is using the

SCC , How to , Software tools

A Better Way To Set Up LVCompare and LVMerge

EDIT: Since I originally wrote this post, I have come up with a much easier way. I am leaving this post up for historcial reasons, but do yourself a favor and just go here I have previously written about setting up LVCompare and LVMerge. I ran into a situation where

Coding Philosophy

The Freedom of Refactoring

Let’s talk about software design and refactoring in LabVIEW. When I first read Martin Fowler’s Refactoring book several years ago, it was very liberating. Prior to that, I had always had the idea that I had to get things right up front. It was kind of paralyzing. I

Sam On Joel , Coding Philosophy

Choosing a Language

I’ve decided to start a new series. I recently bought the book “Joel on Software” by Joel Spolsky. It is a collection of his blog posts. He still continues to produce more content today. Some of the articles in this book are a little dated but they seem to