Surprised Boone's mentioned AI yet.
It's AI.
HN user
Full-stack engineering.
Surprised Boone's mentioned AI yet.
It's AI.
Canada shouldn't include Palantir at all.
Yuck.
Protip: never even mention undefined in your codebase. Erase it from your vernacular. If you ever need to pass or return nothing, you use null.
It's why fail fast is a thing
Kind of them to put the evil right in the name.
I for one look forward to rewriting the entirety of software after the chatbot era
I've used it for gixapixel scale rendering projects. Giant wall murals at 300 DPI.
QGIS is incredibly powerful.
Generative AI worlds, real time neural rendered VR, plus BCI === end of the world as we know it
Very nice! Love the clean UI.
Tup: Use interface for structural types in TypeScript, not type.
Surveillance Capitalism
The vast majority of state problems in React are a result of nonsense cargo culting around the idea that classes are somehow bad.
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.
vectorization != intelligence
The bane of "functional. No such thing as objects or classes, just a bunch of shotgun spread state fragments.
Cargo cult runneth strong on web.
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.
CTEs are extremely useful mechanisms for writing modular and easily maintainable queries, particularly around anything to do with ETL, graphs, and timeseries data. Highly recommend.
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.
Kudos to you. Bullshit metric.
Perhaps it was a response to the Arecibo message, and the response was "quiet, they'll hear you".
Came here to post this. I remember once when going back on ADHD meds, a very smart doctor adding 5mg of Dexedrine. At 5pm.
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.
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.
Your newest team member sounds like someone worth holding onto.
Reminds of Hofstadter's concept of the "Parallel Terraced Scan". Kind of a mix between breadth-first and depth-first search or unsupervised learning.
Nice write-up here: https://www.menimagerie.com/manuscripts/2018/6/9/v-douglas-h...
Static analysis platform with multiple language frontends and backends. Have some large scale renderings if you ever want to see them or take a poke through the repo.
Very cool. Have built something like this in the past - let me know if you are hiring.
I dunno, Postgres seems pretty solid.