DEV Community: Prahlad Yeri

Programming is morphing from a creative craft to a dismal science

Prahlad Yeri — Mon, 27 Oct 2025 06:38:22 +0000

To be fair, it had already started happening much before AI came when programmer roles started getting commoditized into "Python coder", "PHP scripter", "dotnet developer", etc. Though these exact phrases weren't used in job descriptions, this is how recruiters and clients started referring programmers as such.

But LLMs took it a notch even further, coders have started morphing into LLM prompters today, that is primarily how software is getting produced. They still must baby sit these LLMs presently, reviewing and testing the code thoroughly before pushing it to the repo for CI/CD. A few more years and even that may not be needed as the more enhanced LLM capabilities like "reasoning", "context determination", "illumination", etc. (maybe even "engineering"!) would have become part of gpt-9 or whatever hottest flavor of LLM be at that time.

The problem is that even though the end result would be a very robust running program that reeks of creativity, there won't be any human creativity in that. The phrase dismal science was first used in reference to economics by medieval scholars like Thomas Carlyle. We can only guess their motivations for using that term but maybe people of that time thought that economics was somehow taking away the life force from society of humans, much similar to the way many feel about AI/LLM today?

Now I understand the need for putting food on the table. To survive this cut throat IT job market, we must adapt to changing trends and technologies and that includes getting skilled with LLM. Nonetheless, I can't help but get a very dismal feeling about this new way of software development, don't you?

AI assistance is only making coders dumb, lazy and prone to replacement

Prahlad Yeri — Thu, 23 Oct 2025 07:48:40 +0000

LLMs like ChatGPT and copilot are like those super saturated junk food like a pizza or burger which feels good in that moment (ready code snippets or answers) but over a period only accumulates weight gain, sugar and diseases (technical debt, brain drain).
We have stopped reading or even looking up official documentation, that has become an extinct skill today. And why would we if an LLM does it for us and tells us only what we need to be told to create that release or fulfill that urgent deadline.

What happened with AWS outage recently is only a brief foreshadow of what might eventually come to pass if this trend continues. Imagine a world where most programmers are primarily LLM prompters with a very shallow understanding of core programming skills or even operational skills pertaining to an app, framework or library. What will we do if a major outage or technical issue occurs then and no person around knows what’s really going on?

And that’s not even mentioning the replacement of human workers problem which is the most discussed topic these days. Eventually, the senior/mid management will think why do we even need these “prompt engineers”, let an agent do that work. After that, senior management will think why do we need these “prompt managers”, let another agentic AI that controls other agents do it! Eventually, the company will be run entirely by robots and shareholders will enjoy their wealth in peace!

As dystopian as the above scenario sounds, that’s the world we are eventually heading towards with all the progress in AI and the commerce oriented environment it’s evolving in. But it’ll still take decades at least considering the state of prevailing systems in public and private sectors. But until that happens, let us programmers equip ourselves with real old school skills which have stood the test of time - like scavenging documentation, referring to stack overflow and wikipedia for knowledge, etc. and coding with humility and passion, not this LLM crap.

The slow death of epiphanies and utilitarian programming

Prahlad Yeri — Tue, 14 Oct 2025 18:03:46 +0000

Utilitarian coding is defined as follows: The code you write should be directly useful or serve the interest of at least one actual human being. It might appear somewhat abstract or vague, so examples might help. For example, I don't consider frameworks as utilitarian code. What you create are like the "frames" of a picture box, someone else (the user) will take it and draw the actual picture. Though you did help with part of the process, it's indirect at best. You're part of the supply chain here, not part of the team.
A clever and witty bash script running on a unix server somewhere is also not utilitarian coding, no human ever directly benefited from it.

Libraries can be somewhat utilitarian, at least more than frameworks. At least they provide some reusable functionality to the user out of the box like logging, scanning a barcode, fetching data from a URL, etc. But again, a lot of indirection and little lasting time, what did you learn about implementation and life in that process my friend?

It's my strong belief that our life's purpose isn't just about learning technology but also other non-technical things in life (such as life itself). By compartmentalizing themselves into libraries, frameworks, specifications, package managers, build and tooling, etc, many coders over the last decade have sort of divorced themselves from the intricacies and interaction with life itself.

A decade ago from now (i.e. circa 2014-15) is where I'd say utilitarian coding came to an end. The kind of programming that prevailed until then (mostly desktop programming) was highly utilitarian in nature. You used to develop a Winforms App for the client, with actual textboxes, dropdowns and buttons, tailored to their specific requirements and domain knowledge, what could be more utilitarian than that! You used to gain domain expertise and not just technology expertise.

As things started moving to the cloud, the interaction between the end-user and programmer became less and less, that's when utilitarian coding started dying too. As a new breed of specialists called "Agile Experts", "Scrum Masters", "Tech Advocates", "Thought Leaders", etc. started inserting themselves between the coder and end user, the former's role started morphing as the ostrich policy of dealing only with technology and nothing else. We started losing touch with domain expertise, and became branded as "python coder", "PHP scripter", "web developer", "AI developer", etc. That's how folks started churning out more frameworks, libraries, packages, stencils, helper scripts, etc. instead of worrying about actual problem solving with the stakeholders.

This is how things stand right now for the most part, desktop development and other forms of utilitarian coding have still maintained their small niche somewhere, but they're just a niche. But it's not a healthy development, nor is it sustainable long term. I strongly feel that this bubble is waiting to burst one day soon, and there will be a reversion towards utilitarian coding again. Even the cloud itself needs to be more utilitarian, a lot of needless clutter out there which can be simplified.

What do you think? Let me know in comments.

Create a C# Windows Desktop App in 9 Lines — No Visual Studio Needed

Prahlad Yeri — Sat, 20 Sep 2025 16:17:05 +0000

If you're new to C# and especially desktop development, here's how easy it is to get started on a modern Windows 10/11 PC. This way of creating a Hello World C# program doesn't involve installation of any heavy IDE like Visual Studio or the .NET 8/9 SDK.

In fact, most recent Windows versions already come with .NET Framework 4.x preinstalled, including the classic C# compiler at a location like this:

C:\Windows\Microsoft.NET\Framework\v4.0.30319

The exact folder may differ depending on your system but it usually contains csc.exe, the built-in compiler that can compile simple console or desktop apps. You can add this folder to your PATH environment variable (temporarily or permanently) so that csc is available from the command line:

set PATH=C:\Windows\Microsoft.NET\Framework\v4.0.30319;%PATH%

We will be using this classic, old-school style of programming (similar to writing C programs with gcc or turboc) — a great way to get acquainted with a new language.

Step 1: Create the source file

Make a new folder anywhere on your drive. Inside it, create a file named Program.cs using Notepad, VS Code, or any editor you like:

using System;
using System.Windows.Forms;

class Program {
    public static void Main() {
        Form frm = new Form();
        frm.Text = "Hello";
        frm.ShowDialog();
    }   
}

In just nine lines of C# code, without using any IDE, you now have a working “Hello World” desktop app with no additional dependencies.

Step 2: Compile and run

Open Command Prompt in your project folder and run:

csc Program.cs
Program

The first line tells the C# compiler (csc.exe) to build the app into Program.exe. The second one runs it. You can also double-click Program.exe in File Explorer.

By default, a console window appears behind the form. To build a GUI-only app without the console, recompile with the /target:winexe parameter:

csc /target:winexe Program.cs

What’s next?

In upcoming posts, we’ll add more features such as menus, buttons, event handlers, and even database access with ADO.NET. But for now, enjoy this milestone: you’ve built your very first Windows desktop app in C#!

By default, a console window appears behind the form. To build a GUI-only app without the console, recompile with the /target:winexe parameter:

csc /target:winexe Program.cs

What’s next?

The art and science of effectively maintaining changelogs

Prahlad Yeri — Mon, 08 Sep 2025 06:38:16 +0000

Even in 2025, maintaining changelogs isn’t an exact science. There is no general consensus or even tooling around how your changelog should look in order to conform to some norms or standards, because there aren’t any. After some trial-error and pondering, this is what I came up with for my upcoming FocusBeam project:

# Focus Beam Changelog

## [Unreleased]
### Added
- [x] Dashboard and Timesheet view
- [x] About View
- [x] Settings View
- [x] Project creation and editing
- [x] Task creation and editing
- [x] Enable Timesheet button on dashboard
- [ ] Show Total Hours worked on the project on Dashboard View
- [ ] Logged hours computation
- [ ] Notes
- [ ] Mind Maps
- [ ] MCQ
- [ ] Export/Reports

This format looks somewhat better than the older version that I still retain for some existing projects:

R1.1

- Pending CRM Reports.
- Check post script.
+ Clicking on logos go to home page.
+ Chart: width on various screens.
* Chart: Remove decimal from "Total Life (Hrs)"
* report: pdf: line items: add gap between fields.
* report: space below header.

Here, the mnemonic prefix is dash (-) to define a pending task, a plus (+) means work is in progress, and asterisk (*) means it’s complete. Now, if you’re an automation nerd and decided to opt for conventional commit message spec, it’s possible to maybe construct the changelog automatically by following this spec while committing the code itself!

- feat: pending CRM Reports
- chore: check post script
+ fix: clicking on logos go to home page
+ feat: chart: width on various screens
* feat: chart: Remove decimal from "Total Life (Hrs)"
* fix: report: pdf: line items: add gap between fields
* fix: report: space below header

This assumes that you’ve followed the conventional spec while committing your code to git source control. For example, “feat: pending CRM Reports” for implementing this particular feature.

When Gandhi met Satoshi

Prahlad Yeri — Sun, 20 Apr 2025 04:08:10 +0000

A fictional encounter between two radically different revolutionaries… or maybe not so different after all.

Scene:

A quiet room beyond time, filled with gentle candlelight. Mahatma Gandhi sits cross-legged on a simple mat, spinning a symbolic charkha (spinning wheel). A soft whirring sound is heard — it’s Satoshi Nakamoto, hooded and calm, typing quietly on an open-source laptop.

Gandhi (smiling gently):

I see you’re building something... abstract. Not cloth this time, but code?

Satoshi (nodding):

Yes. It’s called Bitcoin. A currency without rulers. A decentralized network where no single man holds the power.

Gandhi:

Ah! Decentralization. You speak of Swaraj — self-rule. But tell me, does this tool free people, or enslave them in new greed?

Satoshi:

That depends on the user. I built it so that no central bank, no emperor of finance, can erode the common man's savings.

Gandhi:

Hmm. That is noble. But in my land, I spun khadi — not to gain wealth, but to empower the weaver. Can your coin clothe the poor, feed the farmer?

Satoshi:

Not directly. But it can return power to local communities — if used wisely. It can fund clean water, create transparency in charity, help refugees carry value without paper.

Gandhi (thoughtfully):

Technology must serve the last man. The poorest. If your invention becomes the toy of the rich... it has failed its Dharma.

Satoshi (softly):

I agree. That's why I vanished. Power corrupts. I wished to spark something, not to rule over it.

Gandhi (smiling):

Then we share a path, my friend. The world will judge our ideas — not by their cleverness, but by the compassion they inspire.

[A pause.]

The spinning wheel turns. The screen glows.

Gandhi leans forward:

You must promise me, Satoshi — build for the village, not just the venture capitalist.

Satoshi (grinning faintly):

Only if you promise to try a Raspberry Pi.

[Fade out.]

The revolution continues — in code, in conscience, and in khadi.

Very few people are truly 'cut out' for programming in the way it's traditionally taught or practiced

Prahlad Yeri — Sat, 05 Apr 2025 03:16:13 +0000

Nobody is truly that "cut out" for programming. We might be emotional and biological machines, but we aren't logical circuit boards. As humans, we are wired to appreciate patterns in life and relationships, not binary 1s and 0s. However, coding patterns like decision trees, loops, recursions, etc. also do feel interesting as long as they produce interesting and utilitarian software which feels like magic.

But when the drudgery of programming sets in and all you're seeing is just heaps and mounds of instructions that need hours to fathom their working, even the best of programmers feel like leaving the field and running away! And that's exactly why things like no-code, low-code, AI assisted development, frameworks and packages, etc. are becoming so popular increasingly. Humans aren't "natural" programmers in that sense, they're primarily story tellers and meaning seekers in life.

Unlocking Text from Embedded-Font PDFs: A pytesseract OCR Tutorial

Prahlad Yeri — Sun, 01 Dec 2024 06:59:06 +0000

Extracting text from a PDF is usually straightforward when it's in English and doesn't have embedded fonts. However, once those assumptions are removed, it becomes challenging to use basic python libraries like pdfminer or pdfplumber. Last month, I was tasked with extracting text from a Gujarati-language PDF and importing data fields such as name, address, city, etc., into JSON format.

If the font is embedded in the PDF itself, simple copy-pasting won't work, and using pdfplumber will return unreadable junk text. Therefore, I had to convert each PDF page to an image and then apply OCR using the pytesseract library to "scan" the page instead of just reading it. This tutorial will show you how to do just that.

Things you will need

pdfplumber (Python library)
pdf2image (Python library)
pytesseract (Python library)
tesseract-ocr

You can install the Python libraries using pip commands as shown below. For Tesseract-OCR, download and install the software from the official site. pytesseract is just a wrapper around the tesseract software.

pip install pdfplumber
pip install pdf2image
pip install pytesseract

Converting the PDF page to an image

The first step is to convert your PDF page to an image. This extract_text_from_pdf() function does exactly that-you pass the PDF path and the page_num (zero indexed) as parameters. Note that I'm converting the page to black and white first for clarity, this is optional.

# Extract text from a specific page of a PDF
def extract_text_from_pdf(pdf_path, page_num):
    # Use pdfplumber to open the PDF
    pdf = pdfplumber.open(pdf_path)
    print(f"extracting page {page_num}..")
    page = pdf.pages[page_num]
    images = convert_from_path(pdf_path, first_page=page_num+1, last_page=page_num+1)
    image = images[0]
    # Convert to black and white
    bw_image = convert_to_bw(image)
    # Save the B&W image for debugging (optional)
    #bw_image.save("bw_page.png")
    # Perform OCR on the B&W image
    e_text = ocr_image(bw_image)
    open('out.txt', 'w', encoding='utf-8').write(e_text)
    #print("output written to file.")
    try:
        process_text(page_num, e_text)
    except Exception as e:
        print("Error occurred:", e)
    print("done..")

# Convert image to black and white
def convert_to_bw(image):
    # Convert to grayscale
    gray = image.convert('L')
    # Apply threshold to convert to pure black and white
    bw = gray.point(lambda x: 0 if x < 128 else 255, '1')
    return bw

# Perform OCR using Tesseract on a given image
def ocr_image(image_path):
    try:
        # Perform OCR
        custom_config = r'--oem 3 --psm 6 -l guj+eng'
        text = pytesseract.image_to_string(image_path, config=custom_config)  # --psm 6 treats the image as a block of text
        return text
    except Exception as e:
        print(f"Error during OCR: {e}")
        return None

The ocr_image() function uses pytesseract to extract text from the image through OCR. The technical parameters like --oem and --psm control how the image is processed, and the -l guj+eng parameter sets the languages to be read. Since this PDF contained occasional English text, I used guj+eng.

Processing the text

Once you've imported the text using OCR, you can parse it in the format you want. This works similarly to other PDF libraries like pdfplumber or pypdf2.

nums = ['0', '૧', '૨', '૩', '૪', '૫', '૬', '૭', '૮', '૯']

def process_text(page_num, e_text):
    obj = None
    last_surname = None
    last_kramank = None
    print(f"processing page {page_num}..")
    for line in e_text.splitlines():
        line = line.replace('|', '').replace('[', '').replace(']', '')
        parts = [word for word in line.split(' ') if word]
        if len(parts) == 0: continue
        new_rec = True
        for char in parts[0]:
            if char not in nums:
                new_rec = False
                break
        if len(parts) < 2: continue

        if new_rec and len(parts[0]) >= 2: # numbered line
            if len(parts) < 9: continue
            if obj: records.append(obj)
            obj = {}
            last_surname = parts[1]
            obj['kramank'] = parts[0]
            last_kramank = parts[0]
            obj['full_name'] = ' '.join(parts[1:4])
            obj['surname'] = parts[1]
            obj['pdf_page_num'] = page_num + 1
            obj['registered_by'] = parts[4]
            obj['village_vatan'] = parts[5]
            obj['village_mosal'] = parts[6]
            if parts[8] == 'વર્ષ':
                idx = 7
                obj['dob'] = parts[idx] + ' વર્ષ'
                idx += 1
            elif len(parts[7]) == 8 and parts[7][2] == '-':
                idx = 7
                obj['dob'] = parts[idx]
            else:
                print("warning: no date")
                idx = 6
            obj['marital_status'] = parts[idx+1]
            obj['extra_fields'] = '::'.join(parts[idx+2:-2])
            obj['blood_group'] = parts[-1]
        elif parts[0] == last_surname: # new member in existing family
            if obj: records.append(obj)
            obj = {}
            obj['kramank'] = last_kramank
            obj['surname'] = last_surname
            obj['full_name'] = ' '.join(parts[0:3])
            obj['pdf_page_num'] = page_num + 1
            obj['registered_by'] = parts[3]
            obj['village_vatan'] = parts[4]
            obj['village_mosal'] = parts[5]
            if len(parts) <= 6: continue
            if parts[7] == 'વર્ષ': # date exists
                idx = 6
                obj['dob'] = parts[idx] + ' વર્ષ'
                idx += 1
            elif len(parts[6]) == 8 and parts[6][2] == '-':
                idx = 6
                obj['dob'] = parts[idx]
            else:
                print("warning: no date")
                idx = 5
            obj['marital_status'] = parts[idx+1]
            obj['extra_fields'] = '::'.join(parts[idx+2:-2])
            obj['blood_group'] = parts[-1]
        elif obj: # continuation lines
            if ("(" in line and ")" in line) or "મો.ઃ" in line:
                obj['extra_fields'] += ' ' + '::'.join(parts[0:])
    if obj: records.append(obj)        
    jstr = json.dumps(records, indent=4)
    open("guj.json", 'w', encoding='utf-8').write(jstr)
    print(f"written page {page_num} to json..")

Every PDF has its own nuances that must be accounted for. In this case, a new serial number (like 0૧ or 0૨) in the first field signaled a new group when the subsequent field (surname) changed.

pytesseract is a testament to the evolution and advancement in IT technology. About a decade ago, reading or parsing a PDF image using OCR in a non-English language on a modestly configured PC or laptop would have been nearly impossible. This is truly progress! Happy coding, and let me know how it goes in the comments below.

References

Beyond Google: the future of shopping and search with ChatGPT

Prahlad Yeri — Wed, 13 Nov 2024 17:00:49 +0000

I've been an indie tech blogger for several years, and the gradually declining page views and organic traffic point toward only one thing: The reach and omniscience of Google Search are on the decline as more people become addicted to ChatGPT. If you keep an ear out on blogging and SEO subs, you'll hear the same thing.

When I interact with ChatGPT today, stepping out of my programming shoes and evaluating it as a layperson, I see that the potential here is enormous and very much within the realms of technical feasibility. Many Android apps could vanish from our phones if a few key players, like OpenAI, decide to take the initiative. Imagine a chat with an LLM called BBGPT that's linked to BigBasket:

Me: Hey BB, please create an order for 1 kg of sugar, 4 packets of Nandini Blue Milk, and 800 grams of Parle-G biscuits.

BB: Sugar from the Popular or Royal brand?

Me: Which one tastes better and is healthier?

BB: They're usually the same for most practical purposes, but you can check the nutrition facts here, if you're interested.

Me: All right, please confirm the order!

BB: I've just sent a Google Pay request for UPI payment.

Me: (Makes the payment).

BB: Your order is confirmed! Let me know if I can do anything else for you today.

Me: Thanks BB, you're a great buddy!

This is 10x more efficient than placing an order on BigBasket app or website, or any online order for that matter! It's only a matter of time before someone figures this out and starts rolling these changes out.

About a decade ago, in 2014, if I had told you that something similar to Tom Riddle's Diary would give a tough competition to the greatest search engine on the planet, you'd probably have laughed at me! But not today, with the advent of ChatGPT.

The future is here. The technology is ready. It's only a matter of who, when, and how someone will take the initiative! What do you think about this? Please let me know in the comments.

The whole “shameless plug” conundrum and stigma associated with sharing one’s own blog posts

Prahlad Yeri — Thu, 07 Nov 2024 17:50:35 +0000

Traditionally, there has been a significant stigma associated with sharing one’s own posts on platforms like Reddit, Facebook, Twitter/X, and others. Moderators often discourage such behavior or at least try to limit it. Terms like “self-promotion” and “blogspam” are frequently used to create a sense of disgust or guilt, especially towards indie bloggers or writers who share their posts or articles.

To be fair, there have been quality issues on the other side as well, and in many cases, the content may deserve to be ignored or removed. However, there is always a better way to communicate or send a message. Our efforts should focus on nurturing creativity, not crushing it under our feet the moment it starts to show signs of life on the internet.

Moreover, the world seems to be becoming increasingly unfair with each passing day. On one hand, indie bloggers are guilt-tripped and admonished by moderators for sharing their content. On the other, big players with deep pockets have their low-quality content promoted across the internet simply because they’ve paid to do so.

Despite the materialist ethics of our current times, which often tilt in favor of those who pay the big bucks, the works of smaller creators and indie bloggers deserve at least a small chance — a tiny window of opportunity to share their stories with the online world.

Through this open letter, I want to strongly appeal to the decision-makers and CTOs who control the largest social networks and search engine algorithms: giving that tiny window to an indie blog post may not make immediate financial sense for shareholders, but it does contribute to making the world — and the online space — better and more organic. Think about it, and if possible, act to make it happen!

The illusion of simplicity: how OOP can overcomplicate simple problems

Prahlad Yeri — Tue, 05 Nov 2024 14:37:45 +0000

Object-oriented programming (OOP) has been hailed as the savior of the software world, promising more manageable codebases and scalable applications. From encapsulation to inheritance, the paradigm offers a toolkit that is designed to make developers’ lives easier. Yet, over the years, OOP has gained its fair share of critics who argue that the principles it upholds can often lead to overcomplication—especially when applied to simple problems. So, is OOP truly the answer to every software challenge, or is it an illusion of simplicity, cloaking unnecessary complexity beneath a facade of best practices?

In this deep dive, we’ll explore why the abstraction and encapsulation principles of OOP might be overkill for simple problems and when sticking to basic solutions or alternative paradigms can lead to more effective and maintainable code.

The promise of object-oriented programming: simplicity through abstraction

The core philosophy of OOP is to model software as a collection of objects that interact with each other. It’s akin to representing the real world in code. Principles like inheritance, polymorphism, and encapsulation provide a way to make code modular, reusable, and maintainable. In theory, this sounds like an absolute win.

Consider an example of a basic Car class:

class Car {
    private String color;
    private int speed;

    public Car(String color, int speed) {
        this.color = color;
        this.speed = speed;
    }

    public void drive() {
        System.out.println("The car is driving at " + speed + " km/h.");
    }

    public void repaint(String newColor) {
        this.color = newColor;
    }
}

On the surface, it looks quite simple and intuitive. If you want to create a car, you instantiate an object with a color and speed, and you can make it drive or repaint it with a method. It's elegant—until complexity starts creeping in.

When simple tasks become complex

The illusion of simplicity in OOP begins to unravel when basic requirements evolve. Let's say we need to support a new vehicle type: a truck. Following OOP principles, you may introduce a Truck class that inherits from Car, or you might abstract both into a common superclass called Vehicle. It looks like a small addition, but such minor changes snowball over time.

Layers of abstraction: How complexity multiplies

In larger OOP-based systems, creating classes for every concept or behavior quickly results in a deep inheritance hierarchy. A simple problem, like managing vehicles, might require dozens of classes and interfaces due to enforced abstraction.

For instance, to accommodate more types like electric cars and motorcycles, you might structure a hierarchy like this:

Vehicle (superclass)
- Car (inherits from Vehicle)
- ElectricCar (inherits from Car)
- Truck (inherits from Vehicle)
- Motorcycle (inherits from Vehicle)

If you now need to add a behavior like calculateMaintenanceCost(), you could end up writing it in multiple places or creating an additional abstraction to handle it.

Encapsulation and its trade-offs

Encapsulation is another tenet of OOP that often contributes to this complexity. While encapsulation helps in hiding internal states and only exposing necessary details, enforcing this for simple problems can create a tangled mess of getters, setters, and boilerplate methods.

For instance, if the internal state of an object is simple, having strict getters and setters can lead to code that is difficult to refactor. It also creates an illusion that these methods are somehow necessary for safety or maintainability when the underlying data could be as simple as a couple of fields.

This proliferation of unnecessary boilerplate has even led to entire frameworks (like JavaBeans or Lombok in Java) existing solely to reduce the drudgery of writing these repetitive pieces of code. And at that point, you need to ask: Are we truly simplifying things?

Why OOP may not be the best fit for simple problems

Misalignment with the problem domain

In many cases, using an OOP approach to solve a simple problem can feel like over-engineering. If all you need is a script that calculates the sum of integers from 1 to 1000, writing a class named IntegerSummationService with multiple methods for "abstraction" is absurdly unnecessary.

Functional paradigms: Less fluff, more focus

Functional programming (FP) has gained traction as an alternative to OOP precisely because of its emphasis on simplicity and immutability. FP offers the flexibility of defining isolated functions, leading to more straightforward code for many straightforward problems.

For instance, consider how a vehicle maintenance cost might be handled in a functional style:

def calculate_maintenance(vehicle_type, age):
    if vehicle_type == 'car':
        return 200 + (age * 10)
    elif vehicle_type == 'truck':
        return 500 + (age * 20)
    else:
        return 100 + (age * 5)

No need for a sprawling class hierarchy; the logic is contained within a small, easy-to-understand function.

Procedural simplicity for simple needs

Sometimes, basic procedural programming—writing simple scripts and functions—can be more than adequate. For tasks like file reading, processing CSVs, or generating reports, there's often no tangible benefit to wrapping the logic in classes or objects. The code remains more readable and easier to maintain without the OOP overhead.

The pitfalls of enforced best practices

The notion that OOP is the only way to organize code is a fallacy that often leads developers to overthink basic solutions. A classic example of this can be seen in frameworks that enforce design patterns, such as Model-View-Controller (MVC). While MVC is great for complex applications, forcing it on a simple CRUD application can lead to unnecessary classes, interfaces, and abstract factories.

It’s like forcing every home cook to set up a professional kitchen just to make a bowl of cereal.

An anecdote: The battle with classes and interfaces

Here’s a story that many developers can relate to. I once worked on a project where a senior developer insisted that every single domain object needed an accompanying factory class. For example, to instantiate an order, we had to go through an OrderFactory. This was justified as a best practice, and when I inquired about what it achieved, the answer was always the same: “It’s good design.”

What it ended up achieving was hundreds of lines of boilerplate code and confused junior developers who spent more time understanding factories than solving actual business problems.

When OOP works, and when it doesn’t

Of course, there are situations where OOP shines. For large-scale systems with numerous entities and relationships—such as banking systems, e-commerce platforms, or content management systems—OOP can help manage the complexity effectively. The benefits of encapsulation, polymorphism, and inheritance pay off in these scenarios.

However, using the same hammer for every nail isn’t always the right strategy. For smaller projects or simple tasks, other paradigms like functional programming, scripting, or procedural code can be more straightforward, easier to maintain, and require less boilerplate.

The key takeaway: balance over zealotry

The takeaway here is not to discard OOP altogether. It’s a valuable tool, but one that needs to be wielded judiciously. Treating it as a panacea can lead to an illusion of simplicity that hides layers of unnecessary complexity. As developers, we must remain adaptable, choosing the right paradigm based on the problem at hand rather than blindly adhering to OOP principles.

The next time you’re about to design a new system or refactor an existing one, ask yourself: Is OOP truly the simplest solution?

Robots.txt pitfalls: what I learned the hard way

Prahlad Yeri — Sun, 27 Oct 2024 05:08:15 +0000

This applies to sites indexed on Google that hope to gain organic traffic. As an indie blogger and SEO enthusiast, I foolishly updated my robots.txt file to prevent indexing of certain unwanted parts of my site, leading to subtle repercussions that I couldn't have foreseen.

A few days ago, while reading about SEO, I came across the concept of a "crawl budget." Apparently, Google allocates a specific crawl budget to your indexed site, and the more useless content it has to index and store on its servers, the more it affects your site—resulting in delays for new content indexing, favicon updates, and robots.txt crawling.

Being a minimalist and utilitarian, I decided to prevent indexing of the /uploads/ directory on my site since it mostly contained images used in my articles. I thought blocking this "useless content" would free up more crawling budget for my primary content, i.e., articles. So, I added this directory to my site's robots.txt:

# Group 1
User-agent: *
Disallow: /public/
Disallow: /drafts/
Disallow: /theme/
Disallow: /page*
Disallow: /uploads/

Sitemap: https://prahladyeri.github.io/sitemap.xml

The way search engines work means there's typically a 5-7 day gap between updating the robots.txt file and crawlers processing it. After about a week, I noticed that my site's favicon disappeared from SERPs on mobile browsers! Instead, there was a bland (empty) icon in its place. That’s when I realized that my favicons also resided in the /uploads/ directory. After I recently optimized the favicon format by switching from WEBP to PNG, Google was unable to crawl and index the new favicon at all!

Once I realized this mistake, I removed the blocking of /uploads/ from the robots.txt and requested a recrawl. But who knows how long it will take for Google's systems to sync this change and start showing the site's favicon back in SERPs! Two lessons learned:

The robots.txt file is highly sensitive; avoid modifying it if possible.
Applying SEO is like steering an extremely large ship or vessel. You pull a lever now, and the ship only moves after several days!