Lol

On the other hand, I understand the utility of knowing how to do these things for ourselves. There are a number of “black-box” libraries that were just an absolute mystery to me until I tried implementing them myself and began to see these libraries are usually not complex so much as they are thorough in covering edge cases that 90% of users will never care about.

Yeah, that’s one of my big fears. Not necessarily losing my job to an AI, but AI exacerbating existing bad practices.

When I started my current job, we had one rock star coder responsible for a fairly fiddly piece of our product. He went heads-down for two weeks and churned out pages of densely-written python without comments. It did what it was supposed to do, flawlessly. He left the team shortly afterward to work on a bigger project, and we got word from the higher-ups that we had to support a new feature upstream in that code. And then another. And so on. Nothing’s commented. Everything’s over-optimized. We eventually ended up just cross-compiling the upstream logic and using that in our stack because it was easier than using his impenetrable stuff.

In the end, we had to fix it with menial, boring, aggravating manual work anyway. We got ourselves into that situation without AI, but I could see something like that becoming more prevalent. And that was working code. Imagine getting a SEV, and everyone on the blame list shrugs and says “idk, I had CoPilot do it.”

It would definitely be a shame if these tools caused new developers to bypass fundamental skill development. My only hesitation is the number of developers who should’ve developed those skills and never did before AI. There’s something wrong either with how developers are learning or who is getting into development.

Yeah, this is part of it. There’s maybe the science of programming and also, for lack of a better term, the craft: writing maintainable code, handling a SEV, thinking in terms of uptime, setting things up to be reverted easily, shutting down neurotic code reviewers, testing your code… stuff like that. Universities are good at the science part. Internships, theoretically, handle the rest. This isn’t an AI issue, but I could see AI making this problem a lot worse.

It’s not interesting, there’s no puzzles involved… It’s basically data entry

So? Show me an industry that’s 100% interesting all the time. Artists still have to stretch and gesso their canvases. Rock stars still have to deal with band drama and touring logistics. Directors have to work their budgets and wrangle big egos. Why should software, which is basically using fancy math to tell the dumbest guy in the room exactly what to do, be any different?

There’s this awful idea that everything should be fun and nobody should struggle with anything or be forced to do anything menial. We want to be instant experts without going through the boring or hard stuff. And we’re willing to offload more and more of this onto proprietary black boxes in exchange for… what?

I see cursive writing brought up a lot in these conversations and I don’t think it applies. Firstly, the cognitive load of writing code is higher than writing your letters so they join up. You’re not just making sure you write the letters correctly, you’re also following the syntax rules of the language you’re writing. And while you’re writing, you’re reinforcing those rules in your head. Yes, initially it’s hard and boring.

And yeah, sometimes you get it wrong or forget to capitalize. That is a feature, not a bug. The more you do it, the easier it gets. I spent a couple weeks trying to use CoPilot and at the end I still had to correct its shitty code, which either hallucinated features I wasn’t implementing, or hallucinated syntax rules I wasn’t using. It was like spending a sprint trying to get a subpar intern up to speed. At the end of those two weeks, my manual coding accuracy took a noticeable hit.

I complained to higher-ups and they told me “oh it’s definitely a skill getting the prompt written correctly”, which was patronizing and irritating. Would I rather spend time getting good at asking the proprietary magic thinky box to maybe write good code this time, or would I rather get better at coding?

I mean I’ve spent a lot of time writing regex to automate large sets of changes. Sometimes it can be a bit fiddly to get the regex just so. Like replacing direct field access with > getters where you have to find the field access and change .foo to .getFoo() and the capitalization can take a couple of tries to get just right.

At least you’re learning more about regexes when you do this. Yes, there’s menial bullshit in coding. There’s menial bullshit in every field. Some of it gets abstracted away (syntax highlighting to help with comprehension), some of it gets kicked around and ultimately does not impress (VB’s drag-and-drop coding), and some of it stays because it’s necessary. Nobody likes doing manual stuff, but sometimes it’s preferable to trying to automate it.

Also, I’ve never heard of anyone paying $20 a month for the privilege of not writing in cursive, or being unable to write because they don’t have internet. Something to think about.

Yep. It’s gonna be $20 forever, too. Have fun!

But the real savings? Repetitive code. I suck at it, I always make typos and it’s draining. I just toss in a table or an api response and tell it what I want and boom

Get better at it, manually, or you’ll suck at it forever. It’s a skill like anything else.

There was a senior dev at my first job that we called Lord Voldemort and he was the king of ungreppable variable names. Short, full of common characters, and none of them actually described what they were doing. I swear he only used characters that appeared in C++ keywords, so looking for fo would invariably tag every for statement in the file.

He also had hooks set up to notify when anyone was in his area of the code and you’d always get a two-hour phonecall where he’d slowly wear you down and browbeat you into backing out your changes. Every time I pulled a ticket in his codebase I’d internally shudder. He was friends and/or had dirt on the CTO so he just remained in that role and made everyone’s life hell.

I agree with you. Even if you never touch it, it’s nice to know what the libraries you’re calling are doing under the hood.

maybe this will work

...

...

...

linting and unit tests

A thing that hallucinates uncompilable code but somehow convinces your boss it’s a necessary tool.

Steps to test: “Idk try some shit”

Yep. This is the way. Also, you’d be surprised how many devs don’t run through their own QA steps before asking other people to verify.

Yuck.

“I’m a specialized clerk interested in mathematics” if you don’t wanna get burned.

At some point, they’re gonna have to debug it.

If you’re trying to pull your weight, and it sounds like you are, the problem is either with the tasks, the codebase, or the teammates:

Potential problems with the tasks:

• they’re not researched sufficiently
  • is this doable?
  • should we we even be doing this?
  • have we actually thought about how hard this will be, or did someone say “well that should be trivial” a bunch?
• there’s not enough info on the tickets
  • inexperienced leads tend to just shit out tickets with zero info and underpoint them
• they’re not broken down into small enough pieces
  • are you working “implement X” tickets while everyone else is working a series of “implement X: step N” tickets?

A ticket needs: clear repro documents (if necessary), screenshots, and clear steps to reproduce. It needs more than “Title: Add X to Y. Description: We need Y in X. Implement it.” unless you’re intimately familiar with the codebase. And even if you are, you still need a paper trail to back up what you’re doing. If you’re not closing tickets, be very chatty in the comments. Share where you are, problems you’re running into, and who you’re waiting on for help. If there’s a consistent theme to the things you’re fighting, keep a list of them and bring them to your manager. Be your own advocate and be very transparent about all the research you’re doing because other people didn’t.

Potential problems with the codebase:

• someone preemptively optimized it
• it’s not documented well
• it’s spidery bullshit code that someone has deep emotional attachment to

Hey, it works. But it’s not documented, someone decided to be clever instead of elegant, the local story sucks, or it’s optimized to such a degree that you have to refactor just to add a simple option ("lol why would we ever need that data here? It’s inefficient!)

Potential problems with teammates:

• they’re not supporting you
• they’re grabbing easy tasks because you’re the “code whisperer”
• they didn’t know what they were doing either so they’re vague when you ask them questions

Everyone pulls their weight. Everyone communicates in clear, declarative sentences and provides examples if necessary. “I don’t know” is an acceptable answer. Evasiveness, vagueness, specialized jargon, or acronyms point to the dev being insecure about their knowledge in that area. Be very suspicious of the word “should”: “that should work”, “that shouldn’t be hard”, “you should be able to…”

And, as an aside, I’ve seen this happen a lot. A new dev or contractor comes on, blows through tickets, gets good marks, and an existing dev or two get called out for not contributing with the same frequency. One of two things are happening here: the new devs are getting softballs, or they’re creating a lot of subtle tech debt that someone else will have to fix because they don’t have a full picture of the codebase. Eventually, those devs will be where everyone else is, but it’s still frustrating.

Hang in there.

It’s funny how soon they realize they want a good one.

I use a car analogy for these situations: You need a mechanic (IT professional.) I’m an engineer (coder.) They’re both technically demanding jobs, but they use very different skillsets: IT pros, like mechanics, have to think laterally across a wide array of technology to pinpoint and solve vague problems, and they are very good at it because they do it often.

Software engineers are more like the guy that designed one part of the transmission on one very specific make of car. Can they solve the same problems as IT pros? Sure! But it’ll take them longer and the solution might be a little weird.

Sometimes, very rarely, I tell my squad that today’s our unlucky day and we’re actually going to have to do math to the problem.

Oh hey, it’s a list of everything I’ve been ranting about for the past three years.