rzimmerman

Yes anything that dynamic is super confusing. I honestly usually don’t bother type checking unit tests. There’s definitely some value but it’s really hard to justify on existing codebases. One thing I love about type hints (rather than compiler checks) is that you can do things like that.

> Mypy catches bugs

100% yes. It’s much better than the examples would lead you to believe. Mypy catches stuff like:

    def f(arg: Optional[Object]):
        arg.method() # type error
        if arg is not None:
            arg.method() # ok

It’s half the goodness of what you’d get from a well-typed language like Haskell or Rust but with the ability to say “trust me on this” and disable type checks for a line or two. Honestly I wish go tooling checked for nil pointer use as well as mypy unwraps optional values. Every time I add type hints and use mypy I find bugs. I would never make the case that type hints are better than a strongly typed language (especially with pattern matching), but it’s a great balance when writing python.

My family has two cars - a 5 year-old Subaru and a relatively new Tesla. The Subaru has great physical controls for pretty much everything. It has a slightly janky touch-screen for changing audio sources (with nice physical buttons on the wheel for pause/skip/change channel). The touch screen is a little frustrating to use, but I rarely need it. I can imagine I'd be pretty annoyed if it was required for car functions or climate control. But the buttons and knobs are great.

The Tesla touchscreen is very good. I would be annoyed if I frequently had to use it while actually driving, but I don't. Everything in the Tesla is pretty much automatic, including climate control, windshield wipers, lights, and door locks. It's easy to use the touchscreen to raise or lower the temperature a degree - that's the main thing I find myself doing while driving that requires the screen. Everything else I do has a physical control on the wheel. The one frustrating exception is defog which the latest update put behind a menu. I have them shortcutted on the home screen but it is obnoxious.

I think having a big screen is nice. It does require thoughtful UX design and a few physical controls. Tesla probably errs a little too much on the side of automation + no buttons but it's generally well done. As driving becomes more automatic I think it really is less important to have tactile controls and more important to have screen real estate.

Definitely - it is a total chore to get a threaded Python program to handle Ctrl-C/SIGINT properly.

Single-threaded Python handles it well - as long as you don't register a custom signal handler, Ctrl-C raises a KeyboardInterrupt exception immediately. KeyboardInterrupt is not a subclass of Exception, (it inherits from SystemExit, which inherits from BaseException directly), so any "except Exception:" clauses don't catch it. Which is the intent. This is also a primary reason to never use bare "except:" clauses (it will prevent Ctrl-C from working!).

For multithreaded Python, the easiest thing to do is just mark all your threads as daemon=True, so they die if the main thread exits. When you can't do that, the best bet is some "threading.Event" and custom SIGINT handler that triggers the event. I kind of wish SIGNINT by default would raise the KeyboardInterrupt in all threads, but I'm sure there are good reasons not to.

Honestly the only reason I was so early in the beta is that I used to do a lot of freeway driving for work. Miles on autopilot counted as a perfect score, so I'd just try to leave autopilot on the whole time.

I've had a great experience with Autopilot. It does what's advertised - maintain speed, follow the car in front of me, stay in the lane and stop if necessary. It can even do more than that, like change lanes and follow exits. It's always healthy to question the safety record and Tesla needs to be more open about incidents with Autopilot enabled. But when operated properly (keep your hands on the wheel and pay attention) it's great and I certainly don't feel deceived.

I understand that many people are confused by the name. I get the argument that aircraft autopilot has a lot of the same constraints, but there are plenty of people who hear "Autopilot" and don't understand the disambiguation between a hands-on assist system, vague rumors that "Teslas drive themselves", and "Full Self Driving". An appropriate remedy is to change the name or put heavy disclaimers on. But it doesn't feel intentionally deceptive like Full Self Driving.

Full Self Driving is a huge mess and there should absolutely be more regulatory action or class action. I paid $10k for the language in the article - get in your car and it drives you where you want to go. Every 8-10 months it's only another year away. I'm not 100% convinced that what Musk claims is even possible with the hardware on my car at this point.

The FSD beta is fun but terrifying and not useful. It drives like a 15 year old and I've never had a single drive where I haven't taken over, either for safety or because the car was holding up traffic. It's also important not to confuse safety (it rarely tries to drive me into a solid object!) with actual usability (it consistently gets confused and blocks other cars in traffic). It's not a few updates away, it's fundamentally not even close to full autonomy. It's not what I bought and it's absolutely false advertising to take $7-12k and just push out the deadline indefinitely.

Carbon Mapper is a really great mission that will help crack down on a lot of accidental and negligent releases of methane and CO2. I used to work on this project and there are some really amazing people making it happen: https://www.planet.com/pulse/carbon-mapper-launches-satellit...

“Unpacking” (on Switch - not sure where else) is a really beautiful game where you unpack a young woman’s things into her new living space at different points in her life (moving in to college, with roommates, a boyfriend, etc) and learn her life story. It’s quick but we’ll worth it.

“How did you say YOLO in the 90s?”

There are two forms of "summon". There's regular summon, where you have to hold down a button to make the car go forward or back. It does turn to avoid obstacles, but with a very nervous energy. Regular summon is super slow, 1-2 miles per hour. If you let go of the button the car stops, but not as quickly as you'd think. It takes about a full second.

Smart summon does have wild raccoon energy. In this case, you need to be within ~200 feet and the car uses its GPS location to plot a path to you. It will back out and turn around obstacles. But it goes kind of fast. Uncomfortably fast. I had my car whip around a turn and nearly hit a parked car. I don't think I've ever seen it work well. Or at least it has always ended with me letting go of the phone kill switch. Which again, takes around a full second to stop the car.

Like someone else commented, this is a very different system than "full self driving" (16 year-old that just got their license energy), which is also a different thing than "Autopilot" (works great on highways).

I have found a lot of value from putting up real code from our code base (maybe simplified with some parts removed) and asking the candidate to explain what a function does. It’s very fair, low stress, and you can ask open-ended questions about “why this way?” or “what are some other ways to do this?”

I’d go with an always lit “HAM BISCUITS” and two signs below that say “AVAILABLE” and “SOLD OUT”, one lit and one dark, to be super explicit.

The problem with a green sign is that it might not stand out against a properly painted bike shed…

When I put together Kal (a compile to JavaScript language, now defunct), I was particular about this and used the sleep syntax:

    pause for 3 seconds

With some other options for units. https://github.com/rzimmerman/kal#asynchronous-pause

Or like a VC I once spoke with listening to a rideshare pitch: “I’m not your target market. I drive alone in my Bentley in the carpool lane. I don’t care if I get a $400 ticket.”

I’m in California where toll roads are more rare. I also dislike tolls on roads, though I understand the pragmatism.

I guess I just like the idea that whether or not you have a nice car/experience, it still takes just as long to get there. Not advocating anything - I just appreciate the abstract equalizer of the road.

Sorry - just speaking about my own experience and implying that an important “American value” to me is classlessness, which seems to erode over time. Thanks for calling me out on that. I don’t think this is different anywhere in the world.

One thing I love about driving in America is that (in a sense) everyone is equal. Whether you drive a brand new Ferrari or a 1990 Toyota, you still wait in the same traffic. HOV/carpool lanes are an understandable conceit to incentivize good behaviors, but the idea that you can pay money to skip traffic just feels awful to me.

Those transponders are cool though. I have a different one for my electric car with a CAV sticker which lets me use some of the SoCal lanes alone.

I also think it will be important for any future teenager of mine to learn to drive without the regenerative braking that Teslas default to. It’s a much better driving experience IMO, but I worry a new driver won’t learn the “oh no hit the brakes!” reflex if they rarely use the brake pedal. I’d probably force them to learn with the car set to “normal” ICE/idle—style for the first few months.

I don't think the answer is simple. I can give you a couple of observations, having worked at tech startups and adjacent industries that are MS heavy. Mostly anecdotal and opinions/personal taste:

When companies are small and the engineers choose the tech stack and tools, they choose the ones that they like best: Slack vs Teams, G Suite vs Office, AWS or GCP vs Azure. At least in the circles I work in.

When companies are larger and/or the management and IT teams choose the tech stack, it's Microsoft's game. They are experts at selling to the business world. If you're in charge of purchasing you see that Office + Teams + Windows is much cheaper than Macbooks + Slack + GSuite. Microsoft is very good at meeting all the same requirements at a lower price, even if the experience is worse for the user.

I strongly prefer to work at a non-MS shop because the tools are better for me. But the dev stack is by no means a dead-end - there are tons of jobs and work to do in C#, .NET. Also Azure is fine, VSCode is actually very good. But you won't be an obvious fit at a small tech startup. When I see a bunch of MS stack on a resume I'm honestly skeptical of fit.

Quitting caffeine cold-turkey is very unpleasant. It can take a full two weeks of withdrawal (bad headaches, general tiredness). I’ve had more success reducing the amount (3/4 caf -> 1/2 caf) over time.

Anything more that 4 cups a day is probably unhealthy. Remember that 1 “cup” of coffee is actually 6 oz, so a normal coffee mug or latte is twice that. One coffee (2 “cups” or a latte) in the morning and one around 2pm works fine for me, but everyone’s body is different.

Also hiring SREs:

Rocket Lab | Site Reliability Engineer (SRE) | Full-time | Long Beach, CA | ONSITE/FLEX

Rocket Lab is seeking Site Reliability Engineers to support development of infrastructure systems and services that enable on-orbit operations of Rocket Lab’s Photon satellites, including the lunar CAPSTONE mission in 2021. The Spacecraft Operations team is responsible for maintaining the health and safety of Rocket Lab’s growing fleet of spacecraft and ensuring that mission objectives and SLAs are met The team’s goal is to maximize the value Rocket Lab can create from a constantly changing fleet of diverse spacecraft. This unique challenge requires a set of backend services to support 24/7 automated operations.

https://www.rocketlabusa.com/careers/positions/site-reliabil...

Rocket Lab | Satellite Operations Software Developer (Full Stack) | Full-time | Long Beach, CA | ONSITE/FLEX

Rocket Lab is seeking a full stack Software Developer to support the development of Photon spacecraft operations software. In this role, you will be working to develop our Space Operations Software that is responsible for commanding and data handling for all of Photon’s operations in space. This role will involve developing software to work with cloud technologies, mission & ground software, customer APIs, and large databases. The ideal candidate will have both frontend and back end full stack development experience.

https://www.rocketlabusa.com/careers/positions/satellite-ope...

I don’t know - yeah technically correlation doesn’t imply causation. But they are correlated…

Prohibition has clearly been worse in the case of alcohol and marijuana. You might be right, but I’m not convinced a prohibition on production and sale would produce the same black market for tobacco. Maybe it’s my own bias, but I like to think that most people that smoke don’t really want to. It’s driven by addiction and ease of access. Cravings are ephemeral and it’s not like buying a 6 pack or some pot to have a good time later. There’s a spectrum where prohibition works. The best example I can think of (at the extreme) is plastic bags at supermarkets in California - no black market for that, vs marijuana where it clearly a failure.

It would be interesting to set up a server/PC that throttled The CPUs/GPUs by power use rather than thermal readings. It’s analogous to the burst credit system used on some EC2 instances, but it would be a cool kernel or hardware feature for devices that are completely solar powered.

Also hiring SREs:

Rocket Lab | Satellite Operations Software Developer (Full Stack) | Full-time | Long Beach, CA | ONSITE/FLEX

Rocket Lab is seeking Site Reliability Engineers to support development of infrastructure systems and services that enable on-orbit operations of Rocket Lab’s Photon satellites, including the lunar CAPSTONE mission in 2021.

The Spacecraft Operations team is responsible for maintaining the health and safety of Rocket Lab’s growing fleet of spacecraft and ensuring that mission objectives and SLAs are met The team’s goal is to maximize the value Rocket Lab can create from a constantly changing fleet of diverse spacecraft. This unique challenge requires a set of backend services to support 24/7 automated operations.

https://www.rocketlabusa.com/careers/positions/site-reliabil...

Rocket Lab | Satellite Operations Software Developer (Full Stack) | Full-time | Long Beach, CA | ONSITE/FLEX

Rocket Lab is seeking a full stack Software Developer to support the development of Photon spacecraft operations software. In this role, you will be working to develop our Space Operations Software that is responsible for commanding and data handling for all of Photon’s operations in space. This role will involve developing software to work with cloud technologies, mission & ground software, customer APIs, and large databases. The ideal candidate will have both frontend and back end full stack development experience.

https://www.rocketlabusa.com/careers/positions/satellite-ope...

I’d add that for most people, you should go higher than 1080p regardless of screen size. UHD/4k/Retina are all a huge improvement just when looking at text and it’s hard to go back.

Objective C does (explicit) reference counting, though I suppose that's a pretty limited use case these days.