One of the things Sue Smith and I talked about the other day in our Write Through It conversation was how you can orient yourself in a system you didn’t build. It is a continuation of mine and Sue’s beliefs around the state of “View Source”, but beyond just learning web development, and actually understanding how systems work, not just a single website or web application.
Orienting yourself in any system you didn’t build will vary from company to company and role to role, but my assumption is that we are talking primarily about doing so within a desktop, web, or mobile application that primarily uses HTTP and TCP. If we are talking about backend systems or other protocols, we probably need to have another conversation, but I think talking about orienting yourself in a desktop, web, or mobile application that uses HTTP and TCP as a transport will cover likely 80% of the use cases folks are going to encounter. I’d even say this applies to a lot of AI applications, because even with LLMs, you are likely using an API to work with it, and my thoughts are also about understanding the inputs and outputs of any application – even AI.
First, I’ll be explicit about fully using whatever system you are trying to orient yourself in through any user interface you are given. You should exhaust clicking around and learning what the application(s) and user interfaces afford you. There are browser plugins like WhatRuns that will help you break down the technology used, but really just playing with an application is the best way to learn what is possible. You can click view source if it runs in a browser, and make sure you click on any documentation, help sections, or any other resources that are made available by anyone who built the system. If it is an internal system, make sure you search for the name of the application(s) and system via common places like the Wiki, portals, Slack, and any other CMS or tools that teams are using to coordinate within a company. You never know what someone published about an application or system that can help orient yourself in what the hell is going on.
My recommendation for any technical, or even non-technical, person’s toolbox is some sort of proxy. I recommend something like Telerik Fiddler Everywhere, Charles Proxy, or Postman Interceptor. You can turn these tools on when using any desktop, web, or mobile (route through workstation) application, and capture all requests, responses, and events that fire. This is how you are going to reverse engineer the inputs and outputs of any system, and orient yourself within the application(s) and the system behind it. Now depending on how many backend systems, microservices, and other infrastructure a system or application uses, you are likely going to hit a lot of walls that you won’t be able to move through. But running Fiddler or Charles Proxy locally will give you a hell of a lot of data about what is being sent as part of the communication behind an application(s) and system you are trying to orient yourself within. Honestly, I just leave Fiddler on all day some days to make sense of what I did all day, as well as what is being tracked about me, which ad networks are tapping into my worlds, and to reverse engineer the systems I am using.
I take the data Fiddler (or others) gather about the requests, responses, and events fired while using an application and store it in various folders, based upon what I am trying to understand. Then I have Claude help me make sense of what is there. There is often just too much code, data, and incomprehensible garbage flowing in and out of systems that there really is no way a human can do this. You need AI to help you sift through the noise and find the signals. It will come down to the questions you ask AI about what domains, paths, headers, parameters, schema, and other digital bits are in play. If you are doing this exclusively in the browser I also recommend using Chrome or Firefox developer tools to actually hack on and transform requests and responses to see what the systems behind them do or do not do, and this will be captured in your Fiddler (or other proxy) data. There are a lot of devils in these details, things like SSL certificates, headers, anti-bot, and other challenges you will encounter, but this is what it is all about. You have to be curious and fearless. Really you don’t have to have any coding experience, you just have to be brave.
You will learn a lot reverse engineering systems. I do it all the time. I’ve long graduated from View Source in the browser, and it is why I use Fiddler instead of Postman, because I can proxy any network traffic on my machine. Postman has many limitations, but is easy to get up and running for some users. Honestly, I recommend Fiddler + Claude as your primary tools, then build up a toolbox of prompts that you ask Claude about the massive amount of information you get. Gather evidence in the form of inputs and outputs and documentation and learn what you can. Then start asking around internally within your company, or even on the open web, about what you are seeing. There are no dumb questions. Now I have to add, some of this can be construed as borderline illegal by some companies and you can get yourself into hot hacking water, so be aware. I know the line well, but that is from bumping up against it.
So let’s recap. Really my toolbox is 1) VSCode IDE, 2) Claude, and 3) Fiddler. I didn’t mention VSCode above, but it is the Integrated Development Environment where you can dump all the data Fiddler produces, and you can use the Claude VSCode extension to sift through it. Depending on what types of systems you are trying to reverse engineer and orient yourself within, you will need additional tools, but these three, plus Chrome / Firefox browser developer tools, will get you 75% there in my experience. This is what I do everyday as the API Evangelist, orient myself in other people’s systems. I am constantly reverse engineering shit I didn’t build. I’ve long considered myself a reverse engineer, and not an engineer. And hopefully my toolbox helps you think through how you are going to make sense of the world around you. I may do an update on this in the future, and talk more about how to document the APIs and schema employed by systems, because the more you gather, organize, and make sense of this knowledge, the more power and control you will have in your job, career, and business.
