Official Blog of Dennis Martinez

Well, it’s been a lot of hard work over the last couple of months (which can explain my absence on this blog), but myself and the company I’m working for finally launched the Beta version of our site on the Internet! The is BarterQuest, and it’s a really great trading site. Okay, so I might be slightly biased, as I spent the last five and a half months working on this. But really, BarterQuest is a trading site like no other I’ve seen around, which really got me excited to come work here in the first place.

We built some cool features to make the entire trading experience fun and much different from the other sites that have similar functionality:

• We have a home-grown Matching Engine, which takes all items that users have and want, and generates trading offers for you automatically, so you don’t need to be spending time browsing all over the site looking for stuff you want.
• You not only can trade with one person, you’ll also be able to trade with multiple people. For example, User #1 has something User #2 wants, but User #2 doesn’t have anything User #1 wants. But don’t fret! User #3 has exactly what User #1 wants, and wants what User #2 has. So our system sets up a trade between all three individuals - each user getting what they wanted. Pretty neat, if I say so myself.
• While we can only trade Goods for the time being, we will soon add trading for Services and Real Estate as well. Have a beach house you won’t be using for the month of August? Trade that lost time with someone who offers Home Repair services! This will open new ways of trading like you never imagined before.

This is only the beginning, but I’m real excited for what’s to come. You can go visit and register right now! During this Beta Testing period, all trading activity on the site is totally free. Not only that, if you complete a successful trade during the Beta Testing period, you’ll be able to use our site free for an entire year! Really, it’s a win-win situation, so what are you waiting for?

I posted this story on a non-technical message board I frequently visit, as a service for some of the users there who might not have a clue on how easy it is to retrieve data from a supposedly-formatted drive. I decided to pass it along here as well. I think privacy is very important, and with the proliferation of electronic devices that store data, it’s getting easier to retrieve information from others.

Here’s a story of some dumb-ass kids who recorded themselves smoking weed on a digital camcorder, returned the camcorder to the store, forgot to erase their tapings (most likely due to said kids smoking weed previously) and the next person who bought the open-box camera from the story posted the videos all over the Internet for all the world to see:

Remember to delete your stuff from electronic equipment if you’re returning it, selling it or giving it away. And even then, be wary of it.

I was once sold a USB flash drive from a friend, and although my buddy deleted the contents, I was able to see what he had their previously before with a freely-available program off the Internet (don’t remember exactly which one right now), out of curiosity. Dude had some… let’s say ‘interesting’ pics of his then-girlfriend.

His way of deleting the contents was to simply do a quick format on the drive from his Windows machine before giving it to me. To avoid all the technical details, for those who don’t know, what this does is simply destroy the FAT table and/or boot sector, which is a sort of ‘table of contents’ for the drive, thus nothing appears when you try to access the drive. But the data is still in the drive’s sectors, and unless you rewrite those sectors (either by copying something new in the flash drive or using some software, which I’ll get to in a minute), they’re easily accessible.

The program I’ve used for a while with Windows is called Eraser (I carry a portable version of this program on my USB drive, called Eraser Portable), which makes sure your data is clear from your portable device (like flash drives, SD cards for digital cameras, even iPods). In short, what this does is over-write the sectors on the drive multiple times with ‘garbage’, so it’ll be virtually impossible to get that information from freely-available tools. I’m guessing the government has more advanced tools, so for the overtly paranoid, you’d be better off just smashing the drive to pieces and dipping them in a vat of acid.

Just wanted to pass this info along so you people can keep your privacy, and know how easy it is to grab a hold of your data.

This is obviously not my first time that I have shilled the PeepCode website. I truly think that for any Rails developer, this is one of the most invaluable tools for learning available anywhere. I’ve purchased many of their screencasts already, and once I get the opportunity, I’ll even spring for their PeepCode Unlimited subscription. I know I will fully get my money’s worth.

If you haven’t been following what they have been doing recently, they have also added PDF books to the mix. These books provide a lot of wealth, just like their screencasts, but only in text form, perfect for printing or, for the environmentally-conscious of you, just keeping in your flash drive and reading it whenever you need it. I just recently purchased two of their PDF books: Git Internals and ActiveMerchant.

I purchased the Git Internals book to satisfy my own curiosity. As many of you should know by now, Git is a distributed version control system (a la Subversion) that’s taking the software development world by storm. I’m slowly getting into Git, thanks to a PeepCode screencast on the basics of Git, and even decided to pay for an account on GitHub (which I will write about in the near future). But I’m usually not content to just know how to get my work done. I like exploring beyond that, knowing how it actually works in the inside. Most of the times, I fully understand its strengths (and weaknesses - nothing is perfect!), making me more efficient. This PDF book does exactly that. If you’re a curious being, and are using (or planning to use) Git, I wholly recommend this book.

The ActiveMerchant book, I actually bought out of necessity. The web application I’m working on has the ActiveMerchant Plugin installed, and some work with that plugin done. However, since the developers who implemented those features aren’t working for the company anymore, and some core functionality has changed since I’ve arrived, it needs to be changed. I didn’t want to start from scratch, so I bought this PDF book to see what should be the “right way” (as per the author, who undoubtedly has tons more experience with the plugin as I have). I really got into this book, because it’s really, really easy to understand (thanks to the plugin actually being easy to implement) and it explains everything you need to know about the entire payment process. This is a must-read for anyone who’s building Rails applications where money needs to get to you.

The guys over at PeepCode are doing an excellent job, so why don’t you head over to their site and check them out? If you’re a web developer, particularly using Ruby and Rails, you’ll definitely find something interesting, or even necessary.

If there’s one positive thing I can take out of having to ride the subway to work for one hour each way every single day, it’s that I’ve been able to catch up on a lot of reading. I love to read a whole lot, particularly about technology. So lately I’ve been able to finish a couple of books I had around, plus I’ve been able to afford more books to read, so I’ve been buying more. While I haven’t read a library’s worth of books, I think I’ve read more than the average software developer has read. I would go into a long discussion about that fact, but maybe another day.

With a myriad of books out there, it’s difficult to know which ones to read. I first got inspired by Jeff Atwood’s Recommended Reading For Developers list. Since then I’ve purchased and read many of the books Jeff recommends, which are still pretty relevant and really good reads.

So I decided to dedicate some time to write some mini-reviews about the books I’ve read, in case someone wants an honest opinion on them from my perspective. I’ve already written about a couple of books before (like the upcoming Advanced Rails Recipes book, and my not-so-popular opinion about The Pickaxe Book), so I hope to expand on that.

Also, I added a nifty text widget on my sidebar which I will update constantly on which books I’m currently reading and into, with a link to Amazon (no referral link!) for more information. I hope you all find it interesting to see where I’m focusing now.

Any suggestions on recommended reading for a software developer like me? While I like programming-specific books, I would really like to get into more books that focus not on one single piece of technology, but as a whole. Any recommendations will definitely be appreciated.

When I left my previous job to come to New York City, I made sure to clean up as much as possible, leave as much documented as possible, and clear up things with those who would be replacing my normal duties. I not only did this because it’s the professional thing to do, I also didn’t want to screw over my former bosses, much less my co-workers, since I did want to be able to maintain my friendship with many of them. Many times I saw people leave abruptly, which led to slight disorganization among the ranks for a while.

Since I only had one week to do this before I finished my non-work duties (moving, packing, saying goodbyes, etc.), and let’s face it, my mind wasn’t at my current job at the time due to the excitement of going to New York, there was bound to be something missing. So I kept the doors open with my former bosses and co-workers, assuring them that if they needed anything that I could help them with, to let me know so I can try to help them any way possible.

While I haven’t been called a lot by my former co-workers, I still get calls from time to time from them asking how to do a certain thing, or clearing up something I didn’t explain too well before I left. I also received an E-Mail from my former boss, asking if I could do some maintenance programming tasks. I has accepted, but since they didn’t answer me back in time if they accepted my terms (or rather, how much I would charge them for my time spent on this), I moved on to other projects and had to decline.

Now, I don’t mind helping out my friends as much as I can. But the problem is that a lot of the times I can’t help for whatever reason. Maybe it’s due to me having much work now like the aforementioned projects getting in the way, or I because I simply don’t remember well something in particular. Whenever this happens, I feel like I’m letting others down. Chalk that up to the way I am. Whether it’s a blessing or a curse, I’m still not sure yet.

Not to sound evil or anything, but although I want to help, I’m not under any obligation to do so anymore. I also think about it this way: When I arrived there, I had absolutely no help at all from the previous person doing the tasks I did, because that person wasn’t there anymore (from what I heard, he left abruptly on bad terms with the company). So I had to do things on my own. There were things I had to ask about, of course. But most of the things I had to learn for myself, like the programming, what type of servers / active scripts running, etc. This wasn’t by choice, it’s because there was no documentation left behind, and the bosses had no clue what the other person did.

So I question myself, where does the ‘professionalism’ end? Should it have ended once I collected my final paycheck and walked out the door? Or is it fair to have a short ‘grace period’? It puts me in a difficult position a lot of the times. I don’t want to let my former co-workers (or at least the good ones) down during their times of need, but I don’t want to be a crutch for them for too long. I think it’s time for them to start rehab and start walking on their own again soon.

When I arrived at my current job, most of the functionality from the Rails application I’m working on was already done by developers before me. There were still some loose ends to tighten, but almost everything was ‘working’. I say ‘working’ in between single quotes, because while the application was certainly working, it really only worked if everything was done in a seemingly exact pattern. Do something different from the pattern, and something will break. Like “Click here and fill in this, in this exact order, and put your cursor there, or the app will give an error.”

I understand why this was done this way. I usually code this way too: after deciding what I’m going to do, I whip up a very crude version of what I want to do, then I take care of some loose ends that could be made better. But there are some things I do along the way to avoid having too many loose ends when I finish writing my basic functionality.

Most of us have heard the phrase “premature optimization is the root of all evil” by Donald Knuth. While this is true, I believe that we should think from the beginning about optimization before writing code. Your algorithm or pseudocode should be as optimized as possible from the start to avoid these things. If you think through your problem well enough, too much optimization won’t be needed.

With web development and frameworks such as Ruby On Rails, it’s easy to forget these things. A lot of the times people just sit in front of their computers and code away, hacking up whatever’s on their mind without thinking it through. I admit I’ve been guilty of this behavior before. But with age comes experience, and I’ve learned a lot since then.

Anyway, back to my current code. Apparently the developers working on it before just sat down and wrote a lot of code without thinking about such basic things, like error-handling. It’s not like they didn’t have time to do it. My workplace isn’t a stressful place, my bosses are way nice, and while we do have deadlines, it’s not like we have someone on our backs constantly nagging that we have impending deadlines. Since those original developers don’t work here anymore, I can’t ask them why they coded like this, so I have to just deal with it the best that I can.

I created a document in our company’s Wiki with some coding tips that came off the top of my mind, so that hopefully any new hires can read it and follow them. Even if they know these things, it should serve as a reminder to follow these basic guidelines. By no means it’s a complete document, but these are the most common mistakes I’ve encountered.

Always handle errors gracefully

Try to never show the user an error page. If something went wrong, show a message letting the user know what went wrong, preferibly a `flash[:notice]` or `flash[:error]` message, which will appear at the top of the page, and send them somewhere where they can either try again or get more information.

Bad Example (If the item for some reason doesn’t exist, or a curious user changes the ID in the URL, it will show an not-so-helpful error page):

def offer_for_want
  @have_item = HaveItem.find(params[:id])
end

Good Example:

def offer_for_want
  begin
    @have_item = HaveItem.find(params[:id])
  rescue ActiveRecord::RecordNotFound
    flash[:error] = “Some error”
    redirect_to :somewhere
  end
end

Use descriptive variables

Although using shorter variables keeps the functionality the same as using longer variable names, using descriptive variable names and conventions will help other developers understand how an action or function works more easily. Also, using normal Ruby and Rails variable naming conventions helps others get up to speed on the scope of the variable.

Bad Example (Notice the use of two- and three-letter variables, which are not descriptive to a developer who’s just working on this portion of the code):

def update_relationship(hi, wi, opt, modify_opt = nil)
  _have_want = {}
  _have_want['HaveId'] = hi
  _have_want['WantId'] = wi
  _have_want['Delete_add'] = opt
  [...]
end

Good Example:

def update_relationship(have_item, want_item, update_type, modify_option = nil)
  have_want_hash = {}
  have_want_hash['HaveId'] = have_item
  have_want_hash['WantId'] = want_item
  have_want_hash['Delete_add'] = update_type
  [...]
end

Comment your code!

All controller actions and model functions should be commented before the action or function, giving a brief description on how it works. Also, if the code is not self-explanatory or is done in a non-conventional way, a brief explanation should be included as well to let other developers know why the code was written that way, or how it works. This will also be useful for generating code documentation with RDoc

Bad Example (No comments anywhere):

def rate( _user )
  @current_user = _user

  transaction do
    user_tv = view_for(_user)
    user_tv.next_step = View::CF[:next_step][:nothing]
    user_tv.status_for_user = View::CF[:status_for_user][:nothing]
    user_tv.rated = true
    user_tv.save!
    self.rate!
    self.reload
    return ended?
  end
end

Good Example:

# Action to rate a user after an action has been accepted, completed and shipped.
# Only the people involved in the action are permitted to rate each other.
def rate(_user)
  @current_user = _user
  # Reloading the object attributes from the database, in case something was changed during the rating process.
  self.reload

  transaction do
    user_tv = view_for(_user)
    # Sets the next step of the action to 'nothing' for both users involved,
    # indicating that the entire process is complete.
    user_tv.next_step = View::CF[:next_step][:nothing]
    user_tv.status_for_user = View::CF[:status_for_user][:nothing]
    # Set a flag to mark the user’s action as rated, so that multiple feedback can’t be given
    user_tv.rated = true
    user_tv.save!
    self.rate!
    self.reload
    return ended?
  end
end

Properly substitute variables from MySQL queries for security purposes

Any query to the database where the user can enter the parameters (for example, a user enters terms in a search field) can potentially allow a malicious user to run a harmful query against the database, like dropping tables. These user-entered parameters need to be protected from these types of problems.

Bad Example (In this example, a user can enter something like ; DROP TABLE users as their search parameters, deleting the users table):

@item = HaveItem.find(:all, :conditions => "title = #{params[:search]}”)

Good Examples (All of these samples do the same thing, except Rails sanitizes the parameters to make sure no arbitrary SQL code is run):

@item = HaveItem.find_by_title(params[:search])

@item = HaveItem.find(:all, :conditions => [:title => params[:search]])

@item = HaveItem.find(:all, :conditions => ["title = ?", params[:search]])

Sanitize any user input before rendering it in the view

Anything the user enters should be treated as potentially hazardous. Any unsanitized output can be vulnerable to Cross-Site Scripting. Any fields in the view that show information entered by a user should be sanitized. It’s as simple as adding the h function before the string.

Bad Example (Anything the user enters in the database, when shown later in a view, can execute arbitrary code):

<%= @item.description %>

Good Example:

<%= h @item.description %>

Keep presentation and business logic separate

Thanks to the MVC paradigm, Rails makes it easy for any new developer to get find presentation code or business logic, but only if they’re stored in the correct places. Any business logic (such as declaring variables, conditionals, etc.) should be kept in the controller or model and not inside the views. Likewise, all presentation code (such as rendering page updates via AJAX) should be done in either regular view files or RJS templates, not in the controller.

Bad Example (Variables being declared inside the view):

<% result ||= match_result %>
<% size ||= :small %>
<% match = HaveItem.find(result.incoming_item) %>


    [...]
  

Good Examples (In both cases, this leaves the view with just HTML and some Ruby/Rails code inside):

Declare the variables in the controller action instead of the view

def action
  @result = Engine.results
  @match = HaveItem.find(@result.incoming_item)
  [...]
end

In case the view is a partial, declare the variables when calling the partial

<%= render :partial "match_results", :locals { :result => @result, :match => @match } %>

Of course, I’m not an expert on these things. Most of them are probably common sense to most people, but you’d be surprised how often these mistakes are actually made. I’m sure you all have seen these, or probably worse. Does anyone have any other tips that can be added? Feel free to leave a comment.

In the past couple of weeks, I’ve gotten incredibly addicted to Twitter, the micro-blogging, social-networking, chatting, or whatever you want to call it tool that’s been a huge hit in the past year or so. I had my account for a while, but never did anything with it. Recently I’ve just started following people and it’s just plain fun to see what these people are doing most of the time. I’m connected all the time now, so feel free to follow me! If you still don’t know what Twitter is, see a pretty cool video called Twitter in Plain English.

Well, I’m not here to talk about Twitter, although I’ve gone on and talked a fair bit about it. This post does have something to do with Twitter. I’ve been following a lot of people from the Rails community on Twitter (Geoffrey Grosenbach, Obie Fernandez, Dave Thomas, Jamis Buck and Rick Olson, among others). Some of the things they say are funny as hell (such as Obie’s “Po-po made me pour out my beer “), but for the most part they’re interesting stuff from these people. Most recently what I noticed is all the stuff these people actually do. They travel a whole lot, they meet a lot of interesting people and work on a ton of cool stuff.

My first thought when reading these comments are “Damn, these people are lucky to be doing all this stuff.” But in reality, I think they didn’t get lucky all of a sudden. Well, probably they had a little luck, but nonetheless it’s not pure luck. It seems like these people actually worked hard to get where they are now, and are probably still working hard to keep it going.

I always wondered why I couldn’t be the one working on awesome stuff, traveling to cool conferences and all that jazz. But making an honest assessment of myself, I definitely don’t work hard enough to earn these things. And it’s disappointing, because I know that if I put more effort into what I currently do now, I can achieve these things as well. Instead of picking up my Nintendo DS and playing The Legend Of Zelda: Phantom Hourglass for one or two hours straight, I could be starting formulating plans for some interesting ideas and projects I have in my mind. Instead of being on IM and chatting about non-significant things with people I don’t know in real life, I could be reading a book that will expand my knowledge. Instead of checking my RSS feeds every 20-30 minutes (like I obsessively do sometimes for no apparent reason), I could be helping with an open source project.

These are just a few of the things I can tweak to make more time for these things. I’m seriously going to try to change these things, even if it means less sleep and less playing Zelda - although I can’t promise anything when I get my Playstation 2 and Guitar Hero games sent from Puerto Rico, those games are more addicting than heroin. Anyway, I really want to start putting an honest effort to get myself more known out there, to do lots of things that other people will use, and to just help in any way possible those things I enjoy the most.

If you think like I thought before, it’s time to take a good look at yourself and see if the problem is that you’re truly unlucky, or if the problem lies simply in yourself.

For some reason, I wasn’t too much into podcasts until recently, when long trips in the subway made me find something constructive to do while traveling to work. So I’ve been downloading a ton of podcasts that have been out there for a while now. My favorite has to be Ask A Ninja - it’s just hilarious. But as far as tech podcasts go, the Ruby On Rails Podcast is one I’ve been going way back to download and listen as many as I can.

One particular podcast (or rather, two podcasts which were from the same interview, just split in two) that caught my attention was a roundtable discussion about women in development (Part 1 / Part 2).

I found this discussion interesting, as I have to admit I haven’t encountered that many female developers myself. During my university days, I probably saw less than 10 different females taking Computer Science courses during my nearly five years there. Half of those were in the introductory programming courses, from which they rapidly switched their major when they realized they didn’t like it. The other half stuck around, but most of them didn’t seem to enjoy it much. It could probably be due to the fact that they were female.

No, I’m not saying that because they’re women, they immediately shun all types of advanced technology or science courses. I say this because in one course, I was paired with a female student for a class project. At the end of the project, while at the library finishing up on some details, she said she was surprised during this project with me, When I asked why, she said that in every Computer Science class, in every single project she’s been teamed up with boys, the guys either dumbed down what was given to her to work on, or she would be constantly be getting hit on. This was the first time someone from the opposite sex seemingly treated her as an equal, which I did.

This is a sad truth in those academic fields where men outnumber women greatly. They’re either perceived to be dumb, or simply viewed as a potential mate. And I honestly never viewed one of these girls who took classes with me like this. Okay, maybe once I took a liking to one girl, but I still would’ve liked her no matter which major she was, so I feel like I’m clear of all charges against me. I’m not sure if this has to do with the extremely-low number of Computer Science students who are female, but I’m suspecting this has something to do with it.

Trying to put myself in their shoes, I’m sure it’s difficult to deal with these things when all you want to do is just learn and be a software developer like any other. Still, I find it somewhat odd that the women need to start off groups like DevChix and PHPWomen. It’s cool to see enough females get together and form these groups and get recognized for it. But I think these groups just label them as a different breed of developer, instead of just trying to get themselves being viewed as equals. Or maybe these groups are really necessary to combat all the obstacles I mentioned that women in this field encounter. It doesn’t seem like there’s an easy way for this behavior to end.

In any case, I’m all for the females getting their voices heard, showing the world what I have known all along: women are awesome developers. Their genetics don’t have a damn thing to do with their abilities, so stop viewing them as “that programmer chick”.

I just read a post by Joan Planas Illas titled “Be proficient in one programming language“. In this post, Joan gives some advice that developers should stick to one programming language, get really good at it, and make a career out of it. He does offer some good points, such as software development not being just about learning programming languages, and how employers actually prefer if a prospective employee is well-versed in the programming language they’re looking for.

But for me, those who follow the advice of just mastering one programming language are usually day-coders: those who only think about software development from 9 to 5, nothing else. Don’t get me wrong, I’m sure there are a lot of day-coders who are awesome at what they do. But usually these people don’t have much passion for what they do. They’re happy being in their own groove, not expanding their knowledge, and just do their job because it pays well and nothing more. These are probably the worst types of software developers any company can hire. No passion almost always leads to a sloppy job.

But the best software developers I’ve seen show an insatiable amount of curiosity to learn every single thing out there. Of course, it’s not possible. While I don’t have any sort of scientific proof to back me up on this claim, I’m fairly sure there’s a direct correlation between how effective a programmer is with what they’ve learned. A person who reads and stays up to date with different programming languages will have a broader vision on how to get things done. A person who only knows one thing will most likely know only how to solve problems the way their language does. Sadly, a lot of programming languages have their own conventions on doing things their way, which sometimes isn’t the right way to do. These bad habits are then embedded to the developers, who are unfortunately ignorant to recognize there are better ways of solving a problem.

I have yet to meet or read about a kick-ass or famous software developer (well, at least famous in my mind and geeks around the world) who is an expert with just one programming language. Martin Fowler didn’t just stick with C. Yukihiro Matsumoto didn’t stay with C++. Zed Shaw definitely didn’t ‘get married’ with Ruby. These are just a few examples. But just think of any well-known software developer, and one common trait they’ll have is that they at least have experimented with many programming languages, and I’m sure that helped them be as knowledgeable as they have been.

So if you have the time, get to know a programming language of your choosing, preferably one that interests you and not one that all the ‘cool kids’ are using so you need to learn it too. Once you get a firm grasp of that language - not master the language, there’s a huge difference - take the time to learn a new one. For example, if you know Ruby pretty well, get into Python. They both are similar, yet have different ways of doing things. Just don’t choose Ruby and stick with that for the rest of your life. You’ll earn no real benefit at all, and when the next big thing comes along, you’ll be get left behind. Unless you’re happy with that, day-coder.

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!