Dealing with this now at work. Got a dev whose time in the industry should make him a senior dev but he gives off massive junior vibes.

• The need to change everything he touches

• Wanting to write clever code over straightforward code

• Everything “needs” a refactor

• Just deprecates things when he doesn’t want to learn them and writes a new implementation without updating old code

• Thinks he knows best while not understanding huge swaths of the codebase

• Everything he can’t understand in <5 min is stupid and wrong

If he was less competent (when kept in a box and closely monitored) I’d be pushing even harder to get rid of him.

I’m not understanding the CoPilot hate. It’s an amazing tool if you are competent. Even when it gets it wrong it still saves me 90%+ of the typing then I just correct what it did differently than how I want it.

Boilerplate becomes a breeze and I work way better when I have something to iterate on rather than coming up with it from scratch. It lets me play with and test ideas way faster and sometimes even does it differently than I’d do it which leads to learning new things and/or looking at the problem in a different way. I don’t blindly follow its output, sometimes I reject it wholesale, sometimes I edit it, sometimes it’s literally exactly what I would have typed myself.

I’ve got nothing against SSR, never have, but CSR or even better SSR+CSR side steps a metric shit ton of issues. I’ve written untold lines of code to render something out in PHP then needed to add jQuery logic to the frontend for UX/UI reasons and then I’ve had to duplicate UI generation in JS/jQuery to match what PHP spits back (think: add a new row to an interface after an Ajax call finishes). It’s hell, you have to keep the two in sync and it’s a bug minefield.

Compare that to CSR where all the DOM is generated though a single codepath. Now take CSR to the next level with SSR+CSR and you’ve got a winning combo. Fast initial render and SEO gains (if you even need that) and only 1 DOM generation pathway.

People want to sound all smug “Oh, back to SSR are we?”, “Uh yeah, we had to CSR first to get to SSR+CSR which is VASTLY superior to SSR alone”.

Tech is circular in that way. See also mainframes, to personal computers, to cloud or any other similar cycle.

This might be the most sane take in the this thread.

Yes, ideally it would all match up but I’ll reject PRs that want to rename a bunch of files/fields/properties/columns/etc because marketing/business want to call it something else. Also you have to pick your battles, sometimes it’s just not worth fighting it.

We have some things that were named badly on the backend a decade or more ago, in our API we name them correctly (example “qty” on the backed, “quantity” in the API). We will NEVER go back and change the old name, it’s not going to happen. It would take a massive effort for no real gain.

Also parts of our API are (semi-)publicly available and so we take that as an opportunity to rename certain things for “public consumption” because we call something different internally (with justification) but there is no good reason to make external people learn our internal lingo/concepts.

Lastly I’ve learned over the last 15+ years in the industry that just about every “black and white rule” is a bad one. You shouldn’t have a slavish devotion to a rule just because it is a “rule” that someone slapped down at some point. It’s like the REST purists who bitch and moan about “that endpoint isn’t RESTful”. Get out and write some real software with real business requirements then get back to me.

I’m not saying rules are bad and I believe heavily in the “Chesterton’s fence” concept but you also have to know when to break the rules instead of twisting yourself and your code into a pretzel to stay within the “letter of the rule”.

I much prefer having an in-memory database than mock what a database does.

Which sounds great in theory but then you get to find where your prod DB and testing DB differ and you have to keep chasing that. Unless you are using something like SQLite which has both (disk and in-memory) as an option.

I worked at a place that used a different in-memory DB (H2, IIRC) in place of our MySQL DB for testing. It ended up being hell to maintain and had to have hacks for how H2 and MySQL differ (tests would work in H2 but fail if run against MySQL or vice versa).

Yeah, I’ve been paying $5 (or is it $10?) a month for my Ghost blog on a digital ocean droplet. It’s not worth it, my plan is to move to a static site generator (probably CloudFront -> S3 deployed via GitHub actions in a private repo) at some point. The features of Ghost don’t really matter to me and I hate maintaining the install/updating. Ghost feels like it’s moved more into “self-hosted substack”-territory which I have zero interest in, my blog posts are all public. Also, you can’t hack static files so security isn’t a worry with SSG which is super nice.

Not sure which SSG I’ll go with, when I was younger I would have written my own but now I’ll just pick something off the shelf that has nice themes lol.

I ran ZoneMinder for years before buying a Reolink NVM and now I couldn’t be happier. I’m a huge self-host-er but unless you want to babysit it ZoneMinder is a pain to self host. I ran it in docker, I ran it on raw metal, I tried multiple plugins/configs. Nothing beat the plug and play of a Reolink NVM. I say this as someone with multiple servers and ~150TB of storage locally.

Skip the headache and buy something off the shelf for this.