When I started working as a developer in Hong Kong, iOS was still in Version 4. Since then, I’ve become one of the six partners in one of Hong Kong’s leading web and mobile development agencies. In addition to acting as the tech lead or PM for projects, I work on initiatives like setting up the company’s Kubernetes cluster for DevOps and mentor junior developers.

I’ve grown with Oursky, since we were fewer than 10 people. Now with over 50 colleagues and new developers every year, we’ve started formalizing approaches to helping new team members settle in. We want everyone hired to pass probation, but the truth is there will always be some who aren’t a good fit in the end. Every case that doesn’t work out is slightly different, but one of the biggest hurdles I’ve noticed is a person’s approach to commits. **

Below are my reflections on what commits reveal about a developer and why it’s an important factor for cultural fit.

How we work with new team members

No matter what their background is, we expect all our developers to be full-stack. (Ben, a co-founder, explained how we hire developers based on fundamental knowledge, effective implementation, and willingness to learn new languages.) For our company, a server-side engineer has to be willing to work on web and mobile projects; a front-end engineer has to be willing to strengthen their backend logic. Everyone has different strengths, but by being full-stack, developers can think about features in their entirety for apps.

When we hire a new team member, we onboard them into our projects immediately. We assign tasks in platforms they’re familiar with first (i.e. iOS, Android, JS), so that they can focus on learning how to work with our team members.

During the onboarding, we can see how a developer works. This includes:

• their coding style
• their logic
• their ability to write readable commits

What a commit message means to us

Adjusting to commit styles can sometimes be painful. Commits may be inconsistent or have multiple changes in one pull request. I have worked with fresh university graduates who may be using git for the first time (it’s not required in all Hong Kong universities) who adapt in a week. I’ve also had an experienced developer putting 30+ micro-commits in a pull request and asking me if the rule was “the more commits the better” when I raised the issue of readability of his pull requests in the Github workflow.

A commit is more than just “our company’s way of doing things”. Our two main considerations are 1) readability, and 2) logic factoring in future maintenance (Wiki on Atomic commits).

Our developers have different styles for writing commits. For example, some prefer the REF number before or after the message. I am flexible on the format as long as a team is consistent for each project.

What a commit tells us is:

• How does someone think about a feature? How do they break down tasks? Are they putting everything in one gigantic commit? Or are they thin-slicing them until others can’t understand the logic?
• What is their working logic? Are they able to make one logical change per commit, so that we can merge or roll back if needed?
• Are they able to think about others? When they write messages, are they clear so the tech lead or peer reviewing can understand and accept or deny a pull request?
• Are they willing to take feedback? How do they respond to their tech buddy or tech lead’s advice? Are they able to implement changes? Can they explain their logic rather than taking follow-up questions personally?

Finding the sweet spot between freedom and teamwork

By giving a new member tasks, we should give them space to execute. We don’t want to box people in with rules and waste time on fixed training procedures. Our company gives individuals the freedom to find the sweet spot between their personal optimal and a team’s optimal working style.

There isn’t only one right way to do things and we want team members to keep a creative problem-solving mindset. Though they’re part of a project team, our developers individually own the features they work on. Though they are working independently, our developers need to think about how to improve their code quality and communication for others to follow.

Things that shouldn’t happen

One of the biggest mistakes PMs and tech mentors can make is not briefing a new team member enough. If there is no discussion with a new team member, there is a danger that they will use the wrong approach and the entire feature cannot be used. Of course, that’s an extreme case. We usually will require small fixes in the commits.

My advice to new developers

Working at Oursky means continually learning as a developer. One of the lessons we are often reminded of, even with colleagues we’ve worked with for years, is that there are always communication gaps. Using the Atomic commit approach is a commitment to creating well thought-out features that are understandable, and therefore maintainable, for people in the future (including yourself!).

A new team member’s willingness to adapt their work style and ensure readable code reflects how open they are to considering different perspectives and engaging in debates. After a month of working with a new team member, I will usually spend less time asking “What does this mean?” and more time on the fun stuff: plans for implementation and exploring possible solutions to the problem of building great products.

‍