Every 100 days, each of us at 42floors chooses a personal goal to accomplish before the 100 days are up. Back in November, I chose my current goal: write 10 blog posts.

Today is day 100 and this is blog post number 10. There are a lot of things I’ve learned that I could write about, but one in particular stands out to me.

One of the hardest things in the software world is learning to actually ship what you’ve made. It’s much easier to simply continue working: adding new features, fixing bugs, refactoring. Often the work simply isn’t as fun. Building the core of a new product is great: you’re laying the groundwork, making important decisions about the entire architecture of your software. It’s all too easy to put off the finishing touches that are required if your software is actually going to be usable.

It’s even easier to put off the whole idea of finishing all together. Drawing a line in the sand and declaring your software ready for others to use is difficult. It means admitting things aren’t perfect and that you aren’t going to fix them (yet). Worse, it means exposing those flaws for everyone to see.

Writing, as it turns out, is exactly the same. In fact, it’s even more difficult to ship your writing. The inevitable flaws you expose when sharing your words are deeper and more personal than any code. And most writing is much more permanent than software: once shared, it generally doesn’t change very much, except perhaps to fix a few typos¹.

So, really, blogging has been the best practice for shipping software I could have chosen. I’ve intentionally tried to embrace imperfection. Every one of my posts needs more work. It would have been easier to sit on 10 drafts, unpublished, for all time. And it really would have been for all time, because none of them will ever be perfect.

My hope then, is that simply by forcing myself to ship lots of imperfect blog posts, my writing will get a lot better. I’ll probably never notice this while I’m writing. Every post I ever work on will have flaws, and whenever I’m writing I’ll be focusing on those flaws.

Every once in a while though, I’ll look back on an old post or two. That’s when I’ll see how far I’ve come.

1. Which, I believe, is why engineers invented the wiki. It’s much more comfortable to keep something an eternal work in progress. ⏎

A few weeks ago, I was given some terrible news: my talk proposal had been accepted.

It might seem strange that being granted something I had asked for would be terrible, but given my reaction to the news, it’s the only logical conclusion.

Here’s a short sampling of the things that went through my head: * What if my talk is boring and no one likes it? * What if no one understands what I’m talking about? * What if nothing I say is new at all? * What if I completely fail to prepare? * What if I have a great talk, but poor presentation? * What if I make a bad joke while on stage? * What if I say something that offends a whole group of people and the entire internet disowns me? * What if someone asks a question I can’t answer and makes me look stupid?

Judging by what most other people have written about giving talks, this is par for the course. Public speaking is universally terrifying, causes enormous stress, and take up countless hours of time in preparation. Why then, does anyone bother?

Because there’s nothing better than overcoming new challenges, and talks are full of them.

Giving a talk requires knowing something well enough to teach it to others. It takes hours of preparation, far beyond that which is required just to be proficient. And you can’t just know fragmented pieces: your knowledge has to be complete and orderly so that you can actually teach others.

Giving a talk (for most people) requires stepping well outside your comfort zone. It requires learning new skills that you can, should, but probably don’t use on a daily basis. Stepping into new things requires accepting a lot of mistakes will be made, and requires the confidence and perseverance to continue despite those mistakes. When giving a talk, all your mistakes happen in public, which is particularly unsettling.

Giving a talk requires great delivery. In a lot of ways, what you say is as important as how you say it.

Giving a talk requires a lot of work. More importantly, giving a talk requires a lot of work with a hard deadline. You have to spend many hours preparing, but you can’t spend an infinite amount of time. You can’t practice your talk until it’s perfect. At some point, it’s the day of your talk and you’re as ready as you can be. The trick then, is to prepare efficiently with the limited amount of time you have¹.

I’m learning a lot preparing for my talk. I know I’ll learn a lot more by actually presenting. And overall, the process has been, and will continue to be a lot of fun. All this motivates me to work on my talk, but I have to admit, there’s one thing that motivates me most of all: to be done with my talk.

1. If you think the time between your proposal’s acceptance and the conference is anything but limited, just wait. ⏎

For several months now, buried in my growing list of blog post ideas has been a single line: “ruthlessly prioritize”. If I remember correctly it’s a snippet of something Mark Pincus once said. While only a line long, somewhere in my brain it’s associated with an entire outline of a blog post.

That blog post would have talked about how there are, at any time in anyone’s life, a nearly infinite list of things that could be done, but time to do only a few. It would have concluded with a poignant reminder that everything we do is a choice, and it’s important to consciously choose to do the things most important to us.

Then I read Edmond Lau’s blog post and saw exactly what I wanted to write laid out before me.

It many ways, it would be easy to throw my hands up and never write that blog post. But after thinking about it for a while, I’m more motivated than ever to write down my ideas.

Initially, knowing someone else has written almost exactly what I wanted to write is painful. But there was going to be a blog post out there similar to mine whether I knew it or not. No writer expects everything (or possibly anything) they write to be completely original. So really, confirmation of such a basic reality of writing shouldn’t change anything.

In fact, there’s a reward to reading someone else’s opinion on anything you’ve thought deeply about, even if you haven’t yet published your thoughts, even if you haven’t yet published your thoughts. Having put your own thought into a topic, it’s much more rewarding to read what others have to say.

For me though, the most exciting thought was how I can improve my own blog post based on what I’ve read. I get to examine someone else’s attempt to write about the same topic, and learn from their work. I can focus on the areas I think they missed, or word things in a different way to avoid specific counter-arguments. Every writer puts their own personal touch into their writing; focusing on the differences is better than focusing on the similarities.

So at the end of the day there’s no doubt: I’ll be writing that blog post and many others. And whatever I write will be my own, even if someone else has written about it too.

Writing code that is easy to read and understand later is arguably the most important habit of a good software developer. There’s plenty that has been written about what the resulting code looks like, but theres more that goes into reading your code than just, well, your code. How you share your code with others helps too.

If you’re using Git (or any other distributed version control), then you have an incredible new power to aid in the understanding of your code, something someone using Subversion (or any other centralized version control) simply doesn’t have. I’m writing all this because I see so few people taking advantage of it.

The advantage is simple: with Git, you can rewrite history.

As a simple example, consider the common “forgot to check in a file” commit. With Subersion, there’s no way to fix this simple mistake, no matter how soon after committing you catch it. For all time one logical group of changes will be split into two places. With git, a simple git commit --amend makes things right¹.

The damage done by not repairing this sort of commit is real: the history of a project is an extremely valuable source of context and understanding. Every commit is a chance to record why something was done, and what it is supposed to accomplish. When reading code, these are arguably the most important questions to answer. Simply looking at code, even well written code, can mean spending time deducing the answers. With a well managed history, the answers are out in the open.

There’s a nearly endless list of ways to create a more valuable history. Most of them are, in fact, widely talked about. Git has cheap branching; use it to keep changes that solve different problems separate. There’s no reason to have a bugfix commit in a feature branch. There’s no reason not to split work on dependencies of a large feature into separate branches.

Commits should be made frequently. Initially, there’s no need for them to have any special meaning or semantics, because commits are infinitely malleable. Take advantage of git rebase and massage your many, disorganized commits created during development into a readable, ordered list of semantically meaningful changes. With practice, these types of improvements can be made quickly.

Invariably, talk of these types of changes seem to devolve into an argument over the concept of an immutable history. The idea is that as with Subversion, all project histories should record every change ever made, in the order they were initially made, regardless of the significance of each change. This is the most basic requirement of source control, but not the only one.

What’s often missed is that with Git, you can have the best of both worlds. Develop your feature however you want. Create dozens of messy, disorderly commits. Use commit messages that convey no information whatsoever. Stow these changes away somewhere. Use a tag, or a branch specifically for changes made during active development².

Now that you know how your code should be written, take just a couple minutes and reorganize, reorder, and coalesce. The details of how the code came to be are no longer important. The priority now is separating changes into logical, semantic units that, when taken in order, come together to make the change in a readable and understandable way.

Everyone on your team will be asking questions your commits can answer. Even future you will ask need reminders about the history of your code. Don’t make anyone have to figure out your code on their own, give them all the help you can! You’re not using Git to the fullest if you don’t.

1. With the usual warning to not use “`git push –force“` if it would disrupt others. ⏎
2. An awesome feature of git branches is that they can contain nearly any character, including slashes. I’ve seen projects that use this to split branches into categories. There can be categories for bug fixes, experiments, development, etc. The initial, unstructured writing of code done during early development can certainly be a category. ⏎

About a year and a half ago, over ten years into my career as web developer, but with only about six months of using web frameworks of any kind, I made the deliberate choice to switch from Python to Ruby. My reasoning was short and simple: I had heard far too many people say good things about Ruby on Rails, and how it was better than Django (that’s a debate for another blog post).

I didn’t really care for Ruby’s syntax, thought Bundler, RVM, rbenv, and co were far more confusing than pip and virtualenv¹, and especially thought the entire mantra of writing code to almost read like English was laughable (things like 5.times especially irritated me).

In short, I expected to essentially carry on programming just like before, except possibly with better tools to help me along. That’s not quite what happened.

Initially little changed. My for i in items: was replaced with for i in items do, but did exactly the same thing. But questions started coming. Why did Ruby have do/end AND curly braces? Why were loop counter variables sometimes enclosed in vertical bars? Why did every damn thing include Enumerable?

As I worked with Ruby more and looked around at code written by more seasoned Rubyists, I noticed something even more strange: no one seemed to use for loops at all. It didn’t even save any typing (clearly the most important thing to Ruby programmers), yet items.each do |i| was universally preferred.

Furthermore, Rubyists seemed to hate creating variables. Class methods were short, and seemed to just take an input, massage it in some small way, and – without even the courtesy of an explicit return statement – pass it on to the next thing. My C++ trained brain longed to see variables created simply to iterate through arrays. Instead all I got were calls to map. I found myself using each_with_index just to stay comfortable, without even needing to use an index.

As time went on though, I began to appreciate the conventions the Ruby community had adopted. There was great clarity to be had in concentrating on what was being done – transforming some data –, rather than how it was done – by iterating through every element in some sort of collection and doing the same thing to each element. My code was shorter, but more importantly, it was more obvious what it was doing, and why it was doing it.

Meanwhile, a movement was brewing in the programmer community at large. “Learn functional programming” they said. “Down with side-effects.” “Bow to your higher-order function gods”. I took note to read up on it some time and kept on coding.

Later, as I was also becoming better with Javascript, a language I had first learned a decade before and dismissed as poorly designed, I finally started getting comfortable when I discovered Underscore.js and Backbone and immediately was comfortable with their powerful collection utilities. “Finally, someone has brought the power of Ruby Enumerable’s to Javascript”, I thought.

The functional programming proponents are at least as numerous in the land of Javascript, so this was about when I really decided to take a look and see what they had to offer. To my astonishment, everything I read about functional programming wasn’t talking about anything new, but simply giving names to things I already did.

It was then that I realized many of the things I loved about Ruby weren’t Ruby things at all. They were functional programming things. Underscore didn’t bring the power of Ruby to Javascript, it brought the power of functional programming.

1. I’ve completely reversed that decision and can’t imagine leaving my Gemfiles behind for requirements.txt. It seems silly that one would install packages, then write the list of installed packages to a file for later, instead of just writing a list of packages to install. ⏎