Since this post was too long for devrant's 5k sign limit, I split it in several parts. I will try to make each part comprehensible as a standalone post. This is part one of WHY WOULD I WANT TO WORK WITH YOU? saga. A tale of empathy, competence and me being a dick, even though I didn't really want to be one. The part one is titled: "Bad times, good times". It may or may not have any value. It probably won't be funny.

I dedicate this to every single junior or entry level dev out there, struggling to find a job in their field.

=====

What do you think, how long does it take for junior with 6 months of commercial experience to find a dev job? If your answer was "idk", you're right. If your answer was "3 montths maybe", you're also right. At least this is how long it took for me. I am writing this at 2am, couple of hours after I managed to get employed. I am happy. My employer probably is happy too. My recruiters certainly are. The guy whose offer I had to reject after we were almost ready to sign the contract, on the other hand, isn't. He probably hates me. We'll get to that one post at a time.

Let's move back in time a little bit. It's December 12th, 2019. It is third month after I left my family home. I don't ha0ve a job, I was living first in my older brother's apartment for a month, then I started to rent my own. I have literally no money, I'm in debts. I moved out because reasons that would make up for another couple of posts, and for said reasons I refused to get 'any job just to pay the bills'. You can imagine that I was in pretty bad situation, and my psyche didn't really take that shit too well either. My daily meal was a bowl of rice with a little bit of self-hatred on top. Gourmet.

At that time, my daily routine would consist of practicing music, practicing programming, trying to get a job and surviving. Some of my friends just turned their backs against me. I did a small rework of my contact list as well. It was a *hard* time. I had sent my CV to around a hundred different companies with very little to no response. Some of them required at least bachelor's in IT for their frontend dev. Some of them required experience I didn't have. Some of them just didn't care to answer me. And then that one day happened. Three different people wanted to meet me and talk about internships/job offers. I will share what happened next in next posts, but here's a quick spoiler. I got a job. Yes, I am hyped.

Dear fellow Dev. This is a small reminder. If you're having bad times, just remember that if you focus on what you need to do, you will be just fine. Sometimes it may take days of struggling, sometimes it will take months of eating mostly rice. We all... Most of us have been through this.

Next posts will be less inspirationalstufftelling and more storytelling. Let this post be a setup, a small context to keep in mind upon reading my next stories. Because it is quite important. For me and for the story.

That’s it I’m done with writing documents like Software Product Specifications and Software Requirements Documents and Software Architecture Documents, manuals, data sheets and more in MS word..

I’m doing it all form this point forward in LaTeX... I can stay in my editor, it works beautifully with version control because it’s just text... I can split it amung multiple files.. it looks damn sexy. I can focus on the content rather than being distracted by formatting and spelling issues and the rest of that shit.. ALSO.. it doesn’t crash or get corrupted.. well at-least I’ve never had a text editor crash or corrupt my files.

Idk why I didn’t learn latex sooner and do the switch.

Recently installed SonarQube and its been amazing to see the level of code quality (or lack thereof)

Some projects have 30 to 60 days of technical debt and I found a few files with a cyclomatic complexity over 100. I’m still learning what the “good” numbers should be.

Yesterday, couple of devs were very proud they were going to start reducing the numbers, they started with one of my solutions that had 5 minutes of technical debt. Yes, 5 minutes.

DevA: “OMG…look at this…it has a cyclomatic complexity of 11…that’s terrible. I thought we were supposed to be professional developers.”
DevB: “And take a look at this, he used the double-slash instead of a triple slash for comments. How does any of code even compile?!”
Me: “Maybe we should tweak some of those SonarQube rules so they make more sense to our code base. We’re never going to use unicode, so all those string culture warnings should go away and code comment formatting? Who cares? Be happy we have comments. I think we should also focus on the bigger fish in that pond. The CRM project is one of the biggest and has a lot of improvement opportunities.”
DevB: “There you go again, don’t bring me problems, bring me solutions..ha ha”
DevA: “Yea, no kidding …hey…did you see the logger? OMG…the whole class is over 25 lines…we gotta split that up into smaller projects so it’s more manageable.”

It’s a good thing our revenue stream isn’t dependent on people getting work done.

PSA: surpise-sending play-by-play instructions via chat on how to answer questions in a phone interview happening IN REAL TIME is not helpful and makes me look like a blubbering idiot

thanks but no thanks

A very long rant.. but I'm looking to share some experiences, maybe a different perspective.. huge changes at the company.

So my company is starting our microservices journey (we have a 359 retail websites at this moment)

First question was: What to build first?

The first thing we had to do was to decide what we wanted to build as our first microservice. We went looking for a microservice that can be used read only, consumers could easily implement without overhauling production software and is isolated from other processes.

We’ve ended up with building a catalog service as our first microservice. That catalog service provides consumers of the microservice information of our catalog and its most essential information about items in the catalog.

By starting with building the catalog service the team could focus on building the microservice without any time pressure. The initial functionalities of the catalog service were being created to replace existing functionality which were working fine.

Because we choose such an isolated functionality we were able to introduce the new catalog service into production step by step. Instead of replacing the search functionality of the webshops using a big-bang approach, we choose A/B split testing to measure our changes and gradually increase the load of the microservice.

Next step: Choosing a datastore

The search engine that was in production when we started this project was making user of Solr. Due to the use of Lucene it was performing very well as a search engine, but from engineering perspective it lacked some functionalities. It came short if you wanted to run it in a cluster environment, configuring it was hard and not user friendly and last but not least, development of Solr seemed to be grinded to a halt.

Elasticsearch started entering the scene as a competitor for Solr and brought interesting features. Still using Lucene, which we were happy with, it was build with clustering in mind and being provided out of the box. Managing Elasticsearch was easy since there are REST APIs for configuration and as a fallback there are YAML configurations available.

We decided to use Elasticsearch since it provides us the strengths and capabilities of Lucene with the added joy of easy configuration, clustering and a lively community driving the project.

Even bigger challenge? Which programming language will we use

The team responsible for developing this first microservice consists out of a group web developers. So when looking for a programming language for the microservice, we went searching for a language close to their hearts and expertise. At that time a typical web developer at least had knowledge of PHP and Javascript.

What we’ve noticed during researching various languages is that almost all actions done by the catalog service will boil down to the following paradigm:

- Execute a HTTP call to fetch some JSON

- Transform JSON to a desired output

- Respond with the transformed JSON

Actions that easily can be done in a parallel and asynchronous manner and mainly consists out of transforming JSON from the source to a desired output. The programming language used for the catalog service should hold strong qualifications for those kind of actions.

Another thing to notice is that some functionalities that will be built using the catalog service will result into a high level of concurrent requests. For example the type-ahead functionality will trigger several requests to the catalog service per usage of a user.

To us, PHP and .NET at that time weren’t sufficient enough to us for building the catalog service based on the requirements we’ve set. Eventually we’ve decided to use Node.js which is better suited for the things we are looking for as described earlier. Node.js provides a non-blocking I/O model and being event driven helps us developing a high performance microservice.

The leap to start programming Node.js is relatively small since it basically is Javascript. A language that is familiar for the developers around that time. While Node.js is displaying some new concepts it is relatively easy for a developer to start using it.

The beauty of microservices and the isolation it provides, is that you can choose the best tool for that particular microservice. Not all microservices will be developed using Node.js and Elasticsearch. All kinds of combinations might arise and this is what makes the microservices architecture so flexible.

Even when Node.js or Elasticsearch turns out to be a bad choice for the catalog service it is relatively easy to switch that choice for magic ‘X’ or component ‘Z’. By focussing on creating a solid API the components that are driving that API don’t matter that much. It should do what you ask of it and when it is lacking you just replace it.

Many more headaches to come later this year ;)

Ever look through at database and see a default constraint prefixed with DF_ and, for a split second, wonder why SQL needs a divine focus?