Our Engineering Values

We are a team with a wide variety of backgrounds coming together to build systems to solve complex problems. We combine strategy, user interface design, and code, into cohesive software solutions. Together, this work forms a practice of software engineering. You may not think of yourself as an engineer, but what we do at Lullabot collectively is engineering. When we say engineering, we mean you.

These Engineering Values exist to guide our team in the work we produce and the interactions we have with each other. These values overlap and expand on our Core Values - they’re not a hierarchy or a tree. When solutions aren’t obvious, or there’s conflict, we use these values to ground our decisions.

People matter more

We build systems and processes for people first — and if we forget or ignore those people, our systems become a source of dread, rather than a source of delight. A project that launches on time and on budget, but burns out a team, isn’t successful. Helping others keeps us connected, even when we’re separated by great distances.

In our work, we use many tools as a means of communication, such as instant messaging apps, project management apps, version control, and peer review workflows. Sometimes, the tools we use to communicate can be a blunt instrument for human dialog. We strive to be aware of the limitations of the tools we use and keep in mind that they are a means to engage people and not an end in themselves.

The work we produce is not separate from the world in which we live. We value human safety and security. While we do not always have direct control over how our work is used, we aim to create products that do not actively harm any one group. We draw on our empathy to build tools and products that equitably empower everyone who uses them, considering the impact of unintended consequences.

Cultivate inclusivity

We value diversity and inclusion. Beyond its intrinsic value, inclusion has an impact on a technical level. Our overarching goal is to identify or to be the experts and advocates for people who are not directly represented by our project teams. For example, we seek out the voice of the end-user, because client perspectives can sometimes miss key factors that only a user would know. We work towards equitable teams so that our work reflects the diverse world we live in. And, we continuously evaluate and respond to feedback, because the voices that are missing are going to be different from project to project.

We cultivate inclusivity at a technical level by building accessible products because the software we build should function for everyone. Sometimes that means educating our clients about the importance of accessibility. Further, we aspire to work using tools that are accessible themselves and seek to use accessible language and technologies in our documentation so that differently-abled people can work on both sides of the keyboard.

Learn and share

We find our work fulfilling because we are always given the opportunity to learn something new. We like to work on new, unsolved problems instead of applying the same solutions to the same problems. Learning and sharing, with ourselves, our clients, and open communities are woven through all the work we do day by day.

We believe that the best engineering comes from sharing and building together as a group. We embrace open-source software and processes. The process of open code-review keeps us innovating, and saves us from reinventing the wheel. By integrating collaboration into our daily work, we create the space for our team to ask for help and to be generous with their knowledge.

Excellence balances perfect and done

We find the balance between getting things done and architectural zen. When we solve tricky software engineering problems, we also consider when we are seeing diminishing returns. Rather than creating in isolation, we iterate using real-world feedback and quantitative results to evaluate our work.

Some projects need tactical engineering measures that are not meant to last. Other times, we discover new information, and we need to stop working to discuss the options again. Not all project scenarios are ideal, but we partner with our clients to find out what will work best for them.

Code for the future

We think about the big picture before making important decisions. Creating a system to solve a complex problem is only the first part of a software project. Good systems last because they are maintainable and also maximize value for the client. Others will inherit our work and need to improve and maintain it. We don’t have perfect memory and know that sometimes the inheritors are just “future us”. We optimize code for future readers, even if that means using more verbose language or limiting the use of uncommon language features.

Automating away repetition for ourselves, the community, and our clients is deeply gratifying. Automation promises to reduce technical debt in our code, make our processes more robust, and save time and money. However, automation can also add unnecessary complexity and waste time. Just because we can automate something doesn’t mean we should.

Work joy into work

As engineers, we have a tendency to look at technical challenges as fun puzzles to be solved. We try things, we break things, and we try again. We come back to work each day because we enjoy tinkering with the systems we build. When planning our work, we strive to leave room for joy, even with tight deadlines and exacting requirements.

Making room for joy empowers us to find possibilities instead of problems and to accept criticism with an open mind. Even amid extreme technical challenges, we find something to smile about — whether that’s a new skill learned, a helpful teammate, or wistfully deleting code we loved. Together, we smile in the face of adversity, freeing us to find elegant solutions to the toughest problems.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License and is also available on GitHub.