In 1984 I was working for a small company that made Z80-based desktop computers running CP/M. All of the software was written in Z80 assembly language. MS-DOS was gaining traction, so we built a machine that contained both a Z80 and an 8088. It could run CP/M or MS-DOS.
However converting a bunch of Z80 assembler to x86 assembler for all our system utilities etc was a daunting task. There were tools available that would translate the code, but the quality was poor and the resulting output was not really readable [maintainable]. I expressed my annoyance in a planning meeting, saying "We should have written some of this in a high level language." One of the other guys on the team had done a small amount of C programming at university and was aware of its portability advantages. He suggested I look into it.
Although I had used several high level languages in the past (Basic, Fortran, Pascal), I was completely unfamiliar with C. So I bought a early edition of K&R. I started reading it from the start; got about 4 chapters in and thought, "This looks easy enough." So I sat down and wrote a rudimentary VT100 terminal emulator (something I knew a great deal about at the time). I tried to compile it: a dozen errors on the first line, a dozen errors on the second line, etc. I thought, "Hmmm, maybe not so easy after all."
The one guy I knew who had done any C programming at all, had done so little as to be useless as a source of knowledge, and we didn't really have a great deal of C source code available to us at the time. So I sat down with K&R and started doing the examples 1 at a time. Hello World going forward.
I picked it up pretty quickly, and within months our source was about 80% C and 20% assembler. Although I wasn't a self-taught programmer, I was pretty much a self-taught C programmer. The scary thing was, I was then considered "the go-to guy" for C programming advice for the rest of the team. I probably ruined them for life.
Agreed. Using git or mercurial would get around this. I worked for nearly a decade on cross-platform code that followed a similar methodology.
Our rule was the code most compile w/o warnings on 3 dissimilar platforms before you could commit it. We were able to do this easily because we had network-mounted home directories, so when you logged into another machine, our development tree was automatically mounted. This made it easy to compile without checking in, then checking out.
It is realistic. I worked on a cross-platform product for nearly a decade that followed a methodology very similar to this. Our code worked on 16-bit, 32-bit, 64-bit, big-endian and little-endian systems. Following these rules did not slow down development noticeably. In fact it became second nature.
Hmmm, "heard/read" limits it a bit, as "self realization" is more memorable.
However, in the 7th grade (age 13-14), my math teacher explained to me
that education was a "privilege, not a punishment". I don't remember how
it changed my thought processes, but I remember the moment. Previously,
I was what you might call a "slacker". After that, I was "nerd slacker" -
at least I paid attention, even if I was still lazy.
A decade late, I graduated university with a degree in Mathematics and
went into software engineering. Smart + lazy = good software.
Although not totally worthless, it is nearly so. It is ~350 slides, most with a single word. To find those commands you've never heard of, you have to wade through a deluge of meaningless, when out-of-context, crap. Most readers, like me, probably said "not worth the time" after about 20 slides.
What seems like a lifetime ago, I was taking graduate CS classes at my local University. I had been writing software professionally for more than 20 years, so I was atypical in my class.
We were given some assignment to write a mail server in Java. At the time, I had never used Java, but had decades of experience with other dialects of C, so I taught myself Java over the weekend.
I put together the server, as well as several classes that could be shared by the client and presented it to the team on the following tuesday. When I showed them java code in emacs, with a Makefile to compile it all and jar it up, they were astonished. They didn't believe that:
1) I had learned the fundamentals of a language in a couple of days and was producing professional quality code in that language (actually professional quality design).
2) That I could do it outside of some java-specific IDE, using 20 year old tools.
I learned Java over a weekend; I wasn't about to tackle ANT at the same time.
After years of using ANT, I still think it is a pain in the ass.
One way to have long, but memorable passwords is to construct them using the first letter of each word a rather long, but memorable quote/phrase. E.g., The opening of the Gettysburg Address yields: fsasyaofbfutcannciladttptamwce. And if you forget the exact words, you can always look them up.
It is probably just a concatenated string of his credit card number or social security number and random words. I wonder if they are currently trying to crack it using some kind of dictionary brute force mechanism, or if there is some kind of lock out enabled after five tries.
If they have physical access, then there is no effective lock-out mechanism. Presumably they can determine which encryption software is used, and can use the algorithm as many times as they want.
However converting a bunch of Z80 assembler to x86 assembler for all our system utilities etc was a daunting task. There were tools available that would translate the code, but the quality was poor and the resulting output was not really readable [maintainable]. I expressed my annoyance in a planning meeting, saying "We should have written some of this in a high level language." One of the other guys on the team had done a small amount of C programming at university and was aware of its portability advantages. He suggested I look into it.
Although I had used several high level languages in the past (Basic, Fortran, Pascal), I was completely unfamiliar with C. So I bought a early edition of K&R. I started reading it from the start; got about 4 chapters in and thought, "This looks easy enough." So I sat down and wrote a rudimentary VT100 terminal emulator (something I knew a great deal about at the time). I tried to compile it: a dozen errors on the first line, a dozen errors on the second line, etc. I thought, "Hmmm, maybe not so easy after all."
The one guy I knew who had done any C programming at all, had done so little as to be useless as a source of knowledge, and we didn't really have a great deal of C source code available to us at the time. So I sat down with K&R and started doing the examples 1 at a time. Hello World going forward.
I picked it up pretty quickly, and within months our source was about 80% C and 20% assembler. Although I wasn't a self-taught programmer, I was pretty much a self-taught C programmer. The scary thing was, I was then considered "the go-to guy" for C programming advice for the rest of the team. I probably ruined them for life.