Will Barrett

Startup software engineer. Classical cellist.

Read this first

Teaching beginners: lessons learned from teaching at Starter School

Starter School is an awesome program, currently in its first year, teaching programming and entrepreneurship out of 1871 in Chicago. I had the joy and privilege of co-teaching 5 3-hour classes with Brian Eng this semester on provisioning and deploying Rails, TDD, and Stripe integration. I have done a fair amount of mentoring of junior developers, but I haven’t taught development to a classroom of students before. I found it to be really different. Here are my big takeaways from the experience:

Don’t underestimate the preparation.

Planning out code samples and running through demos to make sure everything works takes a huge amount of time. This was my biggest surprise. Most everything went off OK, but reserving more time to make sure demos were solid would have improved one of the lectures greatly.

Don’t think you need to write all the example code.

In the best...

Continue reading →


Why am I here?

I have no clue how to build a successful product business.

No. Friggin’. Clue.

I can do a few things well - build websites, talk to product owners, boil down workflows into data structures. That’s what I have practice at. That’s what I’ve been able to do. But, the more I get into the online space, and the more I look at what others who have been successful are doing, the more I realize something really, really important:

Product quality is a function of what it helps the user accomplish.

Really great movie? Helps a user escape from reality. Really great business software? Makes something previously difficult extremely simple, or allow the business to make more money. Good pot or pan? Helps the user make good food. This is worth re-stating.

Product value equals what a user is willing to pay for it.

So, what does that mean? No clue. I’ve never been good...

Continue reading →


Ito: Who are those engineers who have the capability and skills to create real value?

Matz: The ones who would put in effort to create software or systems from a prototype to a final product. And this has nothing to do with whether they work in web or system integration, or whether it’s consumer oriented or corporate oriented.

Excerpt from The Future of Computing, The Future of Computer Programmers - An Interview with Yukihiro “Matz” Matsumoto

Continue reading →


Say No

“Say “no” to choices that require you to work certain hours or live in a certain place. These types of constraints will destroy you over time because they are counter to the reason you started in the first place.”

from the Micropreneur Manifesto

Continue reading →


How I would spend $2,000 on a desktop computer (June 2013 Edition)

This post was adapted from an email to a friend who started a new job and needed to figure out what to buy for her work computer. She was given a $2,000 budget to work under by her employer. Her system will be running Windows, but I based the hardware suggestions on my own Linux machine. The same general principles work for a computer on either OS. Of course, to get the same thing from Apple, you’d be spending $5,000+…

Anyway:

General Approach - Buy the Computer with What’s Left Over

There are a few things that you need more than computer horsepower - the right peripherals, decent monitors, and equipment to back up your data. So let’s price that first.

Peripherals:

The cheap part of your setup. Don’t compromise here. These are the bits that you actually touch. I recommend getting wired peripherals (not bluetooth) as they are less expensive, more durable,...

Continue reading →


Create an Opinionated Development Environment

We all have values with regards to development. Without becoming stagnant, we need to embed these values into our development environments and workflows to ensure that we keep our promises to ourselves. Your results may vary, but I believe in automated testing as a path to higher quality software.

I noticed this past week that nearly all of the bugs found by users in the applications we are creating are found in untested code. Usually, the code is fine when originally written, but when the underlying assumptions inherent in the system change (database schema changes, API updates, etc. - all common in emergent design) then the untested functionality is broken, and there is no way to know without manually testing that portion of the system. This is not a new insight - many other developers understand this. In fact, it is one of the basic justifications for writing test code in the first...

Continue reading →