The A List Apart Blog Presents:

Learning to Be Flexible

Article Continues Below

As a freelancer, I work in a lot of different code repos. Almost every team I work with has different ideas of how code should be organized, maintained, and structured.

Now, I’m not here to start a battle about tabs versus spaces or alphabetical order of CSS properties versus organizing in terms of concerns (positioning styles, then element layout styles, then whatever else), because I’m honestly not attached to any one system anymore. I used to be a one-tab kind of person, along with not really even thinking about the ordering of my properties, but slowly, over time, I’ve realized that most of that doesn’t really matter. In all the projects I’ve worked on, the code got written and the product or site worked for the users—which is really the most important thing. What gets me excited about projects now is the code, making something work, seeing it work across different devices, seeing people use something I built, not getting upset about how it’s written.

Since I went down the freelance route again earlier this year, I’m working with many different teams and they all have different standards for how their code should be written. What I really want to know when I start a project is what the standards are, so I can adhere to them. For many teams that means a quick look through their documentation (when they have it, it’s a dream come true—there are no questions and I can just get to work). For other teams, it means I ask a lot of questions after I’ve taken a look at the code to verify how they prefer to do things.

Even more so than just thinking about how to write code, there’s the fact that I may be working in straight CSS, Sass, Stylus, Handlebars, plain old HTML, or Jade and I usually roll right along with that as well. Every team makes decisions that suit them and their way of working—I’m there to make life easier by coming in and helping them get a job done, not tell them their whole setup is wrong. The variety keeps me on my toes, but it also helps me remember that there isn’t just one way to do any of this.

What has this really done for me? I’ve started letting go of some things. I have opinions on how to structure and write CSS, but whether it’s written with a pre-processor or not, I don’t always care, and which pre-processor matters less to me as well. Any way you do it, you can get the job done. Choosing what works best for your team is what’s most important, not what anyone outside the team says is the “right” or “only” way to do something.

About the Author

Susan Robertson

Susan Robertson is a front end developer working with Fictive Kin who focuses on CSS, style guides, responsive, and accessibility. In the past, she has worked with clients such as FiftyThree, Imprint, Cloud Four, and worked for Editorially, The Nerdery, and Cambia Health. When not actually writing code, she can be found writing about a wide variety of topics on her own site as well as contributing to A List Apart and The Pastry Box. When not staring at a screen, she reads comics and novels, cooks lots of yummy food, and enjoys her Portland neighborhood.

7 Reader Comments

  1. I too am a freelancer, although my domain expertise is in embedded and real-time systems, the kind of stuff where you work close to bare metal, you have a hardware engineer on speed dial, and you own a logic analyzer (or two). Yet my experience is identical to yours. My goal is to ship a successful product, and I’ve come to realize over the (nearly forty) years that there are a lot of ways that can be accomplished. For sure there are “best practices”. But I often find myself working in teams that are absolutely convinced that their way is the only way, usually based on their own (limited) experience and (ditto) circumstances. That’s okay, it’s a win for me: I do it their way, and once we ship, I’ll pick and choose the parts of their process, work flow, standards, and tool chain that I think works better, discard the rest, and move on. It’s all good.

  2. I always try to get people working my way, telling them why “X” is better than “Y” and so on, time to change my mind and do better team work 🙂 great read.

  3. Great article. Reminds me why I love the web, there is more than one way to accomplish what needs to be done. Also, when working with others, it’s not about you or your agenda, it’s about the project and end result.

  4. Hi Susan,

    I was tickled pink when I read the following:

    What gets me excited about projects now is the code, making something work, seeing it work across different devices, seeing people use something I built, not getting (too?) upset about how it’s written.

    I’ve worked with a lot of teams as a freelancer who (appear to) have no clue about standards, while giving me a standards manual, often badly written unfortunately, which no one really seems to follow but me.

    After a few years of this, I too have reached the state of – Lets get this to work – rather than pointing out how it can be done perhaps a whole load better.

    At the end of the day, site visitors will enjoy interacting with your webpage, without having the slightest clue about Web server loads and code execution time and so on. As long as no system error is thrown and the web based UI renders correctly, Magic.

    This has been my usual focus in most cases. Enjoyed the read. Thank you. Made me feel I’m not alone.


    Ivan Bayross

  5. I find that data standards should be sacrosanct and coding standards should be lightly enforced.

    Code makes the work flow, but the correct data definition is crucial.
    The brand of database software is less important than the type definitions being completely understood (and defined in advance).

    Oh, and the customer is always right… until the check clears.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA