"We created the programs, and once they were completed and tested we handed them off. Others were responsible for maintaining them, we just wrote new ones!"
She'd be right at home in the modern job-hopping work environments.
>Incidentally, the SJ management was quite unhappy when they found out that the trainee program brochures had been sent out to both male and female students! There weren't many women who got accepted into the program, but we were a few.
Interesting! My mom learned programming in the same window, getting a civil engineering bachelor's from 1964-68, during which she used Michigan Algorithm Decoder for writing programs that had to be shipped as punchcards to mainframes.
When she took an aptitude test in high school that said she should go into engineering, the school counselor's reaction was, "right, right, but of course women don't go into engineering, so stick with that plan to be a math teacher". (I know because she tells the story about every other day.)
My mom about the same time fought to be allowed to take shop class in high school, but wasn't allowed. My dad meanwhile was the first male to take home economics (different school though, so while it seems likely we can't know for sure that a girl in his school would not have been allowed to take shop).
Even in the 1990s I knew a girl who was told she shouldn't take some sort of engineering class - but when she insisted she was allowed. (3 other girls joined the class when they knew they wouldn't be alone)
Somewhere I've got a flow chart stencil identical to the one shown in this post, with sleeve. An older programmer gave it to me; it was originally from IBM, I believe. I haven't used it since the early 90's.
I was especially charmed by the phrase "pajama paper" to describe the old printer paper with the alternating 3-line high bars of color; I've never heard it called that before, but I plan to call it that from now on. On the, um, rare occasions the topic arises.
The article is translated from Swedish to English. "Pajama paper" is perhaps a localized expression for this paper style. I've also never heard it before.
As you say, its a pretty old term used, since the printout paper itself resembles a classic blue and white striped pajamas.
Pretty much disappeared in Swedish use since the advent of computer monitors.
But I recall my grandpa, who worked at a big Swedish bank during the same time period, using the term in reference to any striped paper.
I somehow have the exact same IBM stencil too and actually used it in class during the 2000s for tasks unrelated to programming. At the time I made my notes very neat and clean and those stencils definitely helped.
> The punch cards had 80 columns – 72 for the program and 8 for sequencing – so each line of code could be at most 72 characters wide.
In case anyone was wondering why the code only used 72 characters, it goes back to FORTRAN, developed on the IBM 701. The IBM 701 was a 36-bit machine. Its card reader loaded 80-column cards one row at a time (sideways to what you might expect), putting the hole pattern in two 36-bit words. Thus, it could only read 72 columns. (A pluggable wiring panel let you select which 72 columns you wanted, but normally it was set to columns 1-72). The 72-character limit has persisted in various places, even though the IBM 701 from 1952 is long gone.
Riddle me this, where did the magic 132 columns come from? I want to say it was fortran77 when extend source was added to let fortran files use 132 columns.
I investigated 132 columns in detail and wrote a blog post about it. It's complicated but essentially, 14 7/8" paper was a standard size going back to the IBM 402 tabulator in 1948, where it was used for 88-column output using a character spacing of 5/32". The IBM 1403 printer (1959) changed to 10 characters per inch, resulting in 132 columns on 14 7/8" paper.
Context about the author: He wrote the EGUI library, an immediate mode rust GUI library. It's very good; one of the best GUI coding experiences I've had.
The hand-annotated code chart reminded me how 1989's LPMUD from Sweden wrote the author's name as "Lars Pensj|" since "Pensjö" couldn't be done in 7-bit ASCII. I guess it would've been "Pensj@" in EBCDIC.
> First we learned a bit about IBM OS, and then we learned PL/I which was IBM's own programming language. It was a more modern version of Cobol with features that Cobol did not yet have (but would get later), like making tables and queries.
It certainly wasn't like Pascal in 1969, given that the first release of that language was in 1970.
If it's 1969, and you didn't happen to have heard of ALGOL, what you know is COBOL, FORTRAN, Assembly, and maybe BASIC: then yeah, PL/I looks like a more modern version of COBOL.
One advantage over FORTRAN IV was that PL/I had complex number types and the associated math libraries. This made certain engineering calculations much easier, for example, transmission line calculations.
It suffered from being IBM proprietary and from its size and complexity, which were too great for the early wave of minicomputers. Hence the rise of the much smaller and more open C language.
I get impression that a lot of open source, is because programmers 'want' to program, it is a hobby, for fun. Because at work there is no programming happening.
If you take entire market.
It seems 90% jobs are not programming anymore. Most jobs today are tickets, or maintenance, or installing some other package, various terms for 'support'.
I've met an awful lot of programmers who either don't know how to have fun, or keep it a closely guarded secret.
Some writers claim that they have to write some of their ideas down so they can get them out of their heads and get some peace. It's an exorcism. I have a very strong suspicion and circumstantial evidence that a lot of open source is much the same. Exorcism, or catharsis.
Sometimes we write code to settle arguments as well. And sometimes we write open source code because we don't want to have to write this code the nth time when we go to a new job. It gets really boring, and if you can convince your boss it's for the Greater Good to put it out there, then you get to reuse it.
Yes.
This was more to my point.
There are a lot of people that like to program, but don't have a job that allows for them to program. Even if the job title would indicate it is a 'programming' job.
Or other example.
At work I'm stuck in meetings, and scrums, and bureaucracy
And at home, I can code for the joy of coding. And a lot of this effort might go to open source.
Just seems like there are a ton of 'software' jobs that just move paper around, and not that many that get to code.
Tickets was just example.
Edit:
So, more high level. How many people took software jobs because they like to code, but end up not coding because a ton of software jobs are on the bureaucracy side. They get frustrated, so go home and code open source.
Maybe asking here in a thread about coding in 1969.
Because even coding from 1999 is no longer possible, and seems more like 'an elegant weapon for a more civilized age.'.
Program has always been about 20% of the labor of a program. Testing was 50%, maintenance, documentation, and other things are the other 30%. The above numbers are all estimates and you can adjust them to some extent - trading quality for test time for example: I know some industries that when to 60% test, and some do less than 50% in test.
The numbers have not really changed in modern software. We do more automated testing now, so programmers might spend a little more time on software, but the additional time is just in test.
What you are relating is a break down of tasks a programmer might do, the % hours of a day for these activities, tasks a programmer does as a part of programming.
They might spend 20% of their time programming, like you say. Actually creating code.
I'm asking, where are these jobs.
It seems like 90% of the 'programming' jobs are doing '0%' coding. The job isn't about creating any new logic at all.
It seems increasingly difficult to find a job that 'codes at all'.
For real?
I'm asking about the entire industry.
Maybe voice an opinion after you get your second job.
Edit:
I'd say overwhelming, 'tickets' are taken and resolved by people with no access to code, and no authority to make any fixes. The situation you are representing is a very small percentage of problems.
Maybe voice an opinion after you get your second job.
You might do well to watch your tone.
I'm not the one you're replying to, but it seems you've constructed a straw man and are now beating the living stuffing out of him. Are you arguing that there are no jobs where machine-executable code gets written anymore? Assuming that is the case, I believe the burden is upon you to demonstrate a lack of new code being written. Because I've got a commit waiting for it's commit message, and it sure looks a lot like a new data abstraction layer to me, and I'm pretty sure I'm the one that wrote it.
I think there may be a confusion here between engineering task tickets versus customer-support tickets which might just be "the thingy isn't working somehow".
Nice history! So cool to read that it was your mother, as well - not your father. I can imagine the shock the SJ brass got when they had /female/ applicants to this kind of serious education. Perish the thought, right?
e: As a Norwegian I read the original version, thanks for that!
It sure has changed since 1969. Not a single mention of Story Points, or Sprint Retros, or Poker Planning or T-Shirt Sizing. Poor saps, stuck spending all their time doing programming instead of planning and ceremony.
No mention of all the long complex design documentation before you did anything either. All those things you mention are individually more valuable than the formal design documents I used to have to write before doing programming.
Note that my team gave up on "Story Points, or Sprint Retros, or Poker Planning or T-Shirt Sizing" years ago.
I still do estimates at times, but they are in days since that is really what everyone wants anyway. Likewise I still do design documentation but only the amount that is needed, and the design is very different from those formal documents we used to have.
GP means has our understanding and perspective of how programming was done in 1969 changed in the last half decade, or do we pretty much believe the same things about it.
Vindication for Alan Turing and the computational analysis done for the Apollo Program have certainly reached a wider audience in the last ten years. They have certainly changed substantially since 2000 for the general public.
She'd be right at home in the modern job-hopping work environments.