Tesla Bug Reports

Posted on November 19, 2021 by way0utwest

This is part of a series that covers my experience with a Tesla Model Y.

I can’t remember where I learned this, but I saw someone that explained how to report bugs to Tesla in their software, or I guess, the hardware. I didn’t think a lot of it initially, but the last few weeks I’ve been using this every time something weird happens.

The way this works is you activate the voice control by pressing the right steering wheel button. When the software responds, say “Bug report” followed by the issue.

For example, the other day I was returning home and going down the country road that leads to my neighborhood. This road has a lot of hills, some steep, and I use cruise control sometimes to keep a steady rate. Sometimes, not always, as I go up a hill, the car will brake before cresting the hill. At times it’s light braking, going from 45 to 43. At times it’s heavy, and has slowed to 35 or slower.

That’s not fun.

I immediately hit the right hand button on the steering wheel and said, “Bug report phantom braking on hill”. I click the button again and it acknowledges the bug report submitted to Tesla. It also says I can schedule service if something is wrong.

I have started to make this report as often as I get phantom braking. What I’m hoping is that every one of these reports includes the telemetry from the car. Knowing when the model is not appropriately managing car functions should help with better training.

If it gets used.

I’m taking a leap of faith that Tesla is looking at this feedback. Not each report, but in aggregate. Certainly test experiences with Autosteer years ago and now show an improvement. I’m hoping that giving them more data points will continue to improve things.

There’s a quick video of my showing this.

Posted in Blog | Tagged , | Comments Off on Tesla Bug Reports

Where is the Puck Going?

Posted on November 19, 2021 by way0utwest

During the PASS Data Community Summit last week, Brent Ozar delivered the day 3 keynote, and it was great. I really enjoyed the format and topic, and I look forward to how someone else might be creative next year with the time. I’d certainly love to do the keynote, though not sure I’d be eligible. I’m hoping a few others get interested and compete for the slot in 2022.

One of the things Brent mentioned was about looking for skills to focus on, primarily for “builder,” or those that develop new applications. He used a quote from Wayne Gretzky: “I skate to where the puck is going to be, not where it has been.” The reference is to pick things that will be relevant in the future (where the puck will be), not where things are today.

Lots of people ask questions and wonder about this when we look at technology. What should I learn? Where is my best investment for the next ten or twenty years? There also is plenty of fear that you might learn to be an expert in something like Notification Services (dead after 2005) or Database Mirroring (deprecated in 2012). The other day I heard a few people say “graph is dead” in SQL Server, and I might agree. The features exist, but are they really growing and improving enough to compete with a graph platform? I’d argue no.

I don’t have a crystal ball to tell you what will be popular. I have a magic 8 ball, but that’s less helpful. Here are a few things I’d suggest to help you think about this. Please, if you have specific questions, engage in the discussion, and I or someone else can try to help.

First, the ability to work in a team is important. The skills to communicate well, debate a point, and collaborate in how you work are important. Not critical because plenty of people can get by without these skills, but when we look to hire new people, often we want to bond. If I find 10 qualified candidates and get along well with 2 in an interview, I’m likely picking one of the two. Learn to speak in small groups, summarize your thoughts, advocate your position, and appreciate others’ views. Also learn to accept defeat gracefully when things don’t go your way.

Second, learn more about the choices your employer has made. Brent mentioned this a bit, but honestly, if your employer is focused on SQL Server on premises or in a VM, learn to run that well. Learn more about how it works and how to solve problems or tune it. If they want to use AWS RDS or Azure SQL Database, focus on those. Spend spare time, or quiet time at work, becoming more proficient with the platform. Read about it and practice on it. It will help you enjoy your current job, increase promotion and raise chances, and give you some confidence if you do need to change jobs.

Third, learn to learn. Always be learning, and follow the advice above, or even pick the things that pique your interest. The important thing here is that if you need to pick something up, you want to be comfortable with those skills. How do I search out info on the Internet. Can I find videos or articles to consume and can I take sample code and stat using it? Can I set up new environments? Am I comfortable poking around a cloud portal or digging into a programming API? Maybe most importantly, can I sit through and absorb information from a Pluralsight (or other) course? All good skills.

Lastly, part of skating to where you want to go is writing a resume/CV that gets you an interview. I’ve given this advice, and Brent did as well. Include keywords on your resume. If you decided to use Snowflake, I’d find a way to mention Synapse and Redshift on my resume. If you are good at Snowflake, you are likely going to be good at Redshift and Synapse. What you aren’t going to be good at is convincing a non-technical, HR person searching for your resume that these are synonyms if they aren’t included in your resume. Maybe you only want Snowflake jobs. That’s fine, decline the interview. Maybe you need a new job, and in that case, don’t limit yourself. Get past the AI or human filters.

Actively managing your career takes some work and effort, and it takes some knowledge. Improve your skills, but take advice from those of us that have walked the paths. Ensure you represent yourself well, both with your avatar (the resume/CV), and in person for the interview. These won’t ensure you get a job, but they to help increase your chances.

Steve Jones

Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

Posted in Editorial | Tagged | 1 Comment

Daily Coping 19 Nov 2021

Posted on November 19, 2021 by way0utwest

I started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here. All my coping tips are under this tag.

Today’s tip is to choose a different route and see what you notice along the way.

I tend to be a creature of routine. I got from point A to point B often and take the same route. I might vary a bit early on, trying to find an efficient route, but then tend to settle in.

I went down to Colorado Springs a few weeks ago for the user group lunch meeting, and decided to try a different route. I went down 83, but then cut over West at the Palmer Divide and enjoyed going through the rural areas. I’m amazed at how many new neighborhoods are tucked in the wilderness, just East of I-25. On the way home, I cut off from 83 into Russellville Road and saw the same thing.

On one hand, I wish there were less construction and building, but on the other, I’m glad to see properties still above 1 acre and spread out. I suspect the pandemic has made it easier for people to work from the country, and not lose a large portion of their day to a commute.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 19 Nov 2021

SQL Bits is Looking for 20 Minute Sessions

Posted on November 18, 2021 by way0utwest

As Simon Sabin (SQL Bits co-founder) pointed out recently, the 2022 SQL Bits conference is looking to get 40% of their sessions to be 20 minute talks.

He did the math for me, if you look through the thread, but I’ll repeat it here. It’s also in the speaker guidance.

  • 50 minute sessions (174) – 56%
  • 20 minute sessions (108) – 35%
  • 5 minute Lightning Talks (30) – 10%

Those are rough percentages, but a little over a third of the sessions will be short.

Thoughts

I like shorter talks. I find a lot of fluff and wandering around in sessions when speakers aren’t quite sure what to talk about and end up covering lots of material around their central theme. Not all of them, but plenty of sessions could be tightly focused.

I’ve experimented with these, and we ran some shorter events at Redgate Software that were 20 minute talks with 10 minutes of questions. They worked well, and I had hoped we’d do more. It seems marketing really wants 40-45 minutes talks and hour webinars.

In the virtual world, I think we can all use breaks, and even in the physical world, I like having a few minutes to get up and move between sessions. 50 minutes allows this, as do 20. A little break, but not a long one as speakers change or people move from room to room.

While this is a change for speakers, I don’t think it’s too hard to shrink a 60 minute talk to 50. I’ve already had to move 75 minutes to 60, and really it was a question of focusing more on you central idea and less on filling time and space by covering lots of related information.

This also means that audiences will need to read what the talk is about and understand this isn’t teaching you something. This is about getting you to think about a topic and start further exploration.

Building a 20 Minute Talk

What does this mean for me, as someone that is submitting to Bits. First, I need to tightly scope the talk. For me, I want to talk about Git for one of my submissions, and I can’t spend time talking about what a VCS is, the history of Git, centralized v distributed, or a bunch of other stuff I covered in my Data Community Summit talk. Instead, I need to focus on a few things about Git.

Here’s my agenda for an hour:

  • Who am I?
  • Why use Version Control
  • The basics of a versioning software
  • Git introduction
  • Push/Pull
  • Branches
  • Merges
  • Pull Requests

If I want to get this to 20 minutes, then I need to cut some things out. I’d likely start to think more about an agenda like this:

  • Who am I? (cut, check online)
  • Why use Version Control – cut
  • The basics of a versioning software (cut, this is about Git)
  • Git introduction (shorten)
  • Setting up a repo
  • Saving Changes
  • Branching and sharing
  • Pull Requests
  • Merging Code

I haven’t removed a lot, but I would do is remove most of the slides and spend more time showing people how I use the tool to accomplish something rather than an explanation and then showing a demo.

That might be the key. Talk about how I do things in a demo, not describe the process orally and then show a demo.

I also would look to minimize the switching between slides and demo, as each transition eats up time.

Goals

The big way that I focus down my talk is that I set up goals. A few conferences have required 3-5 goals in each submission. I liked this because it forced me to think about the things I specifically want to show. For this talk, I’d likely aim get help someone:

  • set up a repo
  • save changes
  • share changes with others
  • branch, create a pull request and merge code

That’s likely it. I haven’t completely decided, and I’d need to run through demos of these things to see if I could explain them relatively slowly in 20 minutes. I don’t want to go too fast, and I do need to allow for a few questions. What I really want is about 10 minutes of demo, a few minutes to describe what I want to show, and then a summary.

If you tightly scope sessions, I think this isn’t too hard. Twenty minutes is a good amount of time to explain something, but only that thing. Not a lot of background or side stories.

Focus is the key.

Posted in Blog | Tagged , | 4 Comments