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:

    Quote:
    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.
    UnQuote:

    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.

    Warmly,

    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

Design for Amiability: Lessons from Vienna

Computing was born in a Viennese café. Between 1928 and 1934, while Hitler plotted and Europe crumbled, a motley crew of mathematicians, philosophers, architects, and economists gathered weekly to puzzle out the limits of reason—and invented Computer Science in the process. What made their collaboration possible wasn't just brilliance (though they had plenty). It was amiability: the careful design of a social space where difficult people could disagree without destroying each other. Longtime A List Apart contributing author Mark Bernstein mines this forgotten history for lessons that might just save today's embattled web from its worst impulses. Spoiler: it involves better coffee service and the looming threat of public humiliation.

From Beta to Bedrock: Build Products that Stick.

Building towards bedrock means sacrificing some short-term growth potential in favour of long-term stability. But the payoff is worth it: products built with a focus on bedrock will outlast and outperform their competitors, and deliver sustained value to users over time. Liam Nugent shows us how.

User Research Is Storytelling

At a time when budgets for user experience research seem to have reached an all-time low, how do we get stakeholders and executives alike invested in this crucial discipline? Gerry Duffy walks us through how the research we conduct is much like telling a compelling story, complete with a three-act narrative structure, character development, and conflict resolution—with a happy ending for researchers and stakeholders alike.

Discover more from A List Apart

Subscribe now to keep reading and get access to the full archive.

Continue reading