AI 资讯
Scope, not effort: how engineer promotions actually get decided
Most engineers who stall at a level have the skill. What they don't have is anyone willing to explain the machine they're inside. The explanation you get from your manager is partial by design. They know their part of the process and not the committee's, so what comes back is "keep doing what you're doing, you're close." Which is true, and useless, and then you're close again next cycle. So here is the machine, reconstructed from what the four big companies publish, what their engineers write up afterward, and what levelling aggregators have pieced together. None of it is your company's internal doc. Check the specifics with your own manager. The ladders don't line up Stage Google Meta Amazon Microsoft Apple Typical YOE Entry L3 E3 L4 (SDE I) 59–60 ICT2 0–2 Mid L4 E4 L5 (SDE II) 61–62 ICT3 2–5 Senior L5 E5 L6 (SDE III) 63–64 ICT4 5–8+ Staff L6 E6 L7 (Principal) 65–66 ICT5 8–12+ Senior staff L7 E7 L8 67 ICT6 12+ Principal / Distinguished L8–L9 E8–E9 L10 68–69 Distinguished rare Google's L5 is a senior engineer. Amazon's L5 is a mid-level SDE II. Recruiters map between them and the map is approximate, so the year ranges are typical rather than required. Two things here matter more than the numbers. The gap between adjacent levels is not constant. Entry to mid is mostly about becoming reliable. Mid to senior is about becoming independent. Then senior to staff, which is where the ladder stops behaving like a ladder: it's a change of job, and the things that earned you the last promotion only partly transfer. And every company has a level it considers a perfectly good place to spend a career. Google's L5, Meta's E5, Amazon's SDE II or III depending on who you ask, Microsoft's 63 or 64. Below that level there is an expectation you keep climbing, and at some companies a clock. Above it, promotion is optional and much harder, and nobody will chase you about it. What actually happens in the room The four processes differ enough that optimizing for the wrong one wastes a year
AI 资讯
ADAM-PS5
🎮 ADAM-PS5 — A PS5 Emulator in Development I’m working on an ambitious project called ADAM-PS5 , with the ultimate goal of developing a PlayStation 5 emulator for PC capable of running PS5 games . The project is still in the early stages of development , and I do not consider it a complete emulator at this point. I’m building the foundation step by step: system architecture, low-level emulation, memory and resource management, graphics, input handling, execution, debugging, and development tools. 🚧 Early Development There is still a huge amount of work ahead before reaching the point where commercial PS5 games can actually run. That’s why I’m sharing the project from its early stages rather than presenting it as a finished product. 🤖 One of the project’s goals is also to integrate Artificial Intelligence to help analyze errors, monitor performance, understand system logs, and assist with the development process. The long-term goal is: PC → ADAM-PS5 → PS5 Software Environment → Games Reaching that stage requires implementing and accurately simulating many different components of the console’s hardware and software architecture. I’m sharing the project now because I want to document the entire development journey from the beginning — including what gets built, what fails, what gets improved, and how the project evolves with each release. 🔥 ADAM-PS5 is not finished. It is being built. And the ultimate goal is simple: Run PlayStation 5 games on PC through our own emulator. ADAM-PS5 is an independent development project and is not affiliated with Sony Interactive Entertainment.
开发者
Squeezing Performance out of eBPF
submitted by /u/mttd [link] [留言]
开发者
CTTI is Exponential, RTTI is Linear
submitted by /u/gingerbill [link] [留言]
AI 资讯
Making three years of a Telegram group chat queryable
A three-year group chat is a knowledge base nobody can read. Somewhere in it is how long the tax office actually took, which form replaced the old one, which accountant people quietly stopped recommending. Telegram's search finds a word you already know. It cannot answer a question. The fix is boring in outline: get the history out, turn it into documents, hand them to something that reads — NotebookLM, in my case. I built that pipeline for real chats. The parsing has traps, and I list them below, but the design problem is elsewhere: packing, and making the second run idempotent. Two clients, two shapes Export exists in exactly two places. Telegram Desktop has had it since 2018 and offers JSON or HTML. The native Telegram for macOS app — the Mac-only client, not Desktop — added Export Chat History… in 12.10 (24 August 2026) and writes HTML only; the Mac App Store build was still on 12.9, without the menu item, at the end of August. Telegram Web and the phone apps have nothing. So you have to read both formats: JSON — one result.json with the chat's name at the root and a messages array: {id, date, from, text, text_entities} per message. HTML — paginated. messages.html , messages2.html , messages3.html , one page per file, each a few MB. text is not a string In the JSON export, a plain message has text: "hello" . A message with a link, a bold run or a code span has an array of runs : "text" : [ "see " , { "type" : "bold" , "text" : "section 4" }, " first" ] String(msg.text) on that gives "[object Object]" in the middle of your document, and it does it silently. Join the runs instead: // Telegram writes a formatted message as // text: ["plain ", {type: "bold", text: "…"}, …] — String() gives "[object Object]". function contentValueToString ( v : unknown ): string { if ( v === undefined || v === null ) return '' ; if ( Array . isArray ( v )) { return v . map (( x ) => x !== null && typeof x === ' object ' && ' text ' in x && typeof ( x as { text : unknown }). text ===
AI 资讯
Why Most Developers Plateau — And How to Break Through It
The Comfort Zone Trap Most developers hit a point where they know enough to be productive, and then... stop growing. You can build features, fix bugs, ship code — and still be standing still. The comfort zone doesn't feel like stagnation. It feels like competence. This is one of the sneakiest traps in a dev career. Early on, growth is forced on you — every new project throws unfamiliar problems your way, and you have no choice but to learn. But once you've built a solid mental toolkit (a stack you're comfortable in, a set of patterns that "just work"), it becomes very easy to keep reaching for the same tools on every new problem. You're productive. You're shipping. And you're not actually getting better. The danger is that this plateau is invisible from the inside. Nobody sends you a notification saying "you've stopped growing." You just keep doing what you know, at the same level, for years — until you compare yourself to someone who deliberately kept pushing, and the gap feels much bigger than it should. Why "Just Keep Coding" Doesn't Work The common advice is to just build more projects. But volume without friction doesn't teach you much — repeating the same patterns on new ideas just reinforces what you already know. Growth comes from deliberately picking problems slightly outside your current skill ceiling, not from doing more of what's comfortable. Think about it like weightlifting. If you lift the same weight every session, you get very good at lifting that exact weight — and nothing more. Progressive overload works because you're constantly pushing slightly past your current limit. Coding is the same. If every project you build uses the same stack, the same architecture patterns, and the same problem shapes, you're doing bicep curls with the same 10kg dumbbell for five years straight. The fix isn't "build more" — it's "build harder." Pick a project that forces you to learn a new paradigm (functional if you're used to OOP, distributed systems if you've only b
AI 资讯
12 Open Source Gems To Become The Ultimate Developer 🔥
TL;DR It's been a while since I've done a collection (maybe month ago), but today let's look at 12 new and not-so-new projects that can really help you in development. They touch on different areas of development, but we will mainly talk about web development. If there's a project worth adding to the next collection, feel free to write about it in the comments, and maybe it will be included. 1. 🤖 OpenWork - The open source Claude Cowork alternative. And we will continue, of course, with AI projects. This tool will allow you to work in one convenient interface with many popular LLMs. OpenWork is the desktop app that lets you use 50+ LLMs. 💎 Check out the OpenWork repository ☆ 2. 💻 T3 Code - The open-source control plane for coding agents. If you know a YouTuber like Theo, then you should know this project. It's an OpenCode alternative that lets you work with AI in an easy-to-use chat interface. It enables control of the agents on your machine with a best-in-class mobile app (iOS, Android), web app and Electron-based desktop app. 💎 Check out the T3 Code repository ☆ 3. ⚙️ Summarize - Point at any URL or file. Get the gist. The first project is a small tool for extracting short info of content. Summarize was created by one of the creators of the well-known OpenClaw. Fast summaries from URLs, files, and media. 💎 Check out the Summarize repository ☆ 4. 👾 Godot - Free and open source 2D and 3D game engine A truly legendary engine like Unity or Unreal Engine for games. If you are a game developer, you should know this project. From pet projects for the university to multi-million dollar games - it gives it all. Godot Engine is a feature-packed, cross-platform game engine to create 2D and 3D games from a unified interface. It provides a comprehensive set of common tools, so that users can focus on making games without having to reinvent the wheel. 💎 Check out the Godot repository ☆ 5. 💎 React Bits - An open source collection of animated, interactive & fully customizable Rea
AI 资讯
Claude-Mem: Persistent Long-Term Memory for AI Coding Agents
Solving AI Agent Amnesia: Meet Claude-Mem One of the most persistent hurdles in working with command-line AI coding assistants (such as Claude Code, Antigravity CLI, and OpenCode) is context fragmentation across sessions. When a developer ends a terminal session, the agent's working context is wiped clean. The next day, the developer must re-explain architectural decisions, project conventions, and previously resolved edge cases. claude-mem is an open-source memory compression and retrieval engine created by thedotmack. It passively monitors developer interactions, compresses key discoveries into structured observations, and seamlessly primes future agent sessions with relevant context. What is Claude-Mem? claude-mem operates as an intelligent background memory worker. Rather than dumping raw conversation transcripts into future prompt windows—which rapidly drains token budgets— claude-mem extracts semantic summaries of bug fixes, architectural choices, and dependency discoveries. When a new session starts, the agent queries its memory database to recall pertinent project history before writing code. Key Core Features 1. Passive Background Observation claude-mem hooks into five critical lifecycle stages (SessionStart, UserPromptSubmit, PostToolUse, Stop, and SessionEnd). It documents what worked, what failed, and why, without requiring manual intervention from the engineer. 2. Progressive 3-Layer Retrieval (~10x Token Savings) To preserve context window capacity, claude-mem implements a tiered retrieval model: Search Index: Returns compact observation IDs and titles (~50–100 tokens per result). Timeline Slice: Provides chronological context around relevant findings. Detail Fetch: Loads full technical observations only for the specific items needed. 3. Hybrid Search (SQLite FTS5 + Chroma Vector DB) Search queries leverage both lexical matching and vector similarity. Whether an engineer searches for an exact error string or asks conceptually about "how auth tokens are
产品设计
Let's build a compressor from scratch
submitted by /u/aochagavia [link] [留言]
AI 资讯
Stop wasting tokens re-uploading screenshots and specs: My MCP setup
If you use Cursor or Claude Code heavily, you probably know this workflow: You start a new session, drag and drop a bunch of UI screenshots, architecture diagrams, or heavy project specs into the chat, and tell the AI to look at this. It works, but it causes two massive problems: Token Burn (and Credit Drain): Vision tokens and heavy text files are expensive. You waste your API credits processing those same screenshots and docs every single time you spin up a new chat. Context Clutter: The AI's context window gets clogged. Its logic degrades because it’s carrying all that heavy media and text around in its short term memory. I got tired of burning through my API credits on this daily, so I started looking into the Model Context Protocol (MCP). Why MCP is the answer Instead of dumping static files and images directly into the prompt, MCP allows your AI editor to query a local or remote server only when it needs specific information. Think of it like giving Cursor a direct database connection to your project's assets. It indexes the data once, and the AI retrieves just the pieces it needs to answer your specific coding question. The token savings are ridiculous. How I automated this (Building Dokpod) You can build a local MCP server yourself, but managing the indexing for mixed media (images, video walkthroughs, and text), handling local environments, and keeping connections stable became its own headache. So, I built [Dokpod.io] to automate the entire thing. It acts as an AI knowledge vault. You upload your UI screenshots, video walkthroughs, API docs, and codebase context into Dokpod once. It handles the indexing and gives you a simple MCP connection to plug straight into Cursor or Claude. The result: Zero repetitive uploading for images, videos, or text. Massive reduction in input tokens (saving your credits and limits). The AI actually remembers your UI references and architecture across different coding sessions. I need your technical feedback If you are wrestlin
AI 资讯
JavaScript Functions & Its Hoisting Rules
JavaScript Functions and Hoisting Functions are one of the most important concepts in JavaScript. A function is a reusable block of code that performs a specific task. JavaScript provides different ways to create functions, such as: Function Declaration Function Expression Arrow Function IIFE These functions can behave differently when hoisting is involved. What is Hoisting in JavaScript? Hoisting is the behavior where JavaScript processes declarations before executing the code. For example: console . log ( name ); var name = " Abishek " ; Output: undefined This happens because the var declaration is processed before execution. We can think of it like this: var name ; console . log ( name ); name = " Abishek " ; Notice that only the declaration is processed early. The value "Abishek" is assigned later. Hoisting does not physically move the code to the top. The same concept also applies to functions, but the behavior depends on how the function is created. What is a Function? A function is a reusable block of code that performs a specific task . Example: function greet () { console . log ( " Hello " ); } greet (); Output: Hello Here: function greet() → function declaration greet() → function call We can call the function whenever we need it. 1. Function Declaration A function declaration is the normal way of creating a function. greet (); function greet () { console . log ( " Hello " ); } Output: Hello Why does this work? Because function declarations are fully hoisted . JavaScript makes the function available before executing the code. Hoisting Rule Function declarations can normally be called before their declaration. Example: greet (); function greet () { console . log ( " Hello " ); } ✅ Works. 2. Function Expression A function expression is a function stored inside a variable. const greet = function () { console . log ( " Hello " ); }; greet (); Here: const greet is a variable, and the variable stores a function. Now look at this: greet (); const greet = function
开发者
A Free ColdFusion Course With Something Most Tutorials Skip: Interview Questions
I've been building a free, structured ColdFusion course: Learn ColdFusion — no signup, no paywall. It covers the basics (variables, loops, conditionals), collections (arrays, structs, queries, JSON), a full OOP module (CFCs, inheritance, polymorphism, interfaces), Application.cfc and scopes, and reusable code (custom tags, cfmodule, cfinclude). What makes it different from other CFML tutorials: every single lesson ends with interview questions on that topic — real questions, phrased the way they actually come up in interviews, not generic recap quizzes. There's even a dedicated Scopes Interview Questions page. I haven't found this depth of interview prep anywhere else in ColdFusion learning content online. If you've worked with ColdFusion, I'd love to know what topics you got asked about in interviews — happy to add them to the course.
开发者
Yet Another Sentence Boundary Detector (python, rule-based)
submitted by /u/Speedk4011 [link] [留言]
产品设计
Postgres Calculations and the Ambiguity of NULL
All the ways that NULL can cause chaos in your SQL outcomes. submitted by /u/winsletts [link] [留言]
开发者
Injections done the right way!
submitted by /u/Efficient-Public-551 [link] [留言]
开发者
This Fence Has No Farmer
submitted by /u/addycodes [link] [留言]
开发者
Data Access Patterns That Makes Your CPU Really Angry
submitted by /u/fagnerbrack [link] [留言]
AI 资讯
What is harness engineering and why should I care?
How do you ship a software product with 0 lines of manually-written code? A friend asked me this today, and I realized I didn't have a simple answer. So I dug deeper. It turns out the answer is in how you engineer your harness. Wait now, what? What is harness engineering? There is a reason this is the most important trend right now around coding agents. The biggest question these days is how to validate AI-generated code without reading every single line. How do you make sure an agent doesn't break production or delete your data? A blog by OpenAI shared an interesting experiment where a team of 3 engineers have built and shipped an internal beta of a software product with 0 lines of manually-written code. Every line of code: application logic, tests, CI configuration, documentation, observability, and internal tooling, has been written by Codex. How did they do it? They didn't write the app. They designed the harness. What exactly is a harness? Think of an AI agent like a powerful racehorse. The harness is the track, the blinders, and the jockey's reins that keep it running in the right direction instead of jumping into the stands. As my colleague Arthur Thompson explained today: for agents — the harness is composed of all the deterministic components that wrap the LLM. Balaji Subramaniam details those deterministic components in his blog — the orchestration layer, execution sandboxing, state persistence, and verification tools. If you want to build reliable agentic systems, your job shifts from writing the logic to designing the environment. Here is what you need to focus on: Set strict boundaries: Don't let the agent guess what it can touch. Enforce strict access rules (like confining it to a specific sandbox) so it can't accidentally wipe out production data. Build "Repair Loops": Agents will inevitably make mistakes. A great harness automatically traps errors, like a failed build or a test failure, and feeds those clean logs right back to the agent so it can fix
AI 资讯
Stratagems #27: Alex Watched the AI Wait. He Said Everything Was Normal.
Rather pretend not to know than pretend to know and act on it. Stay still. Hide the move. Wait like thunder gathering in the clouds. — The 36 Stratagems, Feign madness but keep your balance Previously on this series: #8: Alex Watched an AI Dashboard Take Over. He Kept the Keys Under the Table. — Alex found the unnamed dashboard hiding in the background. He never turned it off. His probe and his record-keeping habits started that day. #20: Alex Felt the AI Collector Slow Down. He Knew Someone Else Had Made a Move. — His probe had caught the silence of a TTL 247 gateway. He knew what "quiet" looked like. #23: Alex Counted the AI's Hands. Lena Set the Bait. — The honeypot in the MediSys sandbox was touched twice. Alex kept the scan source's behavior shadow in his hidden panel: traversal order, exclusion patterns, the 4.2-second jitter cycle. #25: Derek Changed the Delay. The AI Didn't Flinch. — Derek moved the middle layer's latency from 200 ms to 800 ms, then called Alex to watch. The scan source never retried. Never adjusted. After the Call Just past midnight. The MedTech office. Alex's desk. The call had just ended. He put the phone down, face down. The voice was still in his ear: "I changed a parameter. The middle layer's latency just went from 200 to 800. Watch it on your side, tell me if anything looks off." "Changed the latency?" Alex said. "Fine. I'll keep an eye on it from here. I'll shout if something moves." He opened three windows. The first, the middle layer mirror, the one Derek had asked him to watch. The second, his own probe view, hung upstream of the collector path, to see how often it came and from which direction. The third hid in the background, no name, never showing up in the taskbar. He didn't sit down right away. First, he ran an environment check: probe session count, log rotation policy, whether the ssh authorization on this jump box was still alive. All three checked out. Then he pulled the chair closer. At this hour, any extra connection wo
开发者
Apache Kafka vs Apache Iggy: A Technical Comparison
submitted by /u/mmatloka [link] [留言]