🎯 Demo First, or Docs Dive?

What’s your approach to evaluating a new technology?

A new software stack? A new type of sensor?

Do you start with a demo application in mind, and use the new tech to build toward that objective?

Or do you read through the documentation and learn how other people are using it, regardless of their goals?

I took the first approach recently.

I had a concern about the accuracy of a sensor.

I needed to see it compared to a known good (but more expensive) option.

So I built the demo - integrating the two sensors and comparing their output in real time.

It worked. But then I looked at some other ways to use the sensor.

They had a demo application out of the box.

It wasn’t a direct sensor comparison, but it was close enough!

Sometimes it’s worth spending an hour or two trying out options that you don’t think you’ll need, just to see what’s already out there.

It may save you a bunch of time!

-Brian Schoolcraft

🔀 Surprises vs. Solutions

At the beginning of every project, you have a list of expected challenges.

Solving them is in the plan.

The solution may not be obvious yet, but the need to solve it definitely is.

Then there are the surprises. Every project has those too!

Experience helps avoid them, but you can’t be experienced at everything.

If you want to be successful, it’s important to not let the surprises distract you completely from the things you already knew about.

Since you’ve known about them a while, you’ve probably been thinking about them. 

You’ve got a solution or two rolling around in your head.

But it’s not on paper yet (or in CAD, or code, or…).

So it’s not actually solved. It’s still just an idea.

We almost fell in that trap a week or so ago. 

We found a fix for the big surprise.

But then we ran up against a time crunch to get the “known” challenge solved.

And all of a sudden the ideas in our heads didn’t seem so good.

Fortunately, we’ve got a great team, and we got together to brainstorm a real solution.

It ended up being a pretty even mix of each of our individual ideas.

And better than any one of them alone.

Don’t let surprises derail your plans.

But when they do, get all the help you can to get back on track.

-Brian Schoolcraft

Depth or Breadth?

One of the key features of expertise is a deep knowledge of the tools you need to do your job.

Mechanical Design? You’re probably very familiar with the CAD software you used every day.

Data Analysis?

You’ve probably got a data plotting tool that you know inside and out.

No matter the domain, it’s difficult to do work at a high level without understanding how best to use your tools to get your job done.

Often, that becomes one specific tool out of a list of possibilities.

You’re not just good at CAD, you’re good at SolidWorks.

You’re not just good at Data Visualization, you’re good at Plotly.

This is great, and almost essential - It’s pretty much impossible to become deeply familiar with multiple versions of the same tool.

Depth of knowledge is the result.

But sometimes breadth can be useful too.

How often do you take “rival” tools for a spin, just to see what they can do?

I’ve had reason to do just that in a couple different domains over the past week, and I’ve truly benefited from the experience.

What should you try?

-Brian Schoolcraft