I was literally just thinking about my own regret in not pursuing my own OSdev goals when I was a teenager!
Well, I don't think about the regret any more, it's too painful. Ditto for the state of modern software, which used to make me terribly angry for various reasons, some of which are better thought-out than others. What I'm trying to do now is trying to improve myself to make programming easier, so I can make up for all the things I didn't practice back then. My problem-solving and planning abilities are improving from month to month. I'm now trying to develop patience with my own thought processes. I'm trying to be like Chuck Moore:
Quote:
Mike Perry relates a story about Chuck's CAD system.... Chuck
showed Mike that he had written the core of the CAD application
in about five lines of code. When Mike asked him how long it
had taken, he replied, "Oh, about two years."
cmForth's metacompiler is the result of one of Chuck's long
contemplations. It reduces the largest headaches in
metacompilation to fewer than twenty lines of code, all told.
To make that possible, the structure of cmForth departs
somewhat from the familiar.
http://www.ultratechnology.com/mmeta.htmlActually, I'm trying to develop that skill without holding back from gaining experience. Experience clarifies understanding, which in turn helps simplification, but gaining experience means I need to just dive in and do things. It's a bit of a paradox.
Muazzam, you're probably ahead of me in reading documentation, which is an essential part of programming these days. I'm presently tolerating Python, but it took me
hours to pick out the simple way to open a tcp stream connection from a single module's documentation! It was exhausting. Some modules are better documented than others, but the apparantly universal drive to sort documentation alphabetically does not help the beginner! Modern hardware is just as bad. I wanted to start machine code programming the other week, so I downloaded Intel reference manuals and found them as vast and impenetrable as the Himalayas!
I will make use of them some day, when I have practice with it and better know what I want and how to achieve it. I'm going to start with a 386 reference to get practice. I'm hoping studying documentation in general will get easier with practice too.
You know, there's a whole bunch of different skills in programming. Studying documentation, design, implementing, bug analysis, and even motivating yourself and finding inspiration are all different skills. Developing your bug analysis skills will help with hobby and job alike, and may help overcome implementation difficulties. Getting stuck is an inspiration problem. I get my inspiration by trying other systems, and by meditating on the consequences of design choices. I come up with a design I fancy, often a simple thing, and I imagine a system built around it. I try to imagine how other design features would interact with it. This can take hours; its like daydreaming but a bit more focused. (It's not "transcendental" medatation, that's something else entirely.) Time away from the subject can also be important.
I don't think there's any meaningfull strata of programmers. I'm sure those 2-year programmers "doing" cutting edge research would be merely lab techs in any other field of science. Their names wouldn't be on the papers. There has always been a lot of hype and hubris in computing. It was needed in the early days to sell those slow machines.* It's desired now to motivate programmers to work, regardless of their actual skill level.
A guy I know is a supercomputer sysadmin. Last I heard, he was on the 14th best supercomputer in the world. (He was on #1, but moved his family out of Baltimore.) He knows he's just a technician, not an engineer. His wife is an actual qualified civil engineer, and he teases her because his job title includes the word "engineer" too,
but he knows computer "engineering" standards are
far below those of any other field.
*: An elderly friend has a story about that. He worked for a company which had a giant filing cabinet for all their paperwork. They hated it! Believing the hype that a computer would cut down on paperwork, they were one of the first companies in the area to get a computer, in the 1960s. The computer produced so much more paperwork, they had to buy two more giant filing cabinets like the first!
Oh by the way, considering the time it takes to make an operating system, 5 years isn't a terribly long hiatus. 30 years might be, but I'm not letting it stop me.