This holiday I learned how to play backward Stratego — a variant of the old strategy game. We used a set which has wizards, elves and dragons, but I’m sure it would be just as fun with a standard set. I expected it to be frustrating, but it was surprisingly fun.

Setup

1. Set up the pieces facing your opponent without looking at them
2. Then take turns with one person facing away, the other makes sure that the flag is in the back row, has a trap in front of it and a 8,9,10 or trap on each side, with a fair arrangement of strong pieces. If you have to make a choice, ask your partner “pick A or B” or “a number between 27 and 39” and then apply that to your choices so that it is suitably random. The idea is to make the game fun by being equally challenging.

Gameplay

Take turns moving pieces. You need to tell your opponent if he or she tries to move a trap (or a mine in the standard set). Once you know what a piece is, you turn it around to face you. Aside from trying and failing to move a trap or a flag, the only way to identify a piece is to attack with it (or be attacked). You can also pick a piece and ask if it can fly (to identify a dragon), but that takes your whole turn if it isn’t. We also decided that if you run out of dwarves (miners) then you can use the next higher piece to take out traps.

The overall economy still sucks — I read that this is not just the US, but a global problem. Meanwhile, in my little corner of the world, I run into people everyday who are frustrated that they can’t find good Rails engineers to hire. I’ve written that companies need to hire people who are good engineers and don’t (yet) know Rails. I also talk to a lot of unemployed engineers — people laid off from .NET, java or management and young people who are struggling to find their first (good) job. This blog post is for those folks. There are some key skills that are different and that you can (and need to) start to acquire before you can easily find a job.

I find that most engineers can learn the tech, but think they need a job to demonstrate that they know it. Therein lies the issue. It appears to be a chicken-and-egg problem, but it is in fact a gap in skillset. It is common for me to run into engineers who say they have been learning Ruby and Rails for months or years, but I google their name and don’t see anything they have published –no blog post, no tutorials, answers on mailing lists, bug reports, or patches. If you have tried to learn something, then you must have run into an issue with it. If you have built an app, used a gem — if you live in this world and write any kind of software, you have run into missing documentation, you have worked around an issue or solved a configuration problem. Working in open source, experienced engineers publish or patch issues that they find. If you haven’t documented or fixed issues, a hiring manager has to wonder: did you really build something? did you just follow someone else’s tutorial? are you someone who will push themselves? would you even notice if something wasn’t right? If you don’t participate it undermines your credibility.

The good news is this is easy to remedy. Don’t feel you have to start with a big project. It is better if you start with something small. Just continue to do your own development and whenever you run into an issue, really dig into it. Then publish what you discover. Whether it is a bug or a feature someone else will need the answer you just discovered. If it is a bug, report it. If you think you can fix it, submit a patch or github pull request.

More suggestions

• start hanging out in a Ruby or Rails forum or stack overflow and answer questions that you know or can find the answer to. Provide links to resources, not just answers. Do it in a friendly tone with humility or just give a simple answer. This is will sharpen your skills and start to build a little credibility.
• start a blog, write a short synopsis with a code snippet or reference to github repo with an example whenever you learn something, anything that you can imagine someone else might run into or you want to remember
• add your profile to workingwithrails.com
• show up at your local meetups, introduce yourself to a few people who look like they don’t know anyone
• start a study group
• volunteer for railsbridge (seriously, you could just show up on the mailing list and ask what needs doing, say what your skills are and what you would like to do)

While you are looking for paid work, plan to spend a significant amount of time honing your skills by solving some real problems.  In looking for a Rails job, that activity will serve you better than more hours polishing your resume.  Focus on being very good at whatever you do know and enjoy doing.  Understand the results that you can achieve.  Develop your own sense about what is great Ruby code, but be open to not having all the answers.  Once you get fairly good at something and have written code for it, consider publishing it as a gem.  There are plenty of bugs to be fixed and problems to be solved.

After my last post, I had a twitter conversation with @dhh about his talk and my reflections on it. I’m still not sure he understands that his talk wasn’t “weird-cool” like his example of _why, nor do I think it was an example of “weird-angry” that the Ruby community would disdain. Instead it is an alternate brand of weird, on the verge of weird-creepy — over the top for some, but merely boring and off-topic for me. I heard from one person via email that the keynote (and some panel I didn’t attend) caused a first-time RubyConf attendee to feel out of place at the conference — not likely to attend again. I didn’t get a sense of leaving in a huff, rather that this was a closed community with an in-crowd and a sense of humor not shared. I believe there a wide space between delightful and avant-guard experimentation in code and art, and the status quo of corporate America. However, David Hansson and others seem to fear that if they can’t use NSFW language and metaphor that soon we’ll all be wearing suits to RubyConf and the wild creativity of the Ruby community will be stifled. I think not.

I do believe Dave when he says that he sought to inspire…

Over twitter, he re-stated his thesis for me:

What does freedom mean with respect to code?

David referred to Maslow’s Hierarchy of Needs, suggesting that there is a parallel hierarchy of programming languages. I think assembly language should be considered the bottom of the pyramid, since it allows programs to survive using a primitive communication with the machine and agree that Ruby supports the top of the pyramid.

Self-actualization

The top of the pyramid includes: morality, creativity, spontaneity, problem solving, lack of prejudice, acceptance of facts
Examples:

• Open / Dynamic language (spontaneity and creativity)
• Strong support for and widespread practice of testing supports (lack of prejudice, acceptance of facts)
• Ruby Gems allows for experimenting with new versions of libraries
• rubygem.org and gem push (creativity, spontaneity)

Esteem

The next level includes: self-esteem, confidence, achievement, respect of others, respect by others.  These aspects are in some ways strongly supported by the community where there is technical support for publishing our work and strong systems of acknowledgment.
Supporting Examples:

• Ruby Gems
  • Gem specification with author attribution
  • rubygems.org download stats
• GitHub
  • free for open source projects
  • fork
• Blogging, Ruby Meetups, Regional Conferences: diverse venues and respect given to people who publish words as well as code, and who talk about their work

Where we still need work:

• respect by others: there is a difference between playful and juvenile, growing up doesn’t mean becoming like our parents, we can take responsibility for our actions and our impact on others and still have fun
• respect of others
  • We’ve made great strides in the last year or two with the diversity of Ruby VMs to support various technical communities. Java, at times reviled by members of our community, can also now be appreciated for its JIT and other tools with JRuby. As Matz noted, diversity is tough, but worth embracing.
  • We still need to do a lot of work on making Ruby work for people who run Windows. It is not particularly helpful to tell someone who wants to experiment with Ruby that they need to buy new hardware.
  • Sexism and racism still exist. At its best, open source is a meritocracy. At worst, it is a white boy’s club. Go out of your way to not be that guy.

Defending Freedom of Code

I agree that the Ruby community uses the freedom of the Ruby language to great benefit. As the community grows, we are in danger of settling into patterns established by our pundits or the conventions of last year’s gems (which reflect last year’s thinking). Each of us needs to understand the core principles by which we code and practice those, in order to retain our freedoms. I’d like to share some examples that would have worked better (for me) in the keynote, which could have been suitable replacements for what I felt were off-topic metaphors.

One of the points David Hannsson made in his keynote is about the freedom from declaring types. It reminded me of Oliver Steele’s article Test vs. Type — originally referencing JavaScript and Python, but the same principles apply to Ruby. David talked of critics who speak of “enough rope to hang yourself” and asked, rhetorically, if hanging was really the most common use case for rope. Should we focus on preventing one rare use case rather than supporting all of the other useful ways to use rope? Instead of being afraid of what liberty allows, we can provide effective measures to protect ourselves. With Ruby, we do that by having strong technical and social support for testing.

The Ruby test framework explosion in the past few years has been a bit overwhelming to many of us and was at first addressed by blog post tutorials and talks at meetups and conferences. Many Rubyists have also worked hard to support the freedom to use your test framework of preference. Here are some examples:

• Cucumber auto-detects and configures itself based on whether you have webrat or capybara installed
• Rails 3 has plug-in generators so that any test framework can generate its own tests for scaffold, model, etc.
• Rspec lets you configure what mocking library you want to use.

In general, Rubyists value freedom of choice. When we can easily experiment with different frameworks and libraries, we can make well-reasoned decisions without overly valuing the status quo. As software developers, we need to work hard to overcome inertia in order to move forward and continue develop great code year after year. A few more examples:

• Rack: allows us to mix and match web servers
• Rails 3 Routes can be any Rack endpoint, allowing us to mix Rails and Sinatra in the same web app (and potentially other frameworks)

I’d be interested in hearing about other examples of how Rubyists are using the flexibility and freedom that are inherent in the language to create an ecosystem that protects us from the inherent risks, defends those freedoms and promotes programmer happiness and creativity.