norwayjose's comments

On my Mac I accomplish email backups using the Mail app and Chronosync. I have filtering rules to automatically file messages into multiple IMAP mailboxes based on sender or subject. I periodically manually move messages older than a week to local mailboxes to keep my iCloud storage from getting large enough to require paying for additional storage. The Mail app can also export those local mailboxes to a folder which I then back up using Chronosync so I have local copies on multiple drives.

The whole process only takes about 5 minutes once every week or two. It gives me easy access to over 20 years of email which is nice to have even though I only search the old ones a few times a year.

I started my career as a field engineer (basically a computer mechanic) on mainframes and minicomputers 47 years ago. For the first 13 years, almost every computer I worked on had front panel switches and lights which was great for writing and debugging tiny diagnostic programs. I wrote those diags directly in machine code because I had the CPU instruction manuals, no access to an assembler, and a fair amount of free time when I worked a midnight shift on call. I'd sit at a desk, writing the machine code on lined paper because the sites I worked at rarely had graph paper in the supply cabinet. At first I had to look up the op codes for the instructions I wanted but I was able to memorize the ones I used most often which made it a quicker process. The fun part was using the toggle switches to enter those instructions and finally to start it running.

After 6 years of being a field engineer and writing exclusively in machine language, I made the switch to being a systems analyst which gave me access to an assembler. That seemed easy after having to calculate relative jumps/subroutine calls for so long.

Here's what I term my "flypaper" movies. If I happen to glance at the satellite TV guide and notice one of these coming up, there's a good change I'll be watching it.

  Lawrence of Arabia
  The Maltese Falcon
  Most Hitchcock films
  Blade Runner
  The Man From Snowy River
  The Martian
  Monty Python & the Holy Grail
  The Princess Bride
  Serenity
  The Thin Man series
  The Thing
  Tombstone
  Young Frankenstein
  Monty Python and the Holy Grail
  Clerks and most Kevin Smith movies
  Baby Drive and most Edgar Wright movies
  Fanboys
  Spinal Tap
  Kung Fu Hustle
  Apollo 13

I've been in the industry for 47 years - first 5 in hardware followed by 42 in software/firmware. Most of my past 32 years have been spent doing system level code in C which I still enjoy. I've had a few short stints as an acting manager and have managed to reject management's attempts to make those permanent each time because I enjoy spending my days solving problems.

It has gotten harder to remember what I've worked on lately. For the past 15 years, I've been keeping notes in text files to remind me of what I work on each day. It's far easier to do a recursive grep on my top level notes directory than it is to find something in Outlook. I also make heavy use of Confluence to document everything I work on. I think I've created more Confluence pages than the rest of my group combined.

I've kept in touch with a number of people I've enjoyed working over the years with which has made it much easier to find jobs when I need to make a change. For the past 20 years, I've maintained a mailing list to organize weekly happy hours with some of them. I got hit by a RIF 5 years ago (first time in 47 years, believe it or not) and managed to line up a new job in 2 months thanks to a hardware engineer I had enjoyed working with 32 years ago. I also had a few whiteboard interviews during that time which helped remind me why I hate the traditional way of finding jobs.

In roughly the frequency of usage - Kindle, Inoreader, Octal, Audible, Libby, Hoopla, Overcast.

Aeron chair - I bought this in 1999 and it's been much more comfortable than any chair I've used at any office I've ever worked in.

4k monitor - Picked this up on a Black Friday sale 1.5 years ago. It's much easier on my eyes than the HD monitor my company provides in the office.

KVM - Allows me to switch between my work laptop and some of the higher end embedded machines I work with. I end up needing to swap cables at work.

I tried but the survey kicked me out because my schedule is unusual. I typically work from home 4 days per week with only 1 day in the office.

In the late 1970s, we used dial up modems (the kind with the klunky acoustic coupler) to dial into Honeywell's response center to close out repair calls. I also discovered they had games on the response center computer and was able to entertain myself on quiet night shifts by playing Adventure and Star Trek on a TI Silent 700 terminal.

Some of the mainframes we servicced were also connected to ARPANET which provided networked access to university and various government agencies. I know there was an ARPANET worm around 1980. Not sure if there was hacking prior to that.

Thanks. That's interesting. I've only seen the outside of IBM mainframes in the few computer rooms which had both types of machines.

For Honeywell mainframes, the maintenance contract required an onsite office for field engineers. In those offices were stored spare parts (mostly for peripheral devices), larger tools such as oscilloscopes, and the repair documentation which took up a lot of space. The CPUs for Honeywell mainframes contained about 80 large circuit boards (about 12" square as I recall) which were too expensive to have a full set of spares on each site. For those, we had several district offices with more extensive parts departments. Field engineers had to carry a small toolkit with them which in addition to traditional tools contained soldering irons and wire-wrap tools.

I worked in the northern VA district. On weekends we also had to cover DC and parts of MD which was a wide area to cover. Once I was at a site in VA and got a call at the Naval Academy which was over 100 miles away. I wasn't able to make the obligatory 2 hour response time for that call.

I worked as a field engineer on Honeywell mainframes in the late 1970s and later moved into programming so I'm always keen on hearing about the good old days when computers looked impressive. I'd be interested in hearing about their most challenging debugging problems. I'd also like to hear about how your grandfather serviced core memories back in the day. Honeywell core memories had spare bits built in which made is easy to bypass a failing sense amp.

That sucks. Almost 4 years ago I got hit by a layoff for the first time. When it happened I'd been in the industry 42 years. I spent 4 months on unemployment searching job sites and having mostly frustrating interactions with headhunters.

The thing I did which helped most was reaching out to my network as soon as it happened. I ended up with an offer and another company interested thanks to friends I'd worked with at previous jobs. If you've already notified friends, don't be shy about reminding them you're still out of work.

I've been programming professionally for 40 years but don't consider myself a master. I think the term is overused and applies best to people such as Ken Thompson, John Carmack, and Michael Abrash. I'd also use it for a handful of really bright people I've worked with over the years.

As others here have said, the key to being good at anything is to do it often. While it's useful to be able to solve problems on a whiteboard during an interview, during a long career you'll probably be asked to work on many problems which are new to you. Researching new protocols, architectures, software libraries, and peripheral chips may be required. Figuring out how to debug problems in new environments can be essential as well.

I'm an embedded firmware engineer and feel fortunate that I continue to find my job fascinating. I do lots of technical reading to keep up with the field. In addition to the documentation for the chips and tools we use, I read quite a few technical blogs via an RSS reader. I also follow a number of technical subreddits.

I've signed up for developer accounts at the manufacturers of chips we use. One of them has partnered with a company which provides free webinars as well as more extensive in-person training. While it can be challenging to get your company to pay for training, few will object to you taking a free webinar during your lunch hour.

Digital Apollo: Human and Machine in Spaceflight by David A. Mindell

Gray Hat Python: Python Programming for Hackers and Reverse Engineers by Justin Seitz