What does pragmatism mean? Dave Thomas and Andy Hunt wrote a full book talking about this. Just read the book. Here’s a TLDR for the impatient:
Pragmatic programmers know that there’s no such thing as perfect software. They know that change is the only constant, so they design the software to make it easier to change. They take responsibility for their work and communicate with teams in the language they’ll understand.
Software engineering is not about perfection, it’s about trade-offs. We reason about various approaches considering the trade-offs they offer. Instead of trying to build a perfect solution, we’d rather build a “good-enough” solution that does the job today and can scale for tomorrow’s needs.
Pragmatism is one value that we expect everyone on the team to adopt. In fact, it is so important for us that we have it as part of our tagline:
Pragmatic software engineering, released to production.
Nobody wants to work with brilliant jerks. We don’t either.
Software engineering is a team sport. We don’t want know-it-alls who work in silos. We want people who are honest about what they know and don’t know. We want people who complement each other and help each other learn and grow.
We strive to create an environment of trust and psychological safety needed to speak freely. From your side, we will expect you to be honest instead of hiding behind faff or excuses. We don’t like people justifying failures with blame games on their team members.
e.g., In an interview/pairing session, if you aren’t confident about an answer, say so instead of beating around the bush. That will be appreciated and not held against you.
We really care about our craft, really do. So if you aren’t passionate about software engineering, it could be overwhelming, and you may not enjoy the environment.
We like people to ask questions, share knowledge, and think of better ways to do things. We enjoy conversations that help each other grow as professionals. We have communication channels, tech sessions, etc., where people regularly share tips, guidance, learnings, experiences, and resources to hone each other’s skills. We expect you to participate in this give and take, not because we ask you to, but because you like to.
At One2N, we focus on bettering the craft instead of just the tools and technologies that keep evolving. A good software engineer needs to choose tech based on what problem they are trying to solve, not try to force-fit a shiny new tech so they get to work on it.
If you join us, we want you to take the initiative, ask questions, and explore what you don’t know. This shows passion and care for the craft. We won’t be giving you a textbook path to everything.
If you say you’ll do it, do it. Build a reputation such that others have full confidence that you will do it.
Taking responsibility means doing what it takes to get the job done. It does not mean working extra hard. It means coming back and asking questions if you are stuck, thinking of alternative solutions and workarounds, highlighting the roadblocks early, and taking the job to a logical conclusion. It might sometimes mean, “we tried everything but don’t have a feasible solution”. The crucial ask is to simply try various options.
e. g., you are told to get a glass of water for someone. You go to the water cooler and realize it's empty. Do you stop there, or do you figure out a solution and go back with that glass of water?
Take conscious responsibility for success and failures. Both are a part of the game.
Many people say they like to learn, but few like to actually study. We want people who take learning seriously and study.
In a world where change is the only constant, continuous learning is non-negotiable for growth - personal or professional. The one constant job for a software professional is to simply keep learning and be updated about the domain.
We do not believe in tenure-based career paths. When we evaluate you for hiring, your potential to learn is more important than the experience in years mentioned on your resume.