1. Writing contextual CSS ->

    3 min Organization and structure of CSS might be one of the largest difficulties for beginners as for professionals in web design. It is hard writing good CSS. It is somewhat easer with pre-processors (SCSS, LESS, Stylus), but they'll only give you the tools: it's up to you how to use them (what I can't do without is the @import feature).

  2. "Master of many trades" ->

    1 min

    We hear the descriptive words psychopath and sociopath all the time, but here’s a new one: monopath. It means a person with a narrow mind, a one-track brain, a bore, a super-specialist, an expert with no other interests — in other words, the role-model of choice in the Western world. Great text about things I've written or linked to before: how being wide in your interests and learning really is a great way of living. Personally, I am able to connect things that I previously thought were separate, building bridges between areas, and seeing things in a larger perspective, giving me a deeper understanding of the subject and thus a unique satisfaction with what I am currently doing.

  3. Changing perspectives and doing the crazy thing ->

    2 min Like it or not, but tech people often have their way of doing things. Together we've drunk the same drink telling us that "this is the way of doing things", and we repeatedly create products where we incorporate this way of thinking, which go generations back (slight over-exaggeration).

  4. A symbol for sex ->

    2 min "What is an appropriate symbol for sex?". The question I asked myself some time ago might seem somewhat trivial at first, but when you dig deeper, it reveals a bunch of sub-questions and scenarios.

  5. I don't like counting hours ->

    3 min In the freelance and consultancy business, you often charge per work hour. It's the rate, and then you estimate the total number of hours for a project. The estimate is ... an estimate. Estimates are seldom correct, even for senior consultants. I'm not ashamed to say that I often do an initial estimate, then almost doubling it when responding to the client. One thing I've learnt is that it's immensely better to land a project below the estimate than above.

  6. On Scala ->

    1 min A friend and colleague of mine is boasting a lot about Clojure and it's productive capabilities. But I really can't wrap my head around the LISP syntax. Perhaps it's a matter of putting in time.

  7. Programming and communication ->

    1 min

    The difference between a tolerable programmer and a great programmer is not how many programming languages they know, and it’s not whether they prefer Python or Java. It’s whether they can communicate their ideas. By writing clear comments and technical specs, they let other programmers understand their code, which means other programmers can use and work with their code instead of rewriting it. Absent this, their code is worthless. By writing clear technical documentation for end users, they allow people to figure out what their code is supposed to do, which is the only way those users can see the value in their code. Joel Spolsky

  8. Tags and class names – on building flexible markup ->

    3 min It is said your markup should be clean and semantic. What does that mean, exactly? As few tags as possible? The correct tags for the job? Few or no ID and class attributes? At least that's been the main formula for a while now. Littering ID and class attributes over your markup has been frowned upon. But what does the alternative mean?

  9. Object-oriented Programming and Modeling the Real World ->

    2 min

    Almost everybody begins OOP with this misconception - objects in real world directly map to OOP objects. Its maybe a good place to start but how many grow up from the initial simplistic rule - map nouns in requirements to classes. So, you end up with objects that don't really mean anything and don't do much. Naive use of UML diagrams also leads to this. Discovering abstractions is tricky. One needs to really live with requirements inside out before they present themselves. From a Hacker News comment on  this story about Clojure programming. I've seen this myself in school, where we've gone through endless examples of OOP where the classes were a Ball, a Car, a Zebra, or other overused objects in the real world. The thing is, most programming isn't about modeling the real world, our world. When writing code you're free to do things your way, not being tied to the constraints of the real world thinking.

  10. How Ryan Singer builds products ->

    1 min

    Our company DNA at 37signals is make things we want, and to make them the way that we want them Ryan Singer Great interview with Ryan Singer about product design.