#data-science2 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

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.