I've always been a very good software programmer and an excellent designer. Its interesting to look back at the experiences of growth where certain things stand out.
The first company I worked at had grown from the proto-aggressive, manic energy of a recovered addict who found Jesus and credit cards. At the time I came along, the company had become an over 100 person business that did millions every year. The internal management structure was a mess, however. The problem was that the only people who'd survived to become management were the ones who figured out how to steer clear of the boss's fiery (pun intended) wrath. That meant that they sometimes had to hold their tongues at patently stupid ideas because steadfast disagreement in any context usually meant swift termination and it was hard to express any kind of reasonable disagreement with patently awful ideas. Bob also had a lot of good ideas, but singularly stupid ideas ran rampant through the organization like, no joke, our Timesheet Protocol Sheets (TPS) reports. Then there were ‘Words for the Day’, aggressive religious writing. One of the first missives I received offhandedly mentioned that he wasn’t a great fan of the Rolling Stones and their satanic music, but really loved their single, “Can’t Always Get What You Want.” I cracked a joke about and asked someone who sent these stupid things, I was told in hushed terms not to say much about it. Someone once insisted on unsubscribing and been fired. Most everyone used a simple spam rule to avoid it altogether. I quit and moved west.
I landed in LA at a company that had broken apart from the Musical Titanic‘s, Virgin Records, corporate office and then came back to board their ship. The company’s founders were two former IT gurus who quit and formed their own software design company, then asked Virgin if they could just lease the same office space they'd been in. Virgin, humiliated, but broke enough to be willing to just outsource the IT and be done with it, acquiesced. We got to enjoy pointlessly cool events, like a guy reading his autobiography aloud. That he was the dude from Motley Crue rather than some guy in an art house goofery gave it a touch of surreality. Sometimes they had fashion shoots near the coffee pots by accounting.
I ended up working with one of the two, a man named Cassidy. Cassidy was the first person I met who was absolutely superior to me in design and implementation. It was easy to see right away that Cassidy's design thinking was at a whole different meta level. I was whipping through class structures, he was up in meta-class structures. In meetings, the ‘team’ might be discussing a problem that had been vexxing everyone for a week. Strange network behavior, servers that mysteriously popped and blinked, services that sometimes added minutes or hours to the reported times of music files. Maybe its this, maybe its that, etc.
Cassidy could usually walk in, interrupt the conversation, and whip up a hugely intricate web of services and programs that we all independently worked on. Then he would chart the data flows and pinpoint 1 or 2 potential problems by speculating on likely scenarios, and order people to check those things out specifically. Most often he was right to everyone's stunned amazement, and most especially to the programmer whose work was causing the problem. Almost everyone there assumed as a matter of course that their shit was legit, Cassidy had assembled an all-star cast of programmers. I was junior when I joined, which amazed me given that I'd been the best or among the best everywhere I went, including college. I quickly got caught up on the tricks the others used by reading source code and experimenting.
At some point, Cassidy asked me to work with him. By then, I knew the only thing I should do around him was to shut up and learn. I don't think I would have ever gotten as good as he was at the implementation details because I was still thinking about learning how to paint and to keep up with Cassidy required working 36 hour shifts at some points, which I did twice in the year I was there. I didn’t care, I was being paid by the hour through a servicing company.
Cassidy demanded impossible performance benchmarks that even the flashiest and supposedly most optimized of existing services couldn't do by an order of magnitude. We were writing radio software, so I had to be able to serve millions of requests per second to pass our benchmark tests for throughput. With WCF and TCP protocols, we died at about 15,000. I had to start devising disk storage maps and tunnels to the memory, which I did. At the same time, I had also begun developing a tool to test all these services that existed in the network. There were about 30 programmers there, all of which had at least 2-3 services to write and maintain. I was pinging them and analyzing their data, then presenting it in a graphical interface.
When Cassidy would speculate about all his services and suggest what the problem was, I fired up my tool and actually tested his hypotheses and presented my results. They usually confirmed or disconfirmed his analysis, most of the time it confirmed. As I added and refined, I began releasing this tool to our QA guy, Mike, who, incidentally, was eerily similar to another good friend of mine I had in Atlanta, Mike L, a player in a band called Bain Mattox.
Both Mikes are witty, intelligent, artistic, but also a little bit shrewd. They both have quiet, caustic wits and intimations of a hard boiled morality based on being genuinely good people. They're both in bands that have had success beyond where most bands die, but not all the way. Mike P was in that space by choice, he played industrial metal, I guess is what I could call it. 16Volt is surprisingly interesting to my ears, given that I am not into aggressive sounds generally. Tool and Mastodon have that same appeal. I got to those bands through 16Volt and later, again thanks to their music, I found merit I could never hear in music like The Crystal Method.
Anyway, all these All-Star hotshot programmers working at this place hammered Mike all the time, they often vehemently denied that their shit was fucking up. I started developing a way for Mike to call anyone's bullshit, including my own, which is whose BS I started with. I called it a 'black to white' tool, meaning converting a black box data module into a white box via service calls. I showed him how to analyze the data and when certain patters or defects could appear that were obvious. So if I said it was one thing, he could check it. Mike started busting my shit, which helped me tighten up implementation details."Oh, there is no way it could be that." *five minutes later* "Justin, I think its that."
Then I started pushing other programmers' black boxes to grey by learning their service interfaces and revealing their inputs and outputs in the tool and doing basic data analysis on their results. I could even spin up mini service diagnostics by hammering their service calls and quantifying their responses.
There is nothing that programmers love to do more than hypothesize about what is going wrong when a devious bug surfaces. In most cases, the fastest way to find the issue is to take any hypothesis and test it. If that hypothesis proves false, find another hypothesis and test it. Programmers might spend 4 hours talking about a run time error and speculating on 50 potential causes and drilling into sub-variants of a few of those causes. The fix is usually as simple as firing up a unit test that trips the error and fixing the pointer. ~ 5 minutes, tops. I talk through scenarios with QA and cross of possibilities as too highly unlikely, such as nanosecond becoming a millisecond after the last release when nothing appeared to have changed in the service module that receives and transmits units of time that I was writing. Releases were usually related to something else entirely, like figuring out how to transmit cover art images. Mike could show me the munged up times, and I could trace back to its source and begin revealing that services outputs. Then Mike could go get the programmer to actually check into the issue with compelling evidence that cornered them. Usually, they'd rather blow him off by telling him to go talk to someone else because blah blah blah. Its not that people were lazy, the place was intense. Sometimes people had to delay the interaction and subsequent investigation due to a pressing issue, but a lot of the guys seemed to spend a lot of time fucking around on the internet once you got to know them a bit.
Once, I managed to bust Cassidy shit. Cassidy was incensed at a data inconsistency from one of my services. I assured him it was up-stream, Cassidy cut me off and ordered me to fix it, that he didn‘t want to hear my explanation, then sent me out of his office. I slapped a reporting module into my tool and sent him the snapshots of data flows as they were messing up in real time within ten minutes of our meeting. This is when Cassidy seemed to really take me under his wing and I learned a lot of conceptual design from him, how to think of systems in process with their flows and pinpoint potential breakpoints. During this time I worked with him, I really loved Cassidy in the platonic mentor - student relationship sense.
One day, Cassidy's partner, with whom I had limited interactions, called me into his office and said they wanted to hire me outright from the contracting company I was working for and collecting hourly rates for. If I worked 60 hours, I got paid for 60. If I worked 30-40, I got paid less. I asked for a nice 6-figure salary, he said it was larger than figured, but he'd talk to Cassidy. The next day, it was a quick yes. That weekend, I flew to see my friend Warren, who lives in Las Vegas, to celebrate my good fortune. We spent a day on a boat in Lake Mead. I’d never been to the water there before, Lake Mead is a Martian ocean that sits in a rocky desert-scape bowl. A beautiful and eerie place to be and I recall it as one of the nicest times of my 20s, a cloud had lifted all at once. Warren brought some of his girl friends, a pack of friendly betties. That was as far as it went, of course, at the dock we all parted company, worn out from the sun drenched play.
Monday, Cassidy called me into his office to welcome me aboard, then chastised me for not having my phone on Saturday. Something or other had hi-cupped and gone down and he was trying to call me. I expained the weekend, added the technical point that a phone on a boat in this context might as well be tossed overboard before we get out of the no wake zone the marina so I could at least know where I lost it at the end of the day. Cassidy insisted that I was an engineer now, and engineers make enough money that they always have to be in contact.
One of the most important lessons I learned from Cassidy came at this juncture. I should have maintained my independence. I mistook Cassidy's mentoring for friendship when all he was interested in offering was a business partnership. To allow him to become an exclusive customer for my labor was a fatal mistake and as soon as I did he let me know that the game had changed, I was his to be available always. That is part of the deal of being salaried.
I quit a few weeks later and moved north, but Cassidy was right to push me from a business perspective as well as from a mentoring standpoint, which makes me remember him as a lost friend rather than a pushy boss.
I had learned most of what I could from Cassidy about software design, which was how to think systemically. I am sure I could have gotten better, but most of the gains had been made. I was probably not ever going to go to the trouble of getting as technically proficient as Cassidy and in all likelihood I may never have achieved his proficiency with systems analysis. I am uninterested in wholly mastering software design, my interest is testing my hypothesis that software design techniques and concepts can be generalized, modularized, and extended to other contexts outside of software.
The internet is an incredibly powerful and efficient resource allocation tool. The resource the internet moves and proliferates is information, as measured in bits, bytes, etc. There is no reason why the same design techniques and implementations cannot be applied to other resource allocation systems. In OO terms, data bytes are a derived class of a generalized class, resource. There are other instance classes, such as money, and there are other resource allocation systems, such as economies. The specifics of the data are mostly irrelevant to its flow unless throughput and bandwidth are going concerns. In contrast to the internet, the flows in our material economy are a disaster. Bottlenecks, rampant loss, misrepresentation, run time errors, compiler errors, and so on. The waterfall software design framework is modeled on modern business processes, the waterfall is the absolute worst way to design from a standpoint of providing clean solutions that work well and can be maintained and extended. The waterfall tends to manifest bloated, over-engineered, annoying and ill-conceived results, not counting the projects that die in budget overflows.
Programmers love to speculate about philosophical hypotheses, but those are all really beside the point. Every programmer worth his salt knows that the fastest approach to fixing failing performance is to find the run time error, fix it, move on to the next one, repeat. Optimize once the obvious breakdowns are gone. If some programmer spun me a yarn punctuated by imprecise and ill-defined terms and phrases about how their service module was causing a bottleneck because the 'rational self interest' of his application demanded huge sums of data, I'd tell him that I didn't care about all that, either fix the problem or let me at his code.
Every hacker worth a damn knows that human social engineering is the easiest way to access any system. To say that human failure is the main cause of security breaches is conventional wisdom in the realm of security. Perhaps, but I say that systems failure is the main cause of breaches in humanity. One thing I can't figure is why people who are anonymous would choose to wear a Guy Fawkes mask. That seems to me to be too much sub-classing. The power of being nobody is that you can be anybody. Steal your own identity, instantiate any mask you need to get the job done.
Let's optimize.
Advertisements
No comments:
Post a Comment