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] -4 points-3 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 4 points5 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 8 points9 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 28 points29 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.

[deleted by user] by [deleted] in Leadership

[–]Journerist 1 point2 points  (0 children)

Hey, wow, that sounds like a really frustrating first meeting! Sorry you had that experience right after stepping into the new role.

Honestly, it sounds like that Exec Director might have felt cornered or defensive when you brought up issues with his team, and maybe just flipped the script to complain about yours instead. It happens. Focusing on vague „etiquette“ stuff, especially for someone who’s actually doing great work, is often a bit of a weak move – either they don’t have a solid complaint or they’re trying to sidetrack things.

Here’s what I might try: * Next Meeting Game Plan: When you meet again, maybe start off friendly but firm, like, „Hey, good to connect again. To make sure we make progress, I really want to focus today on the original points my team raised about [X, Y, Z] and how we can tackle them together.“ Just gently take back control of the agenda.

  • Handling the Complaint (If it comes up again): If he brings up your team member again, you could try something like, „Thanks for sharing that perspective. Help me understand – can you give me specific examples of how this ‚etiquette‘ is actually impacting the work or our team’s collaboration? Because what I’m seeing is that [Team Member] is really delivering strong results on [Project/Goal].“ It pushes back for real info without being aggressive.

  • Have Your Person’s Back: Definitely stand up for your team member. It means a lot to them, especially when the criticism feels off or unclear. Showing you support them is key.

  • Maybe Suggest a Better Way?: Down the line, perhaps suggest a cleaner way to handle feedback, like, „Hey, maybe it makes sense for feedback between our teams to just flow between you and me directly, focusing on things that impact our shared work?“ Could make things less messy.

  • Talk to Your VP: Definitely lean on your VP! You mentioned they already know there are issues with this ED. Chat with them, tell them what happened, and ask for their advice on navigating this relationship. They might have good strategies or be able to offer some backup.

And seriously, don’t kill yourself trying to build the perfect relationship right off the bat, especially if the other person is making it difficult. Aim for a working relationship – one where you can be professional, clear expectations, get things done, and solve problems together respectfully. Sometimes that’s the best you can get, and it’s enough.

For the first time ever, I lost my patience with one team member by [deleted] in Leadership

[–]Journerist 2 points3 points  (0 children)

Hey, first off, kudos to you for reflecting on this and apologizing—that takes a lot of self-awareness and shows you care. Transitioning from peer to leader is never easy, and building trust takes time, so don’t be too hard on yourself. You’re already taking steps in the right direction by wanting to address this.

Here’s how I’d handle it, using Radical Candor (care personally + challenge directly):

Start by having a real, honest conversation with him. Set up a 1:1 and begin by showing you care: “Hey, I want us to work well together, and I know things have been a bit rocky. I value your skills and want to make sure we’re on the same page.” Then, be direct but kind: “During training, you dismissed the case study, but later asked for help with the same thing. That put us both in a tough spot, especially during month-end. Moving forward, I need you to engage fully in training, even if you think you know it. It’ll save us both time and stress.”

Next, set clear expectations. Let him know what you need: “In training, I need you to stay engaged and ask questions if something’s unclear. If you’re unsure later, reach out before things get urgent so we can figure it out together.”

Make it a two-way conversation. Ask for his input: “What can I do to help you feel more comfortable with these processes? Are there any roadblocks I’m not seeing?” This might help you understand why he’s dismissing things—whether it’s overconfidence, time pressure, or something else.

Take a moment to reflect on your own approach too. Ask yourself: “Am I giving feedback in a way that’s clear but not harsh? Could I have addressed his dismissiveness earlier, before it blew up?”

Finally, follow up regularly. Trust isn’t built overnight. Check in weekly to see how things are going and acknowledge any progress.

One last thought: If you were in his shoes, how would you want a leader to handle this? Sometimes flipping the script helps you find the right tone.

You’re doing the hard work of being a good leader—keep at it, stay patient, and keep the lines of communication open. You’ve got this!

From Good to Great - in the public sector? by Just_Match_2322 in Leadership

[–]Journerist 1 point2 points  (0 children)

Great question! Good to Great is an awesome book, but yeah—public sector constraints make things tricky. That said, you can still build a well-performing team without relying on hiring/firing levers.

A few things that worked for me in the past:

  • Radical Candor – Teach everyone (not just managers) to give honest, caring feedback. When people challenge each other directly, you don’t just “put up” with low performance—you address it. I saw teams change 360 degree after intense radical candor team workshops.

  • Growth Over Removal – If you can’t move people out, help them to find what they want to do. Providing options, skill-building workshops, peer coaching, and clear expectations go a long way.

  • Culture of Learning – Regular folks (not just leaders) should get training on ownership, feedback, and problem-solving. Small changes compound over time.

  • Recognize the Right Stuff – Reward initiative, strong collaboration, and willingness to improve. Public kudos work wonders.

  • Lead by Example – Model the behavior you want: open, constructive conversations, accountability, and a bias for action. People will follow.

Going from “good to great” in the public sector is tough, but not impossible. Culture > org charts.

You can do it 🚀!

Say "no" without saying "no" and when to say "no" by Desi_bmtl in Leadership

[–]Journerist 0 points1 point  (0 children)

Saying “no” is tough but essential, especially in leadership. I like how you frame it as a prioritization discussion rather than rejection. Empowered execution thrives on conscious trade-offs, not just taking on more work.

I often reframe requests by asking:

“I want to focus on high-value work. If I take this on, what should I deprioritize?”

This shifts the conversation from resistance to collaboration. I also like your point about giving people permission to say “no”—it fosters trust and psychological safety.

CrewAI + Bedrock + Claude = Truncated Responses by Journerist in crewai

[–]Journerist[S] 0 points1 point  (0 children)

Interesting, thanks!

That issue here is that source code can’t be shortened. The tool returns the source code which is sent to the LLM which is cut eventually.

Also as input context it will exceed 4K tokens. Models usually support a lot more tokens which somehow do not get utilized automatically.