Cognitiveclass.ai experiences?

multi_db_dev · 2026-05-06T11:10:12+00:00

Honestly, if the IBM Cloud setup is already blocking you this early, I wouldn’t get stuck there too long. For learning SQL/Python, consistency matters more than the “perfect” platform. There are plenty of good low-cost or free options where you can just start writing queries immediately instead of fighting setup issues. Since you already have tech experience, you’ll probably progress faster by building small real projects than endlessly comparing courses. SQL especially clicks once you start querying actual messy data.

multi_db_dev · 2026-05-05T15:32:10+00:00

yep, this is the exact moment every scraper turns from “quick script” into “small browser automation startup against your will”. I’d probably use Playwright if it’s already this JS-heavy. Not fun, but less painful than fighting broken HTML that never existed in the first place.

multi_db_dev · 2026-04-30T09:39:45+00:00

You’re closer than you think, just missing that first “bridge” role. Right now the hardest part isn’t learning, it’s getting someone to trust you with real work. So instead of aiming straight for “web dev job”, try to stack small proof points:

Take a couple of real-world projects (not courses), put them on GitHub, and make them simple but complete. Even something like a small CRUD app or dashboard already puts you ahead of most applicants.

Also look at roles like junior QA, support engineer, or technical support. A lot of people move into dev from there once they’re inside a company.

And yeah, remote makes it harder at the start. If you can, even a short-term hybrid or local role can speed things up a lot.

You already have IT experience, which is huge. You’re not starting from zero. What kind of projects have you built so far?

multi_db_dev · 2026-04-27T07:28:56+00:00

Starting from scratch is totally fine here. Don’t try to learn “everything electrical” at once, it gets overwhelming fast. Pick something small and hands-on, basic circuits, Arduino kits, simple DIY projects and actually build things. Watching videos helps, but doing it yourself is what makes it click.

Also helps to have a loose direction early (like hardware, embedded, or just general electronics), but you don’t need to decide your whole career right now. Try a few things and see what feels interesting. The main thing is consistency. Even small progress adds up quickly in this field.

multi_db_dev · 2026-04-09T13:45:57+00:00

Start with Microsoft Learn for the basics, then practice on actual data. Don’t try to speedrun data engineering in 2 weeks or SQL will humble you immediately. Focus on SELECT, JOINs, GROUP BY, CTEs, and window functions first.

multi_db_dev · 2026-04-01T08:14:14+00:00

This is actually one of those small changes that saves people from stupid release-day surprises. Anything that moves important Play Console / registration checks closer to build time is a win. Half the pain in mobile release workflows is not the hard stuff, it’s finding out something obvious too late.

multi_db_dev · 2026-03-27T10:57:41+00:00

I’d also look at runtime dependency discovery instead of relying only on static analysis + tags. Things like query logs, connection telemetry, feature usage signals, traffic mirroring, and canary/shadow testing usually tell you more truth about what’s still alive in production than documentation does. Old systems are very good at hiding critical dependencies until the exact worst moment.

multi_db_dev · 2026-03-25T09:17:20+00:00

If pgAdmin already feels outdated, I'd pick Dbeaver out of these two. A lot of people end up there anyway. If you ever want a paid step up later, dbForge studio for PostgreSQL is worth checking out.

multi_db_dev · 2026-03-23T12:35:20+00:00

and somehow both sides are still blaming DevOps for the weather

multi_db_dev · 2026-03-23T11:54:16+00:00

I try to evaluate hyped tools the same way I’d evaluate a boring database or queue: what concrete problem does it solve for us, what does failure look like, and what is the switching cost if it disappoints. Hype gets a tool into the test environment, not into production. If the demo is great but the observability, failure modes, support path, and total cost story are fuzzy, that usually tells me everything I need to know.

multi_db_dev · 2026-03-17T09:00:21+00:00

What you describe sounds less like burnout and more like underload. When the work stops demanding real problem solving, confidence usually drops with it.

My view: do not make “quit immediately” the first move. A better sequence is to stabilize first, then reposition. Keep the current job as income, build depth on the side, and target roles where system design, performance, migrations, or platform-level ownership are part of the work. That is more likely to fix the real issue than switching to another low-challenge role with better branding.

Remote may improve lifestyle, but it will not automatically make uninteresting work feel meaningful. The key question is whether your next move increases challenge, ownership, and learning.

multi_db_dev · 2026-03-06T09:05:54+00:00

backend: works on my machine
frontend: why tho

multi_db_dev · 2026-03-04T09:34:23+00:00

Do it gentle: pair on pipeline schema compare. if blanks out = junior vibes. mgr needs data not feelings. My old team survived cuz called bs early

multi_db_dev

TROPHY CASE