I was told that I need to give a 30 minutes speech at my welcome dinner tomorrow, hence I think I should spend some time reflecting on my time so far at Sonar. I decided to write it down because I believe writing is the best way to make myself become a resource for my future self. Inspired by this quote by Alex MacArthur -
“When you write, you become a resource for your future self. It’ll save you time (pulling up your own blog post is a lot quicker than a fresh Google search), you’ll get all the credit (instead of some Stack Overflow post), and it’ll make all that writing feel even more worthwhile.” - Alex MacArthur”
Why I joined Sonar
I joined Sonar because I want to contribute to the code security space. When I first heard about the company I was immediately reminded at how often do I interact with these tools and how much I rely on them to do my day to day job. I remembered when I was at my first company, we immediately started implementing Snyk into our workflow after having to spend painful weeks updating the log4j dependency that was compromised. Right after that, I had experience hearing about incidents regarding cloud platform database being compromised due not managing our secrets properly. And have you heard about the Windows Update that caused by a security update by CrowdStrike that affected all softwares in the airport globally?
It was clear that security is something that I can work on that will be very impactful for the society and it is something I should devote years of my life into. I remember scrambling to understand how does SonarQube API work and making my own version of dashboard and sent it to the hiring manager, the rest is history) for the code security statistics I get from it
What did I learn from the organization
Sonar is unique, by third week I can recite what the organization cares about - being Committed, Obsessed, Deliberate, Effective, new joiners like myself are encouraged to participate in other team's meetings, to speak for themselves and how they feel and are given tools to facilitate communications with their colleagues.
The organization is big, yet when you join slack you don't get bombarded or get added into every slack channel possible that exists. I find that refreshing and helpful. The main channel of communication is still email and honestly! we are very good at it - because we keep our inbox empty, we make it a habit to archive read emails. This subconsciously forces us to respect every email, and keep them very intentional
On the technical side of things, I am currently learning how to be an effective communicator and an organized coder when it comes to executing experiments and communicating the progress of the experiments. Bear in mind we deal with many programming languages, different code analysis setups, agents, datasets and LLMs.
What did I learn from myself
I started this new habit of journaling what I did at work everyday, and reviewing my old journal every now and then to make sure I am also effectively communicating with myself. Things like what are the tools that I have learnt that would be useful, communication strategies during stand ups/ways to resolve Python specific issues etc.
I used to do this at my previous jobs, I did the journaling part really well but not reviewing a journal from time to time and make sure it is tidy and information is reusable was a mistake. It ended up being a zombie table that I rarely looked at because it is very overwhelming.
What did I bring to the organization
This one is going to be tougher, I have been trying my best to keep up with all the ongoing technical discussions let alone start contributing but what I can say is I am building a baseline results for how our current agent is performing, so that we can use it as a ground truth for comparisons with any future fine tuning/changes that we have on the agent
Final Thoughts
I have some new ideas that I have for the team,
- Inspired by Google DeepMind's paper on agentic interpretability and how they brought up Vygotsky's Zone of Proximal Development (ZPD), I encourage everyone in the team to think about whether they are consistently finding areas of improvement by seeking help from a more knowledgable person in order to achieve a task that they think they can't do but is achievable with some help.
- Asking whether our agent needs more context engineering or fine tuning. Inspired by fine-tuning or retrieval paper by Microsoft and context engineering blog by Cognition
- Since the public has been obsessing over how many PRs Codex has merged per day for the past month (its 10k PRs per day btw), are we going to measure ACR on that? Related tweet
Credits
I would like to thank swyx for the quote and The Coding Career Handbook for the inspiration to start writing.