Andrew Brown

Where I come from

I grew up in a corner of upstate New York that most people haven't heard of, and I mean that literally—you'd have to go looking for it. Sixth-generation of my family, or close to it. My graduating class had about half a dozen people in it. My family has been working with their hands out there for a long time, and that's just the culture: something needed fixing or building, so you fixed it or built it. Few people were calling a contractor.

I grew up snowmobiling, four-wheeling, hunting, fishing, logging, and spending most of my time outside. I've thrown around hay bales, shoveled more snow than I'd care to quantify, and mowed lawns and fields that blurred together after a while. I've done carpentry, plumbing, electrical, and construction—all at the homeowner's scale. I've worked on small engines, tractors, and backhoes. Hard work wasn't something I opted into; it was just the default setting where I grew up.

None of that screams "future software engineer," and it wasn't supposed to. I didn't grow up in tech. I grew up about as far from it as you can get in the continental United States while still having internet and electricity. But I sought it out anyway—starting, as these things tend to, with video games. From there I fell in love with computers and what they could do, and by 13 I was assembling Frankenstein PCs out of whatever components I could salvage from the town dump, where people left behind machines they didn't want anymore. I wanted all of them.

For computer education in my high school—which, to be clear, did not have a computer education program—a group of friends and I convinced the faculty to let us start a computer solutions class. That turned into programming. Which turned into robotics. All of it driven by a starving desire for knowledge that just didn't have anywhere else to go in a town that size, no matter how much I loved the peace and quiet there.

I still play golf, write, garden, hunt, hike, and ski. I'm still a woodsman. The outdoors didn't leave when I picked up technology. The two just share the calendar now, and the homelab has yet to complain about the arrangement.

Before software

Before I ever wrote a line of code professionally, I'd already worked across enough industries to fill out a bingo card nobody asked for. Food service, hospitality and tourism, retail, industrial, telecommunications, physical security, network infrastructure. Early on, the goal was to diversify my experience as much as possible so I could figure out what I wanted to do with my life. Work alone has taken me to New York City, Boston, Atlanta, Louisville, Cleveland, Columbus, Cincinnati, Pittsburgh, Washington D.C., San Antonio, and Houston—and outside of work, Cancun, Hawaii, the Bahamas, Colorado, and Los Angeles. Haven't been across the pond yet. I've travelled a bit more than I'd ever thought I would.

At Starry, Inc., I started installing residential broadband, then moved into a remote NOC role—monitoring ISP infrastructure with PRTG and Grafana, triaging PagerDuty alerts, documenting incidents, coordinating restoration during high-alert periods. That stretch was my first real exposure to what it means to operate a system rather than just use one, and the distinction stuck. I also designed and deployed a point-to-point radio internet link that ended up serving about 74 households, which was a satisfying problem to solve.

At ICS Technology Group, I deployed 50+ Ubiquiti and MikroTik devices across SMB environments—routing, switching, wireless, VLANs, firewall rules, DHCP. One project came in two weeks early and improved the client's network performance by roughly 30%. I'd been inside data centers for the first time to swap out and troubleshoot equipment, too.

Then came the stretch that shaped me the most: two back-to-back jobs servicing physical and electronic security infrastructure inside Huntington Bank branches—and outside them, including ATMs. At Cennox and then Wittenbach Business Systems, I maintained DMP alarm panels, vault door hardware, electronic lock mechanisms, KABA access control, IP camera systems, and NVR infrastructure across dozens of bank locations. I programmed central station communication paths, diagnosed faults between alarm panels and monitoring centers within SLA windows, trained 12+ field technicians on integration troubleshooting, and coordinated service windows directly with branch operations managers so they could keep doing business while I did mine. That was three and a half years.

You spend enough time inside bank branches and you develop a gut-level understanding of something that reads fine in a textbook but feels different when you're standing in the vault with a multimeter: these systems have real consequences for real people on both sides of the counter. That understanding didn't leave when I left the field—it followed me into how I think about software and cybersecurity.

What I build

The through line across everything I've done—wood, metal, engines, machines, computers, networks, code—is that I'm at my best when I'm making something. The specific medium has never mattered as much as the act itself. I become whatever is necessary to get something from "doesn't exist yet" to "exists now." Software is where I'm focused at the moment because it's a domain where the reach is genuinely enormous—the work is intangible and amorphous, but it can help more people than any physical thing I could build with my hands alone. That's not a reason to stop building physical things. It's a reason to also build software.

Other projects

Cybersecurity

This part needs some context, because the timeline is genuinely absurd.

A little over a year ago, I switched my major from computer science to cybersecurity. The reasoning was almost comically simple: I thought there was more in cybersecurity that I didn't understand than there was in CS, and that seemed like a perfectly good reason to go learn it. Both fields turned out to be far more deeply intertwined than I expected at the time, and there's more to know in each of them than I'll have lifetime for. I find relief in that rather than discouragement, which probably says something (concerning) about my brain.

When I switched, I knew essentially nothing about cybersecurity as a formal discipline. I had years of physical security experience from the field—vault doors, alarm panels, the tangible stuff—but logical security, CTFs, offensive tooling? I didn't even know what a CTF was. I couldn't have told you what the letters stood for.

That spring, first semester in the new major, I entered the National Cyber League for the first time. No prior CTF experience. I even offered to lead the team I was on. I didn't use the training gymnasium NCL offers before the competition: no playbooks, no dedicated coaching, no prep. I didn't even know how to navigate the competition dashboard on the day it started. I just went in completely blind and came out the other side with a result that, honestly, didn't make a lot of sense given my situation at the time.

NCL covers OSINT, network traffic analysis, cryptography, log analysis, password cracking, web application exploitation, and forensics. You either solve the challenge or you don't—there's no partial credit for understanding something in theory. Going from zero formal background to that result in about a year—with, admittedly, a seasoning of unemployment that gave me an unreasonable amount of free time to pour into it—is probably the most concentrated example of how I tend to approach things when something catches my attention.

Leadership

This one needs context too, because it didn't start with ambition. It started with disappointment.

About two years into my degree, a professor mentioned—almost offhand—that the university had student technology clubs. I'd had no idea they existed. Two years of nothing, and it turned out they'd been right there the whole time. I was genuinely annoyed at myself for missing it, but I digress. I joined the Cybersecurity SIG immediately.

I loved it. My engagement stood out, and I was made an officer, then a senior officer. Meanwhile, I was nurturing my long-time fascination with artificial intelligence—its architecture, its implications, where it's heading. I wanted somewhere to bring that interest, and the existing clubs didn't quite have the space for it. So I went looking for somewhere to create it.

What I found was a dying club called The Python Team. Just Python programming, barely functioning, almost no members. I took it over, rebranded it as the Programming Special Interest Group, and folded it under Franklin's Association of Computing Machinery chapter. I had built the organizational structure from scratch—roles, decision-making, communication, the works. It went from essentially nothing to weekly meetings with nearly a dozen regular attendees.

From there, a lot of other things followed—more than I expected, if I'm honest. I designed and now maintain the technology community of practice pages on Franklin's Canvas LMS—the pages every student in the technology program sees. I found the Franklin GitHub Enterprise organization completely unused, overhauled it, taught myself everything about how it worked, then turned around and taught everyone else. There are more than 30 people using it now. I created the Franklin student clubs Discord server from scratch, nudged the community into migrating there, and now manage it with the help of the other leadership. Almost 40 members and growing fast now. I've written newsletters, authored onboarding materials and announcements, and delivered over 30 original presentations and workshops across both clubs—spanning Python, Git workflows, AI architecture, neural networks, RAG pipelines, AI ethics, physical security, cryptographic fundamentals, NCL competition prep, and more.

I've had a real impact on Franklin's student clubs—ridiculously, across three leadership roles at once: President of PSIG, Senior Officer in CySec, and Treasurer of the broader ACM chapter. I'm not shy about saying that because I worked hard for it and I watched it happen in real time. Synapse came directly out of that experience—watching the engagement problem play out week after week and deciding to solve it with software, because that's apparently what I do when something bothers me enough. The end goal? I just want to create a space for a ton of people to mix, mingle, chill, grow knowledgeable, and build cool stuff together.

That's it. That's all I want. To watch a bunch of people create things in a space I helped make.

What I'm after

I'm looking for my first professional software engineering or security role, and what I need at this point is a runway. I've accumulated a lot of experience across a lot of domains, and I'm ready to apply it somewhere focused where I can keep learning and keep building.

I've spent years in environments where the consequences of getting it wrong were immediate and very physical. A misconfigured alarm panel meant a bank branch couldn't verify its security status. A missed SLA meant someone's system wasn't being monitored. A bad diagnosis in the field meant a second truck roll and a customer who trusted you a little less the next time. In software, the equivalent is a data loss bug that quietly corrupts the thing someone trusted you to protect—and I've built far enough into Vociferous to know exactly what that kind of failure feels like from the engineering side. Both perspectives have shaped how I think about reliability, and neither lets me take shortcuts comfortably.

My background is unusual for someone at this career stage—field infrastructure, financial security systems, network operations, software development, cybersecurity competition, community leadership—and that breadth is deliberate, even if it wasn't always planned. I learn fast when something is new to me. My NCL trajectory is probably the clearest evidence of that, but it's the same pattern that shows up everywhere: find the gap, fill the gap, move on to the next one.

I believe engineers have a responsibility to the people who use what they build—not to institutions in the abstract, but to actual individuals whose days get better or worse depending on whether we did our jobs well. The goal is to improve lives without causing harm. That's the constraint I design around, and it's the one thing that isn't negotiable. The act of creation is a trial of responsibility; the cost of improving the world around you must always be thoroughly understood—prior to construction.