Live data from Hacker News

Plan to throw one away

garethrees.org

51–60 of 88 posts

Re: Plan to throw one away

#51
post #45

I would like to know how the CTO responded to the idea of throwing away the code he'd been slaving on at the very last minute, and replacing it with something that someone cobbled together in two weeks (but worked).

From the sound of the description the original CTO authored code was cobbled together and its replacement was properly engineered (for some value of properly).

And I'm sure if you said that to the CTO they wouldn't take offence and would react in a rational, measured way. Actually, I've worked with managers that would react OK to that, and ones that definitely wouldn't, but I wouldn't tell any of them their work wasn't "properly engineered". Stick to the objective facts: this version runs much faster (no need to even mention the 'several orders of magnitude' factor unless they really want to know).

Re: Plan to throw one away

#52
post #45

I would like to know how the CTO responded to the idea of throwing away the code he'd been slaving on at the very last minute, and replacing it with something that someone cobbled together in two weeks (but worked).

From the sound of the description the original CTO authored code was cobbled together and its replacement was properly engineered (for some value of properly).

Of course, but from the time invested, it would seem the other way around. It's often painful to accept that you wasted a lot of time and that it's better to start over (which is of course the entire point of the article), and even more so if the new hire has already done that and thrown the CTO's code away.

Ultimately it's a question of ego. Does the CTO welcome the new hire who knows more about this than he does, or does he insist he knows better? Does he feel threatened or slighted?

Re: Plan to throw one away

#53
post #30
post #13

Earlier quoted context omitted.

> javascript in the server wasn't "too soon", it already existed Those two things aren't necessarily in conflict. Netscape's server wasn't exactly a roaring success. What really made Javascript-in-the-server work was a Javascript JIT engine (v8) that actually made Javascript very competitive compared to traditional server side scripting languages. So given that there did not exist a Javascript JIT engine back then, m…

Agree that was probably too soon, even if it existed in some form. I've often wondered why precisely people love JavaScript on the server. I would guess it's a mix of 1) event machine parallelism, 2) isomorphism, 3) speed (since V8/SpiderMonkey/Chakra), 4) cross-compatibility, and 5) engineers not needing to learn another language.

I've always assumed it's heavily weighted towards 5 - never underestimate the ability of a coder to avoid effort!

Re: Plan to throw one away

#54

Are Lex and Yacc still the state of the art 20 years later?

Parser combinators are a better alternative. You end up writing a bit more of the data structure yourself, but the result is code that fundamentally makes sense.

Re: Plan to throw one away

#57
post #55

This adage is fairly old, aren't today's programming and management techniques rendering it obsolete?

If this guy were 'properly' managed he would never be allowed to overhaul this project like he did. Not many managers will be impressed by a "I will build a full compiler that is going to be better than what the CTO built in the next two weeks immediately after which is the deadline" speech, as the author also admits.

If the company was properly managed they also wouldn't have been in a situation where there's only two weeks left and a critical component is in a not well understood state.

In practice though these kinds of things constantly happen in even well managed companies. If the author weren't around they'd probably just have shipped a slow Javascript interpreter that couldn't do prototypes very well.

Just curious, what kind of programming technique renders the idea of this article obsolete?

Re: Plan to throw one away

#58
post #52

Earlier quoted context omitted.

From the sound of the description the original CTO authored code was cobbled together and its replacement was properly engineered (for some value of properly).

Of course, but from the time invested, it would seem the other way around. It's often painful to accept that you wasted a lot of time and that it's better to start over (which is of course the entire point of the article), and even more so if the new hire has already done that and thrown the CTO's code away. Ultimately it's a question of ego. Does the CTO welcome the new hire who knows more about this than he does, o…

This is the "First class people hire first class people, second class people hire third class people" paradigm.

Re: Plan to throw one away

#59

I find the dates a bit suspect (referenced ECMA script standard was June 1997, book was late 1996, so how did this all happen twenty years ago, just months following the official release of JavaScript in May 95?), but guess that's not the point. Maybe I'm alone, but implausible details distract me from an otherwise great story that can teach a lesson many should learn.

For "twenty years", read "once upon a time". I feel that a bit of vagueness in dates is appropriate for a story like this. I have no contemporary written documentation, so it's based on my fallible memory, and I don't want to give a false impression of accuracy.
Post reply on HN