My background is in software development, and I’ve worked for agencies, startups, and large organizations. This ranged from being a solo developer to large teams, and allowed me to learn about how to build scalable web applications from scratch, including UI/UX, backend, frontend, DevOps, etc. During this period, I’ve seen what does and doesn’t work in my opinion. I try to apply my experience to how the development team works at Baserow, although every new hire brings valuable ideas on board.
We typically hire full-stack developers who have backend and frontend experience because we want a single developer to be able to build a big feature from scratch. This is because I think developers should have ownership over a task, and not constantly depend on other team members, which can delay the whole process. This also allows us to ship features fast without sacrificing on code quality.
In the early days of Baserow, I was still spending 90% of my time of writing code. This has unfortunately gone down to roughly 10%. I think it’s important to stay hands on for as long as possible, not only because I enjoy writing code, but also to share my vision as much as possible. The more I can share my vision, the more this will be transferred to new hires by existing team members. This is why team members that join early on make the culture within a company.
Nowadays, I can’t be deeply involved in the development of every feature, that’s why we’re splitting into smaller teams that are responsible for parts of the codebase. Each team will have a couple of full-stack developers and a tech lead. In the end, the tech lead is the person that I have the closest contact with, and the tech lead will have close contact with the other devs in the team.
The teams work like a typical software development team where an issue (task) is assigned to a developer. It will already contain a functional description and a UI/UX design. If it’s a big feature, we will often have a video call to talk about it in more detail. If needed, the developer writes a technical plan, and after approval the developer can start with the implementation. When that’s finished, another developer in the team has to review the code, and when approved it will be merged into the develop
branch, and will eventually be released.