A few of my favorite programming environments

In my 40+ year career in software/firmware engineering, only 3 of the computers I've used have had what I considered superior development environments.  This type of environment makes it easy to be more productive.

The first was the Sun 3/80 Workstation i used at work in 1990 while writing software for packet switching communications equipment.  It had a Motorola 68030 CPU which is still my favorite assembly language and offered good performance.  The Sun offered my first extended exposure to Unix and it was love at first sight.  Unix was mature by that time and the development tools were top notch.  The only possible drawback was it only had a monochrome display albeit a high resolution one.  I enjoyed the way it allowed me to define a default window layout so I could have 4 terminal windows in standard locations each time I logged on.

The second machine I thought offered a great development experience was the Apple PowerMac G4 I bought for home use in 2002.  It was purchased to replace a PC because I had grown tired of Windows XP plus I had picked up an iPod 10 GB music player which integrated much better with Mac machines than it did with Windows.  The PowerMac G4 ran OS X, a Unix like OS derived from NeXT's NeXTSTEP. It had a PowerPC G4 CPU which was my first exposure to the RISC architecture.  OS X came with the X11 (aka X Windows) window manager which was also used on the Sun workstation.  X11 enabled me to run many of the same tools I had grown used to using on the Sun.  At the time I was working for an optical networking startup.  Some of the boards in our networking equipment used PowerPC G3 and G4 CPUs so it was handy having one at home to experiment with.  The Mac also gave me an environment which was very close the the Sun I had started using 12 years earlier with the added benefit of supporting a color display.  I've come to love color syntax highlighting of source files.  I eventually made the switch to Intel Macs and then Apple's own CPUs.  Sadly, they also seem to be making Mac OS look more like the iOS used on their mobile devices at the cost of making it less useful as a development machine.

The third (and my current favorite) development environment I've considered exceptional is a Raspberry Pi 5 which runs a multicore 64-bit ARM CPU.  It still amazes me that I could built a reasonable development machine (8 GB memory, 500 GB SSD storage) for less than $200.  Since it runs Linux with X11, I'm once again able to run the same tools (or their successors) on this machine.  It integrates better with the small embedded ARM machines I write firmware for than does my work laptop running Windows 10 or my Mac Mini which runs the latest iteration of MacOS.  Sadly X11 is no longer easy to get running on the Mac.  I know some will think I need to migrate to Wayland but I rarely feel the need to use tools which aren't fully mature yet.

All of these machines have run Unix or Unix-derived OSes which has been my strong preference for 35 years now.  This allows me to edit source files using vi (now vim) which had a steep learning curve but rewards the initial effort by being fast and quite powerful.  Having ctags allows me to quickly jump from a reference in a source file to where the function or variable is defined.  I've used it for so long that it has become second nature to me.  I'm happy to be able to search my source code efficiently again using grep.  And I love being able to use a shell with a proper scripting language (currently bash but I've used sh, csh, and ksh in the past).  Best of all, I've still got good support for the C programming language which I view as a portable assembly language and which has been my favorite since I first learned it in 1985.

These aren't the only environments which can improve productivity.  I've worked with a few engineers who swear by Visual Studio or Eclipse and I've seen how both can help speed up common tasks.  However both have a sufficiently steep learning curve for me to ignore them.  I feel the same way about Emacs when friends point out its advantages over vim.  At this stage in my career, I'm not willing to make radical changes to a workflow I've been comfortable with for a long time at the cost of weeks to months of feeling less productive.

Antisocial with a reason

I'm sure people have noticed that I've been much less social since the start of the pandemic.  That's in large part due to the fact that my wife has autoimmune issues which put her at increased risk from viruses such as Covid-19.  To limit the likelihood of her getting infected, we both mask up whenever we're inside in public spaces.  While this is acceptable for quick shopping trips, it doesn't work well for meeting friends in restaurants or at parties unless there's an option for outdoor dining.

The need for outdoor dining has limited when it's feasible to meet people to times of the year which offer reasonable temperatures to brave the patio.  Those times happen to coincide with when I've got 5+ hours of weekly yard work to complete.  The need for dry weather while mowing can make it difficult to find a mutually agreeable time to meet.  Sadly, patios tend to fill up during prime dining hours.

It may come as a surprise to people that some of us need to be careful because the media offers so little coverage of Covid-19 these days.  The common wisdom seems to be that Covid-19 is no more dangerous than the flu which is definitely not true.  It's easy with an Internet search to find wastewater data which helps track infections through monitoring of sewage treatment (see link below).  Sadly this doesn't always paint a completely accurate picture of infection levels in more rural areas such as ours where municipal water and sewer service are not available so we're forced to infer using the data from surrounding areas.

https://www.cdc.gov/nwss/rv/COVID19-currentlevels.html

My wife and I both miss seeing friends as often.  We also miss live music and dining out.  Hopefully we'll be able to eventually return to doing the things we enjoy without the need to be so cautious.

Sometimes it pays to be skeptical

I may have been born a skeptic.  I've been questioning things I was told for as long as I can remember.  I'm sure many of my teachers were happy to see me advance out of their classroom because of that.  In many situations that doesn't make you popular, however it can serve you well in an engineering career.

On occasion I've needed to be skeptical of things colleagues tell me.  Such misinformation was most prevalent when I was a field engineer (aka FE) 40+ years ago.  If you're not familiar with that title, it's basically a mechanic for computers.  In my first job in the computer industry, I worked on mainframes and minicomputers.  For part of that time I was a specialist which meant I got called in on difficult problems after other engineers had tried and failed to fix.  I started these visits by asking questions of the FEs onsite only to sometimes have them tell me that of course they had checked the things I was asking about.  I learned which engineers I could trust to admit they hadn't checked something which seemed a logical troubleshooting step.  The challenge with engineers I didn't know well or with those I knew were too proud to admit they had missed something was to suggest that we check something together which they had assured me they had done already without embarrassing them too much.

These days my skepticism allows me to discover the discrepancies inherent in technical documentation.  I don't recall ever seeing a chip datasheet which didn't have a few errors (or instances of wishful thinking on the part of the documentation team).  Accepting the idea that the documentation can be wrong allows one to move beyond seemingly impossible situations such as a device register which occasionally isn't as persistent as the manufacturer's docs suggest.  Software documentation is frequently more error prone than hardware documentation.  I don't think I've ever seen an API document without a few mistakes.

Comments in code is another area it's dangerous to trust blindly.  Engineers will often add extensive comments in code when a function is first created.  Subsequent revisions may not see those comments updated to reflect changes in logic.

That makes the world of engineering seem somewhat bleak.  How do we combat it?  For my part, I try to report errors I discover.  That doesn't always work.  I've reported errors in compilers my company has had to pay healthy amounts of money to license only to be told that the compiler is EOF (end of life) and that no errors would be addressed.  I couldn't even convince the vendor to add my discovery to the list of known bugs.  The thing which keeps me trying is occasionally someone at a vendor will be appreciative of having a bug reported.

The non-traditional start of my software engineering career

Unlike most software engineers, I started my career as a field engineer responsible for maintaining those large mainframe computers like the ones you see in movies.  You know the type with the line of tape drives whose reels keep spinning back and forth.  I got that job by attending the last full time field engineering class taught entirely by live instructors at the Arlington campus of Control Data Institute in 1976.  It was a 6 month full time program which taught electronics repair, debugging, and machine language programming.  They delved into topics such as optimizing Boolean logic which we then implemented by wiring together small boards each of which contained a single Boolean gate made up of discrete components such as transistors.  You haven't lived until you've built an adder circuit this way.  One of the big attractions was Control Data consistently managed to find jobs for more than 90% of their graduates from each class.  For the class which followed mine, they started using an early version of a computerized training system called PLATO for part of the training and eventually switched entirely to computer-based instruction.

In 1977, I completed my course and got hired as a field engineer by Honeywell Information Systems with the responsibility for maintaining their Level 6000 and 6600 series mainframes.  Much of the time I worked on peripheral equipment such as disk drives, tape drives, and line printers.  It's a sad fact of life that machinery with moving parts breaks down a lot more often than purely electronic equipment does.  Fixing mechanical problems is a necessary part of the job for field engineers but it's not always interesting and it often means getting covered in printer ink or grease.

My favorite part of the job was the more difficult debugging required when a computer fails to boot or when one crashes.  When the computer itself had problems, I occasionally had to troubleshoot the CPU the way the field engineer in the picture below is doing. 

The CPU for Honeywell's 6000 series of mainframes contained about 80 logic boards, each of which measured about 12" square and contained over 100 integrated circuits.  For the most difficult problems, we sometimes had to put the boards on board extenders similar to the one in the picture above which provided access for easier debugging using an oscilloscope to trace signals from board to board within the CPU.  For me, the best part of those mainframe computers was the large maintenance panels they had.  From that panel I could stop the CPU to examine the contents of registers, single step the CPU to see how it behaved while executing a section of software, and insert breakpoints to automatically stop on certain conditions.  That was when I was infected by the love of programming.  I'd get 2+ hour windows for preventive maintenance and if I rushed through running the system diagnostics, I'd have time left over to enter machine language programs on those maintenance panels.  Seeing the lights on the panel blink in ways I expected was a thrill.  I spent 5 years working at Honeywell but ultimately left because I was frustrated by the obstacles they presented to employees who want to make the switch from hardware to software.

My second job was with a small company called Atex which used DEC PDP-11 minicomputers to run publishing software used by magazines and newspapers.  For a while I was the onsite field engineer at USA Today and helped install the 12 PDP-11 minicomputers they used when they launched.  Most of my work was maintaining the 200+ terminals used by newspaper staff.  The terminals were simple but company policies declared the ORU (optimal repairable unit) to be the logic board which time consuming to replace.  So I started saving the chips which commonly caused failures from all of the defective boards I sent back to be repaired and I learned which chip to replace for various symptoms.  A vertical line across the screen meant the horizontal deflection chip was likely bad.  That allowed me to reduce my time to repair 45 minutes equired to replace the logic board to about 5 minutes to pop a new chip into a socket.  The time savings left me ample time to write machine language programs I could try during preventive maintenance windows.

Since the PDP was a smaller computer, its maintenance panel was much simpler (see below) than the one used by mainframes.  The CPU's instruction set was much simpler as well.  Maintaining minicomputers proved much less challenging than working on mainframes was.  Their CPUs only had a couple boards and instead of doing chip level repairs, we just replaced the bad board.  Frankly, I found the job a bit boring.  After a mishap where a minicomputer fell on top of me (which is a story for another time), I decided to make the switch from computer hardware to software. 

What I discovered at my first software job was thanks to my unorthodox introduction to programming, I had a much better understanding of low level programming than most of my colleagues did.  I also appreciated that as a software engineer, I was able to write assembly language programs rather then entering instructions as machine language which is just a group of numbers.  Writing assembly language was much less labor intensive.  The instruction "LDA" (load the accumulator register) was easier to remember than the fact that a 235 was the CPU's "op code" for a LDA instruction.   I also didn't have to manually calculate the jump offsets between instructions.  Yes sir, assembly language programming was much easier than what I was used to doing.

At GE, which was my 4th job, I wrote code for Honeywell 4500 series computers.  These were process control systems with a 24 bit CPU which had been modified for use in GE's packet switched network.  The 4500 was yet another another machine with a front maintenance panel.  Most of the code we wrote was in assembly language but the assembler wasn't very sophisticated and it wouldn't give a proper warning when a jump location was too far away.  What could happen was the jump offset might get large enough that it would set the top bit of the offset field, changing the jump direction from forward in memory to backward which caused unpredictable behavior.  I could catch these errors pretty quickly because the assembly listings from our programs also showed the machine language instructions one one side.  In the machine language column the direction of the jump offset was obvious to people who understood the instruction set.  Eventually I was put on a project to upgrade the network nodes to more modern hardware.  I was sent off to be trained on the new machines where I discovered that my management had completely ignored the class prerequisites of knowledge of the C programming language, much to the instructor's chagrin.  So I was forced to learn C during a several week course where I was expected to already have expertise in C and was also learning about the equipment's API.  It was hard until I finally realized that C is really just a portable assembly language.  After that, C became my favorite programming language and remains a favorite to this day.

Eventually I joined Sprint International where I was responsible for developing software for the equipment used in their packet switched network.  It was at Spring that I became obsessed with Unix because I had a Sun 3/80 workstation on my desk.  To this day, the Sun remains my idea of the ideal development environment.  It was also there where I first used a Motorola 680x0 CPU which features my favorite instruction set of any CPU.  One thing I found frustrating was Sun's version of vi (a visual editor) had restrictions on the width of a window and the overall size of the files which could be edited.  My machine language skills allowed me to patch my workstation's copy of vi to expand those restrictions to values I found easier to live with.

The vast majority of my career has been spent writing system software (operating system, device drivers, bootloaders, etc) or firmware.  The line between system software and firmware is sometimes hard to detect.  It can range from simple control loops which monitor and control hardware to what it has become today, hardware specific drivers on any one of multiple embedded operating systems, up to and including Linux.  Regardless of the platform I'm working on, the ability to decode machine language remains a valuable tool for me.  Since my firmware jobs often involve custom hardware, knowing how to read schematics has proved an essential skill as well.

Making changes to your development setup easier

As I'm occasionally assigned new projects at work and as those projects progress, I find the need to update my development environment on a regular basis.  Having the ability to customize my setup allows me to be more productive.

To that end, I have defined a few bash aliases which help make this process easier for me.  These aliases are defined in my ~/.bash_aliases file.

#  config bash

alias   cfgb='gvim ~/.bash_aliases'

# config vim

alias   cfgv='gvim ~/.vimrc'

# source my bash aliases to pick up any new changes

alias   redot='source /home/rod/.bash_aliases'

You'll notice that I have an alias to make changes to my vim setup.  It makes sense to also have a vim macro to read any new configuration settings or vim macros.  This macro is defined in my ~/.vimrc file.

" source .vimrc ro pick up any new macros

map \.  :source /home/rod/.vimrc^M

Default apps for 2023

Lately, I've seen a lot of the "what apps am I using" type posts, apparently prompted by a podcast episode.  You can see a collection of what a number of people are using here.  I find these interesting as they're a good way to discover new apps which I hadn't been aware of previously.  These are the apps I use for my iPhone, Mac, and Raspberry Pi at home as well as the Linux and Windows machines I use at work.

• Mail Client: Apple Mail, Outlook at work (barely tolerable but dictated by the IT team)
  
• Notes: Apple Notes for shared notes, Editorial for notes I don't want on the cloud (such as those containing sensitive information such as birthdays)
  
• Chat: iMessage
• Camera: Apple Camera, Night Capture for evening sky photos
• Photo Management: manual sync into directories on my Mac
• Photo Editing: Preview on Mac, IrfanView on Windows
  
• Calendar: Google Calendar - I like it for its ability to do custom repeats and for ease of having more than 2 notification reminders
• Browser: On Macs I use Safari for lightweight browsing for its ease of sharing bookmarks with mobile devices, Firefox for general browsing because it has a richer collection of security plugins.  At work I use Chrome (barely tolerable but dictated by IT).
  
• Backup: ChronoSync
• Read It Later: Instapaper
• RSS: Inoreader (web and app)
• News: RSS feeds from news sites which lets me keep up with events without being distracted by things I'm not interested in such as sports
  
• Podcasts: Overcast (great performance and the best UI of any app on my phone, bar none)
• Books: Kindle, Audible, Libby, Hoopla
• Database: Tap Forms (good sync between mobile and Mac)
  
• Personal Finance: GNUcash
• Password Management: 1Password - with 600+ non-trivial passwords to remember, this is a must
• Music - Apple Music, Remote app to control desktop from my phone
• Editing (code and general) - MacVim on Mac, GVim on work machines (Windows and Linux)
• X Servers - XQuartz on Mac, VcXsrv on Windows
• SCP client - WinSCP on Windows, scp from the shell on Linux/Mac machines
• Terminal emulation - putty on Windows and Linux machines
  

We lost another dog to cancer

About a month after we lost our dog Bandit to osteosarcoma in March, we adopted a sweet female pit bull mix named Greta.  The jump from an 84 pound Lab, Shepherd, Husky, Pit mix who was strong enough to be considered a force of nature to a 49 pound pit bull mix made Greta seem petite.

Her happy personality was on display from the moment we picked her from the animal shelter.  She happily cuddled in my wife's lap for the 30 minute ride home.

She had had a rough early life, having been bred at least twice by the age of 2, followed by being abandoned in a fenced outdoor holding pen at a shelter in West Virginia.  Luckily for Greta and for us, she was transferred to the Loudoun County Animal Shelter which is where my wife discovered her.

Despite having shorter legs than Bandit did, Greta loved accompanying my wife on 2-3 mile walks once or twice a day.  She found people much more interesting than other dogs or toys and had a number of friends in the neighborhood.

Bandit had always wanted to be a lap dog but Greta was actually small enough for that to be a regular occurrence.  It's hard to tell whether she enjoyed it more or whether we did.  She was extremely affectionate.

 

In early September, we noticed some swelling on her neck, so my wife took her to the vet.  To the vet's surprise, it was not an infection but instead turned out to be lymphoma and a fairly advanced stage at that.  Apparently that's rare in a dog so young.  She was prescribed steroids which did a wonderful if somewhat temporary job of reducing the swelling.  It was lovely having an extra 6 weeks of time with her where she was relatively symptom free.

Unfortunately once the final dose was done, her swelling came back with a vengeance.  It quickly advanced from being an uncomfortable nuisance for her to starting to obstruct her breathing.  I'll never forget the look in her eyes which seemed to question why this was happening to her.

She was sweet and loving to the end, despite all she was going through.  We'll always miss her even though she was only with us for 7 short months.