The Puerto Rican Rails Dude

Here in New York, I’m working at a start-up company that is a few months away from their initial launch. This is a refreshing change of pace from where I used to work. In my previous job, I was the sole programmer, but not for a company whose main purpose was build software. Now, I’m part of a group of people, where we’re all working together to complete a software project. It’s an interesting experience for now, and I know it’s going to be an awesome experience for me.

As many of you should know, working at a start-up that hasn’t launched yet is hard. Really hard. Trying to build something that hasn’t been done yet will definitely have its setbacks, and there’s a high risk involved in the whole deal. Just a look at TechCrunch’s so-called DeadPool, start-up companies who had to shut down for one reason or another - usually because they didn’t have enough money to finish. Also, since these companies aren’t actually generating any revenue while building their product, most of the times there’s not a whole lot of people working at any given time. That means a ton of work for those involved.

Of course, I’m not saying start-up life is bad. On the contrary, it’s been fun and exciting for me. I’m doing what I want to do for a company that has a great idea that, if all goes smoothly with no major bumps on the road, will enjoy massive amounts of success. And being one of the main persons to actually have constructed part of that success, it means there will definitely be rewards down the road. With this being said, lately I noticed a couple of articles with some people saying some… Well, I’m tempted to say ’stupid things’, but I’m not one to pass judgement, especially to those I don’t know personally.

The first one comes from Mike Mason, a software consultant, who advises start-ups to fire their original development team when the company has a successful launch. Of course, now that I’m part of a dev team who’s with a start-up that hasn’t launched yet, I definitely wouldn’t want to be fired. But this article offers absolutely no valid points whatsoever as to why firing the original people who helped get the company to the “Promised Land” is a good idea. His main gripe is apparently this:

The problem I’ve found when working at startups-turned-enterprises is that the guys who built v1 of that web site are now running the IT department.

Yeah, this is a problem, definitely. But guess what? Who put the developers in charge of running IT? It’s not the developers themselves - it’s management. Why on Earth would a manager put a software developer in an IT role - a main position, at that - if they’re not actually qualified to do the job? In this case, the developer who built the first version of the site should stick around, possibly as the lead developer for newer hires, while they’re making their product better. For IT, hire someone who’s actually qualified for what you want. That way, you have someone who know about your codebase actually working with code, while someone who knows about IT tasks can focus on that. Like the ol’ lightning rod him, Zed Shaw, said in his blog about this post:

If you want to fire someone, it’s management. Fire the assholes who focused on making everyone cram for some shitty demo to moron VCs instead of focusing on the quality of the mother fucking code in the first place.

You just gotta love Zed, even if you don’t agree with him most of the times. If you read Mason’s blog post, he also has some more ‘advice’, like “Hire an expensive consulting company to help you build your systems better, and allow Chief Architect dude to ignore their recommendations” and “The minute you’re successful, plan to rewrite your software from scratch“. I admit I haven’t had years of experience in the software development world, but honestly, it seems like this is just a plain bad idea mentioned by Mike here, and just reeks of being counter-productive to the entire company.

Another article I read that left me wondering what the hell the author of the article was thinking was written by Jason Calacanis, CEO of Mahalo, some human-powered search engine, who wrote some tips on how to save some cash when running a start-up. Most of the ideas sound really good, and I agree with most of them. But there was one item that caused a lot of debate around some other sites. Here’s the original quote, as apparently the author noticed he put his foot in his mouth and edited it to sound “less harsh”:

Fire people who are not workaholics…. come on folks, this is startup life, it’s not a game. go work at the post office or stabucks if you want balance in your life. For realz

Whoa, so if I work for you, you’re going to fire me if I don’t work 12 hours a day, at least six days a week? For realz? Sorry, but I definitely wouldn’t want to EVER work for you, even if you pay me ten times as much as I’m earning now. This idea of being a workaholic is just plain idiotic. Overworking leads to so many problems, it’s not even worth it to mention all of them. Stress, bad productivity, bad decision-making, all of these are caused by people working more than they should.

It’s sad to see that in this day and age, there are still people who view borderline slavery (i.e. making them work way too much) as the only way to be successful. People like these shouldn’t be running companies at all. It’s not about how much you work, it’s how smart you work. David Heinemeier Hansson over at 37Signals’ Signal Vs. Noise blog gives his take on this, and brings up some great points to do, what he says, “Fire the people who are workaholics!”

Of course, after a backlash around the Internet, especially in TechCrunch’s aptly-titled post Calacanis Fires People Who Have A Life, Calacanis back-peddled and wrote a follow-up post where he said didn’t actually mean it that way, and that he meant that the TechCrunch headline should be “Calacanis fires folks who don’t love their work”. This, I can agree with a bit more, but still, the post was just plain back-peddling, even if he doesn’t want to admit it.

Calacanis goes on to ask two questions: “Can you have a life and work at a startup?” and “How do you manage stress?” The first one is easy: Yes, I can. I’m currently working in a start-up, and still have more than enough time to explore New York City, keep in touch with my friends and family, work on personal projects, and even write long, interesting blog posts. The second question, about managing stress, it’s also easy: Don’t be a workaholic. If you work all the time, if work is your life, of course you’re going be stressed. Take some time away from work. Go do whatever relaxes you (please don’t say work relaxes you, you liar). Take one day off, it won’t be the end of the world or your start-up. Come back feeling refreshed and hopefully stress-free.

Working and/or managing a start-up is definitely no easy task. But don’t think that working all the time or firing your original people because they’ll run the rest of the operation to the ground will help. Work smart, keep your good people around and treat them well, and you’ll see that your start-up will be successful. As long as your idea is good and you have the funding, of course!

When I was in Puerto Rico, I started this blog because I thought that virtually all programmers out there had their own blog somewhere in cyberspace (or whatever people call the Internet nowadays). Since I was searching for a job, I thought this would help me get at least on par with others in the job-seeking market. Even though I already have a job, I decided to keep this blog active as a hobby, since I do like writing about anything that interests me.

Currently, the company I work for is looking for more Ruby On Rails developers to help with the development and maintenance of ths site we’re making (note: if you live in New York and are looking for a job using Rails, contact me and I’ll let my employers know about you). It hasn’t been easy, since it seems that seasoned Rails developers - although I don’t consider myself a ’seasoned vet’ - are scarce, probably because they already have jobs elsewhere. But that’s another topic I’ll write about soon.

In my case, my boss asked me to check some sample code from someone out. After checking the code, I was curious to see who the person was, so I searched on the Internet (which I truly implore all employers to do when scouting prospective talent) to see what kind of profile this person had. There were some posts of him asking some questions about Ruby and Rails, a mostly empty profile at Working With Rails, but nothing else. No web site, no blog, nothing. I found it weird that a person with years of professional programming experience has nothing that they regularly maintain.

Sneaky spy that I am, I also checked some previous employees at this company, and to my surprise, none of them had blogs or anything else that they keep up-to-date. It’s really surprising that in this day and age, when blogs, websites and domain names are so cheap (or even free) to acquire and maintain, that they don’t spend a couple of minutes to set something up.

Of course, I’m not saying that you need to set up a blog or website if you’re a programmer. It’s definitely not a requisite. But in an era where your electronic identity is more important than ever, it’s a great thing to have for many reasons. Like I did, you could be job-hunting, or looking for work on the side. Having a place where people can freely go and checking out your work (or your personality - something that’s overlooked a lot) is a bonus. It’s like a pre-screening, but you’ll have the advantage over others who don’t have sites set up. Provided that your site is decent, of course. If I were an employer looking for a web developer, and found that their website was full or animated GIFs, MIDIs and scrolling marquees, I would most likely pass.

I think the primary reason for people not doing this is probably their perceived amount of time they think they need to spend maintaining a blog or website. To be honest, it takes virtually no time at all. My usual blog posts take around 15-20 minutes to write up, since they’re just thoughts that come to my mind during the day, and I take the time to write them up later on. I don’t need to sit down, write a first draft, think how I’m going to write my blog, etc. I just sit down and do it. I also don’t feel the need to update the blog every single day. It’s not about quantity, but about quality. If you can write a kick-ass blog post every two or three weeks, I appreciate it more than reading a deluge of uninteresting blog posts every day.

If you’re a developer who wants to make a name for yourself, either for professional or personal reasons, I really suggest at least creating a blog (it’s not like you have to pay - Blogger and WordPress are two good starting places) and trying to write something from time to time. Not only will prospective employers thank you for it, I believe it’ll also let you grow as a professional.

Well, well, even a week after Zed Shaw’s infamous rant on the Ruby and Rails communities, all the talk generated by it continues. While it has died down enough, I feel that the repercussions of the rant are still going on. And I’ll be writing about one I’ve been disturbingly seen more and more in the past week.

One of Zed’s problems with Dave Thomas was due to his book, Programming Ruby (or “Pickaxe” - weird how some people know that book only by the Pickaxe name). Here’s one of the paragraphs he wrote about that particular book:

That’s right, take a look at the original topics and you’ll see that Dave’s book is nothing but a giant me-too book that seems to appeal to the average OOP coder of 2001. However, the average OOP coder using Java, C++, or C# wasn’t doing much meta-programming then, and what Dave presented was nothing more than a book that said, “Hey look, you can do all the stuff you’re doing now, and make NO money at it.”

He goes on to explain a lot of the shortcomings of the book, like the fact that the chapter about classes was demonstrated by designing some sort of Karaoke jukebox machine. I do agree with these specific points Zed makes. I remember reading the book for the first time, and just skimming the classes chapter because it felt awkward that these very important terms were being explained this way. It was also confusing as well. I just read the basics (how to create classes, inheritance, access control, etc.) and skipped most of it. Also, failing to include one of Ruby’s strong suits (which is the ease of meta-programming in this particular programming language) seems very weird.

However, this isn’t what I wanted to talk about. My issue is that after Zed pointed these things out in his rant, I’ve been seeing a lot of negative comments towards this book - something I hadn’t encountered before. In fact, I bought this book because everywhere I read on the Internet, it specified that this was the book to own on Ruby. In fact, let me show you a screenshot of the current reviews this book has on Amazon.com:

See anything interesting there? Yeah, there are only 52 reviews, but 43 of those reviewers - a whopping 82.6% - gave this book either four or five stars. To me, for a supposedly “shitty” book (as I’ve read a lot of people call this book in the past week), this is a rather high positive rating.

So, are these people honestly criticizing the book by their own will, or simply just want to “follow the leader” and bash Dave’s book without thinking for themselves? I find it extremely odd that a lot of criticism is aimed towards this book in such a short period of time - the past week since Zed’s rant. Were people scared or something of giving their honest take on this book for fear that the Ruby zealots would find out where he/she lived and crucify them or something? Something just doesn’t seem right.

Now, while I’ve expressed before how much I enjoy the work of Dave Thomas and others who publish the Pragmatic Programmers books, do know that I’m not biased in any way, shape or form. I’m probably one of the most objective guys you’ll ever meet. If I think something sucks, I’ll gladly say so, as long as I can back my words up. But honestly, I don’t think the Pickaxe book sucks. Far from it. This book has helped many (myself included) find out about the awesome features of Ruby (well, most of them, at least). To ignore the fact that this book helped jump-start Ruby usage in the in the Western Hemisphere is really a disservice to it.

I think Programming Ruby is an awesome book and an excellent reference to the Ruby language. As a book to learn the language, I wouldn’t count on it to be the “be all to end all” Ruby book. To those who think there are programming books like this, you’re totally wrong. In my short programming career, I’ve come to know that one book for a specific language or technology isn’t enough. Obviously, that doesn’t mean you should buy all the books on a particular topic. But more than one, at most two or three books, should help you greatly. No two authors think alike, and there’s always some stuff missing from one book that another has, and vice versa.

So to all those newly-minted Pickaxe “haters”, I suggest you take an honest look at yourself and think if you’re really hating this book because you didn’t like it. If you didn’t like it from the get-go, good for you. I hope you find another book that helps you learn Ruby. But leave the rest of us who learned a great deal from this book alone. We don’t need a Zed-wannabe running around this joint.

UPDATE: After I posted this, I immediately E-Mailed David Heinemeier Hansson (yes, the creator of Rails), because I was curious on how he learned the Ruby language. I was surprised he responded in mere minutes, and his response was even more surprising:

I learned Ruby in large parts from the original Pickaxe and thought it was a great book. No, it didn't cover everything. And I picked up some metaprogramming tricks form The Ruby Way, especially Chapter 5, as well. But I was very happy to have it at the time.

Seems like David agrees with my thoughts on this subject. I bet that most of the big names in the Ruby world also learned the language from Dave’s book. I thank David for that quick and honest response.