17 ms·

Working in the software industry, circa 1989

418 points by firstSpeaker 4y ago

dnissley 4y ago
Hey Jim, it's nice to see a familiar face around here. We crossed paths (extremely briefly) at Angie's List where I was "that one guy working remote from Chicago".
- mobilene 4y ago
  O hai Dylan! Nice to see you here!
Rodeoclash 4y ago
I love these stories. I got my start around 1998 when the web was coming into full force which was only a decade after this and very different. Things were changing quickly in that era. The closest I've had to this was working at a company that had been around for close to thirty years and had kept many of the original developers (they'd taken the product from a terminal interface to the web, from cobol to c#) and had many stories like the one in the original post.
- sillyquiet 4y ago
  I started a few years after you, around about 2003. There were certainly pockets of industry that still operated exactly the same as the article described, especially defense and aerospace. Which makes sense, given working in embedded hardware (especially in classified contexts) back then came with a lot of the same limitations described in the article - software had to be delivered by sneaker-net, installation was burdensome, you couldn't just fire up the application for a quick bug fix at home, etc. Not to mention the inertia of having Always Done It That Way.
- Aeolun 4y ago
  I started about 10 years after, and I think that was almost the best of both worlds. Agile was starting to become a thing, but wasn’t perverted to sell expensive courses and credentials yet, and tooling began to be developed that was a serious improvement on what we had.
deleted 4y ago
[deleted]
KptMarchewa 4y ago
>To my astonishment I discovered that I loved to write, even more than I enjoyed writing code. I wish I was this person. I'm one of those (great majority of) people whose documentation you'd hate. I deeply hate writing like that because I can never properly explain my tangled thoughts. Even my comments on sites like that are at most few liners. Describing things in code is much easier, since you don't have centuries of context written into words.
- user3939382 4y ago
- FroshKiller 4y ago
  Your class names, variable names, and method names have plenty of centuries' worth of context in them anyway whether you like it or not, not to mention the comments and documentation. I think you'd benefit from looking at writing differently. What you describe--"I can never properly explain my tangled thoughts"--is the essence of composition. The goal of the process of writing is to untangle those thoughts and express them! When I say "process," I don't just mean that you begin typing immediately. Composition is about planning as well. Even if you spend just a few minutes making a list of keywords & important concepts then arrange them on cards in the order you think you should present them in, I bet it would help writing your initial draft of a document. If that doesn't appeal to you, so be it, but look into a composition course, because I genuinely think you could turn something you hate into something that helps. You might never fall in love with writing, but that doesn't mean it can't be a tool that solves problems for you.
- rozenmd 4y ago
  Just keep writing. It gets better.
  - spaetzleesser 4y ago
    From my experience it won't get better unless you put effort into learning how to write. Just writing is not enough.
theDaveB 4y ago
I started my first programming job, well trainee programmer in September 1989. Five people applied for the job and I ended up taking my TV and Atari ST to the interview to show them some stuff I had written in STOS Basic. Got the job and started with dBase II on Concurrent DOS.
- fjfaase 4y ago
  I also have some fond memories of writing a 'smart' algorithm in STOS Basic for generating Madelbrot fractals. And is still took hours to fill the screen.
  - theDaveB 4y ago
- SulphurSmell 4y ago
  I am surprised I had to scroll this far to find a dBase reference. I am the same vintage as OP, and yeah... back in the day dBase was the key to riches...at least as a contract dev. I remember spending A Lot of Money on the big box of dBase IV when it was released...all the diskettes and manuals. Around that time there was much talk about migrating from dBase databases (those .dbf files) to the magic of "SQL" which at the time meant nothing to me. Needless to say dBase IV cratered, and the industry went elsewhere. Good times!
  - theDaveB 4y ago
zeckalpha 4y ago
Note that the author is not https://en.m.wikipedia.org/wiki/Jim_Gray_(computer_scientist) https://en.m.wikipedia.org/wiki/Jim_Gray_(computer_scientist... I was surprised by the date of the article at first!
- mohanmca 4y ago
  Exactly I was bit confused, initially thought that I read one of his old writing. The legend is still missing.
- usr1106 4y ago
  I attended a lecture by him around 1990. Maybe I was not the Turing Award class of computer scientist, was not sooo impressed what he spoke about. Remember Parnas [1] approx. the same year much better. Around 1998 Gray had built something called TerraServer, must have been years before Google Maps or OSM. It was a real eye opener at the time to see my little house in the middle of nowhere in Northern Europe on the internet published for free by an American company. At the time PC disk sizes where still measured in Megabytes, so you weren't even able to store that many aerial pictures. At least not pictures of current size. Probably they were smaller then, don't have any data. Edit: [1] https://en.m.wikipedia.org/wiki/David_Parnas https://en.m.wikipedia.org/wiki/David_Parnas
darthcloud 4y ago
Similar to the blank tape story, around 7 years ago at a big networking corp a big customer needed the latest product to be in their possession before some tax related date. The new product software wasn't ready at all at that point, so we shipped them unit with a place holder FW that could do only one thing: FW upgrade!
josephd79 4y ago
Terra Haute, Indiana. The greatest smell on earth.
- mobilene 4y ago
  The trick is to live on the north side. The odor seldom wafts northward.
fjfaase 4y ago
I have been working in the software industry since 1990. In 1990, I joined a company that made innovative coupling between AutoCad and relational databases (Oracle). However, I wrote my first program in 1978 in Algol 60. I also used Fortran, LISP, (Turbo) Pascal, BASIC, and 6502 Assembly before (in 1990) starting to develop software in C.
- fjfaase 4y ago
  I remember that one day at this company, we had just got a MicroVAX system, when I there was someone at the door with a europallet. We wondered what it could be. Turned out it was the VAX/VMS documentation that belonged to the MicroVAX. It took more space than the system itself.
  - SulphurSmell 4y ago
    Shelves and shelves of tidy orange binders. I had them too!
theletterf 4y ago
Lovely story. As a fellow technical writer, I was glad to see you entered tech from that door. Edit: The author will probably smile at this post: https://news.ycombinator.com/item?id=30365800 https://news.ycombinator.com/item?id=30365800
- mobilene 4y ago
  Thank you! I enjoyed writing those behemoth 300-page manuals. The tech writing world has changed so much since those days!
tragomaskhalos 4y ago
Being the same vintage as Jim, much of this brought back memories. There really wasn't any such thing as a tech stack - our company would produce software for various Unixen and, especially, Vax, and the language was alway C, with some Pascal on the Vax side (as, I was told, the Vax Pascal compiler produced far more optimal code than the C compiler). Being a software engineer was like being a furniture-maker. You had to master a small number of tools - the saw, the chisel - and then craftsmanship consisted of discovering an affinity with these tools and a love of getting ever more skilled at using them. This path wasn't for everyone, which was fine - plenty of management and other non-tech roles for those folks - but if you grooved with your tools it was a real joy to be able to move from chair- to table- to cabinet-making and carry and refine your skills as you went. This idyll could not last, however. Before too long it became uneconomical to make furniture this way, so for your chair making project you instead had to learn how to run a chair-making machine. When you moved onto a tables project, the machines there were infuriatingly dissimilar to the chair-making ones you'd just mastered. Worse still, moving back to chair-making after a year or two, you discover that the old machines you knew are now obsolete and you have to re-learn how to run their replacements. This stops being fun, or interesting, after a while, and yet sadly it's all that most younger software engineers know. Occasionally, there is the need to make some shim or gizmo that the machines don't cover, so out come the trusty saw and chisel of yore - much to the amazement of the young'uns, who are astonished that an old-timer can still wield these antiques so effectively.
- joshowar 4y ago
  As a youngster who has had to pick up a saw and chisel to repair an old chair, I think you're looking back with rose tinted glasses a bit. I've never been astonished by legacy code, as much as bemused for the lack of object orientation, data normalization, etc. The technology changes of course, but there are advancements made in craftsmanship/techniques. There's some 'cleverness' lost probably, in the new ways vs the old. I've seen some pretty novel approaches to what should be simple tasks in legacy code. And I do recognize that for what it is. But as impressive as that cleverness can be, I think it's one of the reasons as to why a lot of legacy code persists and nobody wants to touch it. Among many other reasons.
gspencley 4y ago
> Even if we did see then (and we mostly didn’t) that small, frequent releases were better in a whole bunch of ways, we couldn’t really do it. It was expensive to ship on physical media, and disruptive to our customers to have to do frequent installs. It's still disruptive to customers. As a software engineer I love CD/CI. It makes the entire process much smoother and more efficient. As a customer / end-user, though? Nope. I absolutely hate it. Maybe I'm just getting old but I'm extremely nostalgic for the days where I got to decide if I the upgrade was worth it to me or not. These days things will change and move you on without any notice or opt-in what-so-ever.
- LAC-Tech 4y ago
  Sometimes when I play a retro game, I'm completely in awe of programmers of that vintage. Games took a year or two to make, on massively constrained hardware, in assembly language, with no engines, all original artwork and music, and no bug fix updates after it was complete. People like to pretend the future is always better and everything is advancing, but surely they had more talent than we do.
  - BlargMcLarg 4y ago
    I feel like you're cherry-picking. Games have gotten way bigger content-wise and way more intense in many design aspects. Many retro games had massive teams and utilized earlier frameworks and content to release faster. There are many old school techniques which are amazing and quite a few talented developers, but I wouldn't make a sweeping statement that "they" had more talent than "we" as a whole.
    - gspencley 4y ago
      It's funny, though. Maybe it's just my age and not a comment on the quality of games, but I don't even play newer video games anymore. Every once in a while I'll start a game of Civilization IV (from 2005) if I have a lazy weekend and need a change of pace. I played a lot on the PS3 and then my PS4 was a dust collector. Complete buyers remorse there (and don't get me started on the fact that I needed an Internet connection on first boot to set it up. WTF?!!?!!!) And I'll still sit and play Tetris for hours and hours and hours on my retro NES. The newer versions, not so much. I've had this sense over the decades that as video games have grown in scope and graphics they've gotten less fun to the point where I tell people when they ask me "I don't play video games." It's probably been about ten years since I've paid for one. Now get off my lawn.
LAC-Tech 4y ago
Not so sure about the development/testing split of the waterfall, but two months up front just to design and gather requirements... feel like that might be a net benefit! Waterfall up front, party in the back?
- beckingz 4y ago
  Call it hybrid-agile and let's make bank consulting it.
- jdlshore 4y ago
  It sounds nice, but in reality your requirements end up being a castle in the sky. My team once spent 6 weeks for a small project (I was the team lead) creating a detailed requirements document with screenshots, a prototype app, etc. My users were all at hand and I showed them the prototype. They all agreed that it was what they wanted, and signed the requirements doc. We spent several months building the application. When we shipped, the software was unusable, because a security feature that we had been explicitly told could wait for the second release turned out to be essential. We also ran into a big problem with concurrent editing that no one had considered in advance, and blew up our carefully-created design. The solution to changing requirements isn’t to nail them down, because that’s effectively impossible, but to get better at evolutionary design techniques (introduced by Extreme Programming) so you can adapt to arbitrary requirements changes without disruption.
vt85 4y ago
antiterra 4y ago
It’s curmudgeonly, but I can’t help but bristle a bit at the ‘we didn’t have _____ when I was a programmer’ stuff because it very often existed in some substantial form. Case in point, UI/UX- You could have user interface design as a job back then, perhaps at IBM working on ATMs. UI philosophy was a significant part of what was done at Xerox PARC, and you can read a 1989 article by Alan Kay on the topic: http://worrydream.com/refs/Kay%20-%20User%20Interface,%20a%20Personal%20View.pdf http://worrydream.com/refs/Kay%20-%20User%20Interface,%20a%2... In 1988 the first edition of the Handbook of Computer Human Interaction was published, a staggeringly expansive book on the subject, which included stuff like rapid prototyping, user acceptance and design review. Sure, plenty of companies didn’t bother with this added expense, but that’s still the case today. The idea that it wasn’t there at all is misguided. Another bit that seems off is mention how Java was ‘a total game changer’ when it came out. Cross-platform development was an exciting idea, but in practice, everything with Java was dog slow for quite a while. The true and eventual potential of the JVM was still opaque for years after the 1996 launch.
- drewcoo 4y ago
  Xerox PARC was doing bleeding edge work. To compare anywhere else at the time with their revolutionary innovations, to claim that those companies just "didn't bother with the added expense" is absurd.
  - antiterra 4y ago
    PARC was so on the bleeding edge they were doing this stuff in the 70s, by 1989 there was definite influence.
- buescher 4y ago
  "Alls we had was waterfall" rankles too - and maybe it's just me but I've been hearing it a lot the last couple of years - particularly when most people first heard about "waterfall" was when someone made them do SCRUM. And by 1989 OO was obviously the right thing for graphics and graphical user interfaces were arriving in a big way. MacApp was four years old. The original NeXT workstation had launched the year before. "niche" only in the sense that Turbo C++ was a year away. https://en.wikipedia.org/wiki/MacApp https://en.wikipedia.org/wiki/MacApp
trumbitta2 4y ago
The last paragraph story is so "Lean Startup" I'm crying
- leohonexus 4y ago
  Or, it is what any half-competent witty student would do when they couldn’t finish their essay in time - send a corrupted .docx file and blame Moodle :)
beckingz 4y ago
The section about waterfall being the only SDLC is interesting because it touches on the economics of shipping and software engineering practices: Continuous delivery only makes sense if the value of new feedback and delivered software is higher than the total cost of delivery. If you have to mail a floppy disk to each customer, that's a lot more expensive than just updating your production servers.
KingOfCoders 4y ago
"UX design wasn’t a thing yet" On my Amiga UX/UI design was a thing, layout, settings pages, forms, GUIs that did scale with different font sizes. At least for some companies, some UIs had horrible UX though. Like when they added shadow to text labels. On my CPC I wrote a GUI library with auto layouts and muli step flows woth |RX (?) commands with characters like ┤ [1] for borders - always reading Apple magazines. ┌╴╴╴╴╴╴╴┐ │ Title │ ├╴╴╴╴╴╴╴┤ │ Yes! │ └╴╴╴╴╴╴╴┘ [1] https://en.wikipedia.org/wiki/Amstrad_CPC_character_set https://en.wikipedia.org/wiki/Amstrad_CPC_character_set
- mobilene 4y ago
  Good point about the Amiga. Someone else here commented on Xerox PARC. So yes, there was UX design. However, in so many companies like the one I worked for in the story, it was utterly ignored.
ChrisMarshallNY 4y ago
That brings back memories... We also tended to have long-term stays at companies. We usually had to maintain the software we wrote, so it encouraged us to at least leave some decent documentation breadcrumbs.
- ghaff 4y ago
  >We also tended to have long-term stays at companies. I was at a minicomputer company (DG) from the mid-80s until the end of the 90s. Mostly PM for hardware. A lot of engineers had been there for a long time. Even more so, people in support functions of various types. There was one woman who I think may have been the only person who knew our BOM and related systems inside out. I think there are still a few people I worked with who are still there (by way of EMC and Dell). At least as of a few years ago, one of them was one of the engineers who worked on the computer that was chronicled in Soul of a New Machine.
jleyank 4y ago
Graphical vector mini-supers. Unix and vax environments, with SUN ruling the roost and SGI crashing in. Multiple instances of what became things like knime. X11 and multiple vendor-specific gui toolkits. Excellent vectorizing compilers for Fortran and C. 4 and 8 core multiprocessors. Granted, it wasn’t as fast but there was lots there which people probably forget. Software wise, there were research groups with all of the ml/ai areas in chemistry (Gasteiger, others) so I assume they were active elsewhere. The quants were starting upon Wall Street and they needed visualization systems to know whether their model is going up or down. Stereotactic imaging for medical uses, fluid dynamics and finite element analysis were leading to changes in car and airplane design, Microprocessors killed off this ecosystem - the pa-risc chip from HP could be a soft pc faster than a 486 could be a pc. But don’t think it wasn’t there. Hell, all of the foundation was laid by (mostly) hackers in the 60’s and 70’s that were building on now. It just used way less memory :-) And don’t forget the work from the folks at bell labs. And neat stuff like the blit.
kgarten 4y ago
tangent: my mind went to a different Jim Grey https://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29 https://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist... (the ACID properties database guru) The about page of the blog does not tell me much about the author (it would have been nice to mention some projects or other milestones).
- sokoloff 4y ago
  I went to the same place, making this comment thread all the more surreal: https://news.ycombinator.com/item?id=32057986 https://news.ycombinator.com/item?id=32057986
jjav 4y ago
> There was no working from home. The minicomputers were available only on the in-office network. I think it was not technically impossible to connect them to the Internet, but at home we all had only dialup access. Not only would speed have been a concern, but the family wouldn’t enjoy having the phone tied up for hours while you worked. I was lucky in that I got to work remotely from the beginning. Late 80s at the university I set up a modem bank to one of the UNIX boxes and installed a second phone line at home, so I was dialed in pretty much 24x7 (at 2400 baud, of course, but with an all-text terminal session it's fine and usable). At first job they had dialup into the Sun servers as well, so I often worked from home (by now at 14.4 and later 56K at which point remote X was doable).
jmclnx 4y ago
>Every last software engineer at ACD was a white man Interesting, where I was at the time, it was a 60/40 split between men and women. Also I would say 10% were people of color. And one person was completely blind. Two of the smartest people there were people of color, early on (before 1989) I learned a lot from them. This was in the northeast
- krallja 4y ago
  When you say “northeast,” do you mean more like Boston, NYC, or Kennebunkport?
  - jmclnx 4y ago
    at that time, boston
- mobilene 4y ago
  I do acknowledge that my experience was a sample space of one!
  - mixmastamyk 4y ago
    I think this statement goes too far in that case, I'd walk it back: > The software industry was a far less diverse place then. It probably makes sense when talking specifically about the midwest, due to demographics. But out here in SoCal in the 90s, I had a south asian boss and foreign national engineers from a number of countries working side by side. China, Italy, Norway. It was a big facility and we had US minority employees as well, although not a huge number. Software dept was 1/4 women approximately. Re: being gay it was the "don't ask, don't tell" days. No one I knew cared in the least. An interesting angle is I wasn't perceptive about it as a young person. Looking back in the hindsight of maturity, obviously gay people were everywhere. Just like in Hollywood, everyone just winked and nudged. Right, Uncle Arthur is ~fifty, unmarried, and rather flamboyant, nothing to see here. ;-)
- nostrademons 4y ago
  It's interesting, my experience at a FANG (which invests heavily in recruiting women engineers) is that approximately 25% of teams are 60/40 men/women, and 75% of them are 100% men. The women I've worked with have told me that this is not a coincidence, that they very quickly learn which managers they will not work under or which coworkers they will not be on a team with, and that they take the presence of other women on the team as an indicator that none of these characters are present. I wonder if the same principal operates geographically - certain regions find that they just never encounter women or minorities in the workforce, and it may have as much to do with the region as the people.
wazoox 4y ago
My very first programming job was in 1991 or 92 writing an interactive kiosk based upon a touch screen driven by an Amiga, using the multimedia platform Scala (quite similar to the later Macromedia Director, but it still exists). Then with a colleague we developed an interactive phone application (the sort that asks you to "press 1 for this, press 2 for that, press # to go back to the menu") on a SCO Unix system, in some sort of weird BASIC. While one of us tested the application on the phone, the other one played "X-whack-a-mole" :)
hunglee2 4y ago
wonderful writing - looking forward to pt2!
krallja 4y ago
I got my start in the software industry in that building, too. I was an intern at Rose-Hulman Ventures in 2005, building tax administration software for Indiana counties in C# 1.0 WinForms with Visual SourceSafe and Microsoft SQL Server. VSS required you to take a lock on a file to be able to edit it (there’s no merge ability) so I spent a full afternoon one day separating our data access layer class into partial classes so it would be spread across multiple files, and more than one developer could write a stored procedure wrapper at a time! Likewise, our bug database also only had enough licenses for one or two people to be logged in at a time, so we printed out our tickets to work on them. Learned a lot that summer, especially the fundamentals of databases and software architecture. Also learning C# that early gave me a ton of experience and willingness to work with C# again in my next few jobs.
- nobleach 4y ago
  Well, you survived using Visual Source Safe. (I've lost so much hard work with that tool). I worked on stuff one generation before C#. Visual FoxPro was my money maker for awhile.
  - krallja 4y ago
    We had a “robust” backup strategy. (Taking a copy of the source code onto the file share every night.) Definitely lost VSS revision history at least once. I don’t know how VSS ever made it to customers!
- int_19h 4y ago
  But partial classes didn't show up until C# 2.0?
  - krallja 4y ago
    You’re right, I misremembered! I made a hideous inheritance chain instead: abstract class UserDAL { } abstract class ParcelDAL : UserDAL { } ... abstract class DAL_n : DAL_n_minus_1 { } class DataAccessLayer : DAL_n { } each in their own file, of course. I tried to give them descriptive names and very narrow scopes. But inheritance is pretty dumb here. What does it mean for ParcelDAL to extend UserDAL? A parcel is not a user. When C# 2 came out, I was able to get rid of the inheritance and make them all part of one big partial class, keeping the file names the same.
no_wizard 4y ago
Thing I hear from a lot of software engineers from the time-frame of 1980-2000 is how much software engineering - to engineers at least - was about the craft. It was all about the craft of making good software. People invested real energy into trying to do it right, and treated it as such. This is of course likely colored by experience and "rose tinted" glasses, however, I think we as an industry have let this go, especially since the rise of bootcamps. It just isn't about the craft anymore, its all about "hustle". There is some truth to the fact that engineering in this time there was more caring about it as a craft, caring about performance, caring about shipping quality etc. I like thinking about things as a craft, I don't always like the "hustle" aspect that is pervasive now, it guarantees shipping too early and never taking quality & craftsmanship seriously, I feel like. I want to work somewhere again that sees engineering software as a craft again.
- travisgriggs 4y ago
  > I want to work somewhere again that sees engineering software as a craft again. If you find this place, will you tell me? I will come work with you. I admit though, that I struggle to codify what “coding as a craft” is. And that worries me. I fear I am really just playing a game of “I’ll describe it when I understand it” up-over-that-next-hill-ism with myself that is illusory and delusional.
  - TedDoesntTalk 4y ago
    > I struggle to codify what “coding as a craft” is It means working with people who care about the quality of their work.
    - pdxandi 4y ago
      Does caring about the quality actually mean the quality is good? Maybe it doesn’t even matter. If the team cares and they are satisfied with what the quality of what they are building, maybe that’s enough?
      - 4y ago
gbronner 4y ago
I saw the 'blank CD / oops our shipping department screwed up' trick in 1998. I think it was used to recognize revenue in an earlier quarter for a release that wasn't quite ready yet, but where they wanted to have a nice hockey stick growth curve. I think it eventually cost a VP his job though.
gnfargbl 4y ago
This made me chuckle: > Then someone had a brilliant idea: we would ship US Sprint a blank tape with our usual letter listing the changes in the release. ...preceded by... > Our relationship with US Sprint was always iffy, and one day we pissed them off one time too many and they canceled their contract Well, yeah. If your company depends on a small number of large customers, you really can't get away with pulling nonsense like the blank tape trick on them. People aren't idiots.
- wging 4y ago
  That Monday deadline seems to me like they were searching for an excuse to end the relationship.
- fmntf 4y ago
  This old trick is still in use nowadays. However, instead of shipping a tape I have seen a colleague uploading a zip corrupted by hand, just two gain a couple of days of bug fixing.
swyx 4y ago
> "The software engineering team had two titles: Software Engineer and Senior Software Engineer. This was typical in the industry. You had to have at least 10 years of experience, but more likely 15 years, as a Software Engineer before being considered for promotion to Senior. The bar was higher for Senior then, too. I’d say a Senior engineer back then was skilled and experienced more like a Staff or Principal engineer today." amazing to see that the title inflation in our industry has roughly matched actual economic inflation :) on a more serious/optimistic note, there is a lot more tech to learn today than in 1989, and we probably learn at a faster rate too given the available amount of material (HN, youtube, books, etc). so perhaps not unwarranted. i'd love to pit a senior engineer of today vs a senior engineer of 1989 in doing modern programming tasks.
- mywittyname 4y ago
  > amazing to see that the title inflation in our industry has roughly matched actual economic inflation :) Why should there be only two categories of developer? Most trades have at least apprentice, journeyman, and master.
- brunooliv 4y ago
  I suspect that the ones of today would have a mental agility and/or capability to discover things on the fly that simply weren't possible all those decades ago. I think it's only at the real low-level or hardware/assembly or, for instance, a bit above the stack, say, optimizing a data model or fine-tuning a DB engine for a given domain, that the old timers would really shine. I see it in my daily life: my dad was a Fortran programmer way before I was born, so, maybe you know... 1970s or something like that. He was actually very good at his job, getting a research position doing some serious programming work that was seen as groundbreaking at the time, doing some finite element modeling on extremely resource constrained environments, probably what we would call data-oriented programming today, but taken to its extreme.... However, he didn't really keep up with programming after a few years, shifting to MATLAB based tasks for some university courses he lectures... and I feel that the complexity of today is just too much for him to grasp as it was. It's just too many moving parts and too many layers of abstraction to sift through. By the same account, I expect your typical developer of a regular company, myself included, seniors included, etc, etc, to be completely lost if they had to optimize code for a given hardware and needed to write some assembly, or whatever, disassemble some JVM class files, etc.
mikewarot 4y ago
Back then I wrote a program to manage the inspection of Fire Equipment at Generating Systems, by myself, in Turbo Pascal. The inspections were recorded on Hand-Held computers (oooohhhh!) made by the Norand company in Cedar Rapids, Iowa. I wonder how well that code would hold up to modern scrutiny. Here's a clone of TECO[1], which I fell in love with at Rose-Hulman, in Turbo Pascal, as a sample of how I wrote things back then.... roast away [1] - https://github.com/mikewarot/teco https://github.com/mikewarot/teco
smm11 4y ago
I was in that Token-Ring world back then, and the terminator clip at the end of the chain was the bane of my existence. Our System 6 and 7 machines had to talk to everything, VAX and PDP and DOS and anything else that communicated over serial. The WWW was a rumor then a thing, and it was fun to click around on Gopher, but you couldn't find anything you could really use.
lordnacho 4y ago
What's the deal with the machines having to start up in order? How did that come about?
- mobilene 4y ago
  Memories grow dim after 33 years - I don't remember. It do remember that it didn't totally make sense to me at the time.
  - Clubber 4y ago
    I would guess they are dependencies. For example you would want to start the database server before you started the application. If the application started with no databases, it would do some funky things and may end up in a weird state.
scrubs 4y ago
I lived and worked throughout Berkeley, San Jose, Cupertino, Marin County from '80-'95. I've been in the original Apple office. I remember 280 before all the CISCO and Oracle buildings went up. I have my share of stories. Still I feel like us old guys have got to have more on the ball for the new-comers than (i) memories (ii) rants about how it used to be. A psychologist once pointed out old people go to memories if they've got nothing going on now. I like Warren Buffet's line noted for not investing in tech: I might be old fashioned but I'm not old fashioned stupid. Part of having gray hairs is to know what was stuck-on-stupid then, and not repeat it now. Part of having those gray hairs is a Peter Drucker take on business: factual, direct, and unsentimental but not mean. The future (i.e. today relative to '89) isn't always better.
- mobilene 4y ago
  You're right, but there's also room for an old guy to reminisce on an anniversary.
- mlyle 4y ago
  Meh. I'm a decade or two younger than you, and I've got plenty of stuff going on, but I'm still so drawn to sentimentalism. I miss workstations and the feeling of quality. I miss slapping in a router and having connectivity. I miss the sheer degree of early 2000's brogrammer tomfoolery. I miss BBSes and local community. I miss usenet. I miss the sense that IPC and single thread performance was gonna increase forever. I miss having a T1 to my apartment and playing with frame relay and Serious HiCap Telco Circuits (tm). I miss HalTed and the maker movement before we called it a maker movement. Man, we've got such great stuff now. I've got a home 2gbps PON link and 10 gigabit ethernet everywhere and plastic crappy machines that are 20 million times faster than that decked out SPARCStation 20 and more IOPS than I could have ever imagined. But why'd it have to eat all the best parts of those things? (I know why, but that doesn't mean I have to like it...)
  - eps 4y ago
    Yeah, the whoomp of a CRT monitor powering up, the sound of a modem handshake at 2am and the flex of 5" floppies. Good memories of times never to return. But that's just nostalgie.
pjdemers 4y ago
>> we would ship US Sprint a blank tape with our usual letter listing the changes in the release. And so we did. I worked for a company in the same era that did the exact same thing for a late release.
botswana99 4y ago
...and how much is still the same today: coding on networked UNIX machines with TCPIP, C and its variants, emacs, etc. Also, software engineering is still mostly male.
brian_herman 4y ago
Wow this is a great story thanks for sharing!
imiric 4y ago
Fascinating read, kudos to the author. I hadn't considered that token-ring networks had the limitation that all nodes had to be online for it to work, but it makes total sense. We're so spoiled these days. :) And that last idea to ship a blank tape to buy you time is pure genius. Reminds me of the high school / undergrad tricks of submitting a corrupted archive or document on the deadline date. It bought you at least a day or two before the professor noticed, and by then you'd hopefully be finished. Not that I ever partook in such reprehensible behavior...
deleted 4y ago
[deleted]
eternalban 4y ago
> The software industry was a far less diverse place then. Every last software engineer at ACD was a white man, most of them younger than 35. QA was much the same except for one young woman on the team. counter point: My 2nd job in the field, 1990, NYC, software development firm, reported to a Chinese-American woman (Cooper Union grad) and the CTO was also Asian American. My ~mentor was a Bell Labs engineer with a luxuriant white beard (so way over "35"). I also had a private office that I shared with another engineer (a young white married guy who commuted from Philly). Q/A iirc had many Indian women.
- mobilene 4y ago
  I forget that I was in the Midwest, not on the coasts, and things were likely different in this regard on the coasts.
  - sammalloy 4y ago
    It occurs to me, that the one place you might see parity with the Midwest and the coasts in terms of a loss of diversity was in the composition of the graduating classes for compsci in 1989. I remember peeking in on one class in the Bay Area and there wasn’t a woman in sight. The majority of women I knew who were involved in programming at the time came from a background in business administration. I think it’s true that the workplaces on the coasts were decades ahead of the rest of the country (women, minorities, LGBT), but academia was still far behind in terms of inclusion like the rest of the country.
WalterBright 4y ago
> Every last software engineer at ACD was a white man, most of them younger than 35. Not true in the company I worked for at the time. We had many minorities, women, and even some up into their 50s.
WalterBright 4y ago
I don't miss CRTs at all.
gwbas1c 4y ago
> Then someone had a brilliant idea: we would ship US Sprint a blank tape with our usual letter listing the changes in the release. And so we did. > “Oh! We are so sorry. We can’t imagine what must have gone wrong! We will send you another tape today.” Those games are so common no one really falls for it. They might be polite and not call your bluff, but you can bet they know. (And I suspect that this was the "straw that broke the camel's back" for Sprint.)
divbzero 4y ago
> That led us to create enormous Gantt charts (printed dot matrix) that we’d tack onto a huge wall, and use them to track plans and work completed. It never failed that during the first week of coding we’d discover something that we didn’t think of in the design phase, and we’d have to replan the entire project and print all new Gantt charts. We did this over and over every project. I’ve only ever worked with “modern” agile approaches to software development. Gantt charts feel like a mismatch with the speed of software development, but sometimes I wonder if there certain software projects where Gantt would work better than agile.
- misterbwong 4y ago
  For software, the usefulness in Gantt charting seems to lie in the visualizing and mapping project dependencies and rough ordering of milestones. Where most get it wrong is in believing that the date at the end of the chart is anything more than a very rough estimate
deleted 4y ago
[deleted]
lampshades 4y ago
Worked at a company a few years ago that was still using Classic ASP for some projects. It was not supported by Microsoft at this point, which is saying something, and I’d be surprised if the project was ever sunset. The software development process sounds all too familiar, i.e. hundreds of bugs in QA, long releases, long release cycles, death marches, and burnout. Fun stuff. This cultural mindset permeated the entire organization. Even for projects using new technology, we were coupled to this legacy project and our processes always devolved to what it had created.
UncleOxidant 4y ago
I am of a similar vintage. Technically, I was in hardware/firmware in '89, but I was working in a startup then and the lines were pretty blurry - I wrote a good bit of assembly & C code. One thing that I notice was that even though there wasn't really any sort of formal push to get women into tech back then, the software group was pretty close to 50% women where I was working in the late 80s - in fact, for a while there were more women than men in the group. Similar at the next couple of companies I worked in software into the mid-to-late 90s - maybe not 50% women, but pretty close. But then in the aughts that gender distribution tended to skew more towards males. Not sure why that was. And now I'm working in a startup where it's about 40% women, so maybe we're getting back to where we were in the late 80s.
stormking 4y ago
Ha! I've used that last trick a couple of times when stuff was over-optimistically promised "today, end of business", sending out random bytes renamed to .zip and having the real file ready next morning when people complained about not being able to open yesterday's zipfile.
sgtnoodle 4y ago
If this sort of computing history interests you, I just finished reading, "Hot Tech, Cold Steel" https://www.amazon.com/Tech-Cold-Steel-Computer-Aided-Manufacturing/dp/173715370X https://www.amazon.com/Tech-Cold-Steel-Computer-Aided-Manufa... It's interesting how the company, MDSI, started on 8-bit timeshared mainframes, then eventually ported their software to newer platforms using a combination of emulation and microcoding. I happen to know Chuck from my years racing solar cars in college.
RickJWagner 4y ago
Brought back great memories for me-- I worked in Terre Haute in the early 90s. My shop was at a local bank. We were a little more diverse-- we had some ladies working in the shop, and an African-American male also. (And several older men.) We worked hard, running a mainframe/COBOL shop. Some late nights (batch processing was king then!) and some great teamwork. Good memories.
berkeshire 4y ago
1995 India - Had a paid internship (Rs 2500 per month or ~ USD 80 back then) with a small software company that worked on FoxPro + dBase. A very diverse team (gender ratio), the highly enthusiastic bunch created software for non-banking financial companies. A thick documentation book occupied most of the space in the large, laminated box that such development software came in. Along with half a dozen floppy disks where we hoped that no disk would have a bad sector. Requirements were constantly over the phone from clients and shipping software meant taking two sets of floppy disks of different brands (backup!), in-person, to the city where the client was. CRTs needed a warm-up time and we had a small diesel generator (hand cranked) to power up the x86 computers once the main power line crashed (which was frequent). No internet searches, no help other than that thick paper manual or waiting around for hours for a senior engineer to get free to help you out. College taught us C and Pascal on Unix. That seems so far away from the world of microservices and SPAs. </nostalgia>

418 points by firstSpeaker 4y ago

Hey Jim, it's nice to see a familiar face around here. We crossed paths (extremely briefly) at Angie's List where I was "that one guy working remote from Chicago".

mobilene 4y ago
O hai Dylan! Nice to see you here!

Rodeoclash 4y ago

I love these stories. I got my start around 1998 when the web was coming into full force which was only a decade after this and very different. Things were changing quickly in that era. The closest I've had to this was working at a company that had been around for close to thirty years and had kept many of the original developers (they'd taken the product from a terminal interface to the web, from cobol to c#) and had many stories like the one in the original post.

sillyquiet 4y ago
I started a few years after you, around about 2003. There were certainly pockets of industry that still operated exactly the same as the article described, especially defense and aerospace. Which makes sense, given working in embedded hardware (especially in classified contexts) back then came with a lot of the same limitations described in the article - software had to be delivered by sneaker-net, installation was burdensome, you couldn't just fire up the application for a quick bug fix at home, etc. Not to mention the inertia of having Always Done It That Way.
Aeolun 4y ago
I started about 10 years after, and I think that was almost the best of both worlds. Agile was starting to become a thing, but wasn’t perverted to sell expensive courses and credentials yet, and tooling began to be developed that was a serious improvement on what we had.

deleted 4y ago

[deleted]

KptMarchewa 4y ago

>To my astonishment I discovered that I loved to write, even more than I enjoyed writing code. I wish I was this person. I'm one of those (great majority of) people whose documentation you'd hate. I deeply hate writing like that because I can never properly explain my tangled thoughts. Even my comments on sites like that are at most few liners. Describing things in code is much easier, since you don't have centuries of context written into words.

user3939382 4y ago
FroshKiller 4y ago
Your class names, variable names, and method names have plenty of centuries' worth of context in them anyway whether you like it or not, not to mention the comments and documentation. I think you'd benefit from looking at writing differently. What you describe--"I can never properly explain my tangled thoughts"--is the essence of composition. The goal of the process of writing is to untangle those thoughts and express them! When I say "process," I don't just mean that you begin typing immediately. Composition is about planning as well. Even if you spend just a few minutes making a list of keywords & important concepts then arrange them on cards in the order you think you should present them in, I bet it would help writing your initial draft of a document. If that doesn't appeal to you, so be it, but look into a composition course, because I genuinely think you could turn something you hate into something that helps. You might never fall in love with writing, but that doesn't mean it can't be a tool that solves problems for you.
rozenmd 4y ago
Just keep writing. It gets better.
- spaetzleesser 4y ago
  From my experience it won't get better unless you put effort into learning how to write. Just writing is not enough.

theDaveB 4y ago

I started my first programming job, well trainee programmer in September 1989. Five people applied for the job and I ended up taking my TV and Atari ST to the interview to show them some stuff I had written in STOS Basic. Got the job and started with dBase II on Concurrent DOS.

fjfaase 4y ago
I also have some fond memories of writing a 'smart' algorithm in STOS Basic for generating Madelbrot fractals. And is still took hours to fill the screen.
- theDaveB 4y ago
SulphurSmell 4y ago
I am surprised I had to scroll this far to find a dBase reference. I am the same vintage as OP, and yeah... back in the day dBase was the key to riches...at least as a contract dev. I remember spending A Lot of Money on the big box of dBase IV when it was released...all the diskettes and manuals. Around that time there was much talk about migrating from dBase databases (those .dbf files) to the magic of "SQL" which at the time meant nothing to me. Needless to say dBase IV cratered, and the industry went elsewhere. Good times!
- theDaveB 4y ago

zeckalpha 4y ago

Note that the author is not https://en.m.wikipedia.org/wiki/Jim_Gray_(computer_scientist) https://en.m.wikipedia.org/wiki/Jim_Gray_(computer_scientist... I was surprised by the date of the article at first!

mohanmca 4y ago
Exactly I was bit confused, initially thought that I read one of his old writing. The legend is still missing.
usr1106 4y ago
I attended a lecture by him around 1990. Maybe I was not the Turing Award class of computer scientist, was not sooo impressed what he spoke about. Remember Parnas [1] approx. the same year much better. Around 1998 Gray had built something called TerraServer, must have been years before Google Maps or OSM. It was a real eye opener at the time to see my little house in the middle of nowhere in Northern Europe on the internet published for free by an American company. At the time PC disk sizes where still measured in Megabytes, so you weren't even able to store that many aerial pictures. At least not pictures of current size. Probably they were smaller then, don't have any data. Edit: [1] https://en.m.wikipedia.org/wiki/David_Parnas https://en.m.wikipedia.org/wiki/David_Parnas

darthcloud 4y ago

Similar to the blank tape story, around 7 years ago at a big networking corp a big customer needed the latest product to be in their possession before some tax related date. The new product software wasn't ready at all at that point, so we shipped them unit with a place holder FW that could do only one thing: FW upgrade!

josephd79 4y ago

Terra Haute, Indiana. The greatest smell on earth.

mobilene 4y ago
The trick is to live on the north side. The odor seldom wafts northward.

fjfaase 4y ago

I have been working in the software industry since 1990. In 1990, I joined a company that made innovative coupling between AutoCad and relational databases (Oracle). However, I wrote my first program in 1978 in Algol 60. I also used Fortran, LISP, (Turbo) Pascal, BASIC, and 6502 Assembly before (in 1990) starting to develop software in C.

fjfaase 4y ago
I remember that one day at this company, we had just got a MicroVAX system, when I there was someone at the door with a europallet. We wondered what it could be. Turned out it was the VAX/VMS documentation that belonged to the MicroVAX. It took more space than the system itself.
- SulphurSmell 4y ago
  Shelves and shelves of tidy orange binders. I had them too!

theletterf 4y ago

Lovely story. As a fellow technical writer, I was glad to see you entered tech from that door. Edit: The author will probably smile at this post: https://news.ycombinator.com/item?id=30365800 https://news.ycombinator.com/item?id=30365800

mobilene 4y ago
Thank you! I enjoyed writing those behemoth 300-page manuals. The tech writing world has changed so much since those days!

tragomaskhalos 4y ago

Being the same vintage as Jim, much of this brought back memories. There really wasn't any such thing as a tech stack - our company would produce software for various Unixen and, especially, Vax, and the language was alway C, with some Pascal on the Vax side (as, I was told, the Vax Pascal compiler produced far more optimal code than the C compiler). Being a software engineer was like being a furniture-maker. You had to master a small number of tools - the saw, the chisel - and then craftsmanship consisted of discovering an affinity with these tools and a love of getting ever more skilled at using them. This path wasn't for everyone, which was fine - plenty of management and other non-tech roles for those folks - but if you grooved with your tools it was a real joy to be able to move from chair- to table- to cabinet-making and carry and refine your skills as you went. This idyll could not last, however. Before too long it became uneconomical to make furniture this way, so for your chair making project you instead had to learn how to run a chair-making machine. When you moved onto a tables project, the machines there were infuriatingly dissimilar to the chair-making ones you'd just mastered. Worse still, moving back to chair-making after a year or two, you discover that the old machines you knew are now obsolete and you have to re-learn how to run their replacements. This stops being fun, or interesting, after a while, and yet sadly it's all that most younger software engineers know. Occasionally, there is the need to make some shim or gizmo that the machines don't cover, so out come the trusty saw and chisel of yore - much to the amazement of the young'uns, who are astonished that an old-timer can still wield these antiques so effectively.

joshowar 4y ago
As a youngster who has had to pick up a saw and chisel to repair an old chair, I think you're looking back with rose tinted glasses a bit. I've never been astonished by legacy code, as much as bemused for the lack of object orientation, data normalization, etc. The technology changes of course, but there are advancements made in craftsmanship/techniques. There's some 'cleverness' lost probably, in the new ways vs the old. I've seen some pretty novel approaches to what should be simple tasks in legacy code. And I do recognize that for what it is. But as impressive as that cleverness can be, I think it's one of the reasons as to why a lot of legacy code persists and nobody wants to touch it. Among many other reasons.

gspencley 4y ago

> Even if we did see then (and we mostly didn’t) that small, frequent releases were better in a whole bunch of ways, we couldn’t really do it. It was expensive to ship on physical media, and disruptive to our customers to have to do frequent installs. It's still disruptive to customers. As a software engineer I love CD/CI. It makes the entire process much smoother and more efficient. As a customer / end-user, though? Nope. I absolutely hate it. Maybe I'm just getting old but I'm extremely nostalgic for the days where I got to decide if I the upgrade was worth it to me or not. These days things will change and move you on without any notice or opt-in what-so-ever.

LAC-Tech 4y ago
Sometimes when I play a retro game, I'm completely in awe of programmers of that vintage. Games took a year or two to make, on massively constrained hardware, in assembly language, with no engines, all original artwork and music, and no bug fix updates after it was complete. People like to pretend the future is always better and everything is advancing, but surely they had more talent than we do.
- BlargMcLarg 4y ago
  I feel like you're cherry-picking. Games have gotten way bigger content-wise and way more intense in many design aspects. Many retro games had massive teams and utilized earlier frameworks and content to release faster. There are many old school techniques which are amazing and quite a few talented developers, but I wouldn't make a sweeping statement that "they" had more talent than "we" as a whole.
  - gspencley 4y ago
    It's funny, though. Maybe it's just my age and not a comment on the quality of games, but I don't even play newer video games anymore. Every once in a while I'll start a game of Civilization IV (from 2005) if I have a lazy weekend and need a change of pace. I played a lot on the PS3 and then my PS4 was a dust collector. Complete buyers remorse there (and don't get me started on the fact that I needed an Internet connection on first boot to set it up. WTF?!!?!!!) And I'll still sit and play Tetris for hours and hours and hours on my retro NES. The newer versions, not so much. I've had this sense over the decades that as video games have grown in scope and graphics they've gotten less fun to the point where I tell people when they ask me "I don't play video games." It's probably been about ten years since I've paid for one. Now get off my lawn.

LAC-Tech 4y ago

Not so sure about the development/testing split of the waterfall, but two months up front just to design and gather requirements... feel like that might be a net benefit! Waterfall up front, party in the back?

beckingz 4y ago
Call it hybrid-agile and let's make bank consulting it.
jdlshore 4y ago
It sounds nice, but in reality your requirements end up being a castle in the sky. My team once spent 6 weeks for a small project (I was the team lead) creating a detailed requirements document with screenshots, a prototype app, etc. My users were all at hand and I showed them the prototype. They all agreed that it was what they wanted, and signed the requirements doc. We spent several months building the application. When we shipped, the software was unusable, because a security feature that we had been explicitly told could wait for the second release turned out to be essential. We also ran into a big problem with concurrent editing that no one had considered in advance, and blew up our carefully-created design. The solution to changing requirements isn’t to nail them down, because that’s effectively impossible, but to get better at evolutionary design techniques (introduced by Extreme Programming) so you can adapt to arbitrary requirements changes without disruption.

vt85 4y ago

antiterra 4y ago

It’s curmudgeonly, but I can’t help but bristle a bit at the ‘we didn’t have _____ when I was a programmer’ stuff because it very often existed in some substantial form. Case in point, UI/UX- You could have user interface design as a job back then, perhaps at IBM working on ATMs. UI philosophy was a significant part of what was done at Xerox PARC, and you can read a 1989 article by Alan Kay on the topic: http://worrydream.com/refs/Kay%20-%20User%20Interface,%20a%20Personal%20View.pdf http://worrydream.com/refs/Kay%20-%20User%20Interface,%20a%2... In 1988 the first edition of the Handbook of Computer Human Interaction was published, a staggeringly expansive book on the subject, which included stuff like rapid prototyping, user acceptance and design review. Sure, plenty of companies didn’t bother with this added expense, but that’s still the case today. The idea that it wasn’t there at all is misguided. Another bit that seems off is mention how Java was ‘a total game changer’ when it came out. Cross-platform development was an exciting idea, but in practice, everything with Java was dog slow for quite a while. The true and eventual potential of the JVM was still opaque for years after the 1996 launch.

drewcoo 4y ago
Xerox PARC was doing bleeding edge work. To compare anywhere else at the time with their revolutionary innovations, to claim that those companies just "didn't bother with the added expense" is absurd.
- antiterra 4y ago
  PARC was so on the bleeding edge they were doing this stuff in the 70s, by 1989 there was definite influence.
buescher 4y ago
"Alls we had was waterfall" rankles too - and maybe it's just me but I've been hearing it a lot the last couple of years - particularly when most people first heard about "waterfall" was when someone made them do SCRUM. And by 1989 OO was obviously the right thing for graphics and graphical user interfaces were arriving in a big way. MacApp was four years old. The original NeXT workstation had launched the year before. "niche" only in the sense that Turbo C++ was a year away. https://en.wikipedia.org/wiki/MacApp https://en.wikipedia.org/wiki/MacApp

trumbitta2 4y ago

The last paragraph story is so "Lean Startup" I'm crying

leohonexus 4y ago
Or, it is what any half-competent witty student would do when they couldn’t finish their essay in time - send a corrupted .docx file and blame Moodle :)

beckingz 4y ago

The section about waterfall being the only SDLC is interesting because it touches on the economics of shipping and software engineering practices: Continuous delivery only makes sense if the value of new feedback and delivered software is higher than the total cost of delivery. If you have to mail a floppy disk to each customer, that's a lot more expensive than just updating your production servers.

KingOfCoders 4y ago

"UX design wasn’t a thing yet" On my Amiga UX/UI design was a thing, layout, settings pages, forms, GUIs that did scale with different font sizes. At least for some companies, some UIs had horrible UX though. Like when they added shadow to text labels. On my CPC I wrote a GUI library with auto layouts and muli step flows woth |RX (?) commands with characters like ┤ [1] for borders - always reading Apple magazines. ┌╴╴╴╴╴╴╴┐ │ Title │ ├╴╴╴╴╴╴╴┤ │ Yes! │ └╴╴╴╴╴╴╴┘ [1] https://en.wikipedia.org/wiki/Amstrad_CPC_character_set https://en.wikipedia.org/wiki/Amstrad_CPC_character_set

mobilene 4y ago
Good point about the Amiga. Someone else here commented on Xerox PARC. So yes, there was UX design. However, in so many companies like the one I worked for in the story, it was utterly ignored.

ChrisMarshallNY 4y ago

That brings back memories... We also tended to have long-term stays at companies. We usually had to maintain the software we wrote, so it encouraged us to at least leave some decent documentation breadcrumbs.

ghaff 4y ago
>We also tended to have long-term stays at companies. I was at a minicomputer company (DG) from the mid-80s until the end of the 90s. Mostly PM for hardware. A lot of engineers had been there for a long time. Even more so, people in support functions of various types. There was one woman who I think may have been the only person who knew our BOM and related systems inside out. I think there are still a few people I worked with who are still there (by way of EMC and Dell). At least as of a few years ago, one of them was one of the engineers who worked on the computer that was chronicled in Soul of a New Machine.

jleyank 4y ago

Graphical vector mini-supers. Unix and vax environments, with SUN ruling the roost and SGI crashing in. Multiple instances of what became things like knime. X11 and multiple vendor-specific gui toolkits. Excellent vectorizing compilers for Fortran and C. 4 and 8 core multiprocessors. Granted, it wasn’t as fast but there was lots there which people probably forget. Software wise, there were research groups with all of the ml/ai areas in chemistry (Gasteiger, others) so I assume they were active elsewhere. The quants were starting upon Wall Street and they needed visualization systems to know whether their model is going up or down. Stereotactic imaging for medical uses, fluid dynamics and finite element analysis were leading to changes in car and airplane design, Microprocessors killed off this ecosystem - the pa-risc chip from HP could be a soft pc faster than a 486 could be a pc. But don’t think it wasn’t there. Hell, all of the foundation was laid by (mostly) hackers in the 60’s and 70’s that were building on now. It just used way less memory :-) And don’t forget the work from the folks at bell labs. And neat stuff like the blit.

kgarten 4y ago

tangent: my mind went to a different Jim Grey https://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist%29 https://en.wikipedia.org/wiki/Jim_Gray_%28computer_scientist... (the ACID properties database guru) The about page of the blog does not tell me much about the author (it would have been nice to mention some projects or other milestones).

sokoloff 4y ago
I went to the same place, making this comment thread all the more surreal: https://news.ycombinator.com/item?id=32057986 https://news.ycombinator.com/item?id=32057986

jjav 4y ago

> There was no working from home. The minicomputers were available only on the in-office network. I think it was not technically impossible to connect them to the Internet, but at home we all had only dialup access. Not only would speed have been a concern, but the family wouldn’t enjoy having the phone tied up for hours while you worked. I was lucky in that I got to work remotely from the beginning. Late 80s at the university I set up a modem bank to one of the UNIX boxes and installed a second phone line at home, so I was dialed in pretty much 24x7 (at 2400 baud, of course, but with an all-text terminal session it's fine and usable). At first job they had dialup into the Sun servers as well, so I often worked from home (by now at 14.4 and later 56K at which point remote X was doable).

jmclnx 4y ago

>Every last software engineer at ACD was a white man Interesting, where I was at the time, it was a 60/40 split between men and women. Also I would say 10% were people of color. And one person was completely blind. Two of the smartest people there were people of color, early on (before 1989) I learned a lot from them. This was in the northeast

krallja 4y ago
When you say “northeast,” do you mean more like Boston, NYC, or Kennebunkport?
- jmclnx 4y ago
  at that time, boston
mobilene 4y ago
I do acknowledge that my experience was a sample space of one!
- mixmastamyk 4y ago
  I think this statement goes too far in that case, I'd walk it back: > The software industry was a far less diverse place then. It probably makes sense when talking specifically about the midwest, due to demographics. But out here in SoCal in the 90s, I had a south asian boss and foreign national engineers from a number of countries working side by side. China, Italy, Norway. It was a big facility and we had US minority employees as well, although not a huge number. Software dept was 1/4 women approximately. Re: being gay it was the "don't ask, don't tell" days. No one I knew cared in the least. An interesting angle is I wasn't perceptive about it as a young person. Looking back in the hindsight of maturity, obviously gay people were everywhere. Just like in Hollywood, everyone just winked and nudged. Right, Uncle Arthur is ~fifty, unmarried, and rather flamboyant, nothing to see here. ;-)
nostrademons 4y ago
It's interesting, my experience at a FANG (which invests heavily in recruiting women engineers) is that approximately 25% of teams are 60/40 men/women, and 75% of them are 100% men. The women I've worked with have told me that this is not a coincidence, that they very quickly learn which managers they will not work under or which coworkers they will not be on a team with, and that they take the presence of other women on the team as an indicator that none of these characters are present. I wonder if the same principal operates geographically - certain regions find that they just never encounter women or minorities in the workforce, and it may have as much to do with the region as the people.

wazoox 4y ago

My very first programming job was in 1991 or 92 writing an interactive kiosk based upon a touch screen driven by an Amiga, using the multimedia platform Scala (quite similar to the later Macromedia Director, but it still exists). Then with a colleague we developed an interactive phone application (the sort that asks you to "press 1 for this, press 2 for that, press # to go back to the menu") on a SCO Unix system, in some sort of weird BASIC. While one of us tested the application on the phone, the other one played "X-whack-a-mole" :)

hunglee2 4y ago

wonderful writing - looking forward to pt2!

krallja 4y ago

I got my start in the software industry in that building, too. I was an intern at Rose-Hulman Ventures in 2005, building tax administration software for Indiana counties in C# 1.0 WinForms with Visual SourceSafe and Microsoft SQL Server. VSS required you to take a lock on a file to be able to edit it (there’s no merge ability) so I spent a full afternoon one day separating our data access layer class into partial classes so it would be spread across multiple files, and more than one developer could write a stored procedure wrapper at a time! Likewise, our bug database also only had enough licenses for one or two people to be logged in at a time, so we printed out our tickets to work on them. Learned a lot that summer, especially the fundamentals of databases and software architecture. Also learning C# that early gave me a ton of experience and willingness to work with C# again in my next few jobs.

nobleach 4y ago
Well, you survived using Visual Source Safe. (I've lost so much hard work with that tool). I worked on stuff one generation before C#. Visual FoxPro was my money maker for awhile.
- krallja 4y ago
  We had a “robust” backup strategy. (Taking a copy of the source code onto the file share every night.) Definitely lost VSS revision history at least once. I don’t know how VSS ever made it to customers!
int_19h 4y ago
But partial classes didn't show up until C# 2.0?
- krallja 4y ago
  You’re right, I misremembered! I made a hideous inheritance chain instead: abstract class UserDAL { } abstract class ParcelDAL : UserDAL { } ... abstract class DAL_n : DAL_n_minus_1 { } class DataAccessLayer : DAL_n { } each in their own file, of course. I tried to give them descriptive names and very narrow scopes. But inheritance is pretty dumb here. What does it mean for ParcelDAL to extend UserDAL? A parcel is not a user. When C# 2 came out, I was able to get rid of the inheritance and make them all part of one big partial class, keeping the file names the same.

no_wizard 4y ago

Thing I hear from a lot of software engineers from the time-frame of 1980-2000 is how much software engineering - to engineers at least - was about the craft. It was all about the craft of making good software. People invested real energy into trying to do it right, and treated it as such. This is of course likely colored by experience and "rose tinted" glasses, however, I think we as an industry have let this go, especially since the rise of bootcamps. It just isn't about the craft anymore, its all about "hustle". There is some truth to the fact that engineering in this time there was more caring about it as a craft, caring about performance, caring about shipping quality etc. I like thinking about things as a craft, I don't always like the "hustle" aspect that is pervasive now, it guarantees shipping too early and never taking quality & craftsmanship seriously, I feel like. I want to work somewhere again that sees engineering software as a craft again.

travisgriggs 4y ago
> I want to work somewhere again that sees engineering software as a craft again. If you find this place, will you tell me? I will come work with you. I admit though, that I struggle to codify what “coding as a craft” is. And that worries me. I fear I am really just playing a game of “I’ll describe it when I understand it” up-over-that-next-hill-ism with myself that is illusory and delusional.
- TedDoesntTalk 4y ago
  > I struggle to codify what “coding as a craft” is It means working with people who care about the quality of their work.
  - pdxandi 4y ago
    Does caring about the quality actually mean the quality is good? Maybe it doesn’t even matter. If the team cares and they are satisfied with what the quality of what they are building, maybe that’s enough?
    - 4y ago

gbronner 4y ago

I saw the 'blank CD / oops our shipping department screwed up' trick in 1998. I think it was used to recognize revenue in an earlier quarter for a release that wasn't quite ready yet, but where they wanted to have a nice hockey stick growth curve. I think it eventually cost a VP his job though.

gnfargbl 4y ago

This made me chuckle: > Then someone had a brilliant idea: we would ship US Sprint a blank tape with our usual letter listing the changes in the release. ...preceded by... > Our relationship with US Sprint was always iffy, and one day we pissed them off one time too many and they canceled their contract Well, yeah. If your company depends on a small number of large customers, you really can't get away with pulling nonsense like the blank tape trick on them. People aren't idiots.

wging 4y ago
That Monday deadline seems to me like they were searching for an excuse to end the relationship.
fmntf 4y ago
This old trick is still in use nowadays. However, instead of shipping a tape I have seen a colleague uploading a zip corrupted by hand, just two gain a couple of days of bug fixing.

swyx 4y ago

> "The software engineering team had two titles: Software Engineer and Senior Software Engineer. This was typical in the industry. You had to have at least 10 years of experience, but more likely 15 years, as a Software Engineer before being considered for promotion to Senior. The bar was higher for Senior then, too. I’d say a Senior engineer back then was skilled and experienced more like a Staff or Principal engineer today." amazing to see that the title inflation in our industry has roughly matched actual economic inflation :) on a more serious/optimistic note, there is a lot more tech to learn today than in 1989, and we probably learn at a faster rate too given the available amount of material (HN, youtube, books, etc). so perhaps not unwarranted. i'd love to pit a senior engineer of today vs a senior engineer of 1989 in doing modern programming tasks.

mywittyname 4y ago
> amazing to see that the title inflation in our industry has roughly matched actual economic inflation :) Why should there be only two categories of developer? Most trades have at least apprentice, journeyman, and master.
brunooliv 4y ago
I suspect that the ones of today would have a mental agility and/or capability to discover things on the fly that simply weren't possible all those decades ago. I think it's only at the real low-level or hardware/assembly or, for instance, a bit above the stack, say, optimizing a data model or fine-tuning a DB engine for a given domain, that the old timers would really shine. I see it in my daily life: my dad was a Fortran programmer way before I was born, so, maybe you know... 1970s or something like that. He was actually very good at his job, getting a research position doing some serious programming work that was seen as groundbreaking at the time, doing some finite element modeling on extremely resource constrained environments, probably what we would call data-oriented programming today, but taken to its extreme.... However, he didn't really keep up with programming after a few years, shifting to MATLAB based tasks for some university courses he lectures... and I feel that the complexity of today is just too much for him to grasp as it was. It's just too many moving parts and too many layers of abstraction to sift through. By the same account, I expect your typical developer of a regular company, myself included, seniors included, etc, etc, to be completely lost if they had to optimize code for a given hardware and needed to write some assembly, or whatever, disassemble some JVM class files, etc.

mikewarot 4y ago

Back then I wrote a program to manage the inspection of Fire Equipment at Generating Systems, by myself, in Turbo Pascal. The inspections were recorded on Hand-Held computers (oooohhhh!) made by the Norand company in Cedar Rapids, Iowa. I wonder how well that code would hold up to modern scrutiny. Here's a clone of TECO[1], which I fell in love with at Rose-Hulman, in Turbo Pascal, as a sample of how I wrote things back then.... roast away [1] - https://github.com/mikewarot/teco https://github.com/mikewarot/teco

smm11 4y ago

I was in that Token-Ring world back then, and the terminator clip at the end of the chain was the bane of my existence. Our System 6 and 7 machines had to talk to everything, VAX and PDP and DOS and anything else that communicated over serial. The WWW was a rumor then a thing, and it was fun to click around on Gopher, but you couldn't find anything you could really use.

lordnacho 4y ago

What's the deal with the machines having to start up in order? How did that come about?

mobilene 4y ago
Memories grow dim after 33 years - I don't remember. It do remember that it didn't totally make sense to me at the time.
- Clubber 4y ago
  I would guess they are dependencies. For example you would want to start the database server before you started the application. If the application started with no databases, it would do some funky things and may end up in a weird state.

scrubs 4y ago

I lived and worked throughout Berkeley, San Jose, Cupertino, Marin County from '80-'95. I've been in the original Apple office. I remember 280 before all the CISCO and Oracle buildings went up. I have my share of stories. Still I feel like us old guys have got to have more on the ball for the new-comers than (i) memories (ii) rants about how it used to be. A psychologist once pointed out old people go to memories if they've got nothing going on now. I like Warren Buffet's line noted for not investing in tech: I might be old fashioned but I'm not old fashioned stupid. Part of having gray hairs is to know what was stuck-on-stupid then, and not repeat it now. Part of having those gray hairs is a Peter Drucker take on business: factual, direct, and unsentimental but not mean. The future (i.e. today relative to '89) isn't always better.

mobilene 4y ago
You're right, but there's also room for an old guy to reminisce on an anniversary.
mlyle 4y ago
Meh. I'm a decade or two younger than you, and I've got plenty of stuff going on, but I'm still so drawn to sentimentalism. I miss workstations and the feeling of quality. I miss slapping in a router and having connectivity. I miss the sheer degree of early 2000's brogrammer tomfoolery. I miss BBSes and local community. I miss usenet. I miss the sense that IPC and single thread performance was gonna increase forever. I miss having a T1 to my apartment and playing with frame relay and Serious HiCap Telco Circuits (tm). I miss HalTed and the maker movement before we called it a maker movement. Man, we've got such great stuff now. I've got a home 2gbps PON link and 10 gigabit ethernet everywhere and plastic crappy machines that are 20 million times faster than that decked out SPARCStation 20 and more IOPS than I could have ever imagined. But why'd it have to eat all the best parts of those things? (I know why, but that doesn't mean I have to like it...)
- eps 4y ago
  Yeah, the whoomp of a CRT monitor powering up, the sound of a modem handshake at 2am and the flex of 5" floppies. Good memories of times never to return. But that's just nostalgie.

pjdemers 4y ago

>> we would ship US Sprint a blank tape with our usual letter listing the changes in the release. And so we did. I worked for a company in the same era that did the exact same thing for a late release.

botswana99 4y ago

...and how much is still the same today: coding on networked UNIX machines with TCPIP, C and its variants, emacs, etc. Also, software engineering is still mostly male.

brian_herman 4y ago

Wow this is a great story thanks for sharing!

imiric 4y ago

Fascinating read, kudos to the author. I hadn't considered that token-ring networks had the limitation that all nodes had to be online for it to work, but it makes total sense. We're so spoiled these days. :) And that last idea to ship a blank tape to buy you time is pure genius. Reminds me of the high school / undergrad tricks of submitting a corrupted archive or document on the deadline date. It bought you at least a day or two before the professor noticed, and by then you'd hopefully be finished. Not that I ever partook in such reprehensible behavior...

deleted 4y ago

[deleted]

eternalban 4y ago

> The software industry was a far less diverse place then. Every last software engineer at ACD was a white man, most of them younger than 35. QA was much the same except for one young woman on the team. counter point: My 2nd job in the field, 1990, NYC, software development firm, reported to a Chinese-American woman (Cooper Union grad) and the CTO was also Asian American. My ~mentor was a Bell Labs engineer with a luxuriant white beard (so way over "35"). I also had a private office that I shared with another engineer (a young white married guy who commuted from Philly). Q/A iirc had many Indian women.

mobilene 4y ago
I forget that I was in the Midwest, not on the coasts, and things were likely different in this regard on the coasts.
- sammalloy 4y ago
  It occurs to me, that the one place you might see parity with the Midwest and the coasts in terms of a loss of diversity was in the composition of the graduating classes for compsci in 1989. I remember peeking in on one class in the Bay Area and there wasn’t a woman in sight. The majority of women I knew who were involved in programming at the time came from a background in business administration. I think it’s true that the workplaces on the coasts were decades ahead of the rest of the country (women, minorities, LGBT), but academia was still far behind in terms of inclusion like the rest of the country.

WalterBright 4y ago

> Every last software engineer at ACD was a white man, most of them younger than 35. Not true in the company I worked for at the time. We had many minorities, women, and even some up into their 50s.

WalterBright 4y ago

I don't miss CRTs at all.

gwbas1c 4y ago

> Then someone had a brilliant idea: we would ship US Sprint a blank tape with our usual letter listing the changes in the release. And so we did. > “Oh! We are so sorry. We can’t imagine what must have gone wrong! We will send you another tape today.” Those games are so common no one really falls for it. They might be polite and not call your bluff, but you can bet they know. (And I suspect that this was the "straw that broke the camel's back" for Sprint.)

divbzero 4y ago

> That led us to create enormous Gantt charts (printed dot matrix) that we’d tack onto a huge wall, and use them to track plans and work completed. It never failed that during the first week of coding we’d discover something that we didn’t think of in the design phase, and we’d have to replan the entire project and print all new Gantt charts. We did this over and over every project. I’ve only ever worked with “modern” agile approaches to software development. Gantt charts feel like a mismatch with the speed of software development, but sometimes I wonder if there certain software projects where Gantt would work better than agile.

misterbwong 4y ago
For software, the usefulness in Gantt charting seems to lie in the visualizing and mapping project dependencies and rough ordering of milestones. Where most get it wrong is in believing that the date at the end of the chart is anything more than a very rough estimate

deleted 4y ago

[deleted]

lampshades 4y ago

Worked at a company a few years ago that was still using Classic ASP for some projects. It was not supported by Microsoft at this point, which is saying something, and I’d be surprised if the project was ever sunset. The software development process sounds all too familiar, i.e. hundreds of bugs in QA, long releases, long release cycles, death marches, and burnout. Fun stuff. This cultural mindset permeated the entire organization. Even for projects using new technology, we were coupled to this legacy project and our processes always devolved to what it had created.

UncleOxidant 4y ago

I am of a similar vintage. Technically, I was in hardware/firmware in '89, but I was working in a startup then and the lines were pretty blurry - I wrote a good bit of assembly & C code. One thing that I notice was that even though there wasn't really any sort of formal push to get women into tech back then, the software group was pretty close to 50% women where I was working in the late 80s - in fact, for a while there were more women than men in the group. Similar at the next couple of companies I worked in software into the mid-to-late 90s - maybe not 50% women, but pretty close. But then in the aughts that gender distribution tended to skew more towards males. Not sure why that was. And now I'm working in a startup where it's about 40% women, so maybe we're getting back to where we were in the late 80s.

stormking 4y ago

Ha! I've used that last trick a couple of times when stuff was over-optimistically promised "today, end of business", sending out random bytes renamed to .zip and having the real file ready next morning when people complained about not being able to open yesterday's zipfile.

sgtnoodle 4y ago

If this sort of computing history interests you, I just finished reading, "Hot Tech, Cold Steel" https://www.amazon.com/Tech-Cold-Steel-Computer-Aided-Manufacturing/dp/173715370X https://www.amazon.com/Tech-Cold-Steel-Computer-Aided-Manufa... It's interesting how the company, MDSI, started on 8-bit timeshared mainframes, then eventually ported their software to newer platforms using a combination of emulation and microcoding. I happen to know Chuck from my years racing solar cars in college.

RickJWagner 4y ago

Brought back great memories for me-- I worked in Terre Haute in the early 90s. My shop was at a local bank. We were a little more diverse-- we had some ladies working in the shop, and an African-American male also. (And several older men.) We worked hard, running a mainframe/COBOL shop. Some late nights (batch processing was king then!) and some great teamwork. Good memories.

berkeshire 4y ago

1995 India - Had a paid internship (Rs 2500 per month or ~ USD 80 back then) with a small software company that worked on FoxPro + dBase. A very diverse team (gender ratio), the highly enthusiastic bunch created software for non-banking financial companies. A thick documentation book occupied most of the space in the large, laminated box that such development software came in. Along with half a dozen floppy disks where we hoped that no disk would have a bad sector. Requirements were constantly over the phone from clients and shipping software meant taking two sets of floppy disks of different brands (backup!), in-person, to the city where the client was. CRTs needed a warm-up time and we had a small diesel generator (hand cranked) to power up the x86 computers once the main power line crashed (which was frequent). No internet searches, no help other than that thick paper manual or waiting around for hours for a senior engineer to get free to help you out. College taught us C and Pascal on Unix. That seems so far away from the world of microservices and SPAs. </nostalgia>