Coding Philosophy - The SAS Workshops Blog (Page 3)

The importance of common language

In order to see things, it is important to have words to describe them. Words are how our brains categorize and store knowledge.

Book Reviews , Coding Philosophy , DevOps

The Phoenix Project

The Phoenix Project is a must-read book for anyone who works in technology. If you have ever worked in a larger company you will immediately identify with the situation described at the beginning of the book. You have an overworked IT department that seems disorganized and is always behind on

Runner on a trail in the mountains, stopping to take a picture of the view.

Coding Philosophy

Small Steps in Context

I've written before about breaking changes down into smaller chunks to make things more manageable, but we still have to take into account the context.

Coding Philosophy

The Arc of a Developer

In my recent interview for Legacy Code Rocks, I talked about the arc of a developer. I feel like there is this trajectory that people that go on over their careers. It's the learning and growth path that developers tend to follow.

A young boy with dark skin and curly hair covering his face with his hands.

Coding Philosophy

It's OK to Cringe

Cringing at your old code is actually a good thing. It implies that you've learned something. It is something to celebrate.

Interviews , Coding Philosophy , Legacy Code

Legacy Code Rocks

I was recently interviewed by Scott and Andrea of Legacy Code Rocks. We had a really great conversation about software engineering and dealing with legacy code. We hit on some important topics. It is worth taking a listen.

Sam On Joel , Coding Philosophy

Painless Functional Specs Part 1

This Joel article came out after the Joel Test. One of the aspects of the Joel Test is having a spec. Apparently, Joel got some pushback on that so he launched into a series of articles on Painless Functional Specs. This is the first. A Product of It’s Time

Coding Philosophy

Do we really need more features?

Adding features adds complexity to our program. Is this new feature really worth it? We should be asking this question more often.

Book Reviews , Coding Philosophy

XP Explained

This book is considered a classic for a reason. It’s inspired a lot of coders over the years. I think the first time I had heard about it was from Stephen Loftus Mercer talking about pair programming. I’ve heard a lot about XP over the years since then

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