Search This Blog


Have I Improved as a Programmer? Part 1

Do you ever wonder how far you've come as a programmer? Well, I sometimes do, and today, I've decided to take a look and see if I've made any progress. I think that I have. I certainly have spent a lot of time studying and practicing to be a better programmer, not to mention the years of projects I've worked on in my career, making a living of this fascinating endeavor of instructing computers to perform automated tasks. One hopes that all of that effort hasn't gone to waste.

If I look back at one of my early projects, I should be able to easily see ways to improve it to make it clearer and cleaner. If I can't, well, what have I been doing all of these years? I decided to pluck a project from my operating systems course in college, good old CS537 from UW-Madison. It's a simple introductory project that implements a basic shell in C. The shell can execute commands either in an interactive mode from a prompt, or read commands from a file given to the shell as an argument when it starts. It's a small enough project that I can evaluate it in a couple blog posts, but not so small as to be trivial, like FizzBuzz or the Sieve of Eratosthenes.

Let's Refactor Some Bad Code, Part 3

To quickly recap, we're refactoring some code I found that implements a rainflow counting algorithm. I used this code as a model to implement a real time algorithm for use in a data acquisition system, but before I could do that effectively, I needed to basically rewrite the code so that I could understand it better. I started off by making some tests and running it through an auto-formatter. Then I improved the UI so that I could run the model more quickly. Now it's time to work through the main part of the algorithm and make it more clear and understandable. Once again, you can view all of the commits at my GitHub repo to see side-by-side diffs of the changes to the code.

Let's Refactor Some Bad Code, Part 2

One reason to spend time refactoring code is to make it livable. If you think of your code as a workshop—a place where you get work done—you want your workshop to be clean and organized so that you can spend time efficiently getting stuff done. If you have tools and materials haphazardly strewn all over your workshop, it will take longer to find the things you need, and it will be difficult to clear out the space required to do the tasks that need to get done. A messy workshop negatively affects the quality of the workmanship that's done in it. So it is with code.

Last time we did the bare minimum cleaning necessary to get a rainflow counting program in working order by giving it consistent formatting and a small set of tests. Now the goal is to target those parts of the program that make it the most annoying to work with and fix them so that the program is more well-suited for its use cases. I'll show each change to the code as a git commit, and you can follow along with the diffs in my rainflow git repository in addition to the code snippets I'll show here.

Let's Refactor Some Bad Code, Part 1

Unfortunately, we can't always be writing new code when programming. Much of being a programmer involves working with code that already exists because there is so much code out there already. There are mountains and mountains of code, and, as every programmer knows, not all of it is awesome. Sometimes this code has to be refactored to adequately maintain it, sometimes it needs to be done before new features can be shoehorned in, and sometimes it just needs to be done in order to stay sane while working with it. This is not always other people's code, either. Oftentimes it's your own code. I know I've written more than my fair share of bad code, and I may even use it as an example someday. That would be fun.

Tech Book Face Off: The Shallows Vs. Thinking, Fast and Slow

After my book review on Pragmatic Thinking and Learning and How the Brain Learns, I received a recommendation to read another book, The Shallows by Nicholas Carr. I decided to go with it (thanks +Helton Moraes), and I ended up pairing this book with another popular book on how the brain works and how we humans think, Thinking, Fast and Slow by Daniel Kahneman. Through these books I have a personal goal (it's good to have a goal when reading) of finding ways to regain control of my mind and hopefully improve my thought processes. Do these books help clear a path to that goal? Let's see.

Design Patterns in Ruby front coverVS.Practical Object-Oriented Design in Ruby front cover

Practice Programming Through Play

I'm a big fan of puzzle games for exercising your mental muscles while having some fun at the same time. Solving puzzles through your own powers of thought gives a certain kind of satisfaction that is especially rewarding. Games like Sudoku, Tetris, and Rubik's Cube are great for strengthening mathematical thinking and visual-spacial intelligence.

Nowadays we seem to have an endless supply of puzzle games on mobile devices to keep our minds occupied during all of the spare moments of the day. It's fine to use puzzle games to fill up the empty spaces of time, but I've found some games that entice me to go much deeper. Lately I've been getting into games geared towards introducing kids to programming concepts. Lightbot and Cargo-Bot are games that teach young kids the basics of programming by setting up sequences of simple instructions for on-screen robots to carry out in pursuit of a goal. While these are kids' games, and quite good ones at that, I've also found them to be excellent practice tools for me.

Tech Book Face Off: Design Patterns in Ruby Vs. Practical Object-Oriented Design in Ruby

I've been in a good book-reading mood lately, so I'm writing up yet another Tech Book Face Off. This time I wanted to dig into some more Ruby books, since I've felt like I still have much to learn about this wonderful programming language. I also wanted to work on writing better organized programs, so I targeted some books on program design. The books on deck are Design Patterns in Ruby by Russ Olsen and Practical Object-Oriented Design in Ruby by Sandi Metz. Let's see how they compare with each other and with some of the other books I've read on design.

Design Patterns in Ruby front coverVS.Practical Object-Oriented Design in Ruby front cover