Your web-browser is very outdated, and as such, this website may not display properly. Please consider upgrading to a modern, faster and more secure browser. Click here to do so.
Practicing Ruby has been supported by monthly subscriptions for the last several years. For most folks, this billing arrangement has worked out fine, but we do get the occasional request for annual billing. As of today, we’re happy to announce that we now support yearly subscriptions!
New subscribers will see both yearly and monthly options on sign up. Our existing users can visit their billing settings page, and then click the “Switch to yearly billing” button to change plans.
The price for an annual subscription is $96/year, which works out to only $8/month — the same as our current monthly rate. If you’re already happy with being billed monthly there is no need to change plans, but now you have the ability to choose the plan that’s right for you.
Saying something nasty or mean-spirited does not make you a bad person in the eyes of the world. In fact, for most people, most of the time, negative interactions tends to be sandwiched between positive ones, and so they fade away as quickly as they arise. The larger our social networks are, the more this tends to be the case, because we can quickly get over our own bad behavior by having good exchanges with folks who were unaffected by what we did.
Within a couple days, we feel fine again, and most people we interact with regularly will chalk our mistakes up to us having a bad day, and let it go. All of this makes it easy to forget that the people we hurt (and those who are close to them) may not recover so quickly. Sure, you can apologize for what you did, and when done well it helps, but there is no such thing as taking back what you said.
So the next time that person sees something from you, the fact that you hurt them will still come to mind. It could be months, or years later, but that person will remember. In the best case scenario, they’ll see you doing something wonderful: and that will perhaps change their mind about you to “Oh, this new thing is from that guy who was a jerk to me, but it looks pretty cool”. With enough time passing by, and dozens of positive interactions (even if they’re indirect), the person you hurt may eventually decide that maybe you aren’t so bad afterall, and that they were just an unlucky victim of poor circumstances.
But suppose that doesn’t happen. Suppose instead that the second, fourth, or tenth experience that person has with you (again, even indirectly by observing your work) leads them to believe that you are actually the kind of person who hurts people carelessly. If that happens, you reinforce the negative image that person has of you, to the point of creating a deep set grudge.
In either case, from your perspective, you may not notice at all that any of this is happening. You have good days and bad days, and you try to put your best foot forward, but mistakes happen sometimes. Because you are helpful and polite more often than you’re not, you end up surrounded by people who tell you what a great person you are, and that reinforces that image in your own mind. The stronger that effect becomes, the more you can get away with horrible things and not really end up being punished for it.
In a nutshell, this is the cost of internet fame. Your persona scales faster than your own ability to love, to care, and to be nice. This is why the internet makes it hard for us to have nice things, and nice people: We lack the kind of feedback mechanisms that would inspire lasting habit changes rather than just reactions.
If this is something you struggle with (and most of us do!), you should check out the article “A real person, a lot like you" from Derek Sivers. It contains simple and wonderful advice for making our online interactions more humanized. The advice he offers isn’t easy to stick to, but it’d really make the world a better place if we could follow it consistently.
I used to be in the habit of treating every new productivity technique as if it were some magical solution to all of my life’s problems. Because of that, I tended to advocate my newly learned techniques within the first few days of using them, while I was still riding the novelty-high. There’s a good chance that if you’re reading this post, you’ve ridden that wave before, and you too know that virtually all habits die or fade away within a week or two.
Now that I’ve gained the cynicism that comes along with years of failed life-hacking, I tend to think of each new thing I try as an experiment, allowing it to grow and mutate over time without an expectation of success. The things that survive for several months, I consider good habits that are worth keeping around.
Here are a few of the things that have stood the test of time for me:
1) Jerry Seinfeld’s productivity hack: Use a year-long calendar to track my progress on a single broadly defined goal. For me, this goal is “Two hours a day of content production work”, which typically means code samples or article text for Practicing Ruby, but can mean other stuff when I have special side projects to work on. I made this goal simple enough to be met with relative ease, but important enough to make it worth doing every day.
2) Keep blank index cards everywhere in my house, and pack a handful of them and a pen when I go out. These are NOT for a particular purpose, and have no organization to them by default. Instead, they are atomic bits of information (ideas, tasks, sketches, etc) that can be grouped into piles, pinned to the wall, stuck in places where you’ll see them, and most importantly: can be lost, thrown out, or destroyed.
I find that having no default organization to these cards makes it possible for the system to adapt based on what my needs are. Their fragility naturally prevents them from becoming too permanent, or too rigid. Their entire purpose is just to be a temporary buffer by which I can unload stuff from my mind in a non-sequential, non-structured way, and they serve that purpose wonderfully.
This seems to have given me the benefits that I had hoped to get from GTD, but without the system upkeep.
3) Maintain a single tiny (2ft by 3ft) whiteboard with my entire “action plan” on it for my work. Like the index cards, this has no default organization. In the past, this has been a linear list, right now it looks more like a mini-kanban board. In rare occasions, it has been a single sentence written in giant text to light a fire underneath my butt. The purpose of this board is for me to have a place to go to in order to remind me of what is most important for me to work on, and anything that suits that purpose is fair game.
4) Tie my production schedule to my break time. I take a minimum break whenever I hit a major milestone (like publishing an article), no matter whether I was on time with my work or late. However, I give myself a longer break if I can meet internally scheduled goals (like finishing an article within 14 calendar days), and an extra-long break when I manage to finish something unexpectedly early. This motivates me to do two things: make sure to get adequate downtime, and reward myself for doing my work well ahead of a deadline.
5) Set a single, directly actionable daily goal. I built a barebones micro-application called ShipItDaily that sends me reminders to do this and tracks my progress. By forcing myself to click a button that says “I shipped it!” or “I gave up!”, I get a daily reminder of what is realistic, and what isn’t. Also, this habit serves as an early warning system for when I’m starting to feel burned out, as I tend to fail to meet my daily goals more often then.
There are lots of other things I’m trying out right now that appear promising, but these few habits have helped me maintain a tight publishing schedule for over a year now. It is amazing how much they have changed both in my actual productivity, and my general sense of well-being. If you decide to give them a try, I’d be happy to hear how they work for you :-)
When I first started going to technical conferences, I was surprised at how easily I was able to break away from the social anxiety that had plagued me in virtually every other setting. Because everyone had something in common with me, it was so much easier to keep a conversation going, regardless of who started it. For perhaps the first time in my life, I felt at home among fellow geeks, rather than being the outcast.
I got into Ruby fairly early (2004), and so I came into the community with the benefit of ignorance regarding who the “rockstars” were. At that time, there were a few people who stood out as having larger-than-life personas, but they were rare. This made it even easier to approach people, and to get in touch with many folks who are now among the most well-known in Ruby.
As time went by, I was able to find more and more people I had spent some time with at earlier conferences to hang out with, and so I felt like I no longer even needed to try to carve out a social space for myself: All I needed to do was send a few emails or ping some folks on IRC, and I could easily fill up a several day schedule with lunches, dinners, and night time hack sessions and/or pub crawls.
More time went by, and I started to be recognized for my own work. The community was a lot bigger by then, which created a bit of a pop culture, and so soon enough there were people actively seeking me out to buy me a beer, to thank me for my work on this thing or that thing, or even ask me to sign a copy of my book for them. That last bit always felt a bit embarrassing, but thankfully it was fairly rare.
Eventually, my own existence as a “public persona” began to really tire me out, and the height of it never even came close to the folks I tended to hang out with at conferences. If it took me a half hour to make a quick trip to the bathroom and back because I ended up getting sucked into five conversations along the way, I can only imagine what it must be like for folks like Aaron Patterson, or Jim Weirich.
Increasingly, I tried to hide myself from all of that. I’d not wear my nametag, or clip it to my waist. I’d make plans with friends privately over email rather than blasting something out on twitter or a mailing list. It wasn’t that I didn’t want to meet new people — it’s that I craved the vague anonymity that I had by default in the first few conferences I attended. With it came an ability to speak without my “reputation” in mind, and with it, I didn’t need to consider my own standing relative to someone else’s. To me, that’s where the most healthy conversations happen: when there is no implicit power differential between those involved.
While I can tell you that most of the folks I’ve met who are “Big Names” in our community still act as if they’re just ordinary folks who love what they do and are happy to talk to anyone, they are frequently seen as something different than that from the other side. Not all the time, and not by everyone, but frequently enough where you have to ask yourself whether it badly influences the kinds of interactions people have at these conferences. Some of these things are baked into our nature as human beings, and they’re hard to shake. Rock stars are created when you treat people as if they were rock stars rather than ordinary people, and so there is this awkward feedback loop that keeps this cycle going even if no one ultimately ends up benefiting from it.
The more I tried to escape this stuff, the more I found that I couldn’t do so without sacrificing all the things I loved about conferences. With a baby on the way, I found a good excuse to take a year off from traveling in 2012, and so I was able to take a step back and really look at myself. What I saw, unfortunately, was not pretty.
After spending the better part of a decade increasingly breaking out of my shell within technical circles, you might expect that effect to have spilled over into other areas of my life. Unfortunately, it hadn’t, and I quickly found myself confronted with the awkward teenager that couldn’t place a pizza order without fear of something going wrong; the guy who rarely attends other people’s parties and when he does, sits in a corner somewhere waiting for the thing to end.
Before I got deep into the tech circles, I felt like that awkward fellow was just who I was; I didn’t have another point of reference to compare myself to. But this time around, it’s different. It’s a simple fact that I’ve spoken in front of rooms filled with hundreds of people, and even participated in an extremely ridiculous prank in front of upwards of 1000 people. Although it is a bit of a bizarre alternate universe, in the Ruby community, I’ve been “one of the cool kids” for a long time now.
Now that I’ve spent some time away from that community, I realized that I had optimized far too much for one narrow aspect of my social life, allowing it to become my entire existence. That allowed me to grow tremendously in a limited context, but caused much of the rest of my life to stagnate and even atrophy. And as I think about that, I think about what a tremendous loss that has been.
In the entire year I’ve spent away from the conference circuit, I can count on one hand how many of my “Ruby friends” have bothered to email me and see how I have been, even if I had previously been in regular contact with them. I’m sure that if I was still attending the same events as they were, they’d welcome me with open arms, but I have effectively disappeared by stepping outside of those circles. Go ahead and insert something about “that’s how networking is” here, because you’d be right. But that only serves my point more strongly: your connections in technical communities, no matter how deep they seem, are narrowly boxed into the things you have in common with those “friends”. In other words, they’re no substitute for the kinds of friendships that happen organically via everyday social interactions.
Maybe this is something that was obvious to other people and I just missed the memo. Still, I’d like to let this post serve as a warning for others who made the same poor choices as I did: if you ever find yourself outside of the warm-and-comfy bubble you’ve been living in, you may find that you’re not especially well prepared for the conditions out there. The lesson to learn from that is simply this: spend more time outside your comfort zone, and you won’t regret it. It is a natural human urge to want to be somebody, but it’s just as important to learn how to be nobody.
With all this in mind, I’m planning to spend as much time in 2013 outside the bubble, just to find out who I really am.
This is an abridged form of a rant I sent to the Ruby Rouges parlay mailing list, where I was accidentally invited to comment on something mostly unrelated. Still, may be interesting to others!
Since I’ve spent a good portion of my life teaching and writing and the last couple years doing so exclusively, I find myself spending a lot of time studying software design. Not a blog post which contains a summary of an article, that in turn was a summary of some book, that in turn was a summary of what was in an academic paper, but instead the original source materials themselves. This is essential if you want deep understanding of a concept, because you get the raw ideas, not the layers upon layers of transformations that have been applied on top of them.
But in all honesty, that deep understanding has given me enrichment and nothing more. I think when it comes to practical decisions made in code, it is useful to know all these patterns and principles and laws, because it makes it possible to communicate with others who understand them in a way that allows you to speak in a form of shorthand. They’re also useful as teaching devices, because they give you a framework to start from, a way to bootstrap yourself more quickly into an original point without repeating all of the world’s history.
But as for writing code every day? None of this stuff matters, until the moment that it does. I seriously don’t think much about all the rules and patterns and laws I have learned until the moment I’m looking at a piece of code and think: “It has problems X, Y, and Z”, how can I go about solving them? I don’t have any hard and fast rules that I follow when I program, except perhaps that I force myself to use 80 character lines. I don’t have any sense of moralism about coding decisions: There are costs and benefits and risks to everything, but no Right Way. Every time I delude myself into believing otherwise, it only hurts me.
Everything is constantly in flux, and everything is context-dependent. A year of dedicated studying of old crusty papers from the 1970s through the early 1990s will not change that fact, and I am telling you that from first hand experience. Every design decision is a conversation that ought to be based on experimental evidence in the form of real code: and every pattern, principle and methodology you can possibly learn is just a shorthand notation you can use to share your own thoughts with others who happened to learn some of the same vocabulary words and definitions as you did. The problem is that when dealing with people who came up with interpretations different than your own, a whole lot of clarification is needed.
So if I had to sum it up: Study these concepts so that when you’re pairing with someone, or when you’re having a conversation with your team about how to solve a problem, you can communicate more effectively with less effort. Don’t study them in the hopes that you’ll stumble across the “correct” or “right” way of doing things, because that kind of thing simply does not exist.
We need to work in an ecosystem in which the intersection of all of our possible motivations, interests, and interpretations of the world around us is the empty-set. With that in mind, what we need to get better at is communication and evidence-based argumentation that is tied to real world code, not endless discussions on philosophy that aren’t tied to a specific context and goal.
There have been many times in my career where I’ve seriously considered dropping out of the online programming communities I participate in. In fact, I have that thought about once a week, and every time I do it makes me feel miserable. I often ask myself how something I love so much can nauseate me on a regular basis, and I never have a good answer for that.
The thing that sickens me is the lack of honest communication, and the sloppiness by which we present our ideas and adopt the ideas of others. We are most often moved by who is the loudest, and who is the most popular; true merit has very little to do with the choices we make.
We promise others that methodologies will solve their problems because we comprehend them in theory, even if we’ve never actually implemented them ourselves.
We make promises to others based on what we’ve experienced in codebases that can’t be shared with them, so that our anecdotes become impossible to independently verify.
We offer terrible, oversimplified examples to each other that are so vague that they could be used to argue the case for anything.
We look at extremely local results and pretend as if there aren’t any global consequences to consider.
We push our ideas not by doing better research, not by taking more time to make a more convincing argument with better evidence, but instead by appealing to emotion and playing on the fears and insecurities of others.
We adopt black or white thinking, even when decisions are rarely binary.
When we are presented with criticisms, we quickly search for any reason at all to dismiss them; even if it means resulting to ad-hominem attacks or other nasty tricks. We double down on our own position rather than seriously considering the other side. This makes us better at defending our own opinions, but worse at seeing their weak points.
When we like something, we pay deep attention to its benefits while downplaying its costs, when we dislike something, we do exactly the opposite.
We fail to recognize how intensely context dependent almost all of our decisions in computing are: we vastly underestimate how different other projects and people are from us.
We adopt a winner-takes-all mindset that seeks rapid convergence rather than peaceful divergence and collaboration.
Because of all of these things, we resemble most nearly a community of politicians or marketers, even though we claim to be scientists, engineers, craftspeople, etc.
How can we do better? Well… a good start would be to negate all of the points listed above. Wouldn’t that lead to a better community to work in?
When I started the Practicing Ruby journal, I promised that I would release all of its articles under a CC BY-SA license within one year after they are published. I’ve already done that for Volume 1 and Volume 2, and today it is time to do the same for Volume 3.
You can now check out the raw manuscripts and an index of public share links to the articles as they appear on practicingruby.com. While I don’t do much to advertise this repository, its content is truly open source, and you can feel free to reuse it elsewhere, to submit pull requests, and to report issues as needed. If you do plan to do more than just read the articles though, please check out the project README.
Volume 3 is a bit of a mix bag, content-wise. It was written during a time where I was really struggling to keep up with Practicing Ruby’s production schedule, so it lacked some of the consistency that was found in earlier and later volumes. That said, it did have a few truly great articles, which I’m excited to release publicly today. If you read nothing else from this volume, please do check out Criteria for Disciplined Inheritance (Part 1 and Part 2). Only time will tell, but I currently believe that this pair of articles is the most significant contribution I’ve ever made to the Ruby community.
Now that three of Practicing Ruby’s volumes have been released, we’re looking at over 50 published articles under a CC BY-SA licensed that have been made available to the Ruby community at large thanks to our paid subscribers. Keep in mind as you read these volumes that they would not have existed without the support of those folks, and consider subscribing if you like what I’m doing.
Right now, there are two complete volumes (and dozens of conversations) still behind the Practicing Ruby paywall, but if you’re struggling financially please email email@example.com and I’ll set you up with a free account. Everyone else, please support grassroots indie-publishing and pay up!.
A few months ago, Practicing Ruby was going through many growing pains. I knew that major changes needed to be made to keep it moving forward, and so I made several public promises to help me stay committed to the project. I am happy to say that many of those promises have now been fulfilled, and the service is better than ever.
So what has changed in the last few months?
Of the public promises made, the only things we failed to bring to fruition (but still experimented with) was eReader-friendly content and regular office hours. The former turned out to be much more work than we expected it to be, and the latter was difficult to coordinate because of timezone issues and variable availability of our subscribers. We’d still like to revisit these ideas in the not-too-distant future, but in light of all the stuff that we did get done, I feel happy with our progress so far.
As we head in 2013, we could certainly just keep doing what we are doing now: It seems to be working for the most part, and our subscribers are satisfied with the service. But I’m not the type to settle with “satisfied” when I know I can knock someone’s socks off, so the plan is to keep moving Practicing Ruby forward at a rapid pace. So here’s what to expect in the coming months:
More and more great content from contributors. I’ve found that the time I spend selecting guest authors and helping them develop articles for Practicing Ruby is every bit as valuable as the time I spend writing content from scratch — and it also helps us cover a much more diverse set of topics. We’ve already got a great article from Aaron Patterson lined up for the first issue of Volume 6, and have several other contributions in the works as well.
Several experiments with different formats and mediums for our content: Right now the long-form article format has crystallized into something that works pretty well for our readers, but there are so many different ways to produce useful learning materials for programmers. Starting in Volume 6, we are going to alternate between our traditional articles and various different ways to present the topics we’re trying to teach. This will allow us to balance our efforts between what works right now, and what might make Practicing Ruby a better learning resource in the future.
Lots of small incremental improvements to the overall experience of the service. We’re now in a position to use a combination of direct conversations with our readers and some analytics to figure out how they interact with Practicing Ruby, and how to make it better for them. Rather than trying to make sweeping changes as we have in the last few months, we’ll use the next several months to make frequent small changes that add up to major improvements in time.
More effort invested into business development. This is mostly behind the scenes stuff, but the bottom line is that we want Practicing Ruby to thrive, not just survive. Right now the service is ramen-sustainable, but by the summer time I want it to actually be profitable in a meaningful way. I promise that I will never sacrifice customer experience to grow our business, but I do plan to spend more time on this side of things so that we can be sure that Practicing Ruby will still be around a couple years from now.
Our eventual goal is to become the Ramen Music of the Ruby learning world: A beautifully executed service that is ethical, and that rewards its contributors in a very fair way. We have made some great strides in that direction, and I am very excited to see what the New Year will bring us.
If you haven’t done so already, please subscribe to Practicing Ruby to come along on the ride with me, and tell your friends to join us too!
If you have a habit that you’re having trouble keeping up with, sometimes it is a good idea NOT to be too strict with yourself. Instead, take a day off guilt-free, and then take the time to look at the routine you’re trying to get yourself into and see if you can lower the friction by reducing the scope of your commitments.
New habits tend to be easy to start but hard to sustain, and once the novelty wears off, those promises we made to ourselves may seem much more ambitious than they did just a few days ago. In the end, consistency is more impotant than intensity: we should use this point to our advantage whenever we can.
One problem with deductive presentation is that it gives a seriously misleading impression. When students see a perfectly ordered and concise exposition of a relatively complex derivation they tend to think that the author/instructor originally came up with the material in the same neat fashion, which they (the students) could never have done.
They may then conclude that the course and perhaps the curriculum and the profession are beyond their abilities. They are correct in thinking that they could not have come up with that result in that manner; what they do not know is that neither could the professor nor the author the first time around. Unfortunately, students never get to see the real process—the false starts and blind alleys, the extensive trial-and-error efforts that eventually lead to the elegant presentation in the book or on the board. An element of inductive teaching is necessary for the instructor to be able to diminish the students’ awe and increase their realistic perceptions of problem-solving.
Page 1 of 3