Hi there. My name is John, aka J. M. Hughes.
I’ve been doing engineering of one type or another for over 30 years. And, yes, I am getting older. I can’t seem to avoid it, so I just roll with it.
I started out wanting to be a physicist, but for various reasons that just didn’t work out. So I became an engineer instead. I started out in electronics with things like digital logic, power control and low-frequency analog stuff. Then I moved on to microprocessors and the software to run them. I’ve worked with the original 6800, 8080, Z80 and 6502 devices (I still admire the 6502, actually), along with the 32032 and 68000 devices. After a while I found that I was hooked, and I needed more.
It didn’t take long to discover that I enjoyed designing and writing code about as much as I liked designing and building the hardware, and it’s been a fatal attraction ever since. I became a software engineer. Or, more accurately, an embedded systems engineer.
I started playing with computers in earnest when I got access to the IBM 360/165 at the university I attended. From there I worked with machines such as the PDP-11, VAX and Perkin-Elmer minis, using operating systems like OS/32, RT-11, VMS, BSD Unix, and RSTS/E, among others. As time passed and darkness fell on the era of the minicomputer I moved on to OS/2 (1.0 through 2.1), Xenix, SunOS, Solaris, Linux and the ever-ubiquitous Windows. As for languages I’ve worked with various assemblers, Ada, C, C++, Java, Pascal, Modula-2, FORTRAN, Perl, PL/1, Python and I’ve done some FPGA work using VHDL.
Most of my software engineering experience has been in the realm of real-time data acquisition and control systems. Some of that was for safety-critical stuff used on aircraft (digital engine controls and such), some was used with some big telescopes, and some went dashing off into space as part of a mission. I’ve taught classes on software requirements engineering, test methodologies and safety-critical software (specifically DO-178B).
I am particularly interested in processes, procedures and requirements. And documentation. Lots of documentation. I get cranky when I have to deal with code that isn’t documented, wasn’t written to any requirements, and has not been adequately tested (if it was even tested at all). There are good reasons why at least half of all major software projects end in failure (+/- 20% or so, depending on which definition of “failure” is used).
[Updated 17 April 2015]
Wow. It’s been almost six years since I started this blog. A lot has happened in those six years. I now have two technical books in print, a fiction novella in ebook format, and a third technical book in progress. But, I am starting to feel the years. I guess that can’t be helped. Age happens.
After many years of working at the University of Arizona in various departments and on a wide variety of projects, when I wasn’t taking a break and working in industry that is, I’ve finally made the decision to retire. But I’m still working, nonetheless. My current job involves automated peptide synthesizers, which is interesting because it’s so different from anything I’ve worked on in the past. Actually they really aren’t that much different from any other type of sequential automation system, and I just ignore the organic chemistry part of it (I don’t really need to know it to design software for the systems).
When I’m not at work I occasionally dabble with woodworking, do some stop-motion animation, rebuild old computers, automate various things around my house, write books and stories, and work on not being too cranky.
It is a rare mind indeed that can render the hitherto non-existent blindingly obvious. The cry ‘I could have thought of that’ is a very popular and misleading one, for the fact is that they didn’t, and a very significant and revealing fact it is too. – Douglas Adams
The image in the header is courtesy of my wife, who likes to take photos of odd and interesting patterns of light and shadow. It is actually shadows in late afternoon sunlight on the side of a chiminea.