Coding Horror: Code: It's Trivial | Hacker News Reader

Coding Horror: Code: It's Trivial

codinghorror.com

84 pointsAnon8443 comments

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 see a lot of this as well.

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.

I've been in situations where a programmer has asked me for help, I've given it, only to then be told I was wrong and their approach was much better.

> 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.

ktharavaad (http://news.ycombinator.com/user?id=ktharavaad), the user who said he could clone SO in a weekend (http://news.ycombinator.com/item?id=678501), hasn't commented on HN since before the weekend (http://news.ycombinator.com/threads?id=ktharavaad), so I'm guessing he learnt his lesson.

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.

Actually.... If you look carefully enough.

This was posted 5 days ago:

http://news.ycombinator.com/item?id=684343

That being said, yes, I did learn my lessons.

Thanks for keeping me honest!

"The longest program I have ever written was for a CS lab, and I got extra credit for it because I am the awesome."

Did you mean to write "I am the awesome"? Because I swear I heard that same phrase from notable CS kids at CMU.

Isn't that what he wrote?

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.

"central Michigan"

In that context, CMU == Carnegie Mellon University (my guess anyway, since Carnegie Mellon is well known for their CS/CE/EE programs).

> No, I don't take this claim seriously. Not enough to write a response.

Uhhh, isn't the post his response? Just saying.

I believe he meant a direct response to the 'in a weekend' claim itself. Which he doesn't respond to, aside from citing Benjamin Pollack.

The rest of his post is more of what we've had in every thread on the subject: Doing It vs Doing It Well

(edit: sp)

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.

"So assume that you can write all of the code for Stack Overflow in a weekend."

Only if you're a total idiot.

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'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.

People have told me that they check up the references of the surgeon. i.e., surgeon is the most important factor.

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.

That's really interesting! I didn't have any idea Nintendo had assembly lines for refurbishment. Is that a typical refurbishment process?

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.

It's interesting quite how much "defensive" blog content those couple of HN comments sparked off.

Almost any response was guaranteed fairly decent coverage from news.yc.

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?

It could make a great discussion!

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).

Personally, I'd take "I can write that in a weekend" as a compliment. Simplicity takes so much more work than one would think it would.

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.

All this talk about cloning Stack Overflow makes it ripe fodder for the next "make an X in 20 minutes" web framework screencast.

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?

I reached the same conclusion. It just doesn't make any sense. It's as if two different people wrote the entry.

The quote quoted by OP is a quote in a quote.

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.

Code may be trivial, but it's still the critical path.

Even if you do everything else well, your chances of success decrease geometrically with the crappiness of your code. Or...

Success = (A+B+C+...+Z) * SQ^2

where SQ is Software Quality and A thru Z are everything else.

The critical path is getting people to pay (repeatedly) for this thing.

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.

(btw: I don't like it. That was sarcasm.)

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.

[1]: http://code.google.com/p/hackerexchange/

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.

"He didn't back out because he thought it would be too hard. According to him, he backed out because it would be disrespectful."

Excuse my language, but this comment deserves it: I've seen horse-shit with less horse-shit in it.

http://news.ycombinator.com/item?id=684343

Reply on news.ycombinator.com