Posts Tagged ‘advice’


Throwing Boards Over Walls

August 23, 2015

In response to comments made on episode 114 (Wild While Loops), an electrical engineering listener emailed us:

We all know that ‘throw it over the wall’ sucks as a business pattern. But it’s sometimes really hard not to; I’ve recently been under pressure to order those new boards already. Or I’ve flat-out overlooked something. Or I misunderstood how much testing the last guy had done. Or whatever. It’s hard.

We know we shouldn’t just throw and run, but it’s hard. Do you have any thoughts on how to persuade my boss that stronger reviews, and getting the embedded software people in on them, are a good idea?

I recognize that “throwing over the wall” between hardware and software is somewhat inevitable, especially as HW and SW sometimes have different schedules. The difficulty comes in when there is also animosity: the EE says the problem is software, the SW says it is hardware; no one works on it because it is clearly not their bug (or works on it resentfully). I remember those days and am very glad I grew out of it.

But how to persuade your boss more reviews (and possibly earlier reviews) are worthwhile? If your boss is a promoted engineer, data might help. How many issues were found and by whom? (That person could be part of the reviews.) How many hours do the SW folks say were lost to HW difficulties (that includes schematics they didn’t understand)? How much will a board respin cost if a problem isn’t identified until a quarter of the way through the software schedule? (Even better: how much did the last respin cost in terms of money and time lost?)

You might also pitch better reviews as cross training: should you win the lottery and go on a bender, a cross trained embedded software person might be able to babysit your work for a couple weeks until you sober up or another EE is hired. (We used to say “get hit by a bus” until my EE actually did; now I try for more positive scenarios.)

I am quite thankful that HP believed in cross training. I know the EEs didn’t get a lot from my review of their schematics (“Can you rename this net because I don’t understand your vernacular?”) but I sure did. It made me more effective in my firmware job because I knew what their plan was. It allowed me to debug with an oscilloscope by myself because I understood the schematic before I had to use it (before I was deep into “there is a problem!!!” mindset). Plus, I could ask for the test points I needed instead of cursing the lack of available signals.

And, of course, it is hard. Not only is the work hard, the boards and code are personal expressions of our brains making criticism difficult to accept gracefully. And engineers often neglect to turn on their niceness modules. And schedules are brutal. There is no time for reviews and it is hard to expose ourselves to the angst.

But you do the best you can and try to do work you are proud of, sometimes fighting the right battles, other times tilting at windmills because part of you knows it is important even when others can’t see it.

Hey, look, a rousing speech to close on.


Heaps of public speaking

February 13, 2015

An podcast listener posed a question:

What tips do you have for preparing for an event that you’re speaking/presenting at? Tips for first time presenters (like me)?

Tips for when you’re speaking about something that’s a bit technical, but you don’t want to spend too long explaining everything. ( Do you just assume people are following along, and let them ask questions later?)

Let the pictures in the presentation do the talking?

I wrote Stuart back but I was typing on my phone, delaying getting out of bed, so I did a somewhat terrible job. It is a good question, one I’m pondering since my Intro to Inertial talk was accepted at Solid (June 23-25, SF, CA).  (ESC won’t be returning results until the end of the month though I have it on good authority that I’m in.)

Speaking tips: I can tell you what I do. I can’t tell you if it is the best thing for you. There are different speaking styles and that’s a good thing.

I once suggested a person not read word-for-word off their slides, trying to be, you know, helpful. That person became very argumentative and explained that was the best, perhaps the only good, speaking style as it was how people retained information: visual and audio together. Uhhhh, hmmm, uhhhh. Yeah, sure. Seriously, I thought we might one day be friends, that was the only reason I worked up the courage to gave unsolicited advice. I see that’s not going to be and I will back away slowly. (I hate, hate, hate being read to. Unless it is a bed time story.)

(I had a bad, unrestful night with a sick dog and then a bad morning with the IRS whose operators won’t even let me wait the two hours they did last time to talk to them, this time they just say no one is available and I should call back some other time. I’m not coherent. I’d be working if I was coherent.)

Ok, so first, I can tell you about my style. I can point to other styles I like. TED talk videos are good styles. I saw Simon Wardley speak at OSCON 09 and it changed my speaking style. He does a constant barrage of somewhat-related visuals along with his talk. His slides are relatively word free. The whole thing feels a bit like drinking from a firehose. I dig it. It is a heck of a lot of work to put together so I tend to only go halfway there.

I have my slides and talk from the Embedded Systems Conference 2014 on Element 14. It is about consumers and the internet of things. It isn’t as rapid fire as Wardley but I hope it has the same visuals are another channel of information, supporting the verbal (text) but providing more dimension as well.

I’m slightly addicted to clip art and visual eye candy (stupid but pretty tables! marginally related charts!). I’d prefer they look at the slides than me. You can see this in the (not very technical) talk I gave at Silicon Chef last fall.

Don’t put together a presentation for idiots. For book writing, O’Reilly says to assume your reader is a smart person, just not well versed in your topic. I think that is good advice for all audiences. To consider an audience member, consider yourself before you learned this topic (you minus a year).

Slides should be visible to average vision from 20-60 feet away (depending on size of speaking room). Stick to big fonts and simple diagrams. Colors with some differentiation. If it gets too detailed, break it into multiple slides (and/or take off the words and say them instead of putting them on the slides). So squint at your slide while it is on your screen and take off (or enlarge) the pieces you can’t make out.

Some slide decks are documents unto themselves. Mine are not. If yours are intended to be, you probably will have your visuals and audio match more. (Or you can use the speaker notes section in your slide prep program in case people ask for your slide deck.)

Have cues for yourself on your slide deck for whatever will keep you amused/cogent. For example, consider putting in one or three that tell you (in a non-obvious to the audience way) to take a drink of water. This lets the audience catch up and keeps you hydrated.

My cues are usually small, marginally related icons, reminding me to slow down / breathe / smile. (I once gave a talk at full speed and it was very fun but I gave it to a very small, very smart group.) If you put something that makes you less nervous (a picture of your kid on slide 3; secret, hidden cats on every slide; etc.), do so. It will make you enjoy the presentation more and that will make your audience enjoy it more.

I’d like to say “have fun” but that is so hypocritical I can’t even. And yet, a few jokes to yourself are worth it. I once made bullet points on every slide have haiku form. No one noticed but it made me happy: slightly more relaxed. A happy speaker makes for a happier audience.

I strongly suggest watching this TED talk from Amy Cuddy about posture. It is because of this talk that I can be found doing superman poses before the talk starts. (Ok, usually found in the ladies room.) Whether it is meditating or breathing or putting a pencil in your mouth (forcing you to smile), do something before talking other than thinking yourself into a dither. I do a few voice exercises (most saying “red leather, yellow leather”) to get it so I don’t stutter and so my voice doesn’t crack when I say hello. (If I can just get through slide one, I can settle into the rest.)

Stuart asked about questions. At the start of the talk, I usually request folks ask clarifying questions as we go along. But then when someone asks a discussion or argumentative question, I’ll say “That’s a good point, let’s hold it for the discussion at the end.” Don’t hesitate to push back if a question isn’t at a good time (“If I haven’t answered in 3 slides, please ask again.”). You probably want to think about likely clarifying questions as you do your slides. There is some nice satisfaction when someone asks a question and you flip to the next slide and there is the answer.

If you can get them mentally asking questions and then you, as though reading their minds!!, answer the question, well, all the points to you. They will really remember this stuff and they’ll think you are clairvoyant. Feel free to set them up for this. You have to spend some time thinking about how your audience will think but it is worth it.

One way to get started on a talk/slide deck is to pretend interview yourself about the topic. Then you get a nice rhythm of questions and answers. If you can also build in a beginning, middle, and end, that is better. Jokes are a good way to let your audience mentally breathe.

You will forget an important point during your presentation. Accept that. It is ok. If you have 20 important points, forget to cover one, that’s a 5% loss which is pretty good. (Your audience only got 80% if they were really interested and paying attention, the one your forgot is not worth agonizing over.) It is also ok to have 30 points and give yourself permission to only cover 20, the talk ends up being more fluid and variable (depending on the audience and your mood).

If you have 100 important points, your talk is a Wagnerian opera: consider splitting it into multiple. Your audience will get too tired and tune out. This is why talks are usually under 60 minutes.

I write out my talk. Wait. I write an outline, usually bullet points in Powerpoint. Then I write the talk. Then I redo the powerpoint to not have many words, adding pics and clip art. Then I practice my talk 3-4 times, editing the talk and the slides, not worrying too much about total time. Then I cut the written talk down to an outline and practice 3-4 times, checking to make sure I’m in the right time range. I do the final outline form so I don’t read my talk (which tends to be more monotone and tough to listen to). See notes above about being ok to forget things.

Expect to give the talk aloud 7 times (magic number learned in Mr. De Graf’s public speaking class in high school). This makes 60 minutes talks take at least 10 hours to prepare, usually double that. (Urk! Why do I sign up to speak at conferences? They are such time sucks.) Also, with talks longer than 20 minutes, sometimes in practice I start with the second half (or third third) so I don’t always work on that section when I’m tired.

I said this about pop science books recently: “The key to a good pop science book is > 40% good science, ~30% good explanation & metaphors, ~15% personable-ness, and < 10% politics.” That’s not a bad ratio for prepping a technical talk. Yes, do have a large portion of material but you need to budgt time and space for explanations. And your audience will like it better if you toss in an anecdote or two. Finally, you probably do need some bit about what you want them to do with this information (politics). Brain dumps are great but if you can add some encouragement or next step, even better.

Whelp, that’s all I can think of and my mind is clear enough to go play with some electronics.



In case you hadn’t noticed…

February 3, 2015

An older engineer said to me that she’d recently come out as a woman. She’s avoided all women-in-tech things, all women-only evens, even diversity boards at major companies in an effort to avoid rocking the boat. I get that though I’ve always been pretty upfront with my femininity.

That is why I will not meet you in a hotel bar to discuss your start up. That is always true but even more so if you’ve already been the sort of person who refuses to take hints, who doesn’t seem to notice when I consistently don’t respond to emails and messages. It may not be that I’m busy; it may be that you are creeping me out with too much contact from too many channels.

I understand that you may not get this. It is definitely a girl thing. On the other hand, I do know many guys who get it. There was that business trip where my electrical engineer put a chair in the hotel room door before it could close, even before I could. There was that other business trip when the guy invited me to watch TV with him in his room and then immediately explained three others would be there.

I’m a grown up, even sometimes a professional. I’m happy to meet you at a Starbucks. I’m ok having lunch if I’m not busy (and I want to). I’m a bit leery about meeting you in a hotel lobby but can see the necessities given conferences and business trips. But I won’t meet you in a bar. I won’t have a candlelight dinner with you. And I won’t be alone with you in your hotel room with the door closed.

How would that look to my husband? How would it look to your wife? These sorts of appearances matter. I won’t give my husband reason to doubt me, I wouldn’t hurt my husband for anything, especially to listen to you pitch your start up.

Ok, forget appearances. I won’t meet you in a non-public, not-well-let place because it isn’t safe for me. I won’t get in a he-said/she-said argument because there will always be witnesses. This is for both of our sakes: do you know how much such an argument can hurt your reputation?

And now, I’d like to apologize to the podcast listener that I met for coffee but refused to go back to his car to get the gift he sweetly brought me. I was ok in the busy cafe but I didn’t know him well enough to leave with him. I think he understood but was a little hurt.

So, no, I don’t want to get in your car either. Not until I know you a lot better than this.


Tinkering for dummies

January 24, 2015

I received an email:

I’ve listened to a few podcasts and now am officially a fan. I’m curious about “tinkering” for dummies

I realize that I like to tinker but always run into the reality that my technical skills don’t match up with my creativity.

I am wondering if you would suggest a pathway of least resistance for someone who is interested in tinkering. 

Time is always a constraint but I am serious about learning how to code and also learning about embedded systems but not sure if learning python for example is the best way to start.

This seems like a great question, one I’m sure other people have.

However, I’m a terrible person to answer it because I come at the problem of tinkering from exactly the opposite direction. Since programming is my job, tinkering can be difficult because it feels like work instead of play.

Still, I want to encourage the writer so I’ll try to answer. I invite you to suggest other things in comments.

I think the the very short answer is buy a kit. A kit means you’ll get something that probably works and some instructions. Then you can tweak it to be more along the lines of what you want.

And, in general, I think the path of least resistance is Arduino. Their community and system is set up to teach you things (and to hide the tricky details). It started out as a way for educators and artists to approach technology so they don’t expect you to know a lot of coding. There are many Arduinos (the UNO is my fav) so the next question is what do you want to tinker?

Learning by doing is great but difficult to maintain if you don’t have a direction. Self motivation is much easier if you have a goal, ideally an achievable, amusing, and share-able goal.

Say you want to make a watch or small desk display, start with the MicroView (and programmer). If you want to go all out (or you really have no idea where to start), get the Sparkfun Inventor’s Kit. With the MicroView, you get more tutorials with hardware in the inventor’s kit. Without the MicroView, you still get a wonderful grouping of sensors and lots of tutorials (and an Arduino board).

On the other hand, robots are awesome and seeing something move is deeply satisfying. The Parallax BOEBot (“Board of Education” Bot) is educational (and fun). It was designed for high schoolers so you’ll likely feel brilliant and idiotic in turns (c’mon, you remember being a sophomore, right?). You can get it from Parallax more cheaply but you have to build more of it yourself. (Also, you may need an Arudino UNO for those kits to add smarts to your robot.)

As you start to tinker, decide what you want to do with your limited time. Building from the ground up is an advanced exercise, often leading to frustration. Toddling, baby steps are more fun.

But what if you want light up shoes (or bike helmet)? Lights are an awesome way to get hooked on tinkering,* there are so many beautiful blinking patterns. For that, you probably want to look into the Flora system (oh! they also have a budget pack). It is designed to be wearable which is pretty neat.

Do you have annoyances in your house? Something that would be better if you could assure yourself from work or phone? Maybe knowing that the garage was down, the stove off, or the door locked? For this, I’d suggest Electric Imp (and you’ll need the breakout board as well). It connects to WiFi well and is straightforward to program. It isn’t quite Arduino easy but there are lots of tutorials.**

Finally, do you want to make a big system? Like a balloon that can take pictures and use a GPS and then connect to your home network? While I like BeagleBone Black for engineering use, I’d suggest starting with a Raspberry Pi. These are both little computers, cheap enough that you can blow one up without feeling too guilty. The Pi is designed to be a learning environment and there are many excellent tutorials. The Beagle has an excellent community as well so it may be a toss up between them. And if you’ve already started to learn Python, well, these are the boards for you. They’ll let you use Python, explore Linux, and get some hardware experience without ever worrying you’ll run out of RAM or processing power. If you get a touchscreen (like this one for BBB), these small computer feel like, well, small computers: infinitely flexible.

Which brings me to my next point, once you have a direction, look for  a tutorial for something similar. Even if you aren’t building something exactly the same. For example, if you like the look of MicroView and want to try making a watch, even though Wordy is a ring, my tutorial on building it may give you ideas.  Look at the “Learn” sections on Adafruit and Sparkfun for ideas if you don’t have a project in mind. These companies (as you may have noticed from the above links) sell tinkering hardware. They write tutorials to keep you engaged (so then you buy more hardware). You may also find inspiration from Hackaday and Make. You can document your project on, I’ve been pleased at the niceness of the community there.

Tinkering from scratch without a guide is a like baking cookies without a recipe. If you are experienced, it is completely possible to start with a blank slate. I know from experience and reading cookbooks that cookies should usually have between 1 part butter, 2 parts sugar, and 3 parts flour to 2-3-4 (b-s-f). I can make almost any cookie I can think up. But as you start out, some guidance to success is hugely important. Otherwise you end up with Strawberry-Mint cookies*** and everyone is very disappointed that the lovely promise turned into, um, that.

My final word on getting started tinkering: don’t feel guilty when you stop for a weekend or two. This is for you, it is your hobby. It might be educational but it isn’t required for life. The less guilt you feel, the more likely you are to come back to it when you get interested again.

*  My first tinkering project involved lightup high heels. The second involved halloween pumpkins lights (blue to purple flickering “candles”).

**  Heehee, I wrote that tutorial so total bias there.

*** Yes, that happened, ok? It was an accident with the mint and vanilla bottles looking similar. Quit laughing. Aw, to heck with it.



Blocking Patents with Open Source Prior Art

December 29, 2014

An podcast listener asked a question on Twitter about using open source as prior art to block future patents. So, of course, I’m going to answer on my blog.

I asked podcast guest Judith Szepesi of HIPLegal, LLP for advice. Note that she pointed me in the direction, any wrong turns I take are my own.

As of 2013, the US is a “first to file” country. It used to be a “first to invent” which meant that if you invented something and could prove it (dated, signed notebooks!) then if someone else patented it, you might swoop in and eat their lunch. But now that we are “first to file” it is all about getting to the patent office in time. This also means it is a bit easier to say when prior art is truly prior.

Prior art” is the sum of all public information that lead up to your patent. If your idea is in the prior art, it isn’t novel. For example, if I wanted to patent dilithium crystals used to control an antimatter reaction, there is a lot of Star Trek prior art that would say “no, someone thought of it first.” To get a patent, the idea has to be new (novel). The Star Trek prior art would show that my idea isn’t novel.

(We are not going to discuss how novel, that bar is a moving target. By the way, none of this is legal advice. Get your own intellectual property lawyer. I’m just here to babble.)

So how does this involve open source? With the explosion of open source hardware projects, there is the incredibly legitimate fear that you might build something awesome, share it with the community, and have someone patent it. (The open source 3d printing world turned into a bit of a blood bath. I’d add links but they are all so vitriolic. Ahh, here’s one that gives some back and forth.)

But isn’t open source code enough prior art to block a patent? Maybe. Probably not. You have to publish something in a way that makes it easily available to Examiners. The keyword there, of course, is “easily”: a source code repository on github is not easily findable.

You have two options to make your open source project easily findable prior art.

First, you could patent it yourself. Nothing blocks another patent quite effectively as being the first to file. You can still make it open source and/or freely licensed (we love you, Tesla!). However, patenting is expensive (though it can be cheaper for a small business, get the numbers before you assume a $50k price tag, look through the excellent NOLO Press’ Patent It Yourself: Your Step-by-Step Guide to Filing at the U.S. Patent Office, most of your fees will be lawyers’ so make it really easy for them).

The second way to create prior art (without filing patents) is by publishing. Now we are back to easily findable. The USPTO (US Patent and Trademark Office) has a list of publications they look at, called Non Patent Literature (NPL). If you look at the list, IEEE and ACM can’t be a surprise, those are well respected journals. On the other hand, there are a number of journals that make their living charging people for publishing prior art and providing copies to the Patent Office. Judith also mentioned that some examiners are using Wikipedia as well,  but, of course, that is not static, and thus not directly cited in their findings. Make sure your idea’s wikipedia page has good, respectable links.

To be considered prior art, you want your information to be well-indexed and dated. Consider (they make the wonderful wayback machine). That’s indexed and dated. A series of journals from IEEE is indexed and dated. Your latest homepage is not.

I like Hackaday: their site is dated but not indexed. Could that change and it become a source for the patent office to use? Judith seemed hopeful about the idea in general: “I do see a future in which open source communities create a curated prior-art database.  There are a few starting up now, in software, and I do think they will become a significant source of prior art going forward.”

To summarize, the Examiners focus their searched on patents and easily searched publications. They aren’t going to come to you. You have to go to where they are looking if you want to establish prior art.

One final note: if you aren’t familiar with, it is a good place to look and provides some communication between USPTO and engineers with questions, even open source questions. It is also a reasonable place to try to establish prior art that wasn’t in the standard NPL (but by then you are fighting defensively). You can also submit prior art for a given patent directly to the USPTO:  Third Party Inquiries and Correspondence in a Published Application.