I did most of an electronic engineering course and discovered that I like software more than hardware. After programming portable barcode readers and interactive voice response systems, I wrote a Windows device driver at one company then applied to write Linux device drivers at another. I was strictly honest during the job interview, saying I wanted to write device drivers but I had done only one for Windows and none for Linux. The interviewer said "Writing Linux device drivers is exactly the same as writing Windows device drivers" and hired me. I found that it wasn't and faced the kind of learning curve that requires mountaineering equipment.

I succeeded and even trained someone else how to do it. When we started, he didn't know C all that well so I split the drivers into hard and easy parts and gave him the easy ones. We wrote about six drivers together. I made his parts harder and harder until he was able to write a driver on his own.

Perhaps I haven't been reading the right software architecture books but it seems to me that very little mention is made of changing the design to suit the ability of the individual programmers, the way band leaders like Duke Ellington and Glenn Miller did with their arrangements.

> I succeeded and even trained someone else how to do it. When we started, he didn't know C all that well so I split the drivers into hard and easy parts and gave him the easy ones. We wrote about six drivers together. I made his parts harder and harder until he was able to write a driver on his own.

This is a pretty amazing way to teach someone something as complex as device drivers. It sounds like you did an excellent job mentoring him.

Thank you. Stephen was quite deaf (60dB loss) so we emailed each other all day, even though we were sitting together. When I noticed he was straining to hear during a conference call, I started summarising what each speaker had said. He thanked me afterwards. When he looked confused about something I said, I made sure to repeat it using the exact words I had used as he hadn't heard one or more of them. I noticed that other people thought he hadn't understood, not that he hadn't heard, and repeated what they had said using different words, which confused him even more.

Stephen's deafness did not affect his work, of course, until management made him a quality engineer for our voice over IP project. With that kind of thinking, the company wasn't making any money and owed all of us six months wages. You learn a lot about motivating your team under those circumstances. I did it by emphasising the importance of what we were doing. Of the ten software and five hardware engineers, we were the only ones joining the software to the hardware.

Apart from not being paid, it was a great place to work and I'm glad it gave me an opportunity to develop my management and people skills. Until then, I had been much better at programming computers than working with people and I was feeling a bit lopsided.

I was always curious how things and systems work. There's no better to find that out than doing embedded programming, because it touches both hardware and software. I went to embedded programming straight from the university in my final years where I was studying telecommunication engineering. Knowledge of telecommunication systems and electronics besides C programming proved to be enough to get my first few jobs.