John Endres

Watched a portion of the old Brian Will video on why OOP is bad (https://lnkd.in/epvfRpPR), and bombed out fairly hard when he came out with the puzzling assertion that messages between objects properly speaking shouldn't include object references. Well, there goes your visitor pattern; there goes the UI staple of registering objects with some event bus for callbacks when particular events happen. Is there some source in the literature (Alan Kay, I guess) for this odd restriction? It seems like a basic misapprehension: sure, messages should transfer representations of internal state and not haphazardly leak references to the state itself (otherwise external parties can mutate it without going through the owning object's protocol), but it's also a pretty basic affordance of message-passing systems that the addresses of things that can receive messages are first-class things that can be passed around (compare URIs in REST, or channels in pi calculus). The other odd assertion was that permitting many objects in an arbitrary graph to hold a reference to an object and access its methods was as bad as having global shared state. It fairly obviously isn't: the ability to exercise the protocol for reading or updating a particular bit of state can get passed around to wherever it needs to be, but isn't immediately available to everything, and pretty much the whole point is that you're passing a pointer to the protocol, not the rights to inspect and modify the data structures it guards. It seems that Will wants to argue for a hierarchical flow of messages down a DAG-shaped stack of routines and subroutines with a single controlling root procedure, rather than a potentially cyclic call graph with objects fielding requests from all angles. In practice that's what your average Spring Boot service actually does of course: controller to service to persistence or external client layer, and back up again. But (and this is an argument for a future post) that's because the average Spring Boot service is fundamentally procedural code, with a bit of indirection between modules. Other topologies are possible, and appropriate for particular use cases. The most generous reading I can give of Will's argument is that OOP offers more flexibility than perhaps a majority of actually existing programs really need, and we'd be happier and less burdened by object bureaucracy if we wrote those programs in a more constrained idiom. I actually think that's kind of true, but haven't got to the bottom of what it means in practice just yet.

2

"The only valid measurement of code quality is # of WTFs/minute" I can't remember if he's the origin, but I got that from Robert Martin's clean code. And honestly looking back on my career it is true. But it does not only apply to SWE, I think it applies to Engineering or better yet symmetry in general. You see, the problem with bad code or a bad design, is that based on what you know to be right (and hopefully you are indeed right) what you are seeing is asymmetrical. Examples: An API fails to implement the intuitive use case. Or Drastically changing the behavior of an SUT does not trigger a failing test. Or Someone writes code that only expects the happy path.... what if the remote item you are trying to interact with is unavailable? In all this, it is probably worth noting that Symmetrical doesn't necessarily mean "Correct", it just means it makes sense to you. So make sure you are indeed correct (probably by fact checking and having empirical data)

1

1 Comment

‘In this episode of “The Engineering Room” Dave Farley chats with renowned author, speaker and expert software developer Kevlin Henney.’ https://lnkd.in/gsenvBMQ ‘In their wide-ranging discussion they talk about: • Why Kevlin Henney is famous for big public software failures! • Software Engineering, mathematics and the interesting gap between formal programming and sloppy humans. • Architecture, empiricism and three ideas for design. • Coping with incomplete knowledge and making stuff that works in the real world. • Confidence, certainty and loose-coupling. • Learning from actual failure, not just simulation. • Programming is deceptively easy to start, and gets complicated really quickly: Low Code is no exception.’ Continuous Delivery Ltd Bernard McCarty #ContinuousDelivery

21

A good use I've had lately with ChatGPT is when I'm debugging code and I've spent more than 20 minutes and can't crack it. 9 times out of 10, I have a missing parenthesis, a variable type issue, or a param passed incorrectly to a function. I will simply paste my code in ChatGPT and say "Fix this" and it usually pinpoints the problem on the first try. I don't have to tell GPT what coding language it is or even what the error message I'm getting is. It is a huge productivity boost. It has saved me a ton of headaches. ..the end. #dataengineering

72

30 Comments

"Curiosity over tenure" -- use quality telemetry in your traces to make debugging accessible. Empower curious folks to debug, not just the most tenured person on the team/company. Metrics are great... they're cheap, enable high data retention, but they're coarse... too coarse to understand what's happening in your system. If you're solely reliant on metrics, you'll need lots of intuition and tenure to understand what's going on in the system. "Oh... it's the cache" says the hero on the team peering over a graph, and doing some inaccessible pattern matching. It looks cool, but it's not scalable. Adding lots of telemetry to your traces ensures anyone with a curious mind can understand what's going on in your system.

3

Recently I was reading about the VW data disclosure, and I was thinking: could an LLM spot this? So I built a small prototype using PDL script, and the results are pretty good to be honest! More detailed information here: https://lnkd.in/dqJSMPkU

5

Working on a specification for https://lnkd.in/g-pBfAQv. Then I can verify it with tests and https://blprnt.tech/. I'm reminded that wormwood is optimized for readable source code, not UX. There is very little syntax validation.

4

I spent some time and completely rewrote the whole NATS micro framework for Piggybank. Now instead of headers, it's more of an idiomatic NATS approach using the verbs in the subject. I also updated the subjects used for database actions and secret actions. The binary now also includes a subcommand for database and secrets actions. I don't think anyone was actually using this so I figured completely changing things around wouldn't matter. I think I'm going to actually try to make this a real project. https://lnkd.in/eDuaWtrY

19

If you're the kind of person who's excited about all the recent S3 feature announcements (bucket policy unlocks via temporary root sessions, up to millions of buckets per account, pagination and region filtering for ListBuckets, conditional writes, ListCallerAccessGrants API) and you're attending re:Invent, then you should come to our storage track session, STG306 Advanced security patterns on Amazon S3. Learn how to use all the exciting new stuff securely in the most interactive format available at re:Invent!

94

2 Comments

No matter what language you’re programming in, errors happen. One great thing about #Rust is that you can diagnose and act on them quickly – if you know which tools and mechanisms to use. Learn more on our Tech Blog. https://bit.ly/4gmccX5

2

Declarative Command Pipelines About four years ago (according to GitHub) Patrick Martin introduced me to picocli - a great piece of software for building command line tools. Back then Pat told me about command pipelines he was building. My level of mental investment into picocli was very low and I assumed that Pat meant traditional pipelines - output from one process is serialized and is fed to another process. And maybe he meant just that. However, I wanted a pipeline which could pass Java objects between commands without serialization and crossing process boundaries. And maybe Pat meant this kind of pipelines - sub-commands receiving objects from parent commands. Anyway, just a few years later I finally got it (when I really needed it and invested some time into thinking about it). I also extended the out-of-the-box picocli way of building command hierarchies with a declarative approach - binding sub-commands by parent command type. This Medium story explains the details - https://lnkd.in/dncg6R9f. So, thank you Pat for pointing me in the direction of picocli and pipelines!!!

8

For folks who've used copilot or other genAI tools a lot, I'm curious how good the unit test generation ends up being long term. I'd be concerned that you'd end up with a lot of test suites that verify exactly what you implemented, which are not going to be as useful as TDD cases that are more focused on the intended behavior rather than the code you wrote (which might have latent bugs to begin with)

17

1 Comment

Leveling up my C programming! Check out my probably horrible C https://lnkd.in/gQuDqNk2 I just completed "Historian Hysteria" - Day 1 - Advent of Code 2024 https://lnkd.in/gZWCqCdQ #AdventOfCode

4

1 Comment

It can't be a coincidence that my favorite band, LinkinPark, is celebrating their comeback in the same year I decided to step away from my current leadership role to become a software engineer again. Damn, it feels good hammering some lines of code on the keyboard while listening to LinkinPark again. 😅🤘🎵 Why did I change my role, you ask? The short answer: less talking, more doing. I’ve always loved leading creative teams and helping people shine. But leadership isn’t only about a title or a place on the organizational chart — it’s about setting an example and inspiring others. As a Principal Software Engineer at Shopware, I see my role as one where I can lead by example, pushing boundaries and driving innovation from the frontlines. It’s a hands-on approach, focused on building and making things happen. This is not a step back, but just another chapter in my career and not the last time I will try to be a good leader. "Heavy is the crown". https://lnkd.in/emHAJXkj

44

Day 3 of Advent of Code, and it's time for some newer Java features: sealed interfaces and pattern-matching. They're a good fit for this use case: pull some tokens representing instructions out of an input stream, and feed them to a simple state machine. As I discuss in the notes, we could have done this in a more classically OOP way (have each token type know how to update the state machine; have the state machine expose the methods the tokens use to update its state, possibly following the Visitor Pattern), but it feels cleaner not to. https://lnkd.in/ekgD-2GS

The latest Qwen2.5 Coder models outperform Sonnet and 4o on some benchmarks. Try it on Wingman today!

4

When someone reviews your code, they approach it with the same fresh perspective you'll have in six months. If they don’t understand something, it’s not about their ability—it’s a signal your code could be clearer. Their feedback helps ensure your work is maintainable and easy to understand, even without all the current context. Every suggestion for clarity or simplicity is a gift to your future self. Code reviews aren’t just about today—they’re about building code your team (and you) can rely on tomorrow.

20