@lazyDev reminded me of the time my bid for a project was rejected because I'm a white man. Never mind the fact that I have built my career around data management, visualisation and modelling and the only other competing bid was from someone who had experience in mobile development and little else. I checked up on the company and the project just now, and they've posted the project up again. I've made a bid just like I did before, only this time I've tripled my price. Let's see if they change their minds.

Can anyone recommend good resources for learning how to design NoSQL (document) data models?

I'm interested in stuff that talks about how to make the choices about distributing data across collections, etc.

When to have a single collection, when to split data across different collections, when to duplication data, etc,

So we finished our requirement ( barely) for a new client. Next is data modelling and system design.

We started with data modelling. Unfortunately the lead developer does not know the difference between database and data modelling.

me: hey bro, we'll do the database and stuff later, now let's focus on data modelling.

him: (acting like he knows) yeah I have developed a sample design for the "data model".

me: no this is database design.

him: what's the difference?

me: dude, they're totally different. Okay, simple explanation data model is what you want to store, whereas DB design is how you store it.

him: So, if I am not wrong, it's implied that you know what to store if you are talking about how to store it.

me: but you don't know what it is you want to store yet. And one of them precedes the other.

him: Okay, let's start with DB design.

me: What?????? you want to build a house without a plan??? That's it for me I am done !!!

I left the project yesterday, later I heard that, the team members are coders, who think that developing a software is all about coding and fixing errors.

I had a pretty good year! I've gone from being a totally unknown passionate web dev to a respected full stack dev. This will be a bit lengthy rant...
Best:
- Got my first full time employment dev role at a company after being self-taught for 8+ years at the start of the year. Finally got someone to take the risk of hiring someone who's "untested" and only done small and odd jobs professionally. This kickstarted my career, super grateful for that!
- Started my own programming consulting company.
- Gained enough confidence to apply to other jobs, snatched a few consulting jobs, nailed the interviews even though I never practiced any leet code.
- Currently work as a 99% remote dev (only meet up in person during the initialization of some projects.) I never thought working remotely could actually work this well. I am able to stay productive and actually focus on the work instead of living up to the 9-5 standard. If I want to go for a walk to think I can do that, I can be as social and asocial as I want. I like to sleep in and work during the night with a cup of tea in the dark and it's not an issue! I really like the freedom and I feel like I've never been more productive.
- Ended up with very happy customers and now got a steady amount of jobs rolling in and contracts are being extended.
- I learned a lot, specialized in graph databases, no more db modelling hell. Loving it!
- Got a job where I can use my favorite tools and actually create something from scratch which includes a lot of different fields. I am really happy I can use all my skills and learn new things along the way, like data analysis, databricks, hadoop, data ingesting, centralised auth like promerium and centralised logging.
- I also learned how important softskills are, I've learned to understand my clients needs and how to both communicate both as a developer and an entrepeneur.
Worst:
- First job had a manager which just gave me the specifications solo project and didn't check in or meet me for 8 weeks with vague specifications. Turns out the manager was super biased on how to write code and wanted to micromanage every aspect while still being totally absent. They got mad that I had used AJAX for requests as that was a "waste of time".
- I learned the harsh reality of working as a contractor in the US from a foreign country. Worked on an "indefinite" contract, suddenly got a 2 day notification to sum up my work (not related to my performance) after being there for 7+ months.
- I really don't like the current industry standard when it comes to developing websites (I mostly work in node.js), I like working with static websites (with static website generators like what the Svelte.js driver) and use a REST API for dynamic content. When working on the backend there's a library for everything and I've wasted so many hours this year to fix bugs and create workarounds related to dependencies. You need to dive into a rabbit hole for every tool and do something which may work or break something later. I've had so many issues with CICD and deployment to the cloud. There's a library for everything but there's so many that it's impossible to learn about the edge cases of everything. Doesn't help that everything is abstracted away, which works 90% of the time but I use 15 times the time to debug things when a bug appears. I work against a black box which may or may not have an up to date documentation and it's so complex that it will require you to yell incantations from the F#$K
era and sacrifice a goat for it to work properly.
- Learned that a lot of companies call their complex services "microservices". Ah yes, the microservice with 20 endpoints which all do completely unrelated tasks?

Another gem from my Database Fundamentals class, this time it's from the textbook:

So right now we're learning about data modeling with ERDs and the book is explaining a few things about attributes. I got to a part where the book was explaining when you should split an attribute into many (the book mixes up conceptual modelling and logical modelling). The first example the book gave was an address, splitting it up by street name, address number, city, postal code, etc. So far so good. Now we get to the second example: a phone number. The book split the the number 55 11 9784-8900 into four parts:

Country code: 55
Area code: 11
Number prefix: 9784
Number suffix: 8900

At this point I was like "WHAT?". Separating area and country codes from the rest of the number is ok, that's useful, but splitting the number itself in half? Why the fuck would you want to do that? Correct me if I'm wrong but the dash in the middle of the number is just used for "chunking", to make it easier for our brains to read the number. Why would you want to split the number in half? There's literally no reason to do it, at least not in the example the book was showing.

Every time I open this book I keep wondering why the hell my teacher chose it to be our textbook. He's a great teacher, his lectures are awesome, he explains stuff super well, but he chose this book. A book that's filled with shitty literal translations to domain-specific words and acronyms, shitty examples, and convoluted sentences.