[openbeos] Way Beyond Scheduler/Reminder

  • From: Scott Mansfield <thephantom@xxxxxxx>
  • To: openbeos@xxxxxxxxxxxxx
  • Date: Tue, 23 Sep 2003 23:01:30 -0700

Hey Adi,

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:

Hi!

From: "Scott Mansfield" <thephantom@xxxxxxx>
Since when has being a graphics artist a prerequisite towards improving
the user experience? Pretty pictures aside, there's a lot that happens
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 artists
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, read on...


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 benefits.

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 about
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.
* Patience.
* 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.
* Patience.
* Be able to context shift quickly.
* Perseverance.
* 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 hand."
* Have a good understanding of your target hardware. The more you grok about how the hardware and software interact, the better.
* Patience.
* Know where to get information you don't know. Google is your best friend here.
* Know what a deadlock is.
* Know what "spinlock hell" is all about and how to avoid it.
* Patience.
* Know what critical sections, semaphores, and mutexes are, and when it is appropriate to use each in your sandbox.
* Perseverance.
* 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 entire session.


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" -- same difference).

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? :-)

Take care,
Scott


Other related posts: