I'm a self-taught engineer, and I first picked up Big-O when I was 16. (That was almost 20 years ago). I've written a linux kernel patch (rejected), toy compilers, and the two big no-nos of software development ( 1: Writing your own lock-free code, and 2: Writing a string library, both of which went successfully into production ). I've built my own microprocessor from NAND gates, and wrote the microcode instruction set to go with it. I've studied VLSI (ages ago), but I've never dug into AI topics.
There is one way in which I feel handicapped compared to my colleagues, which is that I find it generally hard to grab a book on a programming topic and read it cover-to-cover (The same goes for taking classes). I've got to get a development environment up, see how I can break the 'examples', and generally abandon the book to doing my own thing before I get more than a third of the way through.
On the other hand, every time I've worked with more classically trained developers on real projects (and all the cruft that goes with it), I always find that there are corners of the code base that none of them understand, and no one ventures in to find out what's wrong.
Myself, I need to understand how a system works in order to work on it, so I always dig, and tweak here, or tweak there, and so I tend to learn full systems much quicker than my colleagues.
In the end, it's a trade-off, but it's how I work, so I guess I'm stuck with it.
Comments
I'm a self-taught engineer, and I first picked up Big-O when I was 16. (That was almost 20 years ago). I've written a linux kernel patch (rejected), toy compilers, and the two big no-nos of software development ( 1: Writing your own lock-free code, and 2: Writing a string library, both of which went successfully into production ). I've built my own microprocessor from NAND gates, and wrote the microcode instruction set to go with it. I've studied VLSI (ages ago), but I've never dug into AI topics.
There is one way in which I feel handicapped compared to my colleagues, which is that I find it generally hard to grab a book on a programming topic and read it cover-to-cover (The same goes for taking classes). I've got to get a development environment up, see how I can break the 'examples', and generally abandon the book to doing my own thing before I get more than a third of the way through.
On the other hand, every time I've worked with more classically trained developers on real projects (and all the cruft that goes with it), I always find that there are corners of the code base that none of them understand, and no one ventures in to find out what's wrong.
Myself, I need to understand how a system works in order to work on it, so I always dig, and tweak here, or tweak there, and so I tend to learn full systems much quicker than my colleagues.
In the end, it's a trade-off, but it's how I work, so I guess I'm stuck with it.