The Fireside Edition

After listening to the “Fireside edition” of Go Time, I questioned myself, how would I answered the questions the hosts discussed.

Because no one has asked, you are very welcome:

1. If you had two weeks to spend on a personal Go project, what would you work on?

I really want to invest more time for profefe. Specifically, on implementing an analyser of stored profiles: the thing that would help to make sense of the data, showing how the performance of an instance, a node, or a cluster had changed over the period of time; how different parts of the codebase had influenced the performance of the application.

Recently Amazon has announced CodeGuru profiler (currently Java-only). From the description it feels exactly what I pictured in my head when I started the project.

Another topic that I would like to invest more time on is the understanding of the ecosystem around/inside Kubernetes. During the past two years, I slowed down the consumption of the DevOps/SRE topics, mostly due to the specific state of the infrastructure in our company. But, “k8s is the new linux”, regardless of what one’s opinion on that. Even profefe recently has ended up having a kube-profefe (a bridge between profefe and Kubernetes), contributed and maintained by other people.

2. What annoys you about Go of 2019?

The same small things that annoyed me in Go 1.4: var, new, make and “naked return”. Sure, I understand that they all ended up in the language for a reason. But I simply don’t like the “magic” of make, which works only with particular types; the two ways of defining a variable (var or :=), or a pointer to an instance of a type (new or &T{}).

One new thing, though. Go modules’ semver imports. But I can’t say anything new about that. Probably, I just need to embrace them. Go 1.14 looks like a version where I might completely switch to modules, thanks to better handling of vendored dependencies.

3. What’s your ideal working environment?

That always surprises me. Lots of people keep saying that working from home is their ideal environment or even a factor that influence their job offers choice. I don’t like to work at home. The only time when I feel productive when stay home is in the nights. A café or a co-working works sometimes. But I like working in a big office space. I don’t know why.

Of course, open-plan offices can be very different. Yandex’s “Red Rose” is still the best space I ever worked in. I heard they do excursions around the Moscow’s office now.

3.1. Something on pair-programming?

Since I wrote about Yandex.

Some people think pair-programming is a sort of super-power. It’s, and it’s not. You can’t just put yourself in an environment, where someone is watching how you write the code while trying to hold a conversation about the code architecture. Pair-programming is a skill to master. But it pays off.

The pair-(trio actually)-programming sessions we did in Yandex, when we worked on bem-core, was the most significant skill boost I had during the five-plus years there.

Of course, the positive experience comes from your peers. In my case, they were people with huge baggage of knowledge and practice of working, talking, debating with each other. Like, out of nowhere, you get the understanding of what types of questions you must ask; when it is important to spend more time on thinking and when you can make a small hack.

4. Your advice to you junior-developer self?

Don’t overthink and afraid of starting anything. Trying something by making a raw, dirty, barely-working prototype will give you way more knowledge than thinking about how to do that.