Teams copy process templates all the time: a Definition of Done from another team, a PR checklist from a blog, a retro format somebody swore by. They save time, and they carry decisions made for a different team.

A hypothetical example of how one line can collide with something you already have.

The inherited line, from a copied DoD

“Every change is approved by two reviewers before merge.”

Sensible. Plenty of teams run exactly this.

Your own rule

“A production incident is mitigated within 30 minutes of the page.”

Also sensible.

Where they meet

It’s 2 a.m., a bad deploy is breaking checkout, and the fix is a one-line revert. The DoD says two approvals. At that hour there’s one person awake who can approve, and she’s the one who wrote the revert. Either the team breaks its own definition of done, which teaches everyone that it’s optional, or the incident runs long waiting for a second reviewer. Neither line is wrong on its own. The conflict only shows up at the worst possible moment.

How I’d deal with it

Read the borrowed template the way you’d review a dependency, a line at a time:

• what is this line for, and does it hold for how we actually work?
• does any line contradict a rule we already have, especially for incidents, hotfixes, or legacy code?
• what’s missing that we need, such as an emergency path or who can approve it?
• then try it against a few situations it wasn’t written for: a hotfix, a tiny typo fix, a change in a module with no tests

Usually the outcome is a small amendment, like “two approvals, except for incident reverts, which need one approval and a follow-up review the next business day”, and that exception being written down is the whole value.

Limits: for a brand-new team with no history, adopting a template as is and adjusting later may be better than debating each line. And an audit only catches the conflicts you think to test for.

How do your teams handle process templates they borrow? Do you audit them up front, or amend them when they bite?

I wrote about the same idea for a different kind of template (system prompts, where inherited defaults can quietly contradict your own rules): https://medium.com/@nagatomopedro05/the-decisions-hidden-inside-every-template-6ddb8715c24e

I've been working with formal methods in my software engineering practices for a while now, and thought I'd try to spread some of what I've learnt into the wider community. In the hope that it will inspire some creativity around the use of LLMs as a complimentary force, instead of the slop cannon we have now.

https://mulgadc.com/blog/blueprints-not-prompts-tla-plus

I think we're still all stuck in the early stages of adopting a new major tech (AI), where we use it do the exact same stuff we used to. Just faster, and worse.

Feedback is welcome!

PS: Zero AI was used in the formulation of this post, or the writing of the article itself. It has no place in creative pursuits such as writing. Not even for grammatical issues. Traditional spellcheck suffices (for better or for worse).

https://w.pitula.me/developer-communication-handbook/

Hey, I wrote a short (~70 pages) free book about communication for developers and I think this is at the very core of what software development (and not programming) is about.

Over the years I noticed how little our crowd cares about communication, so I decided to write something that is approachable, directly actionable and with as little fluff as possible.

Free, no ads, CC BY, not LLM-generated. Web, PDF, EPUB, and an audiobook.

Hey everyone,

I'm trying to build a portfolio of businesses that we help save on their AI bills. Would it be relevant for anyone here?

Hi everyone!

I’m currently in the green card process and expect to move to the East Coast in about 6 months. Since I’ll have a green card, I won’t need visa sponsorship.

A bit about me:

• B.Sc. in Computer Science (graduated 2024)
• ~1.5 years as a full-stack developer at a software company. I’ve built around 100 responsive landing pages in HTML/CSS/JS, and I also work on our company’s own products and on client projects using React, Angular, PHP, .NET, and MySQL.
• ~2 years volunteering as a full-stack developer at a nonprofit, building a React Native / Node.js / MongoDB app that connects shelter animals with adopters. I’m now the tech lead there (code reviews, mentoring new devs, app store releases).
• A couple of years of IT/technical support experience before that, plus a Cyber Security Analyst course (CompTIA CySA+)
• At work, I use Claude Code heavily, both on our company’s internal products and on client projects

I know I’m still a junior and the US market is tough right now, so I’d really appreciate some advice:

1. Interviews: What should I prepare for? Is LeetCode still a must for junior roles? Should I study system design at my level?
2. Resume: What do US recruiters look for that might be different from Israel (where I’m based now)? Anything I should add, remove, or format differently?
3. Job search: Where should I focus: LinkedIn, company career pages, job boards, or reaching out to people directly? Does cold-messaging engineers or recruiters actually work?
4. AI tools: How do US companies view heavy use of tools like Claude Code? Is it worth highlighting on my resume, or could it hurt me?
5. Timing: Should I start applying before I arrive, or wait until I’m physically in the US?

Thanks in advance. Any advice is appreciated!

I'm building a small Python project to detect narratives that spread quickly across social media, focusing on Spanish-language content.

The goal isn't to decide whether something is true or false. I want to collect public posts, group similar content, and identify posts or narratives that spread unusually fast for further review.

What I've built so far:

• RSS feeds from news websites
• Text cleaning and duplicate detection using SimHash
• Retry handling and a dead-letter queue
• Scheduled data collection

Where I need help:

1. Facebook and Instagram: Since CrowdTangle is gone, what are the current, legitimate ways to monitor public pages, groups, and Reels?
2. Telegram: Is it better to use web previews or Telethon for collecting data from public channels? What should I know about rate limits?
3. Reddit: How long did API approval take, and what types of projects were approved?
4. Detection methods: Apart from duplicate posts and sudden increases in views or shares, what signals help identify coordinated activity?
5. Open-source resources: Are there any useful tools or labelled datasets for detecting misinformation in Spanish or multiple languages?
6. Legal and ethical concerns: What should I keep in mind regarding GDPR, platform rules, and responsible data collection?

I'm only interested in methods that respect platform rules and focus on public content and narratives, not tracking individual users.

I'd really appreciate any advice, research papers, GitHub repositories, or lessons from your own experience. Thanks!

Hey everyone,

I built a Chrome extension called LinkedIn DM Scheduler to automate repetitive LinkedIn outreach.

The idea came from getting tired of manually sending similar messages to multiple people. I wanted to build something that could handle scheduling, message personalization, and campaign tracking directly in the browser.

Some of the features I implemented:

• Schedule messages for later
• Personalize templates using placeholders like {name} and custom fields
• Run campaigns with configurable delays
• Track campaign progress through a live dashboard
• Automatically close tabs after sending

One of my goals was to keep the extension self-contained, with everything running locally in the browser rather than relying on an external backend.

I'm sharing the project because I'd appreciate feedback from other developers, especially on the architecture, reliability of browser automation, and how to handle failures during scheduled tasks.

Project links:

GitHub: https://github.com/Ravish2008/linkedin-dm-scheduler

Chrome Web Store: https://chromewebstore.google.com/detail/linkedin-dm-scheduler/agecdfbhigfdjhholmicfkeldbdhobbl

If you've built Chrome extensions or browser automation tools, I'd love to hear what you'd improve or approach differently.

A pre-mortem is a simple idea, usually credited to the psychologist Gary Klein. Before a project starts, you imagine it has already failed and work backwards to explain why. The reasoning is that people are better at explaining a failure that has “happened” than at predicting one that might.

If I were running it for a team, this is the shape I’d use.

Start by saying the premise out loud: it’s six months from now, the project shipped late and badly, and everyone agrees it was a failure. Nobody is allowed to argue that it wouldn’t happen.

Then give everyone five minutes of silent writing. Each person writes down the reasons it failed, one per sticky note or line. Silence matters because otherwise the first confident voice sets the list, and the quieter people, who often know about the awkward dependency or the unclear requirement, go along with it.

Next, go around the room and have each person read out one reason at a time, until everything is out. No discussion yet, no “that won’t happen.”

Only after that do you ask the two questions that decide what to do with the list: which of these could we notice early, and which would be cheap to prevent now? Most of the output ends up being a handful of small changes to the plan, not a long risk register.

A few things I’d watch out for:

• it turns into a complaint session if there’s no follow-up, so someone should own the two or three actions that come out of it
• people may avoid naming problems that point at a manager or at the plan itself, so the facilitator’s attitude matters a lot
• it surfaces risks people already half-know about, and it can’t surface what nobody on the team has thought of
• on a small, low-risk project it’s probably more ceremony than it’s worth

I haven’t seen a good way to keep the results alive after the meeting. The list tends to get forgotten once the work starts.

For people who have run these: what made yours useful, and what made it a waste of an hour? And do you revisit the list at any point, or does it stay in the kickoff doc?

Imagine picking up a change to an existing service. The ticket explains the request, a design discussion explains why an alternative was dropped, and an incident note explains the exception the new code must preserve. You need all three before the implementation plan makes sense. That's a hypothetical, but it's the engineering situation I'm building Shifu around.

I'm looking for professional engineers with 3+ years of experience who use AI coding tools on real products and want to get much better at building with them. Particularly if preparing a feature keeps turning into a hunt through earlier discussions and decisions.

I was an IC before spending the past four years as an engineering leader. The question I keep coming back to is what we should carry into the next piece of work. A conclusion on its own isn't enough. I'd want the reason, the conditions it depended on, and something I can check before trusting it.

Shifu is a personal work-context engine. I'm building it to connect that reasoning from work you choose to share to the feature you're planning. The test I'd use is quite small: can we recover one relevant decision or constraint, check where it applies, and use it to change or clarify the plan? If it produces a plausible summary but I still have to reconstruct everything, that hasn't solved the problem.

I'd also want the lesson from shipping that feature to come back into my own practice: what assumption did I miss, and what would I try differently next time? Execution and personal growth both matter to me here.

I'd like to try this with one real upcoming feature and a supported source you're allowed to share. I'm Shifu's builder: https://useshifu.com. Happy to help with setup and walk through the result together. We can look at what was useful, what was missing, and whether the setup and corrections were worth the effort. Please keep confidential work details out of this thread.

I've noticed a huge divide between those who use AI and the human-purist side which seems to despise those who use AI with a burning passion.

And I do think part of it has to do with the fact that some among us code for the beauty of the craft and others code much more for the outcome.

So is there a way we can have civil discussions without attacking each other personally. I've mainly noticed the purist side attacking AI users and I just don't think that's justified.

Everyone on here is trying to make it and to build software, some just have different philosophies on how to get there.

So to those of you who speak down on and seem to despise AI users so adamantly, why is that ? And could we try to be more civil ?

With the usage of coding agents gaining more prominence, I am writing everything with AI. And the amount of features and hence the line of code that I am pushing is many folds than I was writing before the AI era and hence not the capacity to review. I am literally not able to review everything that I wrote, more so 99% of the code being written is alien to me. I just mostly check the initial plan with AI and then verify if various flows and edge case are working fine.

What is the general trend? Do you guys know the code you wrote? Which piece is in which file etc?

Just wondering if writing tests by hand first could be a good thing to maintain ownership and understanding now that less and less people care about the code itself ?
To my experience it is, but wondering how many of you do still write their tests by hand ?

Something I’ve been thinking about with AI code review. A finding costs almost nothing to produce now, but checking one costs the same as it always did. And they all arrive in the same confident tone.

Take a hypothetical PR that adds retry logic to a payment client. The review comes back with five findings:

finding                              cost to check     cost if wrong
-----------------------------------------------------------------------
variable name inconsistent           seconds           nothing
missing log line                     minutes           low
suggest switching HTTP library       days              low
possible race on retry counter       an hour or two    medium
idempotency key may be reused        an afternoon      a customer charged twice

Read top to bottom, they look like the same kind of item. Sorted by the two right-hand columns, they’re not.

The naming nit is trivial to check and trivial to get wrong, so you just fix it. The library swap is expensive to evaluate and not urgent, so it can wait. The idempotency one is the awkward case. To know if it’s real you probably need the provider’s docs or a sandbox test, so it’s the most expensive to check, and it’s also the only one where being wrong hurts. It deserves the afternoon even though it was worded no more urgently than the naming nit.

So “is this finding true?” isn’t the most useful question. “What does it cost to find out, and what does it cost if I ignore it and I’m wrong?” seems to work better for me.

A few limits I can think of:

• for a small, low-risk change this is overkill; just read the findings
• stakes depend on context that often isn’t in the diff, so the model can’t judge them for you
• it only ranks what the model raised, and says nothing about what it missed

The model can help lower the checking cost, for example by pointing at the lines it relied on or suggesting a test that would confirm or refute the claim. The decision about what’s worth the afternoon is still a human one.

How do you handle this on your teams? Does anyone have an informal rule, or do you just read the findings in order and hope the important one isn’t buried?

I wrote the longer version of this up here if anyone wants it: https://medium.com/@nagatomopedro05/a-finding-takes-seconds-to-generate-checking-it-doesnt-e7ffad4eaea2

For a long time, client acquisition was the hardest part of running my web design agency.

I was doing outreach manually, checking websites one by one and trying to figure out what I could say that would actually get a reply.

The biggest change for me was combining volume with specificity.

Instead of sending generic emails asking businesses if they need a new website, I started analyzing their existing websites for real issues like outdated design, poor mobile experience, slow speed, weak SEO and bad responsiveness.

Those issues then get turned into personalized emails for each business and sent at scale.

That means I can reach a lot of businesses every day without every email sounding like the same copy and paste pitch.

Now the prospecting, website analysis and first part of the outreach are mostly automated.

I mainly focus on the people who reply, book meetings and close the projects.

That shift made client acquisition way more consistent for me.

If you’re a web designer dealing with the same problem, check out my workflow.

Is the custoner finding bugs ? How is he reacting ? Do you have a QA / V&V team supporting you ?

How does the PM reacts to the customer?

There's a lot of articles out there about aidlc and modern ways to do software development in the AI era. I want to hear what's working for your team and what's not

I've seen developers spend months preparing to launch.

One more feature.
One more redesign.
One more rewrite.

Then another month disappears. I understand it.

We want the thing we build to be good. But I've learned that perfection can become another form of procrastination.

Real users will teach you things your codebase never will. Build it well. But put it in people's hands.

Should I go with GPT PLUS or CLAUDE PRO

Or any other AI subscription that you guys can recommend

Used to be my favorite thing in tech. Open stage to talk about your little project, some pizza, and a little talking or networking.

Not the big structured networking focused events, more just meetups/demo nights.

Seems most have gone away by now but I honestly don’t even have the desire to go anymore. Passion projects are just not exciting when it’s made by an AI prompt. Like porting games to dumb stuff was always a hit but now it’s just like…cool you told Claude to do it and it did it.

When a teammate uses or using an AI agent to debug a problem or implement a feature, would you as colleague find it useful to open their workspace, read the entire conversation, and request control with team-lead approval?"

\*\*TL;DR:\*\* I'm not a developer. On September 4th I started building a production management web app for the furniture plant where I work, with Claude Code. One month later it's the tool the office and the shop floor use every day. Sharing what worked, and looking for people who've gone down the same road.

\---

\*\*A bit about me\*\*

I work at a furniture manufacturer, on the operations / planning side (Director). My days are spent in the gap between the ERP, the accounting system, a pile of Excel workbooks, an old in-house tracker the floor depends on, and what's actually happening in the shop. I'm not a programmer, and I'm still a beginner with the terminal and Git. I manage the systems, with an IT guy + looking for a full stack developer at the moment.

\*\*What we built\*\*

It started as "one page per department showing what to build this week". It grew into:

\- Production schedules per department (wood, upholstery, sewing, metal, finishing, shipping), with kanban cards and project closures

\- Lot planning: building lots, closing them, and exporting back to the ERP

\- Purchasing follow-up: open POs, supplier reminders, freight and overseas shipments

\- A capacity simulator, inventory counts, shop reports, a supervisor dashboard, even a small internal chat

\- Read-only connections to the ERP, the accounting system, Access databases and network spreadsheets

Scale, just to give an idea (I know lines of code aren't a quality metric): 386 commits, currently v2.54, \~175k lines of Python and vanilla JS, \~2,100 tests, \~580 API routes, \~280 SQLite tables. The stack is boring on purpose: FastAPI + SQLite + plain HTML/JS with Tailwind, no build step, running on a Windows machine on site. Everything, UI and code, is in French.

\*\*What made it work for me\*\*

\- \*\*A short CLAUDE.md + one doc per module.\*\* CLAUDE.md only holds what applies to every session. Each module (37 of them) has its own doc that Claude reads before touching it. When something breaks, the lesson becomes a rule in the right doc.

\- \*\*Memory for project state.\*\* A new session knows where each project stands and which questions are still waiting on me.

\- \*\*Questions before code.\*\* Every new screen starts as a mockup, and Claude asks me questions first. Some features started with 40+ questions. Honestly, that's where a lot of the value is: it forced me to write down business rules nobody had ever written down.

\- \*\*Every external system is read-only.\*\* The old tracker can literally stop production if it gets locked, so only one read at a time, behind a lock. And a guard blocks any network access, subprocess or file write during the test suite.

\- \*\*One git worktree per feature.\*\* Never code in the folder the live app serves.

\- \*\*A release skill.\*\* A checklist for version number, registries, tests, commit and deploy.

\- \*\*Cost as a constraint.\*\* 4 to 8 targeted tests per change, no swarms of agents.

\*\*Where I'd love your experience\*\*

1. \*\*Bus factor.\*\* I can read the docs and the tests, but I couldn't rewrite most of this code myself. If you've been there: when did you bring in a real developer, and how did the hand-off go?

2. \*\*Docs that rot.\*\* With \~40 module docs and a growing list of rules, how do you keep CLAUDE.md and the docs from contradicting each other?

3. \*\*Tests written by the same model that wrote the code.\*\* How do you check they test the right things?

4. \*\*Adoption.\*\* The floor doesn't care about the tech; it cares that the numbers are right Monday at 6 a.m. How do you ship this fast without burning trust?

5. \*\*Manufacturing / ERP folks:\*\* anyone else doing this? What blew up on you?

I'll stay a bit vague about the company and the systems, hope you understand. Happy to go deeper on the workflow in the comments.

\*(And yes, Claude helped with the English. I'm a French speaker.)\*

Is it scalability, automation, integrations, security, flexibility, or simply the need to solve a problem that existing tools can’t handle?

Had a random realization today that made me feel kinda good about spending so many years in software development.

I was on ChatGPT, opened a chat and clicked on the “Pin” option. I waited for a second and then just refreshed the page..

A moment later I caught myself thinking.. why did I just do that?

So I tried to actually remember what was going through my head.

I guess somewhere subconsciously I had already assumed that clicking Pin would send a request to the backend, and the payload would be tiny probably just the chat ID or something similar, so I had this rough sense that the request would have gone through within that tiny moment I waited before refreshing. I didn't consciously calculate any of this. I just waited for what felt like "enough time" and refreshed. And I knew the chat was using the same URL as the homepage, so refreshing it would take me back there. Since the request should already have gone through, I expected the chat to be pinned when the page loaded again.

I didn't consciously think about any of this before doing it. I just did it.

And that really fascinated me...

After spending so many years working with software, things like requests, URLs, APIs, how pages work etc. have apparently become a part of how I naturally think about things. I don't have to actively reason through them anymore. My brain just makes these assumptions in the background.

It's such a small and probably stupid thing, but I found it strangely satisfying..

Made me realize that maybe all those years of staring at code actually did something to my brain.

​Tech lead on a desktop product, Windows mac and Linux, all three ship. We have no UI automation and I'm finally allowed to fix that.

Squish is the serious answer. Covers all three, mature, nobody gets fired for it. But it's a framework, so it becomes a test codebase, and our QA people don't write code. which means the codebase lands on one of my devs, and in two years it's one person's unmaintained side responsibility that everyone routes around. I've watched that happen twice.

The agent based tools claim to remove that. AskUI is the one that looks like a product rather than a demo, tests are plain files with steps and expected results, no object repository, screenshot and verdict per step. If it works, QA owns their own tests and nothing lands on my team.

The part I don't believe yet is the durability. Has anyone run one of these long enough to say whether the maintenance actually disappeared?

Support engineers at B2B software companies: when you get a complex ticket you haven't seen before, where do you go first to investigate? Docs, Slack, GitHub, asking devs?

I'm a support engineer for the past 6 years so just wondering what other engineers' workflows are.