2 ms·

I think I was pretty plain. Designers suck at code. Coders suck at design. That use case is the "we should only have to pay one guy and he should know everyth

by Gratsby 11y ago

I think I was pretty plain. Designers suck at code. Coders suck at design. That use case is the "we should only have to pay one guy and he should know everything" use case. Or the "I have an idea for an app. I'm a company now." use case. Know why so many bootstrap sites look pretty much exactly the same? --- If someone wants to change the color of the header on a website, should it require a code change? If there's a table that someone wants to change the border on, should that require a person who knows three languages? Or should that require a guy who read an html book last week? Conversely, what if there's a bug report about an element that is not displaying on a Nook Color? Should that require a developer to look at? Or wouldn't his time be better used working on an actual programming problem? --- I interviewed a developer recently and asked him about a particularly difficult challenge that he worked his way through. Usually people respond with a problem that manifested itself in multiple ways or tracking down an important bug in a widely used library. This particular answer was about an errant price change on a major retail web site that took 6 days to implement. A price change should be a zero down time absolutely no-brainer data change. But some idiot along the way decided that he should embed html AND javascript in his java class and it took a team of people several days to track down where exactly the error was that produced the errant price. There's stupid code like that all over the place. With experience, you learn that you can avoid those kinds of problems completely with very little overhead early on.

userbinator 11y ago
But some idiot along the way decided that he should embed html AND javascript in his java class and it took a team of people several days to track down where exactly the error was that produced the errant price. A team of people, several days, and no one thought to just grep the codebase to find the relevant pieces? If that "idiot" didn't conveniently put the pieces all in one place, maybe it would've taken even longer to find? I wouldn't blame that on being "stupid code"...
- Gratsby 11y ago
  I had a little trouble with this one myself. Apparently there was a lot of '<' + elementType + '>' + value + doClosingTag(); kind of junk all over the place. Add to the mix javascript that called a web service and got pricing and another piece of javascript that called a different web service that adjusted pricing based on sales. I'm not going to defend this practice or design. I would never have let something like that get anywhere near production myself. You see a lot of people in this thread who don't feel that separation of code and display information is important. Imagine how that looks in an agile environment where nobody steps back to look at the big picture and developer turnover is high - like maybe a model that included churning offshore resources in and out as requirements demanded it. It's bad.
  - arclyte 11y ago
    I've seen this kind of thing in action. One particular case that sticks out in my memory involved function calls that didn't actually exist but were caught by magic methods and created on the fly. That one took me and another dev a few days to track down. If you find it hard to believe, you're either lucky or are severely underestimating the power of stupid.

by Gratsby 11y ago

userbinator 11y ago

But some idiot along the way decided that he should embed html AND javascript in his java class and it took a team of people several days to track down where exactly the error was that produced the errant price. A team of people, several days, and no one thought to just grep the codebase to find the relevant pieces? If that "idiot" didn't conveniently put the pieces all in one place, maybe it would've taken even longer to find? I wouldn't blame that on being "stupid code"...

Gratsby 11y ago
I had a little trouble with this one myself. Apparently there was a lot of '<' + elementType + '>' + value + doClosingTag(); kind of junk all over the place. Add to the mix javascript that called a web service and got pricing and another piece of javascript that called a different web service that adjusted pricing based on sales. I'm not going to defend this practice or design. I would never have let something like that get anywhere near production myself. You see a lot of people in this thread who don't feel that separation of code and display information is important. Imagine how that looks in an agile environment where nobody steps back to look at the big picture and developer turnover is high - like maybe a model that included churning offshore resources in and out as requirements demanded it. It's bad.
- arclyte 11y ago
  I've seen this kind of thing in action. One particular case that sticks out in my memory involved function calls that didn't actually exist but were caught by magic methods and created on the fly. That one took me and another dev a few days to track down. If you find it hard to believe, you're either lucky or are severely underestimating the power of stupid.