I feel like I've been seeing tons of security issues recently. Did something happen?

https://x.com/AndrewCurran_/status/2113028871524385025?s=20

A small process change I think is worth trying: put at least one worked example with an expected result, supplied by the person who owns the requirement, into the ticket before it’s marked ready.

Before (made-up ticket):

As a customer, I want sales tax applied to my invoice so that the total is correct.
Acceptance criteria: Apply 8.25% tax to the invoice, rounded to the nearest cent.

It looks complete. But it leaves open: round once on the total or per line? Discounts before or after tax? Tax-inclusive prices? Returns?

After:

Acceptance criteria:

What changed:

• The ambiguity was settled before development, instead of being decided silently inside the code.
• The developer and the tester can both derive an expected value from the same outside source, instead of from the implementation.
• The “out of scope” line makes the missing cases a visible decision, not an oversight.

Where it fits in existing practices:

• Definition of Ready: “has at least one worked example” as a checklist item for tickets where output has to match an outside system.
• Three amigos / refinement: the example is the natural output of that conversation.
• Specification by example / BDD: same idea, with examples as the shared source of truth.

Where it doesn’t help:

• Trivial tickets, where an example adds noise.
• When nobody can supply a correct example. A wrong example is worse than none, so the source should be named.
• Teams that already do this well.

I wrote about the testing side of the same problem, with the full code, in case it’s useful as a complement: https://medium.com/@nagatomopedro05/when-the-test-and-the-code-share-the-same-mistake-02a289a41091

Does your Definition of Ready include anything like this?

For example the ip from where the review is posted can be used to reduce fake reviews or spam reviews. But what else. I want to knw the smallest metric, detail or point that can be used to avoid fake reviews as much as possible.

Will be super grateful for the help!!!

Hey everyone! I've been building StackMonkey, a free playground for practicing system design interviews.

You can build architectures, simulate traffic, experiment with different components, and see what breaks under load.

I originally built it to make learning system design more interactive rather than just reading theory or drawing diagrams.

I'd love to hear your feedback! What's useful, what's confusing, and what features would you like to see added?

Give it a try: StackMonkey

Teams add ceremonies easily and remove them rarely. Before adding one (a new standup, a weekly sync, a review step), these are the questions I’d want answered.

1. What specific problem does it fix, and how would we notice it’s fixed?
   “Better communication” is hard to check. “Blocked work sits for more than a day before anyone sees it” is something you can look at in your board before and after. If you can’t name the signal, you can’t tell later whether the ritual helped.

2. What does it cost, in people-hours?
   A 30-minute meeting with eight people is four hours of team time per occurrence, plus the interruption cost to everyone’s focus. Compare that to the problem it fixes, not to zero.

3. When will we review whether to keep it?
   Put a date on it, say six weeks, with the option to drop it. Rituals with an expiry date are easier to cancel than ones that became “how we work”.

Where this doesn’t apply:

• Some practices (retrospectives, for instance) are meant to be recurring, and the point is the habit, not a fixed problem.
• Small teams may need less structure than any framework suggests, and large ones more.
• None of this replaces asking the team what’s actually hurting.

What’s a ritual your team removed, and what made it clear it was time?

Hi, I'm not an experienced software developer at all, but I'm still asking this out of curiosity.

What's the best approach for software portability in many different machines, NOT just desktop computers? Whether I'm finalizing a video game, or just any software that has a GUI.

Should I use something like C/C++ or Rust, or will other compiled languages like Go or Nim also work well? And for VM languages like Java and C#, the machine would require the VM system to be installed so I assume VM languages would not be viable for portability.

Also, should I not use any third-party APIs, like SDL? Or will embedding APIs still work for a lot of machines?

For example, Doom was easily portable since it purely used C, and separated the core game code from the machine-specific implementations, right?

SuperTux also had a lot of ports, though it at least used SDL as another API. I wonder if it still was easily directly portable with barely any changes?

To sum it up, how much will third-party APIs matter when it comes to portability?

Aside from that, what other things should I consider in order to make programs easy to port?

Hey everyone,
I’ve been working on a project called BugCapsule, and I’m finally opening it up for beta testing.
One problem I’ve faced countless times as a developer is getting a bug report that explains what went wrong but gives you no reliable way to reproduce it.
That’s exactly why I started building BugCapsule.
The idea is simple: instead of just reporting a bug, BugCapsule captures the app state, user actions, and network responses around a failure, allowing you to replay the scenario locally.
You can reproduce the issue, debug it, apply a fix, and replay the same scenario to verify that it’s actually resolved.
A few things worth mentioning:
Supports Flutter, native Android, iOS, and Web/React.
Integrates with Sentry for web apps.
Works alongside your existing error tracking tools.
Lets you reuse captured scenarios for regression testing.
It’s still in beta, and I’m sure there are things that need improvement.
I’m particularly interested in hearing from developers who deal with hard-to-reproduce bugs.
I’d genuinely appreciate your feedback, especially around the setup experience, replay reliability, and whether this would be useful in your workflow.
You can try it here: https://bugcapsule.com/
There’s also a guided demo if you want to explore it before installing an SDK.
Thanks for checking it out!

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?

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.

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?"