Udemy courses are targeted at ABSOLUTE beginners. It's excruciating to pull through and finish the course "just because". And some of these courses are jam-packed with 30-60 hours just for them to appear legit, but the reality is the value you get could be packed to 3-5 hours.

You're better off just searching for or watching for the things that you need on Google or YouTube.

You'll learn more when building the actual stuff. Yes, it's good to go for the documentation. Just scratch the "Getting Started" section and then start building what you want to build already. Don't read the entire documentation from cover to cover for the sake of reading it. You won't retain everything anyway. Use it as a reference. You'll gain wisdom through tons of real-world experience. You will pick things up along the way.

Don't watch those tutorials with non-native English speakers or those with a bad accent as well. Native speakers explain things really well and deliver the message with clarity because they do what they do best: It's their language.

Trust me, I got caught up in this inefficient style a handful of times. Don't waste your time.

Have a function that takes parameters and then performs a switch statement to determine what function to call next with those same parameters. One of those parameters is a Union type.

During CR, my reviewer said they’d like if instead of returning the function per case, I instead assigned a handler to the value of the function per case and then returned that handler at the end of the switch. Simple change, right? Only snafu, I’m casting one of the parameters on a per-case basis.

Somehow, through no fucking change of my own, TypeScript in its wisdom has decided that the type of that value by the time I call the next function is a fucking Intersection.

WHY THE FUCK DO YOU THINK IT’S AN INTERSECTION?! I’m fucking casting it per case! I’m ensuring it’s the right type for the next function called on a per case basis!

…. And that, my friends, is how I wasted a day with a stupid refactor that was ultimately just scrapped because no one could figure out how to make it work.

Goddamn fucking TypeScript. I

I often wonder if our clients seriously think we have an all-knowing crystal ball of wisdom when they send tickets like "Cannot send emails - please check" while they have like 10 servers and email delivery is a complex matter on its own already.

If I didn't care what our clients think, I'd reply with equally informative email of "Maybe, who knows"...

After years of experience in the industry, I find that I have 1000% more skills and 2000% more knowledge.

I have come to the realization that I need to do 500% less things and demonstrate 1000% less knowledge.

2022, Lex Lexter, a collection of wisdom

The Zen Of Ripping Off Airtable:
(patterned after The Zen Of Python. For all those shamelessly copying airtables basic functionality)

*Columns can be *reordered* for visual priority and ease of use.

* Rows are purely presentational, and mostly for grouping and formatting.

* Data cells are objects in their own right, so they can control their own rendering, and formatting.

* Columns (as objects) are where linkages and other column specific data are stored.

* Rows (as objects) are where row specific data (full-row formatting) are stored.

* Rows are views or references *into* columns which hold references to the actual data cells

* Tables are meant for managing and structuring *small* amounts of data (less than 10k rows) per table.

* Just as you might do "=A1:A5" to reference a cell range in google or excel, you might do "opt(table1:columnN)" in a column header to create a 'type' for the cells in that column.

* An enumeration is a table with a single column, useful for doing the equivalent of airtables options and tags. You will never be able to decide if it should be stored on a specific column, on a specific table for ease of reuse, or separately where it and its brothers will visually clutter your list of tables. Take a shot if you are here.

* Typing or linking a column should be accomplishable first through a command-driven type language, held in column headers and cells as text.

* Take a shot if you somehow ended up creating any of the following: an FSM, a custom regex parser, a new programming language.

* A good structuring system gives us options or tags (multiple select), selections (single select), and many other datatypes and should be first, programmatically available through a simple command-driven language like how commands are done in datacells in excel or google sheets.

* Columns are a means to organize data cells, and set constraints and formatting on an entire range.

* Row height, can be overridden by the settings of a cell. If a cell overrides the row and column render/graphics settings, then it must be drawn last--drawing over the default grid.

* The header of a column is itself a datacell.

* Columns have no order among themselves. Order is purely presentational, and stored on the table itself.

* The last statement is because this allows us to pluck individual columns out of tables for specialized views.

*Very* fast scrolling on large datasets, with row and cell height variability is complicated. Thinking about it makes me want to drink. You should drink too before you embark on implementing it.

* Wherever possible, don't use a database.
If you're thinking about using a database, see the previous koan.

* If you use a database, expect to pick and choose among column-oriented stores, and json, while factoring for platform support, api support, whether you want your front-end users to be forced to install and setup a full database,
and if not, what file-based .so or .dll database engine is out there that also supports video, audio, images, and custom types.

* For each time you ignore one of these nuggets of wisdom, take a shot, question your sanity, quit halfway, and then write another koan about what you learned.

* If you do not have liquor on hand, for each time you would take a shot, spank yourself on the ass. For those who think this is a reward, for each time you would spank yourself on the ass, instead *don't* spank yourself on the ass.

* Take a sip if you *definitely* wildly misused terms from OOP, MVP, and spreadsheets.

This is more of an advice seeking rant. I've recently been promoted to Team Leader of my team but mostly because of circumstances. The previous team leader left for a start-up and I've been somehow the acting Scrum Master of the team for the past months (although our company sucks at Scrum generally speaking) and also having the most time in the company. However I'm still the youngest I'm my team so managing the actual team feels a bit weird and also I do not consider myself experienced enough to be a Technical lead but we don't have a different position for that.

Below actions happen in the course of 2-3 months.

With all the things above considered I find myself in a dire situation, a couple of months ago there were several Blocker bugs opened from the Clients side / production env related to one feature, however after spending about a month or so on trying to investigate the issues we've come to the conclusion that it needs to be refactorised as it's way too bad and it can't be solved (as a side note this issue has also been raised by a former dev who left the company). Although it was not part of the initial upcoming version release it was "forcefully" introduced in the plan and we took out of the scope other things but was still flagged as a potential risk. But wait..there's more, this feature was part of a Java microservice (the whole microservice basically) and our team is mostly made of JS, just one guy who actually works as a Java dev (I've only done one Java course during uni but never felt attracted to it). I've not been involved in the initial planning of this EPIC, my former TL was an the Java guy. Now during this the company decides that me and my TL were needed for a side project, so both of us got "pulled out" of the team and move there but we've also had to "manage" the team at the same time. In the end it's decided that since my TL will leave and I will take leadership of the team, I get "released" from the side project to manage the team. I'm left with about 3 weeks to slam dunk the feature.. but, I'm not a great leader for my team nor do I have the knowledge to help me teammate into fixing this Java MS, I do go about the normal schedule about asking him in the daily what is he working on and if he needs any help, but I don't really get into much details as I'm neither too much in sync with the feature nor with the technical part of Java. And here we are now in the last week, I've had several calls with PSO from the clients trying to push me into giving them a deadline on when will it be fixed that it's very important for the client to get this working in the next release and so on, however I do not hold an answer to that. I've been trying to explain to them that this was flagged as a risk and I can't guarantee them anything but that didn't seem to make them any happier. On the other side I feel like this team member has been slacking it a lot, his work this week would barely sum up a couple of hours from my point of view as I've asked him to push the branch he's been working on and checked his code changes. I'm a bit anxious to confront him however as I feel I haven't been on top of his situation either, not saying I was uninvolved but I definetly could have been a better manager for him and go into more details about his daily work and so on.

All in all there has been mistakes on all levels(maybe not on PSO as they can't really be held accountable for R&D inability to deliver stuff, but they should be a little more understandable at the very least) and it got us into a shitty situation which stresses me out and makes me feel like I've started my new position with a wrong step.

I'm just wondering if anyone has been in similar situations and has any tips or words of wisdom to share. Or how do you guys feel about the whole situation, am I just over stressing it? Did I get a good analysis, was there anything I could have done better? I'm open for any kind of feedback.

!rant One of the better refactoring insights I've heard today: "With great power comes great responsibility".

Just because a language may not care about certain constructs, doesn't mean you should be relaxed about them (e.g. weak/dynamic typing/not caring about (variable name) consistency).