DEV Community: Srikannan

I posted about the same problem on Social media for 4 weeks before writing any code. Here is what I found.

Srikannan — Fri, 19 Jun 2026 08:00:07 +0000

I am building a B2B developer tool.

Six weeks ago I made a decision that felt uncomfortable at the time:-
I would spend a full month talking to potential users before
touching the codebase.

No mockups. No landing page. No code.
Just conversations.

Here is what actually happened.

Why I did this

I had a problem I wanted to solve.
I had experienced it myself.
I was convinced other people felt it too.

That conviction felt like validation.
It was not.

Feeling strongly that a problem exists is not the same as understanding who feels it, how badly, and whether they would pay someone else to solve it.

I had seen too many developers including myself in past projects build something for six months based on personal conviction and launch it to silence.

This time I wanted real signal before real investment.

The method

I picked the communities where my target users spend time.

Posted genuine questions about the problem space. Not about solutions. Not about what I was building. Just about the pain.

Then I read every reply carefully. Not for validation.
For pattern recognition.

What I found three completely different groups

I expected to find one audience.
I found three.

Group 1 — "This isn't a problem if you set it up correctly"

The largest group by volume of replies.

These are experienced practitioners who have already solved the problem their own way.
They have built internal tooling, established processes, and accumulated deep expertise over years.

When I described the pain I was exploring they did not recognize it as pain. They recognized it as a skill gap.

Their reply was essentially:
learn the tools better and this goes away.

They are not wrong. They are also not my customer.

High expertise means low pain means low willingness to pay for a solution to something they have already solved.

Group 2 — "Yes it is painful but we have accepted it"

The second largest group.

These people feel the friction daily.
They have tried to fix it.
Hit walls.
And eventually made peace with the situation as permanent.

The most common phrase from this group: "That is just how it works."

This group is interesting because the pain is real and present.
But acceptance has killed urgency.

To sell to Group 2 you do not need a better product.
You need to break their belief that the situation is unfixable.

That is a marketing problem as much as a product problem.

Group 3 — "I have no idea how to fix this and it costs us time every week"

The smallest group by volume.
The loudest pain.
The only ones who asked follow-up questions.

These are the people sitting with a problem they cannot solve, watching it cost them time repeatedly, with no clear path forward.

They are not waiting for awareness.
They are waiting for a solution that actually exists.

These are my people.

The uncomfortable insight

I spent four weeks looking for validation.

What I found instead was that the community I was targeting was mostly made up of people who were not my customer.

Group 1 pushed back hard on the premise of my posts. Some were dismissive. Some were genuinely helpful.
All of them confirmed they did not need what I was building.

Group 2 agreed with the problem but had already stopped looking for solutions.

Only Group 3 maybe 10 to 15 percent of respondents showed the combination of pain and openness that makes someone a real potential customer.

If I had read only the volume of responses, I would have concluded the market did not exist.

Reading the quality and pattern of responses told a different story.

What changed in how I am building

Before the research I was building for the average user in the community.

After the research I am building specifically for Group 3.

That sounds obvious in retrospect. It was not obvious before.

Group 3 has different needs than the experienced practitioners in Group 1.

They do not want to learn the internals. They want the internals explained to them in plain language.

They do not want more configuration options.
They want fewer decisions to make.

They do not want a powerful tool that rewards expertise.
They want something that works without requiring them to become an expert.

This changed several product decisions I had already made.
Some features I was excited to build became irrelevant.
Some I had deprioritized became critical.

Four weeks of conversations saved me from building the wrong version of the right product.

The thing I did not expect

The pushback from Group 1 was valuable in a way I did not anticipate.

Their objections became my objection-handling script.

Every time an experienced user said "just do X and this problem goes away" they were telling me exactly what my product needed to address for the cases where X does not work.

The critics gave me the edge cases.
The edge cases became the product.

What I would do differently

Start with lurking, not posting.

I spent the first week posting questions.
I should have spent it reading existing threads to understand the language the community uses to describe the problem.

Language matters more than I expected.

The words your customer uses to describe their pain are not always the words you use to describe what you are solving.

Finding that gap early would have made my posts sharper from day one.

Where I am now

Six weeks in. Product half built.

The research did not validate my idea.
It refined it.

I know exactly who I am building for.
I know what they need.
I know what objections I will face.
I know which features matter and which ones
I was building for myself not for them.

That is worth four weeks of uncomfortable conversations on the internet.

If you are pre-product and thinking about doing something similar do it.

But read the replies for patterns not for validation. The patterns are where the real signal lives.

What did you find when you talked to users before building?

Building a developer tool in public.
Writing about what I find along the way.

Your Jenkins build failed. Now what?

Srikannan — Tue, 16 Jun 2026 08:30:41 +0000

A realistic walkthrough of what actually happens next and where teams lose the most time.

Let me describe a scene that happens hundreds of times
a day across engineering teams worldwide.

It's 2:47 PM. A Slack message appears:

"Build failed - backend-service #1847"

What happens next is where things get interesting.

The notification tells you nothing useful

The alert tells you the build failed.
It doesn't tell you:

Which stage failed
Whether it's a real failure or a flaky test
Whether this has happened before
Who on the team is best placed to fix it
How urgent it actually is

So the first thing every developer does is open Jenkins.

The log problem

A typical Jenkins build log in 2026 is between 2,000
and 15,000 lines long.

It contains:

Dependency resolution output (usually 60% of the log)
Compilation steps
Test output
Docker layer pulls
The actual error (usually in the last 5%)

The error that caused the failure is almost never
at the top. It's buried. Usually near the bottom.
Often wrapped in a stack trace that points somewhere
misleading.

So the investigation starts with Ctrl+F.

Search for "ERROR". Get 47 matches.
Search for "FAILED". Get 12 matches.
Start reading each one to find the real one.

This process takes between 5 minutes and 2 hours
depending on the failure type.

The repeat investigation problem

Here's what makes this worse.

The same failure often happens multiple times before
anyone fixes the root cause.

A flaky integration test fails on Monday. Developer
re-runs it. It passes. Closed.

It fails again Wednesday. Different developer.
Spends 20 minutes investigating the same thing
the first developer already investigated.
Re-runs it. Passes. Closed.

Fails again Friday.

Nobody connected these three events because Jenkins
doesn't connect them. Each failure is a fresh ticket
with no history.

The total investigation time across three developers:
45 minutes. For one flaky test that nobody fixed.

The notification gap

Most teams have one of three setups:

Setup A: Email when build fails.
Result: developer opens email 3 hours later.
Build has been broken all afternoon.

Setup B: Slack notification with build link.
Result: developer clicks link, opens Jenkins,
reads logs, spends 15-20 min figuring out what happened.

Setup C: PagerDuty for critical pipelines.
Result: someone gets woken up and still has to
read the logs to know what to do.

All three have the same problem.
The notification tells you something broke.
Nothing tells you what to do next.

What actually helps

The teams I've seen handle this well do a few things:

They categorize failures automatically.
Not just pass/fail. They know whether a failure is
a dependency issue, a test failure, an infrastructure
issue, or something else. This alone cuts investigation
time significantly because you know where to look.

They track failure patterns across builds.
A test that fails 3 times in a week is a different
problem than a test that failed once. Teams that
catch patterns early fix things before they become
daily interruptions.

They give developers context before they open Jenkins.
The best failure notifications include a short plain-English
summary of what failed and why not just a link to 10,000
lines of logs.

The question worth asking your team

How long did your team spend last week just reading
Jenkins logs?

Not fixing things. Just reading logs to understand
what happened.

Most teams have never measured this number.
The ones who do are usually surprised.

What does your build failure workflow look like?
Have you found anything that actually reduces
the time between alert and knowing what to do?

What's the most painful part of Jenkins that you've just accepted as "how it is"?

Srikannan — Fri, 12 Jun 2026 11:48:30 +0000

Been using Jenkins for 3 years. There are things I complain
about but have never actually tried to fix because it felt
like "just how Jenkins works."

For me:
Build logs that require a PhD to read
No idea which builds are consistently flaky vs actually broken
Plugin updates that feel like Russian roulette

What have you just accepted and stopped fighting?