Five years ago I joined the QA team of one of the leading investment banks. This was the first time I worked in an investment bank. It was also my first encounter with kdb+.
How I got into q
It was luck. I was assigned to complete a task: to verify generated historical analytics. My manager gave me freedom to choose any technology that communicates with kdb+. I told him I would use q because it is native to kdb+. Nothing else would communicate better. That is what I said. But I was also thinking it is a niche technology that could win me respect and an advantage in the QA work. This technology could help my career.
Initially I worked with kdb+ and q on a Windows machine. I thought this was not ideal but it would get me used to the syntax. The syntax amazed and perplexed me.
Again and again I wondered, Why have I written the code this way? How can such compact code do thousands of tasks? I struggled to find a good coding style, sometimes unable to read my own code only days after I had written it.
I rode bareback, coding in Notepad. No IDE! No Intellisense! Old school.
Project constraints moved me to a Linux machine. The shift showed me the power of kdb+/q with Linux. Q just seems to work best with Linux.
Help was available: people with extensive q experience to whom I could put questions. But they were in a different timezone; answers arrived 13 hours later. A powerful incentive to answer my own questions! Or stay up late to ask by phone.
It got done; I completed the verification task. I presented it to my QA colleagues. A few were amazed. A few were confused. And a few did not understand what I had built.
The presentation was a wonderful experience. I still remember that demo.
People asked how many records I could verify in single run. I replied “There are at least 10,000,000 records in a days’s table to be verified. With this automation I can verify not just one day’s but a whole month’s data. This is the return from investing in this work.
People also asked how I installed kdb+/q on my machine; which IDE I use (Notepad!); which website I referred to (code.kx.com); from where did I get help (then the Google Group, now community.kx.com); how I store test results on disk.
My plan had worked. I could feel the respect I had won on the floor.
Not just my fellow coders. The head of QA head told me, “Don’t let anyone know you know kdb!!! The development team will want you.”
After that assignment, my colleagues started coming to my desk with q questions, instead of asking a q developer. I would write small functions and statements to simplify their task. But when I could not answer them promptly I remembered “There is lot still to learn. I am still a qbie, still not ripe.” I started making notes of the questions they asked.
How I got into development
In 2019 a second q assignment came my way. One of the q developers left the team. His work in progress had to be finished. I took it over and finished it. This brought me to the notice of the q developers.
Now I would ask other q developers to assign me tasks to grow my skills. One of the developers helped me as a mentor.
Ii is best to give back to society what you have. I started posting on LinkedIn what I have learned. I keep posts as simple as I can. “No jargon, no complex examples.” This is the first criterion for my posts.
Building up my question bank, I started interviewing for jobs to test where I stand in the market. But interviewers seeme to doubt my kdb+ experience. How could a QA guy move to kdb+ development? There is no precedent. They have seen QA guys move to Java or SQL development, but not into kdb+ development. Though I can clear the technical rounds, I still remember how shocked I was to hear “You nearly made it! Why did you tell them you were doing automation testing before kdb+ development?”.
How to get on
I study the development tools provided by KX and volunteer to beta test their products.
I attend Meetups. I don’t always understand what is presented, but I can always take screenshots and follow up on my own. I am learning QCumber, KX Developer, and KX Dashboard.
For better interview results, read “Q for Mortals”, create your own snippets, keep notes and spend some time thinking from and interviewer’s perspective.
Difficult roads often arrive at beautiful destinations. If you are unwilling to learn no one can help you – but if you are determined to learn, no one can stop you.
