nickm12

I'm with you in not wanting to see these types of comments in my code. I aim for each revision of the code to stand on its own, and not reference its past or future. There are exceptions and nuances, of course, such as TODO comments or comments related to ongoing migrations. I try to keep these short and reference tasks in the issue tracker, which are going to be more useful to anyone who happens to be reading the code.

I've heard the argument that leaving these comments in, helps support future AI code generation. In this example, it was important to you at the time you made the change that create_* functions have defaults, so having this in the code captures that knowledge for later agents. It's similar to a more general argument that you should leave (correct) AI-generated code alone because it will be easier for the AI to "understand" code it generated that your modified version of it.

I see the validity in these arguments, but I don't think we should be so deferential to these models. The first part of this comment ("Now create_background params have default values") is completely redundant with the function signature and as no place in the code. The second part ("the same as create_screen") is genuine knowledge that is worth capturing for the agent, but it should be captured at a higher level doc about the codebase, rather than tacked onto some arbitrary function as a comment.

It's strange that he shows the graphs with the age of vulnerabilities going up without any real commentary on it (except to say that it's an argument that the number of bugs is not close to zero). I'm not so sure—I think a deeper analysis needs to be done that accounts for the fact that the project itself is aging and also accounts for code churn.

For example, if bugs were introduced and detected via a mostly uniformly random process, but most of the code was written in the early part of the project's lifecycle, then you would expect the age of bugs to go up over time (since there is less young code). Even if the code addition rate was constant, if developers were producing fewer bugs over time, then the age of the bugs would increase, since older code would be buggier.

It's been a while since I taught anyone to juggle, but I generally disrecommended scarf juggling. It's fine if you want some quick validation, but the hand movements are so different from balls/bags that I don't think the skills are transferable.

I prefer the method described in the original post. Just start with one ball and get that right, then two, then three. It's a bit like the Karate Kid, though. Students don't find it as satisfying because they want to jump ahead before they've got the movement down.

1) I would generally use BBSes daily. Probably for an hour in the evening or however long I could tie up the family phone line. I would log into two or three, read and respond to messages. Very much like reading email at the end of the day. I forget what I started with, but once I found ZTerm for Mac I did not go back. https://en.wikipedia.org/wiki/ZTerm

2) I'm honestly not sure how I found my first. Possible I found some number at the local library, possible a friend in high school gave me one. Once you found one, you could learn about others from that one. There was a real culture of different sysops trying to get you to use their board (but only up to a point because it used phone lines)

3) It's really difficult to know. There was no equivalent to web search or a way to see what everyone else was doing. I'd expect the popularity followed some kind of power law, but everyone used a different subset of boards.

4) It's difficult for me to remember. Probably much shorter messages that would seem "simple" by today's standards.

Team CLI. I generally think we should build tools that are usable by humans and agents alike. An anti-pattern is having to use an agent to do something because you didn't build a human-accessible one. Another anti-pattern are MCP (Model Context Protocol) interfaces that are not managing any context.

That said, MCP could be an effective way to sandbox what an agent can do with a tool. Also, it seems plausible to me that a tool that actually provided information to a model via the MCP protocol could be more useful than a CLI tool which operates in the "silence means success" mode of most unix CLI tools.

Basically, make a design choice for _reasons_ and not just because you like that TLA of the option you picked.

This is a really nice take and matches my experiences as well. It also calls out one of the biggest incongruity of this current age: the sudden desire from management to have good specs and documentation for the benefit of the coding assistants.

For the first time in my career, I've seen an engineering org add "improve tech documentation" as a high-level goal. It makes me sad that it was never worthwhile to do for the engineers, but now we need it for the coding assistants who can't tell that our docs really out of date. On the flip side, the coding assistants will actually read the docs, unlike many engineers.

This is such a strange take. The definition of "magic" in this post is apparently "other people's code" and it even admits that that no practical program can avoid depending on other people's code. I think what the author is really saying that they like to minimize dependencies and abstractions, particularly in web client development, and then throws in a connection to coding assistants.

I don't see it, either the notion that other people's code is to be avoided for its own sake nor that depending on LLM-generated code is somehow analogous to depending on React.

Python crossed the chasm in the early 2000s with scripting, web applications, and teaching. Yes, it's riding an ML rocket, but it didn't become popular because it was used for ML, it was chosen for ML because it was popular.

Because you generally cannot test every possible input, output pair.

Yes, because no one conflates an engineer with a compiler. But there are people making the argument that we should treat natural language specs/prompts as the new source and computer language code as a transient artifact.

No, for the reasons given in the sibling comments: you won't want to be locked into a single model for the rest of time and, even if you did, floating point execution order will still cause non-determinism.

I'm not sure what the high-level point of the article is, but I agree with the observation that we (programmers) should generally prefer using AI agents to write correct, efficient programs to do what we want, to have agents do that work.

Not that everything we want an agent to do is easy to express as a program, but we do know what computers are classically good at. If you had to bet on a correct outcome, would you rather an AI model sort 5000 numbers "in its head" or write a program to do the sort and execute that program?

I'd think this is obvious, but I see people professionally inserting AI models in very weird places these days, just to say they are a GenAI adopter.

Thank you. I had to scroll way down to find anyone defending using SI prefixes to mean what they mean everywhere else. A decade ago, I decided to alias "du" to "du --si" and not look back. Entire countries have switched from imperial to metric units. Switching to using base 10 for RAM is really just fine.

I use the phrase "drive-by review" frequently too. As a senior engineer, I worry about doing drive-bys myself. Sometimes my gut tells me something is not quite right about the project, but I just don't know enough about the problem domain or technology/architecture choices to advise definitively.

In this case, I try to question the project owners on their assumptions and whether they have validated them. Usually this line of questioning reveals whether they have "done their homework".

This article resonates with me a lot, but as a senior engineer I would not share it in a big team setting. Even though it's correct, it's too cynical for big team morale. I think it would be worth sharing with peers or managers when discussing whether and how to intervene on a bad project.

Two random anecdotes: when the concept drawing were first shown to the graduate students, someone asked what the swooping walkways above the main corridor were for. The answer they gave was "lightsaber battles".

When we first moved in, there was a seminar room that made some people physically nauseous due to its sloping walls. For a time, they were trying to use masking tape on the walls to make the effect less pronounced. Some of the grad students tried to name it the "vomitorium", but the name never stuck. Fortunately,, once the room had a full compliment of chairs, furniture, and a projector screen the effect seemed to be much less pronounced.

Yes, I think this is what seems to be missed by everything I've read about Gehry in the mainstream. As I said in another post, I worked in the Stata Center at MIT for five years. It was indeed a fun space to walk around in and explore, but it failed to satisfy as a workspace.

I worked in the Stata Center for the first five years and it was just a very poor office building to work in. Even setting aside the leaks and other construction defects, individual working spaces, traffic paths, and communal spaces were not well-separated leading to a lot of distraction. There was also various useless corners due to sharp angles.

I much preferred working in the previous building, CS and AI lab building, NE43. It looked like a punch card from the outside, but had a very nice design with small offices (with closing doors) ringing a common space. The primary downside is the square footage per worker was decadent by today's standard.

Oh wait, we were talking about Frank Gehry, right? His museums looks cool but he should never have been allowed to design an office building.

This is yet another very good critique, but it's long past time that we stop paying attention to Uncle Bob.

Not only are his ideas about how to write software patently bad, but he is willfully obtuse when asked to provide nuance or discuss trade-offs. John Ousterhout's dialog with him, published as "A Philosophy of Software Design vs Clean Code" gave him every opportunity to think critically about his own suggestions and he just doubles down.

https://github.com/johnousterhout/aposd-vs-clean-code/blob/m...

He's just trolling us at this point.

Thanks for taking one for the team. I had zero expectations for Clean Code second edition after reading Uncle Bob's dialogs with John Ousterhout. I thought Ousterhout bent over backwards to give Uncle Bob the benefit of the doubt and discuss the tradeoffs and Bob just dug in on his bizarre dogmatic approaches.

https://github.com/johnousterhout/aposd-vs-clean-code/blob/m...

- Archive: Anything you have a feeling might be useful - Delete: Anything you’re pretty sure would be useless in the future

This has always been my strategy, though some might say I'm closer to "archive almost everything". I still do a lot of deleting, though. Deleted mail tends to fall into the following broad categories:

- security alerts and passcodes - notifications for events happening in a different systems (e.g. Venmo payments, bank alerts, etc.) - receipts for non-durable things like restaurants

I guess I could try to move these more forcefully from email versus phone notifications, but this still is really low priority and it's kind of better to just deal with it in a batch at the end of the day.

That's just Archive with fewer steps

$240/yr is a lot to just have a couple of family mailing lists. Even for creating mailing lists for youth sports teams, local civic orgs, and things like that it's really high.

I agree that the available features can steer the online community culture and behaviors, but it's not determinative. I don't see why online communities should give up useful features just because other communities use them in a way you don't like.

I've been using mailing lists for about 30 years now. In the days before social networks, there was tons of forwarded crap and email chains, such that debunking them was a cottage industry. This behavior eventually moved to Facebook and Twitter which is perhaps why email lists seem more civilized these days, but I don't believe its the features that are driving it.

Sorry, I disagree. The lack of a business model means a lack of competition and a weak market. For years I've been looking to find an email list hosting solution that works for a small family, sports team, friends group, etc. There is next to nothing in this space besides Google Groups. There are a few hosted mailing list solutions, but they have enterprise features and pricing.

What makes them feel like 1970s technology: everyone has to manually manage their own archive and pay storage costs for media files, there is no way to share history (if you want), there is no integrated search, differences in clients mean that people have different experiences of the same message, there are no affordances like reactions that allow people to easily interact with a message without sending an entire separate message.

But maybe I should have said late 80s, early 90s tech. In the 70s, if you were communicating with others on a computer, you were almost certainly using the exact same software on the exact same time-shared system, where at least there was a symmetry of experiences (but no multimedia). The explosion of email clients happened in the 90s, mostly.

Yes! I just bought a dealer-certified three year old Kia Niro with 24k miles for $22k. The current new version of this car has an MSRP more than double that price. There is no world where the difference between these cars is worth $25k. In my head it's more like $10k-$15k max.

Agreed. Any complex mechanical device like a car can be "ridden rough", regardless of whether it is gas or electric. I feel like with gas cars there are a lot more moving parts to get stessed, while electric it's mostly about how the battery was treated. Having bought multiple used cars, including a used EV, it seems like a wash to me.

I read the TeXBook over 25 years ago when I wanted to learn about how mathematics was typeset. It gave me a lifelong appreciation for and love of the art of typography.

The downside is that once you know, you know and you will see lots of bad typography. Though I genuinely think digital typography has continually and gradually improved over the decades. The typography you get "out of the box" is much better than 20 years ago. Also, high dpi displays rock!

Agree these are advantages: Mailing lists are simple - Mailing lists are bandwidth-friendly - Mailing lists interoperate - They're asynchronous - They're portable - They can be freely interconverted - They can be written to media and read from it

Disagree these are advantages: Mailing lists require no special software - They impose minimal security risk - They impose minimal privacy risk - They're push, not pull, so new content just shows up - They scale beautifully - they're relatively free of abuse vectors - They handle threading well

I still use mailing lists, both at work and personally, but they are 1970s technology and it feels like it. We could build mailing lists for this century that keep these advantages and fix what's broken, but there's no business model in it.