6 years ago, I left the head office at Boots after nearly 30 in their IT department. I’ve not really spoken about my time there – some of it was being wary of “speaking bad” of a past employer but some of it was, genuinely, PTSD. A lot of my time there was not great.
But it’s time to change that because, like it or not, what happened has shaped me as a person, and I have a lot of stories to tell, good and bad.
Today I want to write about one of the proudest moment as a developer.
Please bear in mind that this was 30 years ago – this is to the best of my recollection and some of the information may be hazy or, unintentionally, wrong.
First, I need to wind the clock right back to 1989, when I first joined the company as a Trainee Computer Programmer.
I was one of 3 people employed as programmers that year that weren’t graduates. The company was trying something new – could they avoid the high costs of having to go out and tempt graduates to their company, without flashy graduate conferences and high wages? Was employing a chemistry graduate really better than someone from college who actually had qualifications with computers? Genuinely, some graduates had never used a computer keyboard before.
The problem was my first manager. Let’s call him Steve. Because that was his name. Actually, no, he was my second manager – Geoff was my first, but he was soon moved to a different team.
When I left Boots 6 years ago, Steve was still there and I was happy to see that he hadn’t risen up the company very much. They say you can forgive but not forget. Well, without any religion telling me that I have to forgive, I can do neither. He made my initial life a misery – remember, I was 18 and this was the first time I wasn’t living at home (I’d move 100 miles away from my family and was a lodger in someone else’s home, with just a small, cold bedroom to myself and no experience of looking after myself). Not long before I did leave, he contacted me because he needed my help with something. And I helped him – I was courteous and professional. Because I’m the better person.
Anyway, back to 30 years ago. Steve really didn’t like the fact that I wasn’t a graduate and made that clear. Even when the team went to a the pub, he’d make sure the conversation got to their university days, so I was unable to contribute. He wanted me to fail because he didn’t like the idea of what the company was doing, and he did that by setting me targets that were, well, impossible. My best friend at the time, who was seen as the best of the new developers, told me as much – even he couldn’t achieve what I’d been set.
Before I can explain the targets, I need to better explain how the team structure worked. These were the rolls, in order of importance…
- Trainee Computer Programmer. You were this for a year after your initial training and were then promoted to the next level. Steve denied this for me and made me wait for another year – I was the only programmer who started in 1989 that didn’t get an automatic promotion the next year.
- Computer Programmer. You coded the programs that you were given specifications for by someone more senior. You devices test plans for your programs and tested them.
- Analyst/Programmer. Designed systems, worked out what programs were required and what they needed to do and wrote the specifications for the programmers to then follow. Once the system was completed, they’d be responsible for system testing (trying all the programs together, often the first time they’ve communicated with each other).
- Senior Analyst/Programmer. A more senior version of the previous role.
- Team Leader / Manager. Kinda hazy over where the differences, at this time, was between these roles.
I should also add that, late 1980’s, this was a mainframe programming role.
One thing I disliked about this structure was that the specifications the AP wrote were often in pseudocode. This was so similar to what the eventual code would be like, it left little for the programmer to do – there was certainly little flexibility or imagination for the programmer to contribute as a result of this.
Back to my targets.
Over a period of time, usually 3 months, the team’s AP wasn’t allowed to find any serious bugs in any of the code that they tested. Remember, this was the first time it was system tested, so there was no way for my to verify some things, such as interoperability with programs being written by other people.
What was a “serious bug” was not defined. Indeed, after a while they also decided that 3 minor bugs were considered the same, including spelling mistakes. A lot of the online programs we wrote included pages and pages of help screens, so avoiding any kind of spelling mistake was… hard. We did everything on mainframe terminals – no PCs here – with no spell checkers to assist.
Needless to say, I failed my targets. Every time. It started off as verbal warnings and then written warnings. Quickly, I was on my last warning, so myself and HR started looking for a way out (and what then happened is another post for another day).
HR, by the way, knew the targets were wrong but were powerless to do anything about it, particularly as Steve’s manager backed him (she seemed to have a similar world view on graduate recruitment than him and was generally disliked by people). It didn’t go any further, though – when Steve denied me some time off, I took it the senior manager (his manager’s manager), who agreed with me. I don’t think that helped my situation with Steve but it was a rare victory for me.
Meantime, our team was given out biggest project yet – the Stores Database.
The Stores Database
The mainframe systems at Boots had been slowly added to over decades of work – multiple systems, hundreds of programs, initially using files and, later, databases. Boots is a retailer to stores are key to a lot of these – however, each system was usually using it’s own data source for stores information. So, every time a new store is opened getting it added to all the systems was complex and fraught with mistakes.
The Stores Database was a project to provide a central database of all stores information, which could be edited and queried from an online system and then, a series of batch programs would run overnight and populate the existing systems (files, databases, etc.). Over time, new systems or changes to existing ones would then use data directly from the new Stores Database.
At the time the team had just one programmer (me) and a trainee programmer. She was due to write some of the batch system, and myself the rest (the remaining batch programs plus the whole of the online system).
The online system is the key bit here – in particular, the query system. Business users needed ways to create list of stores and relevant data – on screen and sometimes as exportable lists to feed into spreadsheets, or whatever. The query system would allow them to build lists of criteria, as well as specify what data about each store they’d like to know.
As well as accuracy, performance was critical.
My AP found from the business what an “average query” would look like, which consisted of 3 levels of information (the 1st level being “all stores”, followed by a second thing to narrow it down and then a third – sadly, I can’t remember what those other two level actually were). She set a maximum performance of 15 seconds for this in her design, based on the idea that they wouldn’t want to wait any longer.
She designed the system and wrote all of the specifications. As part of her investigation she spoke to the Database Administration team to ensure she was creating the list in a performant way. They told her she wasn’t and suggested an alternative. She ignored them.
My AP was going to get married and had taken off a month to do this and go on Honeymoon too. She was behind on the design of the online part of the Stores Database and only completed it on the day she was leaving.
She gave the designs to me to have a read. I immediately found a problem.
The query system was designed based on an assumption about the way that Mantis works with databases. Except it didn’t. Mantis had a different interface to DB2 than the batch systems did (which she knew more about). As a result, I couldn’t do what she suggested… any alternative would completely change how the system would work.
She had no time to do anything so left it with me.
I went back to the DB Admin team and they told me about their ignored recommendations. I didn’t ignore them and, combined with some ideas of my own, I designed a new system. I re-wrote all of the documentation, coded and tested it, all within the time I’d been given just for the original coding (from Pseudocode) and testing.
I left the team as my AP returned and I handed over the code.
The end result
Remember that 15 seconds for 3 queries target? My version did it in 5 seconds. There was a 3 second overhead for any number of queries plus 1 second for each level you added. So, you could make a query with the maximum number of 8 levels in 11 seconds. Way, way quicker than anything expected.
Although my AP’s version was never written, mainly because it couldn’t be, it was predicted that if it could have been, performance would have not been good enough, falling well below the target level she set.
And here’s the most important point… during system testing, not a single bug was found. Years later, still with access to the source code, I took a look at it to see what had happened with it since. Changes had been made to add new functionality but not a single bug fix had been made.
I believe I was able to do what I did because I was actually excited by it – I was bought in to this by given some freedoms, instead of being told what to write. As a result too, the code I wrote included some imaginative ideas, which had come from around 8 years of programming experience (I started early!).
What happened to the other 2 non-graduates? One moved into a non-programming area of the IT department and the other left to move to similar job in London. But it didn’t stop change. Soon after the graduate recruitment programme ended (especially when their “award winning” training team got head-hunted) and people who fitted the requirement of the role, rather than a random degree, became the method of recruitment.
As for what happened to me, what Steve did to me during this time had long term repercussions. It was the start of mental health issues that have affected me to do this day, including spending my entire adulthood feeling imposter syndrome in whatever I do. Steve doesn’t deserve forgiveness or being forgotten for what he did – he was a petty bully and that needs to be remembered.