Most Gemfiles I see are either unordered (just throw new gems in, wherever!) or alphabetically ordered. A while back, I reordered the Sifter Gemfile, ordering by difficulty of removing the dependency and grouping by functional area. Thus organized, it came out a bit like this:
- Framework: Rails, Rack, the mysql2 driver, JSON, Rake. We will basically use these forever.
- Gems for our vendors: Postmark, Braintree, Skylight, Bugsnag. We’ll use these as long as we’re using their respective service.
- Partner integratons: GitHub, OmniAuth, etc. Most of these aren’t maintained by the partner, and we’d have to drop the integration to drop the gem.
- Extensions: jquery-rails, delayed-job, will_paginate, etc. We could stop using these if we cared a lot, but we’re pretty committed to them.
- File uploading: carrierwave, fog, wand, rmagick. We’d have to overhaul our file attachment support if we wanted to remove these.
- Sphinx support: thinking-sphinx and ts-delayed-delta. We’d have to overhaul our search to remove these.
- Admin: bootstrap, etc. Things we could easily remove next time we overhaul our admin, which isn’t really a big deal if we decide to.
- Gems for building assets: jquery-ui-rails, therubyracer, execjs, coffee-rails, sass, compass, etc. We’d have to remove uses of the underlying tool (CoffeeScript, SCSS, etc.) if we wanted to drop one of these.
- Development gems: pry, ffaker, byebug, better_errors, spring, rack-mini-profiler. We can switch these out if we want.
- Testing gems: rspec-rails, capybara, etc. Again, if we change tools we can change these.
- Deployment: capistrano. This could go in the framework section, seems unlikely we’d overhaul our deploy scripts away from Capistrano.
This organization makes it easy to know where to add a new dependency. More importantly, we can better understand how much we depend on a gem and the level of effort to remove it if we need to.
How to get better at programming without even programming:
- Accept, in your heart and mind, that the languages, libraries, and tools that you use to write programs may not be good for other people, other teams, or other problems.
- Search for deeper understanding of approaches to programming that seem strange or incorrect to you. Don’t look for wrongness in what someone else is doing or what you’re thinking.
- You will come across scenarios that challenge principles 1) and 2). When you do, say what you can to help but err on the side of not making things worse; let go of what you can’t control.
Bonus: be a kind person.
Like fast food or coffee at Starbucks, maybe team leadership comes in three sizes.
Extra large leadership. “This is what you’re doing. Make it happen, let me know when it’s done.” The old school, top-down approach. This is what I thought all management was like many moons ago. In my experience this is only useful when people need to think only about what they’re doing, not why they’re doing it or how they do it. Leadership sets the work, lays out the exact process for doing that work, and closely monitors the work as its done. See also: Taylorism.
Large leadership. “Here are some things that need doing. Do one of them, keep me posted.” This is where I think cohesive teams of knowledge workers should aim to be. Leadership lays out the tasks to be done, makes the work to do clear, and gets out of the way. Luckily this is a lot more frequent lately, but probably not so much in part-time labor. Leadership still monitors the flow of work, but not overtly as in Taylorism.
Medium leadership. “Do what you think is most important. Let me know how to remove obstacles.” I suspect most leaders really want to get here, but are constrained, imagined or in reality, by some organizational detail. It’s definitely where I want to be in leadership style. High trust in the team, high trust in the leadership. Lots of unicorn dust.
Oddly enough, I think some teams and projects require large leadership and some require medium leadership. Some people want a little structure to their work, some projects require well-defined milestones to rally around. Other people can effectively guide themselves to useful outcomes, other projects are less about the milestone and more about the journey.
My pal Brandon Hays and I are fond of noting that projects have a very limited tolerance for the risk of picking a novel technology or approach. Thus, they should intentionally choose one thing to break ground on: database, language, domain model, testing methodology, design paradigm, etc.
Turns out, that’s sort of a thing in social psychology too:
Idiosyncrasy credit is a concept in social psychology that describes an individual’s capacity to acceptably deviate from group expectations. Idiosyncrasy credits are increased (earned) each time an individual conforms to a group’s expectations, and decreased (spent) each time an individual deviates from a group’s expectations.
Turns out this is strongly related to leadership, group expectations, and conformism. That explains a lot of my experience. Those most interested in trying novel approaches are often those who let expectations and conformism take a backseat to trying something new or breaking the mold.
I don’t think this is necessarily good or bad; it’s fine and healthy for a project to choose to vary from the norm in some way. Even better, manage those variances so if things don’t go to plan, you can back them out and keep rolling. But, it doesn’t hurt to consider varying in ways that are likely to yield more “credits” amongst your team.
Coding is not the new literacy:
When we say that coding is the new literacy, we’re arguing that wielding a pencil and paper is the old one. Coding, like writing, is a mechanical act. All we’ve done is upgrade the storage medium. Writing if statements and for loops is straightforward to teach people, but it doesn’t make them any more capable. Just like writing, we have to know how to solidify our thoughts and get them out of our head. In the case of programming though, if we manage to do that in a certain way, a computer can do more than just store them. It can compute with them.
That is, it’s not enough to write a loop in Ruby, a class in Java, or use a channel in Go. You’ve got to learn way more “material” than that: how to run your code in an application server, how to store rows in a database, how to deploy all your code to another machine. And then: how to have good taste, how to correct oversight, how to avoid bugs! And then, worst of all: knowing all the little miniutae like platform bugs, slow code paths, unstable code, dependency hell.
We shouldn’t put that upon people just because that’s how most programmers interact with computers. We should keep looking to help folks leverage systems as part of their work, not learn how to build systems to leverage systems to do their work.
Hence, the ending:
Alan Kay did a talk at OOPSLA in 1997 titled “The computer revolution hasn’t happened yet,” in which he argued that we haven’t realized the potential that computers can provide for us. Eighteen years later, I still agree with him – it hasn’t happened yet. And teaching people how to loop over a list won’t make it happen either. To realize the potential of computers, we have to focus on the fundamental skills that allow us to harness external computation. We have to create a new generation of tools that allow us to express our models without switching professions and a new generation of modelers who wield them.
We’ve succeeded in magnifying our voices with computers. I like forward to standing back and looking with wonder at how much we’ve magnified our minds.
Software’s Receding Hairline:
This is interesting, because the mechanism of growing a comb-over applies to software development. A comb-over is the accumulation of years of deciding that today is not the day to change things. A comb-over is the result of years of procrastination, years of decisions that seem right when you’re in a hurry to get ready for work but in retrospect one of those days should have included a trip to the barber and a bold decision to accept your baldness or take some other action as you saw fit.
A comb-over is a local maximum for improving baldness. You can’t really escape baldness of your head. You can escape a local maximum in your software, if you’re thoughtful about managing tradeoffs between product progress and technical progress.
It would have been better if you hadn’t gone bald in the first place though. Same with software!
(Analogies are just great. Thanks for this one, Reginald.)
Pro Bowl rosters selected by Michael Irvin and Cris Carter:
Last year, the NFL did away with the AFC vs. NFC format and began using “captains” to oversee a fantasy draft to fill out the teams. In 2014, Jerry Rice and Deion Sanders were the honorary captains, with this year’s choices being Hall of Fame receivers Michael Irvin and Cris Carter.
In other words, they took the one thing fans can control about the sport, choosing the team in the game that means nothing, and gave that responsibility back to millionaires.
Besides the dozens of other terrible things about the NFL, this is the most NFL thing I’ve heard all week.
18 months is a dangerous window, when it comes to building a product. It’s far enough in the future that it seems like you could deliver an ambitious idea within a year and a half. But it’s a long enough timeline that one is tempted to skip the necessary contemplation, dividing-and-conquering, and hypothetical thinking that the planning process forces on you.
As it happens, 18 months is 540 days. 540 degrees is one and a half revolutions. As in, you started a revolution, but ended up regressing.
Saddest trombone. Be wary of anything that promises to happen in 18 months. It’s the “epic handwaving” of project management.
Let me start with a quote from wonderful person James Edward Gray II:
One of my favorite techniques for really learning a new language is to read the core API like a good novel. I’m a hit at parties!
I’ve had great success with this approach as well. I probably read the majority of Rails, the source of every RubyGem I used, and chunks of Ruby’s standard library in my first few years of working with Ruby. I picked up new tricks, figured out how things worked, and got myself out of a lot of tricky corners by reading code.
That we can do this is, to me, the real wonder of working with an open source stack. If I’m curious, I can dig into the framework, language, database, compiler, and operating system I’m using. If something goes weird, I can dig into it. I probably won’t end up changing or fixing anything below my app in the stack, but the ability to peel back the layers is a huge deal.
Given the choice of digging into why software sometimes goes weird and complaining or giving up, always chose digging into the source to see what’s going on.
When you work with open source software, you can always chose to figure out what’s going on around your app. Eating at the source code buffet is awesome!