Forem: Rohtash Sethi

What's the Hardest Part of Software Engineering? (Hint: It's Not What You Think)

Rohtash Sethi — Thu, 04 Sep 2025 06:11:24 +0000

After 10+ years and now working as a Principal Software Engineer, I've discovered the real challenge isn't in the code, it's in everything that happens around it.

Last week, I watched my wife (who happens to be a software engineer) spend three hours debugging what turned out to be a simple typo.

The fix? One character.

But here's what struck me: those three hours weren't wasted. They were spent thinking, investigating, and understanding the system. The actual typing took 30 seconds.

This perfectly captures the reality of software engineering that most people miss.

Whenever someone outside the tech world hears you're a software engineer, they usually imagine you're some kind of wizard, typing furious lines of code, fixing bugs in seconds, and pushing the next billion-dollar feature by lunchtime.

But the truth? Coding is not the hardest part of software engineering.

Sure, writing code can be tricky. But for most of us, especially after a few years of experience, syntax becomes second nature. We know the tools. We know the patterns. We've solved enough problems to know how to Google the rest.

The real challenge lies in everything that happens before, during, and after we write that code. It's the invisible mental work that determines whether our solutions actually solve problems or create new ones.

1. Understanding the Problem (The Real One)

Photo by Zuzana Ruttkay on Unsplash

Here's where things often start to wobble, and it's usually the biggest source of project delays.

In most projects, the hardest part is not writing the logic, it's figuring out what the actual problem is. You get a task for a feature request, and it seems simple enough:

"Add a filter to the dashboard."

Easy, right? Until you start asking questions:

What should the default behaviour be?
How should it interact with existing filters?
What happens when there's no data to filter?
How will this affect page load times with large datasets?
Should filters persist across user sessions?

Suddenly, you're not just adding a UI component, you're designing a feature that touches the database, affects user experience, and needs to scale.

The key insight: Most requirements are actually requirements in disguise. Your job is detective work first, coding second. The best engineers I know spend 30% of their time just making sure they're solving the right problem.

2. Brainstorming and Aligning on Solutions

Once you understand the problem, the next challenge is deciding how to solve it and getting everyone on the same page.

Picture this: You're in a meeting discussing that dashboard filter.

One engineer suggests adding it client-side for speed. Another wants a new microservice for scalability. The product manager just wants it "simple." The designer worries about mobile layouts.

This is where good teams separate themselves from struggling ones. The best solutions emerge when you can navigate these conversations effectively:

Evaluating trade-offs between speed and maintainability
Balancing current needs with future scalability
Considering team expertise and available time
Understanding the broader system implications

The challenge: There are usually multiple right answers, and you need to pick one that works for this context, this team, this moment. It's like playing chess while juggling, you're thinking three moves ahead while keeping current priorities in focus.

3. Naming Things and Designing Structure

Does this gives you nostalgia!

There's an old programming joke:

"There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors."

It's funny because it's painfully accurate.

I once spent 20 minutes naming a single function. Not because I couldn't think of a name, but because I wanted it to be clear, descriptive, appropriately scoped, and meaningful to future developers (including future me).

Then comes the structural decisions:

Where should this code live?
How do we organize these components?
What's the right level of abstraction?
Will someone understand this in six months?

Last month, I inherited a codebase where someone had named a critical function processStuff(). It took me two hours to understand what "stuff" actually meant and why it mattered.

The reality: You're not just coding for now, you're coding for the future. Every naming choice and structural decision is a message to future developers about how the system works and why it's designed that way.

4. Edge Cases and Real-World Complexity

Let's say you've implemented that dashboard filter. The happy path works perfectly.

"Users can filter by date, see results instantly, and everything looks great in your demo."

Then reality hits:

A user with 10,000 records tries to filter and the page crashes
Someone enters an invalid date format and breaks the UI
The API is slow and users see empty screens
A user with restricted permissions sees data they shouldn't
Mobile users can't scroll through filtered results

Remember! Nothing is as easy as it seams!

These edge cases aren't fun to think about, but they're what separate amateur projects from professional software. Engineering isn't just about building what works, it's about building something resilient that gracefully handles the unexpected.

The mental cost: Thinking through edge cases requires patience and methodical analysis. It's the difference between "it works on my machine" and "it works for our users in the real world."

5. Working with People, Not Just Code

Here's the plot twist that no computer science program adequately prepares you for:

"Software engineering is fundamentally a team sport."

Your daily work involves:

Translating business requirements with product managers
Collaborating on user experience with designers
Mentoring junior developers through complex problems
Getting architectural guidance from senior engineers
Reviewing code and providing constructive feedback
Explaining technical decisions to non-technical stakeholders

I've seen brilliant developers struggle because they couldn't communicate their ideas effectively. I've also seen average coders become invaluable team members because they excelled at collaboration and knowledge sharing.

The human element: Technical skills get you in the door, but people skills determine how far you'll go. Miscommunication leads to delays, frustration, and sometimes building the perfect solution to the wrong problem.

What Makes This So Challenging (And Rewarding)

The hardest part of software engineering isn't choosing between React and Angular, writing perfect SQL queries, or configuring cloud services (though AWS IAM permissions can be pretty brutal).

The hardest part is the thinking:

The thinking before you code
The thinking during implementation
The thinking afterward when you're making it better

Every line of code represents a decision, and those decisions compound over time. Choose poorly, and you'll be fighting technical debt for months. Choose well, and you've built something that can adapt and grow.

But here's the beautiful part: this is also where the real satisfaction lives. When you solve a genuine problem elegantly, when your code helps users accomplish something meaningful, when your architectural decisions make the next feature easier to build, that's the magic of software engineering.

If You're Struggling, You're Growing

If you ever feel mentally exhausted by these invisible challenges, that's not a sign of weakness, it's evidence you're doing the real work of engineering.

Software engineering has never been about typing fast or memorizing syntax. It's about thinking clearly under complexity, making thoughtful decisions with incomplete information, and building solutions that work for real people in the real world.

Here are three ways to embrace this reality:

Ask more questions upfront: Spend extra time understanding the problem before jumping to solutions. Those "annoying" clarifying questions prevent expensive mistakes later.
Invest in your communication skills: Practice explaining technical concepts to non-technical colleagues. The better you communicate, the better your solutions become.
Think like a future developer: When naming functions, designing APIs, or structuring code, ask yourself: "Will this make sense to someone else in six months?"

The next time someone asks what you do for work, you can tell them:

"I solve problems by thinking through complexity and building solutions that work reliably for real people."

Because that's the real work. And that's why it matters.

What's the hardest part of software engineering for you? I'd love to hear about the invisible challenges you face daily. Share your thoughts in the comments below or connect with me on LinkedIn @rohtashsethi, let's start a conversation about the real work behind the code.

About the Author

Rohtash Sethi is a Principal Software Engineer at Sophos with over 10 years of experience building software solutions. While he primarily focuses on frontend development and Angular (and writes extensively about Angular), this post explores the broader challenges that transcend any specific technology stack.

As Co-founder of NG DELHI Community, Rohtash is passionate about mentoring and providing the guidance he wishes he'd had in his early career. He believes the most valuable lessons in software engineering often come from understanding the human and thinking aspects of the job, not just the technical ones.

He's always open to discussing the real challenges of software engineering, sharing experiences, or helping fellow developers navigate their careers.

Open for contributions!

Rohtash Sethi — Thu, 15 May 2025 13:05:27 +0000

Rohtash Sethi for NG DELHI

May 14 '25

We Use Angular: Discover the Companies Powering Their Products with Angular

#angular #opensource #community #frontend

Comments

3 min read

🔍 Angular Challenge #1: Understanding OnPush Change Detection in Angular

Rohtash Sethi — Wed, 14 May 2025 19:53:16 +0000

Welcome to the Angular Daily Challenge Series, where we decode real-world Angular concepts through fun and practical coding puzzles. This article dives into a common interview-level topic: OnPush change detection in Angular.

Let's analyze today's challenge and uncover the behavior of ChangeDetectorRef and OnPush.

❓ Angular OnPush Change Detection Challenge

Here's the scenario:

@Component({
  selector: 'app-child',
  template: `
    <h1>Child Component</h1>
    <span>{{ data().text }}</span>
  `,
  changeDetection: ChangeDetectionStrategy.OnPush,
})
export class ChildComponent {
  data = input.required<{ text: string }>();
}

@Component({
  template: `
    <h1>Parent Component</h1>
    <app-child [data]="data" />
  `,
})
export class ChangeDetectionComponent {
  #cdRef = inject(ChangeDetectorRef);
  data = { text: 'Hello from Parent!' };

  constructor() {
    setTimeout(() => {
      this.data.text = 'Updated from Parent!';
      // Ensure the change is visible in the OnPush child
      this.#cdRef.detectChanges();
    }, 3_000);
  }
}

✅ What Will Be Displayed in the Child After 3 Seconds?

✅ Output: "Updated from Parent!"

But why does this happen? Let's break it down with a deeper look into Angular's change detection system.

🧠 How Angular OnPush Works

When you use ChangeDetectionStrategy.OnPush, Angular skips checking the component’s template unless one of these occurs:

The component receives a new reference via input signal
An event happens inside the component
Change detection is manually triggered using ChangeDetectorRef

🔄 Why Mutation Doesn’t Trigger OnPush Detection

In our example, we changed:

this.data.text = 'Updated from Parent!';

This modifies a property of the object but doesn't change the object reference, so Angular doesn't detect this change on its own.

Hence, Angular won't rerender the child unless we force it using:

this.#cdRef.detectChanges();

This is how we manually notify Angular to run change detection for all components, including OnPush ones.

💡 Bonus Tip: `3_000` vs `3000` in JavaScript

You might have spotted:

setTimeout(() => { ... }, 3_000);

This is JavaScript numeric separator syntax introduced in ES2021. It’s functionally identical to 3000, but more readable.

✅ Benefits:

Easier to read large numbers (1_000_000, 3_000)
Especially useful for time intervals, byte sizes, and money values

✅ Use it in modern Angular projects, it improves code clarity without affecting performance.

🔍 Learnings Recap

Concept	Description
`ChangeDetectionStrategy.OnPush`	Optimizes performance by skipping change detection unless needed
`ChangeDetectorRef.detectChanges()`	Manually triggers Angular’s change detection
Mutating object properties	Doesn’t trigger OnPush if the reference is unchanged
`3_000` in `setTimeout`	JavaScript numeric separator for better readability

📣 Challenge for You: Can You Optimize This?

In this challenge, we manually triggered change detection. But is that always the best approach?

🔁 Explore These Alternatives:

✅ Use immutable patterns: Replace the object entirely using this.data = { text: 'Updated' }
⚡ Adopt Angular Signals (Angular 17+): Better reactivity with built-in efficiency
🧠 Try markForCheck() instead of detectChanges() in some cases

💬 What’s your go-to strategy for handling OnPush changes? Drop your ideas and code snippets in the comments!

🙌 Stay Connected

👨🏻‍💻 Follow Rohtash Sethi 👨‍💻🥷🌟 for daily Angular challenges, JavaScript insights, and performance tips!

We Use Angular: Discover the Companies Powering Their Products with Angular

Rohtash Sethi — Wed, 14 May 2025 19:10:47 +0000

Tired of hearing “Nobody uses Angular anymore”?

Ever been told to 'just switch to React'? Same. But what if I told you that Angular is quietly powering hundreds of real-world apps, from startups to enterprises?

Let’s put that myth to rest, with facts, logos, and code commits.

🎯 The Problem

As Angular developers, we’ve all been there:

"React is the default."

"Angular is too enterprise-y."

"Is anyone even hiring for Angular anymore?"

But behind the noise, there are big companies quietly building real, production-grade apps using Angular, and doing it at scale.

The only problem? This information is scattered, hard to find, and often not public.

🚀 The Solution: We Use Angular

Ng-Delhi, an Angular community from Delhi NCR (India), has launched the We Use Angular initiative — a GitHub-powered, open-source directory of companies using Angular.

🔗 👉 Visit the GitHub Repo

🧭 Why This Matters

Too often, developers struggle to find:

Companies that are committed to Angular
Jobs that match their Angular skillset
Proof that Angular is still very much alive

That’s where We Use Angular comes in.

✅ It showcases real-world usage

✅ Helps job-seekers target the right companies

✅ Celebrates Angular’s presence in the wild

“This initiative was born after mentoring juniors who were confused about Angular's future. We wanted to give them, and all of us, clarity and hope.”

🗂️ What You'll Find in the Repo

We’ve curated a list of companies that use Angular in production.

📦 The repo includes:

🌐 Company name + website
🏷️ Industry segment
📍 Region or headquarters
🏢 Work Mode (On-Site / Remote / Hybrid)
🧱 Tech Stack (Frontend + Backend + DB + Hosting, etc.)
🛠️ Angular usage context (if known)
🖼️ Logo gallery (coming soon!)

We’ve already listed 33+ companies, and it’s growing fast!

🙌 How You Can Contribute

You don’t have to be a Git master to help out. We’ve got multiple ways for you to participate:

🔧 Option 1: Raise a PR

Familiar with GitHub? Just fork the repo and submit a Pull Request.

💬 Option 2: Community Submissions (No Git Required!)

Tag @NgDelhi on LinkedIn with the company name
Reply to our LinkedIn announcement posts
🐛 Open a GitHub issue with the company details
📥 Drop details in our Ng Delhi community chat

Your one submission might help someone land their dream job.

🏆 Recognition & Credits

Every contributor gets public credit for their help in growing the Angular ecosystem!

✅ Your name will appear in the Contributors section of our GitHub repo
✅ We'll give shoutouts from the Ng Delhi LinkedIn page
✅ Top contributors will be featured in our leaderboards and events

Because your contributions matter, and should be seen by the community 🌟

📢 Spread the Word

If you believe in Angular and want to support the ecosystem, here’s how you can help:

⭐ Star the GitHub repo
🔁 Repost this blog or share it with your Angular circle
🧑‍💻 Contribute a company you know uses Angular

Let’s make Angular visible again. Let’s show the world: We Use Angular.

🧡 Final Thoughts

Angular isn’t dead — it’s thriving in companies that value structure, scale, and maintainability. We just need to make its impact visible.

Join us in this movement. Help us build a better map for Angular devs, job seekers, and tech leaders alike.

👥 About Ng-Delhi

We’re a passionate Angular community from Delhi NCR (India), dedicated to sharing knowledge, organizing meetups, and contributing to open-source.

🟦 Ng Delhi on LinkedIn
🐙 Ng Delhi on GitHub

💬 Your Turn!

🔥 Know a company that uses Angular?

🎯 Challenge yourself to submit just one today!

✍️ Like this post? Save it and share it.

⭐ Star the repo → We Use Angular on GitHub

💬 Comment below if you have a company to suggest!

🚀 Angular 20: What’s Coming

Rohtash Sethi — Tue, 13 May 2025 21:03:47 +0000

Angular continues to lead the way in enterprise web development with its commitment to high performance, scalability, and developer, friendly tools. With Angular 20 releasing on May 29, 2025, the framework is set to deliver groundbreaking new features that promise to elevate development workflows. But what truly sets Angular apart is not just its technical prowess, it’s the reliability of its release cycle, which ensures Angular evolves in a stable and predictable way. Let’s explore what’s coming in Angular 20 and why the Angular team's disciplined release schedule is a major asset for developers.

🌟 What’s Coming in Angular 20?

Angular 20 introduces several exciting enhancements designed to boost performance, improve the developer experience, and keep up with modern web standards. Here's a closer look at the most anticipated features:

⚡ Zoneless Change Detection

What’s New in Angular 20?
Developer preview of zoneless change detection, moving away from Zone.js.
Why You Should Care:
- Faster rendering for better performance.
- Smaller application bundle sizes.
- Simplified debugging without the need for Zone.js.

Key Benefit: This feature will enable faster updates in your applications, improving the overall performance and reducing the size of your deployed code.

🧩 Selectorless Components

What’s New in Angular 20?
Import components directly into templates without using selectors.
Why You Should Care:
- Less boilerplate code.
- Easier component refactoring and streamlined usage.

Key Benefit: This change simplifies code by reducing the need for manually managing component selectors, making templates more readable and maintainable.

🧪 Enhanced Testing Facilities

What’s New in Angular 20?
The default test runner options now include Web Test Runner, Vitest, and Jest, with Karma deprecated.
Why You Should Care:
- Faster, more modern testing workflows.
- Support for modern testing libraries and tools.

Key Benefit: This change will result in faster test execution, giving developers quicker feedback and enabling them to catch issues early.

⚙️ Incremental Hydration & Flexible Rendering

What’s New in Angular 20?
Stabilized incremental hydration for server-side rendering (SSR).
Why You Should Care:
- Faster load times.
- Better SEO through server-side rendering improvements.
- Enhanced user experience with improved interactive elements.

Key Benefit: Incremental hydration improves the rendering of SSR pages, making them more interactive sooner, thus enhancing the user experience.

🔄 Reactive API Improvements

What’s New in Angular 20?
Stabilization of the effect API and a preview of resource APIs for handling async data.
Why You Should Care:
- Easier management of side effects and asynchronous operations.
- Enhanced support for modern reactive programming paradigms.

Key Benefit: With these improvements, developers can handle async logic more effectively, resulting in cleaner, more maintainable code.

♿ Accessibility Primitives

What’s New in Angular 20?
New built-in utilities aimed at improving accessibility.
Why You Should Care:
- Simplified implementation of inclusive, accessible applications.
- Enhanced compliance with accessibility standards.

Key Benefit: Angular 20 makes it easier to ensure your applications are accessible to all users, improving user experience and adhering to legal standards.

🏷️ Tagged Template Literals in Templates

What’s New in Angular 20?
Full support for tagged template literals in Angular templates.
Why You Should Care:
- Modernized syntax for easier inline templates.
- Improved tooling and code readability.

Key Benefit: Tagged template literals make it easier to handle dynamic content within templates, providing a more intuitive syntax for developers.

🔁 Two-Way Binding for Dynamic Components

What’s New in Angular 20?
Support for two-way data binding with dynamically created components.
Why You Should Care:
- Simplifies data flow in dynamic UIs.
- Reduces boilerplate code and improves reactivity.

Key Benefit: This new feature helps developers manage data in dynamic components more effectively, making it easier to create complex user interfaces.

🤖 AI-Assisted Development Tools

What’s New in Angular 20?
AI-powered linting and CLI recommendations to assist with development.
Why You Should Care:
- Boosts productivity by offering intelligent code suggestions.
- Helps catch potential errors early in the development process.

Key Benefit: With AI-powered assistance, developers can be more productive and write better code with fewer errors.

📅 Angular 20 Release Date: Mark Your Calendar!

The official release date for Angular 20 is May 29, 2025. On the same day, the Angular team will host a developer event at 9 AM PDT to showcase new features and provide insights into the future of Angular development. Be sure to tune in and stay up-to-date with all the latest updates from the Angular team! Event details here.

🗓️ The Angular Release Cycle: Predictability That Drives Progress

One of Angular’s key advantages is its predictable and transparent release schedule, ensuring that developers can plan their projects with confidence.

“A major release every 6 months · 1-3 minor releases per major release · A patch release and pre-release (next or rc) build almost every week.”

How It Works

Major Releases: Every 6 months (introduces big features & improvements).
Minor Releases: 1-3 per major release (smaller enhancements, always backward-compatible).
Patch Releases: Almost weekly (bug fixes and stability improvements).
Pre-releases: “Next” and “Release Candidate” builds for early previews.

Why This Matters

Stability & Planning: Teams can confidently schedule upgrades and feature releases.
Access to Innovation: Developers get early access to features and stable, production-ready updates.
Long-Term Support: Each major release gets 18 months of support (6 months active, 12 months LTS) [^3][^5].

🏆 Angular’s Evolution: A History of Consistency

Since Angular 4 (released in March 2017), the framework has maintained its six-month release rhythm, ensuring a steady flow of innovation without sacrificing stability. This predictability makes Angular a trusted choice for large-scale, long-term projects.

✨ Conclusion: The Future of Web Development

Angular 20, releasing on May 29, 2025, is packed with powerful new features that will streamline development, enhance performance, and support modern web standards. But just as important is the Angular team’s commitment to a predictable, transparent release cycle. This ensures developers can innovate with confidence, knowing Angular will continue to evolve with their needs in mind.

Ready to Upgrade?

Check out the official Angular update guide and join the community as we embrace the future of web development together! 🚀

References

Why TypeScript Enums Increase Angular Bundle Size and How to Fix It

Rohtash Sethi — Mon, 12 May 2025 04:52:46 +0000

When optimizing Angular applications for performance, developers often overlook a silent culprit: TypeScript enums. While enums improve code readability and type safety, they introduce unexpected overhead in your final JavaScript bundle. This can lead to larger file sizes, slower load times, and diminished performance, especially on mobile or low-bandwidth connections.

In this article, we'll explore how enums contribute to bundle bloat, why Angular's build tools struggle to optimize them, and which alternatives you can use to write cleaner, faster, and more efficient code.

🚩 The Problem with TypeScript Enums in Angular

What Are Enums in TypeScript?

An enum is a TypeScript feature that lets you define a set of named constants. For example:

export enum UserRole {
  Admin,
  Editor,
  Viewer
}

Under the hood, this compiles to something like:

"use strict";
var UserRole;
(function (UserRole) {
    UserRole[UserRole["Admin"] = 0] = "Admin";
    UserRole[UserRole["Editor"] = 1] = "Editor";
    UserRole[UserRole["Viewer"] = 2] = "Viewer";
})(UserRole || (UserRole = {}));

That’s a bi-directional object: you can look up a value by key and vice versa.

🔍 Why Enums Bloat Angular Bundle Size

1. Bi-Directional Mapping = More Code

TypeScript enums emit extra JavaScript to support both directions.
This results in:
- Extra object initialization code
- More JavaScript in your output
- Each import of an enum adds to your bundle

2. Poor Tree-Shaking Support

Enums are treated as live objects with potential side effects.
Tree-shakers cannot safely eliminate unused enum members.
The entire enum stays even if you use just one value.

3. Repeated Across Lazy-Loaded Modules

Enums used in shared files may be duplicated in chunks.
Wastes KBs across multiple modules.

📊 Impact Example

Bundle Size Comparison

Feature	Size Increase
1 Simple Enum (`UserRole`)	+300B
10 Enums (average size)	+3KB
Complex Enum with String Values	+500–700B per enum

Multiply this across dozens of enums and you could see a significant increase in final bundle size.

🛠️ Alternatives to Enums

1. String Literal Union Types

type UserRole = 'Admin' | 'Editor' | 'Viewer';

Pros:

No runtime JavaScript
Fully tree-shakable
IDE support for autocomplete
Smaller bundle size

Cons:

No reverse mapping
No built-in iteration

2. Constant Objects with `as const`

export const UserRole = {
  Admin: 'Admin',
  Editor: 'Editor',
  Viewer: 'Viewer'
} as const;

export type UserRole = typeof UserRole[keyof typeof UserRole];

Pros:

Zero runtime cost beyond plain objects
Type-safe
Retains structure similar to enums

Cons:

Still an object, but no reverse mapping
Slightly more verbose

3. Use `const enums` with Caveats

const enum UserRole {
  Admin,
  Editor,
  Viewer
}

Pros:

Inlined during compilation (zero JS output)
No runtime cost
Very small bundle footprint

Cons:

Requires preserveConstEnums: false in tsconfig
Cannot use with libraries or emitDeclarationOnly workflows
No reverse mapping

⚠️ Note: const enums can break third-party tooling and are not always compatible with Angular CLI settings.

💡 Best Practices

Use string literal unions for simple sets of constants.
Use as const objects when you need iterable values or more structure.
Use const enums cautiously and only in internal modules or performance-critical code paths.
Avoid using enums in shared interfaces or models passed between many modules.

✅ Summary Table

Method	Tree-shakable	Bundle Size	Reverse Mapping	IDE Support	Safe for Libraries
`enum`	❌ No	⬆️ High	✅ Yes	✅ Yes	✅ Yes
`const enum`	✅ Yes	✅ Minimal	❌ No	✅ Yes	❌ No
`string union`	✅ Yes	✅ Minimal	❌ No	✅ Yes	✅ Yes
`as const` object	✅ Yes	✅ Minimal	❌ No	✅ Yes	✅ Yes

🧠 Final Thoughts

Enums are elegant and readable, but in Angular apps where performance matters, they can be surprisingly heavy. By understanding how TypeScript compiles enums and how Angular handles them in the build process, you can make smarter choices and keep your bundles fast and slim.

💬 If you’re building a performance-sensitive Angular application, ditch the enums, your users (and Lighthouse score) will thank you.

👩‍💻 Can You Build This Website? Yes, You Can in 2025!

Rohtash Sethi — Sat, 03 May 2025 03:41:02 +0000

👋 Hey future developers!

The next time you’re using a website, ask yourself: Can I build this?
If that question sparks even a little curiosity, frontend development might just be your thing.

And in 2025, there's never been a better time to dive in.

💡 Why Learn Frontend?

Frontend is more than just styling buttons and writing code—it’s where your ideas come to life. Here’s why it’s worth exploring:

🎨 Combine creativity with logic
🧱 Turn designs into real, usable websites
🌍 Reach and impact millions of users
💼 Stay in-demand—every tech company needs frontend skills
💻 Start with just a laptop and a browser

If you like seeing results fast and making things people can use, the frontend is for you.

🛠️ What to Learn: Frontend Core Skills for 2025

Here’s a simple roadmap to get you going:

Skill	Why It Matters
HTML, CSS, JavaScript	The “holy trinity” of the web—essential for every frontend dev.
Git & GitHub	Track your code, collaborate, and build in public.
Responsive Design	Make your site work on all screen sizes.
TypeScript	A smarter, safer version of JavaScript. Companies love it.
Frontend Framework	Choose one: Angular, React, or Vue (try Angular 😉).
Dev Tools	Get comfy with VS Code, browser dev tools, and useful extensions.
Accessibility & SEO	Build for everyone and help your work get discovered.

🔗 Want a detailed, open-source roadmap? Check this out: roadmap.sh/frontend

🧠 The Student Mindset: How to Grow Fast

Success isn’t about being perfect, it’s about showing up consistently.

🕐 Start now, don’t wait for “the right time”
🧪 Learn by doing, not just watching tutorials
🌱 30 minutes daily beats 8 hours once a month
📢 Share your journey on GitHub, LinkedIn, or even a blog

Small steps add up. Build momentum with curiosity, not pressure.

🚀 Level-Up Ideas for 2025

Here’s how you can go from beginner to confident creator:

✅ Build simple projects: To-do list, portfolio, blog
🤝 Contribute to open source: Fix bugs or improve docs
🎥 Follow devs on YouTube, LinkedIn, and X (Twitter)
👥 Join communities (e.g., NG Delhi if you're in NCR!)
🏆 Attend hackathons: You’ll learn fast, and meet awesome people

🧭 8-Month Roadmap Snapshot

Months	Focus
1–2	Learn HTML, CSS, and JS basics
3	Build 2–3 small projects (e.g., Calculator, Weather App)
4	Learn a framework (Angular, React, or Vue)
5–6	Build a complete app (Blog, ToDo with login, etc.)
7	Learn Git, host projects (Netlify, Vercel, GitHub Pages)
8	Share your journey, ask for feedback, join a dev circle

🎯 By the end, you’ll have projects, a portfolio, and confidence.

✨ Final Thoughts

If you enjoy solving problems, being creative, and seeing your work come to life—frontend is for you.

You don’t need a degree to begin.
You just need:

🧠 Curiosity
❤️ Commitment
💪 A bit of courage

📣 Let’s Connect!

Got questions? Drop them in the comments.
Follow me for more frontend tips, motivation, and resources!

I18n in Web Apps Series Part-1

Rohtash Sethi — Fri, 22 Dec 2023 09:28:42 +0000

As a web developer, you must have developed many great web applications designed for a specific target audience in a specific region or country.

This practice is called Localization.

What is Localization?

Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a locale).

Localization is sometimes written in English as l10n, where 10 is the number of letters in the English word between l and n.

It includes customization related to:

Numeric, date and time formats
Use of currency
Keyboard usage
Collation and sorting
Symbols, icons and colors
Text and graphics containing references to objects, actions or ideas which, in a given culture, may be subject to misinterpretation or viewed as insensitive.
Varying legal requirements
and many more things.

Taking the product/service to the next level

Now, what if the business wants to scale and expand its reach to make their product/service accessible and adaptable to a diverse or global audience?

Ever wondered what practices a web developer needs to follow and implement to enable the expansion of business in multiple regions or countries so their audience can adapt and feel inclusive?

The answer to all above questions is Internationalization!

What is Internationalization?

Internationalization is the process of designing and developing products or services in a way that enables easy adaptation to different languages, cultures, and regions. It involves considering various aspects such as language translation, date and time formats, currency symbols, and cultural norms.

Internationalization is often abbreviated as i18n, where 18 is the number of letters between ‘i’ and ‘n’ in the English word.

By implementing internationalization best practices, businesses and organizations can reach a wider audience, increase user satisfaction, and improve their global market presence.

It is an essential aspect of software development, website design, and content creation, particularly for companies with a global customer base or expansion plans.

In addition to language and cultural adaptation, internationalization also involves considering other factors like time zones, measurement units, and regional preferences. It requires careful planning, collaboration with localization teams, and the use of standardized methodologies and tools.

Overall, internationalization plays a crucial role in breaking down language and cultural barriers, enabling effective communication, and providing inclusive experiences for users around the world.

In upcoming articles of this series, we will dive deeper into the actual aspects which will help us implement Internationalization in Web Apps.

Forem: Rohtash Sethi

What's the Hardest Part of Software Engineering? (Hint: It's Not What You Think)

1. Understanding the Problem (The Real One)

2. Brainstorming and Aligning on Solutions

3. Naming Things and Designing Structure

4. Edge Cases and Real-World Complexity

5. Working with People, Not Just Code

What Makes This So Challenging (And Rewarding)

If You're Struggling, You're Growing

Open for contributions!

We Use Angular: Discover the Companies Powering Their Products with Angular

🔍 Angular Challenge #1: Understanding OnPush Change Detection in Angular

❓ Angular OnPush Change Detection Challenge

✅ What Will Be Displayed in the Child After 3 Seconds?

🧠 How Angular OnPush Works

🔄 Why Mutation Doesn’t Trigger OnPush Detection

💡 Bonus Tip: 3_000 vs 3000 in JavaScript

✅ Benefits:

🔍 Learnings Recap

📣 Challenge for You: Can You Optimize This?

🔁 Explore These Alternatives:

🙌 Stay Connected

We Use Angular: Discover the Companies Powering Their Products with Angular

🎯 The Problem

🚀 The Solution: We Use Angular

🧭 Why This Matters

🗂️ What You'll Find in the Repo

🙌 How You Can Contribute

🔧 Option 1: Raise a PR

💬 Option 2: Community Submissions (No Git Required!)

🏆 Recognition & Credits

📢 Spread the Word

🧡 Final Thoughts

👥 About Ng-Delhi

💬 Your Turn!

🚀 Angular 20: What’s Coming

🌟 What’s Coming in Angular 20?

⚡ Zoneless Change Detection

🧩 Selectorless Components

🧪 Enhanced Testing Facilities

⚙️ Incremental Hydration & Flexible Rendering

🔄 Reactive API Improvements

♿ Accessibility Primitives

🏷️ Tagged Template Literals in Templates

🔁 Two-Way Binding for Dynamic Components

🤖 AI-Assisted Development Tools

📅 Angular 20 Release Date: Mark Your Calendar!

🗓️ The Angular Release Cycle: Predictability That Drives Progress

How It Works

Why This Matters

🏆 Angular’s Evolution: A History of Consistency

✨ Conclusion: The Future of Web Development

Ready to Upgrade?

References

Why TypeScript Enums Increase Angular Bundle Size and How to Fix It

🚩 The Problem with TypeScript Enums in Angular

What Are Enums in TypeScript?

🔍 Why Enums Bloat Angular Bundle Size

1. Bi-Directional Mapping = More Code

2. Poor Tree-Shaking Support

3. Repeated Across Lazy-Loaded Modules

📊 Impact Example

Bundle Size Comparison

🛠️ Alternatives to Enums

1. String Literal Union Types

2. Constant Objects with as const

3. Use const enums with Caveats

💡 Best Practices

✅ Summary Table

🧠 Final Thoughts

👩‍💻 Can You Build This Website? Yes, You Can in 2025!

💡 Why Learn Frontend?

🛠️ What to Learn: Frontend Core Skills for 2025

🧠 The Student Mindset: How to Grow Fast

🚀 Level-Up Ideas for 2025

🧭 8-Month Roadmap Snapshot

✨ Final Thoughts

I18n in Web Apps Series Part-1

What is Localization?

Taking the product/service to the next level

💡 Bonus Tip: `3_000` vs `3000` in JavaScript

2. Constant Objects with `as const`

3. Use `const enums` with Caveats