What excites you about working on a Salesforce developer tool like Clayton?
I like that we are building a tool with a purpose. Every modern developer uses git and pull requests: we start there to make their lives easier.
I’m a lazy developer. I like to work smarter, not harder. We are building a tool for people like me, someone to delegate all the boring and repetitive tasks to. For example: what’s interesting about making sure that every database access checks CRUD and FLS permissions correctly?
The other thing that I like is using Clayton for building Clayton. Or use our own service to develop a better service. We enjoy Clayton and its positive vibes but also use it as clients to recognise and improve any weakness we can find. This is actually pretty cool.
What is the most challenging part of your job?
Above all, the growing complexity for sure. What do I mean?
You will soon face a growing customer base because new clients will come, hopefully.
They will request (for sure) to develop new custom features, but you can’t forget to support all your old components. Or maybe you’ll have to enable features on a flag and, therefore, support various scenarios.
And then, you face data migrations when releasing new features, while assuring SLAs, and introducing any regressions.
Well, I know. That’s what developers do. But you have to do it quickly and well on your first attempt.
Engineering complexity grows non-linearly most of the time, and if this is true in every company, it’s quite real for a startup, where complexity is combined with the vital need for business growth.
Your team competencies are the biggest resources you have. You never know, but you must be always ready to do something you never thought you had to do and challenge yourself.
As of today, Clayton scans about 22B lines of code/month. How do you handle this scale?
Three things: Always automate whenever possible, set alarms and actions to monitor all components, tests, tests, tests, and more tests.
So, if you have to do a thing twice, the answer is: always automate, but don’t forget to monitor what you automate!
I think it’s an indisputable double-truth, and honestly, we are totally close to this goal, at Clayton.
Also, unit tests give you a superpower: to be confident in refactoring. If you are, you can rewrite stuff without causing regressions, which means you can deploy confidently, even on Friday!
At Clayton for example, we scan 1.5B lines of code and we detect - on average - 150 new serious critical violations per day. Some complex scans can last several hours, so we usually manage different servers, with a scalable infrastructure, following our customer needs.
What advice would you give to a startup engineering team?
Choosing the right people and investing your time with them when they need it: they are your most valuable asset. And be always prepared to grow, from day 1 or even before. If you are not thinking about new developments with a scaling perspective, you are probably doing something wrong.
Anyway, there will always be the chance you are missing some skills in your team, thus someone has to learn something completely different or new. Or, when it comes the time, be willing to pay for a service that saves your problems and your agenda.
The second most important asset is having your time allocated on what really matters, for sure.
You’ve worked at larger software companies previously. How is working at Clayton different?
In a centralised big company, you can always go to someone's desk and ask for their attention. In a distributed startup, most of the time you can’t or is not that easy. If you need someone’s expertise, you definitely need to plan in advance.
That’s why sometimes your best choice is to balance the risks and take your decision.
Everyone knows what is expected from you, but the key point is to do the right thing at the right time and pay for the risks if something goes wrong.
.png)
