DEV Community: 💻 Arpad Kish 💻

Profit vs. Principles: The Fracture Between Personal and Business Morality

💻 Arpad Kish 💻 — Tue, 22 Sep 2026 12:03:47 +0000

We navigate the modern world using two distinctly different moral compasses. In our personal lives, our morality is governed by empathy, vulnerability, and mutual care. We are taught to be selfless, to forgive, and to prioritize the well-being of others. Yet, when we step into the marketplace, the compass flips. Business morality is traditionally governed by pragmatism, contractual obligation, and the pursuit of profit.

While both systems function perfectly well in isolation, the modern world frequently forces them to collide. When the rules of commerce are applied to human relationships—or when the expectations of personal loyalty are weaponized in the workplace—a critical line is crossed.

The Two Architectures of Morality

To understand where the line is crossed, we must first look at how these two moral architectures are built.

Personal morality is intrinsically unconditional. Whether dealing with family, friends, or romantic partners, the foundation is trust. If a friend makes a mistake, the moral imperative is to offer grace and support. The "ROI" (Return on Investment) of a friendship is irrelevant; we give our time and emotional labor because human connection is an end in itself.

Business morality, however, is transactional and conditional. A corporation’s primary fiduciary duty is to its shareholders or owners, meaning its core moral imperative is self-preservation and growth. Trust exists, but it is verified by contracts, non-disclosure agreements, and performance reviews. If an employee makes too many mistakes, the moral imperative of the business—protecting the livelihood of the company—dictates that the employee must be let go.

Neither system is inherently evil, but they operate on completely different frequencies. One optimizes for human flourishing; the other optimizes for efficiency and scale.

Crossing the Line: When the Compasses Malfunction

The ethical friction occurs when one sphere attempts to co-opt the language and leverage of the other. This "crossing of the line" typically manifests in three dangerous ways:

1. The "We Are a Family" Fallacy

Perhaps the most common transgression in modern business is the corporate assertion that "we are a family." This rhetoric deliberately borrows the moral weight of a personal relationship to extract disproportionate loyalty from employees.

When a company frames itself as a family, it creates an implicit expectation that employees should work late, sacrifice personal time, and accept lower pay out of "devotion." However, when economic times get tough, the company will conduct layoffs—an act a true family would never do to its members. Using the moral language of unconditional love to manipulate conditional, transactional labor crosses a profound ethical line.

2. Monetizing Genuine Connection

The rise of the "influencer" and network marketing has blurred the line between friendship and consumer base. When an individual leverages a personal relationship strictly to make a sale or recruit a friend into a multi-level marketing scheme, they are applying a business morality to a personal sphere. The friend is no longer viewed as a peer to be supported, but as an asset to be liquidated. This creates a deep sense of betrayal because the foundational trust of the relationship has been commodified.

3. The Shield of "Just Business"

Conversely, business morality crosses the line when it uses the phrase "it's just business" to absolve itself of basic human decency. While a company must make hard financial decisions, hiding behind the ledger to justify environmental devastation, predatory pricing, or the exploitation of vulnerable labor pools represents a total failure of ethical responsibility. A business entity is still composed of humans operating within a human society; claiming immunity from human morality simply because a transaction is taking place is a dangerous rationalization.

Redrawing the Boundary

So, how do we prevent these moral frameworks from cannibalizing each other? The answer lies in clarity of boundaries and radical transparency.

Healthy businesses do not need to pretend to be families. A truly ethical company operates as a high-functioning sports team: it demands excellence, compensates fairly, and operates with a clear, shared goal, but it respects that players have lives outside the arena. It honors the transaction instead of trying to disguise it as romance.

Likewise, healthy human relationships require a refuge from the marketplace. We must fiercely protect spaces where our value is not determined by our productivity, our network, or our earning potential.

Crossing the line happens when we forget what game we are playing. By respecting the rigid, transactional boundaries of business, we actually free ourselves to experience the unconditional, non-transactional beauty of genuine human connection.

The Price of Creation: Why Creative Technologists and Artists Suffer for Greatness

💻 Arpad Kish 💻 — Sun, 20 Sep 2026 09:58:12 +0000

The myth of the tortured genius is as old as the Renaissance, but today, that archetype has traded the paint-splattered studio for the blinding glow of multiple monitors at three in the morning. Whether you are wielding a brush, a violin, or a complex machine-learning algorithm, the pursuit of creative greatness demands a steep and often agonizing toll. This suffering is rarely the romanticized tragedy depicted in movies; rather, it is a quiet, relentless friction between a perfect vision and an imperfect medium.

At the core of all creative suffering is the chasm of execution. A creative technologist or artist conceptualizes something entirely new—a breathtaking digital landscape, a seamless user experience, or a provocative physical installation. In the mind, this idea is flawless, weightless, and alive. But the moment you attempt to drag that idea into reality, it resists. The paint dries the wrong color. The code refuses to compile. The hardware overheats. The agony lies in watching a pristine concept become compromised by the physical and logical constraints of the real world. Greatness is achieved only by those willing to suffer through the tedious, maddening process of bridging that gap, refining and rewriting until the final product resembles the initial spark.

Furthermore, true innovation requires stepping into the void. To create something great, you must abandon established patterns and risk catastrophic failure. For the technologist, this might mean writing a custom physics engine from scratch instead of using a reliable, off-the-shelf framework. For the artist, it means abandoning a popular style to explore an uncomfortable new truth. This voluntary exile from the known is deeply isolating. When you are pushing the boundaries of what a neural network can generate or what a canvas can communicate, there are no tutorials or guidebooks. You are alone in the dark, wrestling with a problem no one else even understands yet, entirely unsure if your sacrifices will yield a masterpiece or a colossal waste of time.

There is also the profound vulnerability inherent in the work itself. To build or create is to extract a piece of your own psyche and put it on display for public consumption. Whether it is a beautifully engineered app architecture or an avant-garde film, the creator’s ego and identity become fused with the output. When the work is criticized, misunderstood, or simply ignored, it registers not as a professional setback, but as a deeply personal rejection. The suffering stems from caring too much, yet that exact hypersensitivity is what allows the artist to notice the subtle details that elevate good work to great work.

Ultimately, suffering is not a prerequisite for greatness, but it is its most frequent companion. The friction of creation builds the muscle required for mastery. The late nights, the discarded drafts, the compiling errors, and the crushing self-doubt are not punishments; they are the price of admission to a realm where something entirely new is willed into existence. The greatness achieved is simply the scar tissue of a creative battle won.

The Illusion of Competence: How "Vibe Coding" Distorts Real Dev Skills

💻 Arpad Kish 💻 — Fri, 18 Sep 2026 13:59:35 +0000

We’ve all seen it recently: someone prompts an AI for 20 minutes, scaffolds a full-stack SaaS app, tweets "I built a company in a afternoon with zero coding knowledge!", and gets 10,000 likes.

Welcome to the era of vibe coding—where intuition, natural language prompts, and ambient steering replace syntax, algorithmic thinking, and system architecture.

While AI tools like Cursor, Claude, and Copilot make us feel like superhero developers, they also setup a dangerous trap: confusing tool speed with actual engineering competence.

Here is how "vibe coding" is changing the dev landscape, why it threatens real skills, and how you can use AI without losing your technical edge.

1. The "Dopamine High" of Instant Scaffolding

Remember the first time you spent 3 days fighting a CORS issue or a broken Webpack config? It was frustrating, but when you fixed it, you gained a piece of "scar tissue" that made you a better dev.

AI eliminates that initial friction. Need an Express backend with OAuth, Prisma ORM, and Stripe webhooks?
Just type a prompt, press Tab, and boom—3,000 lines of working code.

Prompt: "Create a Next.js API route that handles Stripe webhooks and updates PostgreSQL"
AI: *generates 150 lines of pristine-looking TypeScript in 4 seconds*

The dopamine hit is real. But here's the catch: When building code becomes effortless, understanding code becomes optional.

You get the high of "shipping" without doing the intellectual heavy lifting required to understand why it works or how it will fail in production.

2. The Mirage of Instant Seniority

Historically, becoming a Senior Engineer took years of breaking things in production, reading obscure stack traces, and wrestling with performance bottlenecks.

Today, a developer with 6 months of experience can prompt an AI to spit out microservices, Kubernetes manifests, and complex frontend state trees. On the surface, they look like a 10x senior dev.

Until something breaks.

When speed of execution is completely detached from depth of comprehension, high velocity is just architectural recklessness with a prettier UI.

3. Vibe Coding vs. Real Engineering: The Breakdown

Let's compare how a pure "Vibe Coder" handles a project versus a developer with deep domain mastery:

Dimension	🏄‍♂️ The Vibe Coder	🛠️ The Real Engineer
Debugging	Pastes error logs back into ChatGPT without reading the stack trace.	Uses deductive analysis, profilers, and mental models to find root causes.
Architecture	Stitches together fragmented AI snippets; no global design pattern.	Designs around failure modes, data integrity, security, and scalability.
Code Ownership	Passively accepts code diffs; doesn't know what half the lines do.	Owns every line. Reads diffs like a hawk before merging.
Edge Cases	Discovers bugs in production when real users break the app.	Anticipates edge cases upfront with unit tests and defensive coding.

4. The Slow Atrophy of Debugging Skills

Debugging isn't just about fixing a bug; it's how you learn runtime behavior, memory management, and library internals.

When you rely on AI to fix every single error message:

Your resilience drops: You lose the patience required for deep, multi-hour technical deep dives.
The codebase becomes a black box: You end up with thousands of lines of code that no human on your team actually understands.
False confidence grows: You measure your skill by how fast you generate code, not how reliable your systems are.

5. The Hidden Tax: "AI Technical Debt"

What happens when an AI generates code across 50 different prompts?
It introduces subtle bugs, redundant abstractions, and inconsistent patterns.

Because no single human designed the architecture, the code suffers from AI Entropy.

Nightmare Scenario: Imagine an API endpoint generated purely via prompts. During a traffic spike, a database connection pool leaks. The team that "vibed" the app panics because nobody knows how the connection lifecycle was set up in the first place. What took 30 minutes to prompt takes 3 days of emergency hotfixes to repair.

6. How to Use AI Like a Senior Dev (Not a Vibe Coder)

AI is an incredible power tool—think of it like an excavator on a construction site. Operating the controls lets you dig faster, but it doesn't make you a structural engineer.

To stay sharp while using AI tools:

Read the Diffs Line-by-Line: Never accept a generated PR or inline suggestion without understanding every single line. If you don't know what a function does, ask the AI to explain it before accepting.
Debug Manually First: Spent 10–15 minutes trying to read the stack trace and set breakpoints before pasting the error into an LLM.
Learn the Fundamentals First: If you're new to a framework or language, write your first few projects completely by hand. Build the mental map before adding the supercharger.
Focus on System Design: Shift your focus from writing syntax to designing clean APIs, data schemas, and security boundaries.

Final Thoughts

AI isn't going anywhere, and "vibe coding" is fun for prototyping side projects on a Sunday afternoon. But for software that actually matters—systems that process payments, hold user data, and need to run 24/7—hard-earned engineering skills are more valuable than ever.

The developers who win in the AI era won't be the ones who prompt the fastest. They will be the ones who understand deepest.

The Genius Trap: Emotional Intelligence, Maturity, and the Dark Side of Narcissism in Tech

💻 Arpad Kish 💻 — Fri, 18 Sep 2026 11:44:36 +0000

The technology industry has long romanticized the "brilliant jerk." From the mythological garage-dwelling hacker to the abrasive visionary CEO, Silicon Valley lore often suggests that interpersonal dysfunction is an acceptable, perhaps even necessary, price for world-changing innovation.

But as the tech landscape matures—and as the complexity of building global-scale software demands unprecedented collaboration—this narrative is cracking. The hidden costs of low emotional intelligence are becoming too expensive to ignore. Today, the most pressing bottlenecks in tech organizations are rarely technical; they are deeply human.

Understanding the interplay between emotional intelligence, emotional maturity, and the pervasive shadow of narcissism is critical for anyone looking to build, lead, or survive in a modern tech organization.

The Logic Fallacy: Why Tech Underestimates EQ

At its core, engineering is deterministic. Code compiles or it doesn’t; a system scales or it crashes. Because the daily work is deeply rooted in logic, tech cultures frequently over-index on cognitive intelligence (IQ) while viewing emotional intelligence (EQ) as a soft, secondary skill.

In reality, Emotional Intelligence—the ability to perceive, understand, and manage one's own emotions and the emotions of others—is the operating system that allows a team of brilliant individuals to function as a cohesive unit.

In a tech organization, high EQ manifests in highly practical ways:

The Code Review: Delivering critical feedback on a peer’s architecture without triggering their defensiveness, and receiving feedback without tying self-worth to a pull request.
The Post-Mortem: Navigating a critical system outage by focusing on systemic failures ("what went wrong") rather than assigning interpersonal blame ("who messed up").
Cross-Functional Empathy: Translating complex technical constraints to product managers or stakeholders without condescension.

Without EQ, high-IQ teams inevitably fragment into silos, hoarding knowledge and engaging in endless intellectual turf wars.

Emotional Maturity: The Anchor in the Storm

If emotional intelligence is the ability to read the room, Emotional Maturity is the discipline to act appropriately once you have. It is the application of EQ over time, tested by stress, failure, and fatigue.

Tech is an industry defined by whiplash. Roadmaps change overnight, features are scrapped after months of work, and the pressure to ship is relentless. Emotional maturity is what prevents a senior engineer from rage-quitting when a project is deprioritized. It is the product leader who absorbs the anxiety of the executive board without passing that panic down to the development team.

Markers of emotional maturity in tech include:

De-centering the Ego: Recognizing that the best technical solution might not be your solution, and gracefully championing a junior engineer's superior idea.
Delaying Gratification: Doing the unglamorous work of paying down technical debt or writing documentation, rather than constantly chasing the dopamine hit of building shiny new features.
Owning Impact over Intent: When a miscommunication causes a sprint to fail, a mature professional apologizes for the impact rather than endlessly defending their original intent.

The Dark Side: Narcissism Disguised as Vision

Where emotional maturity builds psychological safety, narcissism destroys it. Yet, the tech industry is uniquely vulnerable to narcissistic personalities. The ecosystem often inadvertently rewards grandiose claims, supreme overconfidence, and a relentless desire to "disrupt" the status quo—traits that mirror the clinical definitions of narcissism.

Narcissists in tech usually fall into the archetype of the "10x Engineer" or the "Visionary Founder." They are often highly capable, which makes their pathology incredibly difficult to root out. However, the dark side of their presence creates a blast radius that destroys organizational health.

The Anatomy of Tech Narcissism

Credit Hoarding and Blame Shifting: The narcissistic leader ensures they are the face of every successful launch, while failures are strictly the fault of "incompetent" downstream teams.
Manufactured Chaos: Narcissists thrive on being the savior. They will consciously or subconsciously create organizational chaos—ignoring process, bypassing QA, or changing requirements at the 11th hour—so they can swoop in with a heroic, late-night coding session to "save" the day.
Transactional Relationships: To a narcissist, peers and subordinates are not human beings; they are tools to be leveraged for upward mobility. Once a colleague is no longer useful, they are discarded or actively undermined.
The Chilling Effect on Innovation: Because narcissists react to divergent opinions with rage or subtle retaliation, teams learn to stop suggesting new ideas. The culture shifts from "How do we build the best product?" to "How do we avoid upsetting the smartest person in the room?"

The Organizational Cost

When a company tolerates a brilliant narcissist, they are taking out a high-interest loan on their culture. The short-term gains of a fast-shipping "rockstar" are rapidly eclipsed by the long-term costs of their behavior.

High-EQ, emotionally mature employees—the exact people who keep the organizational gears turning—are usually the first to leave when a narcissist is allowed to run rampant. They recognize that no amount of compensation is worth the mental health toll of constant gaslighting and emotional volatility. What remains is a hollowed-out team composed entirely of sycophants and the burned-out.

Rewriting the Code of Leadership

To build resilient, high-performing tech organizations, leadership must actively dismantle the idolization of the brilliant jerk. This requires a systemic shift in how talent is evaluated:

Screen for Character, Not Just Code: Technical interviews must be paired with rigorous behavioral assessments. Ask candidates to describe a time they failed, a time they had to compromise on a technical vision, or how they mentor juniors. Listen closely for how often they use "I" versus "We."
Incentivize Glue Work: Reward the people who write documentation, mentor onboarding engineers, and facilitate smooth cross-team communication. When performance reviews only reward raw code output, narcissism thrives.
Zero Tolerance for Toxicity: Leaders must be willing to fire high-performers who destroy team morale. The moment a team sees a "rockstar" held accountable for their behavior, psychological safety skyrockets.

The future of technology will not be built by solitary geniuses. It will be built by deeply connected, emotionally mature teams capable of navigating immense complexity together. In the modern tech organization, emotional intelligence is no longer a soft skill—it is the ultimate competitive advantage.

Center Stage: From Megalomania to Main Character Syndrome

💻 Arpad Kish 💻 — Thu, 17 Sep 2026 13:39:58 +0000

We live in an era where everyone is the star of their own movie, but the line between healthy self-confidence and toxic self-obsession has never been blurrier. Megalomania is a historical psychological term for delusional grandiosity, while Main Character Syndrome is a modern, internet-born phenomenon of romanticizing your own life.

While they share a core focus on the self, they operate in completely different ways. One is a clinical manifestation of pathology, while the other is a cultural byproduct of the social media age. This deep dive explores the nuances of both, how they manifest, and the impact they have on the people around them.

The Heavyweight: Megalomania

Historically, megalomania was a recognized psychiatric diagnosis. It describes an intense obsession with power and a delusional belief in one's own absolute superiority, wealth, or omnipotence. The term originates from the Greek words megalo (great or large) and mania (madness or frenzy).

Clinical Underpinnings

People exhibiting genuine megalomaniacal traits don't just think they are interesting; they believe they are fundamentally more important than the rest of humanity. Today, mental health professionals typically do not use "megalomania" as a formal diagnosis. Instead, these traits are viewed as severe symptoms of:

Narcissistic Personality Disorder (NPD): Specifically, grandiose narcissism, characterized by a lack of empathy, a need for excessive admiration, and a belief that they are unique and can only be understood by other special people.
Bipolar Disorder: During manic phases, individuals may experience delusions of grandeur, believing they have special powers, immense wealth, or a divine mission.

In a megalomaniac's worldview, other people aren't even supporting actors. They are merely tools to be exploited or obstacles to be crushed on the path to inevitable greatness. The focus is entirely on dominion and superiority.

The Viral Star: Main Character Syndrome

Fast forward to the 21st century, and the spotlight has democratized. "Main Character Syndrome" isn't found in any medical manual; it was born on platforms like TikTok and Twitter.

This behavior involves presenting or imagining yourself as the lead protagonist in a fictionalized version of your own life. It thrives on romanticizing mundane moments like staring out a rainy train window to a curated soundtrack, or dressing up as if everyday life is a cinematic events and projecting a highly aesthetic public persona.

The Good and the Bad

At its best, this is a harmless, even beneficial, coping mechanism. It helps people find joy in the mundane, assert control over unpredictable lives, and build self-confidence. It allows individuals to romantically frame their struggles as mere "character arcs" or "plot development."

At its worst, it breeds social solipsism. It can make individuals wildly insensitive to the boundaries and feelings of the "NPCs" (non-playable characters) around them. When someone is entirely focused on their own narrative arc, they may act out selfishly, expecting friends, family, and even strangers to play perfectly scripted supporting roles.

Key Distinctions

While both concepts center the universe entirely around the self, the underlying mechanics, motivations, and impacts are distinctly different:

Feature	Megalomania	Main Character Syndrome
Nature	Rooted in genuine psychopathology and delusional thinking.	A behavioral trend fueled by digital culture and hyper-individualism.
Core Drive	Absolute power, control, and undeniable superiority.	Attention, validation, and aesthetic perfection of the personal narrative.
Perception of Self	Rigid, unwavering belief in invulnerability and greatness.	A conscious performance, carefully curated for an audience or personal comfort.
Perception of Others	Tools to be used, exploited, or crushed.	Supporting cast members or "NPCs" meant to witness or facilitate the protagonist's journey.

The Empathy Deficit

We are biologically wired to view the world from our own perspective, making a baseline level of self-focus inevitable and necessary for survival. But the ultimate danger of both extremes whether clinical grandiosity or performative main character energy is the exact same: the gradual erasure of empathy.

When we reduce the people around us to stepping stones, background extras, or mere audience members, we lose the genuine friction and connection that makes reality interesting. You can absolutely be the author of your own story, but it helps to remember that everyone else is busy writing theirs, too.

The 5 Stages of Manipulation (And Exactly When to Say 'No')

💻 Arpad Kish 💻 — Wed, 16 Sep 2026 11:47:31 +0000

Whether you're dealing with a toxic co-founder, a demanding manager, or a draining personal relationship, manipulation rarely starts with obvious red flags. Master manipulators don't just hijack your boundaries overnight; they operate in calculated stages, slowly boiling the frog so you don't realize you're being controlled until you feel entirely trapped.

If you've ever found yourself caught in a cycle of second-guessing your own memory and judgment, you might be caught in a manipulator's loop. Here are the five stages of manipulation—and the exact moments you need to hit the brakes and say "no."

Stage 1: The Charm Offensive

Manipulators rarely introduce themselves as the villain. They start with the "charm" phase—often known as love bombing. They are overly complimentary, hyper-agreeable, and seemingly the perfect collaborator or partner. They mirror your interests and make you feel uniquely valued, establishing a rapid, unnatural sense of intimacy to get you to lower your guard.

The Red Flag: The relationship is moving at warp speed, and the flattery feels performative or unearned.
When to Say No: Say no when they demand premature commitments. If a new manager or partner wants you to bypass standard protocols or jump into a massive commitment because "we just connect so well," pump the brakes. A polite "I need to take this at a normal pace" sets a crucial early boundary.

Stage 2: Isolation and Boundary Testing

Once they’ve hooked you with charm, the manipulator begins testing your limits. This starts with small, seemingly innocent requests that blur your personal or professional boundaries. Concurrently, they subtly isolate you from your support network—complaining about your friends, or monopolizing your time so you can't consult mentors who might spot their toxic behavior.

The Red Flag: They make you feel guilty for spending time with others or make "special exceptions" out of your time and energy.
When to Say No: Say no the very first time a boundary is crossed, no matter how small. If they text you at 11 PM for a non-emergency, do not reply until morning. Your silence is a firm, undeniable "no."

Stage 3: Gaslighting and Devaluation

With your boundaries weakened, the facade drops. The manipulator begins to devalue your contributions and intelligence. When you call them out, they deploy gaslighting—a tactic designed to make you question your own reality. They will blatantly deny past conversations, shift the blame, or accuse you of being "too sensitive" or "crazy" to keep you off balance.

The Red Flag: You start keeping receipts, recording conversations, or constantly apologizing for things you know you didn't do.
When to Say No: Say no to their version of reality. You do not have to argue or prove them wrong. Say, "I remember it differently, and I'm not going to debate my reality," and immediately disengage.

Stage 4: The Guilt Trip

When you start pulling away or regaining your independence, the manipulator will pivot to play the victim. This is the guilt-trip phase. Suddenly, they are the ones who have been wronged. They leverage your empathy, reminding you of all the things they did for you back in Stage 1, using obligation and your own moral compass as a weapon against you.

The Red Flag: Every disagreement ends with you comforting them for a mistake they made.
When to Say No: Say no to taking responsibility for their emotions. A simple, "I understand you are upset, but my decision stands," is a complete sentence. Refuse to negotiate your boundaries out of guilt.

Stage 5: Intimidation and Rage

If charm, gaslighting, and guilt fail to bring you back under their control, a highly manipulative person will often resort to intimidation or a smear campaign. This is a desperate attempt to punish you for asserting your independence. They may threaten your job, spread rumors, or erupt in sudden anger to frighten you back into submission.

The Red Flag: Overt threats, passive-aggressive sabotage, or explosive temper tantrums when they don't get their way.
When to Say No: Say no by walking away entirely. At this stage, negotiation is impossible. Document the behavior, loop in HR or your support system, and enforce strict, zero-contact boundaries wherever possible.

Manipulation thrives in the gray areas of human empathy. By recognizing these stages and knowing exactly where to draw the line early on, you protect your most valuable assets: your time, your sanity, and your reality.

The Realpolitik of Tech: Navigating the Machiavellian Reality of People Management

💻 Arpad Kish 💻 — Wed, 16 Sep 2026 04:44:37 +0000

When engineers first transition into leadership, they often carry a fatal misconception: they believe the best code, the cleanest architecture, and the most logical arguments will win.

The reality is far more Machiavellian. In the context of modern tech organizations, being "Machiavellian" doesn't mean being a toxic, backstabbing villain. It means embracing the pragmatic truth of organizational dynamics: power, perception, and politics matter just as much as technical excellence.

To survive and thrive in tech leadership, one must recognize the stark realities of people management and understand the inherent friction between the three pillars of tech delivery: Engineering Management, Tech Leadership, and Team Leadership.

The Machiavellian Reality of People Management

In an ideal world, management is purely servant-leadership. In the real world, it is a complex game of resource allocation, expectation management, and strategic alignment.

Here are the unspoken realities of managing people in tech:

Optics are the Currency of Trust: Your team might be doing brilliant, foundational refactoring, but if the business doesn't see feature velocity or cost reduction, you are failing in their eyes. Good managers manipulate optics not to deceive, but to translate engineering realities into business value.
Headcount is Leverage: In corporate tech, a manager's influence is often directly correlated with the size of their team and the criticality of their systems. Protecting and expanding your headcount is a political necessity to ensure your team isn't swallowed or sidelined during the next reorg.
Strategic Empathy: You cannot motivate everyone with "interesting technical challenges." Real people management requires uncovering what your reports actually want—promotions, coasting, visibility, or stability—and using those distinct levers to drive the organization's goals forward.
The Shield is a Sieve: Managers are told to "shield the team from corporate noise." But a purely shielded team becomes alienated and unpromotable. A pragmatic manager selectively leaks political context so the team understands why they are building what they are building.

The Disparate Triad: EM, TL, and Team Lead

The friction in modern engineering orgs often stems from a fundamental misunderstanding of the leadership triad. Organizations often conflate these roles, leading to burnout and crossed wires. Each role has a distinct, often competing, mandate.

1. Engineering Management (The Diplomat)

The Engineering Manager (EM) is the political operator. Their primary concerns are outward and upward.

Mandate: Retention, budgets, performance reviews, and cross-functional alignment (Product, HR, Finance).
The Reality: The EM is playing a zero-sum game for budget and promotion slots. Their job is to make the team look good to directors and VPs, ensuring the team's survival and growth.
Blind Spot: They can become so detached from the codebase that they make promises the architecture cannot support.

2. Tech Leadership (The Architect)

The Tech Lead, Staff, or Principal Engineer is the guardian of the system. Their primary concerns are downward and forward (into the codebase and the future).

Mandate: System architecture, technical debt resolution, scalability, and code quality.
The Reality: The TL is constantly fighting for technical purity in a business that only cares about feature delivery. They must wield influence without formal authority, often using fear (e.g., "the database will tip over") to negotiate time for refactoring.
Blind Spot: They often ignore the business realities of runway and time-to-market, seeking elegant solutions when a duct-tape fix would win the quarter.

3. Team Leadership (The General)

Often operating as a Scrum Master, Delivery Lead, or a tactical Tech Lead, the Team Leader is concerned with the immediate horizon.

Mandate: Sprint execution, unblocking day-to-day work, velocity metrics, and tactical morale.
The Reality: The Team Lead is in the trenches. They care about getting tickets across the Jira board today. They are the friction point between the EM's lofty promises and the TL's grand architectural visions.
Blind Spot: They can become so hyper-focused on short-term delivery that they miss team burnout (EM territory) or compounding technical debt (TL territory).

The Inevitable Conflict

Because these roles are fundamentally disparate, tension is not just likely—it is designed into the system.

Role	Primary Currency	Natural Enemy
Engineering Manager	Optics & Predictability	Unplanned technical debt
Tech Lead	Quality & Scalability	Arbitrary business deadlines
Team Lead	Velocity & Completion	Complex architectural overhauls

A successful organization doesn't try to eliminate this tension; it balances it. When an EM acts like a Tech Lead, micromanaging the architecture, the system breaks down. When a Tech Lead acts like an EM, optimizing for Jira points instead of system stability, technical bankruptcy follows.

Embracing the "Machiavellian" reality simply means accepting that these competing agendas exist. The most effective leaders in tech are those who understand the specific game they are playing, respect the different mandates of their peers, and negotiate the compromises necessary to keep the machinery moving.

Demystifying Vector Distance in PostgreSQL

💻 Arpad Kish 💻 — Sun, 16 Aug 2026 08:50:55 +0000

A look into sliding window comparisons for image analysis.

When you need to perform complex similarity comparisons inside a database, you often have to bridge the gap between application-level data structures (like JSON) and low-level math (like vectors).

The PostgreSQL snippet provided is a classic example of this bridge. It sets up the foundation for a sliding window comparison—a technique where you analyze overlapping sequences of data—by extracting features from a JSON payload and calculating how "far apart" two sets of image data are using Euclidean distance.

Part 1: Extracting the Features

Before you can compare two sets of data, you have to format them into a mathematical structure. The get_vector_values function handles this transformation.

This function takes a JSONB array of objects (the cluster_vector) and flattens it into a single, one-dimensional array of real numbers (real[]).

Notice the specific keys being extracted: a, b, and l. This strongly implies the data represents CIELAB (L*a*b*) color space values. In image processing, extracting the average L*a*b* values of images and comparing them is a common way to detect duplicates or cluster similar images together.

The function loops through the JSON array three separate times to group all the a values together, then the b values, and finally the l values. This creates a continuous vector signature representing that specific "window" of image data.

Part 2: Calculating the Distance

Once your image data is flattened into arrays, the distance function determines how mathematically similar they are.

This function implements the standard Euclidean Distance formula. It iterates through both arrays up to a specified length, calculates the squared difference between each corresponding element, sums them up, and finally returns the square root (using PostgreSQL's square root operator |/).

The smaller the returned number, the more similar the two image vectors are. A distance of 0 means they are identical.

The Source Code

/*
 * @rpi1337
 */

module.exports = `

CREATE OR REPLACE FUNCTION get_vector_values(cluster_vector jsonb) RETURNS real[] AS $$
DECLARE
  list real[] [];
  i jsonb;
BEGIN
  FOR i IN SELECT * FROM jsonb_array_elements(cluster_vector) LOOP
    list := array_append(list, (i->>'a')::real);
  END LOOP;
  FOR i IN SELECT * FROM jsonb_array_elements(cluster_vector) LOOP
    list := array_append(list, (i->>'b')::real);
  END LOOP;
  FOR i IN SELECT * FROM jsonb_array_elements(cluster_vector) LOOP
    list := array_append(list, (i->>'l')::real);
  END LOOP;
  RETURN list;
END;
$$ LANGUAGE plpgsql IMMUTABLE;

CREATE OR REPLACE FUNCTION distance(l real[], r real[], length INT) RETURNS real AS $$
DECLARE
  s real;
BEGIN
  s := 0;
  FOR i IN 1 .. length LOOP
    s := s + ((l[i] - r[i]) * (l[i] - r[i]));
  END LOOP;
  RETURN |/ s;
END;
$$ LANGUAGE plpgsql IMMUTABLE;

`;

Modernization Considerations

For modern, large-scale production applications, iterating over JSON elements multiple times and performing custom mathematical loops in PL/pgSQL can be CPU-intensive.

A modernized approach often employs extensions like pgvector, which offloads operations like Euclidean distance computations to optimized C libraries, allowing indexes like HNSW and IVFFlat to significantly speed up similarity searches across large image datasets.

*Authored by @rpi1337 — View more at arpi.im*

Cracking the cloud-mess: Istio, K8s, Helm charts and why you don't need them

💻 Arpad Kish 💻 — Tue, 28 Jul 2026 12:28:07 +0000

It usually starts with the best intentions. You have a new project, and you want to build it "right" from day one. You want it to be scalable, resilient, and future-proof. So, you look at how the giants do it. You see engineering blogs from massive tech companies detailing how they run fleets of microservices orchestrated by Kubernetes, managed by Helm, and secured by Istio.

You think: If it's good enough for them, it's the right way for us.

Fast forward six months. Your team is spending half their week fighting YAML indentation errors, debugging network policies, and waiting for bloated CI/CD pipelines to finish, rather than shipping features to your users.

Welcome to the cloud-mess.

The Usual Suspects

Before we tear them down, let's look at the tools that usually make up this modern infrastructure cocktail.

Kubernetes (K8s): The undisputed king of container orchestration. It dictates how containers are deployed, scaled, and managed across a cluster of machines.
Helm: The "package manager" for Kubernetes. It uses templates (Helm Charts) to define, install, and upgrade complex Kubernetes applications.
Istio: A service mesh. It sits as a dedicated infrastructure layer right on top of Kubernetes to handle service-to-service communication, adding features like traffic routing, encryption (mTLS), and observability.

Individually, these are phenomenal pieces of engineering. Together, they form an incredibly powerful stack for operating software at a massive scale.

The problem? You are almost certainly not operating at that scale.

The "Tech Giant" Fallacy

The software industry has a serious problem with Resume-Driven Development. We often adopt technologies not because they solve our immediate business problems, but because they look great on a CV or sound impressive in a meeting.

When you adopt Kubernetes, Helm, and Istio, you aren't just adopting software; you are adopting a distributed systems philosophy. You are taking on the operational overhead of a tech giant without having their revenue or headcount.

Massive Cognitive Load: To deploy a simple web application, a developer now needs to understand Docker, K8s Pods, Deployments, Services, Ingress controllers, Helm templating syntax, and Istio virtual services. That is a heavy tax on developer velocity.
The Hidden Costs: Running a managed Kubernetes cluster (like AWS EKS or Google GKE) costs money just for the control plane. Add in the compute resources required to run the Istio sidecar proxies, the Prometheus/Grafana stack to monitor it all, and the dedicated engineers required to keep it breathing, and your infrastructure bill has suddenly multiplied.
Debugging Hell: When a request fails in a traditional monolithic app, you check the stack trace. When a request fails in a microservices mesh, you have to trace it through an API gateway, multiple load balancers, sidecar proxies, and network policies, praying your distributed tracing is configured perfectly.

The Antidote: Boring Architecture

If you are building a SaaS product, an internal tool, or a consumer app that isn't currently serving millions of concurrent requests, you need to ruthlessly simplify your stack. Your goal is to ship value to users, not to maintain a pristine cloud-native ecosystem.

Here is what you should reach for instead:

1. The Majestic Monolith

Don't split your application into microservices until a single codebase becomes structurally impossible for your teams to work on simultaneously. A well-structured monolith (often called a modular monolith) is vastly easier to deploy, test, and debug. When performance bottlenecks eventually happen, scale vertically first—compute power is cheaper than engineering time.

2. Managed Containers (Serverless)

If you need to run containers, let someone else manage the orchestration. Services like AWS App Runner, Google Cloud Run, or Azure Container Apps abstract away the underlying infrastructure. You give them a Docker container, and they handle the routing, scaling (even down to zero), and load balancing. You get the benefits of containerization without the operational nightmare of K8s.

3. Platform as a Service (PaaS)

If you want to move even faster, skip containers entirely. Platforms like Render, Heroku, or Vercel allow you to connect your GitHub repository and let the platform handle the build and deployment pipeline. Yes, they cost a premium per compute hour compared to raw AWS EC2 instances, but they save you the salary of a full-time infrastructure engineer.

The Bottom Line

Kubernetes, Helm, and Istio are tools designed to solve the organizational and scaling problems of enterprises with hundreds of engineering teams and massive global traffic.

If your engineering team can fit in a single conference room, adopting the full cloud-native stack is like buying a commercial airliner to commute to the grocery store. Keep it simple, keep it boring, and focus on building the product your users actually care about.

Functional programming primitives in Javascript

💻 Arpad Kish 💻 — Sun, 19 Jul 2026 06:34:38 +0000

Category theory often sounds like impenetrable academic jargon, but at its core, it is simply the mathematics of composition. In functional programming, we use its concepts to build modular, predictable, and bug-resistant code.

JavaScript isn't a pure functional language like Haskell, but it has first-class functions and treats functions as values. This makes it entirely possible to implement category theory primitives.

Here is how the theoretical concepts map to practical JavaScript.

The Vocabulary of Category Theory

Before jumping into code, let's define the fundamental pieces:

Categories: A collection of objects and arrows (morphisms) between them.
Objects: In programming, these are our types or data (e.g., String, Number, Boolean, Array).
Morphisms: These are our pure functions that transform one type into another (e.g., a function that takes a String and returns a Number).

The goal of functional programming primitives is to create safe wrappers (containers) around our data so we can compose these functions predictably, without side effects or unhandled errors.

1. Functors: The Mappables

A Functor is any type that implements a map method. It is a container holding a value, and map allows you to apply a function to that value without pulling it out of the container.

When you map over a Functor, it returns a new Functor of the same type, preserving the container's structure.

The native JS Functor:
You already use Functors every day. JavaScript Arrays are Functors.

const numbers = [1, 2, 3];
// We apply a function to the values inside, and get a new Array back
const doubled = numbers.map(x => x * 2); // [2, 4, 6]

Building a custom Functor:
Let's build a simple Box container to see how this works for single values.

const Box = x => ({
  map: f => Box(f(x)),
  fold: f => f(x), // An escape hatch to get the value out
  inspect: () => `Box(${x})`
});

// Usage:
const result = Box('  Functional Programming  ')
  .map(str => str.trim())
  .map(str => str.toLowerCase())
  .map(str => str.split(' '));

console.log(result.inspect()); // Box(Array(2))
console.log(result.fold(x => x)); // ['functional', 'programming']

Because map always returns a Box, we can chain operations infinitely.

2. Monoids: The Combiners

A Monoid is a type that has two things:

An identity value: A value that, when combined with another value, doesn't change it (like 0 for addition, or "" for strings).
An associative binary operation: A function that combines two values of the same type into one (like + or concat()). "Associative" just means the grouping doesn't matter: (a + b) + c === a + (b + c).

The native JS Monoids:
Strings and Numbers are standard monoids under specific operations.

// String Monoid (Identity is "")
const strConcat = "hello" + ""; // "hello"

// Number Monoid for Addition (Identity is 0)
const numAdd = 5 + 0; // 5

// Array Monoid (Identity is [])
const arrConcat = [1, 2].concat([]); // [1, 2]

Monoids are incredibly powerful for reducing a list of things into a single thing. This is exactly what Array.prototype.reduce relies on.

3. Monads: The Flatteners

The infamous Monad. The standard joke is that "a monad is just a monoid in the category of endofunctors," which is true mathematically but useless for programming.

Practically, a Monad is a Functor that also implements a flatMap (or chain, or bind) method.

The Problem Monads Solve:
If you have a function that returns a Box, mapping it over a Box results in a nested container: Box(Box(value)). A Monad knows how to flatten itself to prevent this nesting.

// A function that returns a container
const half = x => (x % 2 === 0 ? Box(x / 2) : Box("Odd"));

// Using map creates nested Boxes
const nested = Box(4).map(half);
console.log(nested.inspect()); // Box(Box(2))

Adding Monadic Behavior:
To make our Box a Monad, we add chain (the JS convention for flatMap).

const MonadicBox = x => ({
  map: f => MonadicBox(f(x)),
  chain: f => f(x), // Instead of re-boxing, we just return the result of f(x)
  inspect: () => `Box(${x})`
});

const flatResult = MonadicBox(4).chain(half);
console.log(flatResult.inspect()); // Box(2) - No nesting!

The native JS Monads:

Array.prototype.flatMap makes Arrays monads.
Promise is heavily inspired by Monads. Calling .then() with a function that returns a new Promise automatically flattens the result. You never get Promise<Promise<Data>>.

4. Applicatives: The Multi-Container Operators

What happens if you have a function wrapped in a Functor, and you want to apply it to a value wrapped in another Functor? A standard Functor's map expects a normal function, not a wrapped one.

An Applicative implements an ap method to solve this.

const AppBox = x => ({
  map: f => AppBox(f(x)),
  ap: otherBox => otherBox.map(x), // x here is actually a function!
  inspect: () => `Box(${x})`
});

const boxWithFunction = AppBox(x => x + 10);
const boxWithValue = AppBox(5);

// Applies the wrapped function to the wrapped value
const result = boxWithFunction.ap(boxWithValue); 
console.log(result.inspect()); // Box(15)

Summary of Primitives

Here is a quick reference guide to how these primitives build on top of each other:

Primitive	Core Interface	Purpose
Functor	`map`	Apply a function to a wrapped value.
Applicative	`ap`	Apply a wrapped function to a wrapped value.
Monad	`chain` / `flatMap`	Sequence operations that return containers, preventing nesting.
Monoid	`concat` + `empty`	Combine values of the same type safely.

The Trojan Horse of Web Design: The Genius Behind Adobe Fireworks' "Vector PNGs"

💻 Arpad Kish 💻 — Thu, 30 Apr 2026 05:43:29 +0000

If you were designing websites in the late 1990s and early 2000s, your hard drive was likely a mess. The standard workflow of the era demanded a strict, frustrating division of labor: you had your heavy, complex "source" files—usually Adobe Photoshop (.psd) or Illustrator (.ai) documents containing all your editable layers and vectors—and you had your "delivery" files—the flattened, highly compressed .jpg or .gif images that you actually uploaded to the server.

Managing this dual-file system was a nightmare of version control. If a client wanted to change the text on a web button, you had to dig up the original .psd, change the text, re-slice the image, re-export it, and re-upload it.

Then came Macromedia (later Adobe) Fireworks, a tool built from the ground up exclusively for web UI design. Fireworks promised a utopian workflow: what if the source file and the delivery file were the exact same thing?

To achieve this, Fireworks pulled off one of the most brilliant technical sleights-of-hand in software history. They hacked the .png format.

The Problem: Vectors vs. Pixels

To understand the genius of Fireworks, you have to understand the fundamental divide in digital graphics.

Raster graphics (like JPEG, GIF, and standard PNG) are grids of colored pixels. They are universally understood by web browsers, but they are "flat." Once text is rendered into pixels, it's just a mosaic of color; you can't click in and edit the typo.
Vector graphics (like SVG or Illustrator files) are mathematical formulas defining lines, shapes, and text. They are endlessly editable and scalable without losing quality, but historically, web browsers couldn't read them.

Fireworks was a vector-based design tool. It allowed you to draw shapes, apply live drop shadows, and type editable text. But it needed to output a file that a web browser could instantly display. Its solution was to use the Portable Network Graphics (PNG) format not just as an image, but as a Trojan horse.

The Secret of PNG "Chunks"

The PNG file format specification is surprisingly flexible. A PNG file isn't just one solid block of data; it is composed of independent data blocks called chunks.

Some of these chunks are mandatory. Every PNG must have a header chunk (telling the computer "I am a PNG"), an image data chunk (the IDAT block containing the actual pixels), and an end chunk. If an image viewer reads these, it can display the picture.

However, the architects of the PNG format smartly included the ability to add ancillary chunks—optional blocks of metadata. The golden rule of the PNG specification is that if a software program encounters an ancillary chunk it doesn't understand, it should simply ignore it and move on to the chunks it does understand.

Fireworks exploited this rule masterfully.

The Dual-Natured File

When you hit "Save" in Fireworks, the software rapidly generated two completely different sets of data and stuffed them into the same .png file.

The Decoy (For the Browser): First, Fireworks rendered your entire editable canvas into a perfectly flat, standard raster image. It packed these pixels into the mandatory IDAT chunk.
The Payload (For the Designer): Simultaneously, Fireworks took all of your private workspace data—your vector paths, your text layers, your slice guides, and your live effects—and bundled it into a proprietary, hidden ancillary chunk.

The result was a file with a split personality, and its behavior depended entirely on who was looking at it.

If you dragged that button.png file into Internet Explorer, the browser would look at the file, read the standard pixel data, ignore the weird proprietary chunk it didn't understand, and display a beautiful, flat web graphic.

But if you opened that exact same button.png file in Fireworks, the software would bypass the flat pixels entirely. It would dive into its hidden payload chunk, unpack the data, and instantly rebuild your workspace. The text was editable again. The vector shapes could be resized.

The Bloat and the Export

This "Vector PNG" completely eliminated the need for separate source files. Your working directory was just a folder full of PNGs that you could immediately preview in a browser or open in Fireworks to edit.

There was, however, a catch: file size.

Because a Fireworks PNG contained both a flattened image and a comprehensive mathematical breakdown of the document's construction, the files were significantly heavier than standard web images. A button that should be 5 kilobytes might weigh 50 kilobytes.

Therefore, while you could technically put your working Fireworks PNGs directly onto a live web server, it was bad practice for site performance. When it was time to actually launch a site, designers used a specific "Export" function. This process stripped out the proprietary vector payload chunk, leaving behind only the lightweight, optimized IDAT pixel data for the final web-ready file.

A Lasting Legacy

Adobe ultimately discontinued Fireworks in 2013, effectively conceding the web design space to newer tools like Sketch and, eventually, Figma. Today, web browsers natively support vector graphics through SVG, making the specific raster/vector bridge that Fireworks built obsolete.

Yet, the cleverness of the Fireworks PNG remains a masterclass in software engineering. By understanding not just the limitations of the web, but the hidden flexibility within standard file specifications, the developers created a tool that felt like magic to a generation of web designers.

Analyzing the Serverless Deployment Strategy: Infrastructure, Security, and Packaging

💻 Arpad Kish 💻 — Mon, 06 Apr 2026 09:04:56 +0000

Deploying a secure, cloud-native application requires a careful orchestration of application code, network configurations, and security policies. The provided architecture presents a mature deployment strategy that leverages Terraform for Infrastructure as Code (IaC) to provision an AWS environment consisting of an API Gateway, a Lambda function, and an RDS PostgreSQL database.

By analyzing the provided Terraform configuration and deployment scripts, we can break down this strategy into several core components: infrastructure management, secure networking, dynamic secrets handling, and a hybrid packaging mechanism.

1. Declarative Infrastructure with Terraform

The foundation of the deployment relies on Terraform to define the AWS infrastructure in the eu-central-1 region. Rather than manually clicking through the AWS Management Console, the entire topology—from Virtual Private Clouds (VPCs) down to IAM roles—is defined declaratively. This ensures the environment is reproducible, version-controlled, and easily destroyed (facilitated by configurations like skip_final_snapshot = true on the database).

2. Deep Network Isolation

A primary highlight of this deployment strategy is its "security first" network architecture. Compute and data storage are intentionally decoupled from the public internet:

Private Subnets: Both the Node.js Lambda function and the PostgreSQL RDS instance are deployed into private subnets (10.0.3.0/24 and 10.0.4.0/24).
Controlled Egress via NAT Gateway: Because the Lambda function's core purpose is to resolve DNS addresses for reported domains, it requires outbound internet access. The deployment strategy solves this by provisioning a NAT Gateway in a public subnet and configuring a route table to direct outbound traffic from the private subnets through this gateway.
VPC Endpoints: To securely interact with AWS managed services without traversing the public internet, a VPC Endpoint is deployed specifically for AWS Secrets Manager.

3. Dynamic Credentials and Least Privilege

Hardcoding database credentials is a common pitfall in application deployments. This project circumvents that risk by generating database credentials dynamically during the provisioning phase:

Terraform uses the random_password and random_string resources to generate a secure database password.
These credentials, along with host and port details, are combined into a JSON object and stored directly in AWS Secrets Manager.
The deployment adheres strictly to the principle of least privilege. The Lambda function is assigned a dedicated IAM role and policy that specifically allows it the secretsmanager:GetSecretValue action, scoped only to the exact ARN of the created database secret.

4. Hybrid Application Packaging and Deployment

Deploying AWS Lambda functions requires bundling the application code with its dependencies. This project utilizes a two-step hybrid approach bridging shell scripting and Terraform:

The Build Phase (deploy.sh): Before Terraform is applied, a local build script is executed. This script extracts the current version from package.json, installs production dependencies (such as pg, dns, and custom utilities), and packages the code into a standardized ZIP file.
The Provisioning Phase (main.tf): The Terraform configuration maps directly to the locally built ZIP artifact using the filename argument. Crucially, it utilizes the source_code_hash attribute mapped to filebase64sha256. This ensures that Terraform accurately detects when the ZIP file's contents have changed, triggering a Lambda update on subsequent terraform apply executions.
Direct CLI Updates: The deploy.sh script also contains logic to upload the ZIP to S3 and update the Lambda code directly via the AWS CLI. As noted in the project documentation, this offers developers a faster iteration loop that bypasses Terraform when only application code changes are being deployed, though it remains optional.

5. Strictly Controlled Public Ingress

With the backend completely isolated in private subnets, the strategy exposes a single, strictly controlled public interface. An HTTP API Gateway is provisioned with an AWS Proxy integration pointing to the Lambda function. Terraform explicitly creates the aws_lambda_permission necessary to allow the API Gateway to invoke the backend function.

Conclusion

This deployment strategy is highly robust. By combining Terraform's declarative infrastructure capabilities with automated packaging scripts, it achieves a serverless architecture that is highly isolated, dynamically secured, and easily reproducible.