Hacker News Reader

Comment by rewind | Hacker News Reader

"Want to get trained on Ruby at a .NET shop? Implement a one-off project in Ruby. Bam, you are now a professional Ruby programmer — you coded Ruby and you took money for it. (You laugh? I did this at a Java shop. The one-off Ruby project made the company $30,000. My boss was, predictably, quite happy and never even asked what produced the deliverable.)"

Unless an employee actually gets permission to do this, this makes him incredibly selfish, and is a good way to get fired (and deservedly so), no matter how good he is.

View on HN

Technically, the employee would not be fired right away.

He or she, however, would be red flagged for close observation by being put on a Performance Plan.

Basically, a PP is required to legally fire you. For example, if you had a bad record of coming in at a consistent time, they could put you on a PP. In this PP (which you would have to sign as a condition of further employment), there would be a contract for coming in between 9 and 9:15 for the next thirty days, with a small margin of forgiveness. PP are used to document that you have behaved poorly or acted wrongly in the corporate context. Once you are put on a PP, it is a prelude to a firing. You can successfully get out of a PP, but it is stressful.

For the hypothetical Ruby programmer in the Java shop, the PP would probably involve something insidious like LOC.

Basically, a PP is required to legally fire you.

Where are you talking about? Laws vary, even among the states in the USA.

When I mean legally, I mean to protect the company against being sued for firing you. Yes, there are cases where there are immediate terminations. PP assist in the less egregious cases where there is gray areas. In fact, you can argue that the entire point of an HR department is to protect the company from getting sued.

It depends on the state. You can't (successfully) sue a company in Massachusetts (like California) for any reason besides discrimination. They don't need to give a reason why they fire/lay you off. They just fire you and that's how it goes. Not all states are like this.

> You can't (successfully) sue a company in Massachusetts (like California) for any reason besides discrimination.

Being fired while belonging to an Identified Minority is harassment and discrimination unless done according to a documented failure of a Personal Improvement Plan.

In California at least, employment is at-will. You can be fired for any reason (except discriminatory reasons), or even no reason at all.

PPs (and similar shenanigans) are a great way to turn your company into a smoking crater, programmer-wise. Doubly so for relatively insignificant things like not turning up at 9.00am...

Please note, he got to do this working for a boss who "never even asked what produced the deliverable".

This sounds like a very dysfunctional company in the first place.

So here's another reason not to call yourself a programmer: it suggests that you are a peon who needs micromanagement. At Japanese megacorps, which are not historically known for huge degrees of flexibility, it is assumed that Software Engineers should be able to tie their own shoelaces without needing to be told what kind of knot to use.

The boss asked for me to produce comprehensible and comprehensive documentation of 100,000 lines of Perl and gave me a two month deadline. I produced what he asked for in two weeks. The production of this involved a Ruby script.

Contra many sibling comments, delivering a higher quality product earlier than the deadline does not typically result in one getting fired, particularly when one makes a habit of making your boss look like an effing genius for managing you so well.

My take on what you said in the article was that you were encouraging developers to implement software (that was not tied into other software, but that was still used by end users) in a language that they want to learn. From what you said here, it sounds like you mean something you run just for yourself to get your work done, then toss. I thought you were suggesting doing this for actual software that is used internally or by a client, but that had no other dependencies and you could work on by yourself; as in software that may need to be maintained, have bugs that users discover that need to be fixed, etc. If you mean software for your own purposes as a tool to get a project done, but is not used at all once the project is done, and nobody will need to know or care that it existed, then my comment does not apply to that and I'm mistaken on my interpretation of your original meaning. If you mean software that is used more than once internally or by a client and you're writing it in a language that someone has to support that is NOT supported by the company you work for, then my original opinion stands ;-)

Either way, the parent to your comment has no bearing on my original comment or this one. You replied here, so I'm just replying to you.

Assuming he had a green light on the project itself, and it creates value, I don't see why that would be selfish.

Suppose the OP leaves. It's going to be hard for the his former coworkers to maintain the Ruby app.

If the OP did a proper job documenting his work and his former coworkers are competent, it would only be a tiny bit selfish.

And it is not unlikely that there is somebody else looking for an opportunity to put Ruby experience on her resume, and will gladly take on the maintenance. In that case you have created value for your co-workers, too.

$30,000 hard, or minor annoyance hard?

Depends on how competent his coworkers are.

Maybe "one-off" means something different where you're from, but I read it as meaning this wasn't an issue.

A classic mistake people make is assuming that something isn't an issue, when the other party DOES think it is an issue.

If you think the maintainability of a one-off script that's probably already been deleted because its job is done is that crucial, you're simply nuts. If it needs to be maintained, then by definition it is not a one-off.

Hard for them to maintain, or they wouldn't be as inclined to, if it were written in their language du jour?

Ultimately everybody leaves. Does this mean you should never change your language or technology stack?

Do what gets the job done, within reasonable limits. If the expected maintenance is minimal and you can improve your personal capability and/or produce the deliverable faster using a different technology, by all means go for it. I've had to learn languages far more unpleasant than Ruby (VBA, I'm looking right at you!!) in order to maintain programs that no one expected would ever change. That's life!

If management would like easy-to-maintain software, they are free to start prioritizing it.

Maintenance takes a lot more time than the initial implementation. By using a language nobody else knows, you increase the cost for 90% of the project's lifetime to decrease the cost of the initial 10%.

It's selfish if the numbers are such that maintenance ends up costing more than you saved by using your favorite language for the initial implementation. That depends on a lot of things: your co-workers' experience, your coding style, documentation for the language/libraries used that your co-workers aren't familiar with, etc.

For some projects maintainance cost a lot more than initial development. This is kot the case for a large segment of programs though.

Hint: any kind of problem that need only be solved once (or where it is cheaper to write the code again rather than to make it general enough for everybody) can be written however the original developer believes he will create the most value

He said a "one-off" project. Not all projects have such huge maintenance costs.

Reply on news.ycombinator.com