Scratch

Steam Machines showed them they needed to enforce a quality floor that other manufacturers would need to exceed.

Yes, I’m still mad Steam Machines didn’t take off.

“The first phone I’ve noticed with an external lens…”

It’s true. Every book, movie, game or piece of software you’ve ever used (unless you made it yourself) has been subject to some kind of licence, that can be revoked.

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.

Anycubic has (imo) dire customer support. I’m rooting for you, but don’t expect any delivery updates until you hear your doorbell ring.

We’re all* going to need to come together and really knuckle down, if we’re* to catch up with out competitors. It will take sacrifice* and grit.

But together* we* can do it!

*The people affected will be those with a net worth less than €5m

You don’t understand! Yes, we had to turn our citizens into resources for private companies to harvest and sell! But we needed to create shareholder value!

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.

HL3 soon after. 5real this time guise.

And the George Martin will finish A Song of Ice and Fire.

Start printing things first.

Check for issues and address those issues.

If you start disassembling, you won’t know what needs the most attention, and you might just get bored and give up, without knowing what printing can do for you.

Are ‘super-clickbaity’ articles a thing of the past? The signs point to yes!

Pfft. Amateur. I have a grandfathered license from back when it was $100 one-time payment.

Let’s me install on up to 5 machines at the same time

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.