Bruce Sterling’s “Heavy Weather” describes (offhandedly) a post-agricultural ecosystem where only herbicide/cold/heat-resistant weeds remain. People then breed genetically-engineered livestock that can convert the weeds into more useful substances.
It elevates Google itself. “It’s a place where people like Jeff and Sanjay work!” Not saying that was the main motivation for producing the article and definitely not trying to question the protagonists’ achievements.
You could say that about any article that is even slightly positive about anyone that works for Google. It's an absurd premise. It prevents the telling of stories that have good outcomes.
He didn’t generate the music himself, and likely worked with others on setting up the bots (the article mentions co-conspirators). On the song generation:
> This led Smith to pivot to AI-generated music in 2018 when he partnered with an as-yet-unnamed AI music company CEO and a music promoter to create a large library of computer-generated songs. The district attorney announcement did not specify precisely what method Smith used to generate the songs.
I wonder what company he used and whether they can be liable too.
But comments go out of date, and the compiler doesn’t check them against the implementation. To document + enforce the intended functionality, use tests.
Outdated context is miles better than no context in my experience. As long as the comment isn't intentionally misleading, it always helps a ton in piecing together what happened, even if the comment is factually wrong when it was written, because I can tell how the original author was mistaken and why it led to the current code.
Outdated comments are great, because it means you probably have a bug right there. If the comment didn't get updated, the code change probably didn't look at all the context and missed things.
Does it matter? If the comment doesn't match the code, there's a bug (in the comment or the code). Either way you need to spend time to understand the context and figure out the correct thing, not trusting either.
Looking at the commit history is a great start. Especially if your team actually empowers people to reject code reviews when the commit messages are unclear or insufficiently detailed.
Generalizations like that are theoretical, and don't always align with reality. There's nothing wrong with comments summarizing the "what", and in fact doing so is a good thing because it can describe anything from the intention of the code to the business logic. "This function merges array X with array Y, converting all the keys to lowercase because they will be used later by foo()."
The "why" can go out of date, e.g. "do X before Y because [specific thing in Y] is dependent on [specific thing in X]". If you rewrite Y to no longer be dependent on X, the comment is now out of date.
The reality is that any comment can go out of date at any time if the code it describes changes enough. But that's really no excuse for failure to maintain comments. Sure, in reality code is messy and inconsistently written, not even counting comments. Comments are an essential parts of your codebase, and while they are used exclusively by humans, that doesn't mean they are any less worthy of being updated and cultivated.
I dunno, the "why" for me is "why are we doing this, and doing it this way?". If that changes, but somehow the comment isn't changed, that would feel really strange. It's not just tweaking a few lines, it's rewriting the whole routine. If all the code changed but not the comment, that would have to be deliberate, and definitely picked up in code review.
Though, obviously, accidents happen, etc. But then that also happens with tests and everything else. I have definitely seen out-of-date tests in code bases, where the test is no longer relevant but still maintained.
So I actually find this helpful because if the why doesn't match the what (code), I know to look back at the history of changes and see why there is a mismatch. This is honestly a great signal that something might have gone sideways in the past while I'm trying to triage a bug or whatever. So even if the comments are out of date, they're still helpful, because I know to go look at why they're out of sync.
Comments go out of date because of bad developers.
The same people who do the bare minimum for tests not to explode. But won’t add a new test case for the new branches they just introduced.
The same people who will mangle the code base introducing bizarre dependencies or copy paste the same piece of code rather than refactor.
People who fail to handle errors correctly. My favorite: by wrapping code in a if statement without an else. (else? Get a weird error without logs! Miles away from the call site!)
People who don’t validate inputs.
People who don’t give a monkey about adding context to errors making the thing impossible to debug in prod when they explode.
People who are too lazy or in incompetent to do their job properly and will always jump at the opportunity to save 5 minutes now but waste 5 hours of everybody else’s time later. Because of course these people can’t fix their own bugs!
And of course these are the people who make comments go out of date. I’ve seen them implement a thing literally the line below a TODO or FIXME comment and not delete the line.
Comments going out of date is a shit excuse for not writing comments as far as I’m concerned.
The fact that some people are incompetent should not drive engineering decisions. You should always assume a minimal level of competency.
> Comments going out of date is a shit excuse for not writing comments as far as I’m concerned.
I agree.
> Comments go out of date because of bad developers
I disagree.
Comments can also go out of date because
- developer is having a really shit time atm and their head is not in the game (bad looking after people management)
- developer is on a one day a week contract and doesn’t have the time in their contract to write big header comments explaining nuances (bad strategy)
- developer thought it looked obvious to them but it’s not obvious at review time (developer is being classic human)
- developer is getting pushed to deliver the thing now now now (bad workload management)
Most of those are the result of some decision made by someone who was not the developer (they’re all real cases). And they are the “non-code blockers” that good managers solve for us, so we can focus on getting good stuff done.
I’ve been where it seems like you are at. Blaming others for being bad didn’t help me. I had to lower my expectations of others, keeping my expectations for myself. Then get on about teaching willing people how they could be better. Might be making a few assumptions/projecting a bit there, but that’s my experience with “bad developers”.
Being any type of “leader” is lonely. Whether that’s an official role assigned to you or not. Or if it’s just a skill level thing. No one can quite match up to the expectations or understand what we see and why. But explaining it goes a long way with the right ones.
> Just like updating the tests when code is changed, update the comment when the code is changed.
Well, yeah. But the point is that tests can be run in a pipeline that can fail if the tests fail. Comments going out of date has to get caught by a human, and humans make mistakes.
Yeah but there's a fundamental difference between something like tests that can be checked automatically and comments, that have to be checked manually. Because of this, it can be assumed that comments will eventually go out of date.
Good PR review from a skilled and more senior developer catches these things, most of the time.
Just like how tests catch functionality issues , most of the time — bugs still exist in tested software, because people make incorrect assumptions about how/what to test, or implement the test wrong.
> it can be assumed that comments will eventually go out of date.
Don’t make assumptions. That’s just a lazy excuse for not trying.
The same thing could be said for tests
> it can be assumed that tests will eventually go out of date
So why should we bother updating tests? They’re just going to go out of date?!!
Because it makes the codebase easier to work with for someone brand new.
Same as comments.
Pay down the debt for the next person. The next person could even be you in a year’s time after working in a completely different project for 9 months.
Tests only test functionality, they don't test business context. Comments explain business context.
For example, "we have this conditional here because Business needs this requirement (...) satisfied for this customer"
Your comment can test the logic works correctly. But someone coming in, without the comment, will say "why are we doing this? Is this a bug or intentional? Is the test bugged, too?"
Now, they'll see it's intentional and understand what constraints the code was written under. Your test can't send a slack message to a business analyst and ask them if your understanding is correct. The original dev does that, and then leaves a comment explaining the "why".
> To document + enforce the intended functionality, use tests.
Tests go out of date
Tests increase the maintainince burden
The compiler does not ensure code is tested
Tests get duplicated
Mēh! Tests matter, and testing is very important. Good judgment is required
Just like comments.
Writing code requires professional care at every step. The compiler helps of course see, but being professional is more than writing code that compiles
It involves documents too. And tests. Not too many (tests or documents) but not too few
Undocumented code is an enormous burden to maintain (I am eyebrows deep in such a project now). It is not enough to just write code and tests, documents including inline comments, are crucial
Note in Rust if you include comments with code that will run as tests but be inline in your main code instead of having to find the relevant test function to confirm functionality.
Go has something similar: functions marked as examples that are both run as tests and shown and run as examples in the documentation (https://go.dev/blog/examples)
Interesting. I don't know when that was implemented in Rust but clearly Go has had it for a long time, since that post is dated 2015.
While things like syntax are important, languages adding tooling like this (along with stuff like package managers) is so important to the continued evolution of the craft of software development.
It’s also surprising that BBC, a government-funded media outlet, is showing ads. Either the government funding isn’t enough or they are trying to recoup some of those costs by showing ads to people who’ve already paid for the content with their taxes (even the international part is paid for - see below).
> Its work is funded principally by an annual television licence fee which is charged to all British households, companies, and organisations using any type of equipment to receive or record live television broadcasts or to use the BBC's streaming service, iPlayer. The fee is set by the British Government, agreed by Parliament, and is used to fund the BBC's radio, TV, and online services covering the nations and regions of the UK. Since 1 April 2014, it has also funded the BBC World Service (launched in 1932 as the BBC Empire Service), which broadcasts in 28 languages and provides comprehensive TV, radio, and online services in Arabic and Persian.
Long ago I was responsible for implementing a “rate limiting algorithm”, but not for HTTP requests. It was for an ML pipeline, with human technicians in a lab preparing reports for doctors and in dire cases calling their phone direct. Well my algorithm worked great, it reduced a lot of redundant work while preserving sensitivity to critical events. Except, some of the most common and benign events had a rate limit of 1 per day.
So every midnight UTC, the rate limit quotas for all patients would “reset” as the time stamp rolled over. Suddenly the humans in the lab would be overwhelmed with a large amount of work in a very short time. But by the end of the shift, there would be hardly anything left to do.
Fortunately it was trivial to add a random but deterministic per patient offset (I hashed the patient id into a numeric offset).
That smoothly distributed the work throughout the day, to the relief of quite a few folks.
