标签：#productivity

For the last 3 months I recorded every session I had with Claude Code. Not screenshots, not memory. Every prompt I typed and everything it did, saved to a small database I own. I did it because I kept losing my own work. I would finish a week, someone would ask what I shipped, and I genuinely could not remember. The work was real. It just lived in terminal scrollback I would never scroll through again. So I set up a chain of small agents to remember it for me. Every night, while I sleep, one agent reads that day's raw sessions and writes a single clear note: what I built, the decisions I made, what is still open. Plain language, the way I would write it in a journal, not a wall of logs. Once a week, a second agent reads all seven daily notes and updates a profile of me: the projects I am moving, the skills I have actually used, the things I learned. After a few months this turned into a more honest picture of my work than my resume. Then a third agent reads all of that and drafts posts for LinkedIn and X about what I actually worked on that week. Building in public, without me having to remember or sit down and write. The part I like most: none of it runs on my machine. It is all scheduled cloud routines. My laptop can be off. I wake up and the notes, the profile, and the draft posts are already waiting. I have started open-sourcing this as Pulse. The capture and the nightly daily-note agent are out now. You point it at your own database and your own notes repo, and it writes your day for you, in plain English, in files you own. The weekly profile agent and the post-writer are the pieces I am extracting next. It is early and rough in places. The honest caveat: the writing is only as good as the model behind it, and a quiet day still makes a quiet note. But after 3 months, I no longer guess what I did. I just open the vault. The graph at the top is 3 months of my own notes, each day linked to the projects it touched. Repo: https://github.com/muhammademanaftab/pulse

A few months ago, if someone had asked me to build a mobile app, I would've had absolutely no idea where to start. Today, an app I built is on the Google Play Store. It's called Stulo, and it's currently in closed testing. The funny part? I'm not a software engineer. I'm just a college student who got tired of missing opportunities. Internships were on LinkedIn, hackathons were buried somewhere on Instagram, college events lived inside WhatsApp groups, and competitions were scattered across random websites. If the algorithm didn't like you that day, you simply never found them. That felt... ridiculous. So I asked myself, "Why isn't there one place where students can find everything?" That simple question eventually became Stulo. Today, students can discover internships, hackathons, competitions, campus events, connect with other students, and share updates through a campus feed—all in one app. The biggest lie I believed was that building the app would be the hard part. It wasn't. Understanding why it wasn't working was. I built the first version using Emergent because, honestly, I didn't know enough to start from scratch. It got me surprisingly far. As the project became more serious, I moved development to Google AI Studio (Antigravity). That's when I learned something every AI-generated YouTube thumbnail forgets to mention: AI doesn't build products. It generates code. There's a huge difference. AI happily writes hundreds of lines of code, but it doesn't explain why your images randomly stop rendering after ten minutes, why scrolling suddenly feels like you're using a phone from 2013, or why fixing one bug somehow creates three completely unrelated bugs. Most days followed the exact same routine: generate code, run the app, watch something break, Google the error, ask AI, read Stack Overflow, realize the problem was my own code, and repeat. Some bugs took ten minutes to fix, while others stole an entire weekend. Looking back, one of the biggest things I learned wa

The problem: agents forget your project every session If you pair with a coding agent, you have lived this: a new session starts and the context is gone. The agent re-discovers your auth flow, re-guesses why a decision was made, re-reads the same files to rebuild a mental model you already explained yesterday. Project knowledge — the why behind your systems, the runbooks, the "don't touch this, here's the reason" — lives scattered across wikis, code comments, and people's heads. None of it travels with the code, and none of it survives a fresh context window. CLAUDE.md helps, but it's for standing instructions , and it gets loaded wholesale into every prompt. Auto-memory captures what an agent picked up, but it's implicit, per-agent, and not reviewed. A wiki is for humans and needs exporting. There's a gap: curated team knowledge that's structured, versioned with the code, and readable by any agent or person. What OKF is Open Knowledge Format is an open, vendor-neutral format (announced by the Google Cloud Data Cloud team in June 2026, Apache-2.0) that represents knowledge as a directory of markdown files with YAML frontmatter . That's the whole idea. No schema registry, no runtime, no SDK. If you can cat a file you can read it; if you can git clone a repo you can ship it. A bundle looks like this: .okf/ ├── index.md # progressive disclosure (root carries okf_version) ├── log.md # ISO-dated change history, newest first ├── services/auth-api.md # one concept = one file; path is its ID ├── datasets/orders-db.md ├── decisions/use-okf.md ├── runbooks/payment-failures.md └── metrics/checkout-conversion.md Each concept needs exactly one thing to be conformant: YAML frontmatter with a non-empty type . Everything else is optional. --- type : Service title : " Auth API" description : " Issues and verifies short-lived access tokens." resource : https://github.com/acme/auth tags : [ auth , platform ] timestamp : 2026-06-14T10:00:00Z --- # Endpoints | Method | Path | Descriptio

Hello again, DEV Community!I recently shared my project, Jesse Math Rock Star, and the feedback from this community has been incredibly supportive.For those who don't know me, I am 11 years old. I started coding with Scratch when I was 8, and I built this production web app using self-explored vibe coding, Google's Gemini models (via AI Studio), and Vercel!Looking at my analytics, 61% of my visitors are using mobile phones, mostly Android. I want to make sure the app feels perfect and fun for kids my age to use on small touchscreens.Could you do me a quick favour?Open the app on your phone: https://jesse-math-rockstar-app.vercel.app/ a quick round of math.Leave a comment below with your advice on the user interface (UI) and layout!Thank you all for being such a safe and helpful community for early-career builders! ( https://jesse-math-rockstar-app.vercel.app/ )

I've been working on Churo, an open-source voice assistant built entirely in Python. It features high-quality speech-to-text and text-to-speech, web search, image understanding, and agentic capabilities. It runs with Ollama models and is designed to be easy to modify and extend. The goal is to provide a capable, local-first voice assistant that developers can actually inspect, customize, and build on. Repository: https://github.com/MathObsession/Churo-assistant or run it with(You need Ollama): pip install churovoice churovoice --voice male Feedback, issues, and contributions are welcome.

For the last two years, one skill dominated every AI conversation: Prompt engineering. People spent hours crafting the "perfect" prompt. They built prompt libraries. They sold prompt templates. They believed that better prompts meant better AI. But AI has evolved. The bottleneck is no longer the prompt. It's the context . The Prompt Was Never the Problem Imagine asking an AI: "Build me a secure authentication system." A perfect prompt isn't enough. The AI also needs to know: Which programming language you're using Your existing codebase Your framework Your database schema Your security requirements Your coding standards Your deployment environment Your team's conventions Without that information, even the best model is forced to guess. And AI is terrible at guessing. What Is Context Engineering? Context engineering is the practice of giving AI everything it needs to solve a task—not just instructions. It's about designing the right environment for the model to think. Context includes: Source code Documentation Project architecture Previous conversations Git history APIs Logs Tool outputs User preferences Business requirements Memory Constraints The prompt tells AI what to do. The context tells AI how to do it correctly. Why Prompt Engineering Is Reaching Its Limits A prompt is static. Real work isn't. Projects change. Requirements evolve. Files get updated. Tests fail. New bugs appear. The AI must continuously receive fresh information. That's impossible with a single prompt. Instead, modern AI systems constantly rebuild their context as they work. Think About AI Coding Agents Why do AI coding agents feel dramatically smarter than a normal chatbot? Not because they have better prompts. Because they constantly gather context. They can: Read your repository Search across files Run terminal commands Execute tests Inspect logs Read documentation Fix errors Verify changes Remember previous actions Every step adds more context. Every iteration makes better decisions. Cont

I built a free n8n workflow that writes your launch content for you. It broke three times before it worked, and the third break is the only part of this post worth reading. The problem Every time I ship a new digital product, I write the same five things: a short blog intro, a LinkedIn post, an X post, an Instagram caption, and a launch email. Same structure every time, different product. The kind of task that's boring enough to automate but annoying enough that I kept putting it off. So I built Launch Content Pack : an n8n workflow that takes one product description and generates all five, using an LLM node wired up with Claude Code on the customization side. It's free, it's on Gumroad, and the JSON is the whole product — open it, see every node. Why bother when there are 9,000+ free n8n templates already There are. I checked before building this, because there's no point shipping a workflow that already exists for free somewhere else. What's actually missing from most of those templates: nobody validates the nodes. A huge chunk of free n8n templates floating around were generated by someone (often an LLM) guessing at node types and parameters, and they quietly break the moment n8n ships a version update. I used n8n-mcp , a free MCP server, to confirm every single node type, version, and parameter against n8n's actual schema before writing any JSON. No guessing. That sounds like a small difference. It's the reason this post exists. The bug that actually mattered I tested the workflow in n8n Cloud. Two nodes ran clean — green checkmarks, no errors. Then the Code node that's supposed to take the LLM's output and split it into five labeled fields threw: Cannot read property 'text' of undefined My first guess was wrong. I assumed the LLM node's output field was named something other than text — output , maybe, or response — and that I just had the wrong field name in the Code node. Reasonable guess. Also not the actual bug. Here's what was really happening. The OpenAI

Disclosure: I'm Aditya Kachave, co-founder of Be10x. We sell AI training, so read this knowing I have skin in the game. I've tried to write the version I'd want even if I weren't selling anything. There's a lot of noise telling professionals they'll be "left behind" if they don't master AI immediately. Most of it is fear used as a sales lever — and I say that as someone in the business. Here's a calmer framework I actually believe in. Four levels, not a cliff You don't go from zero to "AI expert." You move through levels, and most people only ever need the first two. Level 1 — Aware. You understand roughly what these tools can and can't do. You know they predict plausible text, which is why they sometimes make things up. This alone protects you from both the panic and the over-trust. Level 2 — Applied. You use a tool to do one or two real tasks in your job — drafting, summarizing, reformatting. This is where the actual productivity lives, and where 90% of professionals should aim to land. Level 3 — Integrated. You've built repeatable workflows and you reach for AI reflexively on the right kinds of tasks. Useful, not urgent. Level 4 — Building. You're chaining tools, using APIs, automating across systems. This is genuinely technical and most people don't need it. (The dev.to crowd is the exception — many of you live here.) The one mental model that matters most Think of current AI as a fast, confident, occasionally-unreliable assistant. That single framing tells you how to use it correctly: You delegate first drafts, not final decisions. You verify anything that matters. You never hand it confidential data without checking where that data goes. If you internalize only that, you're ahead of most people throwing money at courses. What's actually worth your time Worth it: Picking one recurring task and getting genuinely good at routing it through a tool. Worth it: Learning to write clear, constrained instructions (a transferable skill, not a tool-specific trick). Not wo

I Deployed 6 AI Systems Live — Here's What Actually Broke A few weeks ago I wrote about the 5 bugs that cost me 60+ hours building 49 AI systems. Every one of those bugs lived inside the code itself wrong array layout, a renamed model class, a serialization mismatch. This article is the second half of that story, and it taught me something more uncomfortable: code that runs perfectly on your machine can fail completely the moment it leaves your machine for reasons that have nothing to do with your code. I took 6 of my pinned GitHub projects and deployed every one of them live on Streamlit Cloud. Locally, all 6 worked without a single error. Deploying them surfaced 5 failures I had never seen before, none of which were bugs in my logic. Here they are, in the order I hit them. Failure 1 — A Module That Existed Yesterday, Gone Today My RAG chatbot used this import, unchanged for weeks: from langchain.chains import ConversationalRetrievalChain Locally: works. Deployed: instant crash. ModuleNotFoundError: No module named 'langchain.chains' The cause had nothing to do with my code. My local environment had an old, cached version of LangChain installed months ago. The deploy environment did a clean install and pulled whatever the latest version was at that moment and recent LangChain releases moved legacy chain classes like this one out of the core package entirely. The fix that actually worked pin the exact version that still contains the class, rather than chasing the newest API pattern under deployment pressure: langchain = =0.3.7 langchain-community = =0.3.7 The lesson: "it works on my machine" is frequently true specifically because your machine never reinstalled anything recently. A clean deploy environment has no such luxury it gets whatever is newest the moment it builds. Pin your versions before you ever need to debug this at 1 AM. Failure 2 — A File That Exists, Until It Doesn't My construction RAG project loads a prebuilt FAISS vector index from disk: vectorstor

Most multi-tenant email-agent setups give every customer the same caps. Your free-tier user who signed up an hour ago and your enterprise account doing thousands of sends a day hit the exact same daily send limit, the exact same storage ceiling, the exact same retention window. That's fine right up until a free trial account starts hammering your infrastructure, or an enterprise customer files a ticket because their agent stopped sending at noon UTC and nobody can explain why. Free-tier and enterprise tenants shouldn't share the same caps. They have different risk profiles, different contractual obligations, and different billing. The trick is to make the quota a property of the tier, not a property of each individual account — so when you provision a new tenant you don't compute limits, you just drop them into the right bucket and the limits come along for free. With Nylas Agent Accounts that bucket is a workspace , and the caps live on a policy you attach to it. Set up one policy per tier, attach each to its tier's workspace, and every Agent Account in that workspace inherits the policy's send, storage, and retention limits automatically. No per-account configuration, no drift. I work on the Nylas CLI, so the terminal commands below are the exact ones I reach for when I'm wiring this up. As always, I'll show both the raw HTTP call and the CLI equivalent for every step, because half of you live in scripts and the other half live in your app code. What you actually get An Agent Account is just a Nylas grant with a grant_id — a managed mailbox that can send and receive on a domain you've registered. Everything grant-scoped works against it: Messages, Drafts, Threads, Folders, the lot. There's nothing new to learn on the data plane. A policy is a reusable bundle of limits and spam settings. One policy can govern many accounts. The limits we care about for tiering are: limit_count_daily_email_sent — how many messages an account can send per day. limit_storage_total — t

Most job search tools focus on submitting more applications. I wanted to solve a different problem: reaching the people actually making hiring decisions. So I built PitchHired , an AI-powered platform that helps job seekers find hiring managers, generate personalized outreach emails, review them with AI, and send them from their own Gmail account on a business-hours schedule. The goal isn't to replace the job search, it's to remove repetitive work while keeping the candidate in control. I also chose a one-time credit model instead of monthly subscriptions because job seekers shouldn't have to keep paying while they're between opportunities. PitchHired is still evolving, and I'd genuinely appreciate feedback from fellow developers. What features would you want in a tool like this, and what would make you trust (or not trust) AI-assisted job search?

Headline: The wins come from context, not cleverness. An AI with your codebase, your design system, and your deploy logs in scope writes code that ships. Without that scope, it writes plausible code that doesn't. Two years ago, AI coding tools were autocomplete with attitude. In 2026 they are a credible second engineer — provided you build the workflow around them. This is the workflow I run today at Devya Solutions and on personal projects like eng-ahmed.com . The Stack Claude Code in the terminal — long-horizon, multi-file edits with skills and subagents. MCP (Model Context Protocol) servers for live access to docs, deployments, browser, and design tools. Cursor or VS Code for inline edits when I want to stay in the IDE. Why Context Is Everything The single highest-leverage move in AI-assisted dev is feeding the model the right context. MCP servers do this without prompt stuffing. Docs MCP — pulls current library docs at call time, so the model doesn't hallucinate the Tailwind v3 API in a v4 codebase. Browser MCP (Claude-in-Chrome) — lets the agent open the running dev server, screenshot the page, and verify the change actually rendered. Vercel MCP — fetches deploy logs and runtime errors directly. No more pasting logs. Context-mode MCP — keeps file scans, search results, and command output in a sandbox, only surfacing what's relevant to your conversation. A Real Workflow The blog page redesign I just shipped was built in a single 45-minute session. Rough flow: State the goal — two sentences, not a spec doc. Let the agent scout — Claude Code greps, reads a few files, proposes a plan. Iterate visually — screenshot the result, feed it back. The agent fixes the sticky-filter scroll bug in one turn. Commit and push — a single cm shortcut runs build, commits, and pushes. Vercel deploys on push. What the Agent Is Still Bad At Holistic taste — it copies the closest example in your codebase. If that's mediocre, the new feature is mediocre. Domain knowledge — it doesn't kn

Hello Devs 👋 AI coding assistants have changed the way many teams build software. Tasks like generating components, creating tests, writing boilerplate, or handling repetitive refactors can now happen in minutes instead of hours. The productivity gain is real and that part is easy to notice. What becomes interesting after using these tools for a while is that a different bottleneck starts appearing. Code generation becomes faster, but the review process often stays the same. Teams can generate hundreds of lines of code within minutes, but someone still has to answer important questions: Does this actually solve the requirement? Are edge cases covered? Will this introduce side effects? Does it align with existing patterns? The speed of writing code has changed. The need for confidence has not. That is where I think the conversation around AI-assisted development is starting to shift. The challenge is becoming less about generating code and more about making sure the generated code is actually safe to ship. The Problem With Reviewing AI-Generated Code Like Regular Code Imagine asking an AI coding assistant to implement coupon validation for premium users. Add coupon validation for premium users and create tests A few seconds later you get: if ( user . isPremium ){ applyCoupon (); } Nothing immediately looks wrong. The code is clean, there are no syntax issues, tests may pass, and the implementation appears complete. But pull request reviews usually go beyond reading diffs. Reviewers start asking questions such as: What happens if the coupon has expired? Does this affect payment calculations? Should audit logs be updated? Are there services depending on this behavior? This is where AI-generated code becomes interesting. It can often be functionally correct while still missing important implementation details. Research around larger AI-generated projects has also shown that functional correctness does not necessarily translate into maintainable system design. Teams stil

Everyone hits the same wall with Claude Code. You add a rule to CLAUDE.md . It works. You add ten more. They mostly work. You add forty more — and now Claude is cheerfully ignoring the rule you care about most, the one that's been sitting there since day one. So you make it LOUDER , in caps, with three exclamation points. It still gets skipped. The instinct is to write more. The fix is almost always to write less . Here's why, and what to do instead. Instruction-following has a budget, and you're overdrawn This is the part most CLAUDE.md guides skip. Frontier models reliably follow on the order of 150–200 instructions at once — and adherence to any single rule drops as you stack more on top of it. It isn't a cliff; it's a slow tax. Every line you add makes every other line a little less likely to be honored. Now subtract what you don't control: Claude Code's own system prompt already spends a chunk of that budget before your file is even read. So the working budget for your project rules is smaller than the headline number — and a sprawling 300-line CLAUDE.md isn't 300 rules followed, it's maybe the first 150 followed well and the rest treated as ambience. The mental model that fixes everything downstream: CLAUDE.md is a budget, not a wishlist. You are not writing documentation. You are spending a scarce attention allowance, and every line competes with every other line. The test for every line: would you bet $5 it's followed? Go through your file line by line and ask one question of each rule: would I bet money this fires every time it's relevant? Three outcomes: Yes, and it's load-bearing — keep it. This is what the budget is for. Nice to have, but I wouldn't bet on it — cut it, or move it to a referenced file (below). It's diluting the rules you would bet on. It absolutely must happen every time — then it doesn't belong in CLAUDE.md at all. Make it a hook. That third category is the one people get wrong, so let's be concrete about it. Advisory vs. deterministic:

I've been building agent workflows for a while, and one capability keeps coming up that the ecosystem hasn't fully reckoned with: letting an AI agent publish a document to the public internet and hand someone a link. It sounds trivial ("save HTML, return a URL"). It isn't. The moment an autonomous agent can mint a public link, you've handed it a primitive that touches access control, data exposure, and reputation. This post is about the design questions that surface once you take that seriously, written by someone who builds in this space. Disclosure up front: I work on Thryvate, a document-sharing tool with an MCP server. More on that at the end, but the problems below are general. The naive version The first version everyone writes is a tool that takes content and dumps it to object storage behind a public CDN URL: publish(html) -> https://cdn.example.com/a8f3c2.html Ship that and an agent can now share its work. It can also now: expose a half-finished draft to anyone who guesses the URL, leave that URL live forever with no way to pull it back, publish something containing a customer's name with zero record of who saw it. For a human hitting "publish" deliberately, those are acceptable defaults. For an agent doing it as one step in a longer plan, they're landmines. What "publish" should actually mean for an agent A few properties turn the naive primitive into something you'd trust an agent to call: 1. Default to private, opt into public. The safe default for an agent-minted link is not "world-readable." It's "only people on this list" or "only people with the password." Public should be an explicit parameter someone has to set, not the fallback. 2. Revocability. Anything an agent publishes, you must be able to un-publish instantly. A live link is a liability with a half-life, and the ability to revoke is what makes it safe to let the agent create them liberally. 3. Expiry as a first-class field. "This link dies in 7 days" should be a parameter on the publish call,

Imagine this - you rely on data that you download every day from some system to your own. That requires a trip to the server asking for information, and then a trip back with the payload we requested. This seems pretty fast since the internet is fast. But we also know the programming concept DRY (Don't Repeat Yourself). So, can we apply this principle to how we handle the scenario described above, creating something like DRD (Don't Repeat Data)? Well, yes. There is something to handle this, and it's called — Zero Copy . What is Zero Copy? As the name suggests, you are copying zero data, and yet, you are getting it on your system. How is this possible? If you think about it, you'll probably come to the conclusion that we are just opening a window. The data is just out there to be looked at by those who are allowed to. There's no need to bring the same data to different people's windows; we're just keeping the data in one place and making it available to anyone who needs it. What does this mean for ServiceNow? When it comes to Operations Management—dealing with data fetched from different databases (like monitoring data from Datadog or Dynatrace, ERP data from SAP or Workday, or cloud platforms like Snowflake, AWS, or Azure)—copying that data has traditionally been a hassle. We were reliant on sometimes complex ETL (Extract, Transform, Load) pipelines or massive data extracts. This complicated the whole process, consumed a lot of time, and required careful checking of data pre- and post-migration. So how exactly does Zero Copy help us here? Virtual Data Fabric Tables. Instead of copying data extracted from other tools, ServiceNow queries the exact data that is requested. It temporarily holds that data in memory for the user to interact with. During that time, the user can leverage that data for various use cases as required—and once they are done, it's gone. So, what exactly are the benefits of Zero Copy?! No need for data duplication on the destination. No need for d

One of the hardest things about going freelance as a developer isn't writing code — it's knowing what to charge. Charge too little and you're basically doing a salaried job without the benefits. Charge too much without backing it up and you scare off clients. Most developers I've spoken to either guessed their rate or copied someone else's. Neither is a great strategy. In this article I want to walk you through exactly how to calculate your freelance day rate properly — based on real numbers, not gut feeling. Why Most Freelancers Get Their Rate Wrong The most common mistake is this: taking your old salary and dividing it by 260 working days. That ignores: Taxes (you now pay both sides of self-employment tax in the US) Unpaid days — holidays, sick days, slow months with no clients Business costs — software, hardware, insurance, accountant fees No employer pension or benefits — you fund all of this yourself If you were earning $80,000 as a salaried developer and you divide that by 260, you get roughly $307/day. But that's actually a pay cut once you factor everything in. The Right Formula Here's the framework: Step 1 — Work out your actual billable days A year has 260 working days. Subtract: Public holidays (~10 days in the US) Your own holiday allowance (~15 days) Estimated sick days (~5 days) Non-billable time: admin, chasing invoices, marketing yourself (~20 days) That leaves roughly 210 billable days. Step 2 — Calculate your real income target Take what you want to take home and gross it up for tax. If you want $70,000 net and your effective tax rate is around 30%, your gross target is roughly $100,000. Step 3 — Add your business costs Software subscriptions, hardware depreciation, liability insurance, accountant — easily $5,000–$10,000/year for a freelance developer. Step 4 — Divide by billable days $110,000 ÷ 210 = $524/day That's your minimum. Price below that and you're losing money compared to employment. A Faster Way — Use a Free Calculator If that maths mad

A few years back I was a junior dev on a car financing product, and I got handed the deal jacket. A deal jacket is the full picture of a deal. How much the buyer puts down, what the car is worth, the terms, all of it packaged up and sent to a bank so the bank can come back with a yes or a no. The flow I had to build would send that package to one bank, wait about a minute for an answer, check whether the offer that came back was any good, and if it wasn't, send the whole thing to the next bank. A pipeline. Under the hood it was a recursive call with state managed in between, talking to Route One on the other side. It kept breaking. I wrote it, tested it, read the logs, fixed one thing, watched it break somewhere else. Day three, day four, still broken. Then on the fourth day I hit send in Postman one more time, watched the logs roll past, and it just worked. The approval came back clean. I jumped out of my chair. I was loud enough that the whole room looked over, and the two guys who knew what I'd been stuck on for four days were already grinning, because they knew exactly what had just happened. That feeling is the whole reason I'm writing this. Not the code. The feeling. The joy had two parts, and I only saw the second one once it was gone The first part is obvious. It's the problem solving. The thing fought back for four days and then it didn't, and I had beaten it. You chase a bug through the logs, you argue with it, and at some point it gives. That is a real high and every engineer knows it. The second part is quieter. I built that. Me. Back then if I shipped something, even a plain HTML page, it was mine end to end. I had to learn HTML before I could build the page, so the page was proof that I had learned. You could point at the thing and say that came out of my head and my hands, and nobody could take that from you. So the joy was solving the problem, and it was owning what you solved. That second part is the one that broke. Same problem, four years apart Ta

Habit stacking is one of my goals this year. I've been so focused on improving my software...