Scratch

PR reviews take the most time, eliminating those saved us loads of time.

QA were also bogging us down, axed them too. Now we’re flying.

The Social Security Infrastructure rebuild should be done in a matter of weeks! At least that’s what Copilot says.

Be a man.

‘git commit -am “changes”’

Mobile app users get annoyed if you push too many updates. So you gotta pace yourself.

I completely agree. Not mentioned in my spiel is the constant human QA effort, each ticket merged gets checked, releases get a week of testing before release to the public.

Also, yeah. I’m iOS frontend. I make pixels dance. Either I leave security to Keychain or I hope (read: confirm) backend is sanitising inputs.

Small PR are easy to review and parse. Work gets broken down in to small, shippable changes. If you couple that with feature flags, you can get to a point where shipping a release is as easy as building whatever the latest commit is on Main and pushing it out the door.

Automate that, do it every week or two.

Tell me you commit your dependencies without telling me you commit your dependencies.

As I understand it, Bruce already spends a lot of money helping Gotham, but the city is so corrupt it’s slow going.

Like any newb, the nuance is lost.

Data types don’t matter, the interface matters.

It uses proprietary, disposable, non-rechargeable batteries with drm built in. $60 for 4 hours playtime.

/s?

But modern shareholders have a policy of jumping on the AI bandwagon. Line must go up!

Can you give me the TL:DR?

I genuinely feel like that was a coordinated campaign to erode voter trust and motivation with some trolling thrown in on top.

Catch any single lib and ask them straight up; “Do you think both sides are the same?”

Some liberals.

I use a specialised hammer-and-anvil system that produces an audible notification whenever someone use it.

Difficult to make, too heavy to be effective, and iirc yeah, unreliable.

Or skin tone.

Ah, but you see the AI let us reduce headcount for full time employees. Reducing the budget for full time salaries.

Now we just spend twice as much on contractors and consultants, but that’s a different budget, so it’s not my problem.

The site doesn’t define what a code smell is, though. It’s just a list of Don’t Do’s.

That’s kind of the nuance I would be hoping for.

Something like:

Code Smells are clues that something is amiss. They are not things that always must be ‘fixed’. You as an engineer will, through experience in your own codebase and reading of others, develop a sense of the harm imparted by and the cost of fixing Code Smells. It is up to you and your team to decide what is best for your codebase and project.

(The rule of 3 formatting was intentional, given the community we’re in)

I think to present rules like this as hard rules, with little explanation and no nuance is harmful to less experienced engineers.

A prime example here is the Duplicated Code one. Which takes an absolute approach to code duplication, even when the book that is referenced highlights the Rule of Three:

The Rule of Three
Here’s a guideline Don Roberts gave me: The first time you do something,
you just do it. The second time you do something similar, you wince at the
duplication, but you do the duplicate thing anyway. The third time you do
something similar, you refactor.
Or for those who like baseball: Three strikes, then you refactor.

I’ve seen more junior devs bend over backwards, make their code worse and take twice as long to adhere to some rules that are really more what you’d call guidelines than actual rules.

Sure, try to avoid code duplication, but sometimes duplicating code is better than the wrangling you’d need to do to remove it.

Making extra changes also leaves extra room for bugs to creep in. So now you need to test the place you were working, and anywhere else you touched because of the refactoring.

Like all things programming; It Depends.