Honeywell's marketing strength was in commercial data processing so we were not a mainstream project. My whole career with the exception of a horrendous 6 months was with non-mainstream projects. This helped knit together the team because we had to stick together. At one point a few months into the project we were called into a meeting, I noticed that Hugh, a nice brilliant older fellow that was part of the project wasn't there. It turned out he had died during the night. This was quite a shock to all of us and helped knit our project together a bit more.
This project had just been started in the Scientific Programmming department to build a compiler for the Honeywell 800 (an odd machine with 3-address instructions, 48-bit words, multiprogramming built into the processor, and extremely good tape drives). My assignment was to build the code generator. The project leader, Ned, was very good and had done the overall design - which was a good thing given my lack of experience. After a couple weeks of training I jumped in.
Our team had Sal, the evil assistant department manager and Tony writing the first pass of the compiler; Barbara writing the subscript generator, Lou doing the optional optimizer (which never really worked very well) and I was the code generator. There were several other people doing the loader and the runtime I/O and other runtime support. Sal's code was awful and had errors whose existence he denied so I had to do a lot of fix-up to the input to correct his bugs; this was much easier than arguing with him. On the plus side he had a pirated copy of the original optimizing compiler written by IBM for the 701/704 which was quite useful. (Several years later some underground work by several of us exposed him, got me into a bit of trouble, but resulted in his being fired).
These were the days before disk drives and lots of memory so the intermediate representation of the first pass of the compiler had to be written on tape (actually the subscript info was on a second tape) and then read back by my code generator which produced relocatable programs on another tape which was then processed by the program loader. One of the things that we discovered was that it took more time to rewind the tape (which didn't have much information on it) than to read it or write it since part of the operation involved moving the tape drive head out of the way so that it didn't touch the tape during rewind.
Our solution to this was for the code generator to read the tape backwards (this was a unique capability of the Honeywell 800 tape drives which was extremely useful in speeding up tape sorts). And thus the code generation was from the end of the program to the beginning so the compiled program was placed on the tape backwards. The program loader then also read the tape backwards to load it for execution. In Fortran the common practice was to compile a bunch of related programs and then link and load them in order to run the resulting program. Prior to compiling these programs we would write a copy of the runtime library onto the run tape and the loader would then select the needed ones.
Another problem was that the operating system that the compiler and compiled programs were supposed to run under was awful. It was designed to run prescheduled batches of business programs and not suited for the Load-and-go style that Fortran Users were accustomed to. So we just wrote a copy of the OS onto tape and took control of the machine and eventually restored when all the Fortran Jobs were done.
The system was written in assembly language. We wrote our code on forms and gave them to the key-punch operators to prepare cards. An hour or more later you got the cards back, printed them, desk checked and then stood in line at the one programmers keypunch to make corrections. Then you put your card decks in a tray and someone took them to another building to run them. Several hours later you got your card decks back, printed listings of the programs, and dumps of whatever you had run. Occasionally something went really wrong and you'd get back 3 boxes of paper with such helpful information as error or 10101010101.... written on every line of the 1000's of sheets of paper. I worked 6 days a week; we were paid overtime so I made a lot of extra money. The gold standard of a good programmer was that your monthly salary was more than the monthly rent of a tape drive (~$1200)
With little experience, good brains, and with Ned the project leader, I learned a lot of stuff that might well be taught in a computer science course. I invented a macro processor to generate code for built-in functions. I also wrote a reverse assembler to generate readable representation of the generated code - this was much easier than reading the octal dumps of machine code and figuring out if it was correct or not.
Honeywell's marketing strength was in commercial data processing so we were not a mainstream project. My whole career with the exception of a horrendous 6 months was with non-mainstream projects. This helped knit together the team because we had to stick together,At one point a few months into the project we were called into a meeting, We noticed that Hugh, a nice brilliant older fellow that was part of the project wasn't there. It turned out he had died during the night. This was quite a shock to all of us and helped knit our project together a bit more.
We completed the first release in about 1 1/2 years. Actually I remember that management was so anxious to get it out on-time that we released a version that we knew wouldn't work and assumed that in the several weeks it would take to actually get it to customers we would have the fixes done (we did). Then as soon as we released these bug fixes we had to do documentation. So I and others drew flow charts (the theory is that these had already been done as part of the design) and wrote narrative descriptions. Then these were sent out to be professionally drawn and typeset. Five months later I got back the finished copy of this documentation. By then it was obsolete because we had made lots of changes. I asked about submitting documentation changes and was told that we couldn't do it because it was too expensive to produce. Of course no-one read the documentation because we were the maintainers and the field support people who were one of the intended audiences had no need for it anyway.