Readit NewsI’ve found ai tools most valuable for:
1. Quick “how to do x in y” language
2. Large scale refactorings that are mostly mechanical.
This still takes a bit of guidance to get the right output (and breaking down the refactoring an into multiple steps). But it does speed things up when I would touch 40-some files. I still review all the code.
Watch 2-3 onshape tutorial videos and then just dive in trying to make parts for yourself.
If you’re new to 3d printing you’ll soon learn that what you design doesn’t always print right. Welcome to creating things in the real world. This is part of the learning experience (and why you need to learn by doing).
Onshape also has a bunch of public cad designs, so you can look at how other people made things to learn (sort of like reading source code to learn).
This JSX:
<section><h1>Welcome</h1>{data.enabled ? <input /> : "disabled"}</section>
_jsx("section", {children: [
_jsx("h1", {children: "Welcome"}),
data.enabled ? _jsx("input", {}) : "disabled"
]})
_jsx("section", ()=>{
_jsx("h1", ()=>{_jsx("Welcome");});
if (data.enabled) _jsx("input", {}) else _jsx("disabled");
}})
render() {
if (this.dontNeedToRender) {
return null
}
}
I don’t get this at all.
I’d much prefer a team of highly empowered and highly responsible engineers than impotent engineers who need hand holding in case they make a mistake.
This is only a vulnerability if you have pages you don't want to render for some people, regardless of upstream data it would need to fetch.
For example having all routes under `/admin/*` automatically return an error if the user is not an admin, and then the individual routes don't need to be concerns with access control.
There’s also folks that pair because they’re a crutch for one or two other engineers. The other engineers never improve or are let go, but softly slow down the team.
There’s also the folks that pair because their code doesn’t make sense on its own. Or they have some config files they’ve refused to check into the repo, etc.
Pairing makes them feel valuable.
AI programming isn't going to improve the state of the craft. Developers hate AI coding tools for the same reason they hated Dreamweaver back in the 00s: the generated code was crap. You'd spend more time "fixing" the generated code than you'd spend writing it from scratch.
What it is going to do is finally kill this obsession the tech industry has with moving fast and breaking things. We can't compete with AI on speed and breaking things. It's just not humanly possible. It's going to force the entire industry to find other metrics to compete on. I hope that's going to be quality (performance, uptime, and reliability), but, then again, I'm an optimist in this regard.
It's the same with music and art, too. AI isn't going to replace musicians and artists, but it is going to make them compete on different metrics than they're used to.
The tools are going to get better, and it’s going to lift everyone while doing so. But it will vary across task.
The bottom tier of engineers will have improvements to their code.
The top engineers will move faster. Top engineers will still be great at what they do.
—-
The same thing is happening in music. Everyone gets lifted but on different dimensions.