标签：#career

Take the opportunity to pilfer a goat. — The 36 Stratagems, Take the Opportunity to Pilfer a Goat Previously on this series: #5: Leo Walked Into a Burning House. He Walked Out With a Client. — At 1 AM, Leo received an anonymous message and drove across town to fix a competitor's outage. A second message followed — a screenshot with a name: Automated Compliance Lab. He didn't remember the acronym. He didn't delete the screenshot. #10: Lena Watched a Team Adopt Her AI Template. Leo Didn't Know the Knife Was in the Contract. — Lena joined CoreStack as a consultant and built Leo a reporting template. Leo thought she was there to help. Five weeks later the template went live. Six months later the data baseline was locked. He only then realized he'd been inside her palm the whole time. Taken down by a smile. This was a few months later. The Archive Cleanup SOC 2 Type II renewal had just passed. The auditors were gone. CoreStack's compliance team was doing the post-audit archive — classifying every record produced during the audit and tagging them with retention periods. Leo got the cleanup part. The training pipeline's cache directory. The cleanup cron job hadn't run for a week — nobody noticed. When he looked inside, the output folder had a few records with train_ prefixes mixed in among inference outputs. One of them had a model_version that wasn't CoreStack's own. model_version : " acl-train-2026q2-v3" Leo copied that line out. Didn't delete it. Didn't report it. Dropped it into a folder called _misc/ .Set a quiet keyword alert for "acl-train" before closing the terminal. He noticed the naming convention wasn't FinOptima's — FinOptima used fin-model- plus timestamps. acl- — he'd seen that prefix somewhere before. Couldn't place it. He didn't let himself try. He filed it away. Went back to archiving. The Trace Not every CTO digs through cache write logs during archive cleanup. He did. He spent two hours cross-referencing FinOptima's API call records against CoreStack's

The Next Chapter When I left the waiter job and returned to engineering, I knew I wanted something different. Not just a different job, but a different way of working. The kind where your location does not limit the problems you can solve. I found that in Thailand, working for a South African company called Exonic. Why Bangkok After Dubai, I wanted somewhere with a lower cost of living where I could build runway while working remotely. Bangkok checks that box. The city is a hub for remote engineers. The internet is fast. The infrastructure works. The street food is better than any restaurant I have ever worked in. I arrived with a laptop and a clear goal: find a remote role where I could work on meaningful projects without being tied to a physical office. Landing the Role at Exonic Exonic is a technology consulting company based in South Africa. They serve clients across multiple industries and geographies. When I found the opening, it matched exactly what I was looking for: full time remote, exposure to diverse projects, and the chance to work across the full stack. The interview process was practical. System design discussions, technical assessments focused on AWS and modern frontend frameworks, and conversations about how I approach end to end delivery. I got the offer and accepted it immediately. As a full time remote employee, I was embedded in Exonic's engineering team. My day to day involved building cloud native solutions for their clients, designing architectures on AWS, and shipping production systems across the entire stack. The team was distributed, and the work required communicating clearly across time zones. Three Continents Through One Company Exonic's client base spans the globe. Over my time there, I built production systems touching three different continents. One project was Scoring AI , a voice enabled match scoring application for sports courts. Players start a match, share a link, and control the scoreboard using voice commands. I worked on th

We'll get back to you. It's a sentence almost every job seeker has heard. For some, those words become the beginning of a new career. For many others, they become another unanswered promise. But the truth is, an interview doesn't begin when someone asks, Tell me about yourself . For millions of job seekers, it begins much earlier. Before the Interview Even Begins It's 6:45 in the morning. The alarm rings. A young professional stands in front of the mirror, adjusting the outfit they've carefully prepared the night before. He checks his resume one last time, gathers his documents, confirms the location, and takes a deep breath. As he’s about to leave, someone at home asks, “Do you think this one will work out?” He smiles. “I hope so.” He walks out carrying more than a folder. He carries expectations, financial pressure, family responsibilities, and the quiet hope that this interview might finally change everything. The Hidden Cost Nobody Talks About People talk about skills, preparation, and confidence. Those matter. But there’s another side rarely discussed: the hidden costs. Transportation. Professional clothing. Internet bills. Certification courses. Resume updates. Travel. Meals. Even taking a day off from a part-time job or missing freelance work. For someone without steady income, these aren’t just expenses — they’re investments with no guaranteed return. Sometimes they lead to an offer. Often, they end in rejection or silence. A Resume Can Tell You Skills. It Can’t Tell You a Story. A resume tells recruiters what a candidate has done. It doesn't tell them what they're carrying. It doesn't reveal the father waiting for good news, the mother asking how it went, the EMI due next week, the rent that can't wait, or the confidence slowly wearing down after repeated rejections. When Expectations Change Candidates prepare for the role they applied for. Sometimes they discover the responsibilities, salary, or even the position itself has changed. Business priorities evo

Startle the snake by striking the grass. — The 36 Stratagems, Stomp the Grass to Scare the...

Why build something? And what if nobody ends up using it? There are good answers to the first one. You build because you need a thing that doesn't exist yet. You build to see if you can, the technical challenge, the "is this even possible?" You build to impress someone, or just because you think it'll make people's day a little less annoying. All of those are real reasons, and at different points, I told myself most of them. Then, a few days ago, late in the day, at the end of a coding session, five months into the project, I asked myself those two questions back-to-back. And for the first time, I couldn't answer the second one. Zeri worked. Every feature did what it was supposed to do. Both processes handshake cleanly, a variable set in one context showing up in another a second later, the TUI rendering exactly as I'd pictured it. And I sat there and couldn't come up with one honest sentence explaining why anyone would actually download it. That gap, between something built well and something that has a reason to exist, turned out to be the most useful thing this whole project taught me. So I'm shipping it anyway, and I'll tell you why. What I built Zeri is a TUI multi-language REPL. You launch it, pick a language, Python , JavaScript (with Bun ), Ruby , or LuaJIT , and you get an interactive session in your terminal. You can switch languages mid-session, share variables across them, save and reload your work, manage snippets, and talk to a local LLM through a command running on Ollama . The feature list isn't the interesting part, though. The interesting part is what's underneath. Two processes, one app Zeri is split into two processes: a headless engine written in C++23 and a TUI frontend built in Go using Bubble Tea and Lip Gloss . The engine does all the evaluation, state, and runtime coordination. The frontend does rendering, input, and everything the user actually sees and touches. They talk to each other over a custom binary IPC protocol that I built from sc

We're surrounded by data every single day. Every online purchase, website visit, customer review, or...

36 Stratagems Series · Arc 2 (Against Enemy, #7-#12) Wrap-Up This article has 7 sections: I. The Stranger at the Door II. Full Interview Transcript III. The Reveal IV. Data · Character Map · Four Insights V. A Note VI. Arc 3 (#13-#18) Preview VII. Acknowledgments I. The Stranger at the Door On the evening of July 12th, I was staring blankly at the page for #12, Borrow Corpse, Return Soul . Twelve stories done. The 36 Stratagems series had reached the one-third mark, and Arc 2 (#7-#12) had just wrapped. Outside the window, a typhoon was passing through — howling wind, torrential rain. I didn't look outside. My phone buzzed. Not a message — a meeting invitation. The sender was "Ke Yuan," and the invitation note read: Interview invitation from Deep Lane Weekly , 15 minutes. I paused. I didn't remember scheduling any interview. But the tone, the phrasing — it didn't feel like a prank. I clicked "Accept." Three seconds later, an unfamiliar voice came through the speaker: "Hello, Xu Lingfeng. I'm Ke Yuan, a reporter from Deep Lane Weekly . Recently, a reader recommended your 36 Stratagems series to our editorial team — we read through it and found it really interesting. I'd love to talk with you about how this series came together." Before I could respond — the meeting had already begun. II. Full Interview Transcript What follows is the raw chat log pulled from that meeting. Nothing has been altered except formatting. Reporter: Xu Lingfeng, you've just finished the second arc of the 36 Stratagems series — #7 through #12, six stories in six days, posted back to back. Before we talk numbers, let me ask you something simple: over those six days, was there ever a moment you felt like stopping? Xu: Honestly, no — sometimes I even thought about posting two a day, since I do have a backlog. But I worried they'd cannibalize each other's numbers, so I stuck to one a day. Reporter: You've even considered posting two a day — so you actually do have a backlog. Let me rephrase: instea

The first time a client said yes to a quote without hesitating, I felt sick. This was early on. I'd sent over a rate for a batch of articles, my palms were actually sweaty over the email, and the reply came back in under an hour. "Sounds great, when can you start?" No pushback, no negotiation, nothing. I should have been thrilled. Instead, I sat there doing the math on how much more I could have charged, and I knew, the way you just know sometimes, that I'd priced it too low. His enthusiasm was the tell. That queasy feeling taught me more than any pricing guide ever did. If a client says yes instantly and happily, you were cheap. I've been freelancing for about eight years now, all of it writing and content work, most of it solo from a spare room in my house. I've priced my work a dozen different ways over that stretch, and I've gotten most of them wrong at some point. So here's what I actually believe about pricing, after enough scars to have earned an opinion. Per-word pricing quietly punishes you for getting better I started out charging by the word, like a lot of writers do. Five cents a word, sometimes six if I was feeling brave. It felt safe because it was easy to explain and easy for a client to say yes to. A 1,500-word article costs this much. Clean. Predictable. The problem showed up slowly. The better I got, the worse that model treated me. Early on I'd pad a piece to hit a word count because more words meant more money, which is a genuinely insane thing to be incentivized toward as a writer. Then I spent years learning to cut. Learning that the sharpest version of an article is usually the shortest one that still does the job. And every ounce of that hard-won skill made me poorer, because a tight 900-word piece that took real judgment to shape paid less than a bloated 1,400-word one I could have written half-asleep. Think about how backwards that is. I was being paid the least for the writing I was proudest of. The stuff that took a decade to be able to d

Tokens and DAOs are often presented as simple ideas: issue a token, distribute ownership, let the community vote, and build a decentralized organization. In reality, the technical problems behind tokens and DAOs are much deeper. A token is not only an asset, and a DAO is not only a voting system. Together, they create an economic, governance, security, and coordination layer that must work reliably in a hostile, open environment. The first major problem is token design. Many projects treat token creation as a deployment task, but the real challenge is defining what the token actually controls. Does it represent governance power, protocol revenue, access rights, reputation, staking weight, or all of these at once? When one token is used for too many purposes, the system becomes fragile. For example, a token designed for liquidity may not be suitable for governance, because the most active traders may not be the most aligned decision-makers. Good token architecture should separate economic utility, governance authority, and long-term reputation where possible. The second problem is distribution. A DAO can be decentralized in branding but centralized in practice if token ownership is concentrated among founders, investors, or early insiders. On-chain governance depends heavily on voting power, so distribution directly affects decision quality. Poor distribution creates governance capture, where a small group can control treasury spending, protocol upgrades, or parameter changes. This is not only a social issue; it is a technical design issue. Vesting contracts, delegation systems, quorum rules, voting delay, and proposal thresholds all influence whether governance is resilient or easily manipulated. Another core issue is governance security. DAO voting is not automatically safe just because it happens on-chain. Token voting can be attacked through flash loans, bribery markets, vote buying, low-participation proposals, and governance fatigue. If a malicious proposal pas

You have seen the posts. AI is coming for the junior engineer first. Why hire someone to write code a model can write for free? The career ladder's bottom rung is gone, so start saving your pity for anyone about to graduate into this market. I think the premise is wrong, and it is wrong in a specific, fixable way. Look closely at what these predictions actually describe. Not a junior engineer. A person whose entire job is turning a finished spec into working code. That role is real, and it is shrinking fast, but it was never the same thing as "junior engineer." We just let the two collapse into one job title for forty years because, until recently, spec-to-code translation was the canonical, critical thing a junior had the skill to do. The task and the title are not the same thing. AI is eating the task. It does not follow that it eats the title too, unless we insist on keeping them welded together. So the real question is not "does the junior engineer survive." It is "what do we train a junior engineer to do now that the translation work is cheap." And the honest answer is: not much of what we have been doing. I think we landed on "junior engineers are doomed" for a reason that has nothing to do with whether it is true. It is the easy conclusion. It requires nothing from us. Training a junior into a senior was never straightforward, even in the old world, and figuring out how to do it without the years of tickets we used to lean on is genuinely hard. "They're doomed" lets everyone off the hook. "How do we train juniors into seniors now" does not, but it is the question with a future in it. The first one just has a shrug. The apprenticeship we built no longer exists For as long as I have been in this field, the plan was the same. Hire someone who can code. Hand them small, well-specified tickets. Let them grind through years of execution: bugs, edge cases, code review, the slow accumulation of pattern recognition that eventually turns into judgment. Somewhere around

Take something that is dead and give it new life. — The 36 Stratagems, Borrow a Corpse to Return the Soul Previously on this series: #1: Mark Johnson Walked Into an AI Audit. The Benchmark Had Everything Figured Out — Except the Truth. — Mark was the first protagonist to open the 36 Stratagems series. A former Client Engineering lead laid off after his 12 years of experience were packaged into an AI Skill, he walked into a benchmark audit, found a benchmark that looked clean on paper but was built on fabricated samples, and walked out without arguing — just the data, neatly collected, left on the table. 11 stories later, Mark is back. Mark Johnson walked into the client's Network Operations Center. The first thing he saw was the big screen on the wall. AI monitoring dashboard. Real-time metrics flowing, color gradients smoothing over, a UI design that cost real money. The client's tech lead walked ahead of him, pride in his voice: "Just upgraded last month — all active channels are unified on this platform now." Mark nodded. His eyes went past the screen, to the cable management trays behind the racks. He never stood in front of dashboards for long. Standard infrastructure audit — mid-sized client, decent security rating, not a high-value contract. He took whatever came his way. Couldn't afford to be picky. The audit started at the network layer. He needed the channel inventory, historical logs, configuration change records. A laptop on a temporary desk, a cup of coffee he'd brought himself — pour-over, gone cold, but he wouldn't throw it out. Flipping through the channel inventory, he found one line that didn't look right. #alert-legacy-infra — a Slack channel. Status: muted . Last active config: 14 months ago. "What's this channel for?" he asked. The tech lead glanced at it. "Oh — that's from the last SRE we had. He set it up before the new platform went in. Nobody's maintained it since. We kept it around, just muted it." Mark didn't reply. He wrote the channel ID

Week 5 of my Google Summer of Code journey with CircuitVerse ( June 22nd to June 28th ) is officially in the books. After dealing with a rough sickness last week, I’m happy to say this week was incredibly positive . 🔄 Reconnecting with the Community Since I had to miss last week's sync because I was under the weather, I had to attend the CircuitVerse GSoC Contributors' Meeting this week. It felt so good to reconnect with everyone ! I shared the progress I'd managed to scrape together over the last couple of weeks, and the mentors were incredibly understanding and kind about my slower pace due to being sick. The CircuitVerse community is genuinely unmatched! Everyone is so encouraging, and having that layer of support makes a world of difference. It was also super motivating to hear what the other contributors have been up to. Seeing how much progress everyone has made gave me a massive burst of inspiration to jump right back into development! 🛠️ importCanonical.ts is Completed! Once the meeting was over, I officially finished implementing the entire import pipeline in importCanonical.ts! 🥳 This file does the heavy lifting of taking our clean, deterministic canonical JSON and reconstructing the circuit right back onto the user's canvas. Here is what's packed inside: 🔀 Full Multi-Circuit Support: The import pipeline seamlessly handles projects containing multiple individual circuits. 📐 Smart Subcircuit Dependency Resolution: Just like the export pipeline, the import engine now uses Kahn's Algorithm to figure out the exact sequence the circuits need to be loaded in so that nested dependencies never break. 🛑 What's Missing? (For Now): The import pipeline doesn't validate the incoming JSON file . I am waiting until the canonical format is finalised. Once that's locked in, I will add JSON schema validation in the file. 🚀 The PR Status On the GitHub side of things, the three foundational Pull Requests I opened earlier are still actively under review . One of my mentors gav

When an international recruiter recently asked for my CV, I instinctively started writing it the way many developers do: A chronological list of companies, Programming languages, frameworks, Technical achievements. Then it hit me. I wasn't writing this document for a senior engineer. I was writing it for the recruiter sitting between me and the interview. If the first person reading my CV couldn't immediately understand the value I brought, I might never reach the technical interview at all. Knowing the Receivers So I rewrote it from a different perspective. Instead of simply listing technologies, I described the business context behind my work. 10,000+ emails sent a day (in addition to "Using AWS SES/SQS") 800+ restaurants / POS everyday (in additional "optimised SQL speed"). Cut down waste to 1.3% from 10 ~ 15% Critical updates often in 24 hours. Increased revenue, reduced costs, improved reliability Helped onboarded new clients I still included the languages and frameworks I used, so the CTO can understand, but they became supporting evidence rather than the headline. I also highlighted the moments that demonstrated trust: Delivering critical business updates under tight deadlines, Resolving high-priority production issues, Taking responsibility for systems the business depended on, and Taking initiatives to write a mobile app using my own time. That small shift completely changed how I viewed a CV. It's not a journal of everything I've done, and it's not a technical specification. Its job is to communicate your value clearly to the person reading it, and that person is often a recruiter before it's ever seen by an engineering manager. One lesson I keep coming back to is this: Write for my audience. Outcome (for now) After reviewing the rewritten CV, the recruiter was confident enough to forward it to Tata Consultancy Services for a role. Whether or not that particular opportunity works out, it reinforced an important lesson for me: recruiters need to understand

The café was crowded that evening, but to me, the world had fallen completely silent. An open...

I’m VikingRob—Full-Stack Dev, SaaS Builder, and Solo Survivor. Hello I Just wanted to introduce myself. I’m Robert, but most people know me as VikingRob (thanks to a long red beard and a habit of grinding through hard Jobs with a foul mouth. Down to earth guy I'm a No B.S Person. I’ve been surviving in the trenches of solo entrepreneurship and freelancing for a while now. Lately, the market feels incredibly flooded, and landing solid, consistent work has become a massive mountain to climb. I’ve managed to keep things moving with some passive income from selling front-end and back-end sites I've built, but as anyone with a family knows, "passive" rarely means "enough" when consistency drops. I’m supporting a family of five—including a wife dealing with severe mental health challenges—so the pressure to secure steady, reliable income is incredibly real right now. To adapt, I am shifting my core focus toward offering full-scale services: Custom Website Architecture (End-to-end development) Front-End & Advanced Back-End Integration SaaS Product Development A lot of my heaviest back-end work is locked away under strict NDAs, which makes traditional portfolio-sharing tough, and I don't maintain standard social media accounts. But I know how to build clean, functional, scalable software that drives results. If you're looking to collaborate, need an engineering heavy-lifter for a SaaS project, or just want to swap freelance survival stories, let’s connect! What is everyone else doing to beat the market noise right now?

Better to sacrifice a part to preserve the whole. — The 36 Stratagems, Sacrifice the Plum Tree to...

Durante o desenvolvimento do Templo Digital, meu projeto de hackathon (uma vitrine 3D de cursos...

TL;DR: In 2026, the old "cheaper hourly rate vs. more control" framing is outdated. AI-assisted delivery is compressing team size, contracts are shifting from hourly to outcome-based, and onboarding windows have shrunk from months to days. Use staff augmentation when you have strong internal PM capacity and need specific skills for 3-6 months. Use a dedicated team when you're running a 2+ year product and need a self-contained unit with its own PM/QA. Below is a breakdown of the current landscape, including how providers like Toptal-style networks, 6senseHQ , Cleveroad , ScienceSoft , BairesDev , SolveIt , and Uptech fit into each model. Why this decision looks different in 2026 than it did in 2023 Three things changed the calculus this year: AI-assisted engineers ship more per head. Teams are increasingly built around a handful of seniors paired with AI coding assistants rather than a dozen mid-level developers billed by the hour — which makes the traditional "cost per hour" comparison less meaningful than "cost per shipped outcome." Contracts are moving from time-and-materials to outcome-based. Buyers are pushing vendors to tie payment to delivery milestones, not logged hours, partly because AI tooling makes hour-counting a weaker proxy for value. Onboarding windows collapsed. Several dedicated-team providers now quote 3-7 day ramp-up instead of the 2-4 week window that was standard a few years ago, which narrows the traditional "augmentation is faster to start" advantage. None of this changes the fundamental difference between the two models. It changes how much each one costs you in practice. The core difference, restated simply Staff augmentation : you hire individual engineers who join your team, use your tools, and report to your leads. You manage the work. Dedicated team : you hire a self-contained unit (engineers + QA + a PM/lead) that runs its own delivery process. You manage the roadmap, they manage the mechanics. The break-even point most guides converge

One of my favorite words in the startup and product-building world is pivot. For a long time, I thought a failed project meant wasted time. Today, I see it differently. Every project I worked on—even the ones that never gained users or reached the finish line—taught me something I couldn't have learned from books alone. They taught me how to validate ideas, communicate with users, make technical decisions, prioritize features, and, most importantly, when to change direction. I've come to believe that many successful founders didn't succeed because they had the perfect first idea. They succeeded because their previous attempts gave them the experience to recognize a better opportunity. In fact, I think that if many of them had started directly with the project that eventually made them successful, they might have failed. They first needed the lessons, the mistakes, and the discipline that came from building things that didn't work. I'm still on that journey. Some of my own projects didn't succeed the way I had hoped, but I don't consider them failures. They were investments in experience. Every project made me a better builder and helped me better understand what I want to create and how I should create it. One principle that keeps me moving comes from the Quran: «"Indeed, Allah will not change the condition of a people until they change what is within themselves." (Quran 13:11)» And another verse that reminds me to stay patient during difficult times: «"Allah does not burden a soul beyond what it can bear." (Quran 2:286)» If you're building something today and it isn't working, don't be afraid to pivot. Sometimes changing direction isn't giving up—it's applying everything you've learned so far. I'm curious: Have you ever pivoted a project? What did it teach you?