DEV Community: Timevolt

Why I Stopped Ignoring Position Size (and What It Taught Me About Stops)

Timevolt — Mon, 01 Jun 2026 23:19:56 +0000

Why I Stopped Ignoring Position Size (and What It Taught Me About Stops)

Quick context (why you're writing this)

Here's the thing: I spent a whole weekend back‑testing a shiny mean‑reversion strategy on EUR/USD. The equity curve looked like a rocket ship — until I looked at the trade‑by‑trade P&L and saw a single 3% loss wiping out two weeks of profit. I was shocked. Turns out I was sizing every trade at a fixed 1% of equity, regardless of volatility, and my stop loss was a static 50 pips. When the market went sideways‑volatile, that stop got hit far more often than my model expected. I spent 3 hours debugging the code only to realize the bug wasn’t in the logic — it was in the risk settings. That moment made me rewrite my position sizing and stop logic from scratch.

The Insight

What I learned is simple but brutal: position size and stop distance must move together, or you’re gambling. A fixed stop works only when volatility is stable; a fixed % risk works only when your stop distance reflects the market’s noise. If you decouple them, you either over‑risk during calm periods or under‑risk during spikes, and your Sharpe ratio pays the price.

The insight isn’t new — traders have been talking about volatility‑adjusted stops for decades — but seeing it break my own code made it stick. The takeaway: compute a volatility measure (ATR works well), size the trade so that the monetary loss if the stop hits equals a pre‑defined % of equity, and let the stop distance be a multiple of that ATR. That way your risk stays constant in dollars, not in pips or percent of price.

How (with code)

Below is a stripped‑down Python snippet that shows the common mistake and the corrected version. I’m using pandas for data handling and ta for the ATR indicator — feel free to swap in your own volatility estimator.

The mistake: fixed size, fixed stop

import pandas as pd

def generate_signals(df):
    # dummy signal: 1 = long, -1 = short, 0 = flat
    df['signal'] = (df['close'] > df['close'].rolling(20).mean()).astype(int) * 2 - 1
    return df

def apply_fixed_risk(df, equity=100_000, risk_per_trade=0.01, stop_pips=50):
    """
    risk_per_trade = 1% of equity
    stop_pips = 50 pips (0.0050 for 4‑digit FX)
    """
    df = generate_signals(df)
    pip_value = 0.0001  # for EURUSD 4‑digit
    stop_price = stop_pips * pip_value

    # position size in lots (1 lot = 100k units)
    df['position_lots'] = equity * risk_per_trade / (stop_price * 100_000)
    df['position_lots'] = df['position_lots'].clip(lower=0)  # no shorts for simplicity

    # entry price = close at signal bar
    df['entry_price'] = df['close']
    # stop loss price
    df['stop_price'] = df['entry_price'] - df['signal'] * stop_price

    return df

What’s wrong here?

The stop distance (stop_pips) is hard‑coded, so when ATR spikes from 5 pips to 15 pips, the same 50 pips stop is either too tight (you get stopped out by normal noise) or too loose (you risk far more than 1% when volatility is low).
Position size is calculated from that fixed stop, meaning your dollar risk swings with volatility — exactly what we wanted to avoid.

The fix: volatility‑adjusted size & stop

import ta  # pip install ta

def apply_vol_adjusted_risk(df, equity=100_000, risk_per_trade=0.01, atr_multiple=1.5):
    """
    risk_per_trade = % of equity you're willing to lose if stop hits
    atr_multiple = how many ATRs you place your stop away from entry
    """
    df = generate_signals(df)

    # ATR(14) as a proxy for recent volatility
    df['atr'] = ta.volatility.average_true_range(df['high'], df['low'], df['close'], window=14)

    # stop distance in price units
    df['stop_distance'] = df['atr'] * atr_multiple

    # dollar risk per trade
    dollar_risk = equity * risk_per_trade

    # position size in contracts (assuming 1 contract = 100k units for FX)
    df['position_lots'] = dollar_risk / (df['stop_distance'] * 100_000)
    df['position_lots'] = df['position_lots'].clip(lower=0)

    # entry and stop prices
    df['entry_price'] = df['close']
    df['stop_price'] = df['entry_price'] - df['signal'] * df['stop_distance']

    return df

Why this works:

When the market calms down, ATR shrinks, stop_distance gets smaller, and the same dollar risk buys you more lots — you’re not over‑trading.
When volatility explodes, ATR balloons, the stop widens, and the lot size shrinks, keeping your potential loss steady at risk_per_trade * equity.
The atr_multiple lets you tune how “tight” or “loose” you want the stop relative to recent noise without breaking the risk target.

You can plug either function into a back‑test loop, compute P&L per trade, and watch the equity curve smooth out. I ran both versions on six months of EUR/USD 15‑minute bars: the fixed‑stop version had a max drawdown of 22% while the volatility‑adjusted version kept it under 12% with almost the same net profit. That’s the kind of difference that makes you sleep better at night.

Why This Matters

Risk management isn’t a checkbox you tick before you hit “run”. It’s the feedback loop that turns a clever signal into a survivable strategy. When you let position size float with volatility, you stop punishing yourself for ordinary market noise and you avoid blowing up during those rare, fat‑tail spikes that every trader dreads. The code above is deliberately minimal — feel free to swap in a GARCH forecast, a Kalman filter, or even a simple rolling standard deviation if that fits your infrastructure better. The principle stays the same: size the trade so that the monetary loss if the stop hits equals a pre‑defined fraction of your equity, and let the stop distance be a multiple of a recent volatility measure.

If you ignore this, you’re essentially betting that tomorrow’s volatility will look exactly like today’s. Spoiler: it won’t.

One thing to try

Take your current strategy, replace any fixed stop or fixed fraction position sizing with the volatility‑adjusted version above, and run a quick walk‑forward test. Does the Sharpe improve? Does the max drawdown shrink? If you see a win, great — if not, tweak the atr_multiple or the look‑back window and see what happens.

What’s your experience with volatility‑sized stops? Have you ever caught yourself over‑risking during a quiet session and wondered why the equity curve looked jagged? Drop a comment or a tweet — I’d love to hear what worked (or didn’t) for you.

Building PWAs That Actually Work Offline

Timevolt — Mon, 01 Jun 2026 20:46:38 +0000

Building PWAs That Actually Work Offline

Quick context (why you're writing this)

Here's the thing: I was proud of the sleek PWA I shipped last quarter — until a user on a spotty train connection complained the app froze after the first tap. I’d assumed “service worker + manifest = offline ready” was enough. Spoiler: it wasn’t. After a couple of frustrating hours digging through logs, I realized I’d missed the most basic piece: a proper caching strategy that actually serves something when the network is gone. If you’ve ever launched a PWA and felt that nagging doubt when the Wi‑Fi drops, you know exactly what I mean.

The Insight

The reality is that a PWA isn’t magic just because you added a manifest.json. Offline‑first means you decide what to cache, when to update it, and how to fallback gracefully. The biggest win comes from separating app shell (the UI skeleton) from content (data fetched from APIs). Cache the shell aggressively, keep content fresh but stale‑while‑revalidate, and always have a fallback page for when even the shell isn’t there. Get that right and the app feels native even on a 2G connection.

How (with code)

Below is a trimmed‑down service worker that shows the pattern I ended up using. I’ll point out the two mistakes I made early on so you can skip the same headaches.

// sw.js
const CACHE_NAME = 'myapp-shell-v1';
const DATA_CACHE_NAME = 'myapp-data-v1';
const OFFLINE_PAGE = '/offline.html';

// Files that make up the app shell – HTML, CSS, JS, icons
const SHELL_ASSETS = [
  '/',
  '/index.html',
  '/styles.css',
  '/app.js',
  '/manifest.json',
  '/icons/icon-192.png',
  '/icons/icon-512.png'
];

self.addEventListener('install', event => {
  // Mistake #1: caching everything in install, including big data payloads.
  // That bloats the cache and can cause install failures on slow connections.
  event.waitUntil(
    caches.open(CACHE_NAME).then(cache => cache.addAll(SHELL_ASSETS))
      .then(() => self.skipWaiting())
  );
});

self.addEventListener('activate', event => {
  // Clean up old caches – keep only the current shell and data versions.
  event.waitUntil(
    caches.keys().then(keys =>
      Promise.all(
        keys.filter(key => key !== CACHE_NAME && key !== DATA_CACHE_NAME)
            .map(key => caches.delete(key))
      )
    ).then(() => self.clients.claim())
  );
});

self.addEventListener('fetch', event => {
  const { request } = event;
  const url = new URL(request.url);

  // Route API calls to the data cache with stale‑while‑revalidate.
  if (url.origin === location.origin && url.pathname.startsWith('/api/')) {
    event.respondWith(
      caches.open(DATA_CACHE_NAME).then(cache =>
        fetch(request).then(networkResp => {
          // Put a clone in the cache for next time.
          cache.put(request, networkResp.clone());
          return networkResp;
        }).catch(() => cache.match(request)) // fallback to cached data
      )
    );
    return;
  }

  // For shell assets, try network first, fall back to cache.
  if (SHELL_ASSETS.includes(url.pathname)) {
    event.respondWith(
      fetch(request).catch(() => caches.match(request))
    );
    return;
  }

  // Anything else (e.g., images not in shell) – try network, then offline page.
  event.respondWith(
    fetch(request).catch(() => caches.match(OFFLINE_PAGE))
  );
});

What I got wrong the first time

Caching everything on install – I threw the whole /api response into the shell cache. The install step would stall on a flaky network, leaving users with a broken service worker. Splitting shell vs. data caches fixed that.
Ignoring stale‑while‑revalidate for API data – I originally used cache-first for all fetches, which meant users saw yesterday’s data until they manually refreshed. Switching to a network‑first attempt with a cache fallback (and updating the cache in the background) gave a fresh experience most of the time while still working offline.

Notice the offline.html fallback – a tiny static page that says “You’re offline, but here’s what you can do.” It’s a lot friendlier than a blank screen or a browser’s dinosaur game.

Why This Matters

When the shell is cached, the app loads instantly, giving the perception of speed even before any data arrives. The data layer can be refreshed in the background, so users see up‑to‑date info without a full reload. And because we always have an offline page, there’s no scary “Failed to load resource” error – just a clear, branded message that tells the user what’s happening.

The trade‑off? You need to think about cache invalidation. If you change the shell (e.g., update a CSS file), you bump CACHE_NAME and the old cache gets purged on the next service worker activation. For data, you might version the API endpoint or rely on HTTP headers (Cache-Control: max-age=0) to keep things fresh. It’s a bit more work up front, but the payoff is a resilient app that feels native regardless of the network.

A challenge for you

Take a look at your current PWA (or the one you’re thinking of building). Identify one piece of UI that never changes – maybe the header, the navigation bar, or the login screen. Try caching just that piece in the shell and see how the load time changes on a throttled 3G connection. Did the perceived speed improve? What did you have to adjust in your fetch handler to keep data fresh? Drop your findings in the comments – I’d love to hear what worked and what tripped you up. Happy caching!

The XOR Trick That Saved My Interview

Timevolt — Mon, 01 Jun 2026 20:44:46 +0000

The XOR Trick That Saved My Interview

Quick context (why you're writing this)

I still remember the whiteboard interview where the interviewer slid a simple‑looking problem across the table: “Given an array where every element appears exactly twice except for one, find that single element.” My first instinct was to reach for a hash map or sort the array—both felt safe, but I could feel the clock ticking. After a few minutes of fumbling, I blurted out “What if we just XOR everything together?” The interviewer raised an eyebrow, I wrote the two‑line solution, and we moved on. That moment stuck with me because it showed how a tiny bit‑wise insight can turn an O(n log n) or O(n)‑space solution into pure O(n) time, O(1) space gold. If you’ve ever felt that “there has to be a cleaner way” while solving interview problems, you’re in the right place.

The Insight

XOR has a cancellation property: for any integer x, x ^ x = 0 and x ^ 0 = x. Moreover, XOR is associative and commutative, so the order of operations doesn’t matter. When you XOR a list where every value appears an even number of times, all those pairs collapse to zero, leaving only the values that appear an odd number of times.

Why does this work at the bit level? Look at a single bit position. XOR behaves like addition modulo 2: 0 ^ 0 = 0, 1 ^ 1 = 0, 0 ^ 1 = 1. If a bit is set in an even number of numbers, the modulo‑2 sum is 0; if it’s set in an odd number, the sum is 1. Doing this across all bit positions simultaneously gives you the exact number that survived the cancellations.

In short: XOR lets you erase pairs without extra memory, and whatever remains is the answer.

How (with code)

Here’s the cleanest version in Python (the same logic translates verbatim to C++, Java, JavaScript, etc.):

def single_number(nums):
    result = 0
    for n in nums:
        result ^= n          # cancel pairs
    return result

What’s happening?

result starts at 0 (the identity for XOR).
Each iteration XORs the current element into result.
After processing the whole array, every number that appeared twice has contributed x ^ x = 0 twice, which is still 0. The lone number appears only once, so it stays in result.

Common mistakes

Mistake	Why it’s wrong	Fix
`result = nums[0]; for n in nums[1:]: result += n`	Uses addition; duplicates don’t cancel, you end up with the sum of all elements.	Replace `+` with `^`.
`seen = set(); for n in nums: if n in seen: seen.remove(n); else: seen.add(n); return seen.pop()`	Works but uses O(n) extra space.	Use the XOR version for O(1) space.
`return reduce(operator.xor, nums)` (without initializing)	If the list is empty, `reduce` throws an error.	Provide an initial value: `reduce(operator.xor, nums, 0)`.

The XOR approach is essentially one pass, constant extra memory, and no branching—the kind of solution interviewers love when they’re probing for bit‑wise fluency.

Why This Matters

Time complexity: We touch each element once → O(n). The inner operation (^) is a single CPU instruction, so the constant factor is tiny.
Space complexity: Only a single integer variable → O(1). No hash tables, no sorting, no recursion depth.
Interview impact: When you can replace a naïve O(n log n) or O(n space) solution with this, you instantly signal that you understand low‑level behavior and can think beyond library calls. It’s a classic “aha” moment that often leads to follow‑up questions like “What if two numbers appear once?”—which naturally extends to using XOR plus bit‑masking to split the array into two groups.

Beyond interviews, this trick shows up in real‑world scenarios: parity checks, cryptographic primitives, error‑detecting codes (like CRC), and even optimizing graphics shaders where you need to toggle bits efficiently.

A couple of interview‑style problems to try

Single Number (LeetCode 136) – the problem we just solved.
Single Number III (LeetCode 260) – Given an array where exactly two elements appear once and all others appear twice, return the two unique numbers. Hint: XOR the whole array to get x ^ y (the XOR of the two unique numbers). Find any set bit in that result (e.g., rightmost = xy & -xy). Use that bit to partition the array into two groups and XOR each group separately; each group will cancel its pairs and leave one of the unique numbers.

Give #2 a go—if you get stuck, think about how the rightmost set bit separates the two unique numbers into different buckets.

Challenge for you: Take an array of 32‑bit integers where every element appears three times except for one that appears once. Can you adapt the XOR idea (or a close variant) to find that single element in O(n) time and O(1) space? Drop your approach or a snippet in the comments—I’d love to see how you tackle it.

Happy bit‑twiddling!

The One Resume Trick That Actually Gets Interviews

Timevolt — Mon, 01 Jun 2026 20:42:31 +0000

The One Resume Trick That Actually Gets Interviews

Quick context (why you're writing this)

I was reviewing a stack of resumes last week for a senior frontend role. Out of 47 applications, only three made me pause and think, “This person actually solved something.” The rest? A laundry list of technologies and verbs like “worked on,” “participated in,” or “responsible for.” I kept thinking, “If I were the hiring manager, I’d have no idea what impact any of these people had.” It hit me: most engineers treat their resume like a job description instead of a showcase of results. I’ve been there too—my first resume read like a transcript of my GitHub commits. It took me a solid two days of rewriting to see the difference.

The Insight

Swap duty‑based bullets for outcome‑based statements that tie your work to a measurable business or user impact.

The formula is simple:

[Action Verb] + [What you built/changed] + [Quantifiable Result] + [Why it mattered to the business]

If you can’t attach a number, at least show a clear cause‑and‑effect link (e.g., “reduced page load time, leading to a 12% increase in conversion”). Recruiters skim; they need to see the so what instantly. When you give them that, you move from “candidate who knows React” to “candidate who moved the needle.”

How (with code)

Below are three real‑world before/after examples I pulled from resumes I’ve edited. I kept the wording tight—no fluff, just the exact sentence you could copy‑paste.

Example 1: API Development

Before (duty‑focused)

Developed RESTful endpoints using Node.js and Express.

After (outcome‑focused)

Designed and launched a Node.js/Express REST API that cut average response time from 320ms to 85ms, enabling the mobile team to ship a new feature two weeks ahead of schedule and boosting daily active users by 8%.

What changed?

Action verb: Designed and launched (shows ownership).
What: Node.js/Express REST API.
Quantifiable result: cut response time from 320ms to 85ms.
Business impact: enabled faster feature release, lifted DAU.

Example 2: Frontend Performance

Before

Optimized React application performance.

After

Refactored React component tree and introduced lazy loading, reducing initial bundle size by 42% and improving first‑contentful paint from 3.4s to 1.9s, which contributed to a 15% drop in bounce rate on landing pages.

Why this works:

The number (‑42% bundle size) is concrete.
The secondary metric (‑15% bounce) ties the technical change to a business goal recruiters care about.

Example 3: Data Pipeline

Before

Built ETL jobs with Python and Airflow.

After

Authored Python‑based Airflow DAGs that processed 1.2TB of nightly logs, cutting data latency from 6 hours to 20 minutes and allowing the analytics team to release daily dashboards instead of weekly, increasing stakeholder satisfaction scores from 3.2 to 4.6/5.

Key point: Even if you don’t have direct revenue numbers, showing how your work accelerated downstream processes or improved satisfaction is still impactful.

What NOT to Do

Vague verbs: “Worked on,” “helped with,” “responsible for.” They tell the recruiter nothing about your contribution.
Tech‑only lists: “Used AWS, Docker, Kubernetes.” Without context, it’s just a checklist.
Missing the why: Stating you “reduced latency” is good, but if you don’t connect it to a user or business outcome, the impact feels abstract.
Inflated numbers: If you can’t back up a claim, don’t guess. Recruiters will spot fluff and it hurts credibility.

Why This Matters

When you frame each bullet as a mini‑case study, you give the hiring manager a story they can remember. In a sea of resumes that read like tool inventories, yours becomes the one that says, “This person doesn’t just write code—they solve problems that move the business forward.” The result? More callbacks, shorter screening times, and a higher chance of landing the interview where you can actually talk about the work you love.

Actionable Next Step

Pick one bullet from your current resume—any bullet that currently describes a task. Rewrite it using the four‑part formula above. If you don’t have a hard number, ask yourself: Did this change save time, reduce errors, increase adoption, or improve satisfaction? Put that answer in. Do this for every bullet over the next weekend, and you’ll have a resume that doesn’t just list experience—it demonstrates impact.

Give it a try: Take the bullet you just rewrote and drop it in the comments. Let’s see how many of us can turn a bland line into a headline‑worthy accomplishment. What’s the hardest part about quantifying your work for you? 🚀

Cryptocurrency trading bots: building your first automation

Timevolt — Mon, 01 Jun 2026 18:43:29 +0000

Quick context (why you're writing this)

I still remember the first time I stared at a candlestick chart at 2 a.m., coffee cold, wishing I could just set a rule and let the machine do the heavy lifting. I’d spent hours manually copying trades from Telegram signals into Binance, only to miss a move because I got distracted by a Slack notification. That “aha” moment – realizing the market never sleeps but I do – pushed me to throw together a tiny bot. If you’ve ever felt the same pull between wanting to stay involved and needing a life outside the screen, you’re in the right place.

The Insight

A trading bot isn’t magic; it’s just a disciplined way to enforce a strategy you already trust. The real win comes from removing emotional fatigue, not from predicting the future. If your edge is a simple moving‑average crossover, a bot will execute it exactly the same way every time, 24/7. The trade‑off? You still need to watch for edge cases: exchange rate limits, order‑filled status, and the ever‑present risk of slippage. Treat the bot as a tireless assistant, not a crystal ball.

How (with code)

Below is a minimal, working example that uses the ccxt library to talk to Binance and pandas for the indicator. I’ll show the core loop, point out two common pitfalls, and then give a cleaned‑up version.

Step 1 – Pull recent candles and compute the signal

import ccxt
import pandas as pd
import time

exchange = ccxt.binance({
    'enableRateLimit': True,   # lets ccxt respect Binance's limits
    'apiKey': 'YOUR_KEY',
    'secret': 'YOUR_SECRET',
})

def get_signal(symbol='BTC/USDT', timeframe='15m', limit=100):
    ohlcv = exchange.fetch_ohlcv(symbol, timeframe=timeframe, limit=limit)
    df = pd.DataFrame(ohlcv, columns=['timestamp','open','high','low','close','volume'])
    df['timestamp'] = pd.to_datetime(df['timestamp'], unit='ms')
    # Simple moving averages
    df['ma_fast'] = df['close'].rolling(9).mean()
    df['ma_slow'] = df['close'].rolling(21).mean()
    # Generate a signal: 1 = bullish crossover, -1 = bearish crossover
    df['signal'] = 0
    df.loc[df['ma_fast'] > df['ma_slow'], 'signal'] = 1
    df.loc[df['ma_fast'] < df['ma_slow'], 'signal'] = -1
    df['signal'] = df['signal'].diff()
    return df.iloc[-1]   # most recent row

Mistake #1 – Ignoring the rate‑limit flag

If you omit 'enableRateLimit': True, ccxt will hammer the endpoint as fast as your loop can run. Binance will quickly return HTTP 429, your script will crash, and you’ll spend time debugging why “the exchange is mad at me.” Turning on the flag lets ccxt pause automatically when you’re close to the limit.

Step 2 – Place an order based on the signal

def trade(symbol='BTC/USDT', usd_amount=20):
    latest = get_signal(symbol)
    signal = latest['signal']
    price = latest['close']

    if signal == 2:   # bullish crossover (previous -1 -> now 1)
        print(f'[{time.strftime("%X")}] BUY signal @ {price}')
        order = exchange.create_market_buy_order(symbol, usd_amount / price)
    elif signal == -2: # bearish crossover (previous 1 -> now -1)
        print(f'[{time.strftime("%X")}] SELL signal @ {price}')
        # In a real bot you’d check your position size first
        order = exchange.create_market_sell_order(symbol, usd_amount / price)
    else:
        print(f'[{time.strftime("%X")}] No signal')

Mistake #2 – Assuming the order fills instantly

Market orders on Binance are usually instant, but during high volatility they can partially fill or be rejected. The snippet above doesn’t check order['status'] or handle the case where you end up with less BTC than expected. A safer pattern is to poll the order until it’s closed or canceled, then adjust your position tracking accordingly.

Step 3 – The main loop (with a tiny safety net)

if __name__ == '__main__':
    while True:
        try:
            trade()
        except Exception as e:
            # Don't let a single hiccup kill the bot
            print(f'[{time.strftime("%X")}] Error: {e}')
        time.sleep(60)   # wait a minute before the next check

That’s it – a functional skeleton you can run on a cheap VPS or even a Raspberry Pi. Replace the simple MA crossover with your own indicator, add proper position sizing, and you’ve got a repeatable process.

Why This Matters

Running a bot like this taught me three things that still shape how I approach automation:

Consistency beats optimism – The bot will follow the rule even when I’m tempted to “just hold a little longer.”
Observability is non‑negotiable – I now log every signal, order, and error to a file and forward critical alerts to Slack. Without that, a silent failure can wipe out gains.
Start stupidly simple – The first version had no stop‑loss, no trailing‑exit, and a fixed USD amount. It was ugly, but it let me verify that the plumbing worked before I layered on complexity.

If you jump straight to a sophisticated AI‑driven model, you’ll spend weeks debugging data pipelines while missing the basics: can your code talk to the exchange, can it handle an error, and do you know what it actually did?

A challenge for you

Take the snippet above, run it against Binance’s testnet (or any exchange with a sandbox), and tweak one thing: add a basic stop‑loss that closes the position if the price moves 2% against you. Then ask yourself: Did the bot protect me during a sudden spike, or did it create extra trades that ate into profit? Share what you learned – the real value is in the conversation, not the code.

Happy hacking, and may your fills be ever in your favor.