But I think the action regulating CFCs is kinda what I'm talking about. As a consumer in the US, I don't ever remember having to sacrifice on my refrigerator or A/C - heck, I generally remember those appliances going down a lot in price from the 80s to the early 00s.
So my argument is not that we can't regulate technologies, but that we only do so when it becomes "technologically convenient". I think the comparison of CFCs to fossil fuels also highlights this point. CFCs were used in a relatively small area of the economy, and replacing them was pretty easy, so not a lot of regulatory will was required. Contrarily, the entire world economy runs on fossil fuels, so replacing them is an enormous task, and as one example you get tons of powerful invested interests pushing back. I honestly don't remember any crazy people shouting "the ozone hole is just an elite conspiracy", but you hear that all the time with respect to global warming.
My fear with AI is that it is such a powerful tech (or is at least viewed as such) that the powers that be are scared of being surpassed by another country/company if they slow down.
The question isn't what what you're experience of the 1980's, but what would have an alternate 1980's with flagrant use of freon been like? Freon was used everywhere, it's how air-conditioning worked back then. That technology was held back because of the hole in the ozone layer above Antarctica. With a lot of money poured into researching alternatives, alternatives were found, but humanity deliberately held back use of freon for the greater good of humanity.
Commit messages are immutable. Linking them to a bug ticket gives you a mutable place to record any new information about the bug that you discover in the future. (For example, that it affected more cases than you originally thought, or that the fix caused another bug.) This new information will be discoverable when starting from the original commit (found e.g. by doing a blame on a particular line of source).
To fail to do so is a gigantic missed opportunity in my opinion. You never know when you will need it.
Another way to look at it is that you’re getting to do all of the fulfilling parts of management roles (helping your team(s) to grow and develop) without the less fulfilling parts (endless meetings, budget spreadsheets, unpleasant conversations, having to give up writing code).
> These are not rookies if they reached Principal IC, but the most experienced team members ever, yet the author still feels the need to say this.
At this level the job is qualitatively different from what went before - you do start as a rookie in this role, and if you only try to keep doing what you’ve done before only better then you’re not setting yourself up for success.
> Do we need to move up or out?
Not to this extent, no. If you are still a Junior after 15 years, that’s a problem and questions will be asked. But if you want to stay in a role where you keep doing what you’ve done before only better, then that’s generally completely fine and the right choice for many people.
> At this level the job is qualitatively different from what went before - you do start as a rookie in this role, and if you only try to keep doing what you’ve done before only better then you’re not setting yourself up for success.
Other people here are arguing that you only get promoted to Principal IC if you have been already acting like one in practice. We cannot have it both ways...
And if not, this seems like the Peters Principle. Why inflict this promotion on someone doing well in the other role?
If you show promise but you haven't proven yourself, that's a risky move. You either succeed or you're out, there's no going back to the previous role. I've seen it happen...
Certainly that would be the case with film ribbons, but I don't see how typed character history could be obtained from a cloth/cotton ribbon, especially since they were as I recall reversible (would spool one dirction, then the other when reaching the end), meaning the previous typing would be overwritten multiple times.
Debuggers allow you inspect stuff forward in time, while print statements allow you to debug backwards. (There was a lot of academic work on reversible debuggers at one point; to be honest I haven’t kept up on how that turned out.)
If you can detect a problematic condition and you want to know what will happen next, a debugger is a great tool.
If you can detect a problematic condition and you need to find out what caused it, it’s printf all the way.
My theory is that different types of programming encounter these two types of problems at different relative rates, and that this explains why many people strongly prefer one over the other but don’t agree on which.
Nearest thing to a name drop is the end, but isnt a name drop (also spoilers):
"And yet, now that I am an old, old man, I must confess that of all the faces that appear to me out of the past, the one I see most clearly is that of the girl of whom I've never ceased to dream these many long years. She was the only earthly love in my life, yet I never knew, nor ever learned, her name."
reply