How I transitioned from humanistic jobs to tech and development and why it is possible to start from the basics.

In this post I'll cover my story. Not because it has great importance or anything, but because it could help somebody, I hope, to understand that is possible to switch career from a humanistic career to a technical one, up to become even an engineer (well, developing-code speaking at least).

It was not somehow decided voluntarily. Circumstances made me make that choice, but I'm very happy that those happened. At the bottom of the post there are few tips I learnt along the way.

Before the tech

I'm from Italy, I'm 35 at this moment and I got my first development job few months ago. Between 15 and 19 years old I studied in a technical high-school.
At that time the best part of the curriculum about Informatics (that's how it was called) was some coding in C++. I'm saying this not because it helped my actual career, but just the opposite.

I didn't learn anything (the peak of knowledge was drawing with code some geometrical figures) and after school I forgot everything. I bought some C++ books at the time, but I got stuck at some concepts like pointers (geez I still remember those pages) and I was very bad at math. So the interest and curiosity about programming just died there.

Fast forward, I took humanistic studies at the university, because I liked them more, and I was more prone and good at them. Eventually, I moved to Latin America and I started teaching languages, passed to commercial work in a language school, then take over the academic part of it.

That lasted few years, and eventually I decided with my wife to go back to Europe. We tried Italy with no success and after a little while I decided to accept a Service Desk position in a multinational company in Czech Republic. I mean, I understood a little how PCs are working and something else about the internet, so why not?

There I did the most basic technical support. But I was always willing to learn, even so because I had night shifts as well. I passed many uneventful hours to study (I did a short nap sometimes and I have also eaten though). At that time I didn't know what directions to take, not even which field to specialise on (I didn't even know devops was a thing), so I started with SQL and Unix command line. I'm not sure what triggered this idea, and why these specific fields.

These two skills were fundamental to my change of job and company. As a matter of fact, in the next one I started from a so-called level 1.5. It was an intermediate level between service desk and level 2, which is basically operations and maintenance. I had the luck that comparing to the level 2 of other companies which are providing very specific software support, in my new one I could have hands-on on exactly those skills I studied earlier.

A point here to make: all your knowledge is building on top of the knowledge you already have. The service desk was built on my high-school and passion skillset; the new job on what I built before, including corporate tech bureaucracy and procedures. And so on and so forth.

Building more knowledge on SQL and Unix allowed me to get promoted quickly, passing to L2.
For that particular project, it meant that I had to open up to a little of everything: investigation, analysis, data manipulation, deployments. And I had to know all the infrastructure, from the databases to the proxies, to the endpoints, oracle bus services and so on.
I didn't have access to the code itself of the applications (which were written in Java), only the exceptions and similar during the log analysis.

However, the broad scope of the team allowed me and my colleagues to think about automating things, and we had free hand to use whatever was more fitting.

So I started learning development, with Freecodecamp as initial resource, and complementing it with a course (just one? Yeah...) on Udemy. I finished the latter, but about the former I managed to go through the curriculum until the frontend projects.
I didn't complete those one though, as it was about time to put knowledge into work-related projects (it also rhymes right?!).

First and foremost I created my website with the tools I had. At the time I was not familiar with React so I did it in NodeJS with EJS as template engine (Javascript embedded into HTML). Secondly I started doing the project for work, still in Node (which was then my favourite thing to work with, and still is).

So I built an automation tool that allowed me or my colleagues to upload a file on a server of ours, and with just a simple interface and few clicks deploy a third-party vendor software and sync it with all servers. Of course, looking retrospectively, the code I wrote was very bad and with ....some... untracked bugs.
But it worked fine, although almost never crashed (just sometimes had to be double-checked) it was reliable and allowed the team to save hours of manual work.

That's just one example of what can be done. I followed with other small projects, eventually in React, so that I could apply what I was learning in real world applications.

Meanwhile I became a father of a very very active boy, so the time lessened more and more. But I continued to cut little pieces of time here and there to continue to learn.

Eventually our team was 'transformed' and we were assigned different scopes. So I decided to hit the road and start applying to developer jobs.

I used the tactic of quality over quantity. That means not applying randomly and en-mass, but selecting what I could actually do on the offers; check the company website, what were they doing; personalize a cover letter accordingly highlighting how could I help with my skills.

Before landing my actual job, I maybe applied to only 30 offers, or even less. And that was when Covid hit (so companies stopped hiring and started firing).

The best part of the interviewing process were the projects at home. I did have few board interviews, some went well, some less, but generally I enjoyed them because every time I was learning something new.
That's why it's said to start applying early in time, not to wait indefinitely that the knowledge of the language gets very good or excellent (which won't happen anyway in this phase). I actually waited too long.

Luckily I had many complete and detailed reviews (rejected) from my take home projects. From each I learnt something. Then from my actual company they were looking for a frontend developer. At the first interview I got already some experience on this aspect, and they proposed take home projects for both frontend and backend (Node). I decided to take them both. That's when persistence, enthusiasm and good will make a good impression on the candidates.

I actually failed twice on the FE position, but I insisted and got accepted on the BE one.

Lessons learnt

1. Don't give up. Every failure is a lesson learnt. You don't know how far is the goal but you are always one step closer.
2. If you come from other fields you can have the advantage of thinking more creatively. It's possible to find association of concepts. Sometimes it's easier to adapt some solutions from other jobs to the developer one. In my case it helped to know more (spoken) languages. Knowing the deep structure (philology curriculum at university) of a language helps understand some logic in the programming language (after all, it's all made by humans)
3. If you come from any humanistic field, usually you have developed some good 'soft' skills -or 'human' skills - especially communication, which is of great importance in a team.
4. You don't have to push yourself aggressively to the companies; persistence comes with gracefulness. But I found that after a review, if there's space for improvement, you can correct and fix your project and send it back to evaluate. There's nothing to lose, actually it'll make a good impression, even if not successful. Just be sure to not send back a project that you know for certain it will be rejected. People's time is valuable.
5. Sometimes the reviews are even difficult to understand, or you have no idea what some things actually mean. Give up on those and thank them, it means the requirements were actually higher than you thought.
6. Always thank the company after the rejection. They spent a lot of time reviewing your code and your CV, appreciate that.
7. If they didn't give you a review after a rejection, thank them but try to ask them for it. Maybe they'll refuse, or ignore you, but possibly they'll send it to you, and you'll learn from a good senior developer review.
8. Don't bother to insist with companies that don't give you any news at all, good or bad. It's a bad sign.

Feel free to drop any questions or comment!