Keep up the good work! If you have any questions, please don't be afraid to ask. ;)

As someone who's been here for twice as long... welcome to our industry. The trick is taking all of your personal time and focusing on something bigger and better that you can create. That process, however, will been even more agonizing at first - with the unfortunate chance of your journey (and you) becoming the thing you most hate, especially if you habitually break focus or aren't up to dealing with the personal aftermath of a successful startup and the inevitable employee that thinks you're a complete heap, delivering a fraction of what they should. And, the kicker is that they may be just as correct as you are right now. It's a fickle, trendy beast of an industry; hard to tame and harder to master in a positive and proactive manner as an entrepreneur. Big plans often come with bigger faults, but if you're willing to accept a ridiculously large amount of refactoring yourself, as well as your code, you may have a fighting chance.

AngularJS officially went EoL on July 1st, 2018. June, 2021 is simply the end of the LTS period. This is why no one should use any of these frameworks, imo. The same will happen to React, as well. Just watch. Learn what they're built upon, or something else completely, otherwise you'll be swimming up s**ts creek to find decent work. As a side note: Vue.js may be the only viable candidate for the longest life, and is geared more towards supporting various approaches as opposed to requiring them (such as TypeScript.)

You should add the one thing every tutorial neglects: How to lock it down and secure the database. As soon as you do this with a VPS, for app-oriented transactions, your DB collections are going bye-bye (aka "hijacked") within the next six months (if you're lucky.)

I agree with j , to a certain extent. Certificates can be written on toilet paper these days, and don't really prove much other than the recipients fundamental understanding of what they've been certified for. It also has its limits, especially in this current industry where things change much too often. There's also a chance, like for server administration, where you'll need to re-test every so often to have an up-to-date and valid certification. In my experience, caring about a potential developer having a type of certification is a huge mistake and - more often than not - results in toxic work environments. You need to be able to perpetually learn and grow with your colleagues, because much like college degrees, your skill set will eventually become antiquated and you've leaned on those pseudo-intellectual qualifications for your entire career without properly evolving.

On a side note, we need to be careful of what is defined there since it's "universal" and everything will use those properties. Some elements also have no reason to use them, which also brings us to a huge issue when using a universal selector. Just like BEM - to semi-quote a previous thread - it turns your code into a proverbial garbage pail; encouraging bad practices and unnecessary code bloat. Inheritance is important, and when you ignore the fact that styles are handed down from parent elements... you're missing the point of writing DRY code (aka "Don't Repeat Yourself"). We often make the mistake of considering the CSS file the defining factor of style for an interface, however, we don't often use a single class within the markup when assigning it to an element within the HTML. The result is a CSS file that seems to be DRY, but defeats the purpose by redefining the same properties within each id or class name that's used. Even though I disagree a bit, I like articles like this, because it will inspire folks to deep dive for more information. Jason Knight was a brutal critic in many of his posts, but sometimes the truth hurts. Source: https://hashnode.com/post/css-methodology-to-bem-or-not-cjmwskdv901sbbts2pkanc3gr

Oh, Atom... it was like running a marathon, and then falling on your ass right before you reached the finish line.

I voted for "From time to time", since estimates based on planning sessions are dependent on the team member and their role. However, I would recommend thinking "shirt sizes" rather than "hourly". Also, review the past few sprints. I find this extremely effective for me in recognizing patterns within different workflows, which basically dictates what's worked in the past for similar issues (relative to the person that they've been assigned to.) On a personal level, I would actually vote "Quite often". Because there's no guessing game involved, and I'm fully aware of other issues that life might throw me, which a Scrum Master would not be aware of.

I've known about Socket.io (https://socket.io/) over the past few years, and now I'm taking a course. Here's their chat demo: https://socket.io/demos/chat/ The course is on Udemy, and on occassion, it's on sale for about $12. It's very good so far, and also teaches you the fundamentals of websockets, TCP/UDP, etc. https://www.udemy.com/course/socketio-with-websockets-the-details/

My goodness, to how far Atom has taken a nosedive. Shows the critically flawed potential of a functional redesign (like the one that pretty much killed Atom's compatibility with a huge portion of the packages and add-ons that the community had created for it.)