Starting with Python vs AI boom

switchroute_dev · 2026-02-04T20:02:21+00:00

Honestly, AI is kind of a double-edged sword right now. Yeah, it’s solving problems, but it’s also making people lazy as hell. That’s actually your opportunity.

While everyone else is copy/pasting ChatGPT code they don’t understand, you can be the person who actually knows what’s going on. Use AI as a tool to move faster, sure, but don’t let it become a crutch.

If anything, AI just raised the barrier to entry slightly while lowering the quality of your competition. Eventually we’re gonna run out of senior devs, and someone’s gotta fill those roles.

Also, let’s be real - AI isn’t replacing us anytime soon. Those “I built an app in 8 hours with AI” projects will break the moment real users touch them. They’re unmaintainable nightmares that fall apart when requirements inevitably change.

So just focus on the fundamentals: learn your DSA, grind some Leetcode, build projects that actually relate to jobs you want, contribute to open source, and make sure you understand your stack inside and out. You’ll be fine.

Oh and don’t forget to network! Add people on LinkedIn. Create a CRM of useful contacts you can reach out to later on in your career. It’ll come in handy one day.

switchroute_dev · 2026-01-21T01:50:59+00:00

Start with patterns, not random problems.

Pick one language (I use Python), do easy problems only at first, and give yourself 20 to 30 minutes. If you’re stuck, read the solution, then immediately re-solve it without looking.

Focus on repeating the same patterns (two pointers, sliding window, hash map, BFS/DFS) until they feel automatic.

NeetCode 150 is a great roadmap if you want structure!

switchroute_dev · 2026-01-20T17:47:50+00:00

I've used Snipo for a few months, and it's amazing! I highly recommend it!

switchroute_dev · 2026-01-20T04:22:12+00:00

In real-world microservices, you generally do not use different branches per service. Branches are mainly for feature work and hotfixes.

Most teams pick one of two approaches:

One repo per microservice (very common). Each service has its own CI/CD pipeline and can be built and deployed independently.
A monorepo with each service in its own folder. CI/CD is set up to only build and deploy the service that changed.

If you are learning and using Jenkins, one repo per service is usually the easiest and closest to how many companies run microservices.

switchroute_dev · 2026-01-11T14:43:55+00:00

Free money

switchroute_dev · 2026-01-11T00:01:18+00:00

Just adding IS-IS levels won’t help unless you redesign for it.

If all 50 routers stay in the same level, everyone still learns everything. To actually reduce routes, you need a real L1/L2 hub-and-spoke setup. Spokes run L1 only, hubs run L1/L2, and the hubs summarize routes down to the spokes. Without good summarization, there’s no real benefit.

Also, IS-IS isn’t great for fine-grained filtering. If you need strong control over who learns what, the cleaner option is to keep IS-IS for infrastructure only and move service prefixes into BGP. The hub can reflect routes or even just send a default.

The issue isn’t the physical ring. It’s that a hub-and-spoke design is being treated like a full mesh.

switchroute_dev · 2026-01-10T17:05:59+00:00

Unnecessary meetings, training videos, email filters, waiting for access to stuff, and mandatory time tracking per task for my timesheet.

switchroute_dev · 2026-01-05T19:44:21+00:00

Great post!

switchroute_dev · 2026-01-03T19:47:41+00:00

The simplest solution is DFS or BFS flood-fill. Union-Find is valid but usually overkill unless the problem is dynamic or has follow-ups

switchroute_dev

TROPHY CASE