Justin Bricker

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

I once asked a lead engineer on Angular: Which is better: Angular or React? His response: "Both require good engineering to be effective." So, my developer friends, consider this a reminder that "frameworks" like Diátaxis are fine, but they still require good engineering--such as UX, information architecture, style, maintenance processes, and so on--to create great documentation experiences for your customers. Alas, the framework alone isn't enough.

35

7 Comments

Reading about the CAP theorem in distributed systems. Some posts online claim to have systems that achieve consistency and availability - is this possible, if so, how? I read an article from Coda Hale called "you can't sacrifice partition tolerance" - link in the comments. I've been looking into how LLM systems operate, much like Google search, where availability supersedes consistency but obviously trading systems must (for the most part) prioritise consistency. ...and we're hiring - link in the comments! #distributedsystems #Hiring

10

4 Comments

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

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

I know some software developers participate in the Advent of Code challenges at the end of the year which can be a fun way to learn a new programming language or hone your skills in ways that you might not get to flex in day-to-day development. If you aren't but are looking for a "winter break" sort of project, I propose that if you have never written a raw TCP client and server, that you try. Could be something simple like an echo server or maybe kick it up a notch to writing a chat server. Most jobs don't need that low of a level of socket programming anymore but I think writing something basic helps you appreciate what the abstractions that using a http or rest client gives you. I have used my knowledge of socket level programming professionally multiple times plus it really scored points when I was interviewing at a very well known company that recruits top talent when I was asked what I knew about networking and I countered with I needed more clarification on the question. Did the interviewer want physical/hardware knowledge, sockets/packet knowledge, or more application knowledge. The counter was asking me a little bit about all three. I could explain what my knowledge on all of those and what I likely didn't know/remember. The interviewer was impressed because he was used to candidates answering around the http protocol in relation to rest. Which helped because I lost some points in a couple of the other interviews. I'm not saying everything needs to be related to interviewing but part of our profession in constant learning. There is nothing that says it has to be the latest and greatest technologies. Diving a little deeper on the fundamentals is never wasted, in my opinion. #software #softwaredeveloper #softwareengineer

55

15 Comments

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

"I don't like leetcode style interviews!" See I wasn't making it up! Kurtis Nusbaum tells us more about why engineers don't like leetcode and the types of interviews that lead to a more enjoyable and effective interviewing experience.

4

1 Comment

i think we frame hiring "juniors" weird in order to avoid talking about calcification. doing anything, literally anything, for a long time, makes you better at doing the thing, but worse at doing adjacent things you do not also practice (ex. working effectively in a strong test culture does not help one optimize for hip-firing kubectl commands, and *does* explicitly optimize for taking one's time and thinking heavily). your "seniors" and "juniors" provide similar value adds in terms of where they say "what the fuck?" seniors only say "what the fuck?" when they encounter bad behavior *that they have not already calcified in themselves*. your seniors all have a few absolutely awful habits that make your product worse, waiting for a convincing junior to say "what the fuck?" at the ideal moment to *fix* them. if you don't find that convincing junior, they will propagate that calcified misbehavior throughout your org and sink your shit. you also probably don't know what the problem is, because you share the calcification. and this is all normal and good, because if you're arrogant enough to think that you deserve a team of only seniors, you deserve exactly what that gets you.

11

1 Comment

I've been thinking a lot lately about ways of structuring IaC code, specifically - should this code be separate from application's code, or they can (should) be kept close to each other. When writing backend code, my rule of thumb about managing transactions (and other resources, like connections) is that a method or class cannot interfere with its (transaction's) state if that transaction has been started somewhere outside of that code. In simple words, only a piece of code that started a transaction should make a decision to commit or roll it back. Looks like this model can be applied to codifying infrastructure as well. If an application owns the lifecycle of an infrastructure resource, it is okay to put them in one source code repository. Short unpolished writeup on this topic: https://lnkd.in/emzDC9Nn

2

There were other examples of this around the web, but none explained _how_ automatic reloading worked in Django. Some implementations felt half-baked. I think this one stands apart. This is also my 70th blog post on DEV 😮 https://lnkd.in/gtC6sBMr

3

2 Comments

Some unconnected thoughts on this “ghost developers” panic: Despite tech being a major economic driver for a couple of decades, MBA programs, and therefore the state of management thinking, are rooted in manufacturing. The mindless drive for efficiency in all kinds of businesses makes the most sense if you’re talking about factories and logistics. Not so much for knowledge work. Software is the only huge field where “R&D”, “production” and “services” are collapsed into one big undifferentiated mass. The output of product development is code shipped to production, and it needs to be continually maintained and updated. The closest thing software has to a manufacturing model is offshoring engineering to eg India or Eastern Europe, while keeping design and product/eng leadership in the US, but that creates ongoing problems because you can’t just hand off specs to India for manufacturing and move onto the next launch. Offshore teams need ongoing support because the customers need ongoing product support. Because engineers produce the actual shipping product, while they’re closer in spirit to fellow managers/leaders or an R&D team, the manufacturing mindset can only really make sense of engineering as the factory floor, and MBAs’ whole thing is looking for ways to extract extra pennies by optimizing manufacturing and distribution. They can’t actually do that with software, but they aren’t technical enough to know that, and it doesn’t stop them trying. So, “ghost developers” — which, of course, is just engineers writing good docs, being in meetings, talking to customers, supporting each other with code reviews or pairing — seems like gross inefficiency because it looks like a factory producing fewer LOCs than companies are paying for. Remember how, when Elon took over Twitter, we’d hear about him asking coders to _print out_ their latest contributions to the codebase, and if the pile was too short they got fired? Elon is a manufacturing guy, not a software guy. Even the “Stanford researchers” part is MBA culture gone wild — they have _no idea_ what’s involved in making software, and can’t even talk to their teams effectively, but they think their dumb mindset is “science” and now they have “research” telling them they could fire half their teams and be more productive. 🫠

1

Woah there, "hiring juniors is about making your entire team better" is exactly the kind of unhelpful, oversimplified headline that needs an A4 sheet of caveats adding. Juniors are a massive investment and the suggestion that simply hiring them will make the team stronger is not right at all. Processes that support the career development of more junior engineers aren't accidental byproducts, they're deliberate. Senior engineers need to be provided the time, headspace, training and support to coach, mentor and develop their more junior colleagues. You know what doesn't work? Hiring juniors into overstretched/under-resourced teams where the seniors are overcommitted and under pressure to meet aggressive deadlines. And I've seen this more times than I care to mention. In the scenario where you've got small teams that are under pressure, and the existing engineers don't have time or headspace to coach someone junior, you are *always* better hiring another senior. Someone who reaches autonomy faster will always be better in that situation. If you hire a junior into that team you won't get better code reviews, more innovation or a richer culture of learning. You'll end up with an under-developed junior who struggles to progress their career, and some seniors who feel like they're doing the junior a disservice by being unable to support them properly. It's horrible. And I've been there. Were we all juniors once? Yep. Should *every* team hire juniors? Absolutely not.

4

"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

This is a very good paper on benchmarking courtesy of Justin Jaffray. We definitely need more practical books and writing on benchmarking practices geared at senior+ developers. https://lnkd.in/enuumUy4

30

3 Comments

Every time I pull on the "Oh, you must be using them wrong" thread with "A.I." coding assistants, it seems to lead to a lower quality bar. That's the "prompt engineering" secret sauce, apparently. Care less. I did actually say I was afraid this is how Gen A.I. would play out over a year and a half ago. I wasn't afraid that they'd be able to do my job; they clearly can't. What I was afraid of is that execs and investors won't care that they can't.

46

10 Comments

🏎️💨 Making of a Ridiculously Fast™ API client in R. Why my package is **~17x faster** than the community alternatives that call the **exact same API endpoints**. 👇🏽**design choices matter** ✨ https://lnkd.in/ggi_2XyQ

129

2 Comments