Notices by Robert Roskam (raiderrobert@mastodon.social)

Can code be objectively good?

Objectively is doing a lot of work here so let me be very clear. I'm thinking in terms of something like who to measure if a hypothesis in science is good.

- testable / falsifiable
- specific, makes a clear prediction
- consistent with existing evidence
- parsimonious, that it's simple
- fruitful, leads somewhere

1/

Desert soup? I added pumpkin spice mix instead of cinnamon and nutmeg by accident.

My brain be confused.

We have the taste. We have the vision. We dream the dreams, not the AI.

We make the art.

A software engineer without "soft skills" is 0.1x engineer.

We all know this guy.

The one that you make sure to never talk to customer. The one you always need to ensure you approach carefully. The one who's "not good with people."

Yeah, that guy.

Software engineering is fundamentally a team sport. Even if he is very fast at typing in and recalling algorithms from memory, he'll make the entire org around him 1/10 as effective.

The fables of 10x engineers never include:
- updating the docs
- pair programming
- adding meaningful test coverage
- listening to burned-out coworkers
- improving on-call runbooks

The engineers that do these do not seek glory. They plant trees they don't expect to sit under.

I wish more software engineers knew about my favorite debugging method, bisection.

I usually call it the "cut it in half" approach. As an aside, I seem to recall learning it when in college and using it as a method to identify shorts in an electrical circuit.

1/

I'm not anti-LLM. I'm just pro-thinking.

Everyone I know who is REALLY into AI uses it for reading EVERYTHING longer than 1000 words.

It's the mental equivalent of eating only smoothies, because they go down easier.

I say this with love: reading is thinking.

Stop letting slop think for you.

I'm not anti-AI. I'm just pro-thinking.

What do I mean? I mean that everyone I know who is REALLY into AI uses it for reading EVERYTHING longer than 1000 words.

This is the mental equivalent of eating only smoothies, because they go down easier.

I say this with love: reading is thinking.

Stop letting slop think for you.

|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
| Get off social media and hug someone |
|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|
\ (•◡•) /
\ /
——
| |
|_ |_

The Real Engineering Career Ladder

Jr - how do I even code?
Mid - I can code!!!!! Code EVERYWHERE!!!
Sr - how do I solve the same problem with less code?
Staff - delete like 90% of this code
Principal - I miss coding

Things no one will mention at your funeral:

- participated in standups
- increased to shareholder value
- got in expense report on time all the time
- had 90% code coverage on all PRs
- clocked your time on time all the time

This is not an exhaustive list by any means.

Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.

This law captures the fundamental difficulty of software estimation. Even when we know we're bad at estimating, we're still bad at estimating.

- The discovered work emerges because...well, you "discovered" it
- Scope creep happens gradually
- Integration takes longer than expected

The solution isn't better estimation; it's shorter feedback loops.

The best software engineers solve problems, not just write code.

They ask:
- What problem are we actually trying to solve?
- Is this the right problem to solve?
- What's the simplest solution that could work?
- What are the trade-offs?
- How will we know if it's working?

Writing code is the implementation detail. Understanding the problem space, considering alternatives, and thinking through implications—that's where the real value lies.

Code is just the tool. Problem-solving is the skill.

Dunning-Kruger Effect: People with low ability overestimate their competence in that domain.

In software engineering, this shows up as:
- Junior developers confident they can rewrite the entire codebase
- Engineers dismissing "legacy" code without understanding its complexity
- New team members suggesting major architectural changes on day one
- Developers convinced they don't need tests

The most dangerous phase is when you know enough to be confident but not enough to be cautious.

I think this is secretly how most entertainment companies see us.

We’re the llama.

I died laughing on the first question.

https://jsdate.wtf/

AI is hurting engineers.

Many new engineers think the AI is smarter than they are. It's not.

You're paid to think about the problem. One important way you learn to think about the problem is to go through the exercise of writing code—especially the boring parts early in your career.

So if you're new to this, turn off Github Copilot and struggle on some of it for longer than is comfortable. Learning takes place at the edge of comfort.

Embrace McKinley's Boring Principle: "Prefer solving your problem without adding any new tech."

New tech brings hidden costs: learning curves, immature ecosystems, unknown failure modes.

"Boring" technology isn't avoiding innovation—it's being intentional about where you spend your innovation budget.

Goodhart's Law: "When a measure becomes a target, it ceases to be a good measure."

Tell engineers "we need 80% coverage" and coverage becomes about hitting numbers.
- Story points → velocity games
- Bug counts → closing tickets without fixing root causes
- Deploy frequency → empty deployments

The best metrics: (1) multiple measures in tension with each other and (2) measuring teams not individuals.

Favorite songs by programming language:
- C: “Segmentation Fault in the USA” by Miley Cipher
- Java: “Pause! In the Name of GC” by The Stop-the-Worlds
- JS: “NaN NaN NaN” by My Undefined Romance
- Perl: “Oops!… I Did It Inline ” by Britney Syntax
- PHP: “Smells Like SQL Injection” by Nirvana Error
- Python: “White Space” by Taylor Slow
- Ruby: “Gems just want to have fun” by Cyndi Looper
- Rust: “Every Borrow You Take” by The Checker
- SQL: “Join Me Maybe” by Carly Rae Schema