So, you work in IT then do you? (part 2)
Please see Part one of this article, if you haven’t read it yet (https://medium.com/@optimiseordie/so-you-work-in-it-then-do-you-fb59ee93d098)
I was quite surprised about the interest in my first article so thank you for all the great feedback — it merely spurs me on to write the rest of this series, so keep it up please!
I mean, Simo Ahava (Simo bloody Ahava!) tweeted MY article and said something really nice. Over the moon, chuffed, pleased it resonated. (D) — All of the above. As you can see from the photo below.
The best feedback I get is when people read and find something of utility within my words, analogies, explanations and lessons learned. When they apply these things and tell me what happened next, I have found that this is the pinnacle of any work.
Not the presentation, the slides, the applause at the end but when people go home, back to their jobs and do something different tomorrow, next week and forever after. That’s the best feedback you can get.
So now rather aptly, we turn to Lesson #3, which is having the “Freedom to Learn”. This is probably the biggest single factor in finding fulfilment and mastery in your work, so bear with me. I’ll explain this one over the arc of my entire career so you can spot the signals.
One of my first computers was this lovely Tandy TRS-80 clone, called a Dragon 32. Computer adverts were, if anything, even more overtly and patronisingly sexist than they are today:
It wasn’t the computer I actually wanted (a BBC Model B with all the expansion gear would have been nice) but this model *was* rather magically within my dad’s budget when getting completely hammered at the pub one night and buying it on the way home, surprising us both. I raise a glass in thanks to Mr. Johnnie Walker!
I prised that computer apart and tested its limits. I discovered new graphics modes and stuff that was undocumented. I took apart all the games I bought and modified them. More trial and error learning rather than directed but it worked.Most importantly, I figured out that there was a way to extend the core language (BASIC) that the computer was hobbled with. I could hook my own interrupt and start hacking the core hardware. It was like finding an open door to a new world…
So that was a hacking epiphany for me — I could actually break out of the consumer supplied operating system and build a new one. Just a slight problem — how was I going to write 6809 assembler? You couldn’t buy an assembler program for this computer — nobody had written one yet. It simply didn’t exist.
I would have to make my own. Oh shit. I understood interpretive languages but bare metal coding seemed somehow beyond me, an impossible thing I couldn’t even understand or read about, let alone hack. I had to build a program to do something, without the very thing that I needed to build that program. Haha! Recursion! As an aside, several years later, a Systems Programmer who worked for Edinburgh University, explained the tools used to accomplish porting systems software (OS and platform stuff) between different chipsets. At the time, there was nothing like this either. I was on my own — build it or give up.
There was no internet then, but thanks to my mother kindling my interest in reading, I used my local library (gasp! remember them!) to order and source books on coding for 68000, 6809 processors and one handy guide called “Build your own 68000 Macro Assembler”.
In those days, you had to wait weeks or sometimes months for the books to come through the postal system to your local library. There was like, a priority list for some of these, so your book would be thumbed many times before it arrived. I checked nearly every day at the library and eagerly awaited these tomes. When one arrived, I’d start reading before I got home, ideas already spilling from the pages. Because my information was so scarce, I consumed every page greedily and read them several times over.
Possessing the winning combination of social ineptitude, obsessive compulsive coding, poor personal hygiene and non-existent interaction skills meant I could spend nearly all my time figuring this stuff out. I started pulling all night coding sessions, recording my forays onto cassette tape and building something, anything. Code. Save. Code. Save. Repeat.
My father often paused last thing at night and looked up the stairs to my room. He checked I wasn’t pulling an all night session by looking at the glass panel above my bedroom door to check I was already asleep. I soon fashioned a cardboard insert and handle that fit snugly inside the glass window, making it look completely dark when he checked. I placed this at the start of my coding session and removed it afterwards. Bliss. No interruptions.
There was no github, no coding magazines for this stuff, no commercial software so using three books, I figured out I could port a 68000 Macro Assembler from one chipset to another.
That took about 6 weeks of work, crashing my computer in trial and error hundreds of times until I figured out how to map 68000 -> 6809 instructions. I nearly gave up several times but eventually, I had a stable macro assembler. I had implemented my first interpreter. Once I had my own editor, I could write assembly language without using hex or binary!
I built several games, commercial programs and software utilities that I sold by mail order advert in computer magazines. I helped a local deaf school with some hardware hacking too. Using a microphone, we were able to make a prototype system to help students practise by seeing the waveforms of words and sounds from the teacher. This was my first bit of hardware fun, using the IO ports and a soldering iron.
That love of hardware persisted through my career and my geek side is proud that I got my daughter her first quad core laptop at 8 years old and when 12, she built her first PC from the bare parts as I watched. My love of hardware is clearly something that runs in the family ;-)
The Coding Years
1986–89 was my most intense coding period.
I forgot to show up at University for my degree course in Computer Science (that’s a story for another day!). Instead of my four year course, I walked into a computer shop and asked for a job helping them with hardware and coding. They stupidly accepted and paid me the princely sum of £37.50 a week haha!
For anyone old enough to remember, I was using Mac, PC and some hybrid hardware here along with a range of languages. Dbase, Foxpro, Turbo Pascal, Assembler, Basic, Pick — a mixture of low and high level stuff. This wasn’t the most interesting part of this period though. It was the businesses I worked for.
I built a system for a small road haulage company in the kentish countryside, designed a stock management system for a womens fashion chain, figured out how to create school timetables and a golf clubhouse leaderboard display system. From corner shops to decent sized businesses, I found they were all unique and different.
The golf club system was a heap of fun, because I had to write a markup language to display adverts interleaved with the leaderboard displays. We ran a network of TV monitors around the golf club and the markup language worked perfectly. This is what the markup language looked like:
Hey — I invented <warp></warp> before anyone else, right? If you really want to know, it cycled rainbow colours for any font or graphics. Vomit inducing but hilarious.
This was 1984 and I’d unwittingly plumped for some striking similarities to HTML. I used the markup language to run ads for the golf leaderboard as well as a window display for a shop in Glasgow — because it was easier for people to edit the markup than have me edit the code every time. I even made it into a magazine at the time:
In this period, I learned about many different people, businesses and the concrete problems they were trying to solve. I asked lots of annoying questions. I found all this stuff both fascinating and really hard to wrap my head around.
I started to understand that writing code wasn’t about me — it was about their problems and how I could solve them. The code and hardware were simply a vector we could use to create an outcome, if only I could understand where that endpoint really was.
I found the haulage business really bloody confusing, so I just had to try harder to really understand what all the terminology meant. I didn’t understand the stock handling, so I had to get them to explain it about 15 times for me. The coding part was so much easier once I actually understood what problem I was trying to solve. I think they thought I was an idiot. I was only trying to get all the details right, which I cared about more than people thinking I was stupid.
Without really understanding what I was doing, I learned about the people and the physical or paper processes that underpinned ‘how stuff worked’. I had to learn about NON COMPUTER stuff in order to make the COMPUTER part work out okay. Before this point, I only thought that spending more time coding was the answer to pretty much any problem ;-o
So — this was a big learning period for me. Hardware, processors, languages then the people and businesses that technology was married to. Curiosity took me some way here — but empathy and understanding of people and the problem domains they were trying to solve were integral to writing better code.
We’ll continue the ‘Freedom to Learn’ lesson in the next part of this article, which will cover my years at PriceWaterhouseCoopers, John Lewis, LOVEFiLM and up to the present day. It’s a lifelong thing this learning gig, so I need to show you the arc of all my work and this thread that runs so clearly through it.
Hope you are enjoying the read!
C.
