Do you need X years of experience in Y

... to actually do your next job? (The picture above is the illustration of different but adjacent tools doing different but adjacent things)

I've been thinking lately about how much hard technical skills are actually transferable between different branches of software engineering. Out of a conversation with my friends in the last couple days I got some interesting thoughts:

• Job descriptions often list hard requirements of experience with certain tech
• They often appear to disregard other software development (or tech in general) experience
• I have however done quite complicated stuff without prior experience with some technology X

So, what gives?

Statement

We often see this kind of requirements (I cherry-picked some examples from the quick Linkedin search):

• Active participation in the development of production-ready REST API services written with ASP.NET Core and/or .NET5+.
• Minimum 2 years of experience working with React
• 2 years of professional experience in writing Python code as part of your job

It's often the particular technological stack, and if you don't tick these rather specific boxes, it suggests that you're not cut for this job. I find it quite silly to ask for these specifics, and screen out the candidates that do not meet (and I know that people are indeed screened out):

• Wouldn't a person who had some other REST API service experience (say Flask) and experience with C# outside of ASP.NET, be capable here?
• Is React that special, that we disregard people with frontend experience with other frameworks?
• It is often the case that people use different languages even within the same company on different projects, isn't it? What about that?

This feels rather short-sighted to me, especially because I have done the jobs without prior experience, picking up tech X that's new to me rather quickly. And it's not that I want to call me special here, I've seen a lot of times my peers successfully doing just that too. So for the rest of the post, I'll just list out a few cases from my industrial and academic experience to illustrate this point.

Cases in point

Mathematica for gene expression distribution fitting

When I went into my PhD, I knew very little about single-cell gene expression data/patterns/analysis methods. I have just finished the MSc in Bioinformatics, but I've mostly worked with protein data there. Nevertheless, I had to quickly figure out how all of this works, and what can we do with that.

At one of the lab meetings, my supervisor suggested "Why don't you do distribution fitting on this data?" Well, I replied that it might be complicated with the stack we currently have on the project. "Can't you just do it in Mathematica?"

Wolfram Mathematica was a tool that I've had used until then. So I had to figure out the Mathematica itself, then how to properly do distribution fitting on our data, then how to do it quickly enough for the large datasets that we have. And you know what, I did. That notebook is now an essential part of the paper that we've subsequently published.

What prior experience helped me?

• General biological and bioinf knowledge acquired in MSc
• Rather brief, but existing experience with Matlab from my ML and Computer Vision courses; they share similar concepts
• Fundamental knowledge of statistics (without that this whole thing wouldn't make sense to me), and software engineering best practices (as you'll see, I often refer to them, as they are common amongst different languages/frameworks/tools) so that my labmates can use and maintain that when I leave.

OCR for the medical studies

When I first joined the company I work at today, there was an image processing project for medical research. The system was basically a Flask service, with a few endpoints, one of which would do a bunch of image processing with OpenCV and OCR with Tesseract, and then upload the results to the cloud (SQL and a storage bucket). At the time, the code base was already large, but test and documentation coverage was rather subpar (by our company's current standards). Have I done this kind of complex image processing things before? No, not really. But I have quickly grasped how I should do the tasks given to me.

What prior experience helped me?

• I've seen different large code bases before (during studies and pet-projects), software engineering patterns are common (yeah, again, I'm talking about best practices, they help to read too)
• Having theoretical knowledge about possible image processing techniques (even though I haven't used OpenCV or implemented most of them myself before)
• For that project (and, often, generally) it was useful to know what my code editor can do. Searching for references and definition, interactive debugging, all of those things are really useful for understanding the code base

Multiprocessing in Python

For the same project, we wanted to speed up the processing of the documents. The idea that came to our mind is to split the job into chunks and do them concurrently. I have known of multiprocessing before, but I've never done this kind of things with Python. Well:

• Being organised, keeping notes of the code iterations, keeping the performance numbers, etc. Treating these kind of things as small research projects basically.
• Knowledge of how multiprocessing is done theoretically; I had it as part of my OS course module, plus I've read some materials in my own time. So, fundamentals, again.
• Knowing your tools helps. This time it's the profiling tools that are available.
• Having the documentation for what I'm working on ready, and reading it carefully. I haven't mentioned this before, but I'll mark it for this case specifically. For more stable tools like Python the documentation can answer many questions.

"Smart" job scheduling on Kubernetes

Different client at my day job. The task was to write a management Go service that would scale pods for Kubernetes jobs dynamically in "a smart way" (we don't need to know how here, we just need to know that the default strategy did not satisfy the needs). Well, I'd heard about K8s by that point. I'd seen Golang once before. I've spent a day practically learning how I operate a K8s cluster. There was a lot of unfamiliar concepts in both K8s and Go. Nevertheless, after a day of warm up I've started working on the thing itself.

It was challenging, not gonna lie. There were a lot of unknowns for me. But yet again, it was quite possible:

• Fundamentals, fundamentals, fundamentals. This whole thing was practically a set of distributed systems, and the scheduling problem. I had theoretical knowledge on both of those by that point (different depth, but still)
• I had decent experience reading and writing in a handful of different imperative languages by that time. Go has its quirks, but it still shares a lot in common with the other languages.
• Reading the docs is important. Knowing how to read technical documentation, and how to search for the unknowns is the key.

Real-time data collection with Typescript

Another client's project that I've essentially kick-started was a rather large real-time data collection system. They used to write everything in Javascript (Node), but they wanted to switch to Typescript, so this new thing was to be written in TS.

Well, I didn't know TS, but:

• I had previous experience with Node.js and strongly typed languages separately. It wasn't too hard to bridge the gap.
• Again, this project was a lot about engineering best practices. A common theme huh.

Godot at the game jam

The most recent example of this is my entry to the Fishing Game Jam, Reel, Roll, Repeat! I decided one week before the jam, that I wanted to check the Godot engine out, I've heard some good reviews of it. Never used it before. One day before the jam, I install the editor, I go through the tutorials. Next day, I'm jamming, implementing the idea that I had. No major issues (I actually liked the tool, it's pretty neat).

Why?

• GDScript as a language is heavily inspired by other languages that I've already used (to different extent, but still)
• I have had previous experience with game development, back in the day we've done some things with Unity3D and Marmalade engine (I think it's actually discontinued sadly). Even though I hadn't done much there, it was still valuable, 'cause you see patterns similar to what you've already seen before.
• Yet again, fundamental knowledge. Godot games are in their essence event-driven systems. I've seen those before. I've written them myself before, outside of gamedev entirely.

What does it all mean?

This post is a bit chaotic. But what I want to point out  is the requirement of "X years of tech Y" that we all see way too often is kinda arbitrary and meaningless (nope, I have no good advice to people hiring devs either).

After quite a bit of self-reflection, I'm not going to say that "I just learn new tech quickly" anymore, 'cause it appears to be quite more nuanced. It's the collective prior experience that lets me pick them up quickly.

All of the cases I've listed here are rather different, but they do share a common theme of things that help picking up new tools/languages/technologies/you name it.

• Fundamental knowledge: be it computer science, software engineering practices, or domain knowledge; knowing the fundamentals helps a lot along the way (and you more often than not expand this knowledge while learning about a new thing)
• Wide tool experience, reading/writing/looking at a wide variety of things; if I do not limit myself to a fixed set of tools, soon I end up in a situation where a new toy looks really similar to what I've used and done before.
• Know your instruments and documentation; the editor you use is probably more helpful than just a text box, plus knowing how to troubleshoot things in general (where's the tool documentation? stackoverflow? community forum?) makes things go smoother.

So yeah, learning new things is fun. The more you do it, the less painful it becomes it seems. Of course, to master game development I still need to actually built more things like that (and Godot will probably be the tool for some time now), but pivoting from what one does right now into an adjacent field, may not be as hugely difficult as some people portrait.