[HN Gopher] Working in the software industry, circa 1989
___________________________________________________________________
Working in the software industry, circa 1989
Author : firstSpeaker
Score : 346 points
Date : 2022-07-11 10:02 UTC (12 hours ago)
(HTM) web link (dev.jimgrey.net)
(TXT) w3m dump (dev.jimgrey.net)
| vt85 wrote:
| Rodeoclash wrote:
| 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.
| Aeolun wrote:
| 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.
| sillyquiet wrote:
| 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.
| lordnacho wrote:
| What's the deal with the machines having to start up in order?
| How did that come about?
| mobilene wrote:
| 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 wrote:
| 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.
| tragomaskhalos wrote:
| 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.
| jjav wrote:
| > 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.
|
| Love your analogy, it's all spot-on.
|
| On the above, I'll add that the new chair-making machine is
| hardly ever better than the one from 2 years ago that you saw,
| it's simply all completely different for the sake of being
| disruptive to you its user. Most of the time it's actually
| worse, with fewer features and more restricted customization.
| [deleted]
| joshowar wrote:
| 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.
| [deleted]
| de_Selby wrote:
| I think you might be missing parent comment's point. The way
| I read it they aren't saying that old code is better, just
| that you used built everything up from scratch generally (or
| to a much greater extent than nowadays) instead of using
| whatever framework is in fashion this week
| NoGravitas wrote:
| The truth is that most code, whether old or new, is terrible.
| The odds of any old code you might end up having to look at
| being terrible is very high.
| roblabla wrote:
| Huge disagree on this. Old code tend to be much more
| terrible because the tools were terrible. They gave little
| incentive and absolutely no help to write even passable
| code. We end up with a mess of poorly documented, sparingly
| commented spaghetti code that sometimes work, often by
| accident.
|
| Nowadays, we have linters to point out common classes of
| mistakes, programming languages with _actual_ type systems
| to enforce invariants, integrated testing tools, etc...
|
| Note that, yes, we do still have new, terrible codebases.
| But at least the tooling nowadays raised the bar to have a
| minimum floor of quality that, while very low, is still oh
| so much higher than it used to be.
| TedDoesntTalk wrote:
| This is nonsense. The code quality is determined by the
| author, just like today.
|
| > Nowadays, we have linter
|
| I was using a C linter in 1986. The tooling is better now
| but it still comes down to the author.
| Clubber wrote:
| We had "coding standards," and if you didn't code it to
| the right format, you'd get fussed at. I didn't start
| professionally until the mid 90s, so I'm a little younger
| than the OP. I've been coding since the mid 80s though as
| a youngster.
|
| Putting BEGIN..END around a one line block was always a
| contention since it wasn't required. Less code vs
| arguably more readable code (Pascal) If
| BLA Then Begin DO STUFF End
|
| vs If BLA Then DO STUFF
| maestroia wrote:
| I agree with the first sentence, and re: the second, also
| was using a C linter in 1986.
| com2kid wrote:
| > Huge disagree on this. Old code tend to be much more
| terrible because the tools were terrible.
|
| I've looked at 1990s code in the Windows NT kernel. It
| was wonderful.
|
| Oldest source file I went through was from 1993.
| Perfectly readable and understandable.
|
| One of the best modern code bases I ever worked in didn't
| even have a linter setup. The principle dev reviewed
| every single commit and enforced a consistency across the
| code base that was better than what any tools ever could
| have done.
| twright0 wrote:
| > The principle dev reviewed every single commit and
| enforced a consistency across the code base that was
| better than what any tools ever could have done.
|
| How was it so much better that it justified that level of
| busywork on the part of the senior member of the team
| (and busywork for everyone else, to fix the style nits
| they enforced in review)? I would have guessed that
| taking a few hours to install and configure a formatting
| linter to free up the principal dev's time to focus on
| other things would have been hugely high leverage.
| beckingz wrote:
| Reading every commit seems like the best short term way
| to maintain code quality and keep the whole project in
| your head?
| com2kid wrote:
| It ensured not only consistency of style, but also
| consistency of ideas. Every file was structured
| similarly, impedance mismatches were minimized, work
| across the entire code base was organized and unified.
| Junior engineers got a chance to talk to the principle
| developer about every commit they made, and accordingly
| their abilities as software engineers skyrocketed.
|
| Developers quickly set their IDEs to follow the team's
| coding guidelines, style wasn't really a problem.
| WalterBright wrote:
| Any of my code more than 5 years old is terrible. This has
| always been true for me.
| 3a2d29 wrote:
| Could be survivor bias. All legacy code that isn't
| terrible is rewritten. All terrible legacy code isn't
| touched by anyone and therefore remains.
| glouwbug wrote:
| Yeah but this guy wrote the first native C++ compiler and
| then the D programming language
| singaporecode wrote:
| Did not know that until you mentioned! Sometimes even
| legends post here on HN!
| glouwbug wrote:
| Walter is pretty regular around here, but I agree, it's
| like Arnold Schwarzenegger dropping in at reddit to hang
| out
| swyx wrote:
| > "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 wrote:
| > 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 wrote:
| 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.
| com2kid wrote:
| > 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.
|
| I've done both. I've gone from high level C# to counting
| clock cycles for embedded, and then back again.
|
| There is a transition period, but it is perfectly do-able. It
| is helpful if you have someone to show you the ropes, but
| after that it isn't too bad.
|
| Heck I've met some teenagers who are into disassembling
| JVM/CLR stuff. (Which is actually, IMHO, much easier than raw
| assembly).
|
| Have you ever done scaling calculations for AWS services?
| Same sort of logic applies to writing code for embedded,
| there is just a different number of mhz and instead of
| gigabytes of memory you are talking kilobytes of memory, but
| other than order of magnitudes, the reasoning is actually not
| that dissimilar.
| davedx wrote:
| My first couple of jobs from late 90s on were C++ and Java:
| homogeneous giant code bases with no agile, scrum, code
| review or anything.
|
| I do just fine with modern code bases and their complexity. I
| know I also have the experience to understand when the
| complexity is there for the sake of it and when it's because
| of the business domain.
|
| I've left projects where the first kind was too high because
| I've seen enough to know I don't have time for that BS
| anymore :)
| divbzero wrote:
| > _There was a holy war over text editors. IDEs weren't a thing
| yet, so we all coded in a text editor. I was firmly in the Emacs
| camp, but most of my co-workers loved vi._
|
| IDEs are definitely a thing now but the holy war continues.
| jleyank wrote:
| 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.
| gnfargbl wrote:
| 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 wrote:
| That Monday deadline seems to me like they were searching for
| an excuse to end the relationship.
| [deleted]
| [deleted]
| kgarten wrote:
| tangent: my mind went to a different Jim Grey
| 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 wrote:
| I went to the same place, making this comment thread all the
| more surreal: https://news.ycombinator.com/item?id=32057986
| WalterBright wrote:
| > 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 wrote:
| I don't miss CRTs at all.
| divbzero wrote:
| > _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 wrote:
| 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
| KptMarchewa wrote:
| >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.
| mobilene wrote:
| I'm the OP. I wasn't very good at it when I started, but I
| persisted. And read books on writing. And was edited by a
| couple of very good editors.
| kstenerud wrote:
| It's weird... I was never big on writing, but when I finally
| tried my hand at a data format specification
| (https://github.com/kstenerud/concise-encoding), I found that I
| really enjoyed the experience.
|
| It's 3000 lines and took me four years and countless revisions,
| but I feel it was worth it. I actually enjoyed writing the spec
| even more than writing the reference implementation :)
| mysterypie wrote:
| Wow, I like the data format specification you devised.
| Especially that you insist on "no optional features or
| extensions" -- something that makes other standards so
| difficult to rely on.
|
| Is there anyone using it? It's always great to have extra
| ammunition to make a strong case that we should use this
| instead of, say, XML.
| kstenerud wrote:
| It's still in the prerelease stage, but v1 will be released
| later this year. I'm mostly getting hits from China since
| they tend to be a lot more worried about security. I expect
| the rest of the world to catch on to the gaping security
| holes of JSON and friends in the next few years as the more
| sophisticated actors start taking advantage of them. For
| example https://github.com/kstenerud/concise-
| encoding/blob/master/ce...
|
| There are still a few things to do:
|
| - Update enctool (https://github.com/kstenerud/enctool) to
| integrate https://cuelang.org so that there's at least a
| command line schema validator for CE.
|
| - Update the grammar file
| (https://github.com/kstenerud/concise-
| encoding/tree/master/an...) because it's a bit out of date.
|
| - Revamp the compliance tests to be themselves written in
| Concise Encoding (for example
| https://github.com/kstenerud/go-concise-
| encoding/blob/master... but I'll be simplifying the format
| some more). That way, we can run the same tests on all CE
| implementations instead of everyone coming up with their
| own. I'll move the test definitions to their own repo when
| they're done and then you can just submodule it.
|
| I'm thinking that they should look more like:
| c1 { "type" = {
| "identifier" = "ce test" "version" = 1
| } "tests" = [ {
| "name" = "Some kind of test" "success"
| = [ // These must successfully
| convert to each other {
| "cte" = "c1 [1 2 3 4]" "cbe" =
| |u8x 81 01 7a 01 02 03 04 7b|
| // Events are a kind of text shorthand for what the parsing
| of cte or cbe should produce
| "events" = ["v 1" "l" "n 1" "n 2" "n 3" "n 4" "e"]
| } { ...
| } ] "failure" = [
| // These must fail to decode {
| "cte" = "c1 100 ]" }
| { "cbe" = |u8x 81 01 64 7b|
| } ] } ]
| }
| user3939382 wrote:
| notjustanymike wrote:
| > I deeply hate writing like that because I can never properly
| explain my tangled thoughts.
|
| I brought a friend of mine to give a couple lectures at our
| company for this exact reason. He's a professor of non-fiction.
| There's a couple techniques we learned you can use:
|
| - "madman architect carpenter judge"
|
| - shitty first draft
|
| - The most dangerous writing app,
| https://www.squibler.io/dangerous-writing-prompt-app
|
| They're all fundamentally the same concept: write first, edit
| second.
| Inhibit wrote:
| I enjoy writing and hate editing! There's always some
| problem.
| FroshKiller wrote:
| 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 wrote:
| Just keep writing. It gets better.
| spaetzleesser wrote:
| From my experience it won't get better unless you put effort
| into learning how to write. Just writing is not enough.
| rozenmd wrote:
| Slight tweak to my original statement:
|
| Just keep writing, and get feedback on each piece of
| writing. It gets better.
| lampshades wrote:
| 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.
| darthcloud wrote:
| 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 wrote:
| Terra Haute, Indiana. The greatest smell on earth.
| mobilene wrote:
| The trick is to live on the north side. The odor seldom wafts
| northward.
| mikewarot wrote:
| 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
| antiterra wrote:
| 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%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.
| buescher wrote:
| "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
| drewcoo wrote:
| 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 wrote:
| PARC was so on the bleeding edge they were doing this stuff
| in the 70s, by 1989 there was definite influence.
| pjdemers wrote:
| >> 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.
| theDaveB wrote:
| 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 wrote:
| 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 wrote:
| SulphurSmell wrote:
| 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 wrote:
| krallja wrote:
| 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 wrote:
| 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 wrote:
| 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!
| KingOfCoders wrote:
| "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
| mobilene wrote:
| 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.
| zeckalpha wrote:
| Note that the author is not
| https://en.m.wikipedia.org/wiki/Jim_Gray_(computer_scientist...
|
| I was surprised by the date of the article at first!
| mohanmca wrote:
| Exactly I was bit confused, initially thought that I read one
| of his old writing. The legend is still missing.
| usr1106 wrote:
| 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
| no_wizard wrote:
| 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 wrote:
| > 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.
| no_wizard wrote:
| Closest I ever got was working at Apple, and even then it was
| due to the fact I was on a very specific type of team, so I
| don't know if it was common case or not.
|
| I hear Google is largely like this, but who knows anymore. I
| hear mixed things all the time. It feels like you have to
| find a specialized company that may be immune to certain
| pressures and likely top of their field or the only company
| really in their given market sector. Maybe Oxide Computer?
|
| I think Supabase might be like this, given their marketing
| and hiring materials, but its hard to say. They're in a "long
| game" (according to their founder) so they think more long
| term. That tends to be a good indicator of this, I think, is
| seeing long term horizons over quarterly ones.
| xyzzyz wrote:
| Google used to be like this, but now, though some isolated
| pockets remain, is not like that anymore. A good mental
| model of how Google internally works today is Microsoft,
| but with free food.
| wnolens wrote:
| My time at Microsoft was learning a craft from old guys
| who were there in "the beginning". I'm so grateful for
| the hours spent on a whiteboard with a patient sage
| explaining to me how things work. My code reviews were 10
| iterations until I learned to do a better job. Very high
| bar. Even comments had to be full English sentences. I
| miss it.
|
| AWS is the opposite.
| rochak wrote:
| Not sure I agree with your experience at AWS. For me, my
| teammates have been super critical, always trying to
| raise the bar and looking for ways to make things better.
| So, all I'll say is that it is very team specific and you
| can find good and bad teams at every company.
| kiwicopple wrote:
| {supabase founder}
|
| We're fortunate to have started at a time when VCs were
| incredibly irrational (read: good for founders), and even
| more fortunate to have found a lead investor that's
| patient.
|
| We've been able to build Supabase our own way: hire the
| right people (mostly international), focus on what
| developers want (even though they don't pay much), and
| build open source (collaborating rather than competing).
| None of these are controversial until you have a profit-
| maximising VC breathing down your neck.
|
| > They're in a "long game" (according to their founder)
|
| I stand by this. It's a decade-long endeavour to build
| credibility as a database company and that's not something
| we can hurry.
| no_wizard wrote:
| Perhaps we should talk :)
| marshray wrote:
| > codify what "coding as a craft" is
|
| It means you produce something that works, has some
| consistency of organization, and most importantly: other
| developers will be able to come behind you to support and
| extend it.
| Clubber wrote:
| >I struggle to codify what "coding as a craft" is.
|
| It means different things for different people, but for me,
| it means: Step one is getting it to work,
| step two is making is as simple/clean as possible (most
| people stop at step 1 it seems). Take time to fix
| issues / sloppy code when you see it. Ideally you
| want the codebase to look like it was all written by one
| person. Carefully balance maintainability vs speed
| or cleverness. Refactoring is a necessity and
| should be done periodically. Same with tuning.
| Take the time to name your methods/classes/variables as
| accurately, verbosely and consistently as possible.
| Test your shit for bugs before you give it to QA, for the
| love of everything holy. If QA sends something back, you
| should feel a little embarrassed. Take the time to
| write useful comments. Focus on intent, that way the next
| person can know if the code is doing what it's supposed to or
| not. KISS, DRY, YAGNI.
|
| The best test is when I come back to my own code I wrote 6
| months ago and if I say, "who the hell wrote this shit?!" and
| it's me, I need to clean it up.
| bluedino wrote:
| What's the quote about writing a shit program and then
| thinking you're clever when you fix SOME of the bugs it
| has?
| cgrealy wrote:
| I 100% agree with all of that. That's how you make good
| software in a sustainable business.
|
| Unfortunately, that's not how the market works anymore.
|
| Do the minimum, get to market first, hype features over
| reliability and performance, get a nice looking balance
| sheet, and cash the fuck out.
|
| I love writing software, but I hate this industry.
| throwaway2037 wrote:
| You wrote: <<The best test is when I come back to my own
| code I wrote 6 months ago and if I say, "who the hell wrote
| this shit?!" and it's me, I need to clean it up.>>
|
| Up vote on this! I do it once a week -- at least. First, I
| am frustrated by some unreadable logic, then I look at Git
| blame... "Oh..." Second, fix it... again!
| TedDoesntTalk wrote:
| > I struggle to codify what "coding as a craft" is
|
| It means working with people who care about the quality of
| their work.
| hvs wrote:
| I was a professional developer starting about 1996, so this
| doesn't apply to earlier timeframes, but there were a lot of
| people TALKING about software engineering be a craft. In the
| trenches, there were a lot of people just trying to get things
| working. You would try to do this "the right way" (cf. how
| Agile is described vs how it actually works today) but a lot of
| it was aspirational. We were hacking things together and
| rushing it out the door back then as well.
| [deleted]
| granshaw wrote:
| On the contrary most programming history stories I read talk
| about how one had to come up with a clever solution or shortcut
| to hit a deadline...
| no_wizard wrote:
| I hear this too, but don't forget about context. Like the
| article states, it was hard to push updates, so there was a
| grind. Extreme Programming wasn't a thing yet, nor was online
| updates to software, so there were self inflicted downsides.
|
| It's also not like everyone forgot at the end of the day
| there was a business that had to be run, and profits had to
| be made, to continue working in the craft.
|
| And yet, even these "hacks" were interesting, at least, and
| to some extent, sometimes quite masterful.
|
| When I listen to folks re-calling this period its not that
| they don't say there weren't short comings, of course there
| was! Its that they remember everyone being in it together, in
| the thick, and really collaborating, because they _cared_ ,
| even when they had to take shortcuts to meet a deadline.
|
| Maybe that's what it is, the average engineer just doesn't
| care anymore like that, for better or worse. Its a hard thing
| to describe exactly, but it sure isn't prevalent now.
|
| And who can blame the average engineer today? Business
| incentives are often actively hostile to caring in this
| fashion. Technical excellence is not a goal anymore. Worked
| at many places now, and IME all have the same broad stroke
| issues around quality, meeting deadlines, product owning
| engineering work pipelines (definitely not true Agile, where
| teams are autonomous) etc.
| grishka wrote:
| Also, having to ship the product on physical media and fast
| internet not being a thing meant that software would actually
| have a "finished" state. Today nothing is ever finished,
| everything is in eternal beta and constantly updated for no
| good reason.
| sureglymop wrote:
| I disagree with you. It's still "about the craft" for probably
| just as many people as it was back then... But of course now
| there are way more people and it's much simpler to enter the
| field. Now, you don't need a college degree to get a job in
| this business. However, just as many people as back then still
| do get that.
| bcantrill wrote:
| Oh my goodness, no -- that wasn't it at all. To the contrary,
| the 1990s sucked for software development: everything was
| proprietary and (not unrelated) mostly terrible. Worse, the
| world was moving in the wrong direction, as what had started as
| a liberating computing movement (personal computing) had turned
| into a proprietary monster in the form of Microsoft. If you
| want to know what software development in the 1990s was like,
| read "Showstopper!"[0]; if you want to know what it was like to
| try start a company in the shadow of Microsoft, read
| "Startup"[1] -- and if you want to know just how shabbily
| software engineers were thought of, read (actually don't --
| it's terrible) Ed Yourdon's "Decline and Fall of the American
| Progammer."[2]
|
| Anyone telling you that the 1990s were "all about the craft" is
| pranking you. This may be an uncomfortable truth, but you live
| in the best time in human history to be a software engineer!
|
| [0] https://www.goodreads.com/book/show/1416925.Show_Stopper_
|
| [1] https://www.goodreads.com/book/show/1171250.Startup
|
| [2]
| https://www.goodreads.com/book/show/250164.Decline_Fall_of_t...
| -- but NOT recommended!
| ho_schi wrote:
| I appreciate the craft type of working! Within a craft you care
| about your work and your tools.
|
| The German phrase "Beruf kommt von Berufung" describes the howl
| attitude but all translations to English seem improper. Because
| it is a pun and probably because the apprenticeship (vocational
| education at work and school) isn't such important in the
| English speaking world.
| tablespoon wrote:
| > ...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.
|
| Hustle almost always seems like the most direct path to
| market/economic success. As market imperatives increasingly
| dominate, other priorities (like "craftsmanship") fall by the
| wayside.
|
| IMHO, the market system is important and useful, but it's also
| pernicious in a lot of ways. It needs to be powerfully kept in
| check, otherwise things become shiny and hollow.
| no_wizard wrote:
| Its a bubble / bust mentality though. I remember a _lot_ of
| people pivoting from finance (the previous "winner" of high
| salary, high growth opportunities pre mortgage crash
| especially) to tech, that also corresponded with the rise of
| this culture, IMO. Still was happening until maybe very very
| recently, MBA's were flooding the tech sector looking for
| opportunities, founding companies etc.
|
| Unsurprisingly, this is when "hustle culture" and the
| explosion of management roles started to take off in earnest.
|
| Craftsmanship isn't a bubble / bust mentality. Good work
| should stand the test of time, as it were.
| dnissley wrote:
| 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 wrote:
| O hai Dylan! Nice to see you here!
| gwbas1c wrote:
| > 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.)
| scrubs wrote:
| 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.
| msla wrote:
| > Part of having gray hairs is to know what was stuck-on-stupid
| then, and not repeat it now.
|
| Yeah, remember the utter idiocy of Pets.com? Imagine: Trying to
| sell stuff directly to consumers on the World Wide Web!
|
| Certainly wouldn't want to invest in a business that would try
| _that_ tomfoolery again.
| [deleted]
| mobilene wrote:
| You're right, but there's also room for an old guy to reminisce
| on an anniversary.
| mlyle wrote:
| 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...)
| drewzero1 wrote:
| I drooled over all that stuff but couldn't afford it. Now I
| might be able to afford some of the workstations I coveted as
| a kid, but they can hardly do anything by today's standards.
| Some of them can heat a room pretty well at least.
| eps wrote:
| 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.
| IntelMiner wrote:
| I picked up an old CRT at Seattle's RePC a few months ago.
| An absolutely massive 1600 x 1200 (at 85 Hz!) thing
|
| The first thing I did after powering it on was hit that
| degauss button, and _my god_ the feeling
|
| The bastard clonnnggeddd so loud my roommate heard it
| through the floor!
| jjav wrote:
| > 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).
| brian_herman wrote:
| Wow this is a great story thanks for sharing!
| gspencley wrote:
| > 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 wrote:
| 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.
| dayvid wrote:
| There's an amazing interview series with Nasir Gebelli, who
| made some of the first Apple II games, coded the first three
| Final Fantasy games and a 3d game in assembler, as well as
| Secret of Mana game for SNES. Highly recommended!
|
| https://podcasts.apple.com/gh/podcast/episode-3-nasir-
| gebell...
| BlargMcLarg wrote:
| 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.
| reaperducer wrote:
| _Many retro games had massive teams and utilized earlier
| frameworks and content to release faster_
|
| I think you and the previous commenter have different ideas
| of what constitutes "retro."
|
| The people I knew who worked on retro games usually were in
| "teams" of one or two, even if they worked for a massive
| company like Atari. If there were three people working on a
| video game, it was a huge deal. And "frameworks" weren't
| even a thing. Each game started from the ground up, with
| the exception of code clips that you printed out and saved
| in a binder.
| BlargMcLarg wrote:
| You'd still need to name specific examples. All the way
| from the NES to the current gen, you can name examples of
| both big teams and small teams / individuals having some
| form of success.
|
| The coding got easier per content unit and the skill
| floor is lower, yes. But the ceiling is still high, the
| demands are far higher and you'd need to be far more
| skilled in various disciplines to deliver the equivalent
| of a few decades ago. Those hours you gained no longer
| coding? You better have spent them figuring out how to do
| VFX, some decent pixel/line art, or make some stellar
| sound tracks. If not, maybe be able to do marketing or
| know how to make your game function in multiplayer
| online.
|
| >And "frameworks" weren't even a thing.
|
| Using virtually the same frame across a wide variety of
| processes is the very definition of a framework, even if
| it isn't a software framework in the modern sense. Many
| big games on the NES and SNES were built off of one
| another, you can tell by the similarities between
| developers and their work. Square being the most
| notorious.
| gspencley wrote:
| 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.
| zippergz wrote:
| This is why I turned off auto updates on my phone. I do update
| stuff periodically, and sometimes I'm forced (and certainly I
| do OS updates when there is a security issue), but I don't want
| my apps randomly changing out from under me overnight. Rarely
| these days are the "bug fixes and performance improvements"
| actually an improvement for me as the user. I especially hate
| it when a developer says something like "we update the app as
| often as possible to make it better for you!" No, updating it
| "as often as possible" is not better for me. It might be better
| for YOU, but it's just annoying to me.
| grishka wrote:
| I turned off automatic app updates on my phone. It turns out
| some apps, especially Google ones, do get whiny at you for not
| updating. Other than that, changes at least happen when I
| expect them. Nothing can save me from A/B testing though...
| tablespoon wrote:
| > 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.
|
| Yeah, even as someone who works as a developer, it seems that
| in all but a few cases the development organizations have a
| massively more control about how things are done than they
| should (which usually manifests as a veto by saying X is too
| hard/expensive). The overall effect is to make software crappy
| and annoying in ways that are less technical, and thus less
| likely to be fixed. Shipping on physical media put a technical
| constraint that helped keep that social problem in check.
| gspencley wrote:
| Yup. In most businesses it seems the path to promotion for a
| Product Owner is to come up with that killer feature that
| will garner massive new adoption and launch the company into
| hyper-growth. This leads to existing end users being the
| sacrificial guinea pigs in a never ending experiment that
| place hypothetical (and almost never realized) future users
| over the immediate interests of those currently paying for
| the product.
| dangus wrote:
| I love it as a customer. There's a lot of excitement when new
| changes come out, and I want them _right now!_
|
| Beyond business software, I can think of the way that indie
| games are delivered as early releases on Steam. Most recently,
| I would get excited for every little Valheim update. It
| extended the life of the game, which probably won't be truly
| done for many more years. If they were limited to a single
| boxed physical release, the game would be left with a shorter
| development cycle limited by the production budget. Now, the
| game's sales more directly dictate the level of attention the
| game gets. Concepts are validated earlier and customers get to
| more frequently provide feedback rather than developers
| spending years building something and hoping that people like
| it.
|
| That particular developer also did a great job of generally not
| breaking your world and save game (somewhat unlike similar
| creative/survival games like Minecraft, where you'd be missing
| out on a lot of things by not starting fresh for each major
| update).
|
| Sure, frequent updates can break things...but back in the day,
| there were still plenty of bugs on formally released products,
| and then you're stuck with those broken things for months or
| years waiting for the next version to physically ship to you.
|
| One of the things that makes CD/CI possible in the first place
| is that testing has become far more automated and
| sophisticated. No one would tolerate CI/CD if it didn't have
| that additional level of automated quality.
|
| When I see someone who claims not to like when software gets
| frequent updates, I ask myself: "Do you even _like_ software? I
| thought new functionality was supposed to be exciting! " I
| personally see resistance to change as a generally negative
| personality trait (obviously, there are limits, not all change
| is good change), and I think that's why I don't understand the
| romantic nostalgia for the days when we'd buy a piece of
| software in a box off of a shelf.
| ghaff wrote:
| > I ask myself: "Do you even like software?
|
| In many cases, no. It's an adequate tool for some task I need
| to accomplish. And while some updates are genuinely useful
| and appreciated, others are regressions or just a change that
| I now have to get used to and which IMO doesn't make the
| software a better tool for the task at hand.
| [deleted]
| tablespoon wrote:
| > I love it as a customer. There's a lot of excitement when
| new changes come out, and I want them right now!...
|
| > When I see someone who claims not to like when software
| gets frequent updates, I ask myself: "Do you even like
| software? I thought new functionality was supposed to be
| exciting!" I personally see resistance to change as a
| generally negative personality trait (obviously, there are
| limits, not all change is good change), and I think that's
| why I don't understand the romantic nostalgia for the days
| when we'd buy a piece of software in a box off of a shelf.
|
| You seem to be thinking about this through the lens of
| computer games, which is probably not the right one to bring
| the problem into focus (then you pile on a bunch of personal
| judgement, which is frankly irritating).
|
| Also, why should anyone "like software" (as a broad
| category)? That seems like putting the cart before the horse.
| I use software because it solves a problem I want solved
| (ideally with minimal effort); I don't find problems just to
| put software to use because I "like software." You don't seem
| to realize that "update" does not _necessarily_ mean
| "improvement". Often an update is actually a _regression_ to
| the user (most obviously because of bugs, but more
| perniciously through annoying changes like unnecessary UX
| redesigns or dropping features). I 'm not "excited" when my
| workflows get broken or having my knowledge invalidated (e.g.
| changes that force me to waste effort re-learning how to do
| things I already knew how to do).
|
| The nostalgia about buying software in a box off a shelf is
| nostalgia for having problems that stay solved. If that
| software worked, it would almost certainly continue to work
| until _you_ made the decision to change something. Not
| anymore.
| tomc1985 wrote:
| > When I see someone who claims not to like when software
| gets frequent updates, I ask myself: "Do you even like
| software? I thought new functionality was supposed to be
| exciting!"
|
| Taking away a much loved feature is exciting? Losing more and
| more control over your own computer, over things you paid
| for, is exciting? Waiting an hour for your PS4 to install
| mandatory updates because you haven't turned it on in a few
| months is exciting?
|
| Good god this is such a naive opinion. I suppose you think
| _all_ change is good? Even if the people implementing them
| are greedy assholes in search of ego strokes or power trips?
|
| What if I changed the balance of your checking account to $0?
| Would that be an exciting change?
|
| For every update that delivers on its exciting new promise,
| there are four others that have made the life of its
| developers easier at the cost of their users.
|
| Developers are the ones getting paid beaucorp bucks here,
| making their life easier should not be a higher priority than
| supporting things that users want.
|
| Speaking as a developer and lifelong computer nerd of 30+
| years.
| gspencley wrote:
| > When I see someone who claims not to like when software
| gets frequent updates, I ask myself: "Do you even like
| software?"
|
| I used to. That's why I've dedicated 30 years of my life to
| making it.
|
| But to be honest, not so much anymore. It's not just about
| breaking things, it's about CHANGING things. Things you paid
| for. Things you agreed to purchase in a certain shape and
| form. Forget video games, I'm talking about every day tools
| you use and depend on to do your daily job or life functions.
| Things like online banking - my bank suddenly rolled out a
| complete UX overhaul of their online system and omfg is it
| ever worse than it was before... I now need to take multiple
| steps and clicks to do something I used to be able to do in
| one step. They also broke the browser's back button etc.
|
| And why does this happen? Not because brilliant teams of
| seasoned experts sat around the table, did focus groups and
| market research with existing customers to figure out how to
| make the product better. But because a lone Product Owner
| sees a path to promotion if they can figure out that one
| single killer feature that will get a massive new adoption of
| hypothetical new users (hardly ever realized). And so we, the
| end user, end up perpetual sacrificial guinea pigs in a never
| ending experiment that throws us under the bus because the
| business is chasing a hyper growth they are very unlikely to
| see.
|
| If you're dealing with something like an indie video game,
| made by an individual or a small team of passionate people
| who actually care about their existing users and what to make
| things better for them then you're going to have a different
| experience. 99% of the tech industry today is not even in the
| same universe, let alone ballpark, as that.
| maestroia wrote:
| >But because a lone Product Owner sees a path to promotion
| if they can figure out that one single killer feature that
| will get a massive new adoption of hypothetical new users
| (hardly ever realized).
|
| This++. It's also the young hotshot phenomenon, where they
| come in and decide they can do everything better than the
| old timers (the previous hotshots 3-4 years ago), and
| change everything they can. We've all been there.
|
| I have elderly family members, 85-plus, who can't
| understand why the UI changes all the time and they have to
| continually relearn. Explained this way, they get it, but
| still say, "they need to remember that not everyone wants
| to relearn everything every couple of years".
| amatecha wrote:
| Yeah, I get frustrated about this A LOT. "Change for the
| sake of change", and chasing meaningless KPIs and metrics
| that involve ZERO value to users and only serve to
| benefit the vendor (usually at the expense of users, in
| fact).
| dangus wrote:
| To me, disliking greedy corporations and bad management
| isn't very connected to the method of delivery of products.
| Frequent and often automatic updates just represent that
| delivery method.
|
| In contrast to your bank, my bank's website has added
| numerous improvements and modernizations that have made it
| easier, more useful, and less frustrating. Perhaps it's
| just time to switch banks?
|
| There are plenty examples of badly managed products in the
| pre-SaaS era. If you bought Windows Me, it shipped as a
| terrible product and it never got better. As soon as you
| opened the shrink wrap you had no recourse but to wait for
| Windows XP to fix those problems.
|
| Grand Theft Auto: Vice City featured a bug where saving at
| the ice cream factory was very likely to corrupt your save.
| The PS2 had no ability to apply patches or updates to
| games, so you were just stuck with the software that way
| forever.
|
| So, you "agreed to purchase it in a certain shape and form"
| - but just like any other product you never truly know what
| you get until you made the purchase.
| gspencley wrote:
| You're straw-manning and shifting the goal post.
|
| I have no problem with greedy corporations. What I don't
| like is people changing stuff on me when I didn't opt in
| to that change. Imagine if someone broke into your house
| and rearranged all your furniture. That's what it feels
| like. I don't like not owning my software and not being
| in control of things I pay for. I don't like not getting
| to decide if/when I upgrade and what I upgrade to. No one
| had to upgrade to Windows ME. That's my one and only
| point.
|
| I don't know why you keep trying to shift the
| conversation back to video games. Video games are a very
| different type of software from most and I don't play
| them or have any interest in them. They're completely
| irrelevant to the conversation as far as I'm concerned.
| dangus wrote:
| Respectfully, I'm not straw-manning nor am I shifting any
| goal posts. Whether or not you agree with my arguments, I
| believe I am making them as consistently I can and in
| good faith.
|
| I'm using video games are an easy example because it's
| simple to point to a specific gameplay bug that every
| player will encounter in those boxed games. Those kinds
| of experiences aren't as well documented for older
| productivity software. I understand you don't like video
| games but you should be able to understand the concept of
| my argument, for all purposes of our discussion these
| games can be considered to be generic software.
|
| My overarching argument revolves around my belief that
| the bad things about software revolve around its business
| model, not from its delivery method in isolation.
| amatecha wrote:
| Yeah, we like software. Probably every single person reading
| this site does. What we don't like is having constant new
| crap added that doesn't actually benefit us as users (like
| constantly-shifting user interface, new limitations that
| didn't exist before, "overhauls" that remove functionality we
| relied on or expected or were otherwise intimately familiar
| with). It's a waste of our time and energy, and causes
| stress.
|
| Yeah, new functionality is neat, but it's an ignorantly-
| optimistic delusion to believe that frequent updates strictly
| involve new functionality. It's extremely common that updates
| involve literally zero benefit to the user, instead
| introducing some bullshit we didn't want like a "What's
| New?!" popup that now harasses every time you open the
| software (Miro, Discord, etc.), or a new notification icon
| that glows blatantly every time there's a new _Awesome Sale_
| available (looking at you, Guild Wars 2).
| jmclnx wrote:
| >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
| mobilene wrote:
| I do acknowledge that my experience was a sample space of one!
| mixmastamyk wrote:
| 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 wrote:
| 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.
| krallja wrote:
| When you say "northeast," do you mean more like Boston, NYC, or
| Kennebunkport?
| botswana99 wrote:
| ...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.
| trumbitta2 wrote:
| The last paragraph story is so "Lean Startup" I'm crying
| leohonexus wrote:
| 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 :)
| gbronner wrote:
| 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.
| ChrisMarshallNY wrote:
| 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 wrote:
| >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.
| wazoox wrote:
| 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 wrote:
| wonderful writing - looking forward to pt2!
| remoquete wrote:
| 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
| mobilene wrote:
| Thank you! I enjoyed writing those behemoth 300-page manuals.
| The tech writing world has changed so much since those days!
| eternalban wrote:
| > 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 wrote:
| I forget that I was in the Midwest, not on the coasts, and
| things were likely different in this regard on the coasts.
| sammalloy wrote:
| 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.
| imiric wrote:
| 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...
| LAC-Tech wrote:
| 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 wrote:
| Call it hybrid-agile and let's make bank consulting it.
| jdlshore wrote:
| 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.
| beckingz wrote:
| 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.
| smm11 wrote:
| 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.
| fjfaase wrote:
| 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 wrote:
| 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 wrote:
| Shelves and shelves of tidy orange binders. I had them too!
___________________________________________________________________
(page generated 2022-07-11 23:00 UTC)