(Originally published on Medium)

One year?...time certainly flies, but the most important thing is that it flies when you are having a good time!

Jumping outside Academia

This story deserves a whole post and I promise I will write it at some point, but at the moment the only crucial information is:

• Every PhD is different (duh!) and I don’t encourage people to abandon their studies, but if you don’t feel comfortable, maybe you should consider it to improve your life.
• Most of the grants really value the number of publications you have as something related of “how successfully you are”, which I don’t think is correct.
• There is a lot of things you can improve in any research institute if you have some tech knowledge, since in most cases the latest technologies are not being used.
• I prefer to work on teams, because I really like the discussion with peers, and the last years of my PhD were everything but that.

How to not be afraid of your skills

During my PhD I did mostly C++ and Python, but for things that are not so complicated, from a “code” point of view.

I wrote a N-body integrator in C++ with some Python utils (GraviDy), but the hardest part was understanding the physics behind, not really the programming part, even though I was using CUDA for the GPU-side of the integrator, it was nothing impossible to understand in a couple of hours.

So, when I started looking for a job, my skills were those, C++ and Python, but nothing fancy like C++11/15/17, TensorFlow, PyTorch or anything like that, which were the specifications and technologies I mostly saw on the job offers.

I considered myself a good programmer, but there were always things I didn’t know, or I was avoiding to learn, so this was the main motivation: I had many things to learn.

Only a few C++ jobs appeared on the job-offer platforms I checked, and a couple got my attention, after applying to ~10 places, I got 3 offers, one of them by The Qt Company, which after a couple of days I decided to take.

I have been officially on the PySide2 Development team, the official Python bindings for the Qt project.

Learning C++, but for real this time

Before the interview processes I started to learn many things about C++11 which were completely new for me, I ended up with many, many pages of notes from tutorials, interview questions, language overview, etc.

I was prepared for a C++ company, or was I?

As soon as I got to the office on my first day, I started to look at the code base, and many really weird things...

I think I don’t really know C++...

Don’t get me wrong, I was comfortable with anything related to OO, templates, lambda functions, and stuff, but the amount of lines which I didn’t understand motivated me to really learn more about C++.

At least I know Python…right?

Most of the prototyping and data analysis that I did during my PhD was Python based, hence I felt really comfortable writing Python code, but…working with bindings is totally different.

This time, I was playing side-by-side with the Python C code, CPython, which I heard about a couple of times in my life, but nothing else (I had some painful experiences with SWIG, and did some small stuff with Cython, but anyways...)

CPython is nothing else that the C code which Python is made of. Still, it was really nice to see how Python was really structured, and that every time I was doing simple things like my_list = [], so many weird things were called under the hood.

So...you get the whole picture right? I was learning C++, and the C code that runs under our beautiful Python interpreter that we use every day, so I guess challenging is the word that would describe this process.

Let others review your code

Git? of course, all my little projects were on Github.

The Qt project uses Gerrit, a code review platform that allow your peers to review your commits and decide if it’s good enough to be on the Qt code base.

I still remember my first commits. I was scared as hell.

Even though my English improved a lot during my PhD, my first commits were full of nit-picking comments, which make me feel that even my communication skills needed to be improved, not only the programming part.

After a while, you get used to this mechanism and the famous phrase

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live”

started to make sense.

I never got a harsh message, or something offensive, the company and the Qt community were really welcoming, which is crucial to feel comfortable contributing to a project.

Working on a new project

Thinking of joining a team that just maintains a project doesn’t seems really motivating IMHO, but I was really lucky that PySide2 was not even officially released.

An project in development has a lot of place for improvements, and this was fantastic, because I was able to try new things: from writing documentation, tutorials, modifying the code architecture, to even hosting some webinars/talks about the project.

The Qt company doesn’t feel like a real company (positively), the freedom that each developer has on their projects is really nice, but since it’s an Open Source project, your work will be reviewed and discussed by the whole Qt community, not only your colleagues.

The idea of working in a suit, registering my working, having many meetings, or reporting my work every day was completely destroyed by this experience, and having the freedom to work on a project like this, made me perform better than I was expecting.

Qt was not really new to me

Around 2009 I started to use Qt for a project at my University, which consisted of an IDE to write Arduino procedures (Look at the video, it was really cool!). And after that, I got motivated enough to start promoting Qt in other projects. One of those was the ALMA Common Software (ASC) group at my University, which I joined in 2009 (ALMA-UTFSM, now called LIRAE).

ACS was using Java for their interface side, and using Java (censored rant about JAVA). I was trying to get some control software at the ALMA observatory to be written in C++ or at least Python using Qt.

Qt was (and still is!) the option for writing graphical interfaces, and even though I tried GTK and even tkinter (I’m sorry but sadly it’s true), it still feels so nice when I start playing around on my personal projects, like it was when I discovered it in 2009.

So what?

The main idea of writing this was for a couple of things:

• Don’t be afraid of not being the best programmer in any language, usually companies allow you to learn and understand their workflows and technologies as apart of the job itself.
• Keep in mind the working environment you want. Are you a lonely wolf? Are you a team player?
• Usually when we think we know something, companies could be using features we are not even aware of, and that’s OK :)
• Learn to write good code, because it’s highly possible that it will be reviewed by your colleagues…or maintained by a violent psychopath who knows where you live.
• What is more important to you? Improving something already created? or starting something new? Usually this is not advertised on the job-offers, but I believe it’s crucial to start a new career.