I wrote a couple issues of a design newsletter earlier this year. I’ll eventually talk about why I stopped. Actually, I can do that right now: writing an email was sort of scary because you can’t edit once it’s sent out. Eventually I’d like to have a mailing list again so I’ll just need to get over that.
I was about 80% done writing issue 3 when I abandoned the project1. Anyway, I remembered that the draft some somewhere in Google Docs and thought it had a bunch of stuff about podcasts I enjoyed. It didn’t. But there were a couple other things I can use for future posts.
Then I remembered the writing about podcasts I like is somewhere in Evernote. So and I sort of found it.
A lot of people know her for her rules:
Your class can be no longer than 100 lines of code.
Your methods can be no longer than five lines of code.
You can pass no more than four parameters and you can’t just make it one big hash.
When a call comes into your Rails controller, you can only instantiate one object to do whatever it is that needs to be done. And your view can only know about one instance variable.
A lot of this is over my head, but I certainly know that five lines of code helps you focus on doing one thing.
Sandi also wrote Practical Object-Oriented Design in Ruby. I’m not a Ruby developer but I own a copy because it’s regarded as one of the best programming books out there, regardless of language. I wanted to learn Rails at one point in my life. One of the hardest things in programming is naming things. And if it’s hard to name, you’re probably not doing one thing with it.
If the simplest description you can devise uses the word “and,” the class likely has more than one responsibility. If it uses the word “or,” then the class has more than one responsibility and they aren’t even very related.
This can be applied more broadly. My favorite screencasts (egghead.io and Laravel) were enjoyable because they were short and taught one thing at a time. When I make a screencasts, I want to focus on teaching one thing a time. If I notice that the title might have and then it might be worth splitting into another screencast.
In that Bike Shed episode with Sandi Metz, there’s a Q&A at the end (it’s a recording of a live event). She answers a few questions about speaking. She really, really encourages it. It reminded me of another thoughtbot developer, Ben Orenstein. He also encourages speaking, teaching, and also blogging:
People who are in the market for a programming job should blog every day. Write about what you’ve learned so far. Don’t make the excuse that you’re just a beginner. Imagine someone who is two months behind you and write for them.
The key is writing it down when you have the beginner’s mind. You have empathy that is pretty much impossible to recreate once you gain more knowledge.
Sandi says if you learned something in the last six months, there’s probably something worth documenting and sharing with others. If it would’ve been helpful to you six months ago then it’s likely helpful to someone right now.
So I’m going to try to teach some things. But first I’ll make sure to write what I learn down as I learn it.
-
I will not abandon this project. Note: If you’re reading this in, say, 2017 and the count on the front page is still around 37, then I probably abandoned this project. ↩