At liblab, we tackle complex engineering problems to build SDKs for our customers and their end users, who are engineers themselves. Our team's extensive knowledge in software, software-as-a-service solutions, and developer tools is critical to our success. Therefore, retaining our talented developers is a priority.

Why should you care about engineering culture?

While it's often said that people leave managers, not jobs, it's equally true that engineers leave companies with poor culture. Engineering culture, shaped by the attitudes and experiences of software developers and team leaders, influences the working atmosphere. By understanding the importance of engineering culture, we can enhance the positive aspects and minimize the negative ones.

Practical tools for fostering a great engineering culture

There's a lot of discussion about building a great engineering culture on the internet. However, I'm focusing on practical tools here. These are concrete steps anyone can take to improve their team's culture and their own contributions.

1. Coding style and standards

Coding style is an aspect of engineering culture. It's not about specific preferences - we're not engaging in the tabs versus spaces debate! - but how coding style is shared across the team. Often, one "tastemaker" can influence the team's preferred style. If one engineer is the sole torchbearer, the implementation can seem arbitrary, and enforcing that style in code reviews with the wrong tone can alienate coworkers.

A coding standards document covers basic expectations like naming variables and functions, commit comments, and best practices. Creating these standards with feedback from the team fosters consensus and buy-in. Implementing a corresponding linting solution in the team’s IDEs and code repositories can clarify expectations and allow for early and regular corrections by the system, not a peer.

2. Developer tool choice

Another aspect of coding standards to consider is allowing tool choice. Not every developer likes the same IDE - some even prefer a traditional text editor! Allowing engineers to choose the solutions they’re most comfortable with will improve their satisfaction and productivity.

3. Code reviews and pair programming

Code reviews are routine tasks with a significant impact on culture. For engineers who don't pair on projects regularly, this could be their main professional interaction. Establishing a routine for code reviews ensures this important collaboration happens consistently. We recommend engineers spend time at the start of their day and after lunch on reviews to avoid a full-day wait for feedback. Alternatively, regular pair programming can reduce the need for code reviews since multiple engineers have evaluated the code already.

While experienced engineers analyze the code for style, functionality, and performance, every engineer can contribute. Less experienced engineers should be able to understand the code and changes. Asking for more information on a new function is a great reminder to include detailed comments! Seeing how others solve problems can spark new ideas and questions, leading to mentoring or collaboration. Participating in code reviews fosters relationships between developers, improving collaboration and culture.

4. Architecture discussions

Architecture discussions are some of my favorite times working in software engineering. Analyzing a problem, freely exchanging ideas, and incorporating elements into a cohesive solution represent the team's collective experience. Experienced engineers are naturally inclined to solve problems quickly, but these sessions are also opportunities to mentor and develop less experienced developers.

Encouraging experienced engineers to speak last allows the rest of the team to work through the problem together. Making a single engineer responsible for the project and the final decision on technical matters encourages strong ownership. This approach can also encourage participation from less experienced engineers, since they know an experienced engineer is ultimately responsible for the design.

5. Design reviews

Technical design reviews follow these architecture discussions. The responsible engineer details the proposed solution in a "request for comment" document, which the engineering team reviews asynchronously. If there are comments to consider, then a meeting is scheduled to discuss questions and collect feedback. This process gives every engineer a voice, promoting participation and an inclusive engineering culture.

6. Hiring

Hiring is another area where we can influence culture. New team members bring their own experiences and influence, but how we select them also matters. We at liblab prefer a take-home style coding challenge that closely reflects the daily developer experience. We've extensively discussed and iterated the content of this test, ending up with tests that target each of our engineering teams' focus areas.

Creating the test, having coworkers take it for a baseline, and evaluating the results is an important part of engineering culture. It establishes a minimum standard for the team, and completing the coding challenge becomes a shared experience and a badge of belonging for those who join.

Conclusion

Here are some practical tools for fostering a great engineering culture:

• Promoting coding style through tools
• Allow engineers to use their preferred tools
• Setting ground rules for engineering discussions
• Conducting inclusive design reviews
• Regular code reviews and/or pair programming
• Involving engineers in hiring practices
• Anyone can adopt these practices within their own engineering team to enhance their culture. Teams should also experiment; what worked well for us at liblab might differ for your team.

If our commitment to a great culture sounds appealing, then come join us! We are hiring for a range of roles, and you can find more details at liblab.com/careers.

This article was originally written by Adrian Luff for the liblab blog