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).
Plan to throw one away
51–60 of 88 posts
Re: Plan to throw one away
#52I 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).
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
#53Earlier 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.
Re: Plan to throw one away
#54Are Lex and Yacc still the state of the art 20 years later?
Re: Plan to throw one away
#55Re: Plan to throw one away
#56This adage is fairly old, aren't today's programming and management techniques rendering it obsolete?
In other words, no.
Re: Plan to throw one away
#57This adage is fairly old, aren't today's programming and management techniques rendering it obsolete?
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
#58Earlier 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…
Re: Plan to throw one away
#59I 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.
Re: Plan to throw one away
#60Are Lex and Yacc still the state of the art 20 years later?