HN user

jschrf

401 karma

Full-stack engineering.

Posts0
Comments166
View on HN
No posts found.
QGIS 4.0 5 months ago

I've used it for gixapixel scale rendering projects. Giant wall murals at 300 DPI.

QGIS is incredibly powerful.

Aye. Sign of the times. You're 20+ years in, so I'm preaching to the choir and old-man-yelling-at-cloud here.

Cargo culting + AI are the culprits. Sucks to say, but engineering is going downhill fast. First wave of the shitularity. Architects? Naw, prompt engineers. Barf. Why write good code when a glorified chatbot could do it shittier and faster?

Sign of our times. Cardboard cutout code rather than stonemasonry. Shrinkflation of thought.

Peep this purified downvote fuel:

Everything is bad because everyone is lazy and cargo cults. Web specifically. Full-stop. AI sucks at coding and is making things recursively worse in the long run. LLMs are nothing more than recursive echo chambers of copypasta code that doesn't keep up with API flux.

A great example of this is the original PHP docs, which so, so many of us copypasta'd from, leading to an untold amount of SQL injections. Oopsies.

Simalarily and hunting for downvotes, React is a templating framework that is useful but does not even meet its original value proposition, which is state management in UI. Hilariously tragic. See: original example of message desync state issue on FB. Unsolved for years by the purported solution.

The NoSQL flash is another tragic comedy. Rebuilding the wheel when there is a faster, better wheel already carefully made. Postgres with JSONB.

GraphQL is another example of Stuff We Don't Need But Use Because People Say It's Good. Devs: you don't need it. Just write a query.

-

You mention a hugely important KPI in code. How many files, tools, commands, etc must I touch to do the simplest thing? Did something take me a day when it should have taken 30s? This is rife today, we should all pay attention. Pad left.

Look no further than hooks and contexts in React land for an example. Flawed to begin with, simply because "class is a yucky keyword". I keep seeing this in "fast moving" startups: the diaspora of business logic spread through a codebase, when simplicity and unity is key, which you touch on. Absolute waste of electricity and runway, all thanks to opiniation.

Burnt runways abound. Sometimes I can't help but think engineering needs a turn it off and then on again moment in safe mode without fads and chatbots.

Very cool article. Semantics are important and key. Article nails it.

Reduce, reduce, and then reduce farther.

I'll add my 2c: Ditch the cargo cults. Biggest problem in software dev. I say this 30 years in.

Hard lesson for any young engineers: You don't need X, Y, or Z. It's already been invented. Stop re-inventing. Do so obsessively. You don't GraphQL. You don't need NoSQL. Downvote away.

Pick a language, pick a database, get sleep.

Never trust the mass thought. Cargo culting is world destroying.

Time spent on "incidental complexity" (new features, key fixes, performance) versus time spent on "accidental complexity" (anything and everything else).

Easy metric to understand, easy metric to teach, just remember that it applies to teams and not individuals.

See: Out of the Tar Pit.

Always blows my mind how much time we waste talking about Git instead of just using it properly. Cheatsheet:

- It's distributed horticulture. Your tools come saran-wrapped to the tree.

- Rebase flow. Keep your branches linear.

- Merge commits are BS

- There is no source control problem that rebase, rebase --onto, reset, and reflog can't fix

- Topology is everything. Add this to your aliases: https://stackoverflow.com/questions/1838873/visualizing-bran...

TL;DR: Keep your branches up to date. Feature flags are a huge red flag. Constant conflicts and the inability to have long lived branches is indicative of poor architecture and project layout.

Use "rerere" as a bandaid.

Why won't anyone think about the release managers.

I don't like this take. This post is for any engineering leader.

The Bus Factor is how hard your team would suffer if you - or anyone else on the team - got hit by a bus.

Ideal Bus Factor for all team members is 0. This might sound counter-intuitive at first, almost like "make everybody expendable", but it's quite the opposite and kind of the point.

Teams should be good enough that they are a) autonomous and b) there are no mysteries. In the ideal state, everyone understands how everything works. New employees should hit the ground running and be able to produce value immediately. Departing employees should feel comfort in knowing that there are no unknowns.

An ideal team with 0 BF across the board is desirable. It means that team members are fungible. It means that every single team member can fill in the gaps if someone is ill, or on vacation, or actually leaves or is removed.

More importantly, a 0 BF is a reflection of simplicity. The software, its build/test/deployment pipelines, documentation, and support, should all be cohesive and coherent. Siloing information in team members is bad, everyone should be able to build and deploy.

0 BF is a healthy metric, but it is absolutely 100% not measured in email rate, commit rate, PR rate, lines of code, timeliness, GitHub heatmaps, etc. Those metrics indicate nothing at all. Quite the oppositve. They are harmful, awful metrics.

Measuring people by these metrics is just monkeys on typewriters. More startups need to hear this.

There are two things that everybody misses about OAuth and they fly under the radar.

Nice to hear someone touch on one of them: you absolutely NEED to use a transaction as a distributed locking mechanism when you use a token.

This goes double/quadruple for refresh tokens. Use the same token more than once, and that user is now signed out.

It doesn't matter if your system runs on one machine or N machines; if you have more than one request with a refresh token attached in flight at once - happens all the time - you are signing out users, often via 500.

Refresh tokens are one-time use.

The other thing devs and auth frameworks miss is the "state" parameter.