12 ms·

Programmer's Resignation from 1985

286 points by systems_glitch 5y ago

systems_glitch 5y ago
I recovered this document from an 8" floppy diskette on a S-100 system running CP/M. Interesting that, the more things change in programming, the more they stay the same!
- h2odragon 5y ago
  May I suggest adding a note to the page with (at least) that context?
  - systems_glitch 5y ago
    It'll get its own writeup with the rest of the details about the system. Just found it today and thought I'd quickly share.
    - lmas 5y ago
      Please share your writeup once you're done!
- Jach 5y ago
  Thanks for sharing, old stuff in the field is still quite relevant. One of my favorite reads in the last few years was The Psychology of Computer Programming, 1971. Very interesting to read about some problem or difficulty they faced then, and that we still face now, or that we have somewhat alleviated with certain technologies.
- jgrahamc 5y ago
  How did you do the recovery?
  - systems_glitch 5y ago
    First I repaired the S-100 system, then used a PC with 8" drive and ImageDisk to archive all of the diskettes before exploring their contents. To get individual files (rather than disk images) off of the system, I wrote a KERMIT-80 customization which allowed me to do batch file transfers from the S-100 machine to my Linux workstation.
literallyaduck 5y ago
The grass was probably not greener and eventually reached an equilibrium at the new company. This letter reminds me of my recent departure. I wasn't really coding much anymore, the company had been ignoring suggestions since I started years ago. We fought the same fires and nothing was learned on company time. I had to devote my own time to growth. Sadly we don't know the rest of the programmer's story. I'd like to know if they finally found the dream job.
- mark-r 5y ago
  I wonder in general what are the odds of finding a better job? Are they 50/50 or do they skew one way or the other?
  - AnimalMuppet 5y ago
    Depends on how bad your current job is. The better the current job, the harder it is to find something still better. There can be a halo effect - the better your current jobs, to some degree the better offers you get - but I still think that on net, you should be more reluctant to leave a decent situation. If your current job is in the top 10% of jobs, then the odds are 9 to 1 that switching will get you something worse.
    - jll29 5y ago
      > If your current job is in the top 10% of jobs, then the odds are 9 to 1 that switching will get you something worse. This is a wise insight. It therefore would be good if developers had created a Glassdoor-like site where people can enter technical details about their jobs (languages used, appreciation of refactoring, software tools, pair programming, technical documentation, use of version control, A/B testing, unit tests, UML, ...) in order to permit people to get a sense of what they're getting into. Asking about this at interviews is not productive, as hiring managers may bend the truth a bit to get talent on board.
    - mlac 5y ago
      I’ve seen a similar idea with employees, but a bit more forgiving. I can’t find the article, but it was about when it makes sense to replace someone vs keep them. The idea was to keep them if they get 70% of their work correct / do 70% of the job well and go to the market for a new hire if they don’t hit that. It seems low, but with the inefficiency caused by turnover I guess 70% is where they settled.
traeregan 5y ago
What was an Application Engineer who has "not written any code for 3 months" doing for that amount of time then? Surfing Usenet? It seems like putting out fires would've involved at least some code.
- systems_glitch 5y ago
  Probably getting stuck managing other engineers or teams of them.
- icedchai 5y ago
  Meetings? Documentation? Support calls? These all can take tons of time.
- cratermoon 5y ago
  You might be surprised how fast time can pass when you're in a holding pattern while management dithers over the quarterly priorities.
- mandelbrotwurst 5y ago
  In addition to all of the things other commenters have mentioned, it may also have just been an exaggeration, and they're not counting things like fixing logical and configuration errors as writing code.
  - ahelwer 5y ago
    Yeah. Hacking together a deployment or CI script is basically an exercise in figuring out which API calls take what parameters, and I would not count it as programming for the purpose of retrospectively feeling like I wrote code.
- burntoutfire 5y ago
  The more senior you are, the less code you write. Also, the bigger the organization, the less code you write.
  - 5y ago
biglost 5y ago
As a rule, you never, ever tell about your new job nor position, your boss could call your new future boss and you could lose the job.
- sigstoat 5y ago
  > your boss could call your new future boss and you could lose the job and say what? "hey yeah that guy who worked for us until leaving of his own accord is total garbage, you don't want to hire him"? they'd sound like an idiot doing that.
  - fian 5y ago
    In the past senior people at major companies that were competitors entered into agreements not to poach staff from each other. I have seen this happen to a colleague who tried to leave for a competitor. His manager at his current job found out, contacted their counterpart at the competitor and got the job offer rescinded. Needless to say, my colleague was extremely pissed off and ended up exiting to a non-competitor as soon as possible. Also I used to work at a consultancy. The unwritten rule was that clients would not try to hire any of the consultants directly, especially if they had been seconded in to the client for an extended period. If a consultant applied for an advertised position, it wouldn't be blocked but would be frowned on and cause tension for the client with the consultancy (usually an increase in rates).
    - bencollier49 5y ago
      Your first example is illegal in most places. The second is perfectly normal practice - it's in most contracts and stands to reason - if you're introduced to a client by your employer and you jump ship to work for them, it represents a breach of trust.
      - greenyoda 5y ago
        > Your first example is illegal in most places. But that didn't stop it from happening in some of the largest companies in Silicon Valley: https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_Litigation https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...
bsd44 5y ago
"I have not written any code in a little over 3 months. I have not learned anything new in the software field in the past year. I have been putting out the same old fires that were here two years ago." WOW that's just like 2021! Well the tech changed, but human behaviour stayed the same.
- kqr 5y ago
  It's been that way at least since the mid-sixties. I recommend going back to the early written material. By learning which parts of what was hard then are still hard now, we get a sense of where to focus our efforts. (As far as I've been able to tell, only three real problems have been solved since 1968: we have faster computers, higher level languages, and version control. All the other software engineering problems are just as hard now as they were then: We're still struggling with skill drain to management, thinking knowledge workers are fungible, team organisation, verifying features with users before building them, choosing proper abstractions, testing for reliability and understanding, resource management, documentation, modeling the domain clearly, prototyping the right way, and so on.
  - kasey_junk 5y ago
    Hardware acquisition has gone from something that took multiple year planning cycles to push button. I largely agree that we are still solving many of the old problems but by enumerating only three things that have improved you do us a bit of a disservice.
    - kqr 5y ago
      That's an important one I hadn't thought of! One reason is personal bias: I work in a place that still orders physical hardware for the most part. Another reason is that the early software engineering papers and articles I've read haven't brought up hardware acquisition as a problem. Maybe they just didn't know it was a problem, or software is flexible enough to make it okay with slower hardware cycles?
    - ptx 5y ago
DonHopkins 5y ago
>I will being working as a systems programmer for Lear Siegler Inc. Avionic Systems Corps. Did you get an ADM-3A? https://en.wikipedia.org/wiki/ADM-3A https://en.wikipedia.org/wiki/ADM-3A >The initials "ADM" were referred to as meaning "American Dream Machine" in some advertising.
- fm2606 5y ago
  >The use of the HJKL keys for moving the cursor in the vi editor and its descendants originated from the ADM-3A And now we know!
  - systems_glitch 5y ago
    And why ~ is home in *NIX, they're on the same keycap.
- fnord77 5y ago
  I used one of these in college! I bet they all got thrown away :(
  - systems_glitch 5y ago
    If you went to UVA, I ended up with a bunch of them :P
- systems_glitch 5y ago
  Heh, not with the system, it came with a rebadged Televideo TVI950. I do have an ADM-3A and ADM-5 though, largely for the UNIX/vi heritage.
benjaminwootton 5y ago
I recently googled a few phrases about being disenchanted with programming and big companies. I found some great forum posts from 2003 which really seemed to capture and articulate my views. Check the posters name and it was.... 2003 me! Exactly the same issues about not getting anything done and architecture astronauts 18 years later! Big company IT. The more it changes the more it stays the same.
- postit 5y ago
  Every 10 years my career repeats itself. I’m solving the same problems I was solving back in 2011
  - jaclaz 5y ago
    Of course, nothing personal, but as an user (not programmer) I have the feeling that programmers are given the same problems and fail to actually solve them like they failed 10 years ago. You might be the exception, but - again as an user - I find the same inconsistencies or bugs or more generally "queer" behaviour in programs that I found 10 years ago, so something (not necessarily the pure programming part) must be "wrong" in the way they (the programs/apps) are conceived, released or tested (or non-tested).
- chiefalchemist 5y ago
  It goes back longer than that. What's confusing is leadership and management continues to believe they hold all the cards. As if there's no demand for the skills their people possess. They often say "We can't find good people" when they should be asking "Why are best people always leaving?" That lack of self-awareness is what drives the turnover rate.
  - obedm 5y ago
    i love the typical "we are willing to pay this good candidate 30%" more than our current engineers. Even tho he knows nothing". And then go on to not raise the experiences engineers salaries so that the new guy has the highest salary. And then they're surprised when the veterans just leave the company.
chiefalchemist 5y ago
My knock on my previous to jobs was leadership / management (lack of) delivering on what was discussed in the interview (nature of the work, team, culture, future, etc.) vs no updates (read: communication) as things evolve in different direction(s). Yes, difficult conversations. I understand things can and do change. But assuming I'm onboard with whatever (without even asking me) was for me an invitation to look elsewhere. It's as if they didn't understand the market favors the engineers. And that with rare exception there's more sea for well-qualified fish.
darepublic 5y ago
The current project is always a dumpster fire but don't worry, rewrite in shiny new framework is just around the corner. What, analyze the issues with our current code? Don't waste our time
andrewem 5y ago
"Application Engineer" probably means an engineer who does high-level technical support for customers, as it did when I worked for a company which sold products to technical users in the 1990s. Your customer buys some complex electronic part or system from your company and then tries to use it in some demanding application. When it doesn't work as expected, an "AE" is called to debug the setup and educate the customer on how to properly use the company's product. In such a role, you're not part of the product development organization, so you might spend all your time training or debugging (edit: adding for clarity - training customers and debugging their systems), and none of your time writing any code; and anyway what code you write might well be examples or proofs of concept for customers.

I recovered this document from an 8" floppy diskette on a S-100 system running CP/M. Interesting that, the more things change in programming, the more they stay the same!

h2odragon 5y ago
May I suggest adding a note to the page with (at least) that context?
- systems_glitch 5y ago
  It'll get its own writeup with the rest of the details about the system. Just found it today and thought I'd quickly share.
  - lmas 5y ago
    Please share your writeup once you're done!
Jach 5y ago
Thanks for sharing, old stuff in the field is still quite relevant. One of my favorite reads in the last few years was The Psychology of Computer Programming, 1971. Very interesting to read about some problem or difficulty they faced then, and that we still face now, or that we have somewhat alleviated with certain technologies.
jgrahamc 5y ago
How did you do the recovery?
- systems_glitch 5y ago
  First I repaired the S-100 system, then used a PC with 8" drive and ImageDisk to archive all of the diskettes before exploring their contents. To get individual files (rather than disk images) off of the system, I wrote a KERMIT-80 customization which allowed me to do batch file transfers from the S-100 machine to my Linux workstation.

literallyaduck 5y ago

The grass was probably not greener and eventually reached an equilibrium at the new company. This letter reminds me of my recent departure. I wasn't really coding much anymore, the company had been ignoring suggestions since I started years ago. We fought the same fires and nothing was learned on company time. I had to devote my own time to growth. Sadly we don't know the rest of the programmer's story. I'd like to know if they finally found the dream job.

mark-r 5y ago
I wonder in general what are the odds of finding a better job? Are they 50/50 or do they skew one way or the other?
- AnimalMuppet 5y ago
  Depends on how bad your current job is. The better the current job, the harder it is to find something still better. There can be a halo effect - the better your current jobs, to some degree the better offers you get - but I still think that on net, you should be more reluctant to leave a decent situation. If your current job is in the top 10% of jobs, then the odds are 9 to 1 that switching will get you something worse.
  - jll29 5y ago
    > If your current job is in the top 10% of jobs, then the odds are 9 to 1 that switching will get you something worse. This is a wise insight. It therefore would be good if developers had created a Glassdoor-like site where people can enter technical details about their jobs (languages used, appreciation of refactoring, software tools, pair programming, technical documentation, use of version control, A/B testing, unit tests, UML, ...) in order to permit people to get a sense of what they're getting into. Asking about this at interviews is not productive, as hiring managers may bend the truth a bit to get talent on board.
  - mlac 5y ago
    I’ve seen a similar idea with employees, but a bit more forgiving. I can’t find the article, but it was about when it makes sense to replace someone vs keep them. The idea was to keep them if they get 70% of their work correct / do 70% of the job well and go to the market for a new hire if they don’t hit that. It seems low, but with the inefficiency caused by turnover I guess 70% is where they settled.

traeregan 5y ago

What was an Application Engineer who has "not written any code for 3 months" doing for that amount of time then? Surfing Usenet? It seems like putting out fires would've involved at least some code.

systems_glitch 5y ago
Probably getting stuck managing other engineers or teams of them.
icedchai 5y ago
Meetings? Documentation? Support calls? These all can take tons of time.
cratermoon 5y ago
You might be surprised how fast time can pass when you're in a holding pattern while management dithers over the quarterly priorities.
mandelbrotwurst 5y ago
In addition to all of the things other commenters have mentioned, it may also have just been an exaggeration, and they're not counting things like fixing logical and configuration errors as writing code.
- ahelwer 5y ago
  Yeah. Hacking together a deployment or CI script is basically an exercise in figuring out which API calls take what parameters, and I would not count it as programming for the purpose of retrospectively feeling like I wrote code.
burntoutfire 5y ago
The more senior you are, the less code you write. Also, the bigger the organization, the less code you write.
- 5y ago

biglost 5y ago

As a rule, you never, ever tell about your new job nor position, your boss could call your new future boss and you could lose the job.

sigstoat 5y ago
> your boss could call your new future boss and you could lose the job and say what? "hey yeah that guy who worked for us until leaving of his own accord is total garbage, you don't want to hire him"? they'd sound like an idiot doing that.
- fian 5y ago
  In the past senior people at major companies that were competitors entered into agreements not to poach staff from each other. I have seen this happen to a colleague who tried to leave for a competitor. His manager at his current job found out, contacted their counterpart at the competitor and got the job offer rescinded. Needless to say, my colleague was extremely pissed off and ended up exiting to a non-competitor as soon as possible. Also I used to work at a consultancy. The unwritten rule was that clients would not try to hire any of the consultants directly, especially if they had been seconded in to the client for an extended period. If a consultant applied for an advertised position, it wouldn't be blocked but would be frowned on and cause tension for the client with the consultancy (usually an increase in rates).
  - bencollier49 5y ago
    Your first example is illegal in most places. The second is perfectly normal practice - it's in most contracts and stands to reason - if you're introduced to a client by your employer and you jump ship to work for them, it represents a breach of trust.
    - greenyoda 5y ago
      > Your first example is illegal in most places. But that didn't stop it from happening in some of the largest companies in Silicon Valley: https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_Litigation https://en.wikipedia.org/wiki/High-Tech_Employee_Antitrust_L...

bsd44 5y ago

"I have not written any code in a little over 3 months. I have not learned anything new in the software field in the past year. I have been putting out the same old fires that were here two years ago." WOW that's just like 2021! Well the tech changed, but human behaviour stayed the same.

kqr 5y ago
It's been that way at least since the mid-sixties. I recommend going back to the early written material. By learning which parts of what was hard then are still hard now, we get a sense of where to focus our efforts. (As far as I've been able to tell, only three real problems have been solved since 1968: we have faster computers, higher level languages, and version control. All the other software engineering problems are just as hard now as they were then: We're still struggling with skill drain to management, thinking knowledge workers are fungible, team organisation, verifying features with users before building them, choosing proper abstractions, testing for reliability and understanding, resource management, documentation, modeling the domain clearly, prototyping the right way, and so on.
- kasey_junk 5y ago
  Hardware acquisition has gone from something that took multiple year planning cycles to push button. I largely agree that we are still solving many of the old problems but by enumerating only three things that have improved you do us a bit of a disservice.
  - kqr 5y ago
    That's an important one I hadn't thought of! One reason is personal bias: I work in a place that still orders physical hardware for the most part. Another reason is that the early software engineering papers and articles I've read haven't brought up hardware acquisition as a problem. Maybe they just didn't know it was a problem, or software is flexible enough to make it okay with slower hardware cycles?
  - ptx 5y ago

DonHopkins 5y ago

>I will being working as a systems programmer for Lear Siegler Inc. Avionic Systems Corps. Did you get an ADM-3A? https://en.wikipedia.org/wiki/ADM-3A https://en.wikipedia.org/wiki/ADM-3A >The initials "ADM" were referred to as meaning "American Dream Machine" in some advertising.

fm2606 5y ago
>The use of the HJKL keys for moving the cursor in the vi editor and its descendants originated from the ADM-3A And now we know!
- systems_glitch 5y ago
  And why ~ is home in *NIX, they're on the same keycap.
fnord77 5y ago
I used one of these in college! I bet they all got thrown away :(
- systems_glitch 5y ago
  If you went to UVA, I ended up with a bunch of them :P
systems_glitch 5y ago
Heh, not with the system, it came with a rebadged Televideo TVI950. I do have an ADM-3A and ADM-5 though, largely for the UNIX/vi heritage.

benjaminwootton 5y ago

I recently googled a few phrases about being disenchanted with programming and big companies. I found some great forum posts from 2003 which really seemed to capture and articulate my views. Check the posters name and it was.... 2003 me! Exactly the same issues about not getting anything done and architecture astronauts 18 years later! Big company IT. The more it changes the more it stays the same.

postit 5y ago
Every 10 years my career repeats itself. I’m solving the same problems I was solving back in 2011
- jaclaz 5y ago
  Of course, nothing personal, but as an user (not programmer) I have the feeling that programmers are given the same problems and fail to actually solve them like they failed 10 years ago. You might be the exception, but - again as an user - I find the same inconsistencies or bugs or more generally "queer" behaviour in programs that I found 10 years ago, so something (not necessarily the pure programming part) must be "wrong" in the way they (the programs/apps) are conceived, released or tested (or non-tested).
chiefalchemist 5y ago
It goes back longer than that. What's confusing is leadership and management continues to believe they hold all the cards. As if there's no demand for the skills their people possess. They often say "We can't find good people" when they should be asking "Why are best people always leaving?" That lack of self-awareness is what drives the turnover rate.
- obedm 5y ago
  i love the typical "we are willing to pay this good candidate 30%" more than our current engineers. Even tho he knows nothing". And then go on to not raise the experiences engineers salaries so that the new guy has the highest salary. And then they're surprised when the veterans just leave the company.

chiefalchemist 5y ago

My knock on my previous to jobs was leadership / management (lack of) delivering on what was discussed in the interview (nature of the work, team, culture, future, etc.) vs no updates (read: communication) as things evolve in different direction(s). Yes, difficult conversations. I understand things can and do change. But assuming I'm onboard with whatever (without even asking me) was for me an invitation to look elsewhere. It's as if they didn't understand the market favors the engineers. And that with rare exception there's more sea for well-qualified fish.

darepublic 5y ago

The current project is always a dumpster fire but don't worry, rewrite in shiny new framework is just around the corner. What, analyze the issues with our current code? Don't waste our time

andrewem 5y ago

"Application Engineer" probably means an engineer who does high-level technical support for customers, as it did when I worked for a company which sold products to technical users in the 1990s. Your customer buys some complex electronic part or system from your company and then tries to use it in some demanding application. When it doesn't work as expected, an "AE" is called to debug the setup and educate the customer on how to properly use the company's product. In such a role, you're not part of the product development organization, so you might spend all your time training or debugging (edit: adding for clarity - training customers and debugging their systems), and none of your time writing any code; and anyway what code you write might well be examples or proofs of concept for customers.