What if for a lot of software projects out there you don't need craftsmanship but you need something closer to real engineering: "This is what a sane PostgreSQL setup and transaction management for your app looks like, this is how you do validations and the ORM layer and logging and interaction with APIs and request queueing, this is how a good front-end page looks like, here's the off-the-shelf component library you use, here's how your process errors and show toast messages and handle redirects without messing around with browser history, here's all the accessibility and mean things you DON'T do (like hijacking scroll, not having contrast, having too many animations etc.)."

You don't have a rockstar building a bridge, nor do you usually have craftsmen taking risks on innovative materials and new approaches: most of the time, you just build the damn bridge in ways that have worked for decades and have been proven. Software industry doesn't seem to know what is proven or works, cause it's a moving target. Outside of maybe niches like writing code for airplanes, completely different standards there, not sure if most devs would personally want to work in those conditions, though.

Instead on one hand you have orgs and devs that are moving too fast and create a lot of churn without nailing down what works and doesn't, on the other hand you have a lot of people (myself included) that often have to push out slop because tech stacks are a mess and you still have deadlines which don't care about any of that, and largely the state of software development seems like a comparison between Windows 9X, the UI/UX of which was at least partially based on usability studies, and the modern version which... well, you can see for yourself.

Material is what made me hate google. It makes everything so difficult. It doesnt even look good. It's a low contrast sea of modern bullshit.

I sincerely hope that the material designers go to hell when they die and are forced to use their own garbage designs for all eternity while those of us who dont suck can use properly designed software.

Then there is also the communities, increased accessibility (it's just text) and the more structured nature of the "sites" which may be a feature.

So I would argue that there is definitely some benefits (for the user) to those alternative protocols.

I cannot help but think: they are such cowards, so afraid of anything that stands out after years of flat design. Like, you can almost feel like there is someone trying to sneak it in, only for it to get squeegeed at the last minute. The buttons could look like classic Aqua ( if they are allowed a background color that is), if it got slammed with a belt sander. Everything has to be too subtle, too toned down, too pale, and too faint, only noticable blown up to 4x on an OLED screen. It's like all they are allowed is "mimiminalizm", just remove, remove, remove, tone down, remove, slavishly, without thought. I'm supposed to cheer they added color back to in-focus window sidebars? First: good lord, what were they thinking? Of course they rolled such an utterly stupid decision back. Second: what color? Some single accent color applied to some whisper thin monochrome squiggles they call icons?

Its still more of the same. In the Installer app, there are windows where the dividing line between toolbar and content is like a 1px 30% grey line on same old bland 20% grey background, and that's with the new "Draw Borders" Accessibility setting turned on.

They can dress it up. Fix the worst issues. I'm thankful for it. Hell, I might not skip this one. But the problem still remains: Liquid Glass was a *bad, flawed* design from the start, whose central principle is contradictory (we'll get out of the way of your content by floating directly in front of your content all the time, in the way). There is no salvaging it.

- accessibility (hopefully improved soon)

- floating buttons over content that doesnt need to scroll

- switching light/dark when scrolling over content with borderline brightness

i will also say on accessibility, i recognize the site is a bit too small font in general — and will fix it soon.

For something so complex like a PC or desktop experience, having a bunch of oppositional goals (like ad pop ups) do not serve the user well enough. Often times a committee releases a product, but there is no real consensus or accessibility in mind.

"Try describing something different for the shortcut."

I guess I shouldn't be surprised that it still doesn't work.

Remote: Yes

Willing to relocate: Yes, especially for great fit

Technologies: Great with TypeScript. macOS development, especially around accessibility APIs e.g. built a platform to let agents interact with apps (getinvoke.com). Good with React, Svelte, Vue, Solid, all things frontend. Good with UI/UX, would consider myself a strong Design Engineer. Good with Rust. Some audio-related work. A little cryptography experience (wrote provably-fair gaming algorithms).

Résumé: https://cv.merlin.audio

Email: merlindruzinec@gmail.com (personal) or merlin@merlin.audio

Technologies: Anything. Very strong with TypeScript, frontend and backend. Dove deep into every frontend library/framework under the sun. I love Bun. Very strong with Rust. Have used all mainstream languages.

I've built getinvoke.com - an open-source platform over the macOS accessibility DOM. It enables deterministic computer-use for agents: they explore an app, click around, etc. Then they note down the actual working steps for any UI task in simple JS. Then replay them.

Got good grips on how React, Svelte, Vue, Solid.js work, both internally, and in practical terms. Led the transition for a 350k MAU website from a jQuery mess to a rewrite in Vue + redesign of the component system.

I've built Ethereum/Web3 payment systems before.

Worked with realtime online gaming and implemented cryptographically provably-fair algorithms.

Came up with & implemented a pluggable AI workflow system (think n8n) in the GPT-3.5 days.

I love design and UX.

Email: merlindruzinec@gmail.com or merlin@merlin.audio

The majority of soccer we played as kids wasn't even on a pitch. If you had a wall, a football, and two objects (usually jackets) to mark the goal - you could play - and that's exactly what we did.

But yeah, small neighborhood pitches were usually easy to find.

It runs as a background terminal that the agent can observe, and then exposes all interaction options as structured commands that can be run from the foreground CLI which then update the state of the background terminal via IPC. My hope is to establish a sort of “ARIA for terminals” standard to improve accessibility for both humans and agents. Email in profile, ping me if you’re interested in giving it a spin (just have plugins for Inquirer + Commander right now, hoping to broaden to other frameworks & TUIs soon).

Security, GDPR, backups, build pipelines, disaster recovery, most of it will be faked, half-heartedly done once or ignored entirely.

Then there's the more abstract things like scalability, idempotency when integrating with external APIs, error recovery, accessibility, UX, etc.

Almost always that sort of stuff will have been entirely ignored, or there will be a fig leaf over a real mess of misunderstood standards or manual intervention steps.

Startup developers usually have to be generalists as they often wear many hats, so things that need deeper domain knowledge get done to a bare minimum.