DEV Community: Prakhar Yadav

I Gave 4 AI Models the Same Agent Skill. Here's What Happened

Prakhar Yadav — Fri, 02 Oct 2026 08:14:06 +0000

I've been experimenting with video generation workflows lately, specifically with how different AI models behave when they're given the same tools, environment, and instructions.

So I decided to run a small experiment.

I created a reusable video-generation skill — a set of detailed instructions describing how the task should be approached — and gave the same skill to four different models through OpenCode.

The results were interesting.

The models produced broadly comparable outputs, but their approaches to the task were noticeably different.

The Setup

The video-generation skill was created with the help of Opus 5.5.

It contained the workflow, instructions, verification steps, and expectations for generating the video.

I then gave the same skill to:

GLM 5.3 Flash
DeepSeek v4.1 Flash
MiMo v2.6 Flash
LongCat 2.5 Preview

Each model had access to the same general environment and tools.

The goal wasn't to create a formal benchmark or determine which model is "best."

I wanted to see something simpler:

How differently do models behave when they're given the same well-defined workflow?

The Results

Here are the execution times and token usage from each run:

Model	Time	Tokens
GLM 5.3 Flash	28 min	200.1K
DeepSeek v4.1 Flash	29 min	265.6K
MiMo v2.6 Flash	47 min	266.3K
LongCat 2.5 Preview	1 hr 5 min	276.8K

A few things immediately stood out.

GLM completed the task in 28 minutes, while DeepSeek was just a minute behind at 29 minutes.

GLM also used considerably fewer tokens — about 200K, compared with roughly 266–277K for the other three.

MiMo took 47 minutes, despite using almost the same number of tokens as DeepSeek.

LongCat was the slowest at 1 hour 5 minutes, and also used the most tokens.

That made sense once I looked at how each model approached the task.

1. GLM 5.3 Flash — Fast and Focused 🏎️

GLM understood the assignment and got straight to work with what it had been given.

Its instruction following was particularly strong.

There was very little deviation from the predefined workflow, and it didn't spend much time exploring unnecessary paths.

It simply followed the instructions and executed.

The result was a relatively efficient run:

28 minutes · 200.1K tokens

If I had to describe its behavior in one word, it would be:

Focused.

It didn't try to reinvent the workflow.

It just executed it.

2. DeepSeek v4.1 Flash — The Most Exploratory 🎨

DeepSeek understood the assignment well, but its approach was quite different.

Instead of immediately executing the provided workflow, it spent more time understanding the environment.

It went digging.

It launched Playwright MCP and other tools to inspect how things actually looked in the environment rather than relying only on the information already provided.

That extra exploration made it the most interesting model from a creativity perspective.

It wasn't necessarily looking for the shortest path.

It was trying to build a better understanding of the context before producing the result.

The run took:

29 minutes · 265.6K tokens

So despite using roughly 65K more tokens than GLM, it completed the task almost exactly as quickly.

3. MiMo v2.6 Flash — The Thinker 🧘‍♂️

MiMo spent considerably more time understanding the task and the environment before getting started.

It was more deliberate.

It explored the context, worked through the instructions, and then executed the workflow.

The interesting part was that the final output was still broadly comparable to the others.

The run took:

47 minutes · 266.3K tokens

And this highlighted something important for me:

The quality wasn't necessarily coming from the model figuring everything out from scratch.

The skill itself was doing a lot of the heavy lifting.

Because the instructions were already clear and structured, MiMo had a roadmap to follow.

It could spend more effort understanding the context without having to invent the entire workflow.

4. LongCat 2.5 Preview — The Most Iterative 😼

LongCat took the longest of the four.

1 hour 5 minutes · 276.8K tokens

Like MiMo, it spent considerable time understanding the context and environment.

But there was one thing that stood out.

It performed two verification rounds.

After generating the initial result, it checked its work, identified areas that could be improved, and then performed another iteration.

That made its workflow particularly interesting:

Understand → Generate → Verify → Improve → Verify

The final quality was broadly on par with the other models, but its process was more iterative.

It wasn't just generating the result and stopping.

It was actively trying to improve it.

The Interesting Part: They All Verified Their Work

One of the most interesting observations from this experiment was that every model performed at least one verification round at the end.

These weren't simply:

Prompt → Generate → Done

workflows.

The models actually checked their output.

LongCat went one step further and performed another iteration specifically to improve the result.

So despite the differences in their approaches, they all converged on a similar pattern:

Understand → Execute → Verify

Some models explored more.

Some were faster.

Some spent more tokens.

Some iterated more.

But verification was present across all four runs.

Was This Really "One-Shot"?

Technically, each video was generated in a single run.

But there's an important caveat.

The models weren't starting from a blank page.

They were given a pre-built skill containing clear instructions and a defined workflow.

So calling this a pure "one-shot" experiment would be misleading.

The actual process was closer to:

One prompt + a predefined workflow + autonomous execution

And that's arguably more interesting.

The experiment wasn't really testing:

Which model can figure out video generation from nothing?

It was testing:

How differently do models behave when they're given the same structured workflow?

The Skill May Have Mattered More Than the Model

This was probably my biggest takeaway.

The final outputs were surprisingly close in quality despite the models taking very different approaches.

The predefined skill gave every model a strong starting point.

Instead of having to figure out:

Which tools to use
What steps to follow
How to inspect the environment
How to validate the output
What constitutes a good result

the models already had a roadmap.

That changes the role of the model.

Instead of asking the model to invent the entire workflow, you're asking it to execute and adapt a workflow.

And that seems to reduce the differences between models for this particular task.

Model Behavior at a Glance

Model	Time	Tokens	What stood out
GLM 5.3 Flash 🏎️	28 min	200.1K	Fast execution, strong instruction following
DeepSeek v4.1 Flash 🎨	29 min	265.6K	Environment exploration and creativity
MiMo v2.6 Flash 🧘‍♂️	47 min	266.3K	Deliberate reasoning and context gathering
LongCat 2.5 Preview 😼	65 min	276.8K	Verification and additional iteration

These numbers come from a single task/run per model, so I wouldn't treat them as a general benchmark of model speed, efficiency, or capability.

They're simply measurements of how these models behaved in this particular workflow.

What I Took Away From This

We've spent a lot of time comparing models based on raw capabilities.

Which model is smarter?

Which model follows instructions better?

Which model writes better code?

But agentic workflows introduce another variable:

How good is the workflow you're giving the model?

A good skill can provide:

Context
Tool usage instructions
A repeatable workflow
Validation steps
Quality criteria
Recovery strategies

And suddenly the model doesn't need to figure everything out itself.

It needs to execute the process well.

That makes the combination of:

Model + Skill + Tools + Verification

potentially much more important than looking at the model alone.

Final Thoughts

This was a small experiment, not a benchmark.

Four models.

One task.

One predefined skill.

But the differences in how they approached the same problem were fascinating.

GLM was fast and focused.

DeepSeek explored and experimented.

MiMo was deliberate.

LongCat iterated.

And despite those differences, they all managed to produce broadly comparable results.

For me, that's the interesting part.

Maybe the future of agentic AI isn't just about finding a smarter model.

Maybe it's also about getting better at telling the model how to work.

TL;DR

🏎️ GLM 5.3 Flash — 28 min / 200.1K tokens
🎨 DeepSeek v4.1 Flash — 29 min / 265.6K tokens
🧘‍♂️ MiMo v2.6 Flash — 47 min / 266.3K tokens
😼 LongCat 2.5 Preview — 65 min / 276.8K tokens

All four performed at least one verification round.

The bigger takeaway wasn't which model was "best."

It was how much a well-designed skill can shape the behavior of very different models.

LongCat 2.5 Preview vs Space Bunny Alpha: My Experience Building Real Projects

Prakhar Yadav — Mon, 28 Sep 2026 10:12:26 +0000

Over the past few days, I've been comparing LongCat 2.5 Preview and Space Bunny Alpha across actual software projects rather than isolated benchmark prompts.

The projects included:

A minimal website with navigation
An enterprise ServiceNow demo instance connected to an internal MCP server used by thousands of engineers and non-engineers
A Chrome extension with complex wiring involving its own backend and UI while also integrating with existing UI components
Homebrew installer development
General automation and scripting tasks

After using both extensively, I found LongCat 2.5 Preview consistently outperforming Space Bunny Alpha in areas that matter during day-to-day development.

1. Context Understanding

The biggest difference was context retention and understanding.

LongCat generally understood project goals, architecture, and previous discussions much faster. It required less repetition and fewer corrective prompts.

Space Bunny often needed additional iterations before it reached the same understanding, which translated into higher token usage and slower progress.

2. Tool Usage and Orchestration

Modern development workflows increasingly rely on tools.

In my experience, LongCat was significantly better at tool calling and coordinating workflows involving multiple tools.

Space Bunny struggled more frequently when several tools were available, occasionally choosing the wrong path or becoming confused about which tool should be used next.

3. Next-Step Recommendations

A surprisingly important capability is recommending what should happen next.

LongCat regularly suggested logical follow-up actions, implementation steps, validation strategies, and improvements without requiring additional prompting.

Space Bunny's suggestions were often generic and required more guidance from me.

4. Architecture Feedback

When discussing system design and architecture, LongCat provided stronger and more actionable recommendations.

It identified improvement opportunities, implementation concerns, and alternative approaches more consistently.

Space Bunny was capable of providing architectural feedback, but the recommendations generally felt less comprehensive.

5. Design Understanding

LongCat also demonstrated a stronger understanding of design intent.

Whether discussing UI flows, product behavior, or implementation trade-offs, it often required fewer prompts to arrive at the desired outcome.

With Space Bunny, I found myself spending more time clarifying requirements and refining prompts.

6. Understanding Intent

One of the less obvious but highly valuable differences was intent recognition.

LongCat frequently inferred the objective behind my request even when instructions were incomplete.

Space Bunny performed adequately, but it required more explicit direction before reaching the same understanding.

7. Handling Roadblocks

Development rarely goes exactly as planned.

When encountering blockers, LongCat was better at proposing workarounds, alternative implementations, and recovery paths.

Space Bunny was more likely to get stuck, make abrupt decisions, or defer the next step back to the user.

Summary

Here's the simplest way I'd describe the experience:

Area	LongCat 2.5 Preview	Space Bunny Alpha
Context Understanding	Excellent	Slower to converge
Tool Calling	Strong	Can struggle with multiple tools
Next-Step Suggestions	Highly actionable	Often generic
Architecture Guidance	Strong	Moderate
Design Understanding	Strong	Requires more prompting
Intent Recognition	Strong	Average
Handling Blockers	Finds workarounds	More likely to get stuck

Final Thoughts

For my specific workflows, LongCat 2.5 Preview felt noticeably more intelligent than Space Bunny Alpha, even when Space Bunny was configured with High Thinking mode enabled.

This isn't a benchmark-driven conclusion. It's based on practical use across real projects involving web development, enterprise systems, browser extensions, automation, and tooling.

Your mileage may vary depending on your workflow, but for development-heavy tasks, LongCat was the clear winner in my testing.

Markdown in ServiceNow: how I made rich work notes easier

Prakhar Yadav — Tue, 16 Dec 2025 14:29:54 +0000

I wanted a better way to write rich notes inside ServiceNow work notes. At work we type a lot of short updates, code snippets, and checklists. The default journal box in ServiceNow is fine, but writing formatted text feels slow and error prone. So I made two things: a small library and a browser extension that uses it.

Links

Library on GitHub: https://github.com/yadav-prakhar/markdown-servicenow
Published on npm: https://www.npmjs.com/package/markdown-servicenow
Browser extension: https://github.com/yadav-prakhar/markdown-sn-extension

Why I built this

I wanted to write notes in markdown and have them appear nicely formatted in ServiceNow journal fields. The goals were simple:

Save time when writing work updates.
Support common markdown like lists, code blocks, bold, italic, and blockquotes.
Keep the output safe for ServiceNow journal format so pasting does not break anything.

I built the library first so the conversion logic is reusable. Then I made a small extension so I can write in a tidy editor and paste formatted output into ServiceNow with one click.

What the library does

The library takes markdown and converts it into markup that can be understood by ServiceNow journal fields. It handles:

Headers, paragraphs, bold, italic
Ordered and unordered lists
Inline code and code blocks
Blockquotes
Tables (basic)
Highlights
Github syle alerts

Element	Syntax
Headers	`#`, `##`, `###`, etc.
Bold	`text` or `__text__`
Italic	`text` or `_text_`
Bold + Italic	`*text*`
Strikethrough	`~~text~~`
Highlight	`==text==`
Inline code	`code`
Code blocks	` fenced blocks
Links	`[text](url)`
Images	`![alt](url)`
Unordered lists	`- item` or `* item`
Ordered lists	`1. item`
Blockquotes	`> quote`
Alerts	`> [!NOTE]`, `> [!TIP]`, `> [!WARNING]`, etc.
Tables	Pipe-delimited tables
Horizontal rules	`---` or `***`

It also takes care of ServiceNow specific quirks so the output shows correctly inside the journal editor.

Sample outputs:

The browser extension

The extension is tiny and focused.

It gives a markdown button below the journal field (comments, work notes, etc.). Once you've typed your markdown, just click it and the text is converted in-place to the journal style entry.
It gives me a small editor pop-up where I write markdown. When I click convert, the extension runs the library, converts the text, and copies the result. Then I paste into the ServiceNow work notes. This saves a lot of clicking and cleanup.
It also has a context menu entry. Just write the markdown → select it -> right click → select Convert Markdown to ServiceNow

Features I built:

Quick editor popup
Live preview of converted output (optional)
Copy to clipboard button
Small settings panel to tweak conversion behavior
Context menu to convert selected text
Button next to Journal field to convert in-place

How to use it (quick)

Install the extension from the repo or load it as unpacked during development.
Open the popup and write your markdown.
Click Convert.
Paste into the ServiceNow work notes field.
Confirm the formatting looks right in the journal.

Before	After

A short technical note

I wrote the library in JavaScript so it is easy to publish on npm and reuse in the extension. The conversion logic is modular, so you can plug it into other tools if you want. I tried to avoid heavy parsing libraries to keep the bundle small.

If you are curious about internals, check the README on GitHub for examples and the small test suite.

What I learned

Small tools solve repeated friction. What took minutes every day becomes seconds.
Writing robust text conversion needs many small rules. Edge cases show up fast.
Packaging a tiny library first made the extension easier to build.

Next ideas

Open to ideas & pull requests if you feel like doing something yourself.

Where to find it

Library: https://github.com/yadav-prakhar/markdown-servicenow
npm: https://www.npmjs.com/package/markdown-servicenow
Extension: https://github.com/yadav-prakhar/markdown-sn-extension

Feel free to open an issue or a PR. If you try it, I would love to hear how you use it or what features you want.

Thanks

Feel free to star the repo if you like it :)
👇 and here's an avatar of me for no reason at all 🤭

🚀 Introduction to Git Worktree (With Oh My Zsh Aliases)

Prakhar Yadav — Mon, 17 Nov 2025 05:12:06 +0000

If you’ve ever had to switch branches in the middle of work, stash your changes, or juggle multiple clones of the same repository… you already know the pain.

Good news: Git Worktree makes all of this much easier.

This guide will introduce:
• What Git Worktree is
• What Oh My Zsh is (and why its aliases help)
• Real workflows for single-repo apps
• Real workflows for monorepos

Let’s make your Git life smoother and your workflow faster. ✨

🌱 What is Git Worktree?

A Git worktree is a feature that lets you check out multiple branches of the same repo at the same time — each in its own folder.

Think of it like having multiple “workspaces” linked to the same Git repository.

Why use it?
• No need to clone the repo again
• No need to stash or reset your local changes
• You can develop, test, or review PRs in parallel
• Saves time and disk space
• Cleaner workflow

Example:
You’re working on feature/homepage-redesign but your teammate asks you to check hotfix/login-bug.

Instead of stashing everything:

git worktree add ../login-hotfix origin/hotfix/login-bug

Boom — a new folder opens up with that branch, while your original branch stays untouched.

🌀 What is Oh My Zsh? And Why Are We Talking About It?

If you use Zsh (default shell on macOS), then Oh My Zsh is like a power-up.

It’s a framework that adds:
• Useful plugins
• Completion
• Themes
• Shortcuts
• And… Git aliases that save a LOT of typing

Instead of typing:

git worktree add ../some-folder feature-branch

With the Oh My Zsh git plugin, you can type:

gwta ../some-folder feature-branch

Here are the key aliases for Git Worktree:

Alias	Full command	Meaning
`gwt`	git worktree	Base command
`gwta`	git worktree add	Add a worktree
`gwtl`	git worktree list	List worktrees
`gwtr`	git worktree remove	Remove worktree
`gwtp`	git worktree prune	Remove stale entries

To enable it, make sure your .zshrc has:

plugins=(git)

Reload:

source ~/.zshrc

And you’re set.

⚙️ Workflow Scenario 1 — Single-Repo App

Let’s say you have a normal project:

my-app/
  src/
  package.json
  ...

You’re working on a big feature:

feature/new-ui

But someone needs your help reviewing:

feature/navbar-fix

Instead of stopping your work:

➕ Add a worktree

gwta ../navbar-fix-wt origin/feature/navbar-fix

Now you have:

my-app/                  ← your main work continues here
navbar-fix-wt/           ← completely separate workspace

👇 Inside navbar-fix-wt/
• Open code
• Run tests
• Try builds
• Review changes

When done:

gwtr ../navbar-fix-wt

Back to your original branch, untouched.

🔥 Why this is awesome
• No stashing
• No losing uncommitted changes
• No slow clones
• You can have 3–4 worktrees open if you want

🏗️ Workflow Scenario 2 — A Monorepo with Multiple Apps

A common setup:

company-monorepo/
  apps/
    web/
    admin/
    mobile/
  libs/
    ui/
    utils/

Now imagine you need to:
• Work on web-app-feature
• Test something in admin
• Also prepare a PR fix for mobile

Instead of checking out branches back and forth:

1️⃣ Create worktrees for each branch

gwta ../wt-web-feature web-app-feature
gwta ../wt-admin-experiments admin-dashboard-refactor
gwta ../wt-mobile-fix mobile/login-crash

Folder layout becomes:

company-monorepo/           ← your main repo
wt-web-feature/
wt-admin-experiments/
wt-mobile-fix/

Each folder is:
• A checkout of a different branch
• Still shares the same .git data
• Fast to create (no re-cloning!)

2️⃣ Work in each independently

cd ../wt-web-feature
npm run dev:web

cd ../wt-admin-experiments
npm run dev:admin

cd ../wt-mobile-fix
npm run dev:mobile

Yes, you can run multiple apps side-by-side — perfect for monorepos.

3️⃣ Clean up when you’re done

gwtr ../wt-web-feature
gwtr ../wt-admin-experiments
gwtr ../wt-mobile-fix

🎯 Final Thoughts

Git Worktree is one of those features that feels small but saves huge amounts of time once you start using it.

Combined with Oh My Zsh’s aliases:
• Faster workflows
• Cleaner development environments
• No more “stash → switch → test → switch back” loop
• Perfect for multitasking across branches
• Perfect for monorepos where multiple apps run at once

If you work on anything slightly complex - frontend frameworks, backend services, monorepos (& ServiceNow apps in my case) - Git Worktree is a superpower 💪

Easy Callback, Promises, Async-Await

Prakhar Yadav — Sat, 28 Aug 2021 22:05:36 +0000

After having read about callbacks, promises & async-await multiple times in not so easy to comprehensions, I finally have wrapped my head around them.
And today I'd share it in simpler terms that I am able to remember & understand.

Callbacks

Callbacks are functions being passed as arguments. That's it. That doesn't satisfy you then read these one page articles (to arrive on same conclusion of course):

Promises:

functions that are not run sequentially. They are run when possible.

const fun = new Promise ((resolve, reject) => {
  if(<some condition>)
    resolve("some success message");
  else
    reject("some failure message");
});


fun()
  .then(msg => console.log(msg)) // some success message
  .catch(msg => console.log(msg)); // some failure message

Resolve is called to indicate & return success status of the Promise, & Reject is called when we need to show failure.

Once returned we need to handle the stuff as well right?

then() is used to handle the resolved state
catch() is used to handle the rejected state

See! Simple.

Async - Await

Just a wrapper around Promise. Async-Await use Promises in the background.
Why was this done?
Because sometimes developers tend to nest things up. Nesting Promises makes it difficult to write, read, follow & understand at one look.

So why not make it easy to read & understand.

const fun = async () => {
  await functionToPerformAsynchronously();
}

That easy. You can easily make any function run asynchronously, by appending a await before it. Just remember that await statement must be in a function declared as async.

And you know what! async functions are nothing but promises (well not really; they return promises).

Don't confuse yourself, just read along and find more detail in the links mentioned at the end.

Which is why you can do this:

const fun = async () => {
  await functionToPerformAsynchronously();
}

fun()
  .then(<whatever you want to do here>) //runs when fun() has run successfully and did not encounter any issue while it ran
  .catch(errorMsg => console.log(errorMsg)); // runs when fun() had some problem running. We can display the problem as an error message is returned & can be displayed like in this example.

Want to dig deeper?

Here are one of the best & easy to follow official Node documentation on each one of the three:

Determine the kind of Software

Prakhar Yadav — Fri, 27 Aug 2021 20:06:06 +0000

Iterative approach effect on prerequisite

Different kinds of software projects need different balances between preparation and construction.

(scroll to the Appendix at the end to see some good practices for common kind of software practices) 👇

Some projects need iterative & some need sequential approach.

A misinformed opinion is that iterative techniques don't need to focus on prerequisites.
However in reality, Iterative approaches only tend to reduce the impact of inadequate upstream work, but they don’t eliminate it.

Example table below compares 2 approaches with respect to prerequisites. Approach 1 relies solely on testing & discovers defects later, making the cost higher, and Approach 2 discovers defects iteratively as the project progresses.

Skipping Prerequisites	Focusing on Prerequisites

A focus on prerequisites can reduce costs regardless of whether you use an iterative or a sequential approach.

Most projects are neither completely sequential nor completely iterative. It isn’t practical to specify 100% of the requirements or design up front.

One common rule of thumb is to plan to specify about 80 percent of the requirements up front, and then practice systematic change control to accept only the most valuable new requirements. Another alternative is to specify only the most important 20 percent of the requirements up front and plan to develop the rest of the software in small increments.

How to choose between Iterative and Sequential Approaches

You might choose a more sequential (upfront) approach when:

requirements are fairly stable.
design is straightforward and well understood.
development team is familiar with the applications area.
project contains little risk.

You might choose a more iterative (as-you-go) approach when:

requirements are not well understood.
design is complex.
development team is unfamiliar with the applications area.
project contains a lot of risk.

Appendix

Table: Good practices for 3 common kinds of projects

Importance of prerequisites

Prakhar Yadav — Thu, 24 Jun 2021 22:15:12 +0000

Paying attention to quality is also the best way to improve productivity. We do this by adopting high quality practices which emphasize quality at the beginning, middle & end of the project.
Emphasizing quality at the beginning implies you plan for high quality product, require high quality product & design a high quality product.
Emphasizing quality in the middle of the project means emphasizing on construction practices.
Emphasizing quality at the end of the project means emphasizing on system testing.

Upstream activities, i.e. architecture, design, and project planning can be done well. Projects will run best if appropriate preparation activities are done before construction begins.
Goal of preparation is to reduce chances of risk as early as possible. Common risks are poor requirements and poor project planning. Hence preparation tends to focus on improving requirements & project plans.
(specific approach to risk reduction must be decided project by project).

WIMP syndrome

Lack of planning can often be attributed to team's leadership. This is often due to WIMP Syndrome of managers. Why isn't Mary Programming?

If your manager happens to be such brigadier general and orders you to start coding right away, it's easy to say "Yes sir!" But that's a bad response, and you have several alternatives:
i.   You can flatly refuse to do work in an inefficient order, that is iff your relationship with your boss & your bank balance are healthy enough.
ii.   (Ethically questionable) Pretend to be coding. Put an old program listing in the corner of your desk (or opened somewhere in your screen) then go right ahead and develop your requirements & architecture with or without your boss's approval. You'll do the project faster with better quality results.
iii.   You can educate your boss in terms of technical projects & how/why planning beforehand will be better.
iv.   Find another job.

Compelling & Foolproof arguments for doing prerequisites before Construction

This section will help you deal with bosses who have not seen the light yet. Learn the argument & then sit down with your boss for a heart-to-heart discussion.

Appeal to Logic - plan before building Big projects require more planning; small projects need less. From management point of view, planning means determining amount of time & people the project will need. From technical point of view, understanding what you want to build, so that you don't waste money/time/resources building the wrong thing. Sometimes users aren't entirely sure what they want at first, so it might take effort in finding what they really want. That's cheaper than building the wrong thing and throwing it away to start anew. It's also important to know how to build the system before starting to build it.
Appeal to Analogy - do things in the right order Building software is similar to any other project. If you make a house, you make architectural drawings & blueprints before pounding the nails. You don't start decorating a Christmas tree before putting it in a stand. You don't get dressed before you take a shower. You don't put on shoes before wearing your socks. Things need to be done in order. If any impurity is introduced in the beginning it'll contaminate the complete food chain. In programming, if your requirements are contaminated, they'll contaminate the architecture which in turn will contaminate the construction & hence will lead to radioactive polluted software along with a malnourished grumpy programmer. You don't want that.
Appeal to Data - speak stats for proof The principle is to find an error as close as possible to the time it was introduced. The longer the defect stays in software food chain, the more is the damage it causes further down the chain.

Time introduced x Time detected	Requirements	Architecture	Constriction	System Test	Post-release
Requirements	1	3	5-10	10	10-100
Architecture		1	10	15	25-100
Construction			1	10	10-25
Architecture		1	10	15	25-100
Construction			1	10	10-25

Table: average cost to fix defects based on when they're introduced & detected (units in multiples of $1000)

Measure Twice, Cut Once: Upstream Prerequisites - Introduction

Prakhar Yadav — Thu, 24 Jun 2021 21:35:32 +0000

Before you begin construction of software, you need to prepare for it.

And preparation is tailored to the specific project.
The carpenter's saying, "Measure twice, cut once" is highly relevant to software development as it is in any other form of craftsmanship. Doing the most expensive part of the project twice is a bad idea.

This chapter lays groundwork for construction phase, without discussing construction directly (which will be discussed in chapter 5). Here we will discuss various prerequisites before construction.

Here is the chapter's layout:

Importance of prerequisites: cost of not doing prerequisites
Determine the kind of software you're working on: how prerequisites apply to your situation
Problem-definition Prerequisites: recognize written problem statement & if it is a good foundation for construction
Requirements Prerequisites: importance of clear requirements & how to handle change in requirements during construction
Architecture Prerequisites: how to determine the quality of existing architecture
Amount of time spent on Upstream prerequisites: time management in upstream activities (requirements, architecture, design, planning)

Code Complete Mini Notes

Prakhar Yadav — Thu, 24 Jun 2021 20:39:33 +0000

What?

I have started reading one of the most recommended books for software development, Code Complete (2nd ed.) that suggests best practices in the industry and talks about development journey from A-to-Z. Covering almost all the aspects of software development philosophy. But have you looked at the size of it!!!?

Yeah! Get a load of this bad boy.

Why?

Due to day to day work not many of us get enough time to read a book, let alone a book of this volume. I often find myself wishing if only people would write the summaries of books that they had been reading. It would speed things up a bit and time restricted people can also catch up with many literature.

So I for one am starting a series on it. I will be capturing the notes that I make along the way in easy words that will make it quick for people to go through the crux of the book.

How?

I'll start with Chapter 3 (which is where the real stuff begins) at first and move along, since chapter 1 & 2 discuss the philosophies initially. I plan on covering them at a later stage.

Every post may be a subtopic of one huge chapter. The banner image of each post will highlight which chapter does the topic belong to, and also the 1st post that begins a chapter will have the 1st line as description of the same.

I hope whoever plans on reading this finds it easy & convenient. I'm open to suggestions on how this can be improved.

p.s. Don't worry, I won't be leaving out much part.

List:

Chapter 3: Measure twice cut once - Upstream prerequisites

Resources for enthusiasts - software dev. & cybersecurity

Prakhar Yadav — Thu, 17 Jun 2021 11:15:19 +0000

Hey folks. Tell me if this happens to you as well.
I find myself often torn up between my interests in web development and cybersecurity. I try to learn stuff in both the paths but it becomes very exhausting.
Sounds familiar?

When it comes to learning, multitasking is not really a friend. Better progress is made when we pick up one thing and achieve the target. But the FOMO (fear of missing out) on the other thing distracts too much.

To deal with this, I at least try to stay up-to-date on the latest developments, outside of my learning time, through podcasts, news-boards & twitter.

Here are my go-to resources for cybersecurity:

These podcasts and articles are the ones that help me & I hope you find them helpful as well.

Interview Prep suggestions & resources

Prakhar Yadav — Fri, 11 Jun 2021 22:01:09 +0000

I have had the opportunity to get in touch with some of the great minds and gather their advises when I was preparing to get in tech companies. And I want to hold the torch while others go through the same phase in their lives.
In this article I want to share my interview preparation experience and some resources for anyone who is or will be going through the same.

Interview is not all about coding, hence the preparation for the same should not be.

You have to take into consideration all the parts involved, like:
1. Coding practice
2. Presentation skill
3. Rejection coping mechanism
4. Your expectations
5. Questions you should ask

1. Coding Practice

When it comes to coding, my go-to source is Leetcode. This is simply one of the most preferred practice sites and it has everything that you need. There are certain topics that are must do to be worthy enough in appearing for interviews. Trees, Graphs and Dynamics Programming. These are the deal breaker in many interview. Mind you, these are the ones that one must know well, after one has gone through basic data structure problems (arrays, linked list, stack & queues).
I have climbed the stairs in this order:
Arrays -> LinkedList -> Stacks -> Queues -> Hash table -> Trees -> simple problems on Backtracking -> Dynamic Programming
In between I also covered some String problems as well.
You can select a topic. Solve 5 problems daily (10/15 if you're planning a rigorous prep duration). And move from easy to medium. It's easy to follow. Trust me. Don't be overwhelmed. You got this.
In only 2 to 3 weeks you'll get a hang of it and know how and where to proceed.
You should also keep track of top questions list. These are found on the right side column.

Oh don't forget this page This should be you one stop shop for the coding practice guide.
You'll find links to most preferred articles that'll guide you how to approach certain type of problems.

Like this article will build your understanding of Dynamic Programming problems & how to think about them.

2. Presentation

This involves your body language, behavior, asking questions, think out loud, how to proceed if you are unable to think of a clear solution.
Radiate positive energy. Stay hopeful and cherish the time you are having. Being nervous is natural. But I took this advise from Simon Senek.

Signs of being nervous and excited are exactly the same. Your hands may shiver & sweat. You feel that adrenalin rush. You are alert.

Tell yourself that you're excited, and soon enough you'll hack your brain into believing it.

Then comes the behavioral part. You don't need to be extremely formal. You can keep your conversation lite and fun, while being respectful all the time. After all you are talking to someone who might be your future colleague. And he's human too. Don't sweat it. I always keep conversations lite and push in some funny responses. This will help you too. Trust me.
You will literally hijack the conversation and keep it in your control.

Whenever you are given a problem to solve, don't dive into depths of your mind to find the solution. Stay in the moment. Ask questions regarding the problem.

What is the size of the input? Is it an integer or can it be a string as well? In which format do we want the output?

Think of the interviewer as a colleague/friend with whom you are solving this problem. Ask for hints if needed.

Think out loud. Be vocal while you think of how to proceed. This will help them understand how you approach the problem and how your brain is functioning.

Hmm.. I'm thinking of storing the pair in a set. That may help us in fast retrieval/finding whether we have seen this before during the traversal.

How to proceed when unable to think of a solution?
There might be times when you have a faint idea but are unable to arrive at exact solution. You can just go ahead and ask for hints. If that doesn't help, communicate that little idea that you're having.

I'm unable to think of a good or exact solution, but I know that this can be solved using memoization.

Or you may not have any clue of the situation. Convey that even after thinking you were not able to think of a solution, because what all you know does not seem to apply in this particular problem. Don't beat around the bush for too long if you don't know what's asked. The interviewer will know when you'll try to bluff.

3. Coping from rejection

It's not necessary that every stone you throw, will bounce off the lake. Some are throws are just for trial.
Consider that you tried your best. Note down the points that you were unable to tackle. Work on them the next day. If you face multiple rejections in a day, or back to back rejections in consecutive days, then take a break. Calm yourself down. Be in peace. Meditate. Listen to songs. And most of all, talk to people and your friends. Make fun of the situation if you can. Have a lite laugh.
Remember, it's a small part of you big life, and this too shall pass. Destiny will take it's course and you'll be somewhere that you are supposed to be. This might be the learning phase to get there.
Diamonds are made when coal is exposed to immense heat & pressure.
You got this. Let's enjoy this time while it lasts.

4. Expectations

While done with the technical part of the interview, remember to reflect on your expectations of the job & the employer's expectations from you. Ask them what kind of skills, performance and attitude they expect from their employees. Ask them how they treat the people who meet those expectations. Explain what you're expecting in turn. This will help you and your employer understand the kind of dynamics you might have and whether or not you'll be suitable for this position. You might feel that you should not go for this... then listen to that gut feeling as well.

5. Questions you should ask

Finally you made it through all the parts of the interview. Congratulations 🎊 😄
Remember to ask a few questions:

What does the average day look like for an employee here?

How is the workload?

Do you get time for your family and friends?

How are troubling situations handled like sudden failure that needs to be addressed right away?

Suppose in distant future if I feel like changing my domain, say from web development to cyber security. Is there a provision to entertain such domain change? How difficult is it?

What is the performance expectation from an employee?

Is it a 6 days work week or 5 days work week?

BONUS: Resources

Finally I'll mention some links to resources that were helpful for me while preparing for interviews:

Leetcode : for coding practice.
GeeksForGeeks : for CS subject concepts, Design Patterns, coding (some must do questions here).
Pramp.com : for free mock interview practice with friends.
Design Patterns lectures on Coursera.
System Design youtube playlist by Gaurav Sen.
Puzzles from GeeksForGeeks as well.
Aptitude problems from Indiabix.

4 Git Habits & curated list of life-saving articles

Prakhar Yadav — Sat, 05 Jun 2021 13:14:52 +0000

Hi folks.
In this post I want to share some tips and suggestions on common best practices for the method of work, that are not always explicitly stated/taught.
When we transition to a new environment, there's a certain learning curve involved before we get on with our work smoothly.
I struggled with my modus operandi and after tripping on many pitfalls, I think these tips might be of help:

Don't branch when you start working. Branch when need to push.
I've had situations where I faced merge conflicts due to early branching. You don't know how long its gonna take for you to fix that defect or complete that story. By the time you are ready to push the changes to remote repository, there might be significant changes in many files. And may be even on the one that you're working on. This is typically the case when many teams are working on a repository. Hence, always create a branch to push your code when you are actually ready to push.
Pull every morning. Keep the code base up to date
Branching off of the previous comment, keeping the code base up to date is ofcourse very essential, but the frequency is what matters. I had this question when I started in my new role "how often should I pull?"
The answer is every morning. Don't worry you won't lose your work. And if you're unable to, because of un-committed changes, then stash your things are apply them after you've pulled.
This way, you can lift-off from where you ended yesterday.
Always sign/author your commits, if you don't.
Although some organizations have some guidelines regarding this, but that might not always be the case. Even though the organization has a way to keep track of who's changed what, it's always advisable to author your commits.
I prefer ending the commit message with:
Reviewed by: Reviewer Name <email@addre.ss>
Signed-off-by: Your Name <your@email.id>
Squash all your commits into one once you're done.
This is something you must be aware of already. Squash all your commits before merging. This way all the code changes for a fix/feature are consolidated into one, and the whole thing is much clearly maintained and tracked.

These are the few things I learned the hard way. I hope you adopt these habits soon if you don't already.
Before signing-off, below are some guides and articles in Bonus section, that I find very useful & you might too.
And even though cats may rule this world one day, you are reading Code with P. 👋🐈

BONUS - Resources

Git Crash Course by eclipse/omr project at github.com
What is Git Stash, how to use Git Stash? by @Yuvaraj
Top 10 Git Commands Every Developer Should Know By @Muthu Annamalai Venkatachalam
Confusing Terms in the Git Terminology by @Pragati Verma
Most practical git commands in a real workflow by @Jing Gu
What is Commit Signing in Git by Seth Falco