Thread by @hillelogram

Day one of #StrangeLoop proper! I'll be livetweeting all the talks I see on this twitter thread (except possibly the closing keynote). If you're at the conference, come find me for homemade chocolate! I have:

- Cacao brittle
- Vanilla bean truffles
- Tootsie Rolls
- & Caramels!

In addition to the regular conf, there's a miniconf happening today: @gvwilson and @mhoye are hosting a version of "It Will Never Work in Theory", about Empirical Software Engineering!

neverworkintheory.org

-------

"Expert software developers' approach to error", Marian Petre, #StrangeLoop

Beginners see errors as problems, experts see them as opportunities. Instead of just swatting bugs, they look into why they happen.

Talk overview:

- Background
- "Active error"
- insights

The talk is based on interviews and observations of people in finance, search engines, video games, automotive systems, telecoms, all sorts of things.

"I'm talking about teams of these people, but I mean people like you. I want to know what successful developers ACTUALLY do."

Psychology research defines "active error". There are different kinds, like "slips" (typos), lapses of memories, mistakes (errors in judgement or intuition). Once you have an error, you can catch it in the act or recover after. It's part of problem solving.

#StrangeLoop

[I just realized she's using Beamer. I recognize the font!]

She's giving an example of how a simple looking bug had a simple fix, but was actually caused by a change in an open source library combined with a communication error that lead to the bug people possible

[STAMP vibes]

So digging into a bug can deeper issues, like conflicting demands and time pressures. Bugs have to be understood in the context of other software issues, and not all bugs have enough relative impact to justify fixing.

One strategy is tolerating: letting it exist and warning people about it. Good for "obviously nonsensical" bugs, like "Temp is 1000 C".

Deferring: leaving the bug til later.

Thrashing: Poorly-directed, inefficient problem solving. Novices get stuck in it, experts don't as much

Compromise: do a fix that solves the immediate issue but is "not quite right". Can be part of an incremental strategy to totally fix a bug over time. Can also be a design strategy. Building things YAGNI and iterating later

#StrangeLoop

Core strategy for compromise: "focus on the essence."

[Missed a bit because I was geeking out with @Felienne about Beamer]

Experts look for the nonobvious: gaps and implicit assumptions in the code and their mental models.

@Felienne In test case selection, people are four times more likely to look for test cases that prove the code works than test cases that prove it doesn't work. Experts don't make fewer slips, but they ARE better at looking for contrary evidence.

Experts understand by breaking. They test lots of pathological values, like very large numbers, nulls, etc.

[Good use for property testing]

Experts "play methods against each other". Using multiple tools and seeing if they converge

[@mhoye I have thoughts on how this relates to how we understand our overall field and the contexts in which we tell posthoc stories I WILL HUNT U DOWN]

"Writing the code isn't the problem. Understanding the problem is the problem."

[Missed a bunch because had to respond to an email]

#StrangeLoop

Experts reach out to other experts. This means that the person who's best suited might recommend someone else: find the person that everybody recommends, who recommends someone else, and ignore their recommendation.

----

Now at the "Never Work in Theory" miniconf. First talk is "It's like coding in the dark: the need for learning culture within engineering teams" by Catherine Hicks. I was a notch late so missed the introduction. #StrangeLoop

Active learning and making mistakes is often said to be a good thing, but interviews with 25 developers find that when we're faced with our mistakes, like in code review, people get super hypocritical and aggressive towards mistakes, which discourages active learning.

"Learning culture" conflicts with other cultures, like "performance culture", where what's important is "productivity". The conflict causes disconnection and alienation.

"A key paradox of sustainable learning: it looks worse before it gets better."

BTW this is a lightning talk format, so we're already at the next talk.

----

"A large-scale survey of software refactoring", Mohamed Wiem Mkaouer, #StrangeLoop

Speaker was inspired by a person complaining that refactor PRs took longer to merge

Study: take 342 PRs at Xerox, half refactoring half not. Refactorings took much longer to merge and triggered more discussion. Based on this, some recs:

1. Explain the intent of the refactoring
2. Say exactly what the the refactor was
3. Say the impact of the refactoring

When he lived in France, he saw a sign that said "one train may hide another one". One code smell can hide another.

People didn't use refactoring tools, b/c they didn't trust them. So they did another study w/ Jetbrains to see how people used IntelliJ refactoring

#StrangeLoop

------

"Code smells in autogen code", @joannacss, #StrangeLoop.

With AI-based codegen tools, like copilot, you can have code made for you. But how do you know if the code is correct?

Research: look for smells in autogen code. Not proof code is wrong, but is suspicious

Step one, look to see if training sets contain code smells. There are code datasets (like APPS or CodeXGlue). Majority of samples in them had code smells. One had 10% samples had code smells in security-related code. Speaker then gave examples of what the code smells were

Next gets Copilot to do a MySQL database lookup. Generated code hardcoded user credentials and had a SQL injection vulnerability.

This matters b/c people won't blame Copilot for problems, they'd blame you

----

"Automatically avoiding API misuses", @sarahnadi, #StrangeLoop

API knowledge is split between the designer intentions, the documentation, and the user expectations. API misuses are then bugs caused by not using the API properly

There are tools that deal with this, they look for known misuse patterns. Study is to see how well these tools work: how many bugs they raise, and how many of the issues actually matter. Study found that 42% of "finable" bugs were caught, but only 34% of things reported mattered

Better idea: using these "bug finder" tools to get information to the API designer of what needed to be documented or prevented, and then use that to make static analysis tools tailored to the API [I think, tricky to listen and transcribe at the same time!]

[Author is giving an example but the code is too small to see what's going on.]

Can try for yourself at sarahnadi.org/smr/api-misuse/

Briefly stepped into the polymorphism talk and heard the myth that the important part of smalltalk was never the objects and always the message passing and now I'm sad.

(It was always about both, Alan Kay changed his mind much later)

I know this isn't a talk about that, but I hear this historical myth a lot and it's become a pet peeve of mine. I don't know why smalltalk has such a mythical nature to it. Maybe I'm just oversensitive to it.

This has nothing to do with the actual talk srry

Anyway speaker is going to compare polymorphism across multiple different languages: kotlin, cpp, java, scala, Python, rust and go.

Slides are too small to see, I'm gonna duck out and watch this talk when its uploaded

I think I see Robert Martin manning the clean coders booth

Yeah other people have confirmed it's him. Gonna give that a wide berth to avoid the risk of an IRL flamewar #strangeloop

Update nevermind I gave him chocolate

Watched a friends rehearsal and now showing people how cool Tasker is

-----

"Programmable Ink", @szymon_k, #StrangeLoop

Pen & paper is a great tool for externalizing our thoughts. It helps us *think*. External models help us with our thinking.

We're going through several examples of people reasoning via sketching.

Problem with P&P is that it's a static medium. Computers, OTOH, are a dynamic medium: we can put thoughts on it and it can "write us back". But most computer tools mimic static media

(not mine!)

Also, computers push us to make sure everything align nicely, because that's possible, so it gets in the way of sketching our rough thinking. And it involves manipulating a formal language, so you can't sketch. What we want is programmable ink.

[I might disagree w that]

Switching to tablet for live demo. Looks like a sketchpad. You can draw things. He's making a todo list, then drew a checkbox to the side. To actually turn it into something dynamic, we need "spatial queries", like (query/overlaps me), that people can add themselves

#StrangeLoop

He adds code saying that if it's checked, then it should be green, otherwise red, and it works.

"This way of creating dynamic behavior is awful. But I wanted to show you it's not magic."

Next example: showing a ball throwing straight up, put x/v/a on chart

Now showing convolutions: drew chart for f and g, and then automatically generates a graph of "f ◯ g".

"This is a promising glimpse of digital paper, but text programming is not a good fit for a sketchy environment"

Going to show possible solution prototypes

Crosscut looks like vector drawing, but you can also draw "meta ink" vectors, which can hold values. Connecting meta ink to vector lines can force properties, like "a line that only stays vertical"

Next demo: using metaink to add a midpoint to a line that always stays at the midpoint, no matter how the line changes. The properties and transformations are draggable "tag" graphics on the screen, too

He's using all of these components to make a step sequencer out of a vector diagram and metaink. It's kinda hard to describe, you'll need to watch the talk when it's up.

"Simple parts have surprising reusability. Geometric primitives can build dynamic models." #StrangeLoop

Looked away, I think we're on a different prototype. It looks like a constraint solver, with logic being determined by arrows and sigils. Seems very high-level but also incantationy.

"Hand-drawn input is well aligned with exploratory problem solving. Fuzziness of system accommodates fuzziness of our thinking." [Would probably grok this more if I was able to completely follow the example.] So here's links!

inkandswitch.com/crosscut/
inkandswitch.com/backchannel/

"Our goal is to let you create mental models without engineering, tools that build on intuition and fuzziness instead of turning us into logical machines. Tools should help us, not scold us when we make mistakes."

Questions:

- "What is a real-world context of use?"
- "What's the substrate for these tools to coexist?"
- "How do these tools fit alongside existing ones?"
- "How can we make the tools collaborative?"

#StrangeLoop

He did the cool think of thanking his collaborators and I recognized a good fifth of the names

Made a Tasker to open the #StrangeLoop schedule when I scan my room key hell yeah

JOHN ROH MEH ROW

JOHNROMERO

---

"ID Software's Early Days", John Romero, #StrangeLoop

"Some of the things I'm about to say may sound insane, but remember, we were in our 20's. We didn't know there were limits."

As a kid, Romero was really REALLY into Qbert

He started learning BASIC from the college students, at 11, by asking college students what their programs did.

"Then my parents got me an Apple II, and I stopped going outside."

He learned assembly to make "serious" arcade games on his computer

By 15 he was programming for the air force, completely by accident. Then after high shool he got a job for Origin Entertainment, first job was porting 2400 AD from apple II to commodore 64. By that point, he'd made 80+ games for himself

#StrangeLoop

Then he had to hire a team to make SLORDAX.

Eventually hired John Carmack, Adrian Carmack (unrelated), Tom Hall. All of them had a lot of experience making games, but all solo. This was the first time they made games with other people.

John Carmack figured out how to make smooth scrolling work on the PC, made a demo called "Dangerous Dave in Copyright Infringement", and Romero saw this and realized they'd go big. Convinced Nintendo to make SMB3 on PC, but they decided to go nintendo only. So... commander keen!

This was the first time, nine years after the PC, that anyone published a game with smooth scrolling. They made all three first keens in three months. To move so fast they made their own game engine. Was a massive hit. For keen 4, they started selling the engine too #StrangeLoop

id made 13 games in 1991. Were able to move so fast because of principle one: NO PROTOTYPES. "Just make the game. Polish as you go, keep it always shippable."

"Remember, this is a small team of 4 people. Larger teams need planning and prototypes."

Telling a story of trying to get to work during a flood where the roads were completely submerged, and wading past water snakes.

Principle two: "Game should always be runnable by the team. Engine should be bulletproof and provide defaults on memory load failure."

"It should be obvious when something's not loading." If an image doesn't load, show a bagel.

Principle 3: "Keep your code absolutely simple." Up until quake, all games were written in C, not C++.

#strangeloop

In 1992, all four moved to Wisconsin. "Four months later, we're found dead in the snow."

After the winter they moved to Texas.

Principle: "Great tools make great games. Spend as much time on tools as possible"

[Hell yeah tooling!]

In 1992, they made catacombs. "Looked really cool, didn't play really cool." Decided to go all in on 3D. Made wolfenstein 3d in three months, released the shareware, made the rest of the episodes later (didn't know this!) in two months. Sold thousands of copies

John Carmack wanted a more advanced engine, for a game they wanted to call "Doom".

Principle: "We are our own best testing team. Nobody should see a bug."

Principle: "As soon as you see a bug, fix it. Do not continue on."

#StrangeLoop

Doom was inspired by their D&D campaign, full of demons. Also loved Evil Dead

Principle: "Use a development system that's superior to your target." They developed it on Nextstep workstations.

They made complex level editors for Doom and Quake. Just five people worked on Doom.

Doom had to be halted to rush out Wolfenstein 3D due to contract obligations. So they had to learn how to program anything on the SNES. Were in peek id mode and made it in three weeks.

-

Uploaded version of Doom to a university in 1993. People went INSANE over it

People were calling their unlisted phone numbers to ask when the full game would be released.

"On the last day, we worked 30 hours."

1994: Heretic AND Doom 2. AND the Doom 2 Jaguar port

1995: Started working on quake. NINE developers.

Principle: "Write your code for this game anyway. You'll need to write new code later because you'll be smarter."

They almost got a Cray supercomputer for half price. Quake was supposed to have a room filled with Crays. But then Cray was bought & the deal fell through

1995: Released Heretic.

1996: Published Rogue Entertainment's MOCKERFUCKING STRIFE.

[I cheered for strife, nobody else did :( ]

#StrangeLoop

Oh god I was so excited I said "mockerfucking" instead of "motherfucking".

Then quake and final doom and shit.

Principle: "encapsulate functionality to ensure design consistency". Instead of cloning torches, make a torch entity.

Anyway, Quake was 6/22/96. Had a bug where occasionally a frame would show a different part of the map. Traced it to an error in the Pentium CPU, the Pentium FDIV bug

Quake introduced mouse-look full 3D and multiplayer.

Principle: "Code transparently"

Q&A!

Q: How did you collaborate?
A: No source control, floppies, backups were the state of everyone else's computer. But it was okay because everybody was in the same room.

No source control until 2000

Q: What was the bug that Carmack fixed without debugging?

A: They had to speed up the ingame timer to properly handle audio playing. Hardware was sending 16bit timer signals, DOOM was 32bits. So at FFFF hardward would go to 0000 while DOOM would keep going higher

Q: How did you resolve architecture conflicts?
A: People owned chunks of the code, so nobody was ever working on the same file at the same time.

Q: Thanks for making a game that can run on literally everything.
A: You're welcome for Pregnancy Test DOOM.

Q: how do I balance time on personal projects like games with professional life?

A: It needs to be on your own free time. We were working full-time jobs and doing games in our free times. It was a sacrifice of time.

Q: "Your team was suspiciously happy and productive for a suspiciously long period of time. ...How did the business side work?"

A: Did not have even distribution of shares. Romero with Carmack until they made the shares more equitable. Money was reinvested into company.

Q: "Small, high performing team. How and who did you decide when to hire someone?"
A: Hired people after three years. Based on personal connections.

Q: "Tell us about the DnD Campaign"
A: John had a complex campaign with 100s of characters with complex political relationships

[John Carmack rant the game]

A (cont): At one point Romero had to hide in a pocket dimension. Got tempted by a demon to break a containment pentagram. Demon floods world with demons. Carmack started a 2 month apocalypse and killed all his 100s of characters

Q: "What's the origin story of the Does It Run Doom meme?"
A: We released the source code in 1997, eventually someone ported it into an ATM machine. Modern chips are fast enough to run C directly.

Most impressive is getting it to run on 20 bit machines

Okay, that's a wrap for day one of #StrangeLoop! I'll livetweet on a new thread tomorrow.