There are two kinds of Steves in this world: Blanks and Klabniks. There are the Blanks, who write about not needing permission, and there are the Klabniks, who write about needing a borrow checker.
I've known at least two other kinds of Steves:
• The Steve who told me I would never be able to write a 6502 disassembler because "this is a microcomputer, and it operates on completely different principles than the mainframes you've worked on." (He was neither a programmer nor a hardware engineer.)
• The Steve who threw out several months of my Python work and ordered it rewritten in C++ because "we need precision in our calculations, and C++ has both floats and doubles, where Python only has floats." (He had a Python certification at our company, but he didn't know that a Python float is the same as a C++ double, a 64-bit floating point value.)
Sometimes the rust way of doing things is very detail oriented and breaks the smooth flow of thought to code that python enables.
Probably best to make that zoom call (write python) and then have an evidence based conversation about how you didn't lose precision and performance is as good as rust or c++.
Unfortunately they were both very strong-willed, and I didn't get anywhere with either of them.
I ran into the first Steve at a natural food store in Palo Alto. We got to talking about this little computer company he was starting with a friend and how they needed a 6502 disassembler.
We didn't have a business deal or anything, but I was curious about the 6502 and it sounded like a fun side project, so I got to work on it.
He called me a couple of days later to tell me I wasn't capable of doing it. I tried to explain that I'd written code on a variety of computer architectures and the 6502 was a fairly simple one, but he said "I'm sorry, my mind is made up. You couldn't possibly do this."
I said to myself, "who is this Steve guy telling me I can't program?!" I went ahead and wrote enough of the disassembler to be a good proof of concept.
Our phone call hadn't gone well, so I decided to visit their office with a printout and show him the code. It was listed at 770 Welch Road, near the Stanford Barn.
When I got there, nothing looked like a computer company, there was just a row of telephone switchboards. I told one of the telephone operators I was looking for Apple Computer, and she said "um, this is their answering service." So I walked out and told myself, "These guys are flakes. They're never going to make it."
The second Steve was a little less interesting. I found out about his objection to Python floats near the end of a team meeting, and he had another objection too. Some of our code would need to be written in C++ regardless, and there was no way to call C++ code from Python. I told him about CLIF and SWIG, which were both widely used at our company, and I explained the float vs. double thing. But like the other Steve, he said "my mind is made up, we have to rewrite everything in C++."
This was a set of geographic data importers for some messy data in a variety of formats from multiple countries. The data quality was so bad that north and south were sometimes reversed, or even worse, north and west would be reversed, among many other problems.
This required a lot of ad hoc code to clean up the data. It was originally written in C++, with all the data importers linked into a monolithic binary with an eight-minute build time for a one-line change. (Or a half-hour for a full build.) So if you spotted one data error and wanted to clean it up, it was an eight-minute wait to try your code.
When I changed it to use a Python front end that cleaned up the data and fed it to a simplified C++ back end for the compute intensive part, the C++ code hardly ever had to be rebuilt, and there was no build time at all for the Python part. So you could explore the data interactively and easily figure out how to clean it up.
Technically, this was a huge win.
Socially, not so much.
OTOH, if you ever interview me and ask the "behavioral" questions: "Tell me about a time when a project went really well" and then "Tell me about a time when a project didn't go so well", I can use this episode for both questions!
You'd give up any dynamic features of cpython in the process.
>• The Steve who told me I would never be able to write a 6502 disassembler ... (He was neither a programmer nor a hardware engineer.)
I didn't want to put in the second Steve's last name (hoping not to burn too many bridges), and I liked the parallelism of just mentioning each one by first name.
I do think it was ignorance about programming, combined with Steve's infamous arrogance. I'd programmed in machine language on a few different architectures by that time, and not just assembly but binary machine code too. To me the 6502 just looked like another instruction set.
But as you might guess, I have sometimes wondered "what if" I'd pushed back more.
Would I have ended up a billionaire or at least a multi-millionaire?
Or would Steve have driven me to the brink of despair, as he did with a few other people? (One dear friend of mine once said in an interview, "You may find that some people who worked with Steve won't want to talk about their experience.")
Or perhaps worse for the world in the long run, could my involvement have led to Apple Computer's downfall? The dirty little secret is that I didn't have a 6502 chip to test my code on, but I was working at Tymshare [1] at that time, I had a Teletype [2] machine at home, and Tymshare had a 6502 emulator that I used to test my code. Oops! What if they had gotten wind of this and sued me and/or this little Apple Computer company?