Development @ SI

Everything starts with experienced developers: Kolja, Peter, Matt and Jesper have worked at Small Improvements for around 10 years, Laura for 6 years, and Aina and Sebastian for 2 and 4 years.

Experience isn’t everything of course, it’s just as important to apply all those skills pragmatically while working towards shared goals. But it sure helps to know the codebase well, or to be able to turn to someone who does.

Everyone is also a learner and keen to improve their skills, and highly receptive to feedback. 

The codebase is certainly not perfect, but it’s in generally good shape, with plenty of tests to prove it. Sometimes we rewrite a feature from scratch to get rid of older code, for  example we just rebuilt our frontend tables with TanStack and our charts with Recharts. We’re regularly upgrading core tech like React or Java, and we’ve happily replaced webpack with Rspack. 

But we’re unlikely to follow the latest trends and incorporate something just because it’s new and shiny. Most development is incremental and happens in existing code, and we want to see clear benefits before throwing out the old. 

Every senior developer will eventually work on every part of the codebase. So a learning mindset is crucial, and the perspective of working on highly diverse tasks should excite rather than scare you.

Naturally everyone has their favorite code areas, and we value efficiency as well, so when choosing tasks from the queue it’s fine (to a degree) to favor those you’re most comfortable with.

But there is definitely no “off limits” code, and we expect everyone to have an interest in the entire code base eventually, so everyone can jump in at short notice if an urgent bug should strike.

We strive for high throughput at high quality. Having to put out fires at short notice would ruin both, and so would overly tight deadlines. So we’re careful in planning, testing and deploying.

It’s extremely rare that we need to deploy emergency fixes, and we’ve never done so between midnight and 9am so far, let alone on weekends. But if there’s an incident, we need all hands on deck until we know who can fix it. This could happen maybe once or twice per year after working hours. One person is on pager duty all the time.

A base set of automated tests must be run before committing code to master, the whole set of thousands of unit- and integration-tests is then automatically run on our build servers.  Failures are attended to immediately.

Twice a day we auto-deploy master to staging servers, every senior developer can deploy and take live from master any time from Monday to Thursday before 4pm, and everyone can deploy branches to QA servers anytime. 

Developers are expected to test features manually in order to ensure we didn’t miss anything obvious, but more complex features undergo additional QA by the respective PM.

Security plays a central role, even if we don’t work on security tasks all day. We conduct Pen Testing roughly once a year (see latest Executive Summary here) and we have an ongoing HackerOne project that regularly finds us low- to mid-prio issues. High priority issues get fixed at once, low-to-middle get slotted in at a regular pace.

We almost certified for ISO27001 – the bureaucratic requirements stopped us in the end, but our external auditors were quite impressed during our pre-testing. You can find more about our practices in our security center.

We work exclusively with pull requests, and all undertakings are code-reviewed before they go live. Code reviews are always the top prio before starting new work, as seen on our prio queue on the left.

Our main goal with code reviews is to save time in the long run: We invest a bit of time upfront, but avoid major problems in the future, and ensure knowledge-sharing as a side benefit.

It’s fine for a reviewer to raise aesthetic issues, but we don’t strive for perfection, and if the code’s author doesn’t see the necessity,  the reviewer must decide if they want to improve something on their own.

Our position is clear: We expect team work! Due to our remote character the actual coding happens on your own, but it’s always based on discussing things intensely before, during, and after the fact,  usually in writing (Slack, GitHub, Linear), and sometimes also during zoom calls and pair programming.

So no silo work, although one might be working for hours without actually talking to someone.

In addition to development tasks, you will also be collaborating with PM a lot: Feature tasks and specs are never set in stone, but require both PM and Dev input and iteration (see our product process for details), so it’s definitely a role for people who enjoy team work.

Out ultimate goal is to deliver value, and we do this best as a team. Check our release notes to get an overview of what we launched the past year.

We want to learn, and we expect everyone to share their gems. Interesting articles can be shared in Slack, but deeper knowledge sharing happens in our weekly DevExchanges.

On the side you’ll see the agenda of a typical Dev Exchange.

We expect everyone to be an interested listener and occasional speaker. 

The DevExchange is also the perfect place to propose and discuss improvements to our processes. We expect every senior developer to actively shape how we work.  Champion improvement, no grumbling!

We set aside time for cleaning up old code and working on security improvements. Code quality is very important, but aesthetics are not.

So we don’t refactor old code for the sake of it, but wait until major work is needed in that product area anyway, then we rewrite from scratch.

Old code that’s ugly but known to work (and doesn’t hamper our other projects) may linger for a few years. We’re pragmatic.

We hope we could answer the most common questions about how we develop. You can learn more about our product  process, about our team in general, about our values and work ethos, and if you’re interested to work with us, proceed to our Senior Developer Job Ad over here. 

All the best from the Dev Team @ SI