Jennifer Konikowski

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

Dev agencies, if you don’t want to be treated as a commodity, stop acting like one. - Learn the business context for engineering needs - Stop squeezing your clients every opportunity you get - Prioritize transparency, communication, and accountability In short, position yourself as a partner that uses tech to solve business problems. You really can’t complain about being seen as a commodity if you treat everything as a transaction.

1

1 Comment

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

You can't make anyone do anything they don't want to do. If you find yourself with a team that isn't shipping fast enough, you can't use tactics to "increase the sense of urgency". You need strategy. And that's a problem for the Engineering Manager, not the individual contributor. Certainly, allowing developers to be co-owners of a project is best practice, but that only works if it's actually true. That is, if a developer suggests a better way and you ignore it, or a VP 2 steps above shuts it down, then the team is going to learn very fast to keep their heads down. You need buy-in from leadership. In other words, if you fake it, your people aren't stupid. They may placate you, but they'll know. The gaming industry is still finding this out... And another nit. If a developer commits to a timeline that is unrealistic the first time, oh well, it happens. But if this keeps happening, then what are you as an Engineering Manager doing about it? Releases are often a point of resource contention. If you're running into situations where you can't release because of an individual bottleneck, it usually points to a process issue that you need to fix, instead of blaming devs for missing deadlines that are hard to predict.

1

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'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

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

Hey folks, I need some advice. -- What are the top 3-5 things you do when making an API? Does your team have a standard way of writing APIs? Do you do api design reviews? Thanks for your help 🚢 #ApiDesign #SoftwareEngineering

170

59 Comments

I have a question for software teams that meet ISO-27001 / SOC 2 Type II *and* who use outsourced software development with git. Do you have all your contractors sign all your policies so they can contribute to your codebase directly? Or do you have the outsourced team work in a separate git repository and then have an employee merge to the main repo? Or some other model?

3

lateinit and lazy in Kotlin Imagine you’re at a party 🍕, and you tell your friend, 'Bro, you’re on snack duty, but don't bring them right away. We’ll call for snacks when we really need them.' That's lazy in Kotlin! You don’t initialize a variable until it’s actually used. It’s like telling your code, 'Hold up, I’ll get to it later when I need it.' val snacks by lazy { fetchSnacks() } Then there’s lateinit – it’s like inviting a DJ 🎧 and saying, 'Yo, I’ll tell you where to set up later, but trust me, I’ll need you.' Here, the variable is initialized later in the code but must be initialized before it’s used. lateinit var dj: DJService In short: Lazy: 'Bring the snacks when I need them.' 🍿 Lateinit: 'I’ll set up the DJ before the party starts, but not just yet.' 🎶 Now the next time you see lazy or lateinit in code, you know they’re just like party prep! 🎉 #Kotlin #LazyVsLateinit #CodingAnalogies #AndroidDevelopment #DevLife"

12

1 Comment

so what is your move gaes

1

"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

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

Even /if/ "A.I." coding assistants improved productivity of dev *teams* - and that's a big "if" (the last 2 years' DORA reports suggest they don't) - the history of productivity-improving dev tools has consistently been one of them creating demand for *more* software and *more* developers. If you're not hiring and nurturing entry-level developers, you'll probably find yourselves on the wrong side of history. Competitors who did will stroll past you while you're struggling to hire from a greatly reduced pool of talent. That's the FOMO you should be worrying about. LLMs are a dead end. They're already played-out tech.

132

82 Comments

Learn how to write custom result builders https://lnkd.in/ehqq5XK 🧐 What are result builders? 🤩 Defining your own 🚀 Ready to use AutoLayout example #swiftlang #iosdev

7

Observation: 9/10 SWE's quit at “reading the docs”. Cut through the BS with this easy trick: Take action and build. Writing code is 100x easier than the docs make it sound. “Reading the docs” gave me crazy imposter syndrome: -Git -WPF -Kafka -OAuth -Angular -GraphQL -RabbitMQ -Kubernetes In ALL cases, I conquered my fears by building. Except for WPF. I gave up on that. And Kafka, that's for another day. Forcing yourself to build/code/deploy melts analysis paralysis. Then you'll say "oh that was pretty easy". Trust me, we aren't building rockets. Practice AND Study build true mastery.

22

1 Comment

Large scale code change verification... without executing the build for each repository. 🚀 This is going to be an essential element of any practical agentic experience of large scale code transformation, but is a super difficult problem in a couple dimensions: 1. If you execute the repository's build (i.e. like CI does) for each code change, you're talking about a ton of compute, especially when you get into the hundreds or thousands of apps. 2. Even if (1) wasn't a problem, knowing HOW to execute a build for an arbitrary enterprise repository is a super difficult problem in its own right. And the consequences: 1. That's why these solutions are so unbelievably expensive per line of code. But when their proprietors are selling you compute, inefficiency is a win for them? 🤷‍♂️ 2. That's why the few solutions that do this kind of thing with agentic experiences are hyper narrow in what build tool configurations they allow. I'll write more on HOW we just achieved this, but it suffices to say there is enough information in the LST to do compile verification on hundreds of millions of lines of code post recipe making a change, and it costs almost nothing in time or compute.

69

5 Comments