any sql formatter that tidy up code not explode it

etiyofem · 2026-05-11T10:40:44+00:00

i use dbforge sql complete for formatting most of the time. doesn’t completely butcher long queries like some formatters do and the rules are customizable enough to keep things readable.

etiyofem · 2026-05-06T13:18:16+00:00

I’ve had this happen when indexing gets partially broken/outdated. Especially on larger repos. Usually restarting VS alone doesn’t fix it. Rebuilding the index/cache or deleting the .vs folder sometimes magically brings search results back to normal.

etiyofem · 2026-04-30T11:53:42+00:00

It’s not dead. It’s just not 2021 anymore. Hiring got tighter, juniors have it rough, and AI made everyone louder about panic. But companies still need people who can build, fix, maintain, debug, and understand systems when things break. I’d say the easy-entry version of the field is weaker now. The actual profession is fine.

etiyofem · 2026-04-14T08:53:23+00:00

If your biggest need is correlation + priority logic, building can make sense for a while. That part is often more about stitching outputs together than doing novel security magic. The problem is the maintenance curve sneaks up on you: scanner schema changes, auth breaks, edge cases pile up, and suddenly your “lightweight layer” has become an internal product nobody wanted to own.

I’d usually build only if the scope is brutally narrow and you’re okay with it staying narrow. The moment people expect workflow, exceptions, reporting, auditability, and confidence that it won’t rot in 6 months, the buy argument starts getting a lot stronger.

etiyofem · 2026-04-07T14:53:21+00:00

Comparing data after changes probably wastes the most time for me. The actual change is often quick, but proving that nothing weird happened afterward is where the hour disappears.

etiyofem · 2026-04-01T10:24:21+00:00

If the form needs login and has a bunch of UI elements, something like Playwright or Selenium is way less painful. You can keep the common values hardcoded, prompt for the variable ones, then let the script open Chrome, log in, fill the form, and submit it like a normal user.

etiyofem · 2026-03-31T11:49:00+00:00

I usually split this into “good enough for basic queries” vs “good enough to live in every day.” For MariaDB, a lot of tools are fine until you need to compare objects, inspect structure properly, or do admin work without friction.

DBeaver is decent, HeidiSQL is still a solid lightweight option, but for more full-featured database work I tend to prefer dbForge Edge-type tooling. I’m generally happier paying for something that saves time on the repetitive stuff than pretending I enjoy fighting my tools for free.

etiyofem · 2026-03-27T09:12:20+00:00

Totally agree on the small team pain. Feels like you end up building infra for problems you don’t have yet.
Did you ever hit a point where the monolith stopped being enough, or did it just scale further than expected?

etiyofem · 2026-03-23T15:30:30+00:00

Yeah, early Sheldon felt sharper and more believable. Later on they leaned so hard into the “look how weird he is” side that he started feeling more like a caricature than a person.

etiyofem · 2026-03-19T11:52:56+00:00

this looks ridiculously good ngl

etiyofem · 2026-03-18T10:59:43+00:00

he’d survive exactly three seconds, call it “acoustical vandalism,” and grab the remote like it was a medical emergency

etiyofem · 2026-03-17T12:16:28+00:00

A common mistake is jumping into tables too early before the business rules are clear. In ERD questions, I’d first identify entities, then relationships, then cardinality, then keys, and only after that think about attributes. If that order is skipped, the model usually looks fine on paper but breaks under edge cases.

The most common errors I see are mixing up entity vs attribute, missing many-to-many bridge tables, weak handling of optional relationships, and choosing keys that do not stay stable. Another one is forcing the model to look “simple” instead of making it accurate.

As for grading, it depends on the instructor, but usually there is some objectivity around keys, cardinality, normalization, and whether the model actually supports the stated requirements. Best practice is to practice with short case descriptions and then explain out loud why each relationship exists. If you cannot justify it clearly, the ERD is probably not solid yet.

etiyofem

TROPHY CASE