@hwayne’s “Crimes with Python’s Pattern Matching” is already trending today, but I thought this was worth a read for Path.read_text alone.
I also agree with the general suggestion, namely that we should do deep-dives into documentation. I did this with Perl’s documentation when I was first learning to program, and it was hugely helpful.
For context, this is my newsletter, so I was letting my newsletter people know about the website piece. And because I try to make every newsletter engaging to read, I bundled it with my standard weekly essay (on browsing).
With the nature of Excel it can be used in different ways to achieve the same goal. Because of this the user should know the indendent way to use software from the developer. This might be possible with a tutorial or a video like You Suck at Excel with Joel Spolsky.
Am I the only one who finds watching that video incredibly painful? There’s so many kludgy approaches to things you could avoid with a program driven more by explicit (typed) commands. The select-copy-paste values pattern to switch from formulas to values is particularly egregious but I think this general approach shows up in a lot of other places. For little 15 entry sheets like this it’s not a big deal, but if I’m dealing with tens or hundreds of thousands of rows the problems start becoming obvious.
I’m aware that its easier to just ingest sheets into Access (or Base or whatever) or to read the values into a program and manipulate them that way (or at a REPL) but Microsoft (quite unintentionally) developed this relatively accessible data manipulation tool full of anti-patterns that rapidly became close to the lowest common denominator in the field.
I do appreciate the caution against vlookup: I once worked in an office with ~200 people where some nitwit had decided to create what was effectively a personnel, training, and travel database run entirely off of vlookup and undocumented macros for ingesting CSV files from the official HR databases. The results were a mess.
I’ve been thinking about Excel being a terrible interface to a great tool that’s just extremely useful in practice (a little bit like git) for quite some time. And I really wanted something more structured.
In case anyone’s in the same boat, I’ve checked out quite a few projects and settled on Grist (https://www.getgrist.com/) - being able to keep the tables and the formulas, but also keep it in a reasonable format and drop down to python as needed is just perfect access/excel combination for me.
There’s lots of other programmable docs options out there like airtable and notion, but they never resonated with me.
I’m reminded of how when I was young I’d spend hours exploring the strange corners of the Microsoft Office menus (and other desktop programs). There was so much to discover there, it was really fun! And yeah people would wonder why I knew so much… it was just a bunch of goofing about.
Eventually I found the embedded Visual Basic IDE and started trying to make games inside word documents using the dialogue box tools. This was probably the first time I did much programming. I had no idea it was a standalone thing at the time!
I wonder if this is how we are in general (how we expect to come to an app with a use case and find it how to complete it) or how the apps present learning these days. Clippy sometimes suggested office help docs, i remember many buttons in office leading to the right sections in there as well. Now I can’t remember the last time I’ve seen the classic windows help app… actually I don’t know if they new version has it at all?
I learn by doing. This means that I take up a project, get blocked and then search for the specific solution to that blockage. I am grateful for any documentation, but what I like most is documentation via example organized around use cases with links to further reading and the underlying API docs.
When picking up a new framework (currently I am teaching myself how to program the Oculus Quest 2. I said Oculus. So there.) I may read the general introductory notes but I definitely do not approach it like a textbook to read from start to finish or even chapter by chapter. I look for examples close to what I want to do and then go from there. I learn what I need and then put it into practice and repeat the cycle.
I kind of get the argument for reading the manual for memorizing the ten different settings on my power drill, but I’d rather spend that time finishing building my shelf.
Couldn’t agree more. I’ve taken to telling people that reading documentation is a super power. So few people actually read documentation to understand how a system (or library, or whatever you’re trying to learn) is designed and is meant to be used.
Searching for answers might get you to a (probably sub-optimal) solution that mostly works. Understanding what you’re working with will allow you to come to a solution yourself, and potentially help others come to solutions of their own.
@hwayne’s “Crimes with Python’s Pattern Matching” is already trending today, but I thought this was worth a read for
Path.read_textalone.I also agree with the general suggestion, namely that we should do deep-dives into documentation. I did this with Perl’s documentation when I was first learning to program, and it was hugely helpful.
For context, this is my newsletter, so I was letting my newsletter people know about the website piece. And because I try to make every newsletter engaging to read, I bundled it with my standard weekly essay (on browsing).
That layout, at least on mobile, confused me. I didn’t realize the article was after the post list until after bouncing around a bit.
With the nature of Excel it can be used in different ways to achieve the same goal. Because of this the user should know the indendent way to use software from the developer. This might be possible with a tutorial or a video like You Suck at Excel with Joel Spolsky.
Am I the only one who finds watching that video incredibly painful? There’s so many kludgy approaches to things you could avoid with a program driven more by explicit (typed) commands. The select-copy-paste values pattern to switch from formulas to values is particularly egregious but I think this general approach shows up in a lot of other places. For little 15 entry sheets like this it’s not a big deal, but if I’m dealing with tens or hundreds of thousands of rows the problems start becoming obvious.
I’m aware that its easier to just ingest sheets into Access (or Base or whatever) or to read the values into a program and manipulate them that way (or at a REPL) but Microsoft (quite unintentionally) developed this relatively accessible data manipulation tool full of anti-patterns that rapidly became close to the lowest common denominator in the field.
I do appreciate the caution against vlookup: I once worked in an office with ~200 people where some nitwit had decided to create what was effectively a personnel, training, and travel database run entirely off of vlookup and undocumented macros for ingesting CSV files from the official HR databases. The results were a mess.
I’ve been thinking about Excel being a terrible interface to a great tool that’s just extremely useful in practice (a little bit like git) for quite some time. And I really wanted something more structured.
In case anyone’s in the same boat, I’ve checked out quite a few projects and settled on Grist (https://www.getgrist.com/) - being able to keep the tables and the formulas, but also keep it in a reasonable format and drop down to python as needed is just perfect access/excel combination for me.
There’s lots of other programmable docs options out there like airtable and notion, but they never resonated with me.
Thanks, that is interesting and incorporates many of the features I find desirable for this. I will have to noodle about with it.
So true, so obvious, and yet still can’t be stressed enough. Bravo.
I’m reminded of how when I was young I’d spend hours exploring the strange corners of the Microsoft Office menus (and other desktop programs). There was so much to discover there, it was really fun! And yeah people would wonder why I knew so much… it was just a bunch of goofing about.
Eventually I found the embedded Visual Basic IDE and started trying to make games inside word documents using the dialogue box tools. This was probably the first time I did much programming. I had no idea it was a standalone thing at the time!
I just wanted to say that
pathlibis one of the best things to happen to modern Python.I wonder if this is how we are in general (how we expect to come to an app with a use case and find it how to complete it) or how the apps present learning these days. Clippy sometimes suggested office help docs, i remember many buttons in office leading to the right sections in there as well. Now I can’t remember the last time I’ve seen the classic windows help app… actually I don’t know if they new version has it at all?
I learn by doing. This means that I take up a project, get blocked and then search for the specific solution to that blockage. I am grateful for any documentation, but what I like most is documentation via example organized around use cases with links to further reading and the underlying API docs.
When picking up a new framework (currently I am teaching myself how to program the Oculus Quest 2. I said Oculus. So there.) I may read the general introductory notes but I definitely do not approach it like a textbook to read from start to finish or even chapter by chapter. I look for examples close to what I want to do and then go from there. I learn what I need and then put it into practice and repeat the cycle.
I kind of get the argument for reading the manual for memorizing the ten different settings on my power drill, but I’d rather spend that time finishing building my shelf.
It has worked for me.
Couldn’t agree more. I’ve taken to telling people that reading documentation is a super power. So few people actually read documentation to understand how a system (or library, or whatever you’re trying to learn) is designed and is meant to be used.
Searching for answers might get you to a (probably sub-optimal) solution that mostly works. Understanding what you’re working with will allow you to come to a solution yourself, and potentially help others come to solutions of their own.