Comment by edw519 | Hacker News Reader

Comment by edw519 | Hacker News Reader

It's extremely difficult to be simultaneously concerned with the end-user experience of whatever it is that you're building and the architecture of the program that delivers that experience. Maybe impossible.

Layperson who's never seen it: "Impossible"

Practitioner who's becoming better: "Extremely difficult"

Expert: "We do this all the time. What's the big deal?"

I think the only way to pull it off is to simply not care about the latter. Write comically straightforward code, as if you just learned to program, and go out of your way avoid wearing any kind of software engineering hat--unless what you really want to be is a software engineer, and not the designer of an experience.

I know that OP meant well, but I think this is about the worst advice I've ever seen here. A little background...

I have reviewed or maintained the code of thousands of other programmers, and I've encountered maybe a couple dozen I'd actually hire and about 5 I'd consider as technical co-founders. What's the biggest difference? Until today, I wasn't sure how to verbalize, but now, I think a good description would be those who appear to take OP's advice and those who know better...

AFAIC, there's is a close correlation between good code and user experience. There's a close correlation between readable code and maintainable code. There's a close correlation between expertise and precision to detail throughout. And perhaps most of all, there's a close correlation between something built properly to stand the test of time and long term user satisfaction.

If you want to learn a hobby, develop a passion, or really dig deep, by all means, follow OP's advice and just code it. Sometimes that's simply the best way to understand what goes on under the hood and learn what's possible once you learn the right way to build things. Once you learn the right way to build things.

But, please, please, please, leave your experiments on your own hard disk where they belong. You may have thought that those bleeding pixels were cool, but your name will be cursed by the poor souls who forever have to maintain your mess.

I disagree with you because in some projects technical correctness is not the first priority. So why should you sacrifice everything in favor of it? In some settings, coding an ad-hoc solution is ugly but better in terms of the constraints (i.e. time, budget) of the project. For example, demos and prototypes.

Also, some programmers don't take satisfaction in writing good code, this article will encourage them to stay in their bad ways, so that's not good. I think this article is good for people who take too much satisfaction in writing good code. Good code is not always an end in itself.

I have reviewed or maintained the code of tens of other programmers and came out with your same conclusion. Writing code like that is acceptable if you know exactly what your users want, and you won't need to build any features on top of it.

"...and you won't need to build any features on top of it."

Right. It seems to me that most coding "best practices" are designed to help you maintain and build on your code. The guy who hacked together the animations would be in a world of hurt if his boss came in and said "we need the pool of blood to empty in case A, and in case B, it needs to be water, and in case C, it needs to be a cuddly bunny instead of a skull. Also the animation speed should vary depending on the time of day." This would be even worse if 6 months had passed since the original code was written.

Suddenly, refactoring for flexibility and clarity would sound really, really smart.

Now, if I'm writing a piece of "throwaway" code - say, a script that I'm going to run once to accomplish something, then never use again - I'd agree with "do what works and don't worry how the code looks." But generally, if your code matters to anyone at all, it will need to be tweaked and maintained.

Most software companies end up having at least one person who prototypes or produces proof of concepts. Some have entire teams that prototype (at the behest of the technical pre-sales guys).

The ability to rapidly prototype ideas is extremely valuable. For many early stage founders, a proof of concept is more valuable than a well engineered core product. The PoC gets them the funding, or the first customers.

For most people who have an idea, the PoC should come first, as suggested by the OP. I will agree that there are very few people that can write a PoC with production worthy code. They are real superstars.

Many engineers will knock together PoC before starting to write the main product. When I start out doing that, it's disposable. You throw it away.

Thanks for this guys. I really need to do a PoC so I can recruit some buddies to my idea.

Just started thinking about all of the "rapid prototyping" environments and languages that I've heard about over 10 years of programming.

There is obviously something to RAD, 4GL, etc. in terms of investigating the problem domain. Sometimes, you have to "just do it" to get clued up.

I generally agree with your argument. Well designed code is the best in the end. It's what I aim for.

But I disagree with the implication that one ever reaches an expert stage where one easily balances the conflicting demands of real world program creation.

I don't think I'm original in claim that programming is inherently hard, even compared to other "difficult" tasks. It's hard because a client would prefer you "take on technical debt" (take short-cuts), it's hard because computer programs are among the largest artifact constructed by humans, it's because of the halting problem and any number of factors.

It's hard.

I just had to get that off my chest, OK?

Agreed, right after that are idiots who model everything they talked about in the meeting as a class. If I see Manager/Employee classes then I know I'm in for a ride of unmaintainable dreck.

> your name will be cursed by the poor souls who forever have to maintain your mess.

That's fine as long as it generated jobs.

Depends where. In the US? poor souls kept getting blamed by management.

IT is expensive says Management.

So they offshore.

Job is gone.

Once industry sang the same song, we're done. No more IT practitioners in the US.

The shift is happening right now and it happens in a similar fashion: nobody feels it yet but suddenly the rug under them is gone one day.

Silicon Valley is an exception. There are always great companies like Apple and Google. And there are those poor startups that try to overwork the so-called "energetic, genius, creative" fresh-grads.

But the turn-over/turn-around rate is very high.

Stick long enough in this industry and we'll start seeing patterns.

This is the broken window fallacy [1]. If the company didn't have to pay developers to maintain bad code, they could invest that money in something more economically useful, like new products.

[1] http://en.wikipedia.org/wiki/Broken_window_fallacy

Unless they went out of business while trying to perfect the code instead of releasing any kind of product.

There is a vast stretch of appropriate solutions between the maintainability hell of "hardcode the coordinates of every pixelchange in your animation" and perfect code.

Absolutely. Let's not fall into false dichotomies here.

Yes, we developers sometimes focus on making the code perfect, beyond the point where there's an actual business case. So we need to be reminded that the code serves the business, not vice versa.

But really. Bad enough code is a liability to the business. You can't add features to make the customers happy, you get bugs you don't understand, it runs really slowly, etc.

The real trick is determining, with an intelligent conversation between developers and business people, what's good enough.

Reply on news.ycombinator.com