RubyConf, Day 2: Maximizing Productivity
Don’t reinvent it if it doesn’t exist; extend what exists.
Don’t be a coding superhero – you don’t need the latest, greatest
Be selfish: fix your own problems first, and don’t even feel like you need to release (but do share that you did something like that somewhere that others might notice)
KISS and YAGNI. Don’t distract yourself.
YAGNITAGAFI: …they aint’ gonna ask for it. Invest in your own features, don’t make guesses about what they’ll want. They’ll tell you. They may even write it themselves.
Test: tell your future self (and others) what you know is necessary and what you think might break.
Autotest to keep yourself from forgetting to test related things.
Keep everything in sight: Eric likes to be able to see his four shells: code, test, autotest, terminal) in quadrants of the screen. Keeps the edge of chat window handy. Uses SSH Keychain and SpiritedAway to keep essential bits on the menubar/tab accessible.
Use Heckle.
Automate everything: setup, migrations, common tasks. Automating setup is good self-defense against support requests.
Know (and love) your editor. [me: it’s your primary tool, of course].
Pair programming [me: Eric pairs with zenspider; I’ve heard them called “peas and carrots” ;]
Ping-pong pairing: write a test, other person fixes and writes next test.
Polish your docs just before release (but rdoc along the way). README == quick start guide, synopsis and feature overview, links to bug tracker and rdoc. [I’d add contact info for developer]
Set up a bugtracking with no anonymous submissions. Don’t keep it in your email or a mailing list. It opens up the debugging and fixing to the community of users.
Have a review partner beat on your code just before release. Local ruby user’s group is a good source. =]
Releasing with Hoe: packaging uploads emails and blogs all taken care of. This makes it possible to release lightly and often. Small changesets. Less complexity, easier to pin down introduction of problems.
Go have a life! =]
Maintenance
Bug trackers allow collaboration and reduce the load on you. Except when they don’t and instead send it to your email (or mailing lists, or blogs, or somewhere). Find them and move them into the bug tracker.
Version your tools meaningfully and consistently. (e.g. v1.2.3 == major minor bugs)
Don’t fear breaking your code into the natural components when it grows too big to be easily dealt with. Find the natural divisions (and dependencies) and pull it apart.
Inspiration
“I don’t owe you” … “right now”. You released it to the world so you agreed to help them, but it’s okay not to drop everything. Be okay with criticism; the critic might dig in and fix it themselves.
Go to a HackNight/HackFest. Talk to people. Help them with their projects; they’ll help you with yours. Go to the pre-/post- dinner/drinks where your laptop isn’t out so you’ll think and talk.
Look to other domains for interesting ideas. autotest was inspired by Smalltalk.
Answer your own annoyances – automate or change your workflow. IMAPCleanse was written to read ruby-talk and flag messages that are interesting, and delete aging, unread messages.
Q: What bugtracker do you recommend?
A: Eric tends to use RubyForge, doesn’t have a favorite.
Q: IMAPCleanse for …?
A: ruby-talk, primarily. Very hard in that volume to keep track of a thread. Then use smart folders to highlight types of messages. [me: would be interesting to see email divided by tabs/sets like for a given mailing list or interest like “New Threads”, “Old Threads I Replied To”, “Old Threads I Didn’t Reply To”]
Q; How much time do you spend communicating with the community? Do you close out the world occasionally?
A: Think week-to-week, not day-to-day.
Q: How do you pair program?
A: Ryan and Eric ping-pong at one screen, one keyboard. Turns into a contest to write the perfect failure test to force the other to spend maximum time coding the fix. “Coding Gang Bang” … give a person a big window on the projector and all they can do is type what they’re told. [me: yike! I don’t wanna be the typist!]
Q: How much time do you spend on open source projects?
A: Sometimes a lot, sometimes a little. Depends on interest. Used to do a lot more but then hit burnout. Balance is very important. Smaller, simpler changes.
Q: What happened to Robot Coop?
A: I left and worked for LimeWire for a while, left in August to decompress (worked on RubyGems) and now working on a top secret project.
Q: You work closely with Ruby Core and have been thinking about productivity … what do you think needs tweaking?
A: Hard to say. The biggest problem is language barrier. ruby-dev’s titles are usually in english, so you can know what they’re talking about but not what they’re saying. ;]
A: (from bug manager on RubyForge project): Would love to see unification on one bug tracker.
Q: You talked about the importance of bugtrackers. The impression is that Ruby Core wants to have bugs/patches submitted to the mailing list, not a tracker.
A: (Matz) It’s easier for me […] because I’m mail based.
Q: Do you have a method size limit?
A: Yes! Roughly one window high (~26 lines). [me: shades of what Drew’s been
Q: Do you lmit how long your rdoc is?
A: If it’s that long, the code should likely be refactored as it’s too complicated and needs that much explanation.
Q; What if you want to document mindset or why you chose a particular implementation?
A; I make it a short note at the end of the line(s) where the implementation choice was made.
Q: What methods do you use to increase coding speed?
A: I type on QWERTY (Ryan: “No, you don’t!”) Oh yeah, what am I saying, I type Dvorak (audience: Yay for pair programming!). Don’t change your keycaps or you won’t learn to touchtype. Autotest shaves a lot of time, ~2-10s per test run.
Q: Using autotest, do you just not save interim (e.g. broken) code?
A: No, autotest has trained me not to. Instead, I write small pieces. Small test. Small method. Saves every 30 seconds or so.
Q: How do you make it easier to pick up what you working on some time ago (a day or more)?
A; I break the work into chunks of a day or less, or spend a day in exploration.
Q: How do you go about becoming a better coder?
A: Pair programming. Test-first. Seeing what other people do and challenging their beliefs. Keep learning.
blog comments powered by Disqus