Embedded - 347: Be Careful About the Bits
Episode Date: October 8, 2020Chris (@stoneymonster) and Elecia (@logicalelegance) discuss API design and team dynamics. Elecia’s book: Making Embedded Systems Embedded Patreon StewMac (Ukulele kits) Transcript: embedded.fm/tra...nscripts/347
Transcript
Discussion (0)
Hello and welcome to Embedded. I am Elysia White here with Christopher White. This week
it's just going to be the two of us chatting with each other.
I'm so sleepy.
Well, I hope you wake up because I can't chat with myself.
I hope that doesn't come across at all.
Let's see, let's do announcements first.
Big thank you to our Patreon supporters, which, of course, you can join if you want to.
We're going to talk about a question from there today that's got a lot of really good advice.
But it's also, we appreciate it, and it is help paying for the transcripts.
And mics.
And mics. If you have any comments on the transcripts. And mics. And mics.
If you have any comments on the transcripts, please let me know.
I'm still pretty new at it,
and I am finding it pretty amusing to read through them as I post them.
A little strange. It's a little strange.
It's weird to be searchable.
Also strange to see when you talk for what you feel like is five minutes and it turns out to be a paragraph.
Yeah.
Okay, so what do you want to talk about today?
I don't want to talk about anything.
I want to go back to bed.
You could have left me on the couch then.
I thought you had an agenda.
I have sort of an agenda.
But first, I wanted to talk about what we've been doing besides
work. I plead the Fifth Amendment. Not true. I mean, you've started a couple of projects. You're
still working on the album. I'm becoming a professional doom scroller.
You can't do that. It's just not good.
I can do it.
I assure you I can do it.
I'm really good at it.
I don't know where the professional part comes in then.
Well, it's just the level of skill involved.
Okay.
Yeah.
No, I've been working on the album.
It's coming.
We have one more song to do, and it's a difficult song,
and I'm having trouble writing a part for it
and getting up the gumption to fight with it.
It's a little tricky,
but I think,
I think I'm close.
And you took over part of the garage,
put away my soldering station in order to do your soldering station.
But I think I use it more than you probably do.
Yeah.
I'm building a ukulele from a kit.
It's a baritone ukulele, which is the largest form factor, I think, of ukulele.
And it still has four strings, but they're tuned like the top four strings,
the highest pitch four strings of a guitar.
So I don't have to learn a new ukulele turning tuning which wouldn't be a
big deal but i'm lazy so i thought it'd be which is why you're building one from scratch because
you're lazy well it's not not from scratch exactly the kit's pretty pretty nice it's actually it's
harder than i expected given when you look at the pictures on the website and they show you what
parts they send you and what's like pre-assembled it's like oh this won't be that big a deal but uh it's gonna take me a few weeks um but it's from a
company called stewart mcdonald uh their website is stewmac i think dot com and they have all sorts
of guitar building lutherie um tools and parts and kits and blank wood, you know, if you're building totally from scratch,
you can spend $5,000 on very expensive wood if you're insane.
But this kit was like $120 or something like that.
Yeah, and you've already talked someone into sending it to their parent for a gift.
So I thought that was pretty funny.
But it's a nice kit.
The hardest parts are already done.
So like the neck is finished.
It's already shaped.
That's a super hard part of building a guitar or any sort of stringed instrument.
They've slotted the frets.
That's also a hard part because those are precisely measured in distance.
The body sides are already shaped, so they're curvy bodies, so you don't have to shape them yourself. But you have to glue everything up and put in the bracing
and install the frets, which I'm not quite looking forward to,
even though I've already done it on a guitar at one point.
I remember that being sort of fun,
but getting them filed to shape and stuff is kind of tricky.
But yeah, a lot of glue.
Clamps.
Clamps and glue.
Yeah, the hard part is having enough uh woodworking tools that you need
that you can get by with most things and the thing that's most frustrating now is like when
i need something i can't just pop down to the hardware store wander around and you know find
a part i need so i have to look like on amazon for l brackets or plywood or something. So, but anyway, yeah, that's sort of fun.
Very low tech.
Yeah.
I've been trying to find things that keep me away from the internet and computers in
general, but even origami, I've now got a Python script to help me design seashells.
It's not going the direction it was supposed to go.
The highest tech part of this project is the YouTube video I'm using as the instruction manual.
Okay.
Let's see.
What else have I been doing?
Reading.
I've been doing a lot of reading.
Science fiction, fantasy, mystery.
What are you reading?
Romance.
What do you recommend? Well, fantasy, mystery. What are you reading? Romance. What do you recommend?
Well, let's see.
I guess the most interesting book I've been reading that I'm willing to admit
is one by, I think his name is Vermeer.
And it's a natural history of seashells.
And it is really, really interesting, but it is a textbook.
Oh.
And, I mean, I'm doing okay,
but I had to get it in paper because it didn't come electronic,
and so I keep pushing the words to figure out what apical means.
And it means towards the apex.
I forgot that from context clues, but it was just, yeah, I missed the definitions.
Was that the book you said was authored by a blind person? Yeah, he's a professor at Davis who was
I believe blind
as a child and still blind
and he
is the foremost expert
on shells
all by touch.
That's cool. It's really cool.
And the book
a book of seashells like this
would normally be 90% pictures but this one actually talks about it and gets a little bit into the math and evolutionary biology in terms of economics.
Okay. Why shells end up this way instead of that way because of cost and how different formations of the shell are more expensive in terms of energy or upkeep.
It's weird.
It's cool.
It's one of those things that when you tell people you're reading it, they're like, why?
I don't.
No, you just make me show you the pictures.
So we do have a couple of emails.
I have one from James.
This one was hard.
James is an electrical engineer and part of the job involves writing firmware in C.
James wants to know if we have advice for writing bare metal code, in particular to MCU-specific registers.
And he does say that it's possible that after we read the following, the advice will be stay away from firmware.
But I doubt it.
Where is the best place
to put MCU-specific code for
configuring IOPins, clocks, peripherals,
and interrupts?
James' usual method is to have one or more
board-specific hardware.c files.
That sounds really familiar, like
something that would happen.
C files?
Or.h and.c.
But he says for configuring, so I assume that's the actual action of configuring.
Okay.
And those files map the pins to the functions and hardware.h to have macros to map PIM controls without exposing the MCU's internal registers.
Peripherals are more different to place.
UARTs end up with a UART driver, an init function, send-receive.
I mean, basically, James, you're doing the same thing we're all doing.
Yeah, I mean, the idea is to layer things
and have abstraction layers where they're appropriate.
It's called a hardware abstraction layer for a reason.
But let's get to the actual questions.
Is it okay to define the MCU-specific registers,
or is it better to use an inline function in case you want to port your code
to a controller without, say, a UART peripheral
and you need to write a bit-banging-style routine?
I'm going to parse that.
I think, is it, do you, do you do pound Fs or do you write a proper abstraction layer that makes it so you can do it on a different processor?
It depends on if you anticipate having to port your code to a different processor.
That's actually a really good point.
I mean, there's a lot of,
there's this Yagi principle, like the dry principle. And where dry is don't repeat yourself,
Yagi is you aren't going to need it. Apparently I didn't have the acronym right. Yagni?
There you go.
Yagni.
Okay.
But you, you aren't going to need it. A lot of times we try to design for portability when the truth is it's not likely to be portable.
And if it is portable, and if it is need to be portable, we can make all the modifications then.
Sometimes.
I mean, I do agree that portability is sometimes it's one of those premature optimizations that people get excited about.
And I do think it's overvalued sometimes.
But again, it depends on what you're doing.
It totally depends on what you're doing.
I'd say if you're building a platform of products, like your company wants to make, you know, a new product every year and
reuse the code and upgrade the hardware with new features, but you want kind of a fixed code base
that you build on over many years, then yeah, thinking about this very carefully is warranted.
Because you are going to find new chips, cheaper chips, more capable chips that you want to port to over time.
And so, yeah, portability is important. But if not, and if it seems like the next time you're
making a product, you're going to start over from scratch, which happens a lot more than people, I
think, want to believe, then optimizing this upfront may not be worth the time and complexity.
I don't know. Let me go on with James' email a little further.
Where do you put peripheral interrupts
that have MCU-specific labels?
Do you put them in the driver
or the callback to a higher-level function
or put them in the application code
and accept that if you compile for a different processor,
you need to remember to change that?
Putting interrupts in application code makes me nervous.
And with the UART driver, there might be a command handler, which he would put in a different
file, but are there any rules of thumbs for the maximum number of functions or lines of
code in a particular file?
I mean, we've all seen the EE who puts all of their code in a single file. And I think we've
all agreed that that may not be the optimal solution. But is it possible to have too many
files? I've seen that. My gut feeling is that if you've designed your code well, this sort of falls out. If you have
areas of functionality that are modules
that are common, that
fit in a file,
it'll be kept to an appropriate size.
And if that starts to grow too big,
then that's probably not one module or one
area of functionality. And you actually
have two that have snuck in there,
and you should split it.
Having too many files i mean there's
big projects but the only way you get too many files is if you're artificially limiting what
you're putting in them and then you have the other problem where you have a module that spans too
many you know you've divided up something that should be common into a bunch of stuff that
isn't common but should be common into a bunch of stuff that isn't common but should be.
Exactly.
What do you think? Yes.
The problem with software engineering as a whole is that there are no hard and fast rules.
No.
Yeah, the compiler has some.
But this architecture part, it's blurry.
And with hardware, it's kind of easy to say, okay, so if it touches the hardware, it needs to go over here.
And if it doesn't, then I'm going to put a layer in between hardware abstraction layer and keep them separate. But that doesn't really work when you start thinking about command parsers.
Because that depends on a UART.
You can't pretend that it doesn't.
I mean, you can.
It depends on input from a stream.
Yeah.
And so you could draw the line there,
and then you could just as easily hook your command parser up to an internet socket or...
Which has a different speed, and so therefore it has to be checked at a different speed.
I mean, it's software, nothing's impossible.
It's just, how do you design it in a way that makes it easy and streamlined and you don't write the code you don't need and you write the code you need in a way that when you have to look at it in a year, it still makes sense.
I mean, James, yeah, okay, we all have this problem.
You're definitely not alone in that one.
You did mention in the email, which I didn't say, was that you have my book.
And so I'm actually going to go back to my book on this one.
I don't know if that, what the word for that is, self-aggrandizing?
Don't think so.
Anyway, in the book, there's this section about creating system diagrams.
And while I am not really a visual learner, I do tend to think more if my hands are involved.
And so in the book, I suggest that you write a block diagram.
Simple, okay, so here's how the hardware looks, here's what's connected, this is over in SPI, this is over in UART. And you end up with this picture of the system. And maybe you also add a few more things, like your UART handler is going to go near your command handler is going
to go near your uart this sort of thing makes sense and if you have a display you have a
rendering engine and that means you have fonts and text and images and you know you start to
to collect all of the pieces of the system if you aren't responsible for all of the architecture, you can just put up your piece.
And in James's case, that would be, there's a hardware piece that talks to the hardware, and that would be kind of on the outside of everything.
And then there's the, maybe the interface layer that makes it into a sort of generic-ish UART.
And then there's the circular buffer,
and then there's the command handler.
Okay, so you write all this together,
and you have this block diagram of how the hardware works
and a little bit of how the software works.
Now you're going to put that block diagram to the side.
You're not going to worry about it anymore,
other than now you have sort of a list of parts. Do an entirely different organizational diagram that looks over what the shared resources
is. This is more of a tree thing where you have main on top and main calls like a display or
calls sensors or calls logging. These are separated out like a family tree, although, of course, they may end up talking to each other.
And then you end up with this idea of where the organization goes, where the control flows
through, and how it flows, and who ends up talking to each other. Okay, so you finish that drawing,
you put that to the side, And now you do one more drawing.
This is a layered view where you are trying to figure out what touches.
And the other two drawings will inform this.
But the idea is that if you have the UART commands, then it's going to touch the UART interface.
And the UART interface is going to touch the hardware.
And these are going to be lined up together.
And the boxes now are about the same size, proportional to their effort.
And if you think about the UART interface layer,
that's going to be pretty small probably,
especially if you pull out
the circular buffer. If you think about drawing on a screen, rendering is going to be a big thing,
but it's going to touch how it gets images, how it talks to the LCD, and then how the images are
going to talk to maybe a spy flash. I mean, there's a lot of layers here.
And the idea is you end up with this diagram that shows where the connections are and what pieces are big and what pieces are small.
Okay, so you have these three drawings.
Now you go back and you answer this question.
The drawings are not that important.
You're not going to keep them forever. You don't need them to be question. The drawings are not that important. You're not going to keep them forever.
You don't need them to be beautiful. It's a way of thinking about the system that starts out with
how is the hardware organized? How does my information flow? How is control flow? And then
what needs to talk to each other? And it's that what needs to talk to each other that starts
informing what your modules are and how big they are. Because you can think about, you know,
if my rendering engine gets so big, then I can break it into text and images. And as long as
they don't share too much, that's fine. You start seeing the natural breakpoints and that's what you're looking for. It's really bad
when you try to break along edges that you shouldn't have.
Then you end up with spaghetti code and globals all over the place.
The goal is to find a nice crystalline structure
and crack it that way. Have I gone too far into metaphor there?
No, no, that's all really good.
I have opinions, and they relate, specifically I have opinions related to this, which is
good, because I don't want to hear me just rant about it.
I mean, I've heard some of your opinions.
So, this,
how do I start this?
Firmware and electrical engineers,
we tend to get excited and focused on
peripherals, hardware, MCUs,
registers, very
low-level things.
And we tend to worry about
them because they're difficult.
And it is difficult to organize all this stuff and get it to play nicely together. And so I think there's a bias
towards designing from the bottom up. Yeah. And that's okay, because most of these systems end
up looking very similar. And so from the bottom up, the layering, you're always going to end up with something that's pretty much
what 90% of the other engineers in the world are coming up with.
Sensor, display, interface to the world.
There are only a few things.
I think these four diagrams you had?
Three or four?
Three diagrams.
I think these three diagrams are great and should absolutely do that.
I think you should draw a fourth diagram that's from the top down.
If this is part of your mandate at your company is to do the whole application, the whole MCU thing,
is to start from the application requirements and the top, the user interface,
and do a diagram that's driven from the top down.
The second two are driven from the top down because second two are driven from the
top down they sort of but you were still talking about interconnections and flow rather than
features ah yes yes and the trouble that i've gotten into with the bottom up stuff
uh and and just looking at the inner relationships between modules, is if you ignore the top-level features,
what the thing is supposed to do,
how it's supposed to interface with the user,
sometimes you can get into trouble
with your interface diagram,
your APIs and other things,
to where you design yourself into a corner.
And that's all I'll say about that.
It's just make sure you think about your application
either alongside or as a separate exercise
while you're doing those.
Yeah.
To your point about how we tend to focus on the hard parts
or the parts we find fun,
for those of us who really like the hardware.
It's the parts we interact with the most.
So that's where the bias comes from, right?
It's the parts we worry about the most too, because you have to read the data sheet or the
manual and you have to be careful about the bits and it's hard to maintain. And so you worry about
that. But the truth is every time you go in there, you're going to have to read the manual and figure
out the bits again. I mean, I try to make nice comments and I don't always have to,
but it's better to just assume that.
And so if that piece of code is always going to be hard,
then maybe you should spend your attention on the pieces that you can make easier.
And so back to James's question, you have it right. You need to build the layers. And how many modules you have a spy flash, you should have a file that is called spy and you should have a file called flash.
And then if you have a storage system, you should have a file called storage system.
Don't put them all in one file.
Because as you talk about them, they're different things. And as you talk about a command
handler, you can talk about a UART and a command handler. Now, because I kind of agree with you
that if you're thinking about someday you may have to port it, then you need a UART, a little
hardware abstraction layer, and then the command handler.
And that makes a lot of sense.
You don't have to do that.
But if you're going to do that,
you should think about making drivers similar to the POSIX model,
which is open, close, init, read, write, and ioctl, which is kind of the catch-all for IO control, I don't know what I'm doing, please don't look over here, sort of function.
The setup function.
But if you think about the, okay, I'm going to have an init function, I'm going to have a read and a write.
If I have more than one thing using this, I need an open and close.
That works for ADCs, it works for Uarts. Works for everything and close that works for adcs it works for uarts works for everything
it really works for everything um sometimes you need to keep pipes open you know a connection
to the internet that you're waiting for something to respond to but it's a it's a good model to
start with i mean dma sometimes gets in the way way of that, but you can hide that under read-write too, if you
want. Because
you're either blocking or you're
checking to see if it's there
and yeah. Yeah,
and that's what I've done in the past. We've even gone as
far as to do like the virtual
function table for drivers.
We didn't have an OS at
ThreadX, but
for drivers, they all had to have those functions,
and you just filled in the structure, and it did its thing.
And, yeah, I mean, that alone is 95% of an abstraction layer
that's going to solve a huge number of problems.
And if you're doing it in C++, you can do this with objects,
and you can replace you know, replace
the IO thing with the virtual functions that you're talking to. Where am I headed with
that? Oh, the great thing about that, the virtual function, either in C or in C++ is
it's really easy to make mocks.
For doing unit testing.
For testing. You can just rip that out and have read and write go to a file or CLI or something like that.
So, yeah, that's a huge, huge thing to think about is just to have a common interface.
Yeah.
And James did follow up with, what about naming?
Do you worry about prefixing?
What?
Like, when you have UART read,
is it in UART.c?
Or do you do something else?
And if you have a command handler,
does it have to be,
if it's called command handler.c,
is it command handler underscore check?
Yeah, yeah, yeah.
Because you want to be able to search for these functions.
I tend to agree.
And if they're all called read, you're going to have a really fun time.
Really fun time.
So I do prefix, if not with the file name, then at least with an ID.
So command handler dot C might be CMD.
Yeah, you can shorten it.
The only other thing I would suggest is
there's a lot of open source stuff out there to crib from.
So if you want to see an example of how this is done...
Oh my God, there's so much Arduino code.
You can look at Arduino code,
you can look at some of the RTOSs that are out there.
They have to do this,
and they have to be fairly general because they work with any application and any processor.
So they've got all this kind of problem to solve as well
in a much more general way than somebody writing a purpose-built application does.
But we go back to, if you aren't going to need it, don't make it too general.
You know, make it a little general, but don't...
I mean, I've been coming across...
I have two things I'm working on.
One with the GPIOs are basically I give it my sensor spy select, and then I give it on.
And then I have a different one, a different project that is port C, comma, pin 3, comma, active high. i would argue that's never appropriate
you should at least abstract that away i actually have yeah of course um but that whole three
having to have three variables instead of two causes a lot of problems so yeah there's there's
a time to abstract those away. But when you think about
some of these abstractions, they take like 15 minutes to write once you've thought about what
you need them to do. And they save you days. And they save you days later. Yeah. So as much as I
say, don't write things you don't need. All right. Maybe it is time to have a function that just is GPIO sensor a spy on instead of trying to do it all.
All right. Well, James, I don't know if we answered your question, but that's this month's effort for it.
APIs are really, really hard to design. And the thing is, you won't know until long after
you've left the company. Yeah, the thing is, you know, you're going to get it wrong. It'll work.
It'll be fine. You get it wrong. And then you'll realize the next time what you got wrong. So when
you do it the second time, you'll do it a little better. And you get that one a little bit wrong.
You know, I think we're all on our eighth tries on some of these things.
Yeah.
And I think most of us end up with the POSIX model because it makes sense.
And if you...
There's problems with the POSIX model.
There's totally problems.
There's problems with everything.
No, no, no.
So go with what is fairly easy to understand.
And the truth is this applies to everything this is not you know this is not a c specific problem no uh this this happens in
every language and it's just a general software development problem of how do you organize code code and do meaningful modules without doing too many.
Yeah.
I suspect just about every profession has something similar, that it's a balance of too much and too little.
Yeah, surgery.
Not surgery.
Okay, so that was James's question.
This other question I have has actually been answered. And I'm going to change the name and hopefully Chris will change it in all the places I forget to change it. But it happened on the Patreon Slack group. And Emmett had a career question. I said, so I have a career question. Okay,
we got that part. Sorry, I shouldn't have started ahead. I joined a startup where I was the only
hardware engineer. We were acquired by Big Tech. Last week, the product I worked on launched,
and it was a Herculean effort.
I used to report to the CTO.
I loved my job and had a lot of fun.
Now my boss hired a gray beard with 30-plus years of experience and wants me to report to him.
Not those guys.
Fair enough, I suppose.
But he's been an individual contributor, and my boss wants him to work on a clean board design,
a design I had proposed and was to work on last year. I have so many concerns that I thought I should ask you. A, how to deal with the disappointment in what feels like a demotion.
The reporting chain is one step removed from decision-making.
Two, how to advocate for myself and keep learning. I told my
current boss that the gray beard has to share the work and I won't settle for the scraps off the
table, but I don't know if that was too confrontational. Yes, yes it was. And three, how do you share your
baby? It was supposed to be my design. I had evaluated the parts, lined up suppliers, got the dev kits.
I feel guilty about asking for more because the startup has been so good to me and my boss has gone above and beyond. The gray beard is also much better than me, has been working for longer than
I've been alive, and the imposter syndrome is so real right now. Oh, and we're also remote,
so not like we have eyes on the other person is doing.
Do you have any advice?
Okay, before we start with the advice, the thing with the Patreon Slack that I am so
pleased by was that he got advice from many people.
He got advice from the graybeards.
He got advice from people who had been in similar situations.
And it was pretty much all good advice.
I mean, I didn't see anything that was like,
I wanted to say, no, no, don't do that.
But it was all very, yeah, we understand.
Of course, this has happened to just about everybody,
and, you know, it's normal.
And the feelings are normal,
and you don't want to be a cog,
but to some extent you are.
I had completely forgotten.
I didn't really jump into this when it happened on Slack.
And I was trying to think of a situation, a parallel situation in my career when this had happened.
And I wasn't coming up with anything.
And I realized just now there was a huge thing that happened to me like this.
I think I wasn't mapping it because of the gray beard part,
but when I was at, and stop me if this is not helpful,
but when I was at Procket,
my first big job there was to do OS,
kind of architect how the OS was going to,
parts of the OS were going to work,
some of the memory management, inter-process communication stuff. But my real job, once that was kind of architect how the OS was going to, parts of the OS were going to work, some of the memory management,
inter-process communication stuff.
But my real job, once that was kind of done,
was to work with the routing team to implement a routing protocol,
and I was doing OSPF.
And after about 18 months,
I had implemented most of it,
and it was working fairly well.
But they hired a new guy.
And the new guy came in and they gave ospf to him
he was originally supposed to help me i think but he basically took over took it over and spent a
lot of time telling everyone what was wrong with it going over the design with a fine-tuned comb
and tearing it to shreds saying he's gonna have to rewrite it from scratch. So it was a very similar kind of feeling,
maybe not the same situation, but the feeling of, I worked on this for years and now this person's
coming in and they're taking it over. Whether or not they're saying it's bad or not, taking it over
still feels like a demotion or like you've done something
wrong um and i don't remember how i dealt with it i think i just got very angry
went off to work on went off to work on something else and let him have it
didn't you get an ulcer around that time i remember that was before or after
um but yeah this is super common especially in startups because new people come in and
there's a big you did it wrong and i have to prove myself kind of
tendency of new people coming into startups well and when you see a new when you see a design for
the first time you mostly see the flaws.
And part of that is because you don't understand it.
And so everything looks like a flaw.
And so it's hard not to be the person who fusses over everything.
You have to make an effort.
I think I've been that person too to keep to keep your mouth shut
until you understand enough and to figure out what the important changes are i mean this is
why when i do code reviews i have a level called knit which says my my ocd compels me to point
this out but it need not compel you to do anything about it. And because sometimes I just, I have to say,
but it really, I know it doesn't make any difference,
but I still have to say.
Yeah, we had nits at Fitbit in the iOS group,
except they were required to fix.
Well, that's not what a nit is.
So back to his question.
I didn't really have any good advice.
It was confusing to me to read because I couldn't formulate what I thought was good advice.
But thankfully other people did.
Well, I'm going to go with my advice and then I want to look at some of the others. And that is for people who are in this situation and maybe not for what you experienced. But some things to remember is the gray beard is good at general stuff. But you're the domain expert. You aren't coming into this working relationship with nothing.
You've already succeeded.
Emmett succeeded in shipping a product in this domain.
And that is something.
It means you've already seen the mistakes possible, possibly made a few.
And if your new gray-beard manager has been an individual computer... Can be a manager?
Well, he was going to be a manager now, but he's previously been an individual computer. Well, he was going to be a manager now,
but he's previously been an individual
contributor, so that's
always tough,
knowing that your new manager
isn't even really a manager.
That's how I read it.
Because
I said he was doing design work,
so that doesn't sound like manager to me.
Emmett said he was getting into demotion.
Well, okay. I took it as a technical demotion.
But that's fine. It doesn't matter, really.
But my point goes back to, remember you have your own experience, and for all that this new person deserves respect, so do you.
Yeah, specific experience in this particular product at this company.
And given remote work these days, screen sharing and being on the phone is really handy.
You don't have to do a Zoom with 95% of it being you on a camera trying to look interested and not like you just want to doodle.
Oh, wait. Sorry. I'm sure that doesn't apply to you. You can do this thing where you just
screen share and you don't have to feel the silence. You're just working in an office together,
looking over each other's shoulder. Okay. So for question three,
let's go back. What was question three? How do you share your baby?
You show what you've got. You don't hold on too tightly. And hopefully the gray beard will want to explore what you've done in order to get his information. Even if he's starting over,
understanding someone else's work is useful.
Offer up your knowledge as an overture of possible work friendship.
It will feel terrible, but it's a way to get further.
And it's a way to maybe get further as a team.
So to some extent, you're advocating for him as well.
You want him to succeed and you will succeed if he succeeds.
And that's really, that's what teams are about.
It's not trying to make it all about you.
Okay, so back to how do you advocate for yourself and keep learning?
Well, you have to do that whether he's there or not.
Didn't you do that before?
How does the gray beard fit in?
And it isn't a zero-sum game.
If the gray beard is as lazy as I am,
he'll be thrilled to share the work for you because it means less work for him.
Offer to take over parts. Be proactive about asking for advice when you're ready for it.
Don't just ask for it in general. Use the gray beard for his knowledge. Learn everything he
can teach you, even if he does it gruffly. I mean, it isn't a one-way street. You're
bringing stuff to the party and you're taking home goodies too.
You can say things like, I think maybe we should go to this virtual conference and it might be good for us. And the gray beard may say, oh God, no, please no. Please don't make me go to another
conference. We don't have time. I've been to so many of these. And then you can say, was it useful? Should I go? So you're actually advocating for both of you to go to a conference or to learn something.
And if the gray beard says no, you're actually in a better position than you would have been if you were just advocating by yourself.
Does that make sense?
Yeah, it makes sense.
I think, you know, it's hard because it's going to be the specifics of the person yeah the gray beard this is the description is law is specific it's detailed
but somewhat vague at the same time and so uh you know it's not clear to me what's really happening
what the gray beard is what their their working relationship is supposed to be.
So it's very hard.
And I think you have it right that taking the time
and taking the deep breaths to not get your dander up.
Dander up?
Dander up?
It's not dandruff.
Not get your hackles up.
That's what I'm thinking.
Sure.
At least too soon before there's a real reason to be upset
and trying to make it into a team.
Because that's what's happening, right?
In these startups, you start out and it's sort of a team,
but really it's just you off in a corner.
The rest of the company's a whole team,
but there aren't enough people to actually have a whole technical team.
And then people start coming in and you have the situation
and this is just what happens.
It's a little hard because,
and this is what threw me a little bit with this story,
is it's pretty unusual to be at a startup,
be the main person and then have somebody extremely senior brought in just wildly different um added to your team and basically say okay now this is the guy because you're you're the person
who's done all of this i'm kind of thinking how i would feel about this you're the person who's done all this you're at a startup you thinking how I would feel about this. You're the person who's done all of this. You're at a startup. You think, oh, I'm in a startup. So,
this is my opportunity to really shine and own this, grow, become a really senior person.
This is a springboard. And then now here comes somebody who's, you know, doing this longer than
you've alive and it's theirs now. That's really hard to deal with.
Well, Emmett said that he had been working really hard,
Herculean task, lots and lots of effort to ship the product.
Yeah.
I expect that his CTO manager felt the same.
It was a Herculean project, and then they just got bought by some big tech.
And maybe Greybeard was hired from the outside,
maybe Greybeard was transferred.
So there are multiple ways you could have gotten there.
But the manager, CTO,
might have said,
I don't have to do all the work anymore.
This is so exciting.
And neither does Emmett.
He doesn't have to do all the work anymore.
We'll give him some help. If they say that openly, that's great.
Well, it may not be said openly because you don't want to discourage people from working.
Well, then you run the risk of pissing people off.
Exactly. It's happened. It's really hard to give up what you've worked so hard on.
And this is one of those situations where a two-week vacation, even in these trying times, where a two-week vacation may end up being in the kitchen, the distance, the perspective is what's needed.
So that you come back to it with less resentment and more, okay's let's do something different now let's learn something different and that might be the option
is like okay i'm in big tech now and this guy's got this project and if things aren't enjoyable
you have places you can go other projects. And that's what ended up happening with the Procket. I was like,
okay, you got it. I'm over here now.
And I'm going to work on
whatever I was doing.
Multicast forwarding engine or something.
I don't remember what I moved to, but
it's, you know,
it's just really, I keep going back to it,
it's hard to not feel, like he says,
like this is
reflecting on his performance.
And it may have nothing to do with his performance.
Yeah.
It may be something that the boss was told to do.
And it may be something that does reflect on his performance.
But it may not be entirely negatively.
It may just be finally I get to give this kid someone to learn from.
Yeah.
And you don't know that. I always made the mistake of assuming maliciousness when usually it was either just neglect or someone actually trying to help in a way that I didn't understand.
Yeah.
And that brings about a lot of frustration that isn't necessary at all.
Yeah.
Let's see.
I want to talk a little bit about some of these other suggestions.
Jakey Poo wanted to point out to try to look forward to working on a team
and that teams come with more processes,
communication, documentation.
And this might not be a demotion.
It may just be a formalization.
And being the person who won't let go of a design,
it isn't healthy.
It's better to look forward to working with others to make it better.
And you can make sure it's a strong design by making sure there are strong
processes.
So if that's interesting to you,
you should do that.
Jakey Poo also wanted to point out that there are a lot of people who have
low pay because it's a scrappy startup. And now that you've been bought by big tech,
you should be getting paid well. Yes, yes, yes. Dial back the effort. Don't overwork yourself.
Take this as an opportunity to rest for a little while. Yeah, once you're acquired by big tech,
you're no longer a startup and you are no longer required to act like you are at a startup.
And now the work that you've been put in have been replaced by you and someone else.
So it's important to look at those.
Let's see.
Patrick chimed in that this wasn't a demotion, and the CTO's job is not to interface with every individual engineer on every project.
They don't have time for CTOing if that's what they're doing.
It's considered more like a role that wasn't being filled beforehand.
And then he talked some about the individual contributor track versus the management track and how those are separate and thinking about that is tough.
A lot of people on the Slack channel were kind of irritated that he didn't get to interview somebody who was supposed to be his new boss or his new major co-worker.
Tech lead, yeah.
I agree with that.
I would be very irritated if somebody hired my boss without me interviewing him.
Oh, I didn't get to interview the guy who took over OSPF.
But he did crash my car.
Oh.
No wonder you just kind of said, fine, goodbye.
I remember that.
Wasn't my car at the time.
It was his car.
It was your car.
It was my car.
We sold him the car.
We had sold him.
We sold him the car.
This is not an important part of the story.
I'm sorry.
But he hadn't actually registered the sale.
He sold him the car the next day he crashed it.
He walks into my office and he says, do you have insurance?
I said, that's not how it works, buddy.
Sorry, sorry, off track.
Let's see.
SMG had some good advice and it's mostly about being nudged in the right direction and learning as much as possible.
Yeah.
Ben had some good advice that ended with, if it all turns sour, get out.
That's advice all the time.
Well, it is, but in this particular instance, it... Well, that's what I was saying about being in big tech, too.
You have options beyond leaving the company.
You should have options beyond leaving the company should you
should have options beyond leaving the company um tom pointed out that at least you got to ship
imagine if this had happened right before you shipped and your design had been trashed
and that would be horrible i mean that would be so much worse at least you got to say yes that's
mine that's mine.
That's the thing with the imposter syndrome too. You can look back and say, I did this. This is a thing. It is out there. It's done. Was it perfect? Maybe not. Doesn't matter. It's done. I did it.
Not many people can say that. And so you can feel whatever imposter-ness you want, but
it doesn't matter. You did it. And they can come in and say, well, we didn't like that,
but who cares?
You accomplished it.
The goal was done.
Tom had a point about graybeards that I thought was,
well, sounded pretty relevant to me.
Here's a tip about graybeards.
They don't appear to do much actual work.
The good ones enjoy hiding the little real
work they do and are good at sharing credit or even dispensing undue credit. They know this is
how you get people to want to work with you. So I hope you got one of those because it's true.
A lot of times when you're pretty senior in your career, you don't need the credit anymore. And it's better
if you don't get it because if you keep getting more credit, they keep giving you more work.
But if you give the credit to other people, those people get the work.
It's true. And if you don't get any credit, you rarely get blame.
Well, that's true.
And Tom does point out that gray beards do things.
It just doesn't look like they do things,
which I thought was a good point about how some people work versus others.
And there's a lot about slow down.
Slow down now.
Don't keep working these 60-hour weeks.
60-hour weeks?
Are there that many hours in a week?
I don't know.
I think there are, yes.
Wow.
Yeah.
Take a step back. You can't do that for very long.
You end up with an ulcer.
And take this as not an opportunity, not a demotion, not somebody
stealing your baby, which it never was your baby. It's a company. That's true.
It's take it as a well-deserved vacation. You know, what's funny is I think about all these
things and I may have talked about this on the show where you asked me questions, but you think about all these companies,
how invested you get in the thing you work on there and how attached to it
and how upset when things don't go your way or when somebody impugns what
you've done or,
uh,
you know,
get credit.
And then when you finally leave a place,
at least for me,
within like two days, I no longer care at all.
Zero.
It's like, what was that?
Why was I so angry?
I'm no longer there.
It's very strange psychology.
I mean, that's part of why contracting works for you is that you lose some of that emotional investment and gain the distance.
I remember...
But it's just a disconnect.
Once you've quit, all of that emotion is like,
oh, that guy was such a jerk to me.
Yeah.
I don't work there anymore.
What is that?
And yet, now if you went back, having cleaned the slate,
it might be easier to work there.
Maybe.
I remember I was at LeapFrog and I had a project I was working on that was not part of the normal toy lines.
It was outside.
And I was told I had to get one of the toy managers to like it.
The toy manager.
And so I got one on board and he liked it.
And we agreed that we were going to sew it off together.
And I was excited because this was a possibility for my toy, just mine.
And he took it and he showed it to a bunch of people and it got okay reception.
It didn't turn out to be a toy.
But I was really upset.
I went to the vice president of engineering and said, it was like he took my
kids to kindergarten and I didn't even get to say goodbye. And the sad thing was that Mike said to
me, well, I have to tell you, I dropped my kids off at kindergarten this morning. And I was like,
okay, maybe that's not what I should have said.
Maybe I should have chosen something else.
So,
yeah.
It's easy to get invested in these things. We put so
much time and effort in them that if we
didn't like them... That's how they get you.
I know. But if we didn't like
them, it would feel dumb and
pointless. It would feel like normal work.
Well, that's the thing is that we forget that this
is actually work it's not us yeah it's hard to it's hard to remember that anything else uh that's
that's actually all i captured for uh i thought i had more but that's all i have right now so
do you have anything else i don't have anything. I forgot to bring down Winnie the Pooh.
Can we read it?
No. No, this time let's
let them make their own story.
We'll let
Pooh and Piglet continue
to wander around looking for woozles.
Am I... Is this airing?
Sure.
Alright.
Thank you to Christopher for producing and co-hosting.
You got it.
Thank you to our Patreon Slack for being, no, wait a minute.
Thank you to our Patreon supporters for being great and our Patreon Slack group for also being great. If you have any questions, concerns, jokes, whatever, show at Embedded.fm or hit the contact link on Embedded.fm.
I think that's all.
All right, bye.
Bye.
Embedded is an independently produced radio show that focuses on the many aspects of engineering.
It is a production of
Logical Elegance, an embedded software consulting company in California. If there are advertisements
in the show, we did not put them there and do not receive money from them.
At this time, our sponsors are Logical Elegance and listeners like you.