Lessons learned (so far) as a software engineer working at appear.in
A bit of what happened from 9 months ago until now. By Walmyr Filho.
Time flies and I’m almost completing my first year working at appear.in, and as a person that likes to share personal learnings from time to time, here is a list of what I learned so far in this great team.
- Automate everything you can benefit from
If you think automation is just about testing, I do not regret to inform, it is not. At appear.in we automate many different kinds of tasks, such as notifying about the status of pull requests and merges to master branch, syntax code verification, compiling and building code, deployment process, infrastructure scaling up and down, provisioning environments, and of course test automation in many different levels, such as unit, integration, UI, interoperability (more on item 6), and even visual regression testing.
The benefits of automating as much as we can are many, but one of the most important ones is that we can move fast. Even before pushing the code to the version control system, we can quickly see if our code is using the standards defined by the team, for example. By the way, this is the topic for the next item, so, let’s move on.
2. Use linting rules to “enforce” best practices
Since a big part of our source code uses JavaScript, we benefit of ESLint to define and enforce that the standards are being followed when we’re coding.
ESLint is a tool for identifying and reporting on patterns found in ECMAScript/JavaScript code. It does both traditional linting (looking for problematic patterns) and style checking (enforcement of conventions).
By using such practice, even with a team of more than 10 engineers, we ensure a coding style that everyone understands and we use good practices applied in many other successful projects. Also, this allows us to focus on what matters, instead of “manually or visually” checking code syntax.
Some examples of rules that enforce best practices are:
- array-callback-return — enforce
returnstatements in callbacks of array methods - camelcase — enforce camelcase naming convention
- indent — enforce consistent indentation
- and much more.
In a code review process, for instance, instead of looking to coding syntax issues, the reviewer can look at the architecture of what is being developed, and provide valuable feedback to solve such problem in a good way. And talking about code review, let’s move to the next item.
3. Code review is a very good way to improve coding skills
By practicing and enforcing the code review process we can learn with our teammate’s experience. We use git to manage versions of our source code, and this allows us to work with pull requests.
A feature branch (or a pull request) can only be merged to master after code review approval, besides having to pass all the already mentioned tests.
4. Run experiments
I’ve learned that this is one of the best ways of understanding what works and what does not work, to move or continue in a specific direction. We run A/B experiments to understand what causes a positive impact on our users, as a way to deliver to them a service they like to use. We experiment new things internally, before putting new features into production. We use feature flags so that we can deploy new features to production and experiment with a reduced group of users, allowing us to learn and improve a lot before removing the flag and making the feature available for all our user’s base. And we also experiment in “internal projects”, such as using a new technology, for example, as we’re doing with visual regression tests.
5. Learn and apply new technologies
The nice thing about technology is that it is always evolving. Every day a better way of solving specific or general problems are available and we take benefit of it. We are totally encouraged to learn and apply new technologies to make our service up to date with what is new in the market and to make sure we don’t stop in our comfort zone.
Some examples of the recent changes we did regarding of using new technologies are:
- We moved our code base from ECMAScript 5 to ECMAScript 2015.
- In some parts of our app, we are moving from AngularJS to React.
- We used to have only unit and integration tests, and now we have even visual regression tests.
6. Interoperability testing
As a video conference service based on WebRTC, we need to ensure that our service works in the browsers that support this technology, and we need to automatically test if the core functionalities of our application works as expected in real use cases, such as verifying if audio and video are being correctly sent and received when two or more people are in the same room, for example, or if screen sharing works as expected, in both free and PRO versions.
This is possible with WebRTC end-to-end tests, and we have tests for many different cases in this matter.
7. Infrastructure as code
I heard a lot about infrastructure as code before working at appear.in, but I have not had the real experience of deploying infrastructure in cloud services in an automated way and everything being code.
Many of our services run on AWS, and to create a computational instance, a security group, a network topology, a storage, or any other kind of infrastructure, we use Terraform, which makes this totally controlled and secure, to roll back to an earlier working production environment, for example, in case an infrastructure change broke something that was already working, beyond many other benefits, such as having infrastructure changes being reviewed as any other kind of code.
8. Work on small things
A very good way to make progress is by working on small tasks that are part of a big one. In our product development process, we work with 2 weeks sprints, and we move with small steps, one after the other to achieve great results.
I remember when I started working as part of this team, and instead of splitting the main task I had in smaller ones, I tried to do all at once. In other words, I worked in the same pull request for two weeks, and when it was time to merge it (after all the verifications and code review process), I needed to solve conflicts and it took at least one or two days more of work.
Today I prefer to have small achievements and work in small pull requests, even if they need to be something like part 1 and part 2, but at least this way I have a quick feedback in the code review process and I have no code conflicts to solve, or at least less (in some cases). It’s all about quick wins.
9. Refactor without mercy
It is very nice when everyone in the team understands the importance of making the code better, for being able to develop a service in a sustainable way.
In the same sprint, some of the engineers will be working on new features, others in bug fixes, and others in making the code every day better than the day before, with refactoring.
In the boy scout rule it is mentioned that you, as a boy scout, need to leave the camp cleaner than you found it, and this is what we do with our code, because we care about it, and we care about it because we know we spend more time reading code, then actually writing it. Also, because we care about each other.
We split code of big files in smaller ones for separating responsibilities and for ease maintenance. In the code review process, we suggest better functions and variables naming, for making the code readable. Also, we try to solve complex issues in simple ways, using sophisticated code standards and working with emerging architecture.
10. Pipelines as code
We use continuous integration and continuous delivery as part of our software development process, with help of a great tool called gocd, and even our pipelines are created as code, which makes the process of creating or updating a pipeline easy and low cost to maintain.
I know a lot more learnings will come and I’m looking forward to it, but I thought you would like to know a bit of what were the learnings so far, and maybe you can tell me what is your perception about all of this. Leave a comment!
If you liked the post, leave some 👏🏻, so your network will have the chance to read it as well.
