Live data from Hacker News

My dad's resume and skills from 1980

github.com

411–420 of 611 posts

Re: My dad's resume and skills from 1980

#411
post #90

Earlier quoted context omitted.

Also: I kind of like the concise wording when the writer doesn't feel they need to adhere to STAR. "Duties Included" is the only meat I want to see when I read a resume. I don't care what the specific challenge you faced was, or if your hard work transforming protobufs from one format to another resulted in "23% year over year revenue growth and 3 industry awards" for a product that uses your protobufs 5 layers up th…

I have an MBA, which I don't really use as a working software engineer, but nowhere else will you learn to take a clear, concise, one page paper (i.e., this is what we did and this is the result) and expand it to 10 pages of BS-laden corporate-speak nonsense. It's a real skill, I tell you.

MBA is still the junior leagues. To learn to take one line and turn it into a whole page you have to go to law school.

And even then, I would daresay that those are applied and therefore lesser. If you want to be able to expand one word into one entire paper, you need to go deep into academia.

Re: My dad's resume and skills from 1980

#412

Earlier quoted context omitted.

I actually very much agree with this comment. I was a manager for 25 years. A bad "team fit" was not good. I never had a technical failure in my hires, but I did have a couple of "bad cultural fits." These usually weren't toxic people, but people that couldn't handle the responsibilities and pressures (we were a small, high-functioning team, and everyone's visibility was fairly high). But this: > who also has a histo…

I'll second that. I never hired anyone who couldn't do the work. The only times things went badly were times when the person basically didn't want to do the work, due to some personal hangup. No amount of interviewing is going to weed out that guy who can code perfectly fine but deep down is yearning to be a psychologist instead. Like any other job that pays bills, you are vulnerable to paying his bills until they fi…

>I suppose what it really does is finds you people who are willing to put in the time to study all the hundreds of questions.

Yes, this is it.

Re: My dad's resume and skills from 1980

#413

Earlier quoted context omitted.

It was very niche. My dad (also early FORTRAN programmer) graduated in the very first undergrad CS class at UCLA, around '69 or `70. I think very few universities had a CS course at that time.

It looks like the first CS department was at Purdue (wasn't expecting that); they introduce a CS degree program in `67. UNC was another early adopter.

What is interesting is that the IITs in India (the first 5 at least) were setup a decade prior (late 50s), and some had very heavy support from American and European universities while setting up. So much so that IIT Kanpur actually had a CS department that started in 1963!

Re: My dad's resume and skills from 1980

#414

When 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."

As recently as the early 90's, making a lifetime career out of software development was considered impossible. When I was starting out in the late 80's all the developers were taking classes or had a side business, with the goal getting out of "programming" before it was too late. Even those who wanted to stay in the industry took every opportunity to talk directly with clients so they could get into sales or marketing.

Re: My dad's resume and skills from 1980

#415

Earlier quoted context omitted.

We do. 80% of the tasks that I did as an engineer in 1999 are fully automated today.

Interesting. Almost nothing I've done as a programmer since 1985 seems automated today. What do you mean by "fully automated" ?

ORMs didn't go mainstream until Hibernate in 2001 or so? Before that, everyone was writing custom SQL and DB access by hand.

Re: My dad's resume and skills from 1980

#416
post #281

Earlier 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…

>VCS dates back quite some time…

Let's see. From the story:

>I first met Mel when I went to work for Royal McBee Computer Corp... [The firm] had just started to manufacture the RPC-4000

https://en.wikipedia.org/wiki/LGP-30#RPC_4000

> the General Precision RPC 4000, announced in 1960

https://en.wikipedia.org/wiki/Version_control#History

>IBM's OS/360 IEBUPDTE software update tool dates back to 1962, arguably a precursor to version control system tools. A full system designed for source code control was started in 1972, Source Code Control System for the same system (OS/360).

The events of the story predate the precursors of VCSs by two years, and the earliest true VCS by a decade.

Re: My dad's resume and skills from 1980

#417

Earlier 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…

I was using objdump and cordumps to debug a kernel crash just last week. Not tedious at all. More like working a difficult puzzle. And very rewarding if you figure it out and fix the crash.

objdump and coredumps today are way less tedious than getting a compiler error the next day (if not few days out!).

At least with punched cards if you kept them sorted (line numbers in front a'la BASIC really helped with that) you could easily edit in place - just replace that one card that was incorrect, because each card = one line.

TECO (which begat EMACS) started out because paper tape which was preferred storage on DEC machines was harder to edit in place than card stacks and instead of retyping whole program you'd summarise your changes (that you dutifully copied on fanfold greenbar printout - or suffered) into few complex commands then used the resulting 4 tapes (TECO load tape, TECO commands tape, incorrect program, fresh unpunched tape) to get one corrected.

For maximum efficiency, the OS/360 team had to work 24h - the programmers would write their changes on first shift, then teams had to prepare cards, submit them for compilation, night shift reprinted modified documentation, and when you'd arrive at work you'd have fresh documentation and results of your compile (unless you had the luck to work on-line that day with more immediate feedback)

Re: My dad's resume and skills from 1980

#418
post #400

Earlier quoted context omitted.

The OP resume looks like a raw typewriter document to me. I don't understand what value it brings to go beyond - it's nothing but a tool to convey your skills and experience.

Dumb things such as having a tiny bit of color or a slightly less basic format can make or break you when the recruiter/hirer is sifting through the pile. Besides, it takes all of ten minutes to do this and be done with it. It's like fashion. Arbitrary but just having the basics understood goes such a long way professionally and socially compared to the effort expended

Maybe this is a good use case for AI. Write your resume then let AI rewrite it to be aesthetically pleasing to resume readers.

People like my interior decorating, I can appreciate other things that are aesthetically pleasing, and I've made my share of actual art. I just don't think I have it in me to understand whatever in the world is going through someone's mind when they're displeased with this resume. It's a missing faculty like blindness or tone deafness. When I get a resume or an email I just read it, I don't sit there and hem and haw over how many pixels the bullet point is indented or whatever it is.

This is why resumes should be abolished entirely and replaced by a standardized database you put your experience and skillset into. Anything an employer wants to know has to go in a standardized field. No discrimination can possibly occur based on your ability to format a piece of paper according to invisible, unpredictable metrics that you might have no faculty for and have no bearing on your ability to do the job.

Re: My dad's resume and skills from 1980

#419

Earlier quoted context omitted.

We probably are close to the same age. My dad was an engineer who also learned to program FORTRAN in the 70's. When I asked him a similar question his reply was (quotes are paraphrased): "It was way too tedious to do. You'd spend hours getting the cards just right. We used to put them in a shoebox and mark them with a pen in case we dropped them on the way to the lab. Then you'd wait until the next day to get your re…

> "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…

> ...and loved to say our jobs were going to India.

They weren't wrong, though; they just omitted delimiting that assertion.

Back in those dark ages, mainframe jobs were still considered by career "experts" the "adult in the room" jobs of programming. It is hard to convey to people who never studied that era or grew up in that era just how much microprocessor-based computers were considered "not real computing" in vast swathes of the industry. The proprietary Unixes thrived under that lay perception, as a "serious business" microprocessor-based computers market segment.

And the mainframe jobs did by and large up and wholesale decamped to India from large chunks of the mainframe account base. Those career experts were right in a way.

Just not quite the way they thought. The scope they thought in was too absolute because they lacked the technical (and business, and financial...) perspective and context to understand why the same wouldn't happen to quite the same extent to sectors outside mainframes, nor of the explosion of re-invention of the wheel of many mainframe tech stacks that would drive the industry forward even to this day and beyond, along with the rapid recombination of new ideas.

Re: My dad's resume and skills from 1980

#420
post #254
post #197

Earlier quoted context omitted.

As Seymour Cray said, "The trouble with programmers is that you can never tell what a programmer is doing until it's too late." It can be months (at a high salary) before you really know whether a hire is likely to work out. I think it makes sense to invest more effort in screening applicants in this case.

But I don't think there is research showing that those strange hiring processes actually do work.

I've seen many variants of the recruiting process from the cute product feature disguised as a take-home to 6 stage interviews with two engineering(!!) interviewers per round that cost the company a few thousand per (un)successful candidate in man-hours.

Which is hilarious in an industry that is pretty binary ("you can build it") || ("you can't build it"). Doubly so when the majority of dev jobs are in web which is easily explored in the candidate's language of choice with basic CRUD / RESTful concepts.

Post reply on HN