
James Hansen
Canada (Metro Vancouver)
Welcome
I’m James, a full-stack software developer in Langley in the Greater Vancouver Area. I build analytics, video, and cloud platforms for security software, working across C#, Python, TypeScript and Docker. My focus is backend systems, data, and the privacy and scale challenges that come with them. Have a look around.
For nine years I’ve worked on a C# and WPF based client for networked security cameras, and for two years on a cloud-based analytics platform, from a Python and Flask backend to an Angular and TypeScript frontend. I've led teams and built high-traffic PHP and MySQL web apps.
I work in Python with Flask, and TypeScript with Angular, all containerized with Docker and backed by MySQL and SQL Server. I also work in C# and .NET. Alongside the engineering I bring a strong data-analysis background and a master’s in public policy for the privacy and compliance side.
JustShowMe is a privacy filter that uses face detection algorithms to blur, erase or replace everyone except you on a video call, in real time. Other projects include a Laravel booking platform and a Python land-value mapper, all open source on my GitHub.
I use Claude Code to help solve problems faster, and have experience with local and cloud LLMs. I’ve also worked on OpenCV detection models and created AI workflows with Gemini for automated meeting and document summaries.
I finished a Master of Arts in Public Policy while working full time, strengthening my understanding of privacy, data governance and compliance.
Policy
Where my software work meets privacy, compliance and data governance.
Master of Arts in Public Policy
Policy, Compliance & Data Governance
Much of the software I have built sits where engineering meets regulation: privacy-sensitive video and detection data, access-control systems, and a cloud platform whose multi-region design keeps customer data separated by jurisdiction. That work, together with my volunteer community work on open civic data, raised questions I kept returning to, about how such data should be handled, what privacy protections need to be designed in from the start, and how regulation and compliance shape what a product can and cannot do.
To explore them properly, I completed an online Master of Arts in Public Policy while working full time, with training in law and governance, statistics and program evaluation, public finance, and economics. The result is an engineer who is comfortable on the compliance and data-governance side of building software: privacy by design, data residency, auditability, and the trade-off between what a system can do and what it should do.
This is increasingly part of backend work. Account onboarding has to be compliant, customer data has to be governed across regions, and logging, observability, and retention have to satisfy more than just the product team. I treat those constraints as design inputs rather than afterthoughts.
From Coursework to Codebase
The degree connected directly to the kind of systems I build. A few examples:
Law, Governance & Public Policy — how privacy and data-protection law translates into concrete software requirements, and how to reason about compliance instead of treating it as a checkbox.
Statistical Methods & Data Analysis — regression and descriptive statistics, the foundation of the analytics, dashboards, and metrics work I already do as an engineer.
Program Design & Evaluation — logic models, indicators, and outcome evaluation, which map cleanly onto product metrics, instrumentation, and measuring whether a feature actually achieves its goal.
International Organizations & Policy Regimes — how rules and regimes differ across borders, the same problem a multi-region, data-residency-aware platform has to solve in code.
Skills
The languages, tools and analytical methods I work with day to day.
Software Developer Experience
Current Technical Skills
TypeScript
Python
Docker & Cloud
Visual C# .NET
Visual C++
PHP & Javascript
Angular
MySQL & Microsoft SQL Server
Analytical Skills
Data Analysis
Data Engineering & Visualization
Program Evaluation
Qualitative Research
Public Finance & Microeconomics
Technical & Analytical Writing
Legacy Skills
Borland/Codegear Delphi
GrafX Visual Objects
Scripting
AI
How I use AI tools in professional software development, and where I think it’s heading.
Claude Code
Local and Cloud LLMs
Google Gemini API
OpenCV
My thoughts on AI
This essay is also published on my StashPop blog — read “My thoughts on AI” there.
We are going through a transformational time in Software Development. AI tools, like Claude and cloud/locally hosted LLMs, can rapidly develop complex code, fix bugs and solve problems.
By 2026, AI tools have become an expectation in software development. It's generally accepted that using these tools speeds up delivery. A controlled experiment found developers using GitHub Copilot completed a defined coding task 55.8% faster than a control group (Peng et al., 2023).
That being said, AI remains a controversial topic. AI-positive speeches may receive boos. AI has been associated with "slop" content, and power and water hungry data centres on the cloud. It has also been considered a threat to a large number of jobs in the workforce, putting the unwritten social contract and expectation of a stable job available for all in jeopardy.
The Pros
In a professional environment, my day-to-day experiences with AI is positive. With AI-assisted development I am able to focus more on the architecture, structure and goals of the project, rather than the nitty gritty of logic problems, process flows and race conditions that can end up consuming an entire day or more to figure out.
A brick wall or a small piece of missing knowledge can sometimes be overcome with AI. An average engineer can tap into previously niche knowledge where documentation is limited, like DLL Hooking or code disassembly. The possibilities were always endless, but now they are becoming far more accessible.
Data Security
Of course, there are trade-offs. Using online AI models gives you the latest, smartest models, but risks sharing confidential or vulnerable code or data with a third-party. In those cases, models running on your own cloud, or locally, is preferable.
Additionally, Generative AI may not write code that is secure. Several studies have identified security weaknesses in AI generated code.
Labour force impact
As mentioned there is a threat to jobs that AI can automate. For simple code-bases, coding tasks and apps, AI can do a huge amount of this work, as demonstrated by sites like Lovable. There is less human work required for apps with a simple architecture as these are less likely to trip up an AI.
However, I don't believe that it will be the end of the Software Developer. A software developer is still needed to architect the application, solve usability issues, and even fix bugs where the AI gets stuck. The security concerns highlight the need for oversight and code review.
And this is why I believe this is a transition, not an end. A Software Engineer today is still needed to architect the software, but perhaps be a little bit more like a mechanic. A good mechanic understands how a vehicle works and the principles underneath, even if they weren't the engineer who designed each part.
Additionally there is the reality of "de-skilling," where when you become dependant on the AI, you lose the ability to write your own code from scratch. I have mixed feelings on this topic - before there was AI, there was Stack Overflow, where code snippets for common problems were free to copy and paste - engineers have always taken shortcuts. With complex code you still need to get in there and get your hands dirty, keeping the mind and skills fresh.
Some have compared it to the industrial revolution, where hand-crafted goods became uncompetitive with those from the production line, and those traditional skills were regrettably lost and became more limited in use in the real world.
Shortcomings
AI isn't perfect, at least not yet as of writing this (June 2026). It gravitates to bland-looking websites and interfaces, even if you explain or show it more unique or usable designs. It usually won't use the best libraries or code structures automatically if you don't research or plan it out yourself in detail first.
There is also the classic context problem. I recently asked Claude Opus to turn 3 boxes on a website, which all had roughly the same design, into a single component. But because this was part of a long laundry list of other fixes and improvements, the "single component" file it generated had a copy of each box inside, it did not recognize the similarities or how to make the component efficient, without this being pointed out and explicitly asked to do so. This sort of review and checking, and making sure the code is maintainable is the responsibility of the modern day software developer.
This ties into questions surrounding the technical debt risk of Generative AI. If there is a problem the AI is unable to solve properly, then a software engineer has to be ready to step in and figure out what is going wrong. This is something I have encountered in my work, even with the latest Claude Opus models, and why I always stay on top of the code the AI is generating. This is essential to avoid large technical debts where the engineer would have to spend a long time deconstructing months of AI generated code.
Pick a Side
Software developers are being forced to pick a side. AI is unpopular among some, yet at the same time, not embracing AI means you cannot compete with those who have. While I adopt AI as a tool, I reject a future where we are dependent on Anthropic or OpenAI to deliver code. I believe this is where the public resentment originates, people feel these large and powerful companies are disrupting their lives.
I am optimistic for a future where developers simply use LLMs either on a dedicated box or on their laptops to assist in their development. Much like the early days of computing were dominated by expensive mainframes offered by the likes of IBM, the "personal AI" revolution is around the corner.
Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). The impact of AI on developer productivity: Evidence from GitHub Copilot (arXiv:2302.06590). arXiv. https://arxiv.org/abs/2302.06590
Cloud
A plain-language walkthrough of how a containerized app is built, served and scaled in the cloud.
Most backend systems today run in the cloud. The advantage is that you can add machines when demand rises and give them back when it falls, so you pay for what you use and the system holds up under load.
This page walks through one common setup, a containerized application built from a JavaScript front end and a Python back end, from the code on a developer’s machine to a service that scales itself when traffic arrives. Other stacks differ in the details, but the stages are much the same.
To explain this process, I have broken it down into three stages. The code is built into a container, the container serves requests, and the running system scales up and down with demand. The three diagrams below take each stage in turn.
How it fits together
In this kind of deployment the container is the unit everything is built around. It packages an application with the exact versions of everything it depends on, so it runs the same way on a laptop, a test server, or a production cluster. Building one is a setup step that happens before any traffic arrives, and it is where the dependency tools do their work. On the front end that tool is npm, which gathers the JavaScript libraries and compiles them into the files a browser loads. On the back end it is pip, which installs the Python libraries, including the web framework and the server that runs it.
Once the container is running and a request comes in, it passes through a short chain of programs, each handling one part of the job. When a single running copy can no longer keep up, the system runs more copies and spreads the traffic across them, then removes the extras as demand drops. That last part, scaling, is handled by an orchestrator rather than by hand.
Building the container front end
TS / Angular / CSS]:::npm --> PJSON[package.json
+ lockfile]:::npm PJSON -->|npm install| DEPS[Dependencies
resolved ✓]:::npm DEPS -->|npm run build| BUNDLE[Compiled bundle
minified assets ✓]:::npm BUNDLE -->|placed into| IMG[(Container image)]:::infra classDef npm color:#111; classDef pip color:#111; classDef infra color:#111;
Building and serving back end
installed ✓]:::pip PYDEPS -->|placed into| IMG2[(Container image)]:::infra IMG2 --> RUN[Running container]:::infra BROWSER[Browser]:::infra -->|HTTPS| NGINX[nginx
front door]:::infra NGINX --> GUNI[Gunicorn
worker pool]:::pip GUNI --> FLASK[Flask
your logic]:::pip FLASK --> REDIS[(Redis cache)]:::infra FLASK --> PG[(PostgreSQL)]:::infra classDef npm color:#111; classDef pip color:#111; classDef infra color:#111;
Scaling under load
stable address]:::infra SVC --> P1[App copy 1
Flask + Gunicorn]:::pip SVC --> P2[App copy 2]:::pip SVC --> P3[App copy 3]:::pip SVC --> P4[App copy 4]:::pip HPA[Autoscaler
watches load]:::infra -.adjusts.-> SVC classDef npm color:#111; classDef pip color:#111; classDef infra color:#111;
An illustrative scaled state, shown static.
The job is the upkeep
Scaling is the part that gets the attention, but most of the work is in the setup and upkeep around it. Someone has to choose the resource limits, set the scaling targets, watch the logs when a service slows, and make sure the database underneath holds up while the layers above it multiply. The system runs itself once it is configured correctly, and configuring it correctly, then keeping it that way, is the job.
In future, the plan is that last diagram on this page may become interactive to demonstrate cloud scaling. You will be able to set a number of simulated users, start a run, and watch a real system scale up to meet the load and settle back down afterwards.
Community
Volunteer civic-technology and open-data work in Langley, BC.
Langley Urbanist Society

Giving back to my community matters to me. Outside of work I co-founded and direct the Langley Urbanist Society, a registered British Columbia non-profit, where I build civic-technology tools that make public information open and accessible, the same open-knowledge spirit I value in software. I look after the technical side: the website, email newsletters, automation scripts, and analytical tools.
I also lead the annual Jane's Walk in Langley, a free community walking tour exploring how our neighbourhoods work and how they could work better.
This runs alongside my engineering career rather than apart from it. The projects are a chance to keep practising my craft on real-world problems, particularly data analysis and visualization, in service of my own community.
Langley Urbanist Society Projects
Value per Acre
Council Meeting Summaries
The Telraam Traffic Counter

One project I am especially fond of is a Telraam traffic counter: a small device that mounts inside a window and automatically counts the pedestrians, cyclists, cars, and larger vehicles passing by, publishing the totals as open data anyone can view.
It began with a simple question, whether removing the gates on a local trail would change how many people walked and cycled there. Counting by hand was not practical, so we ran a fundraiser, the community covered the cost within a day, and after some door-knocking a resident with a clear view offered to host it. It now runs from a weatherproof box beside the trail, the first Telraam installed in British Columbia, with live counts anyone can follow over time.
Work History
Fifteen years in industry, most of it building security, analytics and cloud software.
Fortinet
Inchol Solutions
Zoombucks
CompuMAX Systems Corporation
Projects
Commercial cloud, analytics and desktop work, alongside open-source tools on GitHub.
Open-Source Projects
Just Show Me

VendorMap
Commercial Projects
FortiCamera Cloud — Video Analytics
FortiCentral — Security Device Management Client
Contact & Bio
A bit about my background, and how to get in touch.
Get In Touch
Send me a message and I will get back to you. I’m always glad to hear about interesting work and problems worth solving. You can also find me on GitHub and LinkedIn.
About Me
I was born in the mid-1980s and grew up during the peak era of accessible programming on personal computers, when switching a machine on dropped you straight into a BASIC prompt. Being born in the UK, my first language was BBC BASIC, which I started writing at eight years old on the Acorn Archimedes.
When the World Wide Web arrived I moved into HTML and CSS, and later PHP. I built increasingly complex PHP websites for various passion projects, and that hands-on experimentation became the foundation of everything that followed.
I put programming on pause to study Music Composition at university in London. After graduating I returned to it properly, turning years of self-taught experience into a career in software development.
Over the next fifteen years that career centred on security software, building analytics dashboards, customizable charting tools, camera metadata and detection analytics, access control systems, and Docker-based cloud video infrastructure. You can see some of this in my software projects and work history.
Following the Covid pandemic I found myself drawn to the policy and decision making around technology and governance. The work I was doing sat at the overlap of analytics, privacy, and regulation, and it raised questions I could not stop thinking about, about how detection and video data should be handled, what privacy protections need to be designed in from the start, and how regulation shapes what these products can and cannot do. Those questions led me to complete a Master of Arts in Public Policy online, studying alongside full-time work, with training in statistics, program evaluation, public finance, economics, governance, and law.
Outside of work I volunteer on civic-technology and open-data projects in my local community, applying the same engineering and analytical skills I use in software. You can read about that work on my Community page.
My life has benefitted from the belief that computing should be open and within everyone's reach. I like to think I'm keeping that tradition alive with my love of Raspberry Pi machines, which are sort of a spiritual successor to those old BBC Micros. While my son likes it mainly for Minecraft right now, it's simple, friendly nature invites the whole family to tinker and experiment with computing.