Links/#software-engineering×/13 entries

I love Randy Au's newsletter in general, but this one makes a particularly useful point: Not thinking about why you're doing something ahead of time is expensive and wasteful.

Randy's discussion of how this issue manifests in software teams in particular is completely on point, in my experience. But it applies to all areas of life. Software engineers get asked all the time to just "log everything", with the assumption being that since we have "big data" tools now, we'll be able to make use of it all later. The reality is that extracting value from heaps of unorganized, unstructured raw data is actually very difficult and potentially expensive, and the time to think about what questions you want to answer is before you start collecting data in the first place. It's also mostly true that once something is being collected or logged, it will go on forever. Another consequence of not thinking through your reporting and monitoring infrastructure ahead of time is that nobody really knows who is depending on what, and so things get left in place "just in case" it breaks something downstream. Of course this is madness, but it's how many organizations operate in reality.

It's true that storage is cheap now, but that doesn't mean accessing said storage is cheap, let alone doing something useful with the mess that's in there. Keeping terabytes of logs in S3 is like having a free warehouse in Labrador for all the tchotchkes you know you don't need but can't bring yourself to throw out.

A lot of this data hoarding stems from organizations wanting to be "data-driven", without ever explaining what that means for their context or why it matters. Collecting data is easy and cheap but does not inherently add value, and the difficulty of extracting value from raw data is a function of its volume (among other things). It's worth spending at least a little bit of time up front thinking about what

This is a really cool tool. I use LLMs extensively in my side projects with great success (my workplace is still investigating whether there are ways we can use them that will align with their privacy needs) and often simulate what this tool is purpose-built to do. I think it's going to save me even more time.

When I first started playing with AI-assistant editors (like Cursor, Windsurf, Co-pilot, etc.) I assumed they would be way better than chatting back-and-forth with an LLM, but it turns out, counterintuitively (to me anyway), that I much prefer chatting over the in-editor suggestions. I find these mostly intrusive and wrong, and they just create more work for me. In a chat interface, though, I can guide the conversation in constructive directions.

It might have something to do with the types of questions I ask them, or maybe just my personality. In any case, I frequently copy-paste dozens of files into a project, describe in great details a project's structure and data model, and then ask questions about it to an LLM. It sounds like this tool can automate and improve that process, which is great news for people like me who frequently engage in this kind of workflow.

I found this article interesting. It's about how AI-generated web UIs might help add more value to the work data scientists do. It was also a little depressing to read as a software engineer, but a good reminder of what our role is morphing into within organizations.

The main takeaway for me was that most code is so shoddy these days that we may as well just get LLMs to spit out UIs that are good enough to serve our immediate needs and then move on. She argues that between the break-neck hype cycle JS frameworks go through, high industry turnover, piles of existing tech debt, and constantly changing requirements, code written by LLMs isn't really that much worse than code written by developers anyway and given the astronomical cost savings, maybe we shouldn't be so skeptical about using generated, disposable UIs.

Of course my first reaction is cringe and outrage, but then I have to immediately admit that she's has a point. I've seen a lot of codebases, and I'm ashamed to say that as far I can tell the average quality of software in the wild is poor to terrible. The sad state of web development these days combined with the increasingly impressive quality of code that LLMs (especially Claude) can write, means I have to agree that it actually makes a lot of sense to use them to write software. They're at least very useful for prototyping and getting started, as she points out.

Ultimately this is just another reminder that software engineering is table stakes now. Anybody doing anything tech-adjacent in many organizations is more or less expected to know how to turn their output into a functioning web app a normal person can see, and despite our best efforts this is still an exceedingly complicated task. Nobody can be an expert in so many things at once, and as long as that remains the industry expectation, I predict that we'll continue to see more and more of the gaps filled by LLMs.