5 ms·

> 1. Separate your code from your data. You shouldn't be kicking out HTML with your code, like this guy does in figure 1. When you combine HTML or any display i

by RyanZAG 11y ago

> 1. Separate your code from your data. You shouldn't be kicking out HTML with your code, like this guy does in figure 1. When you combine HTML or any display information with code that means your designer is your coder and your coder is your designer. Designers suck at code. Coders suck at design. Keep that shit separate. How do you feel about the common case where there is one person for both coder and designer roles? This is extremely common. Your comment makes it sound like the coder and designer are always separate people when in reality, for most websites, the front end coder is the designer.

ryanSrich 11y ago
Designers coding is fine. Designers programming is not.
- timlyo 11y ago
  I feel like a designer would have the opposite sentiment.
- rawTruthHurts 11y ago
  *Take with a pinch of salt
- baweaver 11y ago
  Careful on that line as some of us become programmers and are quite apt at playing both roles when needed. In reality separation of concerns is a luxury only afforded to larger teams and orgs. If you have the people, do it. If you don't, you're in for a bad time concerning yourself with it. Granted the html in Java is just straight idiocy, and my point refers to far less insidious mixings.
  - bryanrasmussen 11y ago
    separation of concerns in your organization is a luxury. separation of concerns in your codebase is a necessity.
    - ufukbay 11y ago
      I was about to write the same thing, so true. Even if you are working alone at the moment, doesn't mean that you should glue everything together and end up with spaghetti code.
    - baweaver 11y ago
      I was more of referring to the level of separation.
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.

by RyanZAG 11y ago

ryanSrich 11y ago

Designers coding is fine. Designers programming is not.

timlyo 11y ago
I feel like a designer would have the opposite sentiment.
rawTruthHurts 11y ago
*Take with a pinch of salt
baweaver 11y ago
Careful on that line as some of us become programmers and are quite apt at playing both roles when needed. In reality separation of concerns is a luxury only afforded to larger teams and orgs. If you have the people, do it. If you don't, you're in for a bad time concerning yourself with it. Granted the html in Java is just straight idiocy, and my point refers to far less insidious mixings.
- bryanrasmussen 11y ago
  separation of concerns in your organization is a luxury. separation of concerns in your codebase is a necessity.
  - ufukbay 11y ago
    I was about to write the same thing, so true. Even if you are working alone at the moment, doesn't mean that you should glue everything together and end up with spaghetti code.
  - baweaver 11y ago
    I was more of referring to the level of separation.

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.