A Personal Anecdote About Learning HTML and CSS

Explaining Markdown

When I set out to learn programming in early 2012 in order to build Uncover, I was primarily focused on learning Ruby on Rails. When I thought about what programming was to me, it was always about being able to develop the backend so that I could add, edit, and delete data. That’s the underpinning of any web app, and I was interested in building a web app.

I teamed up with a friend who was a web designer and proficient in HTML and CSS, so I put other aspects of learning to program on hold. I wanted to be a backend developer. I learned enough to be able to integrate my Ruby on Rails with his HTML and CSS, but it wasn’t until twelve months later that I actually took my first crack at coding up a page from only a Photoshop file.

One of the many tasks of a startup founder is to drive sales. Sales are the lifeblood of a company. If they’re going poorly then morale will be low, but if they’re going well, then everyone will be happy and continue to produce great work. As Uncover is a B2B company, one thing that’s required when you’re selling B2B software is Case Studies. We put together one with one of our customers, SeatGeek, and I tasked myself to do the HTML and CSS from only a PSD file.

I’m a little ashamed that it took me so long to make my first attempt at doing the frontend for an entire page from scratch, but when I finally did it I loved every second of it, and I want to tell you why.

The first thing that’s exciting is that when you’re developing frontend HTML/CSS, Google Chrome’s Inspector gives you the ability to make changes in real-time. The page will change as you add, edit and remove HTML and CSS elements. This is different from backend development for the most part. It was liberating to be able to fiddle around with code and watch it change on the spot. My friend Kyle Fox sent me this gif over Twitter, and while it’s always frustrating, at least you’re always getting real-time feedback.

Another aspect of frontend development that I loved was that there’s a real sense of accomplishment as you’re building the page out. You’re hopefully fortunate enough to be working with a good web designer who has given you a PSD file to work with. That makes things a lot easier. As you’re writing HTML and CSS, the page will begin to come to life, and it’s a really neat feeling.

It was also exciting to learn, finally, that frontend development, unlike backend development, allows for a lot of different ways to achieve the intended outcome. While there are conventions in HTML/CSS, just as there are with Ruby on Rails, there is definitely more than one way to do things. With RoR, there is generally only one agreed upon best practice.

Writing frontend code allows you more latitude when you write. It’s nice knowing that getting the page to look exactly like the PSD is the end goal, rather than perfecting the code. Obviously, you shouldn’t write sloppy code, but knowing that there’s more than one way to get where you’re going is liberating.

Just don’t look at it in Internet Explorer when you’re done.

Spencer Fry

I’m a 29 year old entrepreneur. A Business Guy turned Programmer. Co-founder & CEO of TypeFrag ('03 - '07), Carbonmade ('07 - '11) and currently Uncover ('12+). Uncover is everything you need to start and run an employee recognition program for your company. My hobbies are squash, soccer, cooking, music, and art. You should follow me on Twitter.

Comments

18 comments on “A Personal Anecdote About Learning HTML and CSS

  1. Great point about the Inspector. Not only is it satisfying to see real results, but it’s helpful to make sure you’re moving in the right direction.

    The Inspector is super helpful, unfortunately to my knowledge there’s no universal tool quite as simple for the backend. Testing is the best solution I’ve found for tightening the feedback loop on the backend, so far. It can be a pain in the neck to set up, but it offers get faster, more automated results to ensure you’re moving in the right direction.

    Nice post, keep it up!

    • I still haven’t gotten around to writing many tests. I feel as if that’s one of the next things I need to spend time learning how to do. My reasoning for skipping out on learning testing was that I’d rather focus on getting the app to do things than testing if they work. I don’t know many folks that write tests when developing a prototype, but I could be wrong.

  2. Getting a PSD to HTML5 from
    experienced professionals who have the hands on expertise in dealing
    with the queries of the clients and serving them with the best
    results is the main requirement. So, for all the PSD to HTML
    conversion get in touch to get your website developed the appropriate
    way.

  3. This line really bothers me. “It’s nice knowing that getting the page to look exactly like the PSD is the end goal”

    Really? HTML and CSS is code just like Ruby on Rails. Granted in most cases there aren’t security implications when you do something sloppy using them, but there are performance and maintainability implications. And let’s not forget there are also compatibility issues that tight well written CSS and HTML can really help alleviate.

    I’m always saddened when “real” developers seem to think writing good HTML and CSS isn’t as important as writing good backend code, and treat is as such. The end goal with HTML and CSS should be the same as RoR, PHP, Python, or any other programming language. Accomplish the end goal with a well written, well thought-out and manageable code base. Spaghetti code is just as gross when it’s preceded by as it is when it’s proceeded by class.

    • Sorry. I did not mean to imply that HTML and CSS is not coding just as writing Ruby on Rails is. I was simply saying that when I originally got into learning to code, backend was what I felt was more important for me to learn. The reason being was that I was looking to build CRUD apps and I was teaming with a web designer who knew HTML and CSS. That said, if you’re working with a web designer then the goal *is* to make “the page to look exactly like the PSD” as I said.

      • I don’t have that experience with the designers I work with. Every time I send them a review link we have many discussions about what tradeoffs I made, why I think they are ok, and where I can do a better job making their vision fit the realities of the web and the platform we are working with. We often make tradeoffs against the PSD for the sake of making things manageable in the CMS, for mobile, or for compatibility with IE without ugly hacks. Making it looks “exactly like the PSD” is something to strive for, but it’s not the goal, at least not for me. I think making that *the* goal is a mistake, it should be a by product of great code and conversations with your designer and client.

        • I think that depends on the designers you work with. Throughout my career I’ve been fortunate enough to work with world-class designers who also know web development and how to code. Their choices of design tend to take into account how the developer will need to implement things and therefore making it look exactly like the PSD is the right thing to do because they know the limitations of the Web. I could see that not being the case for some designs, though.

          • Sounds cocky to me. Dev’s and designers should be able to sit down together and discuss some points. The designers may know the limitation, the dev’s have their street smarts about the code they are writing.

          • Didn’t mean for it to sound cocky. :) The most recent one I was referring to was the Head of Design at Twitter’s New York office.

    • “Exactly like the PSD” is the part that bothers me; designing to make your design exactly like the PSDs, like how evangelists such as Andy Clarke have always for so long warned about doing, should not be the end goal.

      It unnecessarily creates an assumption that the design should look exactly the same on every browser, it’s not sustainable if you’re going to do a responsive web site( at best, you’d be adaptive, not responsive), and you can over-constrain yourself rather than making the most of what each browser can provide you to ensure the design maximizes the end-goal of the web application being made in the first place.

  4. It always helps to be able to know some type of code if you are a designer or an SEO expert. If you can code you could save a lot of time not just your time but also others who are experts in coding. As a small business consultant I find it easier and cheaper not having to run to my development every time. That said I’m no expert but I do know the basics.

    Sean
    Small Business Consultant
    http://www.jillzander.co.uk