My dad's resume and skills from 1980
371–380 of 611 posts
Re: My dad's resume and skills from 1980
#372When I first entered the working world as a programmer and administrator of an "academic computing center", in the early 70s, you met men like Ray - ex-military, GI-bill educated, learned computers from the electricity on up in their mid-career, rather frequently, either as customer engineers for one of the big mainframe manufacturers (there were 7 or 8, depending on when and how you counted), or from the minicompute…
My father was a physicist. He learned to program in FORTRAN in the university in the 70's. Decades later I, still a teenager, asked him something like this: "Dad, you were a FORTRAN programmer and physicist in the 70's, you could be a very well paid developer anywhere in the developed world... why didn't you?"; he answered me: "I didn't thought this thing about computers would go too far."
Re: My dad's resume and skills from 1980
#373The interesting bit about this post is that with that resume, you can still feed a family in 2022 (okay, you won't need any assembler, and one from the set { Fortran, COBOL } will do). I wonder if Python and JavaScript will get you that far 50 years from now?
Python has been in use since before I graduated college. I supported a code base written in Python at event Microsoft back then (they acquired a company that wrote their product in Python, and then ported it over to C++/COM). We all had one of the something like 1.4 O'Reilly books, even. And I think one person from the team went on to write/support/somehow be involved in Subversion SCM (which was heavily written in P…
Mercurial actually wasn't a bad choice at the beginning of the DVCS era on Windows as git didn't work well on that platform initially.
Re: My dad's resume and skills from 1980
#374When I first entered the working world as a programmer and administrator of an "academic computing center", in the early 70s, you met men like Ray - ex-military, GI-bill educated, learned computers from the electricity on up in their mid-career, rather frequently, either as customer engineers for one of the big mainframe manufacturers (there were 7 or 8, depending on when and how you counted), or from the minicompute…
> college recruiting materials might well brag that at their institution, there were not one, but two computers on campus. Our community college highlighted their Vax minicomputer by having a special window that showed all the flashing LED's to passers by. But when PC's became the "in thing", they felt embarrassed and covered the window with PC posters. Poor Vax, lots of memories together. It was an early lesson in I…
Re: My dad's resume and skills from 1980
#375Earlier quoted context omitted.
Nah, those were different times when bits and bytes mattered. Everything was written in assembly/,machine code. Mel's tricks were just how things were done back then. There was no repo, code didn't need to be maintained or added onto. The lifecycle of software was much much shorter.
> Nah, those were different times when bits and bytes mattered. Obviously not. We're talking about mundane business software. Also the "optimizing compiler" that couldn't reach such levels of "perfection" wouldn't be a thing if this would really matter. > Mel's tricks were just how things were done back then. Obviously not. Otherwise there wouldn't be any point in this story. It points out, with a lot emphasis, how e…
Re: My dad's resume and skills from 1980
#376Earlier quoted context omitted.
Why did Python win the war with Ruby? Was it purely the math community deciding this is where we throw our weight and left Ruby the runt of the litter?
Performance. So many people say it doesn't matter. Until it does. Python works around it by having so many libraries built in C or C++.
Which works quite fine, until it doesn't.
By than the needed rewrite in some language that delivers decent performance and safety all over the place in one package will be very expensive.
I'm not saying that you should avoid Python (and its native code kludge) altogether but when using it just pray that you never reach that point mentioned above. It's a dead end and will likely require an almost full rewrite of a grown, business critical (and already heavily optimized) application.
Re: My dad's resume and skills from 1980
#377Re: My dad's resume and skills from 1980
#378Earlier quoted context omitted.
> "I didn't thought this thing about computers would go too far." I almost didn't major in Computer Science because in the late 90s, there were so many negative articles in the New York Times, vis-a-vis software. People don't remember it now, but the media and the culture were utterly hostile towards us, and loved to say our jobs were going to India, that everything there was to know about Computer Science could be s…
Universities are always several years behind the curve. At college in the 90s they were still teaching token ring networking despite Ethernet already being common place. The same college told me that programmers didn’t design any of the code they write; they only transcribe code from flow charts. Just yesterday I was talking to a grad about DevOps. He said the field sounded boring from what he was taught at uni. Then…
Re: My dad's resume and skills from 1980
#379Earlier quoted context omitted.
Which is, of course, included as “The story of Mel” in the jargon file: http://www.catb.org/jargon/html/
I was fascinated by this story as teenager. But looking back on it, I would say out of my current perspective this Mel guy was not a genius, but one of the worst programmers you could probably hire: He written unmaintainable and even unchangeable "write-once" code that was so complex that nobody else could handle it either. He refused to do what he was payed for and just went away as he lost interest. One of this kin…
Re: My dad's resume and skills from 1980
#380Earlier quoted context omitted.
That's an awesome saying -- I'm surprised I've never heard it. It remains true after a LOT of mutation. The trouble with programmers is that you can never tell what a programmer is doing until it's too late. The trouble with programmers is that you can never tell what a program is doing until it's too late. The trouble with programs is that you can never tell what a programmer is doing until it's too late. The troubl…
The trouble with aphorisms is that you can never tell what an aphorism is saying until it's too late.