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.

Like any newb, the nuance is lost.

Data types don’t matter, the interface matters.

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.

To maintain the status quo.

Could I interest you in some diagonal bracing today?

“Hostile posture”

I really like that phrase.

thats-the-joke.wav

I’ll bet people said the same thing when Intellisense started suggesting lines completions.

And when errors were highlighted in the code rather than console output.

And when high-level languages started appearing.

Figma - Ligma - Ligma balls!!! GOTTEMM

Hashmaps are just arrays with notions. Sets are just hashmaps with doormen.

How is this a parody? It’s not poking fun at the original or pointing out its flaws.

buh muh fare youse!

It’s actually a good ad, though I question the setting for a young woman. She is so immersed by the display, the room she is in has faded away and become whatever game she is playing. That’s why there is no computer desk.