A Junior Engineer's Tale from 1990s Japan
It might seem odd for me to discuss the "man-month rate" at this point in time. This has been a topic covered by prominent media like Nikkei Business for years. The most notable work, "The Mythical Man-Month: Essays on Software Engineering," published by Fred Brooks in 1975, remains relevant today. This speaks to how deeply rooted the challenges in software development are. Personally, "Peopleware: Productive Projects and Teams" by Tom DeMarco and Timothy Lister, which I read in my younger days, left a lasting impression. It's another excellent work that remains relevant in modern times. I strongly recommend young engineers read it.
However, documenting my experiences might serve some purpose for future generations.
A Junior Engineer in the World of System Development
Encountering the Z-80 Assembler
My entry into the IT industry began with Z-80 assembler work. At that time, it was just a part-time job, and the work was purely programming. In middle school, I had written programs on report paper, hand-assembled them while referring to code tables, and entered them using the MON command, only to watch them crash. For someone like me with only that experience, "macro assembler" was shocking. Variables could be used in assembly language. You didn't have to manage labels yourself. That's when I learned what professional programming was like.
Eventually, this project fell through, and I only received partial payment. It was a control program for communication antenna equipment to be installed in mountainous areas, but the project was canceled, and it seemed we were cut off by the prime contractor. I still remember the expression on the president's face at that time.
Entering the World of UNIX Workstations
A year later, during my leave of absence from university, I joined a company as a part-timer where we developed systems in C language on Unix workstations. What I learned at this company were the manners of being a working professional and the customs of the IT industry. As a student, I truly knew nothing. The media called my generation "shin-jinrui" (new breed). We were a generation that was lamented for not understanding common sense.
It's amusing to think that generation is now turning 60, and we're talking about younger generations (laughs).
Development Environment in the Early 1990s
Learning to Be a Professional
When asked to answer the phone at the company, I didn't even know how to do that. I was taught to say a formal greeting when answering, but I questioned why I should say such things to someone I didn't know. It took about a week until I could comfortably use proper business phone etiquette.
Years later, when I started my own company and hired young people, I still remember being asked the same question.
And then there was another thing I learned: the unit called "man-month."
Development Environment and Technical Stack
Upon joining the company, I discovered several things:
- Work was broadly divided into dispatched work and contracted projects
- Dispatched work dealt with financial systems, while contracted projects were for control systems
- Financial systems used COBOL or PL/I, while control systems used C language
- Financial systems ran on mainframes, while control systems operated on workstations
Until then, I had mainly programmed on personal computers and pocket computers. I occasionally used mainframes at university terminals, but that was mainly FORTRAN, with Prolog just for fun. At work, it was C language on workstations, and the Unix system I had dreamed of using.
However, senior engineers stubbornly refused to use workstations, preferring to work on their PCs. I wondered how this could work, given the minimal compatibility between MS-DOS + MS-C and Unix + C.
The reason was simple: senior engineers had never used Unix and didn't want to start. After all, the workstation manuals, when stacked, reached nearly 2 meters in height. They didn't want to bother reading all that.
I struggled with those towering manuals while setting up the development environment. It was my first time using shell and vi. It took two days just to get the Makefile working.
Come to think of it, my senior used MIFES, one of the popular text editors for MS-DOS in Japan at that time. Probably didn't want to learn vi. I believe they continued writing programs in their PC editor and transferring them to the workstation via floppy disk. Each transfer required character code conversion between MS-DOS and Unix systems - similar to how programs needed conversion between EBCDIC and ASCII when moving between IBM mainframes and other systems.
My job was to create and debug programs according to the provided design documents, which were called functional design documents. I later learned that we were supposed to create detailed design documents from the functional design documents and then code from those. The detailed design documents turned out to be flowcharts, and I remember hand-drawing flowcharts from the source program before delivery. I recall receiving a special flowchart ruler from the prime contractor. That was quite handy.
(To be continued)
Top comments (0)