I think most software developers love short feedback cycles, whether they realize it or not. And it makes sense! Really short feedback cycles are one of the first things most developers experience when they write their first “Hello, world!” program. A lot of developers get hooked when they see that any change they make to the code is reflected immediately in the output. This feedback cycle is nearly instantaneous, and many developers love that about programming.

I enjoy listening to tech talks from expert software engineers. When you listen to a good tech talk, you’re given the opportunity to learn from someone else’s experiences, and this is really valuable in such a fast-moving industry. A lot of tech talks from big developer conferences are posted online for free, and I’ve kept a list of some of my favorite tech talks from the last several years. These are the five tech talks that have had the most influence on me personally, and I think that anyone who’s a web developer should listen to them if you haven’t already. Although most of them are several years old by now, I think the ideas presented in them have already stood the test of time. So while some technological details might change, the big ideas presented are still relevant and will continue to be for a long time.

It’s been nearly 2 years since I originally wrote about How I Manage Passwords with KeePass. That blog entry was inspired by Troy Hunt’s post, “The only secure password is one you can’t remember”. Using KeePass was a wonderful experience, and I’m thoroughly convinced that everyone should use a password manager. The ease of use and level of security a password manager provides is way better than anything else you could do to remember your passwords. One of the most common ways a person can be hacked is by reusing the same password on many websites. The problem is that if any website has a data breach, all the websites you used that password on are compromised. And a password manager solves this problem by using a different password on every site.

It’s October, and Hacktoberfest is in full swing! It’s a great time to contribute to open source. I love open source software and the open source community, and I think contributing to open source software has lots of benefits for professional software engineers. Here’s 5 reasons you should contribute to open source software.

Is your source code developer-friendly? Developers talk about user-friendliness of applications all the time, but don’t often think about whether their own source code is user-friendly. Code tends to rot over time. The documentation gets out of date, configuration files change, little “hacks” are put into place… Eventually, it gets so bad it takes days for a new developer to get his environment set up. And along the way, he has to talk to two or three gurus that know all the little tricks to make things work right. As code ages, it becomes less developer-friendly. As developers, it’s our job to counteract that tendency.

I made a training log for runners in Google Sheets!

Even in the age of Fitbit, GPS running watches, and Strava, a training log in a spreadsheet is a useful tool. Because it’s a spreadsheet, it can be used to analyze data in ways that websites and apps can’t. It’s easy to share with a coach. And some people might find extra motivation from setting a goal and recording their progression over time in a spreadsheet.

The Myth of Code Reuse, a quick video by Iain Lowe, became quite popular on Reddit in /r/programming a few weeks ago. I think the reason for it’s popularity is obvious. Lowe talks about the amount of time developers invest in making code “reusable” with interfaces and abstractions, only to watch that code be replaced a few years down the road. Many professional developers have worked with legacy code bases that frequently use these types of abstractions (designed for “future-proof” code), but found the code to be more complicated than necessary and difficult to work with.

Your resume says a lot about you. Perhaps more than you think. I’ve looked at a fair amount of resumes and when I read a resume, I’m not only interested in the experience that’s listed. I also look at how well the person communicates their ideas in a clear and concise format. A well written and easy-to-read resume can make a good first impression, and a poorly written resume can definitely hurt you.

I recently completed a job search where I had the pleasure of interviewing at several companies. Throughout the process, I developed and refined a list of questions to ask the companies I interviewed with.

I’ve also spent a lot of time on the other side of the interview process, and I’m often surprised when the candidates I’m interviewing don’t have any good questions prepared to ask me. They should want to know how we do things here! Asking good questions during the interview process helps both parties find the right fit, so I decided to share some of the best questions I’ve found.

I recently had to reinstall Windows on one of my personal computers. Although I hardly ever use Windows anymore, I keep it around in case I need to run some software that isn’t compatible with Linux (my primary OS).

After reinstalling Windows, I needed to re-install all my favorite programs so things are there when I need them. In the process, I kept a short list of all the Windows software I like to have installed. Most of it is free or open source, so have a look. Maybe you’ll find something useful.

Have you ever tried to diagnose a test failure and had no idea what’s broken? Maybe you were looking at something like this:

Failed asserting that false is true.

Or, equally as bad:

java.lang.AssertionError
  at ...

These are pretty bad failure messages. They have the bare minimum amount of information you might get from a failing test. They tell you something’s broken, and probably give you a line number or a stack trace, but that’s all. They don’t give you very much useful information. In the spirit of Google’s Testing on the Toilet, this is my own rant about one way you can make your tests better.

How much faster does a new SSD make a 2012 MacBook Pro? A lot.

I recently upgraded a 2012 MacBook Pro with a new SSD, and I was blown away by the results. The computer was nearly unusable before the upgrade - it took more than two minutes to boot and about 30 seconds to launch a program like Chrome or Safari. (Although once it finally started, it wouldn’t be too bad to do something simple like surf the web.) Apparently (as you’ll find in comments all over the internet), lots of older MacBooks suffer from really slow responsiveness when running newer versions of macOS. Luckily, the problem can be fixed pretty easily by replacing the OEM hard drive with an SSD – after the fix, the MacBook Pro boots in about 25 seconds and launches programs almost instantly. Overall, the SSD made the computer about four times faster when doing disk-bound operations like booting up or starting a program!

The Hour of Code is an annual event to encourage Computer Science education during Computer Science Education Week. I participated this year by volunteering at an elementary school, where I spent about an hour introducing the students to computer programming through Scratch. I think Scratch is a great way to introduce people (both young and old) to programming because it is simple enough that beginners can get started very quickly, but also powerful enough to create good-looking games (like this Flappy Bird Clone).

On the StackOverflow Podcast, they always ask their guests on the show how they got introduced to programming. Whenever I listen to that segment of the podcast, I always think back to my first experiences with programming, and how I built on those to get where I am today. I like the podcast segment a lot, and I think it’s fun to share these stories. So, in honor of Computer Science Education Week, I’m going to write a blog post about some of my first programming experiences.

Hacktoberfest is a project sponsored by Digital Ocean and Github that encourages contributions to open source software. Anyone who contributes at least 4 pull requests to open source projects on Github during the month of October will get a free Hacktoberfest shirt for their participation.

This year, I participated in Hacktoberfest for the first time as a project maintainer. After learning about the event, I decided to create several issues in my Container Immersion project (which I wrote about in February) with the Hacktoberfest label, inviting new developers to help out. Initially, I was surprised by the quick response of several people willing to help. This is probably the best benefit of Hacktoberfest - it creates an environment where people are actively looking for projects to work on, and projects that normally wouldn’t receive much attention are given a chance to gain exposure and receive contributions from the community.

AWS is incredible technology, making it easy for anyone to deploy a web service without needing to worry about managing servers. In this quick tutorial, we’re going to see how to deploy a simple web service to AWS Lambda and make that service available on the internet with AWS API Gateway. Let’s get started.

Have you ever noticed your internet connection get slower when uploading a large file? I have, but I never put too much thought into it or realized I could do anything about it… Until I stumbled upon this blog post from a systems engineer at Ookla (the company behind speedtest.net). As it turns out, there’s a term for this (bufferbloat), and this is an easily solvable problem.

In recent years (and in some cases, for many years), Continuous Integration (CI) has been taking off. Almost any open source project you look at is using some kind of CI tool like Jenkins, TravisCI, or CodeShip. In the simplest cast, the CI server is just running unit tests. In more complex cases, the CI server runs unit and integration tests, produces a build, and maybe even deploys the software.

I was recently shopping around for a new GPS running watch, and I tried both the Fitbit Surge and the Garmin Forerunner 35. These devices are both good GPS watches with a similar feature set, so I thought it would be worthwhile to see how they stack up against each other.

At SpotX, we manage our codebase with Git. Our commits flow from our develop branch to production, with a code-freeze branch in-between. Like this:

Several weeks ago, I wrote a blog post about how horrible it is to have to deal with the various password restrictions websites use. Of course, that post was influenced by Jeff Atwood’s post, Password Rules are Bullshit. While writing the post, I did some research on what makes a good password. And after writing it, I spent several weeks thinking about my own password management strategies.

I love stories about hunting down interesting bugs. I find things like left-pad breaking the internet, cloudbleed, and the sleep bug in Eve Online extraordinarily interesting.

Jeff Atwood wrote a post on Coding Horror today calling out bullshit password rules. And he’s dead on. Password rules, as most sites implement them today, are not improving security. They might actually be hurting it. Even NIST agrees.

With the rapid growth Docker is experiencing, it seems like everyone is trying to learn how to use the technology. In fact, I've invested many over the last year in teaching myself to use Docker. When I was just starting out, I spent a lot of time searching for the quickest, easiest way to learn.

One of my friends and colleagues writes for the Project Management for Developers blog. He recently wrote an article about the importance of testing. I want to respond to his blog post and provide some additional insight into testing from a developer perspective.