jadero

Going freelance. All the stuff I learned in formal and informal study and from those around me pales in comparison to what I learned from having to craft useful, affordable solutions for a wide variety of customers in several different fields.

It's true that certain aspects of my technical knowledge took a hit, but creating line of business software solutions in direct collaboration with the actual end-users was a transformative experience.

One of the most important things I learned is that approximately nobody actually knows much about how to efficiently and effectively use a computer. About one third of my time was spent teaching people how to use computers.

I'm not sure, but I think they were making a joke. Germany created the Enigma machine. Turing et al did some seminal work as a result of the need to quickly decrypt Enigma messages. Ergo, we wouldn't have computers without the Germans.

Reviews have to be balanced to circumstance. There is a big difference between putting out the sales brochure and the notice on the bulletin board. Likewise in coding a cryptographic framework for general consumption and that little script to create personal slideshows based on how you've tagged your photos.

As a general rule, wider distributions, public distributions, and long-lived distributions need more ambitious reviews. If the distribution is wide, public, and permanent, then everything needs very detailed scrutiny.

I have found some success in starting with and occasionally revisiting review goals. This helps create and maintain some consistency in a process that is scaled to the task at hand.

I'm going to offer something a bit different. I'll start by saying that I've never actually used it beyond a bit of tinkering and watching the presentation at the Strange Loop conference.a

https://www.hedycode.com/

The basic idea is that it's actually pretty hard to do things wrong at the start, mostly because you just can't do much. What you don't get right has very clear descriptions of what you've done wrong, where, and even suggestions for corrections.

As you progress, you can do more and you have a very gradual transition to the more restrictive environment that most programming languages have.

By the time you are done, you are basically programming in Python, so further learning can take place using the myriad of courses, tutorials, and documentation available for that language.

I have no real experience with it beyond some basic tinkering. It is designed for classroom use, or at least on the assumption that there is a teacher or instructor available. That may not translate well to someone learning on their own.

That only makes sense. We are having a conversation, not creating literature.

I would argue that "should of" is just a naive written rendition of the spoken contraction "should've". They are homophones, so it's a completely understandable error among those without the relevant education or background. I know only English and was in Grade 9 at a different school before someone corrected me.

In that spirit, I will call attention to your first sentence, specifically the comma. In my opinion, that can be improved. One of three other constructions would be more appropriate:

• I am really happy when people are quite strict in code reviews. It makes me feel safer and I get to learn more.
• I am really happy when people are quite strict in code reviews, because it makes me feel safer and I get to learn more.
• I am really happy when people are quite strict in code reviews; it makes me feel safer and I get to learn more.

The first of my suggested changes is favoured by those who follow the school of thought that argues that written sentences should be kept short and uncomplicated to make processing easier for those less fluent. To me, it sounds choppy or that you've omitted someone asking "Why?" after the first sentence.

Personally, I prefer the middle one, because it is the full expression of a complete state of mind. You have a feeling and a reason for that feeling. There is a sense in which they are inseparable, so not splitting them up seems like a good idea. The "because" explicitly links the feeling and reason.

The semicolon construction was favoured by my grade school teachers in the 1960s, but, as with the first suggestion, it just feels choppy. I tend to overuse semicolons, so I try to go back and either replace them with periods or restructure the sentences to eliminate them. In this particular case, I think the semicolon is preferable to both comma and period, but still inferior to the "because" construction.

I've clearly spent too much time hashing stuff out in writers' groups. :)

I have read more than is probably healthy about the Chinese room and variants since it was first published. I've gone back and forth on several ideas:

• There is no understanding
• The person in the room doesn't understand, but the system does
• We are all just Chinese rooms without knowing it (where either of the first 2 points might apply)

Since the advent of ChatGPT, or, more properly, my awareness of it, the confusion has only increased. My current thinking, which is by no means robust, is that humans may be little more than "meatGPT" systems. Admittedly, that is probably a cynical reaction to my sense that a lot of people seem to be running on automatic a lot of the time combined with an awareness that nearly everything new is built on top of or a variation on what came before.

I don't use ChatGPT for anything (yet) for the same reasons I don't depend too heavily on advice from others:

• I suspect that most people know a whole lot less than they think they do
• I very likely know little enough myself
• I definitely don't know enough to reliably distinguish between someone truly knowledgeable and a bullshitter.

I've not yet seen anything to suggest that ChatGPT is reliably any better than a bullshitter. Which is not nothing, I guess, but is at least a little dangerous.

This is not a direct answer, but I think you have the beginnings of a useful perspective in that episode of "Family Ties". Namely, it is not a problem arising from the ephemeral nature of software, but the nature of time and change.

Thanks for the tips! Especially the one about "human-scale" files.

But yeah, personally, it does excite me to see that the Unison authors thought differently. Even if it's just sheer curiosity what they do with it and whether that added consistency is nice to work with.

This is what attracted me. Before I sold out to VB and Access in the early 1990s, I was just a labourer and hobby programmer of the "language junkie" type. The same three programs written in every language I could find (Metaphone, Pong, and Rolodex).

Now I'm retired (but 10 years away from programming) and want to try to reboot that hobby. I thought I was just making a tiny little complaint about my aged brain, not opening up a whole thread!

Okay, now I want to write my own editor.

Thanks for the inspiration.