Our answers on the Joel Test
A peek into our day-to-day working environment
Our intention behind taking the Joel Test challenge is to provide an insider’s look at what it’s like working as a software developer at Rustici Software. If our answers resonate with you, we’d love for you to apply to one of our open positions.View open positions
1. Do you use source control?
If you ever find yourself interviewing at a place that is not using some kind of distributed version control system, then you should moonwalk your way out of the interview. Just using source control is no longer adequate, especially for larger groups of developers. While a team of one, maybe two developers can get away with pushing straight to a main branch, eventually they will need to develop a process for pull requests, code reviews, and a branching strategy. It does not have to be a complicated process. In fact, if you can not describe it in a sentence or two, then it is probably too complicated. For instance, our approach is the following: We use a development branch and release branches, where every pull request to a release branch is reviewed by at least two fellow developers.
2. Can you make a build in one step?
We can build our products with a single command. Our development environments allow you to build and deploy your changes to a local test environment with a single command.
3. Do you make daily builds?
We still run nightly builds for one of our products. But we have moved on to running a build for every pull request. If a code change breaks the build, it should never make it into a shared branch, so we check to make sure everything still builds before we ever merge a change. All of our teams integrate automated testing to their build and release pipelines. We keep the nightly builds running because we have an extensive amount of conformance tests we run for all the learning standards we support. Those tests are important, but they take too long to run for every pull request that gets made.
4. Do you have a bug database?
While we like to joke that we have been bug free for years now, we do keep track of every bug in GitHub issues alongside the features and improvements we are working on. We also use templates for our issues, as well as our pull request reviews. This helps prevent us from filing issues without enough context for someone to resolve and ensures we consider the security and usability of a change even if it seems small enough to warrant a rubber stamp.
5. Do you fix bugs before writing new code?
In general, the answer is no. Bug fixing is important, and the more severe the bug the more important it is to fix it. But rarely does one benefit from dealing in absolutes. We don’t prioritize bug fixes over all other work. Instead, we weigh each task by its merits. For instance, a new feature that benefits 50% of our customers takes priority over a bug that impacts 10% of our customers. However, a bug that impacts 50% of our customers wins out over an improvement that benefits 50% (or less) of our customers. The point being, we work on the tasks that provide the greatest good, regardless of it being a bug or new code.
6. Do you have an up-to-date schedule?
We have a roadmap for each of our products. Most of the deadlines we have are self imposed, and we try to be flexible on dates whenever we can. Work life balance is important to us, so we set deadlines based on when the developers writing the code think milestones can be reached by putting in their best 40 hours a week. We grant autonomy and expect every employee to use that to accomplish more. In the end, we try to let our developers set the pace for their work and count on them to take ownership of their estimates (with the understanding that estimating larger pieces of work is hard). This is an exercise we talk about with some frequency, in an attempt to get better at it.
7. Do you have a spec?
For larger pieces of work, we write up a Technical Specification that covers several aspects of the work, such as: what we are building, why it is important, how a customer will use it, specific use cases, how to test the changes, the security implications of the changes, etc. If someone can’t describe a body of work concretely in a few sentences, it deserves a tech spec.
8. Do programmers have quiet working conditions?
Every employee at Rustici Software gets their own office. We also have some shared spaces with couches and comfy chairs that people can choose to work in when they feel the need. Our office is a really great space. Being heads down on a problem by yourself in your own private office can be great, but even the most introverted of us want some interaction. During those times, people hangout in one of our shared work spaces, out on the deck, or in the pong room. Rustici is also an onsite/remote hybrid office. We can’t control how quiet someone’s house is, but we do provide really good headphones.
9. Do you use the best tools money can buy?
We consider a laptop, monitor, peripherals, desk, chair, software, etc. as tools of our trade. We want people to do their best work, so we buy them the best tools for the job. We also provide everyone with a sit-stand desk, and the chair of their choice. More importantly, we have a magic whiteboard in the office. If there is something you need (or even just a specific snack you want), you can just write it on the whiteboard and it magically appears in the office (usually within 2-5 business days, shipping times for the magic whiteboard can vary).
10. Do you have testers?
We have QA Engineers, which I think is an important distinction from “testers.” Our QA engineers do run manual tests, but they also automate whatever they can. Our QA engineers are critical. Besides just testing (and often breaking) unreleased features, they have a good understanding of what our products do and how our customers use them. Some of the most valuable feedback they give doesn’t come in the form of bug reports, but rather in suggestions of how the changes can be made even better.
11. Do new candidates write code during their interview?
Often, coding in an interview is cited as being inefficient, not scalable, and possibly an unfair burden on the applicant. I agree with all of those sentiments to varying degrees. Coding ability is just one aspect of what we look for in a developer. We look for strong communication skills, personality traits, and a variety of other qualities. We also incorporate code tests on the front end and back end of our interview process. Our aim has always been to get a good assessment of a candidate, in the least amount of time possible. But we also weigh the cost of hiring the wrong person as being much more than missing out on a good hire. So we take our time, and try to collect as much evidence needed to make the best decision. This is a process we consistently try to hone. If we ever find a way to consistently identify good candidates without a coding test, we will let the world know.
12. Do you do hallway usability testing?
The short answer is no. We cover this as part of our code review process, and our QA engineers also provide good usability feedback. This is definitely a place where we have room for improvement. If a feature rolls out that has usability issues, we usually resolve it as quickly as possible. Our support team and developers provide a tight feedback loop with our customers. Many of our customers are software developers, and our developers often work directly with our customers to help them solve their problems. This allows us to listen to their pain points customers are experiencing and iterate to alleviate those pain points whenever possible.