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!
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.
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.
"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.
Read some ancient Greek history texts that have been translated into English. The world is much faster now but absolutely nothing has changed with us.
Favourite example (Thucydides, could be wrong) - "An old man complained to a crowd that the teenagers were spending too much time lazing around talking to the opposite sex than training to fight" (or something to that effect), ever heard that one before?
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.
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.
Someone here on HN recently mentioned Tymshare[1], which was essentially the 1964 equivalent of AWS. Apparently CompuServe also started as a similar cloud service company in 1969.
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?
> we have faster computers, higher level languages
There was already LISP, COBOL and (a few years later) Algol 68, so maybe the only real improvement is the faster computers, making the high-level languages more widely applicable?
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.
It pays to switch jobs. If nothing else each new employer will do their best to justify the decision to offer a significant increase. They know what they have in hand. You just need to be perceived as having more potential than that.
Also keep in mind, pay is often a function of having management potential. If you're getting more for similar work it could be because they see you as having greater long term potential, or have other things to contribute sooner.
There's more to advancing in tech than tech-centric skills.
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).
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.
There will be a full writeup on this system later on, but the diskette that contained this letter of resignation was part of what remained of the author's 8" diskette library, and contained a lot of 8080/Z80 code he'd written. He's deceased now, the fellow who passed the system on to me never knew him either, but digging through that much of someone's code and notes (a banker's box of documentation), I at least sort of feel like I end up in the programmer's shoes a bit.
Unfortunately, it seems this machine had a fault in its floppy drive controller some time in late 1985 or early 1986 (files stopped being updated). The fault caused any writes at all to disk to clobber whatever was under the write heads. So, this is about the end of the information I've got w.r.t. personal correspondence, etc.
The grass is greener if you stop working for companies dominated by non-technical leadership.
Unfortunately the types who move from one corporate behemoth to another rarely see the light and continue indulging in the fantasy that one day they'll find a large old company run by non-technical leadership with respect for engineering, other good developers to collaborate with who haven't left, and processes focused on progress.
The rest of us learned the lesson and stopped working as engineers for such companies.
- I am not coding anymore.
- I am putting out the same fires I have been for the last 5 years.
- I no longer learn anything on company time. (New technologies does not equate with improvement)
- I have to devote my own time to growth.
My company's leadership is _entirely_ technical. In fact, engineering leads the whole organization, pretty much. We're still a feature factory.
Working for technical people is not a panacea to bad leadership. It just means they're better at bullshitting engineers to their face.
I've read somewhere that BMW and Audi have internal regulations in place, which dictate that at least half of the top level leadership group should always consist of people with engineering backgrounds.
I have not been able to confirm if it's true or not.
But it sounds as a healthy regulation to have in place for a technical company, since gravity seems to work in the opposite direction. Non-technical leaders will, in my experience, have a tendency towards hiring other non-technical leaders, and towards trying to mould the company operations into something which can be run without the need for technical knowledge.
And Toyota has (had?) the requirement that all employees, no matter how privileged, should regularly spend time on the factory floor doing the core business of the company: assembling cars.
I think that sort of idea makes a lot of sense to avoid losing touch.
and their cars interior is by far the worst for price range. Infotainment is so bad that sometimes the touch response happens like 4-5 seconds later on a four year old corolla hybrid. Worst interior in a car i experienced
Just the rest of stuff is so bad, i mean for a car worth 25-30k i expect a touchscreen that is not absolute lemon from the start. Or just give me an api over network/bus that someone can create an app for it and i can just run a tablet which would be a total of say (300 bucks for a decent tablet, 100 bucks for the app ).
Not a fan of teslas at all, but i hope they put the direction of industry to have a decent infotainment as default. Korean/German cars seem to have a bit better infotainment.
> just give me an api over network/bus that someone can create an app for it
Be careful what you ask for…
I got a _very_ stern talking to by legal a long time back (~2013), when I demonstrated to my boss that using the Toyota telematics and some knowledge of specific vehicles, I could locate 2 of the fleet Prius we used. I’m reasonably sure I could have popped the door locks on them too with a little more work.
I was just “playing” with some api docs I found in the company wiki.
Legal and the CTO made it very clear to me that I’d never found those docs, I’d never written any code to use those APIs, I’d never connected to any Toyota never mind one I didn’t own personally, I’d certainly never tried exploiting those APIs, and I knew _nothing_.
I hope (perhaps in vain) that things are better than they were 7-8 years ago (and that 7-8 years and the company who’s NDA I was covered by company going into receivership is long enough to tell some of the story…)
That would be fun, i know its hard to trust car manufacturers with software, but one can alwys wish.
I just wish if some company create an android/ios app, it would be definitely easier to create than working on some random hardware found in car infotainment for which its hard to find developers.
Now any tablet can be my infotainment. I only need navigation and music to be integrated in app. No other features what so ever.
Basically what volkswagen e-up / skoda e-citigo has done.
I'm not good at it either and landed at a good place by sheer luck. But once I know what a good culture looks like, next time I have to look for a new job I would try to do an extensive reverse interview to learn what their approach to architecture, planning, development and testing is. Basically I'd like to make sure that these all are driven by developers, that people care about quality, not just metrics, and that there is a long-term vision of what the team wants to deliver.
Ask who your manager will be. Look them up on LinkedIn. Look at all the people on the technical side of the company and their LinkedIns. If their last few jobs for the last several years aren't technical, that's the answer.
In general, pretty much any company that isn't a technology company will fail this test. Working for companies which are young and specifically software companies is your best bet.
I have the unpleasant task of informing you that I will be leaving __*this_crummy*__ employment as of __*shortly*__.
As you know I have not been very happy with __*the_same_old_shit*__. I have not __*seen_anything_worthwhile?*__ in a little over 3 months. I have not learned anything new in the __*professional*__ field in the past year. I have been putting out the same old fires that were here __*a_sad_number_of*__ years ago.
I will be working as a __*much_better_position*__ for __*a_truly_respected_employer*__.
I would like to take this opportunity to thank everyone who I have worked with for the past two years. I know that I will miss you all.
On the other hand, a job that is 'good enough' can make you too scared to make the jump to leave. Then you get paid less, learn less and it becomes harder to make the jump if the job stops being 'good enough'
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.
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.
> 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.
Seems very difficult to gauge quantitatively. I've changed jobs at year 2, 12, and 19. Each time, what I was interested in to make my next job better had changed based on my age as well as my accrued experience at the different jobs. And there's the fact that for someone like myself, I'm guilty of moving the goalpost. I honestly have a great job right now. Bit as I get used to that, then new things bug me.
I loved my first job. Every thing about it. But looking back in hindsight, it was a vanity project of the ceo, and was never going to recoup the manpower investment. Requirements and goal posts were ever-shifting. I was too naive to even perceive role status and did little or nothing concrete to forward my career except turn out (quality) code.
I loved it.
I would be frustrated to distraction if I were in that position now.
Great point. My first programming job in college was for a little boutique software company in town. My boss would walk into my office at noon, describe some software, and ask if I could have a PoC by 4 so he could drive over to the client and hopefully get a check to build. Now, something like that would drive me nuts, but at the time I didn't know better and it was exciting.
The one consistent thing in my career is I don't tolerate jobs that have too little work to do. I've had 2 jobs at various points in my career where was I told to just hang out for extended periods of time, and in neither case did I make it a year working there.
I've often found that the thing that made me take a new job was the change that I wanted and failed to make in the old. In fact, often enough I misjudged the new org in the interview and they had the same problems but I ended up being the force for the change that I wanted to see.
For some odd reason, it always seems like getting that inertia is easier at the next job than the current one.
You can always reduce to more material aspects, like money. Sometimes a large salary increment can make you accept much more shit.
I have incredible frustrations at my current job but the 2x increment I got compared to my amazingly fun job I had in a small company before makes me brush them off much more easily :D
Every time I've changed jobs I've been happier for maybe 12 month or so and then it felt like the same old grind as the last job. It's almost like I might be a factor as well in the whole thing and not just the job.
"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.
When I left my previous employer, I told them exactly where I was going. The mentality at the previous employer had been changing (post-takeover), and the new company was founded by, and mostly consisted of people who came from the old employer and disliked the new direction. Everybody at the new employer knew what the old employer was like. If the old boss would have made such a call as you describe, the new boss would have seen right through that.
In the case of the resignation in the link, I suspect the programmer left on amicable terms, which is also a situation where you could tell the old employer where you're going.
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).
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.
Also I used to work at a consultancy. The
unwritten rule was that clients would not
try to hire any of the consultants directly
Here (East Coast, US) this is almost always a written rule in the consultancy contract, because otherwise it is a very common case.
Usually I think it's like, "if you hire one of our consultants you owe us $xx,xxx" or something.
While I am just about always pro-worker, I accept this as a necessity.
Otherwise consultants get "poached" non-stop, because they've basically already "auditioned" for the client and the client gets an extended amount of time to figure out which ones would be great to poach. Makes it just about impossible to run a consultancy otherwise.
I once tried moving from parent company to child company.
And such a phone call made the move impossible.
Also, I've heard similar stories from people trying to move within the company to new department. Your old manager might be higher in the hierarchy and just might be an asshole.
"Hey Mike, I understand you are hiring Joe, though because of our good relationship, I'd like to tell you why exactly is Joe leaving. Well, we didn't want to cause an uproar in the company, but Joe caused this one issue that cost us $100M and his behavior was exceedingly erratic." Now mix in some typical subconscious behavior of Joe that anyone could notice in 10 minutes and build some story on top of it so that the new manager has it always in front of his eyes. That's how intelligent character assassination works these days. Many managers got to the position of power by using these "dark techniques" so they know how to do it properly without raising a suspicion.
Don't tell anyone where are you going. Don't put it on your LinkedIn until you are established there.
If Joe costed you $100M and his behavior was exceedingly erratic, why didn't you let him go? You should be happy to have such a problematic employee go. If you _did_ let him go, why are you stalking him and make his life even harder? In both cases, I would rather talk with Joe directly over a manager who's either lying or causing harm to his employees. It's also not like hiring managers form some kind of a club, warning each others about bad hires.
That's actually the opposite to what people do here in Sweden. Because once that letter goes out to everyone the new contract is already signed and the current employment is already terminated.
We usually have 1-3 months resignation period, so there is no resignation letter. The closest we have is a goodbye letter that goes out to all your co-workers. And this letter reminds me most of those.
The actual resignation is done in person with your manager. Of course you could do it over e-mail but I'd be willing to bet 99.99 out of 100 times your manager would schedule a 1-on-1 meeting with you if they received such a resignation.
Surely you'd put something in writing when you wish to resign?
In Britain, I'd print out and sign something like this:
Dear [Manager]
I wish to offer my resignation with effect from 14 June 2021.
I am obliged to give 3 months notice. Therefore, my last day of service will be 14 September 2021.
Yours sincerely
Anything else is optional, and can be discussed with the manager if you want to, or not.
Yes that is true, just a simple "I quit", dated and signed is enough. Just to make it formal. But my point was that this happens 1-3 months before your last day so any personal opinions are much better handled in a 1-on-1 meeting with the manager, and of course aired in your final "goodbye letter" after your 1-3 month period is over.
Every time I've quit I've done so by just verbally informing my boss. Then a couple of weeks later I get a piece of paper from HR that I have to sign confirming my last day of service.
I think that's common through all of Europe, but a petty manager that's out for blood can call you next manager and 'tell' him how bad of hire you are and that getting rid of you if for the best.
if the new manager believes him you can be let go in your probation period, and end up with no job.
I heard of this done once or twice through friends.
Bullshit. If some guy calls me claiming that my new hire is bad, that automatically rings all kinds of alarm bells. Only someone that is some kind of psycho would try such petty revenge.
Speaking as a such a boss, the idea of doing ‘bad things’ to somebody in the name of team retention seems rather counterproductive!
If somebody’s made up their mind to leave, the best you can do is ensure it’s as amicable as possible, then a thorough exit interview to understand where you went wrong and try to fix those issues to course correct & retain others.
That is the best mature, professional people can do.
Spiteful incompetents, on the other hand, don't think that there are issues they should fix (the employee isn't a good fit); are afraid of exit interviews; and can be unprofessional enough to burn bridges and damage the company in order to damage the quitting employee.
Worked for a company doing tens or hundreds of millions in sales a year (automated metrology machinery). VP did stuff like this. It was illegal in the jurisdiction in which they operated, but it happened anyway.
don't know about 'phoning the company', but someone from the previous place might consult their linked-in profile and contact some acquaintance from the new place informally, with the aim to bad mouth their former peer. I stopped updating my linked-in profile, because this is quite possible, if you have worked in a toxic work environment (in terms of security: all what is in the realm of the possible, is also likely to happen in reality)
As a hiring manager, if someone did this, I would just feel bad for the person who was on their way to me, that they had to work with people like that.
That's a very reasonable position, on the other side: as a hiring manager you probably wouldn't work with the new hire on a day-to-day basis, and you wouldn't be involved with his performance review.
Early in my career, I followed some coworkers to a new company. I was a couple months behind the others.
The perception at the old company was that everyone was poached by one of these coworkers. They got a cease and desist letter from the old company lawyers. I told people then but wished I hadn't. Everything turned out fine for me in the end though.
The next job change I had, I didn't tell anyone where I was going. I was a little scared from the last experience. Many people asked, and I politely told them I would share after I'm settled in. It was a cross country move and I didn't feel that there was any benefit to sharing where I was going ahead of time. The work environment I left was a little dysfunctional at times, and I didn't want to take any chances of someone sabotaging me or creating extra noise or rumors.
Then in my last job change, I had built good working relationships and felt comfortable sharing, so I shared freely.
Unless your boss is a total jerk, they wouldn't do that. Also, you are not as important as you think you are. Everybody is replaceable and people leave all the time. Your boss is unlikely to take the trouble to call some random person just to badmouth you. He's got better things to do. Having said all that, I still think you shouldn't tell where you are going. The reason - it serves no purpose to your old employer and they don't need to know. Your employer never gives you any information during your employment that you don't need to do your job and you are not obligated to give them any either (especially when you are leaving).
Never ever? I wouldn't mention it in the resignation letter like in the OP but it's been very natural for managers and colleagues to ask where I'm going next and I've been happy to share. I also ask colleagues who are leaving where they're going next and I never saw it as a problem. Then again, I've worked with mostly reasonable people.
Though Ive seen many people do this, and for the ones I kept in touch with, there were no repercussions. Caveat that this is in a dense area of high tech jobs so it would be difficult for a manager to have enough contacts to effect damage. Plus, those managers were pretty busy.
What I heard is that companies are not even giving detailed references for fear of being sued. They just send some boilerplate. I have always said where I would be going next and nothing bad came out of it.
This was actual policy at the company I worked for. Name, rank and serial number only (dates of employment and position).
It was frustrating. I often wanted to say good things. After leaving that company, one of the first things I did, was give a bunch of good LinkedIn testimonials.
I generally avoided badmouthing people. For one thing, there were only a couple of folks that left my team under actual unpleasant circumstances, and I feel that everyone deserves a second chance. Often, the most valuable employee, is one that has learned hard lessons.
I have also found, personally, that seeing the worst of my fellow [wo]man puts me into a rather miserable personal space, so I try to avoid that.
Also, when contacted, it was usually long after I had last dealt with them, so I felt that what I had to say would be well out of date. If I didn’t have anything good to say, I’d be very vague. That could speak for itself, but that’s the worst I would do.
> Name, rank and serial number only (dates of employment and position).
This is very common. Many companies will also add if eligible for rehire. The last one is a safe way to convey if the employee was fired for something illegal.
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.
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
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.
Maybe not officially, quote possibly as an ad hoc manager due to deficiencies in the offical management.
I've been in that position before. If you have a good relationship with your coworkers, it's more efficient to diagnose problems yourself and then ask your coworkers to fix them (i.e. play the PM role). I don't enjoy being a manager, I'd rather write code. However, I'd rather put fires out quickly by working as a team instead of playing the martyr and trying to do it all myself, or singing the "it's not my job, I'm not a PM" song while the ship is sinking.
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.
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.
... and the longer you stay in such a situation, the less sharp your programming skills become, and the less in touch you are with the way the industry is moving.
It's not uncommon at all to interview people who have 10+ years experience at <Big Co> who can't even answer basic questions about industry-wide technology you're using, because they didn't bother to stay in touch...they didn't need if for their last role and thought that that would last forever.
On the flip side, I see people get excited about <internal NIH syndrome technology> and learn all the ins and outs, and don't bother to research and find out that other companies or FOSS has been doing the same thing but better for a decade. And then, when they leave the company, that internal tech becomes inaccessible and the knowledge somewhat useless.
Doesn’t seem all that unlikely, I’ve personally gone weeks without writing code, usually leading up to a release where a lot of documentation and preparation has to be done.
Never-ending infrastructure migrations can be a contributer too. "Lets migrate to these new unix hosts, our spaghetti code will run 5 times faster after that"
