CultureFactorial’s Engineering Culture - A newbie’s perspective

It’s no news that every engineer wants to work alongside brilliant engineers, however, this is never the only consideration in the bid to accept a job offer. A very important factor is usually the engineering culture of a company. The Center for Advanced Research on Language Acquisition defines culture as the shared patterns of behaviors and interactions, cognitive constructs, and affective understanding that are learned through a process of socialization.

Having been in this “process of socialization” for about 5 months, I’ll like to take some time to detail my observations about the engineering culture at Factorial, so, please humor me 😉.

The Emphasis on Learning

Factorial University

As a newbie on the Engineering team at Factorial, one of your first stops to understanding how the app is structured and why certain technologies are adopted is the “Factorial University”. The term university sounds weird, right? Maybe not! The Factorial university archive contains a set of recorded classes in which different concepts employed within the app are explained by a developer on the team; these classes are typically held once a month and have most developers in attendance.

Tech Lunch

There’s another event called the Tech lunch which holds for 30 minutes every Thursday of the month depending on the availability of a speaker. Yeah, you guessed right! It happens at lunchtime 🙂 . At this lunch, the speaker (a fellow developer) delivers any topic (must not be related to our stack) for about 20 minutes and allows some time for questions and interactions. Is it fun? Yes! There’s always a dose of healthy sarcasm.

Factorial Library

Oh Yes! We do have a library, it’s typically a “learning resource database”. Here, you can find books and courses on topics ranging from Architecture to literally any engineering topic you can think of. Our CTO and engineering managers keep adding more books and courses to keep it updated. I recall the first book I picked up was suggested by my manager when I hinted that I wanted to improve my Ruby; it’s titled “99 Bottles” and it was an interesting read 😋

The Technology Chart

This is a map of all the technologies Factorial is either experimenting with or using in production. The goal of this tool is to have a commonplace to document how we use these technologies, thereby serving as a further learning resource for both newcomers and established team members. It looks something like this 👇🏽

At Factorial, you have no excuse for not improving as the environment is structured in a way that constantly encourages you to be better while providing the needed resources. Amazing right? I think so too 🚀 

The Emphasis on Passion

No matter how good developers are, they most certainly have areas of interest and areas that do not excite them as much. At Factorial, one of the things you’ll have to figure out is what part of software engineering excites you and how you can channel that excitement into adding value and causing improvements. This causes you to not just view your employment as a job, but as an opportunity to make real changes and flourish while at it. Several teams have been formed this way eg., the DX (Developer Experience) team that recently migrated 400k plus lines of code from Flow to TypeScript. The fact that no one is doing a particular thing yet is not an excuse for you to let go of your idea, you can become the pioneer and you can be rest assured that you’ll be getting all the support you need. What do they say about passion? It is the fuel in the fire of action.

The Emphasis on Taking Responsibility

At Factorial, the “ship, show, ask” pattern being practiced forces every engineer to take responsibility. It’s your responsibility to determine what category your pull request belongs to and act accordingly. This forces you to ensure that your code is tested and trusted before shipping; however, this is not totally failure-proof as sometimes, there may be some blind spots. What do you do in such cases? Quickly identify if the sudden weird behavior of the app was introduced by your change, be quick to revert or push a fix if need be, do not be ashamed to own up to it. At Factorial, nobody berates you for making a mistake seeing that we all do, as a result, there’s no shame in owning up to your mistakes and making conscious efforts to do better. This brings to mind a conversation I had with my manager when I just joined:

Him: Do you have access to sentry?
Me: No. Did I break something?
Him: Nope, you didn't break anything yet, but you will eventually, and that's fine.

This is that moment where you go “awwwnnn 💖 ”, well, I had the same reaction; Factorial does consist of amazing humans.

The Growth Pattern

At Factorial, once you get to a senior position, you can decide to either progress technically or managerially. This means that you do not have to become a manager if you do not want to and being a manager is not the “logical next step” in your career as some companies may have you believe. There is a “Career Path” document accessible to everyone in the company which helps you determine what you need to improve upon to get to the next level. There are no secret decisions made outside the influence of this document, and there are no separate internal versions of it. Compensation is not based on your negotiation skills, hence you will never find two engineers on the same level earning differently.

This sort of openness and transparency about the growth and compensation of engineers is one I find admirable. Not only does it speak to the integrity of a company, but it fosters an environment void of rifts. By the way, you can always change your mind about the chosen path, nothing is cast in stone.

Conclusion

There’s so much to say about the engineering culture at Factorial. Damn!, I didn’t even talk about how everyone is always willing to help, and you can literally reach out to anyone and if available, they’ll hop on a call with you to help fix whatever issues you’re facing. Oops! I also missed the product/engineering team combo, and if that’s indeed a recipe for disaster as assumed by many engineering teams out there. Oh Well!, now I hear the universe beckoning for a second part to this article; Will I respond to that call? We’ll see 🤞🏽
PS: As of the 8th of April 2022, as part of some improvements to our engineering culture, we stopped practicing the “ship, show, ask” pattern, and reviews are now required for every pull request.