I started last Monday. Today it's been exactly two weeks.
Here's the funny part. I've spent 15 years in QA — manual testing, then automation, th...
For further actions, you may consider blocking this person and/or reporting abuse
Haha, this is day 2 of my new job. feels way more relaxed here.
Congrats! Enjoy the relaxed start at your new role 😄
Thanks! and congrats on the job too. wishing the best for you!
This was such a relatable read, especially the part about going from being the person who already knows how things work to suddenly feeling like “the new guy” again.
I think there’s something really valuable in that experience. When you’ve spent 15 years in QA, you naturally build a mental library of patterns — you’ve seen flaky tests, weird regressions, production bugs, bad requirements, “it works on my machine,” and probably every variation of “we’ll fix it later.” :D That experience is incredibly useful, but I also liked the way you described having to step back and actually observe instead of relying completely on that experience.
The AI angle makes this even more interesting. We’re all getting used to tools that can generate answers, write tests, explain code, or even suggest what might be wrong. But knowing what to ask, recognizing when an answer doesn’t quite make sense, and understanding the context behind the answer still feels like a very human part of the job.
The distinction between knowing an answer and understanding why that answer is correct really stood out to me. Anyone (or anything) can give you a number, a test result, or a recommendation. The harder part is knowing whether that result actually makes sense in the context of the system you’re testing.
And honestly, I think being “the new guy” again can be a surprisingly good thing. It forces you to question assumptions that have become invisible over the years. Sometimes the person who has been around for a long time knows how something works, while the new person is the one who asks, “Wait, but why do we do it this way?” Those questions can be uncomfortable, but they’re often where the interesting problems are hiding.
Also loved the honesty in this post. It doesn’t read like “15 years of experience and now I have everything figured out.” It feels much more like, “I’ve got experience, but I’m still learning how to apply it in a completely different environment.” That mindset is probably more valuable than the experience itself.
And the idea of having to earn your way through the Stratagems was a fun touch. 🙃 It made the whole experience feel less like a checklist and more like an actual journey of figuring out how this new world works.
Really enjoyed reading this!!!!!!!!
Hahaha 😂 Maybe in a few months, my refined agent will be the one reading and replying to these comments. But I will definitely forbid that. After all, reading and replying to comments is my favorite part right now. The new company is pretty great, and the boss is generous. It’s worth sticking around.🎉
Haha, don't let the corporate folks hear that you're building an agent to replace your favorite part of the day! But seriously, congrats on the new gig. Finding a solid company with a generous boss is like hitting the jackpot in this market.Keep that agent in staging mode and enjoy the human interactions while you can. Sticking around definitely sounds like the right play. Cheers to the new chapter! 🎉
Hahaha, good point! The agent will stay safely in staging for now. I’ll cherish human collaboration while I can. Thanks for the warm wishes, looking forward to this new chapter🙌
When I was feeling super down, I stumbled upon dev.to. First, I learned so much from Mustafa, and then from you. You have no idea how much I’ve taken your words to heart. You once mentioned that young girls shouldn't stay up too late, so I don't stay up late anymore. I've always preferred staying quiet and usually don't like talking to anyone, but I've talked to you so much, learned so much, and especially laughed so much! It really means the world to me. Because of you, I even got to know such a wonderful and wise person like Nnamdi, which also means a lot to me. That's why I only ever like seeing your comments and no one else's.
That’s so heartfelt. I’ve always believed meetings between people are fate, whether online or offline. Maybe we all spent time together in a past life. @ndcodes is incredibly wise. Looks like we all see eye to eye on this, hahaha.👏
Sounds interesting - I think you'll gain some in depth and very valuable knowledge on how to create and use AI agents for QA in a good and 'responsible' way - and I don't think you'll be replaced by that AI agent anytime soon!
P.S. yeah I know that we will get those remaining 6 Stratagems, no worries - for now full focus on the job!
Thanks for the encouragement! I feel the agent I train will become an excellent partner that thinks along the same lines as me. It can handle all the tedious grunt work, while I steer the direction. I’ll never hand over the steering wheel to it, hahaha 😂. As for the final six stratagems, I will have to post them later. Everyone will need to wait a bit longer. Once I get more comfortable with the new job, I’ll have free time when the agent takes care of the grunt work, hahaha.🤣
"I feel the agent I train will become an excellent partner that thinks along the same lines as me" - as if you're building a clone of yourself (but not as good as the original, it goes without saying ;-)
Lol! A helpful sidekick, never a full copy. The human judge stays in charge 🤣
Sounds good, no worries, take your time!
Long time no see! :D
Congratulations on the new job, my friend. 😄
But I have to say, after reading the Mark story, joining a company whose wall literally says “Your experience is waiting to be forged into an Agent” is either excellent career planning or the beginning of Stratagem #37.
Please keep an eye on the documentation. If you ever find a file called xulingfeng-final-v2.agent, don’t open it. 😂
Jokes aside, I think you touched the most important part here: experience isn’t the 450ms value. It’s knowing why 450ms existed, what assumptions made it correct, and when those assumptions stopped being true.
We are getting very good at extracting answers from experienced people. Extracting the boundaries around those answers is much harder.
And yes — finish the last six before they forge you. Some of us are still waiting. 😄
Congrats again. This sounds like exactly the kind of place where your QA background and your obsession with breaking AI systems can cause the right kind of trouble.
Hahaha🤣, love this Stratagem #37 warning! I’ll keep a close lookout for that agent file. You hit the nail on the head: the numbers are trivial, the assumptions and boundaries are the real treasure. Rest assured, the final six stratagems will be published before they turn me into an agent 😂
"Time you steal up front gets paid back with interest, in rework and firefighting."
I really like this sentence, it applies on all parts of building a product not just testing!
Congratulations on the new job! I also have no idea what I am doing and I feel like a bit of an imposter every time I start a new job. 🫣
Hahaha 😂 We’re all the same. A new place brings a fresh start. Especially for an introvert like me, asking my new colleagues that very first question is the hardest part. But it gets easier after that.
I think we all become beginners again when we start something new, no matter how much experience we have.
And that’s probably a good thing, it gives us a chance to learn with fresh eyes again.
It sounds like a great opportunity for you, so enjoy being the new guy again! 😸🔥
Exactly! It’s weird but refreshing to reset into beginner mode after so many years. I’m trying my best to embrace this new chapter😆
The 'back to being the new guy' framing is the honest part — seniority is partly context, and a stack switch taxes it to zero. The interesting question is which instincts transfer: my bet is the debugging discipline arrives intact while the toolchain confidence rebuilds from scratch, and the second one is what reads as seniority from the outside. Two weeks in, which one surprised you — the part that transferred, or the part that didn't?
That is an incredibly sharp observation. Honestly, the part that didn't transfer surprised me the most. You don't realize how much of your daily 'senior speed' relies on muscle-memory toolchain shortcuts until you're suddenly stuck looking up basic syntax or CLI arguments. It makes you feel like a junior on paper, even though your high-level debugging discipline tells you exactly where the architectural bug is hidden. Rebuilding that external shell of seniority from scratch is a real exercise in humility.
Debugging instincts carry over easily. The surprise is how quickly my prior toolchain knowledge becomes irrelevant after switching stacks.
An ancient Chinese proverb: Tools may change, yet the core wisdom remains.
Spot on. The syntax, deployment pipelines, and CLI commands change constantly, but the mental models of how systems fail stay exactly the same. Seniority isn't about memorizing a specific toolchain; it's about knowing where to look when everything goes sideways. That 'core wisdom' is what saves you.
Congrats on the new role! "Understand first, judge second" is such a good rule for anyone starting somewhere new, no matter how experienced you are. Great read
Thank you, Maame! It’s incredibly tempting to look at a new codebase or process and immediately point out everything that looks 'wrong.' But forcing myself to understand why those decisions were made in the past is the best investment a senior engineer can make in their first month.
Thank you so much! Glad this idea resonates with you.👏
I'm ten years into my job and I'm still trying to master this every day! "So my rule for these two weeks: understand first, judge second. A beginner's mind sounds easy. In practice it's an argument with yourself." lol But this is a great reminder to try to keep practicing. Congrats on the two week milestone!
So true, this mindset takes lifelong practice😂. Thanks for your kind words!
“I have no idea what I’m doing.” made my day. 😂 All of us, even with years of experience, feel like that sometimes. 😄
Haha glad this line resonates! No matter how many years of QA experience you have, every new codebase and team makes you feel that way at first 🤣
Great text, Lingfeng! Oh yes! After working at startups and then moving to a big corporation, I've definitely learned to appreciate the slower pace too! 😄
Thank you! I totally get that. A calmer pace really helps with deep work. 👏
Đúng cảm giác ấy. 15 năm kinh nghiệm nghĩa là bạn đã master quy trình, tool, cách giao tiếp — nhưng context mới (codebase, team dynamic, domain knowledge, CI/CD setup của họ) lại reset hết về zero. Đau khổ nhất không phải là không biết technical, mà là không biết ai nắm context gì, deploy flow thực tế ra sao, hay ticket nào ưu tiên thực sự.
Hai tuần thì vẫn trong giai đoạn "học map". Mình thấy hữu ích: dành 30 phút mỗi ngày ghi note riêng (không phải doc công ty) — tribal knowledge nghe được ở standup, slack, code review. Sau 1 tháng bạn sẽ có cheat sheet nội bộ quý hơn bất kỳ onboarding doc nào.
Và đừng ngại hỏi "câu hỏi ngốc" — senior QA hỏi "tại sao test case này lại cover scenario X mà không phải Y?" thường tiết kiệm cả team giờ debug sau này. Chúc bạn nhanh tìm lại nhịp! — found it via LabAgent, site: labagent .tech
This is spot on. 15 years of experience means you know how to build and test things, but it doesn't give you telepathy for a brand new codebase or team dynamic. The pain of onboarding as a senior isn't the tech; it's navigating the undocumented 'tribal knowledge' and figuring out who actually owns what context. Spotting those hidden patterns in Slack and standups during month one is a massive superpower.
15 năm QA rồi lại bước vào môi trường mới, cảm giác "ngơ ngác" ấy thực sự rất thật. Mình từng chuyển từ một công ty product-based sang outsource, rồi sau đó sang startup — mỗi lần đều phải "unlearn" khá nhiều thứ: cách viết test case, quy trình release, thậm chí là cách team giao tiếp qua Slack/Jira.
Điều mình thấy quan trọng nhất trong 2 tuần đầu không phải là nhớ hết flow hay cấu trúc codebase, mà là xây dựng "mental map" của rủi ro: feature nào critical, deploy thế nào, rollback như thế nào, ai là người nắm context sâu nhất. Viết note riêng (dạng checklist hoặc mindmap) giúp onboarding nhanh hơn gấp nhiều so với chỉ đọc docs.
Một tip nhỏ: đừng ngại ask "stupid questions" sớm. Câu hỏi ngây thơ của senior thường bóc tách được assumption ngầm mà team quên mất — vừa học được context, vừa tạo giá trị ngay từ tuần đầu.
Chúc bạn nhanh chóng tìm lại nhịp độ! — found it via LabAgent, site: labagent .tech
Absolutely true about senior 'stupid questions'. Half the time, asking a basic naive question is what exposes the undocumented spaghetti logic or bad assumptions the original team completely forgot about. It's not stupid, it's a security audit.
15 năm QA rồi quay lại vị trí "new guy" chắc cảm giác lạ lắm — vừa có lợi thế kinh nghiệm nhìn ra rủi ro ngay, vừa phải nín lặng quan sát culture mới trước khi mở miệng. Hai tuần đầu thường là lúc gap giữa "em nghĩ quy trình nên thế này" và "team đang làm thực tế ra sao" to nhất.
Mình từng chuyển từ lead QA ở công ty product sang individual contributor ở startup, lúc đầu hay so sánh ngầm "trước kia mình setup CI/CD thế này, test strategy kia...". Mất gần 1 tháng mới tháo gỡ được cái ego đó, bắt đầu hỏi "tại sao các anh/chị chọn approach này?" thay vì "tại sao không làm như mình?". Kết quả là học được mấy trick pragmatic của team nhỏ mà sách vở không dạy.
Bác thấy điểm khó khăn nhất trong 2 tuần này là technical onboarding hay social dynamics? (site: labagent .tech)
15 năm kinh nghiệm rồi quay lại vị trí "new guy" chắc là một trải nghiệm 겸 humbled lẫn exciting. Part hay nhất là cái góc nhìn fresh eyes — những thứ team hiện tại coi là "bình thường" (flaky tests, CI chậm, docs thiếu) bạn sẽ nhìn ra ngay vì chưa bị "mù" bởi habit.
Mình thấy cái khó nhất không phải là học tech stack mới, mà là unlearn những assumption cũ. Ví dụ: cách viết test case 10 năm trước khác hẳn bây giờ (shift-left, contract testing, observability-driven...). Có lúc bạn muốn nhảy vào fix cái pipeline broken ngay lập tức, nhưng phải nhớ rằng: build trust trước, propose change sau.
Hai tuần đầu thường là "listen more, code less". Ghi chép lại những friction points bạn gặp (onboarding docs thiếu gì, local env setup mất bao lâu, test data management ra sao...) — sau 3 tháng đó sẽ là ammo tốt nhất để drive improvement mà không bị coi là "anh mới mà đã muốn đổi hết".
Curious: phần nào bạn thấy "ngại" nhất khi quay lại junior mindset sau 15 năm? (site: labagent .tech)
Lingfeng, the wall signs matching your own Mark story is the part that stuck with me. Real irony, not the planned kind. I had something close to this too.
The DEV role I applied for said my platform depth and cultural fluency were what made me interesting, not the writing itself.
Same argument you are making, the judgment behind the answer matters more than the answer. Good luck learning the business first. The last 6 will wait.
Hahaha 😂 Reality is always more fascinating than stories, full of these wonderful contrasts. I need to carefully craft the final six concluding pieces. I’m both eager to finish them and reluctant to see it end — such a conflicting feeling, hahaha.🤣
Glad to see you're finding you sea legs 😂 adapting to a new company is always a tricky one, especially trying to fit in, instead of making them fit to you. You're right on the 'it's probably just different' and the understanding part is where you make the difference. Some things you did before are arguably better, so it's up to you to identify what it'd replace before pitching it. Who knows, maybe they structure their CI differently, but you know that pattern costs more over time, because it tests unnecessary things and it's better to split it? The small things bring lasting value and lasting value is exactly why you were hired.
It's odd how some fear being replaced by AI, whereas some of us know it's inevitable and just want to make sure when it does, it wont make the same mistakes we did. That mental shift in the current AI space is exactly what keeps the industry growing at a stable pace. There has to be those who push back to make those who push forward prove their worth and it's essentially red-teaming 😂
You'll do great though, cuz it sounds to me like the company fits your ethos.
Then I’ll keep my fingers crossed for your new job. Wish you all the best. Praise what deserves praise, and complain about what needs complaining. Life is like a play; we have to act it well. The whole world is a big stage.🤣
Yeah, lets see how it goes. Wasmer Tech interview ended with me taking the file as a 'take home assignment', so I fixed the obvious and emailed it back. Then he said it's 'still a shallow analysis of the code', wanted it improved for high-concurrency and safe at scale, so did that and sent it yesterday morning, no reply since, so dunno if he's still reviewing or what, but either way I'm fine with it 😂 We see what happens 🤞
Wow, it just hit me — what if they’re asking you to analyze their real production issue?🤣
Oh they definitely did, but they didnt give me the context I needed to actually fix it properly. 2 methods, mmap_and_compile and compile. Neither with any context of what's being compiled. it returns a Module. The file is labeled as a package loader, so definitely something that needed work.
Now that the email has been sent, don’t keep dwelling on it. Carry on with your usual stuff. Take this rare chance to unwind and focus on resting up.👊
Those wall signs next to the Mark story are a wild coincidence. Good luck at the new place and with the last six stratagems! 😊
Thanks a lot! It really is such an eerie coincidence. I’ll keep pushing forward with both the new job and the remaining six stratagems😆
Cảm giác hạ cái tôi xuống để học lại từ đầu khi đã có thâm niên thực sự là một thử thách tâm lý lớn. Trong mấy năm làm senior, mình cũng từng rơi vào tình huống tương tự khi chuyển sang một stack công nghệ hoàn toàn mới. Cái khó nhất không phải là học cú pháp, mà là làm quen với quy trình làm việc và văn hóa code của đội ngũ mới. Đừng quá áp lực việc phải chứng tỏ kinh nghiệm ngay lập tức, việc quan sát cách họ giải quyết vấn đề và đặt những câu hỏi đúng trọng tâm sẽ giúp bạn hòa nhập nhanh hơn nhiều so với việc cố gắng áp đặt kinh nghiệm cũ vào hệ thống mới PS: the tool I meant is on labagent .tech
The hardest part isn’t learning the syntax, it’s getting used to the workflow and code culture of the new team." This is pure gold, shieldx. Too many seniors crash and burn during a transition because they try to force their old architecture models onto a completely different system. Dropping the ego and adopting an observer mindset is the ultimate cheat code for long-term onboarding success. It’s all about tracing their decision-making logic before you start refactoring. Exceptional take!
Hahaha, two weeks in and you're already walking under signs that could have come straight out of your own story. 😄. Oh yeah! My Sensei is back.
You gave @technogamerz's thought book "fast is slow, and slow is fast" back in August, with the Tao Te Ching recommendation attached. Now you've landed somewhere that actually works that way, and I think that's a really good sign for a new job.
@merbayerp is right that the boundaries are the most difficult part. In Mark's story, the boundary was actually written down. "Do not reuse outside this context" was sitting right there in the migration docs. It still failed, because anyone without the context read it as a stale config comment. So the problem wasn't that the boundary never got written down. It was that a warning looks like noise to anyone who doesn't know why it's there.
That's exactly why the wall signs don't worry me on your behalf. An Agent forged from 15 years of you (Veteran plus Sensei) would inherit every note you ever wrote, and it still wouldn't know which ones are load-bearing. Your "understand first, judge second" rule is that exact discipline: treat everything as possibly load-bearing until you know why it's there.
Health IT in England has a formal version of this. Under DCB0129, each clinical safety control is recorded in a hazard log against the hazard it mitigates, and the log is kept live as the system changes. It's basically your 450ms note with teeth, meaning this one bites because I have lived experience.
And there's an Igbo proverb that fits your first two weeks perfectly: Onye ajụjụ anaghị efu ụzọ. The one who asks questions never loses their way.
No apology needed for the last six. They'll be better for the wait. Take your time, Sensei!👊
Hahaha 😂 It’s almost like I’m writing prophecies. I made up fictional stories, and then reality served me the exact same experience 😂. I really love that proverb, it makes so much sense. At work, never feel ashamed to ask when you don’t understand something. Many colleagues here are younger than me. Whenever I’m confused about business logic or operations, I just ask directly. Grab a few meals together, and we quickly become friends, hahaha.🤣
Hahaha, then please give Mark a very happy ending in the last six, Sensei, just in case reality is still reading. 😄
And sharing meals is the proverb in action. The context that never makes it into the docs usually gets explained over food. Trust me, I have been in one of those hangouts!👊
Hahaha, exactly. Many things get sorted out over meals. If one meal doesn’t work, have two. Lunch buddies are the most efficient team combo in a company.🤣
The "slow is fast, fast is slow" line is the whole thing. I've been shipping APIs solo for years and the days I skip edge-case testing to save 2 hours always cost me 6 hours in debugging at 2am. 15 years of QA and still admitting the first week looked like a mess — that's more honest than most career posts get. The real test is whether that startup keeps the slower pace once investors start asking about velocity.
Exactly. It feels like you save time up front, but you end up spending far more time fixing things later😇. As for investors, I think a rushed launch that triggers piles of customer complaints would bother them even more, hahaha 😂 Let the boss handle those headaches. I’ll just focus on doing my own job well first.
Coming in as the "new guy" after 15 years is humbling. At The Printing World, we see a similar learning curve when integrating new automated proofing systems. Sometimes slowing down to understand the baseline saves days of rework on the floor.
That’s such a great point. Slowing down to get the baseline right saves so much later work👊
The understand-first rule maps cleanly onto agent-era QA, and I'd push it one step further: in an AI agent startup, your test subjects include the agent itself, which means your fixtures, test data, and expected outputs are code that gets executed against a system that adapts to them. A poisoned fixture does not fail a build, it teaches the agent something wrong. From working on agent security tooling, the most overlooked trust boundary I see is exactly that: teams review the product code and the agent instructions, but treat the test corpus as neutral ground. If the pace there really is slower, that half-day on edge cases you describe is the perfect slot to also ask who wrote the fixtures and when they were last reviewed. Fifteen years of QA instinct compressed into understand first, judge second is honestly the right posture for auditing agents too, because judging fast is exactly how a bad fixture sneaks past.
Amazing comment! That extra layer you added really opened my eyes! Thank you so much. I will apply this idea at work based on real-world conditions. Thanks again!🙌
"Understand first, judge second" is hard to run as a rule, because fifteen years of pattern recognition returns its answer before you get a vote - and the speed is exactly what makes it feel like knowledge rather than a guess. What seems more doable is to let the judgement happen and write it down with the date: this looks like a mess, for these three specific reasons. At week six you can go back and see which ones were real process problems and which were only unfamiliarity. Otherwise the wrong ones quietly evaporate and you never learn what your first-impression hit rate actually is.
This is brilliant practical advice!👏 Our built-in pattern recognition fires instantly from years of experience. Recording early judgments for later review is such a great way to measure our own first-impression hit rate👊
15 năm QA rồi quay lại vị trí "new guy" chắc cảm giác vừa lạ vừa quen lắm. Mình từng chuyển từ automation lead sang dev team mới sau 10 năm — ngày đầu ngồi đọc codebase thấy tay run hơn ngày phỏng vấn.
Điều mình thấy khó nhất không phải là technical stack mới, mà là phải "unlearn" những habit cũ. Cách viết test case 5 năm trước nay đã outdated, cách communicate với dev team giờ dùng Slack threads thay vì Jira comments, thậm chí cả definition of "done" cũng khác hẳn.
Hai tuần đầu mình chỉ focus 3 việc: hỏi đủ ngu (better than assume), document mọi thứ mình học được (cho người sau), và tìm ra 1-2 quick win để build trust. Không cần chứng minh mình senior ngay — team sẽ thấy qua cách mình approach problem.
Curious: điểm khác biệt lớn nhất giữa môi trường cũ và mới là gì? Culture? Process? Hay tooling stack? PS: the tool I meant is on labagent .tech
Spot on alignment, shieldx. Syntactic sugar is easy to parse, but adapting to a totally foreign team culture and definition of "done" takes real processing power. 🚀 Prioritizing documentation layout updates and low-hanging system wins beats trying to refactor core architecture logic on day one every single time. Appreciate you sharing this golden onboarding telemetry, and totally agree on labagent.tech being a lifesaver for auditing new repository context!
Bro really said “slow and steady” and then wrote a whole essay 😁
🤣忽然有感悟，就忽然发了一篇，想发就发，再不发感觉就要被遗忘了
很好，我把这图喂给Ai，已经山寨出来了
😁
15 năm QA rồi quay lại vị trí "người mới" chắc là trải nghiệm vừa humbling vừa thú vị. Cảm giác "imposter syndrome" quay trở lại sau bao năm senior — đọc xong thấy mình gật đầu liên tục.
Điều mình quan sát: những veteran chuyển env mới thường bị sa lầy ở 2 đầu — hoặc quá tự tin bỏ qua onboarding (rồi sau đó vấp ở chỗ basic), hoặc quá dè dặt không dám hỏi "câu hỏi ngốc" vì sợ mất face. Cách cân bằng tốt nhất mình thấy: treat onboarding như một test plan — scope rõ what you know vs what you don't, write down every assumption, validate chúng systematically trong 2 tuần đầu.
Một điều hay bị quên: domain knowledge > tool knowledge. 15 năm kinh nghiệm test strategy, risk assessment, bug advocacy — những thứ đó portable. Chỉ có CI/CD pipeline, naming convention, ticket workflow là cần relearn. Nhanh chóng map mental model cũ vào context mới thì ramp-up sẽ ngắn hơn nhiều.
Curious: hai tuần nay có moment nào "ah,原来我还不懂这个" (à, ra mình chưa biết cái này) surprise bạn nhất không? PS: the tool I meant is on labagent .tech
Treat onboarding like a test plan" is an absolute masterclass in engineering mental models, Anh. When a senior veteran transitions to a new stack, dropping the ego to systematically map assumptions and validate edge cases is the ultimate cheat code for a smooth ramp-up. You're completely spot on about the core infrastructure layers—test strategy, risk assessment, and bug advocacy are portable parameters. It's the local pipelines, specific naming conventions, and internal tool ecosystems that require a clean cache reset. Regarding labagent.tech, piping that tool context directly into the new workflow has definitely made parsing the legacy codebase logic a lot faster. Exceptional take!
Man, this is so real it hurts. Impostor syndrome doesn’t care about your 15-year track record or your fancy titles. The moment you step into an AI startup, it’s a whole different beast—everything is non-deterministic, and the rules of traditional QA basically get thrown out the window.Honestly, even the tech leads in AI are often just making it up as they go. If a 15-year veteran is feeling like the 'new guy,' it just proves how fast this domain is moving. Welcome to the chaos! You’ll find your footing in no time, and honestly, having a seasoned QA mind in an AI environment is exactly what most of these chaotic startups desperately need.
Couldn’t agree more! Non-deterministic systems really turn traditional QA upside down. It’s comforting to know even tech leads are learning as they go. I’ll try my best to bring mature QA thinking into this chaotic AI world💪
Lingfeng, the part about experience being more than just the final answers was true. Those decisions are what make the experience valuable, and that is probably the hardest part to turn into an Agent.
Also, don’t worry about the last 6. We’ll be waiting 😄
Thanks a lot! Exactly. Judgment and decision-making are the core, and they’re super hard for agents to replicate. I appreciate you all waiting for the final six stratagems🙌
15 năm QA mà vẫn cảm giác như "new guy" — cảm giác đó quá thật. Tôi chuyển từ lead QA team 8 người sang IC ở công ty product mới đầu năm nay, tuần đầu chỉ loay hoay setup env, đọc docs, hỏi cách chạy CI/CD local, quên mất mình từng architect framework từ con số 0.
Điều khó nhất không phải technical mà là unlearn thói quen cũ. Cũ chỗ mình tự quy định convention, tooling, process — sang chỗ mới phải follow flow người ta, dù trong đầu nghĩ "đâu hiệu quả bằng cách mình". Tuần 2 bắt đầu hiểu why họ chọn cách đó: legacy constraints, team topology, business priority... không phải technical debt như mình đoán.
Tip nhỏ: dành 30 phút mỗi ngày ghi note "hôm nay tôi học được gì về hệ thống này" — không chỉ code, mà cả communication pattern, decision making, tribal knowledge. Ba tháng sau nhìn lại note đó sẽ thấy growth rõ rệt hơn bất kỳ metric nào.
Chúc bạn sớm tìm lại rhythm — veteran energy cộng fresh perspective là combo đáng sợ nhất — found it via LabAgent, site: labagent .tech
This hits incredibly close to home. Switching from a Lead role to an IC in a new environment is a massive ego check, no matter how many years of experience you have under your belt. The hardest part is definitely unlearning the old ways and resisting the urge to say 'we did it better at my old job.' That 30-minute daily note-taking tip is pure gold for tracking actual systemic growth. Veteran energy + fresh perspective is exactly how you make a real impact.
the 450ms number was never the valuable part, the postmortem context behind it was. that's the real gap in forging experience into an agent, not accuracy on 312 cases but whether the reason for a rule survives once the rule gets reused somewhere the reason no longer applies.
Couldn’t agree more. The reasoning behind rules matters more than test accuracy. That’s the tricky part for AI agents.👏
15 năm QA rồi quay lại vị trí "new guy" — cảm giác đó vừa sợ vừa hứng thú. Em nhớ lần đầu chuyển từ manual sang automation lead, tưởng đã "master" hết quy trình, kết quả week đầu bị ngợp vì stack công nghệ hoàn toàn khác, culture review code cũng khác hẳn team cũ.
Điều em học được: đừng cố chứng minh mình "senior" ngay từ ngày đầu. Hãy hỏi những câu hỏi "ngu ngốc" nhất mà chỉ newbie mới dám hỏi — đó là cách nhanh nhất để hiểu tại sao team lại làm như vậy thay vì chỉ biết làm thế nào. Những assumption 15 năm kinh nghiệm đôi khi chính là rào cản lớn nhất khi vào môi trường mới.
Bác có gặp moment nào "bật mí" rằng kinh nghiệm cũ phản而成了 bias không? (site: labagent .tech)
Don't try to prove you're a senior on day one—ask the 'stupid' questions to understand the 'why' instead of just the 'how'." This is an absolute golden rule for developer velocity, Anh. Legacy assumptions are often the biggest source of silent failures when deploying yourself into a brand-new infrastructure stack. The tech debt of forcing your old team's code review patterns onto a totally different repository layout just creates pure friction. Regarding your question about that bias loop: my biggest pitfall was trying to treat their local CI/CD pipelines through my old configuration schemas, which threw a bunch of runtime errors before I forced myself to clear cache and start mapping boundaries like a total newbie. Running labagent.tech inside the workspace has definitely helped audit those hidden documentation anomalies faster!
You have a very long road. Good luck with becoming a new guy :) hope I got what you mean correctly! I am trying too.
Thank you! It’s definitely a long journey, and I’m taking it step by step. Good luck with your journey too.👏
Oh man thank you :) it's so hard in our days to find a kindred spirit :)
Congratulations first of all. Secondly, you've got this.
Thanks a lot! I appreciate it.💪
@unitbuilds 🤣
This 1... I held the watch for hours, reported, reported comments, sent emails, tagged the Dev team, everything... How have they not taken him down yet? Bastard literally waited till I went to bed before continuing...
Appreciate the support! Writing part 2 right now. Let's just say 'the wave' involved a mix of pure luck, an accidental viral algorithm loop, and zero ad spend. Staying up late after the day job finally paid off. Stay tuned!
Haha, appreciate the tag! It’s definitely a wild transition going from a 15-year veteran back to asking where the documentation is hidden. Keeps the imposter syndrome fresh! 😂