Live data from Hacker News

My dad's resume and skills from 1980

github.com

251–260 of 611 posts

Re: My dad's resume and skills from 1980

#251

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…

> even the people who taught it were still just learning it. Still true today.

And this will likely never change as the most skilled people land eventually in leadership positions or become entrepreneurs.

By the day we didn't even invent some best practices or std. tools everybody in the field would agree on.

CS is still like electrical engineering around 1850. ;-)

Re: My dad's resume and skills from 1980

#252

If the minimalist resume is appealing, can we also bring back walk-on hiring? In warehouse and construction work, if someone shows up at 7:30 AM on a Monday morning, odds are quite good that the foreman will have something for them to do. Maybe not that day, but maybe tomorrow, or maybe someone on the list above them won't show up that week and they'll get called. I made rent doing that in my early 20s and they even…

We had a fellow just out of college walk in off the street, maybe 2015 or 2016. "I heard you guys do Clojure programming here, is that right?" We said yes. He said I'd like to interview. We interviewed him that week and hired him.

We were a small-ish startup and he had done his homework, showed interest, and could write code to our standards. He stayed for a year or two and then moved on.

Re: My dad's resume and skills from 1980

#253

Earlier quoted context omitted.

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

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 studied in railyard switching, in existing abstract math textbooks, etc.

By a combination of luck, and my dad's insistence, I ended up at Carnegie Mellon, and while I was there, I saw what folks at Google were doing, and I thought to myself, no, this stuff is hard, and this is just going to be the beginning.

> "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 results. If you had a mistake you'd repeat the whole process"

Even what came after that, e.g. in C / C++ was considerably tedious compared to what we do today. Folks sometimes had to do objdumps of compiled binaries to debug what was going on. We had to get coredumps, load them up, and try to determine what memory error had caused things to crash (this is an entire class of problems that doesn't exist today). You used to legit need that CS degree in order to code in your day-to-day because you had to understand the function stack, the network stack, basic syscalls like wait and poll, etc.

It was a lot of work, for relatively little product, and I think part of the reason why software is paid more today is in part because of 1. faster processing speeds and 2. better tooling and automation, and higher-level programming languages – all of which were enabled in part by cheaper / faster CPU speeds (e.g. people don't have to care about how slow Python is – you can optimize it after you find product-market-fit), and 3. a better understanding of how software should be developed, at all levels of management.

Re: My dad's resume and skills from 1980

#254
post #197

If the minimalist resume is appealing, can we also bring back walk-on hiring? In warehouse and construction work, if someone shows up at 7:30 AM on a Monday morning, odds are quite good that the foreman will have something for them to do. Maybe not that day, but maybe tomorrow, or maybe someone on the list above them won't show up that week and they'll get called. I made rent doing that in my early 20s and they even…

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.

Re: My dad's resume and skills from 1980

#255
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.

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.

Re: My dad's resume and skills from 1980

#256
post #197

If the minimalist resume is appealing, can we also bring back walk-on hiring? In warehouse and construction work, if someone shows up at 7:30 AM on a Monday morning, odds are quite good that the foreman will have something for them to do. Maybe not that day, but maybe tomorrow, or maybe someone on the list above them won't show up that week and they'll get called. I made rent doing that in my early 20s and they even…

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.

I know a company that hired a contractor, who (probably) sat on his ass for months, then went AWOL with nothing delivered, and said company had to start over from scratch. Probably a little too much trust there.

Re: My dad's resume and skills from 1980

#257
When I graduated college with a EE degree in 1977, my resume was damned sparse on experience, mainly because I didn't have any. All I could throw out were the EE and engineering classes I'd taken in school. Somehow, I got hired by a company in S.V.. By the time I retired after 43 years, I had so much experience, it wouldn't fit on 3 pages. Fortunately, I didn't need a resume any longer.

Re: My dad's resume and skills from 1980

#258

Good to see your dad's resume. Good recollections of the programming languages COBOL and FORTRAN. Hope your dad enjoyed and continues to enjoy whatever he does. I was born in 1981, learnt programming in college in 1999-2000. I learnt COBOL and FORTRAN too. To me, at this moment, all programming languages are almost the same. I am doing go now, will pick up rust by the end of this year. We have to the solve the proble…

> To me, at this moment, all programming languages are almost the same.

COBOL, Fortran, Go, and Rust are all the same language… ;-)

Have you tried out OCaml, Scala, or Idris?

Or maybe something exotic like Mercury?

Re: My dad's resume and skills from 1980

#259

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

No? You had valgrind to find memory bugs in 1985?

Re: My dad's resume and skills from 1980

#260
post #197

If the minimalist resume is appealing, can we also bring back walk-on hiring? In warehouse and construction work, if someone shows up at 7:30 AM on a Monday morning, odds are quite good that the foreman will have something for them to do. Maybe not that day, but maybe tomorrow, or maybe someone on the list above them won't show up that week and they'll get called. I made rent doing that in my early 20s and they even…

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.

I've hired hundreds of developers over three decades, and this is completely wrong:

> It can be months (at a high salary) before you really know whether a hire is likely to work out.

It's only that way if you make it take that long. You should know if you have a good programmer 2-3 weeks after the hire. Here a couple things that make making great hires hard:

* Making it difficult to learn and understand your system.

* Having slow and expensive employee onboarding. I've seen companies spend $3-4K (not including the actual laptop) just getting a laptop to a new employee after IT gets done with it. If it's super-expensive to make a hire, the incentive will be to keep people that aren't getting the job done.

* Not looking at work output for extended periods. In short give new people tickets that can be done in a few days at most so you are able to look at work output in six days instead of measuring at six months.

> I think it makes sense to invest more effort in screening applicants in this case

There's only so much you can really screen before error in your hiring process exceeds 50%. Every step you add to a screening process has an error rate, and some are very subjective and error prone. The more screening you do, the slower you go, and honestly, the worst candidates you have to pick from. Why? Because a good programmer will be on the job market for 1-14 days (I'm not saying you are bad if it takes you longer to get hired, it's just what we're seeing in our recruiting software right now).

Post reply on HN