"I took a break from coding to write this." A Software Developer's story

At some point in your life, you’re going to need a plumber. Or a doctor. Or maybe even an electrician. They provide us with services we can’t do without: running water, life-saving medication, or the ability to see when it gets dark. But what about software developers?

At some point in your life, you’re going to need a plumber. Or a doctor. Or maybe even an electrician. They provide us with services we can’t do without: running water, life-saving medication, or the ability to see when it gets dark. But what about software developers?

Nowadays, software touches every aspect of people’s lives. It plays a central role in how we interact with the world. Without software, the plumber couldn’t order tools, the doctor wouldn’t be able to write prescriptions, and the electrician could never schedule service appointments.

Software is the driving force behind people’s day-to-day. However, its very nature as an intangible thing makes it something many people can’t relate to, or even begin to comprehend. As a developer, I’m well versed in these concepts. Being out of touch with the end-user, spending over-caffeinated days and nights working on something so abstract, but ultimately, to what end?

Over the past few years, I have worked for different companies with vastly different processes and corporate cultures. But here at Jonar, I'm in an environment that encourages respect, teamwork, and learning. For the first time, I truly understand and appreciate how the work I do every day impacts others.

It starts with a clear process

The Scrum Cycle is my single favorite aspect of how our development team works at Jonar. Dividing our work into two-week sprints allows a clear cut “definition of done”, as well as reasonably scheduled deadlines. Not only has it proven to be results-driven and efficient, it has changed the way I feel about my role as a software developer.

Every two weeks I face a brand new set of challenges, keeping me on my toes and preventing my days from becoming repetitive. In each sprint, there are a wide variety of tasks to complete: from research spikes to user stories, technical debt, and bug fixes. No two days are the same.

As the two-week sprint moves forward, I get to experience the progress first hand: basic ideas develop into research cases, and eventually prototypes. New features are designed and implemented. My own work is reviewed by my peers and eventually integrated into the system. When the two weeks are up, the progress is tangible and our work is shipped out to customers, ready to be used in live environments. The disconnect that usually exists between developer and user does not ring true. I know that my efforts over two weeks could have a real-life impact on someone... by tomorrow.

And, it’s driven by teamwork

Not only does the range of work differ massively, so does the team.

Every person in the development team possesses a different skill set and is motivated by different interests. Some have preferences in the way they code, others have an emotional attachment to parts of the system they’ve built. There are those who need a shippable product that meets certain requirements, others that desire clean code, no technical debt, and efficient algorithms.

So what makes the dream work?

Managing the difference in motivations, as well as simultaneously navigating the sprint takes place through negotiation. Team meetings take place every Friday, alternating between a Planning Poker and a Retrospective. During these, the development team prove they are no longer the ‘quietest’ department in the company, as passions often run high. The sole purpose of this time is for the team to voice concerns, speak honestly, and set expectations. Was a deadline missed? If so, why? Is an external factor affecting your project? What were last sprint’s learnings?

These debates provide constructive criticism and complete clarity, because what other way is there to improve the next sprint? Our CEO attends and we even invite other members of the company in to witness discussions. Mistakes are pointed out and people are held accountable. And despite all this, no one takes anything personally and feedback, whether positive or negative, is well received.

Supported by a positive company culture

In contrast to other companies I’ve worked for, at Jonar, my mind is deemed my most valuable asset. My physical presence in the office at 8:00 am sharp is less valuable than my optimized, well-written code for a new user-facing feature.

What’s more, the dynamic of how we get things done sets us apart. On an average day, I’ll indulge in coffee and ice cream, schedule my own breaks, listen to my favorite music, and share interesting conversations with bright individuals. In fact, I’m actively encouraged to do this. The workplace that empowers me both as a human as well as an employee, allows me to excel at my craft.

However, there’s no room for slack: the goals that need to be achieved are well-defined and within reach. The Scrum process holds everyone accountable. The team will be counting on me to get my part done, but they’ll also provide me with whatever I need to accomplish it.

Building bridges, both in code and between people

One of the biggest lessons I’ve learned in this role is that the diversity within development proves that the stereotype attached to us isn’t necessarily true. Software is not just about plugging code and programming ‒ it’s also about the people. It’s this overwhelmingly human side to development that motivates me and brings life to my role.

To me, software development is an opportunity to make the world a better place. Really. As a developer, I’m given a chance to contribute my skills to the community, building new tools to improve people’s daily lives and the standards by which they live. And, at Jonar, I have the means, the team, and the guidance I need to effect this change.

Alejandro de Majo