I Call Him Thorn - Part 3
A survivors account of working with an unscrupulous hack
In this part I'll continue sharing events that occurred during the time I worked with Thorn. See part 2 for earlier events.
A short time later I was tasked with adding a new feature to Thorn's second prototype. Upon asking how I can create my own instance of the distributed, cloud application I was instructed, on multiple occasions, to look at the source code in order to figure it out. I guess Thorn had had enough of auditing his own handiwork to remember how it was built. And as you'd expect he had poor 'cloud hygiene' and there were multiple, similarly-named instances of services strewn about the cloud environment. And so my forensic investigation of prototype #2 began.
I should mention that Thorn was continuing to work on the prototype and never gave me a 'heads up' about changes that would affect my attempts to get a duplicate system running. He expected me to just keep investigating and figure out what had changed when my instance stopped working with the latest source code. You'll recall that Thorn never used the issue tracking system and bear in mind his code commit messages were all 'Latest' (i.e. absolutely no documenting of changes).
To my benefit, I decided to learn how to script the creation of infrastructure and adhere to best practices when doing so. I became quite familiar with the cloud providers command-line-interface (CLI) and tried to share this powerful technique with Thorn, who had never heard of the CLI. To reiterate, Thorn had been doing well over 6 months of cloud development (likely for other companies too) and never heard of a cloud CLI.
Things had reached a pretty low point with me promoting an automated, reproducible process for creating instances of the system, and Thorn continuing with his manually created, rather disorganized 'master' system. I offered to spend some time going over the scripts, which were written in JavaScript at Thorn's request. However he preferred to take a look at them himself first. Maybe he objected to having things explained to him, which sounds pretty pathetic but it wouldn't surprise me. Later he would call the scripts 'pretty slick', which is a condemnation as he prefers the 'scrappy startup' mentality. Thorns opinion is unsurprising as he never understood the value of maintainable code nor developed the ability to produce it.
Things came to a head when Thorn's use of a cloud VM for development was found unable to produce Docker images and, despite my offering to build them for him, roundly condemned the use of Docker-based solutions. You'll recall he has been issued with a physical PC identical to mine (that has been returned from IT after virus scanning issues resolved). His claim that VMs were more cost-effective spawned a round of cost analysis that proved the two approaches were roughly the same expense. Despite this finding, VMs were ruled the preferred solution because, in a troubleshooting scenario, one could use an IDE to debug easily whereas Docker would require the configuring of ports. Bear in mind VM deployment had not been automated and was not well understood whereas Docker images were being produced and deployed with a few console commands. It was at this point I realized my utter lack of political capital and how poor my rhetorical skills were during discussions, which had become highly adversarial and heated to put it mildly.
A lot of people would have 'abandoned ship' right about now and I wonder why I didn't. I had offered my resignation to Manager a couple times by now because of the dysfunctionally-large difference in opinions on the team. My staying comes down to my loyalty to Acme and Manager for hiring me when they did and investing in me. I also teach my children that difficult people cannot be avoided and these situations are merely lessons in how to deal with difficult people. So 'soldier on' is what I did, resolving to be more systematic and calm during meetings and making a conscious decision to be happy despite the presence of Thorn in my life. Remarkably valuable lessons I must say.
During the migration to VMs, Thorn managed to foist another round of surprise architectural changes on the team and I made sure these changes were reflected in the current Docker-based solution before switching it off. Somehow I thought it would be less effort in the long run and time would prove me right. For now, I embarked on setting up VMs by hand as automation scripts were now discouraged. However I did manage to address one of Thorn's 'bright' ideas: he was going to share his corporate account login details with the team in order to distribute binary files via Git. Fortunately this was avoided and I 'held my nose' for the rest of the exercise. Next came the final 'nail in the coffin'.
See part 4 for the last of the sad events and a conclusion to this story.
In this part I'll continue sharing events that occurred during the time I worked with Thorn. See part 2 for earlier events.
A short time later I was tasked with adding a new feature to Thorn's second prototype. Upon asking how I can create my own instance of the distributed, cloud application I was instructed, on multiple occasions, to look at the source code in order to figure it out. I guess Thorn had had enough of auditing his own handiwork to remember how it was built. And as you'd expect he had poor 'cloud hygiene' and there were multiple, similarly-named instances of services strewn about the cloud environment. And so my forensic investigation of prototype #2 began.
I should mention that Thorn was continuing to work on the prototype and never gave me a 'heads up' about changes that would affect my attempts to get a duplicate system running. He expected me to just keep investigating and figure out what had changed when my instance stopped working with the latest source code. You'll recall that Thorn never used the issue tracking system and bear in mind his code commit messages were all 'Latest' (i.e. absolutely no documenting of changes).
To my benefit, I decided to learn how to script the creation of infrastructure and adhere to best practices when doing so. I became quite familiar with the cloud providers command-line-interface (CLI) and tried to share this powerful technique with Thorn, who had never heard of the CLI. To reiterate, Thorn had been doing well over 6 months of cloud development (likely for other companies too) and never heard of a cloud CLI.
Things had reached a pretty low point with me promoting an automated, reproducible process for creating instances of the system, and Thorn continuing with his manually created, rather disorganized 'master' system. I offered to spend some time going over the scripts, which were written in JavaScript at Thorn's request. However he preferred to take a look at them himself first. Maybe he objected to having things explained to him, which sounds pretty pathetic but it wouldn't surprise me. Later he would call the scripts 'pretty slick', which is a condemnation as he prefers the 'scrappy startup' mentality. Thorns opinion is unsurprising as he never understood the value of maintainable code nor developed the ability to produce it.
Things came to a head when Thorn's use of a cloud VM for development was found unable to produce Docker images and, despite my offering to build them for him, roundly condemned the use of Docker-based solutions. You'll recall he has been issued with a physical PC identical to mine (that has been returned from IT after virus scanning issues resolved). His claim that VMs were more cost-effective spawned a round of cost analysis that proved the two approaches were roughly the same expense. Despite this finding, VMs were ruled the preferred solution because, in a troubleshooting scenario, one could use an IDE to debug easily whereas Docker would require the configuring of ports. Bear in mind VM deployment had not been automated and was not well understood whereas Docker images were being produced and deployed with a few console commands. It was at this point I realized my utter lack of political capital and how poor my rhetorical skills were during discussions, which had become highly adversarial and heated to put it mildly.
A lot of people would have 'abandoned ship' right about now and I wonder why I didn't. I had offered my resignation to Manager a couple times by now because of the dysfunctionally-large difference in opinions on the team. My staying comes down to my loyalty to Acme and Manager for hiring me when they did and investing in me. I also teach my children that difficult people cannot be avoided and these situations are merely lessons in how to deal with difficult people. So 'soldier on' is what I did, resolving to be more systematic and calm during meetings and making a conscious decision to be happy despite the presence of Thorn in my life. Remarkably valuable lessons I must say.
During the migration to VMs, Thorn managed to foist another round of surprise architectural changes on the team and I made sure these changes were reflected in the current Docker-based solution before switching it off. Somehow I thought it would be less effort in the long run and time would prove me right. For now, I embarked on setting up VMs by hand as automation scripts were now discouraged. However I did manage to address one of Thorn's 'bright' ideas: he was going to share his corporate account login details with the team in order to distribute binary files via Git. Fortunately this was avoided and I 'held my nose' for the rest of the exercise. Next came the final 'nail in the coffin'.
See part 4 for the last of the sad events and a conclusion to this story.
Comments
Post a Comment