QGIS is incredibly powerful.

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.

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.

Cargo cult runneth strong on web.

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

See: Out of the Tar Pit.

- 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.

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.

I asked him why he would prescribe a stimulant so late in the day. His reply was simply "it's so you can think of one thing instead of all the things".

Worked for me.