The art of unlearning

The #1 skill to have in the 21st century is to “learn the art of learning”

The team at Versent was slated to join a new client on a micro-services project, running in AWS. Having done micro-services at a couple of gigs before, I was both excited and confident. Excited because the domain was a new one, and confident because it was known territory.

But boy, was that about to change, and how!

I’ve been writing Java professionally for close to 10 years now. I’ve done quite a bit of Python, C++, DevOps, Continuous Integration as well. As for the platform, I’ve always done applications that ran on the cloud, or in my past life, created the cloud itself.

My 22 months at Versent have been the fastest in my career.  Having done product development before, I wasn’t used to client facing roles, or getting embedded in teams at a client site. I’ve had to adapt quickly, learn quickly and be ready for change, all the time. But, it’s been an amazing journey so far.

The most important things I’ve learned so far – change and agility. Learning new skills or revising old ones has almost become second nature. But, still, I have never had to ‘unlearn’ something…

Two weeks into the new project, we found out that we were going to do micro-services in Golang. A language none of us had used before deep in the trenches. At the outset, the mood in the team was mixed. “Why should we give up all the SpringBoot / Java goodness that comes for free with the framework?” “Why should we wind back the clock 10-15 years and write filters and auth mechanisms?” The initial reluctance gave way to denial, but we managed to pull our socks up, and jump in.

What’s the worst that could happen, right? I’ll learn something new, I told myself.

Every day the team came across a new challenge. LMGTFY started coming up in every other conversation between the team members.

Technologists have always been on the edge, pushing the boundaries. Today’s software craftsmen and women will probably lose their development jobs within the next decade. Could we have predicted that the gamut of testing roles we had 7-8 years ago will go on the decline so quickly?

We’re seeing cookie-cutter patterns emerging in micro-services. Soon, somebody, (AI) will automate all that, and we won’t need micro-services engineers for the simple-intermediate implementations.

For a good portion of the initial sprint, we struggled with the basics. How should I structure my code, what is a package, how and where do I write tests? What are some standard patterns?

With Java, these things were a given. You knew where to find something in a standard micro-services project. You knew where your resources were, the standard ways of passing in configuration parameters, the controller, service, repository layers etc.

I didn’t realise it until the end of the first sprint, but I was struggling to unlearn all of this. Subconsciously, I was trying to write Java patterns in Golang. My code worked, but it looked like a high-school project. I wasn’t happy at all!

So, I started looking for the basics. What does an interface really mean? What is really happening when one is passing a pointer, or passing a copy? I started finding more about the philosophies and motivations that shaped Go.

“What is the ‘Go Way’ of doing X?” That became my goal.

So, after going through this process, here are my tips for the art of unlearning.

1.  Don’t assume

Since we’re used to a particular development environment / language, we tend to take some things for granted. For example, code structure, start-up scripts, testing methods.

Packaging structure in Golang is unique; what you see in the folder hierarchy may not be how things are actually packaged. This hurt us a couple of times. A thing as simple as folder structure and packaging taught us to not assume that things will work the same way as your preferred language.

2.  Let’s break down the problem

This one isn’t new, but it’s so important. Developing micro-services are in a way breaking down a monolith i.e. breaking down a problem.

We sat down, charted the basic layers of a micro-service, and started picking at it piece by piece. We identified libraries that could be used JWT / authentication, logging, routing, Swagger etc. At that level, we kept things simple. We tried simple functionality, in single functions without thinking of classes, and packages etc. Not having the burden of ‘where do I place this code’ when actually writing that code was actually quite liberating.

3.  Debug, a lot

This one is probably the most underutilised feature by developers. When starting anything new, we tend to pepper the code with ‘printfs, or log.info’ statements to get a sense of the execution flow.

This time however, we decided to debug the code from day one. This helped develop a good understanding of the standard libraries in Go.

4.  Identify patterns

As software engineers, we have been taught to do things in standard ways, and not create exotic components. This was one of the hardest things to unlearn and relearn for me personally. But, looking for these patterns, reapplying your previous learning, or an example from stack overflow, just scouring through GitHub repositories turned out to be invaluable tools.

I believe, at the end of this project, I will have had a deeper appreciation for Golang, as well as SpringBoot.

At Versent, we don’t leave any man behind, and this was exemplified by our leaders like Mark Wolfe, and Rhys Evans who constantly helped us along the way.

So, what are you waiting for? Go and unlearn!

Ravi is a software engineer passionate about craftsmanship, teamwork and camaraderie in technology. An avid foodie, he spends his spare time paragliding, playing with his sons and working on his ham radio.