It's all Ball Bearings (AI) These Days

I saw recently that Google and Amazon announced how much AI they use to generate code, Google in percent, and Amazon in hours saved. There has been a lot of hype that it is all AI these days. Over the summer, I played around with different AIs to get my head in this space to see how much is hype.

I built a few Python apps in Google Colab to detect license plates in a video stream from my bike rides. Colab uses Codey and Gemini, and they did an excellent job of getting me started as someone who didn't know Python or the libraries available. I am a trial-and-error learner who tries something and, when it doesn't work, refers back to references to figure out why. At one point, I had a working app and asked how I could change the implementation to be multi-threaded, which it did. It didn't work, but that resulted from Colab and not the code generated.

In my new job, I make a point to use ChatGPT, GitHub Copilot, and/or Claude a few times a week. Last week, I asked it to create two apps for me; a random people picker as a spinning wheel and an out-of-office (OOO) helper. The spinner took me about 15 minutes to get right, so I repeatedly asked Copilot to modify the implementation to get it the way I wanted. In the end, it was close, and I made minor changes to the CSS. The exciting thing about this approach was that I iterated with Copilot to turn the implementation instead of finding completed implementation(s) and Frankensteining them together.

Where it has yet to work well for me at work is melding technology with the specifics of my organization. For instance, what does an executive dashboard look like for our ecosystem? Or what is the best way to configure the on-call paging system across our teams? Sure, I asked if there were any best practices or pitfalls others have run into, and the answers were very generic, which is what I would expect.

My experience and intuition suggest that we can benefit from leveraging AI. As I build the 2025 roadmap, I am encouraging the team to consider how AI or AI-powered products can help us achieve more and faster.

Exploring DORA

We are considering implementing DORA metrics to help track and improve our outcomes. I had never heard of the term DORA, but most of the metrics rolled into this moniker I have a history with. As part of the discussion around DORA, we met with a few vendors whose products integrate with GitHub, Jira, etc., to surface metrics. While we didn't end up purchasing a product to help here, it wasn't because we needed to see the value of DORA. On the contrary, we value the outcomes that DORA metrics (et al.) are after; it is more about timing. Through acquisitions, mergers, and growth, we have a diverse group of teams, each at different maturity levels and mechanisms around SDLC. Starting to track DORA-esque metrics when a team may be working to climb up on the maturity curve seems premature for a few reasons. First, we should focus on helping teams up-level their SDLC. For instance, CI/CD is good, so everyone should do that. Second, most mechanisms have some metrics as outputs that we can leverage. If you're doing Scrum, are you tracking the key metrics or meeting every two weeks to plan work? Lastly, we need to be careful when comparing across teams that don't do the same thing or have similar needs. The apples and oranges analogy exists because it works.

As a team leader looking to uplevel the entire engineering organization, DORA and products that capture related metrics sound attractive from a centralized visibility perspective. Being new to the organization, I know relatively little about each team's maturity level, but many feel there is room to improve. Does that mean we are not going to track any DORA metrics? Of course not; we will track the ones with shared mechanisms and leverage that data. Measure, identify, improve, repeat.

P.S. I was pre-Dora The Explorer. But my kids weren't. Geography interests me, so this Dora is fabulous in my book.

Suddenly I Need to Think About My Safety

Personal safety has changed for me. 

I have not posted much, if anything, about my experience as a transgender person. Mostly because I am a private person. If you want to know why I don't like condiments, no problem. But at work or on social media, I tend to separate my private life from my public life. I think it's no different than people not bringing up topics like their marriage or conceiving a child; it's about having boundaries.

Boundaries are about safety. At work, boundaries support myself and those I interact with. Who knows what is going on in someone's life that will trigger them and make them feel unsafe. That doesn't mean I suppress my private life or who I am, but I will not push it onto others. Like in a previous post, I don't know what is happening in anyone else's life, and I respect that they may want to keep it that way.

Building on boundaries...some folks no longer have boundaries; they are willing to say almost anything, especially on social media.

I've been watching the show Will and Harper on Netflix and was troubled in a couple of ways by the part where they went into a Texas steakhouse together. If you're not familiar with the story, Harper is a friend of Will's from Saturday Night Live and is transgender. Will Ferrell, being who he is, attracted a lot of attention from the other patrons at the restaurant. Some of those patrons wrote terrible things about Harper and tagged Will on social media.

I relate to that story because safety is something I need to think about now. My transition is not something I talk about, and most people are respectful enough not to ask. I appreciate that since, as a transgender person, I often don't feel safe. I say this not to compete with any group; but because of the realization that I went from the top of the privilege hierarchy to a spot much lower. There are many states that I would be uncomfortable spending time in, Texas among them. I recently needed to travel to Dallas for work, so I took several precautions to ensure my safety. My former privilege told me that I was overreacting. But wait, there was my experience in Nashville a few years ago when I was alone and physically/verbally confronted by some huge/drunk men. I was terrified and stunned, this was an entirely new experience for me. It worked out "OK" because I literally ran away, but it was one heck of a wake-up call.

It's this fear/concern for safety that exists for most transgender people and drives the generalized suspicion we feel. It is hard for me to be suspicious that way, but some things have transpired this year, and those suspicions explain many things. Too many things. This is where allies become essential to help with boundaries and safety. The next night in Nashville I asked a friend to walk me back to the hotel, but what about the less obvious things? I need your help there too. 

The revelation for Will Ferrell around what life was like for his friend is something that I wish everyone could understand. It was clear from his reaction how big of a revelation it was for him - how his actions led to the threats on social media. Harper and I are both white trans-women who transitioned relatively late in life and so enjoyed the benefits of our privilege for longer than we won't. It is so much worse for people at the intersection of race and gender!

I need your help to remain safe beyond my physical safety. Stand up to locker-room talk, gossip, social media, bias at work, etc. activities. It will require you to step outside your comfort zone. I hope you can find the courage.

 

Try Noodling on That

The name of this blog is a reference to words uttered by a friend of mine. He also added the word "noodle" to my vocabulary, which is synonymous with thinking in this context. Not to be confused with a Noodle the pug who prognosticated on what type of day we could expect to have.

Whether to myself or someone on my team, I often use the phrase "noodle on that" when the answer is non-trivial and analysis and logic are not yielding a solution. It can be relatively straightforward—I need an answer to this problem—or something more abstract—like ideation. Either way, there are times when looking for an answer is more like chasing something elusive. Finding the answer is often further compounded by some time pressure - I need to solve this by XX.

Enter Noodling.

Several times, the answer presented itself to me - but only when I took the pressure off myself. For instance, I was cramming for a math final, and the answer to a particularly gnarly calculus problem came to me in my sleep. It woke me up, presumably so I could write it down (ha). Another time, the answer came to me in the shower. Someone once attributed this to all the positive ions stimulating my brain. Whatever the reason, it's a thing - Shower Epiphanies.

As a manager, I have often suggested that they take a break from trying to solve the problem directly and noodle on it. Give yourself a break. Let the pressure off. Give your subconscious a chance to work on it. My anecdotal data is that it works the majority of the time. This has the additional benefit of letting people work it out for themselves. My belief is that things feel better when people figure something out on their own, as opposed to me giving them the answer. 

See you on comfy mountain. IYKYK.

A Brief History of Integrating

I was recently asked how I would integrate systems with similar functionality but different code bases and infrastructure. It got me thinking about how I feel I have been solving the integration problem throughout my career and how it (not surprisingly) keeps coming up. My answer was: It depends on what you have and where you want to land. I have many questions: how much of the data is the same? How reliable is the data? Is there an appetite to reduce any duplication? What is the desired recency (age) of the data? Is there a goal to become more homogenous? Regardless of the answers, I have employed several strategies/technologies over my career.

One of the first implementations I worked on was a practical solution for a PC-based application to leverage COBOL code on the mainframe. The company had invested years in the code and was not ready (or able) to rewrite it. We built an LU6.2 gateway to call the mainframe and pass data to the COBOL file's copybook. This was such a common need that later, Microsoft wrote an LU6.2 connector to create a code proxy from the copybook for you. Here we are 24 years after Y2K, and I am willing to bet that the banking and finance sectors still have a bunch of COBOL being used.

During the Object-Oriented boom, there was a big push to build an Enterprise Service Bus (ESB). We talked about technologies like MQSeries, CORBA, and RPC as ways to implement an ESB. I never saw an ESB I liked, probably because so many were never finished. Instead, I watched enterprise architects trying to resolve the enterprises' requirements into something for everyone. It's hard enough to nail this down for a single business line in an enterprise, much less many/all of them.

To some extent, we used databases as the point of integration. One system would be declared the data owner and copies of that data would be made for use by others. At the time, I saw this strategy fail more often than it succeeded because the copy would become stale and not meet our customer's expectations. Nowadays, we make copies, but it's less about integration and more about scale. To succeed, we had to figure out how to work in the world of eventual consistency.

As I shared these examples, I couldn't help but think of a few other topics. But these are the ones I wanted to share. If you've been in this industry for any time, I'm sure you have your own integration history. Integration is a persistent problem, a challenge that we all face, and it's safe to say that it's not going away anytime soon.

Things That Make You (Me) Go Hmmm

I saw a snippet of Captain Hindsight from South Park the other day, and it made me think of a couple things that have been rattling around in my brain lately. My initial college major was teaching history and political science; I changed after my freshman year to computer science. I still like teaching and history. Lately, I have been looking into challenging history as I was taught, looking to understand more of the complexity and unbiased events. For instance, I have been reading about the 1980 "October Surprise" story surrounding the release of the hostages from Iran. The timing of the release of the hostages was always a little suspicious, but not so much that I thought there was something else going on. In retrospect, there is much circumstantial evidence that it wasn't on the up and up. 

Hmmm. 

Where am I going with this? Hang with me.

You would have to live under a rock not to have heard unfavorable news about Boeing over the last few years—the 737-Max, 777 a whistleblower dying, and door plugs not being secured. Some people point to a more significant cultural change at Boeing that can be traced back to Harry Stonecipher, a protege of Jack Welch. For more on the Boeing story, see "Flying Blind" by Peter Robinson.

Hmmm.

I am getting to the point, really.

This got me thinking more about Jack Welch and how he made Six Sigma a pillar of his business strategy. As someone who has led medium-sized teams and big projects, I have always been cautious of Six Sigma. Like most things, it was started to meet a need and add value, but my experience has been that it's become something else. At GE, it was weaponized and became a "religion" to help with the culture. Want an example? Stack-rating employees, considering the bottom 5% of expendables, can be traced back to practices at GE. This practice has become common at most companies I have knowledge of. As a manager, I have had to use this practice on high-performing teams and replace the "bottom" person. The position stayed open for a long time because the person we managed out was very good and not easily replaced. Now imagine teams/organizations playing politics and/or pushing an agenda and how this can be used as a weapon.

Hmmm.

Funny how more information comes out over time, and it changes the narrative. Makes good fodder for someone who likes to learn.

Is Doing the Right Thing - Right?

For most of this year (the last nine months), I have been pondering whether doing the right thing is right. Let me clarify. For me, doing the right thing in the context of honesty or integrity - is ALWAYS the right thing. Is doing what I feel is the right thing to do - the right thing? I have been noodling on specific circumstances that have me questioning whether I did the right thing based on how they turned out. 

There were two circumstances where I put others' needs ahead of my own, and it didn't work out. It is not nearly as noble as when Spock sacrificed himself in Wrath of Khan, but it is my little drama. The binary part of me looks at these situations and sees the only alternative as never putting others first and looking out only for myself. Even writing that down makes me grimace, as it goes against my core beliefs. So, the answer must be in the vast gray area between what I did and doing nothing. In the classic answer for all questions, it depends.

Regarding the two circumstances I have been pondering, the others were not in their integrity, making that the easier thing to focus on. I put others (people, projects, etc.) first and myself second, and it didn't work out as I had hoped. As I healed from that, I was able to begin considering where my learning was. Even if it's a one-off, I won't trust that person in the future.

I have been thinking about reciprocity in this context; doing something for others (entities or people) without expecting what I may get in return. Being a manager/leader is being in service. The thing I struggle with is whether that also requires selflessness. My recent experience is that selflessness in the workplace is a minefield. First, it's not very likely to happen - it's just the nature of companies, especially large ones. Second, I must acknowledge that I sometimes have expectations hiding behind my actions. They may be as simple as looking for a smile, but expectations nonetheless. That doesn't make my decision/activity wrong; it just exposes that I had some expectations. It's the missed expectations that led to my disappointment.

Ultimately, I feel good about what I did and my reasons for doing it. I would make the same choice again, looking out for any expectations I have. It also means that being selfless does not mean sacrificing myself. So, maintain my integrity, do what I believe right, and watch out for personal risks.

Who I Work With is a Choice

Since leaving Amazon, I have been recharging and considering what I want to take on next and with whom. I followed a similar process in 2013 when I last looked for my next opportunity. Then, I gathered a list of the top 10 companies I respected and focused my search on those. I needed to align my principles with the companies that aligned with them. This led me to also form a list of companies that didn't align with my principles and exclude them from my search. As a result, I passed up some well-paying opportunities.

For instance, Amazon was on the list in 2013 because of my experience with no-hassle returns and Amazon Prime. Secondarily, it was the technology, tools, and innovation.

A lot has changed since 2013, including my prioritization of principles. For instance, after the 2016 election, I am paying more attention to politics. It's not a party affiliation but rather a candidate and their policies. It is a contradiction to say you support me as a transgender person and then support policies that limit my freedoms. It's also about the larger company culture concerning diversity, equity, inclusion, social impact, and corporate responsibility.

From what I hear and see, the job market is in a cycle where it's challenging to land a job. I can feel the tension between landing a job and standing by principles. It's a choice.

Ultimately, it's not a choice for me. I have not been happy when I have worked with less principled teams. I am the type of person who wants to wake up in the morning and is glad to be working with the company/team. That does not mean it's easy or there are no challenges. But it does allow me to be myself, be comfortable asking for help, know that I will get help, and pay it forward by helping others.

Do or do not. There is no try.

I recently dreamed I was in a large audience where an unidentified leader asked for a volunteer to lead a big project. They looked at me, and I said something like I will try, but I couldn't do it alone. Someone else stood up and said they would take on the project, and I could feel the audience staring at me with disdain. So much so that it woke me up.

I am not the type of person who looks for a lot of meaning in my dreams, mostly because I don't remember them. But this one woke me up, and I spent the rest of the early morning lying in bed, considering why it bothered me.

This was similar to talking to others and asking them how we get something done, and their answer is something like, "We don't have the resources." That wasn't the question; the question was, what would it take? My dream was similar because the question was not, "Would you deliver this project by yourself." It's not a question of ensuring a successful outcome; it's a question of pulling together enough for a reasonable discussion on feasibility.

The response I would guide my dream self to give is: Sure, I will lead that big project for you. Then, I would document what it's going to take to get it done and present that to the stakeholders. 

This dream bothered me because I was settling for trying when I knew better.

My Experience of APIs

I watched Nate Jones's TicTok last week. He talked about how APIs are becoming the interface to data. As I noodled on his words, I agreed with him, and it got me thinking about my history with APIs - more generally than his point.

I have been developing or calling APIs for a long time, and this got me thinking: weren't the MSDOS interrupts (related post) a form of API? We all know the right answer, so we will not say it out loud and move on.

But seriously. I remember creating an API for the DOS terminate and stay resident (TSR) module I wrote as the proxy for the server-based DBMS we wrote. This API used INT2F as the interface to the TSR.  We didn't expect CBASIC programmers to code to INT2F, so I had a callable C library that abstracted the internals. What we built was closer to something like ODBC, a generic API for retrieving data requiring you to write the query.

There was a period when our systems had a business layer and a data layer; the business layer represented business semantics, and the data layer represented the sproc/view/query/table structure. Weren't these all APIs? During the object-oriented period (which sounds like the Jurassic period), I didn't refer to them as APIs then; they were methods on an object.

We went from RPC to SOAP to REST, each an evolution to build distributed systems. All these are forms of APIs as well. Why? APIs are about creating a dependable contract that callers can depend on to create an outcome—not about the specific implementation technology. The "interesting" part of the API design process was how to design for reusability. And by interesting, I mean the part we spent a lot of time discussing. In the Enterprise IT space, we had enterprise architects who created taxonomies, libraries, and APIs that modeled the data and/or the business processes. Building models/services for the entire company didn't work, and a "single responsibility model" and "separation of concerns" were needed. Even now, we have engineers who have API design as a skill we depend on and use at some level of governance.

From these evolutions (and more) of APIs, I have learned they are hard. Why? Because API design is hard. Why? Because reuse is hard. This is why when we talk about APIs today, we don't think of them as static. Instead, we build them to be extensible as the needs evolve. Even designing for evolution, I have had more than my fair share of painful API deprecations.

I still love a good API design session.

Surprisingly good project estimation

At Amazon, we went through several cycles/iterations of planning. Regardless of how Agile an organization operated, we needed to map capacity to the roadmap to understand how much we could deliver in a given year. This does not mean we actually delivered exactly what we initially planned since requirements and priorities changed over the course of the year. But it did allow us to have a starting place that we used to have a shared vision across engineering and stakeholders.

For each iteration, I would strive for better accuracy by asking technical leaders to revise their estimates. Effort was the input we refined the most, asking teams to go from swags to more educated estimates. How much were they relying on existing services? How much had never been done before? I had a list of prompts to help them assess the complexity/unknowns and, therefore, the risk. I would take all that and put it into my model (i.e., Excel), which would auto-magically create a calendar plan.

Invariably our leaders always requested when we would be "done," typically in the context of something like Prime Day or re:Invent. To answer this question, I would use a scaled-down version of the organization planning spreadsheet. Typically, the project was underway, and varying levels of design were complete. Most of the time this meant that the effort estimates were better, and the number of resources available was known. For each estimate, I would ask managers to provide me with the factor they used to compensate for PTO, meetings, etc. - I called it non-keyboard time.

Anecdotally, the static model usually yielded a surprisingly accurate date. I would use it to drive discussions around resource and/or feature tradeoffs depending on which knob we were using to tune the outputs (typically the launch date).

Such a simple model gave many people heartburn—"How could something so simple model something so complicated?" I tried "enhancing" the model to account for other factors, for instance, parallelization. However, it was too complex to model and required too much from engineering managers or technical leads. Parallelization is needed when building a plan but doesn't work when doing estimation—it simply didn't improve the model. 

The problem was that many leaders would simply not believe the model. I found this very frustrating since they would usually choose a somewhat arbitrary date as to when they wanted to be done and tell me to use that. I would challenge that approach and eventually agree since it was obvious that they were going to get their way (an anti-pattern of Amazon's Have Backbone, Disagree, and Commit). Side note, one time, I escalated a case of this, and while the VP I escalated to was appreciative, the Director threw a tantrum in the meeting. So much so that the VP later contacted me to apologize for the Director's behavior.

In project retrospectives, we discussed how we course-corrected throughout the project. It turns out that the early model outputs were right—scary right?

I have been around long enough to know that when bringing in the date, leaders are often pressuring the teams to keep their foot on the gas. Something to watch out for is that this practice can lead to the outcomes I describe in my "Secure Apps Take A Village" post. Some of this behavior comes down to a couple of challenges leaders (including me) have to grapple with - trust and giving up control. Trust (and verify) what my teams are telling me, and accept that I don't have the same level of control I used to. Both are probably topics in and of themselves.

Things that I ran into...

1. Inflated efforts. Managers and leads pad their effort estimates to ensure they meet commitments. First, how do you know if it's inflated? Who better to know the complexity of a system than the people closest to it? If managers are really doing this, then do they understand what is being asked of them? How will it be used? If managers are padding, they are responding to a fear typically rooted in the organization's culture. This is something to go deeper into to figure out how to make it work for you.
2. Low efficacy factors. Given that keyboard time is an input into the model, this will directly impact the date/resource calculation. Is a low number accounting for a less experienced team? Or is the manager using the same number every time? Why—to pad dates? I used a generously low number, which was painful to write down but proved to be more accurate. For instance, this was especially true for teams that had high operational overhead.
3. What is DONE? Of course, done is something that not everyone defines the same way. As the owner of a launch, done to me meant the system was launched and open to customers. Invariably some folks would define done as some level of completeness for their code. Ensure that everyone is aligned on what done means. I would typically use code complete, including all automated tests and the binaries, in a shared test environment. I used this as done since the cost of integration testing and other launch activities was typically shared across teams, and I could estimate those differently.

Secure Apps Take a Village

I reflect on recent experiences and the tension between rolling out features and ensuring the product is secure. Features are flashy. They make good keynotes and/or demos. Features get customers excited and make money.

Security is about the backend. It's not flashy. It's hard to demo security; you probably wouldn't want to even if you could. But when something goes sideways, a security issue will lose you customers. It's like giving your competition bullets—"Hey, did you hear about that security breach at Acme?"

Security is getting more complex and more challenging to do well. Sure, we are smarter and better understand vulnerabilities. However, applications are also becoming more complicated (e.g., log4j and versioning). Complexity makes security harder—it just does. The bad actors are as determined as ever, and their methods continue to evolve.

I attribute much of this tension to the organization's culture. A typical culture pattern is when leadership compresses engineering estimates, and as time runs out, security verification takes place. This leads to pressure to complete verification and remedy errors without impacting the date. Regardless of the number of times that leaders tell people how important security is - actions speak louder. We must ship at this point in the project, leaving uncomfortable conversations and hard choices. 

The tension between shipping and being secure starts early, when most of the time is spent discussing/planning customer-facing features. Sure, security comes up, but in my experience, it gets a different in-depth consideration. If we are lucky,  the challenging security conversations/decisions are before we launch - and not after. Talking about security feels more like a bad thing when it's this late. Further contributing to this tension is when leaders push to make a date, a security issue is identified, and in response, they make statements akin to - "Security is always a priority, so when I push on the date, my expectation is that the system is still secure."

Imagine a product where this culture goes on for a long time; the product is very successful and lucky that lurking security issues are private. With some certainty, this culture will catch up with you, and a critical mass of security issues will arise, requiring engineering resources. Sometimes, the number and/or severity of the problems is so great - that feature delivery is paused, and most of the team is focused on remediation. I bet that for every case like this in the press, many more are not public.

Too often, I have seen teams rely on the hero model: people who, early on, take the risk of spending time on security—which, in my opinion, is under-acknowledged/appreciated. Or the heroes who scramble to fix issues after they are found—typically in a severe time crunch. The hero model is not sustainable and is unreliable for ensuring secure systems. Further, the hero model is often a symptom of something "wrong."

So, let's stop relying on heroes, best intentions, hollow statements, and punishing the bearers of bad news. In a fiercely competitive world, features are prioritized, and security often gets less attention, sometimes even becoming an afterthought. This is a culture war that needs to be waged. 

We must start by considering security not just as a necessity but as a feature as important as any other. We need to talk about it early. We need to do security reviews early and often. For instance, start a threat model on the first day, keep it up to date, and assess design decisions in the context of how it would change the threat model. Activities like this involve staffing security-oriented teams and embedding them into the project teams. Then, empower them to ensure positive security-oriented outcomes. A culture of security is independent of volunteers who take on additional responsibility to ensure a secure system.  We need mechanisms to help people do the "right" thing. Then, acknowledge (early) security wins, such as actions to avoid an event.

A culture of security is hard to change, and as leaders, we need to be honest with ourselves about it — are we backing up our words in ways that will lead to the outcome we want? Look in the mirror. Yes, the words mean something, but it takes more than words.

PS: If you're unfamiliar with the African phrase "it takes a village" - see here.

Classic Tech Books I Still Have My Shelf

Relating some of the books I still have on my bookshelf. They are totally obsolete but found myself reminiscing around what they represented from my past and why they still took up space on my shelf.

One thing to know about me is that by default, I am a book collector. I once had a collection of over 200 technical books on my shelf. That was before the great purge where I donated most of the books and hung onto 30 or so. The great book purge is a story for another time. Suffice it to say that the books that survived were either timeless or ones that I had a fondness for. Here are a few of the fond ones.

The Pink Shirt Book. What would I have done without this book? If you were programming to the "IBM PC" at the time, this was a must have. I pulled it off the shelf and it flopped open the chapter on INT 21. This was the system services interrupt the keyboard, files, etc. I also found a dog-eared page for the INT 27 terminate and stay resident (TSR) details as well. TSRs were the services of the time. This was mostly assembler, then bumping up to C as soon as I could.

The Genie Book. I used this book in conjunction with the Norton Pink Shirt book. It came out after the Norton book, but had more details on writing TSRs, multitasking, and expanded memory. I pulled this book off the shelf and there is a page that was used so much that it was sticking out - having come off the binding. Now that is one well used page. When grabbing the image for this post, I found that this book was available on the Internet Archive (archive.org). E-versions of technical books is one reason I was comfortable getting rid of so many of my technical books (see future purge post).

The Microsoft C 5.0 Quick Reference Guide. This is an actual picture of my copy because I could not find a stock photo. Note the cup stains on the cover. It was a C reference, the page I used the most for C were the escape sequences for printf (e.g. \n, \r) and the language type ranges (e.g. difference between long and float). I still use this reference occasionally for the last table on ASCII codes - the decimal, hex, and character representation of 0 to 255. If you have seen The Martian, then you know.

The Intel 386 Microprocessor Hardware Reference Manual. Yikes, I am not sure why I am hanging onto this one, I have not used it since the time when I needed it. I have flipped through it a couple of time since and seen all the timing and logic diagrams and thought - we actually did this stuff. I primarily used this around interrupts (maskable vs. non-maskable) and for figuring out peripheral timings for external serial devices. We were doing some pretty hard-core stuff at the time. I recall a device we borrowed from one of the hardware manufacturers that sat in between the CPU and the socket. It allowed you to debug at the CPU level and single step through code. I remember we called it the skateboard because it resembled one but have not seen or heard of one since. Hardcore.

It's worth noting that many of the folks I worked with during this time are still friends. We were young and thought anything was possible. On top of that we had a leader who inspired us to live on the edge and accomplish amazing things.