I don't talk about work details much, 'cause either they're so minor they're meaningless, or they're something my company wants to talk about before I talk about it. But every so often there's a tidbit I can share for my geeky friends.
You know you're a real Embedded Systems Programmer when...
...you find and fix a bug that involves changing this code
Extra bonus geek points if it doesn't happen reliably, doesn't happen in the debugger, and/or takes a long time to reproduce. More extra bonus geek points for not having been the one to put that bug in there in the first place.
That was late last week, and I was pretty proud of it, actually.
You know you're a real Embedded Systems Programmer when...
...you find and fix a bug that involves changing this code
var--;to this:
disable_interrupts();
var--;
reenable_interrupts();
Extra bonus geek points if it doesn't happen reliably, doesn't happen in the debugger, and/or takes a long time to reproduce. More extra bonus geek points for not having been the one to put that bug in there in the first place.
That was late last week, and I was pretty proud of it, actually.
no subject
What language is that - C or C++ or something else?
no subject
no subject
I hated interrupts when I was in CS in school. Exactly because of how thoroughly it kills debugging!
(I note that I am not a programmer now)
no subject
I'm glad I'm not in kernel land much any more. Tracking down multithreaded bugs isn't so bad when the debugger actually functions as designed. :-)
no subject
I haven't been in kernel land long enough that a bug like this is a no-brainer for me. I know people who have (okay, not many of 'em), or at least who are far quicker with such things. If I'm going to stay in kernel land, I want to get that good.
no subject
no subject
Along the same lines, you know you're a real embedded prgrammer when you fix a bug by changing a line like this:
int foo;
to this:
volatile int foo;
no subject
We should start a list. You're a real embedded programmer when you fix a bug by...
Heck, I'd probably learn something!
no subject
no subject
no subject
no subject
no subject
no subject
OK. I'm scared now. Time for me to go into management...
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
no subject
(I'm not a geek, I'm an accountant. I'm not a geek, I'm an accountant.I'm not a geek, I'm an accountant.I'm not a geek, I'm an accountant.I'm not a geek, I'm an accountant.I'm not a ....)
no subject
no subject
no subject
http://www.softwaresummit.com/2005/speakers/jennery_kimberly.htm (http://www.softwaresummit.com/2005/speakers/jennery_kimberly.htm)
But really, that's one of my punchlines - that designing concurrency into a program/system is a whole lot better than trying to retrofit it into an existing one!
no subject
Amen! It's easy to say "create new thread" but a lot harder to make sure you as a programmer have upheld your half of the bargain.
And yeah, retrofitting it is time-consuming and error-prone. This is obvious to the most casual observer, even the folks in management (that last was said with a smile). Yet we still wind up doing it!
no subject
no subject
no subject
no subject
no subject