[openbeos] Way Beyond Scheduler/Reminder
- From: Scott Mansfield <thephantom@xxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Tue, 23 Sep 2003 23:01:30 -0700
Pardon the slow response, things have been a little crazy the last
couple of days...
On Monday, Sep 22, 2003, at 02:56 America/Los_Angeles, Adi Oanca wrote:
From: "Scott Mansfield" <thephantom@xxxxxxx>
Since when has being a graphics artist a prerequisite towards
the user experience? Pretty pictures aside, there's a lot that
under the hood to accomplish what you're advocating. It takes is
desire, imagination, initiative, the ability to speak one's mind, and
the wisdom to take constructive criticism at its face value and not as
an assault on your person or character. Something you're very well
qualified to do.
No no.. haven't you heard about the classical conflict between
and programmers? Each one with their task!
Yes, each to their task. I used to be a GUI designer by trade.
Painting, cooking, and writing music are my true hobbies when I'm not
bicycling, chasing women or coding. :-) There is a corollary here,
I truly believe that you would fit well within the GUI design universe
for reasons mentioned earlier. You may not be able to draw pretty
pictures, so what. You've got a good grasp on the user experience, you
aren't afraid to share your ideas, and you are willing to take in
dissenting opinions constructively. I also sense some creative,
artistic aptitude lurking somewhere in that skull of yours. :-)
A good engineering team works with the creative team, and a good
creative team works with the engineering team. Yes, that's a bit
circular. FWIW: I've learned in my 16+ years as an engineer that with
just a small amount of effort the classic conflict can very easily be
transformed into modern collaboration.
So you're not an artist, that shouldn't be an obstacle. You can,
however, convey what you're visualizing to the creative team with
words. Let the creative team transform your words into pictures (or
icons, window decorations, backgrounds, pointy-clicky things,
whatever). If what the creative team presents doesn't quite fit what
you're visualizing, then you tell them so. Conversely, if the creative
team thinks they can enhance or improve upon your ideas they must be
allowed to do so, unfettered. Along the way a process of discovery
happens and some really cool s**t shakes out.
Collaboration versus conflict. Cooperation versus adversity. Everyone
wins instead of everyone losing. Along the way the project as a whole
Neither is suited towards
embedded/device driver development tasks
Then maybe you can help me!
I want to know how device drivers are written. I know nothing
that. Can you give me an URL to start from?
Yikes! That's an awfully big question! Honestly I couldn't give you
an URL to start from because I'm guessing that you want to know how to
write OBOS device drivers, no? My device driver and embedded
experience has been strictly Windows and Linux, so whatever info I have
in all likelihood doesn't apply to our project.
Here's some platform-agnostic observations, take them at face value:
* "Device driver developers aren't made, they're assembled from spare
C.E.'s and burnt-out S.E.'s" -- to paraphrase a line in "Saving Private
Ryan." Bonus points if you can quote the original line here.
* The ability to read a schematic is a big help, but isn't required.
* Knowing how to use an oscilloscope, frequency counter, multi-meter,
and other test equipment is a HUGE help.
* Be able to context shift quickly.
* Understand the difference between a line discipline and a protocol.
If you can correctly answer the question "When is the traffic highest
for a line discipline?" you're golden here.
* Know your target operating system like the proverbial "back of your
* Have a good understanding of your target hardware. The more you grok
about how the hardware and software interact, the better.
* Know where to get information you don't know. Google is your best
* Know what a deadlock is.
* Know what "spinlock hell" is all about and how to avoid it.
* Know what critical sections, semaphores, and mutexes are, and when it
is appropriate to use each in your sandbox.
* Expect that you will, in many cases, be starting cold with new,
unfamiliar hardware a/o software. You, as a low-level developer are
expected to be able to digest large amounts of possibly disingenuous
information in relatively short order and be able to make sense of it.
* PHB's are the enemy.
* MOST IMPORTANT: be able to read and digest at least 200+ pages of dry
technical documentation in a single sitting, unfazed. Your head must
NOT hit the desk, monitor, the back of your chair, or any other
supportive device conducive to "nodding off." Other than the standard
eye-moistening activity (blinking), your eyes MUST remain open for the
Generally speaking, writing embedded applications isn't much different.
Good examples of embedded applications are the stock Palm OS apps or
some Windows CE apps (Microsoft calls them "pocket applications" --
The four cardinal rules of drivers and embedded apps:
* Be as efficient as possible.
* Be as quick as possible.
* Play nice with both kernel- and user-space.
* Don't hog resources, yield whenever possible.
Still want to learn how to write this kind of stuff? :-)
Other related posts: