Coding Philosophy

A collection of 108 posts

Software Engineering , Coding Philosophy

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

Coding Philosophy

Its Already Hard, Don't Make It Worse.

I was ice climbing with a buddy once in the Adirondacks We had hiked up to the bottom of Multiplication Gully, which is a very popular climb. It was 25 degrees out, but it’s a steep approach and we were carrying heavy packs so we hiked up in long

Coding Philosophy

Rituals

Rituals are an important part of humanity. We’ve been performing them for years. They serve a purpose. They help us to form good habits. As everyday examples, you probably have rituals around brushing your teeth or around washing your hands. There are certain triggers that you use to tell

Coding Philosophy

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

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

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

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

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

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 , 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

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,

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

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

Coding Philosophy

Coding Camps and Climbing Gyms

I have been a programmer for over 15 years and a rock climber for over 20. During that time I have seen a lot of changes in both. In some ways, the changes are very similar. Rapid Growth Both programming and rock climbing have taken off over the past couple

Coding Philosophy

Informative Versus Transformative Learning

In the technology field, particularly programming I feel like we tend to focus a lot on informative learning. Informative learning is just building upon what you already know. For instance, if you already know how a for loop works in C, and then you learn how to implement it in

Coding Philosophy

Two Questions To Improve Your Software Development

Learning is about asking the right questions. When I get a new client, I need to learn about their business and their software development process. I ask lots of questions. There are 2 questions that always seem to lead to the most insight. Asking these questions of ourselves can generate

Coding Philosophy

Soft Skills for Software Development

We tend to equate writing software with technical skills. It certainly does involve some technical skills, but really writing great software is all about human skills, often called soft skills. It’s all about how you interact with other people. Typically you are working in a group and even if

Coding Philosophy

Debug Driven Development

Recently on episode 5 of the DQMH podcast, Chris interviewed Joerg of Hampelsoft. There was a lot of good conversation, but one of the things that stuck with me was the idea of Debug Driven Development. That is writing code in such a way that it is easy to debug

Design Patterns , Coding Philosophy

Keystone Pattern

Reading the Continuous Delivery book recently has got me thinking a lot about ways to achieve continuous integration while still adding new features. The book suggested Branch By Abstraction as a way to avoid stepping on each other’s toes. It also mentioned the Keystone pattern. The real problem the

Coding Philosophy

Dive into the source

If you have been following this blog, it should be no surprise that I listen to the Maintainable podcast. It is a great resource. The other day I was listening and I heard a clip that really spoke to me. Justin Searls is talking about debugging and not being afraid

Coding Philosophy , Community

DQMH Podcast Interview

I had previously mentioned the DQMH podcast. Chris just posted an interview that I did with him a few weeks ago. If you are interested in what we are doing here at SAS Workshops and learning more about how we can help you, then be sure to check it out.