DEV Community: Rufat Khaslarov

Learn How To Run Meetings as a Professional

Rufat Khaslarov — Sun, 06 Jul 2025 10:55:19 +0000

Rufat Khaslarov

Jul 6 '25

Run Meetings Efficiently with the GROW model

#management #leadership #productivity #community

Comments

3 min read

Run Meetings Efficiently with the GROW model

Rufat Khaslarov — Sun, 06 Jul 2025 10:54:53 +0000

Typically, as engineering managers, we spend at least a half of a day on various meetings. It might be one-to-one meetings, project status, escalation or meetings with stakeholders. Therefore, better off being well-prepared, since without the specified structure, any meeting is worthless.

I don’t intend to describe the lifehacks, tips for efficient meetings, like setting up an agenda, sending out invites, and things like that. I want you to understand the structure of meetings, including the questions to be addressed and the expected outcomes.

The GROW model is widely spread in the business world because it is unquestionably not rocket science; it’s straightforward, based on logical principles that managers apply on a daily basis.

Let’s roll and see how GROW principles work in a 1–1 meeting with your teammates.

Goal.

There’s nothing better than achieving your goals, whatever they might be.

At the beginning, all attendees should define meeting goals. There’s a fine line here: ALL attendees should be proactive at this point, since if each of them (at least, some of them) suggests goals, they will take responsibility for realization. Moreover, being on the same page from the start will save your time from unnecessary conflicts/resistance later on.

Getting back to our case. Usually, in 1–1 meetings, people do not know where to start. The meeting is merely scheduled in the calendar, and OMG, you have to cope with it.

First off, try to find common ground with your teammate; set up what your team member wants to carry out at the beginning of a meeting:

What problems do they have?
What are their plans for the next quarter?
What questions do they have in mind?

Gather as much information as possible, and then put it all together and define goals. For instance, an employee asked to be compensated for their professional education. So, now the goal is found.

Reality.

Reality is frequently inaccurate.

To figure out where to go, you should know where you are. Again, all attendees should clearly understand the current state, resources, limitations, useful contacts, and anything that might help to achieve goals faster than ever.

As a manager, you should listen carefully to each teammate and stop unnecessary discussions.

In our scenario, you should definitely explain:

How does the compensation process work?
What financial/time limitation does it have?
What artifacts do you need from the teammate's side?
Who is in charge of it?

Options.

I may be running out of options, but running out isn’t an option.

At this moment, we collectively know what to solve and what the current state is. So, we’re really craving for the ways HOW to deal with it (aka “options”).

That’s the brainstorming phase, when attendees try to generate as many options as possible to achieve goals. A manager moderates the focus of discussions without unhealthy criticism.

After you explain the compensation details, you should generate options together with a teammate. For instance, since there's a financial limitation, you could suggest paying off half of a course price or explain how internal education in a company works; probably, they’d have a course inside.

Will.

Your will shall decide your destiny.

It’s time to decide and act. At this stage, attendees choose options that are suitable for the current goals. Options that would help to achieve them with minimal effort and maximum efficiency.

Each attendee takes responsibility for a concrete action item. At the same time, you as a host should give priorities, deadlines, and other details.

Next actions for our scenario. A teammate has to give you the invoice from a course that is the proof for the accounting department. After that, you have to send an official email with the attached invoice and confirmation from your side.

Conclusion.

There’s nothing better than structure and conscious attention. We’ve just looked at GROW principles, the instrument that should be in your tool belt of an amazing engineering manager.

And never forget, the principles make sure that nothing prevents a team from reaching its goals, and you, as a manager, should lead them in that way.

Thanks for reading, and good luck!

If you missed it, use-case of using Knip.

Rufat Khaslarov — Fri, 04 Jul 2025 09:35:26 +0000

Rufat Khaslarov

Jun 29 '25

How I Cleaned Up Our Codebase With Knip, And Why You Should Too

#javascript #programming #webdev #react

Comments 4

3 min read

Utilizing Knip to remove unnecessary dead code

Rufat Khaslarov — Sun, 29 Jun 2025 12:13:18 +0000

Rufat Khaslarov

Jun 29 '25

How I Cleaned Up Our Codebase With Knip, And Why You Should Too

#javascript #programming #webdev #react

Comments 4

3 min read

Say goodbye to dead code with Knip! My journey...

Rufat Khaslarov — Sun, 29 Jun 2025 11:14:10 +0000

Rufat Khaslarov

Jun 29 '25

How I Cleaned Up Our Codebase With Knip, And Why You Should Too

#javascript #programming #webdev #react

Comments 4

3 min read

How I Cleaned Up Our Codebase With Knip, And Why You Should Too

Rufat Khaslarov — Sun, 29 Jun 2025 11:12:47 +0000

At some point, every fast-growing codebase becomes messy.

In our case, things changed quickly. Features were evolving, old logic was being refactored or replaced, and more than 30 engineers were pushing new code daily. It didn’t take long before we realized: we were sitting on a mountain of dead code.

For sure, during the refactoring we cleaned up a bunch of code, but not every line can be found by a human. In outcome, I decided to clean it up automatically.

Step One: The Easy Wins
My first instinct was to start with the low-hanging fruit aka unused files. A couple of years back, I integrated unimported, a sweet little tool that analyzes your project and tells you what files aren’t being imported anywhere.

{
  "entry": ["./src/index.ts"],
  "rootDir": "./src",
  "aliases": {
    "atoms/*": ["./atoms/*"]
  },
  "ignorePatterns": [
    "**/node_modules/**"
  ],
  "ignoreUnimported": [
    "src/file-to-be-ignored.js",
  ],
  "ignoreUnused": ["npm-package-to-ignore"]
}

It’s fast, customizable, and worked like a spell.

Additionally, we heavily used WebStorm; its dead code highlighting is honestly the best I’ve ever seen in an IDE. But then came the Cursor era.

We started migrating to Cursor (based on VS Code), and suddenly our best tool in the war against unused code was gone. As much as I love VS Code’s extensibility, its native dead code detection just did not work out for us.

Also, turning on the eslint rules ahead of time turned out to be helpful. @typescript-eslint/no-unused-vars and no-unreachable saved us from keeping disorder that would otherwise go unnoticed. Static analysis is our first line of defense against dead code.

So, I went hunting for options.

When ts-prune Wasn’t Enough

I revisited ts-prune, an old favorite that identifies unused exports and code in TS projects. While it still works well, it’s officially in maintenance mode and I’m not a fan of building tooling workflows around deprecated packages.

That’s when I fell on something better: Knip.

Meet Knip: The Dead Code Terminator

Knip didn’t just impress me, it blew me away.

It’s more than a dead code detector. Knip is a comprehensive code hygiene tool with support for:

Unused files and exports;
Unnecessary dependencies;
Missing dependencies;
Monorepos and workspaces support;
Unused class members, enum members, duplicate exports and so on.

What truly makes Knip powerful is its plugin-based architecture. It understands a wide variety of frameworks, libraries, test runners, and build tools out of the box. So instead of spending hours writing a config file, you can usually just run it and get instant insights.

Here’s the configuration sample:

{
    "$schema": "https://unpkg.com/knip@5/schema.json",
    "project": [
      "src/**/*.{js,cjs,mjs,jsx,ts,cts,mts,tsx}!"
    ],
    "entry": [
      "src/index.ts"
    ],
    "typescript": true, // TS plugin is enabled
    "ignore": [
      "src/file-to-be-ignored.js"
    ],
    "rules": {
      "exports": "error",
      "files": "error",
      "unlisted": "warn",
      "dependencies": "off",
      "types": "error",
      "binaries": "off",
      "enumMembers": "warn"
    },
    "tags": ["-knipignore"]
}

After integrating Knip and hitting zero dead code (removed around 3.5k lines of code at once), I immediately added it to our CI pipeline. I was really impressed by how fast it is. Even with our huge code base, it only takes a few seconds to run through all the rules and checks with Knip.

Why You Should Care

If you’re wondering why any of this matters, here’s the TL;DR:

Dead code slows you down. Every unused file, dependency, or export increases your build time, and makes onboarding harder.
Dead dependencies are a liability. If you’re importing code from a dependency of a dependency, and you’re not declaring it directly, your code might break without warning when transitive dependencies change.
Cleaner code means fewer bugs. And fewer bugs mean happier developers.
Psyhological satisfaction. Deleting code is just so amazing! 😋

Final Thoughts

Now Knip runs with every pull request and protects our codebase from regressing into spaghetti.

If your project is more than a few months old, you’ve probably got a few things hanging around that you just don’t need anymore, right?

Knip won’t just help you clean it up, it’ll keep it that way, it’s a process already.

Give it a shot. Thanks for reading.

Support Original Article: https://medium.com/javascript-in-plain-english/how-i-cleaned-up-our-codebase-with-knip-and-why-you-should-too-1aa9d5152659

Quality often becomes the last thing on our minds, both for individuals and companies, even though we swear to value it. And here it is why?

Rufat Khaslarov — Sun, 11 May 2025 17:35:28 +0000

Rufat Khaslarov

May 9 '25

Next time you think quality is optional — STOP, and read this before it’s too late!

#programming #startup #architecture #testing

Comments

4 min read

Quality often becomes the last thing on our minds, both for individuals and companies, even though we swear to value it. Why?

Rufat Khaslarov — Sat, 10 May 2025 13:42:46 +0000

Rufat Khaslarov

May 9 '25

Next time you think quality is optional — STOP, and read this before it’s too late!

#programming #startup #architecture #testing

Comments

4 min read

Quality often becomes the last thing on our minds, both for individuals and companies, even though we swear to value it. Why? Let's explore it together!

Rufat Khaslarov — Fri, 09 May 2025 13:55:54 +0000

Rufat Khaslarov

May 9 '25

Next time you think quality is optional — STOP, and read this before it’s too late!

#programming #startup #architecture #testing

Comments

4 min read

Next time you think quality is optional — STOP, and read this before it’s too late!

Rufat Khaslarov — Fri, 09 May 2025 13:55:26 +0000

Quality often becomes the last thing on our minds, both for individuals and companies, even though we swear to value it. Why? Because quality can feel dull, complex, and time-consuming.

As software engineers, we really enjoy building new features and cleaning up our code, but honestly, not many of us can get happy about writing tests or dealing with bugs. And even having powerful AI tools in our toolbelt, we still tend to skip the tiresome parts.

Over and over again, I’ve seen engineers rejecting bugs because they seemed “non-critical” or because the original reporter went off, so the issue obviously “fixed itself,” right? We ignore coverage metrics and carry on, hoping nobody notices. And often, it takes someone from the top or an external powerful enforcer to set up standards and make us do the right thing.

What Does “Quality” Really Mean?

But what exactly is “quality,” and why do we struggle to agree on it? The truth is that each of us sees quality through our own lens, and in many contexts, we can all be “right.”

Let’s take a look at some historical examples to see just how different things can be!

RAF Aerial Bomb Quality Control.

When WWII is started, Britain’s bombs were pretty unreliable, with about 40% of them failing to go off. It was mainly because of some faulty fuses and issues with how they were made.

By 1943, they used some pretty clever tools for putting together fuses, like precision jigs, and they got smart with testing too, using statistical sampling and test drops.

They also had these go/no-go gauges and did daily checks on the production line. All this helped cut down the fail rates to under 10%, which really improved the reliability of the bombs.

NASA and FMEA.

On January 27, 1967, a fire in the Apollo 1 cabin during a ground test tragically took the lives of all three astronauts. After looking into what went wrong, investigators found a ton of potential issues with the electrical wiring, materials, and procedures.

NASA implemented Failure Mode and Effects Analysis (FMEA) and increased inspections of their suppliers for all components, including life-support hoses and circuit breakers. They listed potential failures, rated their severity and likelihood, and then adjusted the designs or procedures to address the issues. Does it look like bug tracking?

Quality as a Mindset

From these stories, it’s clear that quality isn’t just bug fixes, writing tests, or doing code reviews. Quality measures how well our product meets and exceeds, our customers’ expectations. But how can a single engineer in a development team truly understand those expectations?

“If I were given one hour to save the planet, I would spend 59 minutes defining the problem…” — Albert Einstein

Imagine a small healthcare startup whose mission is to automate life-saving prescriptions for heart-attack patients. In their rush to deploy new features, a bug sneaks into production. Suddenly, dozens of patients receive incorrect prescriptions, severely affecting their health and safety. Isn’t that as catastrophic as a bomb explosion on the factory line?

Quality isn’t simple — it’s a mindset.

It’s all about:

Getting to know our users and what they really need;
Taking responsibility for the real-world impact of our software.
When we move from “just ship it” to “ship it right,” we make quality a priority instead of an afterthought.

Everyone’s Responsibility

By shifting quality left, we move all quality-related activities into the earliest stages of the software delivery lifecycle. As a mantra, we should do everything necessary to meet the customer expectations that truly matter. From the very first idea to the moment code reaches production, multiple teams and individuals share responsibility here:

Product managers ensure if we’re solving the right problem.
UX designers make the solution intuitive and accessible.
Engineers implement changes thoughtfully, write tests, raise concerns, and avoid blindly following orders.
Support teams step in whenever a defect slips through, helping our users and restoring their confidence.

It’s a long journey from concept to deployment, and every role plays a critical part — because quality is everyone’s business. This approach can be summed up as prevention over detection.

My Last Shout-out!

Finally, a shout-out to your QA engineers — they’re not there just to slow down your delivery 😉. They should focus on solving problems every day rather than going throigh the morning task list.

True quality engineers design and implement quality controls, conduct audits, measures the costs tied to quality (both the wins and the risks), capture the data needed for smart decisions.

Give them the freedom, they will give your product the future.

Thanks for reading!

Original post: https://rufat-khaslarov.medium.com/next-time-you-think-quality-is-optional-stop-and-read-this-before-its-too-late-cca7beed8bc7

❤️ If you enjoyed this post, you can buy me a coffee: ☕️ Buy me a coffee

I've been thinking a bit about my dream team, and I’d love to hear your thoughts too! What makes team successful?

Rufat Khaslarov — Sun, 04 May 2025 04:51:30 +0000

Rufat Khaslarov

Apr 27 '25

The Four Pillars of a Dream Team

#programming #leadership #hiring #career

Comments 2

3 min read

Dear community! Updated the article to include the latest report.

Rufat Khaslarov — Wed, 30 Apr 2025 07:57:05 +0000

Remote vs. Hybrid vs. In-Office: How to Decide?

Rufat Khaslarov ・ Apr 29

#leadership #management #hiring #discuss