That's the weird thing about the coding profession. I'd wager that the vast majority of people here work on solved / "trivial" problems which have established best practices and everything all laid out there for you to find if you bother to look.
And yet we've all encountered so many developers who continually get it wrong.
It's this weird recurring phenomena I've had throughout my career (and I'd wager I'm not alone in this) where I know I'm not an excellent programmer compared to even, say, a random sampling of linux kernel developers _but_ I'm flat out horrified by the incompetence of my peers who seem to find the most asinine solutions to these trivial and well-known problems.
> I put it down to the fact that a lot of programmers take exception at being given advice on how to do things and hence they learn the hard way.
Agreed, but on the other hand, I've noticed that from time to time the initial reaction is being annoyed, and then, after a while, they start to adopt what you told them. The initial reaction probably is an ego-thing, but after some private contemplation, they see things more rationally.
I'm no exception to this, BTW. I too have found things that I've done for years that in hindsight seemed stupid after somebody pointed them out. And yes, I got defensive and annoyed about it. Human nature, I suppose.
I really hope nobody with any industry experience thought SO could be cloned in a weekend. That notion screams "The longest program I have ever written was for a CS lab, and I got extra credit for it because I am the awesome."
But, hypothetically supposing that it had been cloned in a weekend, then you'd be staring at the 90% of a software business which does not happen in an IDE. My app can be cloned in a weekend. It has been before, by someone who was PO'ed at me and wanted to drive me out of business. He did a pretty good job in his weekend, too -- I think the user experience of the app was probably better than I managed for 1.0, which took me a week and change.
But the other 90%, yeah, that has taken me about 3 years and a week now. It has had a lot of mental effort, sweat equity, and failing-my-way-forward invested in it. And the business, as distinct from the app, is fairly resistant to cloning.
Somewhere out there, in the forgotten corners of the Internet where not even Googlebot dares to tread, the earstwhile weekend app is probably still wondering what went wrong.
That said, I think people are making too big a deal out of this. Even the best of us occasionally end up shooting comments from the hip without thinking about them first.
I have industry experience and I'm rooting for ktharavaad. An existing site in an exact spec, and when you have an exact spec, it makes everything much easier. Next, there's Pareto's Law which means that, yes, if ktharavaad is a rock star, he can do 80% in a full weekend. And then 10% more the following week. Then 5% more the following two weeks.
The code is trivial. It's really understanding what you're up against and the architecture that will get you there that's hard.
The voice I was going for was "immature but net-savvy". I live in central Japan rather than central Michigan so I would put the common word choice down to global cultural diffusion aided by the Internet rather than desire to mock any individual person, particularly anybody you know.
No. He starts off by conceding the point, basically. The title is "Code: It's Trivial." So assume that you can write all of the code for Stack Overflow in a weekend. He lists 13 things that his team spends time on that are not writing code (at least not in the sense of adding new features or fixing already reported bugs).
His point is that writing code is a relatively small part of even a software business. An important part, but no more important than many other things that must be done for a business to succeed.
Consider how destructive this kind of attitude is toward the programming profession. By trivializing any project, a programmer is by extension making it seem like programming is easier, and cheaper, than it really is. What starts out as an ego-pumping "hey, I'm smarter than THAT person." turns into a devaluation of the work we all do, all to fulfill some desire for acceptance among non-technical peers. You wouldn't pick the brain surgeon that told you he could get the job done in a fraction of the time his colleagues could muster.
I once worked a summer job at Nintendo in Redmond, screwing together refurbished Super Nintendos. One day, the Big Bosses came down and toured the GameBoy line, and they had a kid do a demo using this new "hand you screws" machine so they could see how much it increased productivity.
He rolled up his sleves, took a deep breath, and screwed cases on something like 16 machines in the span of a minute (normal production is about 4). Only afterwards did the ramifications of what he'd just done start to sink in.
Glad I wasn't on that line. Extra glad I wasn't that guy. Lesson learned.
It was actually a pretty cool little assembly line. At one end were pallattes of SNES's that had come in for service. They'd get dropped onto the belt and dissassembled completely by the first 10 or so people, then the individual parts would be tested as they moved along the line. Good parts were collected in bins and eventually moved down the line to assembly stations. Bad parts, stickered lids, and cockroaches would be allowed to roll down the belt and eventually off the end.
Once the pieces were collected, the machines would be re-assembled from scratch as they moved down the line. Some jobs, like screwing on the razor-sharp "tins" were terrible. Routing wires and screwing on lids was OK. My second summer there, I got the prime job on the line: Testing.
My job for the entire summer was to essentially play the first level of Super Mario all day, every day, on every machine that came past. That, plus some simple control tests, plus 8 hours of sitting on a rack running the intro demo of Zelda was enough to verify that a machine was good. Every once in a while the line would stop for whatever reason and I'd keep on "testing" away. I got REALLY good at Super Mario that summer.
I'd argue that brain surgery is even _more_ an example of where the ability to cut, suture, and otherwise tweak the brain is less than 1% of what makes you chose a particular brain surgeon to go messing around inside your noggin. I'm betting that the brand name of the Hospital, the quality of they operating environment, the Insurance Coverage, The Cost - these turn out to be even more important than the actual skill of the brain surgeon.
True. I was actually looking forward to see the guy attempt the "clone". For all the meta discussion about what exactly "clone" completely entails simply the idea of trying to roll out something along the same lines in a weekend is intriguing.
Could it be done? How would it go down? Would working processes change? Is there stuff to learn about the development process that speed highlights?
I recently read Paul Bucheit's chapter in Founders at Work. I believe AdSense and Gmail were ideas he knocked out in an evening or otherwise in addition to his regular duties. They were not products at that point, of course. But there was enough there that, instead of theoretically defending the idea that the ideas could work in principle, he simply demonstrated them working in reality. No one could argue, then, that those ideas were impractical, and that laid the groundwork for making them into real products.
I think those are good examples of "do it in a weekend" type projects. Prove something can be done, before worrying about making a real product out of it.
(Of course, having all of Google's infrastructure at your disposal is nice for implementing some ideas in a weekend or less. We do have AppEngine, though.)
I know many of my better ideas have been done over a weekend or afterhours for a week. The thing is that when its not a "complete project" these things are very easy to bang out. It's the next 6 months where the polish gets added. (side rant: and over those 6 months the frontend guys get all the oohs, ahhs, and credit, despite your having done the core work).
Jeff's conclusion reminded of an adage I read recently about creative work (pardon me for paraphrasing and savagely butchering the author's idea -- I can't seem to find the source now): "Creative work of high quality is not the end. The real work stars once you're done with your work, for making people interested and know about it is as important as your creation itself." In other words, the real work starts once you're done coding.
I would be interested in a web framework that included OpenID login/session management, voting (with several "hot"/"new"/"fabulous" ranking algorithms), user reporting, content tagging and fulltext search, threaded comments, a moderator (not admin) interface, and all of those other things the original response post mentioned as "the stuff you forget about."
I do believe there's some way to stuff all that in without creating a central business-object model (i.e. turning the framework into a CMS.)
From "Open source software only comes in one edition: awesome" to "Open-source software remains such a horrible pain in the ass to use".
How long did it take? Five days?
But they're both true, aren't they? With open source software, it's all there for you to see and use, in all its awesomeness. No pure-marketing limitations. Yet despite that advantage, it doesn't always rise over paid competitors because it's often such a pain to use.
The two opinions are not necessarily mutually exclusive.
You missed the point? He wasn't claiming that open source software is universally awesome, he was saying it's awesome that it doesn't get split into home/premium/business/pro/basic/enterprise/ultimate/etc. editions.
It's always "awesome" edition - you get every part of it.
(Although, I'm not sure I agree - there is price and licensing segregation with commercial Open Source software).
I don't see this as a criticism of the HN comments at all, but as just an excuse to restate that a business (or even just a product) is much more than code.
That said, there can be some competitive advantage due to code, and businesses and products vary in how important the code is. eg Google's pagerank was important (perhaps all important algorithms are only valuable if they are patented... because otherwise they just aren't that hard to copy). For a web2.0 site like SO, I think the code itself is fairly minor, and even the user experience (UI layout, interactions and features), though much more work, is also not that hard to copy. But to copy the business is hard.
The most important competitive advantages for SO are network effects (and potential for further growth); and that people are continuously working on it to improve it.
EDIT this makes me realize why an academic at uni doubted how much of google's success was due to the algorithm - I now think he was reacting to people in that environment who tend to give too much emphasis to code and to algorithms. In my view, it's clear that a better way of doing things (such as a new algorithm) can be the basis of a product or business. Of course it can. But it's not enough on its own.
I like that a lot of the community took the exact same stance that we continually whine about.
Can't you just add feature XYZ to our website?
Can't you just make the buttons cornflower blue?
We (myself included) have become our own worst nightmare :( I am guilty of it too. I wrote a comment a while ago arguing that SO COULD probably be written in a few days.
We've already seen a partial mea culpa from the original author of the comment. His project[1] now suggests StackOverflow can be cloned in "over the course of the[sic] weekends", instead of, you know, already being finished.
Wrong. That was a simple typo he made when he first set up the site, when he was still planning to write in over the weekend.
He didn't back out because he thought it would be too hard. According to him, he backed out because it would be disrespectful.
IMO, if he still thinks he can do it, he should do it and make everyone who is putting him down shut up. And if he fails, so what? At least he will learn a lot.
And yet we've all encountered so many developers who continually get it wrong.
It's this weird recurring phenomena I've had throughout my career (and I'd wager I'm not alone in this) where I know I'm not an excellent programmer compared to even, say, a random sampling of linux kernel developers _but_ I'm flat out horrified by the incompetence of my peers who seem to find the most asinine solutions to these trivial and well-known problems.