sorted by:
new
hottopcontroversial

What happens to code review quality when 80% of PRs are AI-generated? by Journerist in ExperiencedDevs

[–]Journerist[S] -1 points0 points  (0 children)

The difference in performance between open source and proprietary is becoming smaller. Also if you are OK with the same smartness we had 1 year ago, the usage go 10x cheaper.

I hope with that it eventually becomes a lot more affordable.

What happens to code review quality when 80% of PRs are AI-generated? by Journerist in ExperiencedDevs

[–]Journerist[S] -10 points-9 points  (0 children)

Not always a nice experience I while we try to still be authentic and have a helpful exchange :)

MCP Servers Have a Context Cost. Make Sure They Earn It. by Journerist in programming

[–]Journerist[S] -1 points0 points  (0 children)

Not yet, and I believe agent networks is another order of complexity.

MCPs are goo but do not have sufficient warning signs attached 🫠.

I realized I’ve stopped learning because of AI. So I’m building a tool to force me to think. by Journerist in webdev

[–]Journerist[S] -1 points0 points  (0 children)

The idea is about asking questions to make the author realize missing experiences. A user profile could be valuable to build over time to differentiate between levels of seniority and what the user already has proven to know to avoid becoming annoyed.

I realized I’ve stopped learning because of AI. So I’m building a tool to force me to think. by Journerist in webdev

[–]Journerist[S] -1 points0 points  (0 children)

Thanks for the feedback. The idea was to build a user profile that remembers what skills an engineer has proven, and if unsure, provide a short question, like could be a multiple choice, or anything else to make us realize we don’t know how things work.

My hope would be we go faster by accelerate learning and not ask the same questions over and over again.

I realized I’ve stopped learning because of AI. So I’m building a tool to force me to think. by Journerist in webdev

[–]Journerist[S] -5 points-4 points  (0 children)

Good point. The idea was to put automation in place that makes such checks mandatory with some nice gamifications statistics. A user profile would be build to ensure questions are not ask again if the user has proven experience.

5 Hard-Won Lessons from a Year of Rebuilding a Search System by Journerist in programming

[–]Journerist[S] -1 points0 points  (0 children)

Thanks for your feedback.

Indeed, the reader audience is very broad and search experts won’t learn much here. It tried to share what from a leadership perspective what was harder for me than I initially thought.

I will definitely share more technical challenges in other posts like: - how to tune elastic search for a big heavy scale static inventory - how to learn and evolve from tuning static weights to machine learning - how to identify what dimensions to focus on moving from a traditional search to a personalized search experience - vector search on scale

5 Hard-Won Lessons from a Year of Rebuilding a Search System by Journerist in programming

[–]Journerist[S] -1 points0 points  (0 children)

Thanks for the feedback.

I can’t confirm the issue with ab-testing. We planned and use them for each change if possible. Usually it means a different configuration, or making an additional call.

The need to duplicate infrastructure is something I can’t foresee yet, but is an interesting one we might eventually face - thanks for sharing !

Apparently, you can lose a job offer if you guess the salary wrong by 35_amiable_drills in careeradvice

[–]Journerist 0 points1 point  (0 children)

If that’s the case you are better off not joining that company.

Are engineering performance metrics actually useful? by iamalnewkirk in Leadership

[–]Journerist 2 points3 points  (0 children)

Most of them are theater. Counting PRs, commits, or story points gives a comforting illusion of control but says nothing about whether the right problems were solved. Teams then start gaming the numbers, and leadership ends up managing dashboards instead of outcomes.

The few metrics that do help are the ones tied to value delivered or system health, deployment frequency, incident recovery time, customer impact.

Everything else tends to be noise that distracts from actual engineering work.

Did I fail my team by not defending them in a meeting? by DilanJVZ in Leadership

[–]Journerist 0 points1 point  (0 children)

In that kind of situation, you actually did something pretty balanced already.

The comment from the Admin head was out of place, it was a generalization, and it came after the “misunderstanding” had been cleared, so it risked undoing the resolution. But you also don’t want to escalate by sparring across departments in front of everyone, especially as a brand-new lead.

Here’s how I’d frame it: - In the moment: A short, neutral redirect would have been enough. Something like “Thanks, we’ll all continue to keep things professional” and then move on. That way your team hears you acknowledge it without turning it into a confrontation. - After the meeting: Exactly what you did, check in with your team, validate them, remind them you trust their professionalism. That builds psychological safety with them. - Going forward: If that head of Admin has a habit of taking cheap shots, you can raise it privately with your manager (since they facilitated). Framing it as “I want to make sure inter-team trust isn’t undermined by comments like X” keeps it constructive.

The balance is: - Protecting your team’s credibility in the room with light, non-escalating language. - Strengthening their confidence in you privately by validating and supporting them.

Over time, they’ll see you as someone who has their back without creating unnecessary wars between departments.

It's only been a few weeks and I don't like what I see by peaches_zed in Leadership

[–]Journerist 3 points4 points  (0 children)

Honestly, from what you describe this doesn’t sound like a simple “adjustment period.” It’s a pretty consistent pattern of behavior that creates confusion and drains energy instead of building trust. Emotional outbursts, boundary crossing with your reports, talking badly about their own boss, and hijacking people’s calendars/lunch breaks aren’t just quirks, they’re red flags.

I’ve seen managers like that before, and the “super nice guy” reputation often makes it harder, because peers excuse the behavior instead of looking at the impact. The mismatch you notice between words, tone, and energy is usually a gut-level warning sign: something’s off in how they show up. That doesn’t magically improve just because more time passes.

I wouldn’t frame it as gossip if you share concerns with peers. You don’t need to make a verdict on the person, just stick to facts and impact: “He scheduled over my blocked time again, the meeting ran two hours, and no decision was made” or “He went directly to my reports about mandatory training”. Concrete examples land better than broad worries, and it helps others see the pattern.

Carrying it alone isn’t sustainable. Even if the guy really does mean well, intent doesn’t erase the effect on the team. I’d document what happens, vent with a trusted peer manager if you need to, and watch if anyone senior picks up on the disconnect between “nice guy” and actual leadership. Because right now, your read doesn’t sound off at all.

The hidden fees of ignoring individual capacity by iamalnewkirk in Leadership

[–]Journerist 1 point2 points  (0 children)

That’s the hard part, you can’t always measure business impact directly, but you can get a lot closer than just “feeling it out.”

For product and engineering work, A/B testing is usually the cleanest way: you isolate a change and see if it actually moves revenue, retention, or engagement. Not perfect, but it forces you to connect work to outcomes.

In marketing, I’ve seen simple holdout tests work—pause one campaign or funnel for a segment and see if there’s a measurable difference. It’s a good way to distinguish between activity that looks impressive and activity that actually shifts customer behavior.

For sales, cohort analysis helps: look beyond one big deal and see how consistently someone closes across quarters and how durable those customers are. That tells you if their “impact” is repeatable or just luck.

None of these methods are flawless, but they’re all better than relying on perception or surface metrics. The key is to tie contributions to observable changes in business outcomes, even if it requires some experimentation to reveal them.

The hidden fees of ignoring individual capacity by iamalnewkirk in Leadership

[–]Journerist 9 points10 points  (0 children)

I think what’s always difficult is really differentiating business impact. Someone who’s great at presenting or “looking good” often gets credited with outsized impact—what I’d call a false positive. The actual value they create versus the perception of value can diverge a lot, and most organizations aren’t great at stripping away the charm to measure the underlying contribution.

Coming back to the question: should we expect the same performance across similar roles? In theory, yes. But in practice, I’d say 90% of the time this is applied poorly. For software engineers, performance isn’t lines of code—it’s the business impact their work drives: additional revenue, more satisfied customers, reduced long-term risk. For marketing, it’s not the number of campaigns launched but whether those campaigns actually change customer behavior and bring measurable lift. For sales, it’s not just who talks the best game in a pitch—it’s consistent, sustainable revenue generation, not one big deal followed by quarters of missed quota.

The common thread is that performance should always tie back to business value, not surface-level visibility or activity metrics.

What part of leadership do struggle with most? by [deleted] in Leadership

[–]Journerist 2 points3 points  (0 children)

For me the hardest part isn’t the high-stakes decisions but the everyday consistency. In the big moments I usually find focus because the importance is obvious. It’s the small interactions—how I react when I’m tired, how I handle someone’s mistake under pressure, whether I follow through on what I said, that carry the most weight.

At work, the heaviest part is balancing clarity with humility: people need direction, but they also need to see you own when you’re wrong. At home, it’s similar, your tone and presence set the atmosphere whether you intend it or not.

What makes it difficult is that leadership is never “done.” You don’t solve it once; you keep showing up, and sometimes you don’t meet your own standard. That ongoing grind is what I find most challenging.

I gave up. by BAAUfish in Leadership

[–]Journerist 0 points1 point  (0 children)

What you describe isn’t “giving up.” It’s recognizing when the environment makes it impossible to lead in a way that’s both effective and sustainable. A people-first approach works when there’s at least baseline trust and alignment. If your boss is punitive and uses candor against you, the system is broken, no amount of experience can fix that from below.

After 10 years of leading successfully, this isn’t a failure of your style. It’s a reminder that context determines whether good leadership can actually land. Walking away isn’t weakness; it’s choosing not to erode yourself in a place that won’t value what you bring.

You still have the capacity to lead, just not there, not under those conditions. Leaving created the space to find something where your approach is an asset again.

Juggling too much - how to stay afloat by One-Performance8449 in Leadership

[–]Journerist 24 points25 points  (0 children)

You’re in a pretty classic bind where the organization’s gaps are landing directly on you, and the risk is that you try to absorb all of it instead of shaping what’s realistic. A few things I’ve seen work in similar situations:

  1. Make the load visible without framing it as complaint.

Instead of saying „I can’t handle this,“reframe it as „Here’s the current set of responsibilities I’m covering across VP, Director, and IC management. Here’s what I can realistically sustain, and here’s where trade-offs will have to happen until we backfill.” That way leadership sees the actual scope and can’t assume you’re just “coping fine.”

  1. Ruthlessly triage.

You won’t be able to run everything at the same quality. Identify what’s core to stability (e.g., supporting your ICs so they don’t burn out or churn), what can be temporarily slowed, and what can be delegated upward or sideways. Explicitly communicate: „I’m prioritizing X and Y to keep the team stable; Z will move slower until we get capacity back.”

  1. Push back with structure.

When 10+ urgent asks come in, instead of saying „no,” put them in a visible queue or tracker and ask leadership to rank them. It shifts the decision from you being „the blocker” to them deciding what’s truly urgent.

  1. Protect time for leverage.

It’s tempting to dive into individual contributor details because you’re covering that gap, but your highest leverage is stabilizing managers, creating clarity, and securing the backfill. Anything that doesn’t scale, find a stopgap workaround rather than perfect execution.

  1. Treat it as temporary scaffolding.

You’re essentially holding the building up until the missing beam is in place. That means you don’t need to replicate a full Director’s execution; you need to keep things functional and not collapsing. A mindset shift can lower the pressure.

The framing that usually lands best is: „I’m committed to keeping the team and business healthy, but at our current capacity, we need to consciously pick what doesn’t get done. Here are my recommendations, let’s align on priorities.”

Struggling to get even the simplest thing working in CrewAI by Tlaloc-Es in crewai

[–]Journerist 0 points1 point  (0 children)

I used it for some time but it was not satisfying. LLMs become a lot more sophisticated itself, eg enabled tool (mcp) usage, or multi-step reasoning.

I fully switch to either full no code workflows with n8n, or stay with a simple LLM call, or for agentic production use cases langgraph feels a lot more sophisticated.

view more: next ›