Now reading   PJ Brown  •  New Orleans  •  Lead Software Engineer at Dscout  •  Code meets human behavior

People / Engineering / New Orleans

PJ Brown Builds the Parts of Software That Remember People Are There

Before PJ Brown helped build tools for studying human behavior, he was already asking engineers to notice the person on the other side of the screen. His route from Louisiana classrooms to Dscout makes a quiet case for software with better manners.

Long before PJ Brown became a lead software engineer at Dscout, he wrote a short essay about a familiar mistake in software. Developers, he observed, are often expected to make the thing work while designers make it pleasant. The division is tidy, professional and rather convenient. It is also false. A person does not experience an application as a database followed by a wireframe followed by some tasteful buttons. The person experiences one thing, usually while trying to get another thing done. Brown's conclusion was direct: developers should take an active part in design.

That was in 2017, when Brown was moving through New Orleans' software-training circuit. He completed Operation Spark's bootcamp and then Hack Reactor's advanced immersive program. His public work from the period has the earnest practicality of a builder learning by making. Bike Map let communities share routes for exercise, commuting and leisure. Pet Detective offered a place to report lost and found animals. Neither project attempted to reorganize civilization before lunch. Each began with a recognizable human predicament and asked what software might usefully do about it.

Brown's career since then has made that early argument look less like a student exercise and more like a compass. He has built for industrial teams, business clients and researchers. He has worked with front ends and cloud functions, databases and design systems, local colleagues and teams an ocean away. The technologies multiply. The useful question stays put: what happens to the person using this?

The Louisiana route

A technical education, assembled in public

Brown studied computer science at Louisiana State University from 2009 to 2012, supported by an LSU National Honors Scholarship and a Louisiana STEM Scholarship. Several years later, the concentrated training of 2017 gave that foundation a product-making rhythm. His repositories from the time read like a workshop bench: functional programming exercises, deployment experiments, a basketball-training app, a beer finder and the two neighborhood-minded projects that made his portfolio.

2017Bootcamp, immersive training, product projects and UX writing
$3M+Additional GE product funding Brown reported helping secure through 2019
15Public repositories on his GitHub profile

The Bike Map project is especially revealing. Brown used React Native for the interface, Redux Sagas to coordinate route creation through Google's API, PostgreSQL for the relationships underneath, Docker for deployment and Expo for device features such as location. It is the sort of stack list engineers enjoy reciting. Yet the stated purpose came first: help people share the roads they use for fitness, pleasure and getting to work. The machinery was elaborate because the ordinary activity deserved to feel simple.

PJ Brown smiling in a casual blue shirt beside wooden barrels
Off the clock and away from the interface: Brown in a candid image from his public developer profile. His own list of interests ranges from sports and computer hardware to psychology and long conversations.

His interests outside work fill in the portrait. Brown has described himself as a sports fan who enjoys both watching and playing, a hardware tinkerer, a student of human psychology and someone fond of talking with different sorts of people about nearly anything. It is an unusually apt collection for a product engineer. Hardware teaches consequences. Sport teaches systems under pressure. Conversation and psychology teach the inconvenient truth that users rarely behave like the clean little figures in a planning document.

From prototypes to production

The interface is where the organization shows its manners

At GE Digital, Brown's audience changed from cyclists and pet owners to people selling and maintaining power turbines. He helped build a multi-user application with React, Redux and Java, worked with product customers during acceptance demonstrations and collaborated with teams in India. His account of the work gives equal weight to architecture and communication. He refactored front-end state management, testing and performance, then helped other engineers adopt the new practices. He also reported contributing to work that secured more than $3 million in additional funding through 2019.

Funding is the conspicuous number, but the quieter detail says more about Brown's method. The team showed work to customers during the sprint, not merely at the ceremonial end. Expectations, ease of development and customer satisfaction had to be negotiated together. Enterprise software is often where empathy goes to sit beneath fluorescent lighting. Brown's description suggests he considered it a working requirement.

At Lucid, Brown kept working on the seam between a complicated system and the person expected to use it. He built custom interfaces intended to reduce clicks, planned a move from legacy code toward React and Redux, and used AWS Lambda functions to connect a client's CRM to the core platform. The point of that integration was not novelty. It allowed the client to remain inside a familiar interface while automation handled the tedious crossing between systems. Good software, in this telling, is a considerate host. It does not make a visitor learn the location of every cupboard.

Brown also interviewed engineering candidates and thought about how a growing team could remain organized without accumulating red tape. This belongs in the same story as interface design. Users encounter the habits of the team that built the product. Confused ownership eventually becomes a confused screen. An organization that cannot decide cleanly tends to make software that asks its customers to do the deciding for it.

The neat destination

At Dscout, behavior is not background noise

Brown now works as a lead software engineer at Dscout. The company makes a platform for experience research: diary studies, interviews, usability tests, surveys, participant recruitment and analysis. Researchers can ask people to record moments in context, talk through a prototype, complete a task or reflect over time. The product has also expanded into AI-assisted study design, moderation and analysis. Its premise is that decisions improve when teams can get closer to what people actually do and say.

There is a satisfying circularity here. In his 2017 essay, Brown warned developers to distinguish between the features they imagine a user will want and the things users genuinely use. At Dscout, that distinction is the business. The platform exists to replace a hunch with evidence, though of course evidence arrives with its own technical demands: video has to upload, permissions have to behave, participants have to understand a prompt and researchers have to find meaning in a great deal of messy material.

Research software also carries a peculiar burden. A clumsy tool can change the behavior it is meant to observe. A baffling question builder can weaken a study before a participant sees it. A broken recording flow can turn an honest moment into a technical support episode. Brown's background does not prove how any single Dscout feature was made, and his public record does not assign him a personal catalogue of them. It does show why this is coherent terrain for him: front-end structure, customer workflow and human behavior are all present at once.

The industry around Brown has changed sharply since his bootcamp year. React matured. Cloud infrastructure became ordinary. AI moved from a specialist subject to a product requirement with a marketing budget. Brown's newest public repository, a small collection of development-setup scripts created in 2025, is almost comic in its modesty beside that upheaval. Yet setup scripts belong to the same philosophy: remove repeated friction, preserve attention, let a person get to the meaningful work faster.

Brown's public story is thin on theatrical declarations, which may be appropriate. Engineering is full of grand language attached to tiny inconveniences. His record offers something more durable: a set of choices repeated across different scales. Build for a recognizable need. Talk to the people using the product. Make the architecture easier for the next team to carry. Remove a click when a click has no reason to exist. Remember that elegance is not what the system knows about itself. Elegance is what it allows somebody else to forget.

New Orleans remains the stable coordinate. Brown studied there, trained there and built there while his teams and products acquired a wider radius. He can work on software used across borders without turning his biography into a departure lounge. That rootedness gives the career its final, appealing proportion. The tools travel. The questions travel. The engineer stays close to the place where he learned to ask them.