Connecting the Dots - My Onboarding Experience and Mental Model of a Software Development Team

August 10th, 2020

The good news is I recently joined a team of software engineers at Future500 B.V. The normal routine every company embraces as part of their culture is that new team members going through an onboarding process and it's been fun, exciting, interesting and challenging.

During the entire process of the onboarding, I got to learn a lot about the company in terms of team dynamics and talents, their history, their mission as a software company, their impacts so far in the industry and how the future looks.

I must say; it was such a great and remarkable experience and I know this is the right place to be at this stage in my career as a software engineer. This even reminds me of my mental model of a software company formed while reading this book: Software Engineering at Google.

The book highlighted insightful processes, tools, and culture adopted at Google, and reading that book improved my thought about how a good software company should operate.

Future500 has really made me connect the dots together. In this article, I will share how my experience at Future500 connects my mental model of software company's processes, culture, and tools.

The Software Development Culture

During my onboarding process, I was introduced to the projects I will be working on mostly.

My decisions and thoughts in approaching the project were basically just about following up instructions on the README.md file to get me started. But I learned that the nature of software development here is more of a team effort with diverse ideas, strong collaboration and hence they have protocols that are essential for honing the craft in the entire cycle while solving the business needs as a team.

Below are some of the cultural practices:

• Pair/Mob Programming Mostly working in pairs or even with the entire team to get you up to speed instead of working alone. This brings smart and better ways of getting things across different perspectives.

• Scrum Meeting Joining a video conference to discuss the progress on both major and minor wins and if individuals are stacked on any issues. This helps solve any outstanding issues at a faster pace.

• RedWire This is more about finding out where the team could improve in terms of technologies to experiment with, how communications could get better, strategies to get better at the craft, etc.

• Upping Wednesday

  This is meant to make sure the provisioning on deployment environment is tested, updated to prevent any sort of deprecations.

• Retro: It's an hour meeting to talk about what went well for the team and what could be improved. Sometimes a team exercise like playing game together or just talking about things. The idea was borrowed from scrum methodology.

The culture is basically about a developer taking up any special challenge aside software development, it is common culture for a developer to go an extra mile, pushing yourself of learning by contributing toward open-source projects used by our services, speaking at conferences/meetups, writing technical articles as well as even sponsoring conferences as a company. This contributes to one’s personal development and a better version of oneself.

The Processes

Generally, development teams have good structures and protocols that govern the approach to development.

At Future500, the entire processes of development stem from ownership of codebase. Everyone on the development team has authority on all projects hence there is no privilege separation on projects but there is an audited protocol on who did what and the timestamped with the help of GitHub.

The current processes include:

• Code Formatting Rules or Style Guide

  We mostly work with PHP programming language which has its standard recommendation. PSR-2

• Documentation

  We invest heavily in API documentation for our customers hence writing documentation is plugged into the development workflow using tools like openapi. Also most software design choices that addresses a functional or non-functional requirement that is architecturally significant are written down in a document, decisions.md.

• Testing

  The team usually builds a suite of automated tests that are run. Developers write unit tests for their code, and as well as integration tests. These tests usually run in development and also in GitHub actions on every pull request.

• Code Reviews

Since we work in pairs, there is the second eye providing a great source of useful feedback.

Mostly have been other team members on the pair programming who point to some coding standard I usually miss, give you a quick proofread for typos or missed scenarios, and offer an architectural style of coding with many suggestions without forcing them on me.

And before you make a pull request for code review, there is high confidence of the code adhering to rules due to the second pair of eyes when writing code. At code review level, we leverage on GitHub pull request mechanism which always starts from submitting a pull request, passing test suites and building and automatic deployment to a staging environment.

Once all processes are passed, our developers could offer suggestions on GitHub, etc., before it goes to production.

The Tools

With tools, it has always been the state of the arts to help run processes and procedures efficiently from communication to code deployment and many investments have been made so far to enhance the developer’s workflow.

• Communication I had my company email setup on the first day and also invited to join the Slack workspace. Most of the communication happens in Slack with a lot of bots helping in various notifications to meetings, production issues, PRs, etc.

• Infrastructures Most code at the moment runs in Vagrant boxes, with Ansible helping with deployment automation. For logging and metric evaluations, we're using Datadog for such purposes. We use a makefile to speed up most of our toolings that execute from the terminal. The team is also currently migrating to docker :)

• Codebase

  Codebase is centralized in the company's GitHub account with various repositories connected to ZenHub, a tool for easier tracking of issues PRs and also acting as a project management tool at the codebase level.

  Central to codebase tools is Git as our version control system. There is a significant amount of code in the PHP programming language, Symfony to be specific. And all these are written using

  PHPStorm which provides great toolings for PHP codes. We are also using RabbitMQ for queueing messages, code executing, and parsed by the Nginx web server running on Debian OS. Data is mostly stored in MariaDB and using ElasticSearch for searching. There are other services used at the codebase level but generally, these are the tools used.

Conclusion

The culture, processes, and tools outlined in this article describe my overall experience. And could be summed as a key contribution to what it is like in a typical day as a software developer on our development team:

• Morning greetings in slack
• Checking previous slack messages
• Getting into projects you’re working on
• Jumping into general scrum meetings with coworkers to discuss what you're working on, progress made or whether been blocked
• Popping on a call to discuss code design or issues you're facing in project.
• Writing a lot of code.
• Submitting pull requests, reviewing, and merging them.
• Supporting customers on issues

In a nutshell, being part of the team has made me realise my mental model of a software development team. I can't wait to see what we will achieve together as a team. There’s so many things you can learn from the book: Software Engineering at Google by Titus Winters form Google. You can contact us here.

Oliver Mensah

Software Developer