Sonar’s Developer Advocates play a vital role in being the bridge between our developer community and our company. They foster collaboration, knowledge sharing, and innovation, ultimately contributing to the growth and success of developers through modern application development.
By establishing strong relationships with developers and promoting the value of Clean Code, they help shape the technology landscape and drive positive change in the industry. They glean key insights into our customers and community's wants and needs and help drive continued innovation in Sonar’s products.
We took a few minutes to sit down with two of our Developer Advocates to find out how they started their careers.
How did you get started in your career?
BEN DECHRAI: I started my first developer role straight out of university in 1999. I was coding in VB.ASP but quickly got into PHP development. When I moved to Melbourne, Australia, I got involved with the developer community, running and speaking at meetups and conferences.
Then in 2018, I was recruited to be a Developer Advocate for a US-based company, and I decided to close my consulting business to pursue the job full-time. I already knew that I loved engaging with the community and I was excited to dedicate myself to this.
One of the things I love about developer advocacy is that I get to represent a company and a brand that I believe in, and I also get to represent the community. It's about having an authentic conversation with developers about what problems they're facing. And it's not just about me trying to solve their problems. I learn from them as well, and that interaction is powerful.
Developer advocacy sits on the edge of the business because we are there to represent a brand and bring product awareness to developers while also capturing feedback for our product team. We get the best of both worlds - we make developers' lives easier and help the business we work for simultaneously.
PHIL NASH: I started in 2007 as a Junior Front End Developer at a digital asset management company. Back then, it was just building webpages and battling to make them work in IE6. I quickly got the opportunity to join an agency called Mint Digital, which was building its applications in Ruby on Rails, allowing me to understand the full stack. I was lucky enough to lead development on a platform where we used the Instagram API to turn photos into refrigerator magnets, which was a pleasing success.
While at Mint, I also got more involved in local developer communities. I started attending local events and hackathons and speaking. And that led me to my next role, a Twilio Developer Evangelist. That role allowed me to use my experience to teach developers worldwide about communications APIs - how to send text messages and make phone calls in just a few lines of code.
At the start of this year, I joined Sonar, where I’m happy to be part of the team spreading this message of Clean Code. You'll find me writing technical articles, working on open-source projects, or speaking at events to spread this message and use my experience to help developers build better applications using Clean Code principles.
When did you decide you wanted to be a developer?
BD: I first thought about being a developer when I was around seven. I relocated to the UK from Germany, and during that time, I remember being fascinated with computers. I attribute that primarily to my dad. He was a forensic scientist with a little home lab with testing machines and instruments. He had chemical reagent testing machines controlled by a computer, and I was intrigued by the intersection of software and hardware.
In the UK, we got a PC similar to today's, and I still remember being hugely impressed. I started programming in Basic and Assembly and just dabbling around. I loved the satisfaction of writing code and getting a computer to do what I wanted.
When Windows 3.1 was the primary desktop graphical user interface, I wrote software that allowed multi-user capabilities so you could save your profile and tinker with settings without annoying another family member. It was inevitable at that point that I would get into computer science.
Some think code is simple instructions that make the computer do what you want. But it is a creative process because there are many different ways to implement the same algorithm or make software do a particular piece of business logic. It's up to the developer to work out how they want to implement it and then make that happen. And once you've decided on an implementation strategy, even finer details can change.
PN: I was never really a child that knew what they wanted to be when they grew up. I didn't know I wanted to be a developer for quite a long time. But as I look back through my life, I can see a thread that led me to the point where I wanted that. The first interaction I had with a computer at school was with Logo, the turtle you gave instructions to that would draw things on the screen. Then at 13 or 14, I remember doing a class on HTML. I specifically remember building a page about ourselves, and I put things into a table and formatted it to my liking.
I did computer science at the end of high school, leading to a Maths and Computer Science Degree. When I should’ve been focusing on final exams, I was messing around and building websites for myself and people I knew, and I realized I could do this as a job. Once I realized that, I set out to get my job as a Junior Developer. I built a blog and started writing about what I was learning, ultimately leading me to become a developer about a year later.
Tell us about one of your greatest lessons as a developer.
BD: One of the things that I learned early on in my career was the importance of motivating my team. As a manager of developers, one of the biggest lessons I learned was that you could do more for a team by doing less. You can increase productivity by supporting the team as people rather than just helping with the coding side of things.
It's important, even if it's basic, like buying everybody lunch and ensuring everybody has a break to decompress. It was a huge lesson to reflect on - how my efforts could be best applied for the greater good. Where you think your capabilities are best directed is not always the right thing for the team.
PN: One of the greatest lessons I’ve learned as a developer is that there is far too much stuff in this industry for anyone to know. It’s the case that people are pushing the boundaries of programming and development daily. The more you learn, the more you know there is to learn. So taking a step back and understanding that you don't need to learn it all can melt that stress away. Instead, it’s just important to understand the fundamentals of the language and platform you’re building in, and from strong foundations like that, you’ll be able to learn anything else you need to when you need it.
What advice would you give someone starting as a developer?
BD: Today, you can't rely on generative AI tools to write your code 100% of the time. They are not a suitable alternative for a human. While humans may write buggy code, they can also fix buggy code. Your computer doesn't know whether the code is buggy just by looking at it. Right now, AI will not remove the need for software developers.
Humans are still a big part of the development process. However, if you want to be a developer, it's important to understand deeper levels of just the web development or the coding side of software engineering. Understanding good software architecture is going to become a lot more critical.
We'll get to the point where developers will still exist; they'll just be using AI tools to improve their productivity. We're going to be able to create software more quickly and reliably.
PN: If you're starting as a developer, write about your experiences and what you learn and publish them. There are an enormous amount of benefits to writing about your experiences. And they start with the personal. When you write about something as if to explain it to someone else, you have to dig a little bit deeper into your understanding of it to turn that into an explanation. You end up learning the subject with greater clarity and understanding.
If you create a library of your knowledge on a subject and publish this, those writings can go towards helping other people in the community. How you explain something can be the key to unlocking the understanding of someone else. Writing can also come with different opportunities, like networking and collaboration.
My entire career is based on the fact that I started writing about web development to learn about it. That got my foot in the door at my first two job opportunities. Continuing to write, learn, and publish led me to share that knowledge and developer relations as a job. I chose to start writing about my experiences right at the start of my career has led to many opportunities, and I recommend that you do the same.
As a developer, what does Clean Code mean to you?
BD: It means something is readable by the next person. Nowadays, it's more important to think about the next person who will read your code rather than what the computer does with it like we used to in the past when computers had limited memory and processing power. If the next person who reads it can understand what it's doing in a minute instead of 10 minutes, then you are improving the future performance of developers. You're more likely to identify business logic issues, security issues, and bugs as you’re coding rather than waiting for somebody to report an issue with your software.
While we like to think of ourselves as individual contributors that come together now and then, we are often more co-dependent on our teammates. How your team interacts is important; there's more communication going on than you think. Communication through Clean Code is as essential as rituals like stand-ups and retrospectives.
PN: Clean Code corrects me the first time. It means avoiding writing unnecessary bugs or overly complicated code or introducing security issues. It’s code that you’re confident to deploy to production but happy when you return to it six months or a year later to work with again. Clean Code is never legacy code - it’s always a joy to work with.
Read more of our interviews in these related blog posts:
- Interview with Sonar Python Developers Part 1
- Interview with Sonar Python Developers Part 2
- Interview with a SonarSource Developer