Ask HN: Is it worth a back-end developer's time to get into web-design and HTML/CSS

I'll avoid me too and agree you should learn these front end technologies. That said, there seems to be a question of how and what underlying your post. I'm not a designer by any stretch of the imagination, still I hope this helps:

== XHTML/CSS ==

1. Learn basic HTML, understand what "semantic markup" means. I assume you know some HTML already.

2. To understand CSS, understand the box model. Understand inline and block elements. Understand selectors. Understand positioning. The rest of it falls in place from there.

Hopefully you'll have an appreciation for markup and meaning versus presentation at this point.

== JavaScript ==

3. Learn Javascript. Understand that everything is a hashtable. Understand how it handles scoping and understand classless objects. Once you're comfortable with this you're ready to move on.

4. Understand the DOM and how to manipulate it.

5. Read a little on AJAX, I found the DHTML utopia book on Sitepoint.com?myaffiliateid=me was good.

6. After you understand AJAX and DOM, go learn a library like JQuery or whatever else people advocate these days. These libraries are like mana from heaven. They will save you time! Oh, if you did steps 3-5 you'll be productive with a JS library in about 2 minutes. The learning curve is small at this point. Great stuff!

7. Install Firebug and spend an hour or two learning how to use it. Firebug will save you time and console.log is so much better than alert(). Firebug has made me happy.

Now you know how to manipulate sites on the client side. Great! Last step:

== Graphics ==

8. Learn a tool like Photoshop or the GIMP. Understand how to select stuff, copy and paste. Then become familiar with layers and masking. I am not a graphics guy but I've only recently become turned on to the power of masking. Wow. People like you and I can do neat things.

I don't have resources for everything because I scrimped and learned as I went. However this should represent a good order (and some pointers on what to look at) as you pursue this. Good luck!

Amen.

The right approach is to understand /why/ it's hard from the front-end so you can make your back-end more suitable to the front.

I still don't know how to answer when people ask if I am a front-end or a back-end developer. I just don't get it. I used to think I could claim to be a back-end guy because I do know SQL, but I don't know how to make pretty mockups in Photoshop. But now it's apparent that knowing HTML and CSS and JS makes me a "front-end" developer in many people's eyes, so I've gone back to not knowing how to answer. It's like asking whether I walk primarily with my right leg or my left.

I think the dichotomy broke completely when Ajax came on the scene. In earlier times it was possible to pretend that the division between client-side code and server-side code was aligned with the division between the presentation layer and the logic and persistence layers of your app. That alignment was never very clean (there are limits to what you can rearrange with CSS alone, and while JS can theoretically rearrange everything the result is liable to be slow and fragile and terrifying to behold, and obviously the needs of the interface designer need to drive the optimization of the back-end data store, etc.), but you could still pretend. The ever-increasing role of client-side JS makes that view of the world less tenable. Now some logic lives on the client as well as on the server, and Google Gears threatens to give the client persistent storage as well, and the interaction between client and server can potentially have a lot more moving parts, and a developer gains a big advantage by having a basic understanding of the entire stack.

I straddle the line between these worlds. My day job is frontend development with some Ruby here and there, while I've been designing and building out a Rails app on the side.

I think my response would be similar to your 'developer-side' response - if at any point in working on a project I find myself confronted with something I do not understand, I have this compulsive urge to figure it out. In the process, I've saved myself thousands of dollars by investing a few days to learn what I need to at the time to get around the problem.

It sounds like you're a great Ruby developer with a leg up on all of the new "ZOMG RAILS!" converts. Don't be too concerned about the "jack of all trades, master of none" category. If you're working on building a company from scratch, product guys/gals are key - people who may not be experts in everything, but can get the job done for rev1 no matter what. If you can play that role yourself, you'll have far fewer people to depend on.

If you decide to work on the frontend yourself, start with raw HTML and forget that CSS exists entirely. This might help you to think of HTML/CSS as a backend developer.

HTML is just XML with a fixed set of elements that are named according to their purpose and have specific functions in a document - and you'll probably only need a small subset of them. So, look at your comp and think of the elements in it; paragraphs, lists, images, buttons, links, etc. Then, start writing what seems like an XML document describing it. Again, don't even think about styling it at this point. Just build the best web page that 1994 ever saw:

  
    
      My Application
    
    
      
        (Name, logo, etc. here)
        (Navigation)
      
      (Main app content)
      (Sidebar content, if you have one)
      
    
  

Once you've got your document written, you can start to tackle CSS. Since you've got a valid, well-formed document composed of semantically-meaningful elements, you'll find it much easier to style than people who focus upon the look of the document as they write it rather than its well-formed-ness. If you choose to hand it off to a dedicated frontend developer at this point, they'll be grateful that you've provided them with a solid canvas to build on.

Good luck building your application; whichever route you choose, let us know when it launches!

And if you'd like any recommendations for either a designer or just someone who can slice and dice a comp, let me know; I've got a few solid friends who charge reasonable rates and have some availability coming up.

Nice outline. I agree with just about everything you have put forth here, but I think OP might want to either skip the graphics part for now and let someone who really knows it handle it, or learn that right after XHTML/CSS. JavaScript is going to be easy for him, better not to focus too hard on it and give time to what is going to be a little more challenging.

As for learning XHTML/CSS, http://htmldog.com/ is an incredibly easy tutorial. You'll understand it all in hours.

Having a good design "sense" is important - you should at least be good enough to tell excellent from good from bad. This goes doubly if you're in business for yourself, since you'll likely have someone else doing your design for you on a contract basis, it's good to know they're good at it.