𝔸𝕐𝕆𝔻𝔼𝕁𝕀

1% BETTER EVERYDAY 🎯

@EOEboh Please check dm

Interview Question: "Design a function that finds duplicate emails in our user database." 🔴 Candidate A: "Sure, I'll use a hash map" **starts writing code immediately** 🟢 Candidate B: "Great question. Before I start, can I clarify a few things?" Interviewer: "Of course" Candidate B: "First, how large is the dataset? Are we talking thousands or millions of users?" Interviewer: "About 50 million" Candidate B: "Got it. Should I consider emails case-insensitive? Like, is 'User@mail.com' the same as 'user@mail.com'?" Interviewer: "Yes, treat them as the same" Candidate B: "Perfect. And what should I return...just the duplicate emails, or do you need user IDs or counts?" Interviewer: "Just the list of duplicate email addresses." Candidate B: "One last thing.....are we working with the entire dataset in memory, or should I consider a database query approach?" Interviewer: "Assume it's a SQL database" Candidate B: "Excellent. So given the scale, I'd actually recommend a SQL query rather than loading everything into memory..." **proceeds to design the right solution for the actual problem** The lesson here: interviewers aren't just evaluating your code. They are evaluating how you'd work with their team. Someone who asks good questions and communicates clearly is often more valuable than someone who codes fast but builds the wrong thing.

@honour_can_code @pxxl_space When .NET

Top Languages and Frameworks supported by @pxxl_space

@arrakunrin Something wey we dey use catch cruise steady. 😂

I once trolled my “friend” that sent a voice note of 2 minutes to me explaining something. I jokingly told him “Omo, I go save this VN, upload am for audiomack o” He deleted the voice note before I could even listen to it. Deleted it over playful banter. I knew right then and there that we couldn’t be friends for a long time

Your localhost project is not teaching you anything. The real learning happens when you put your app out there to real users. Your local dev environment is a sanitized bubble where you're the only user, where your database has clean test data, where your network is fast and stable, where your project is running on your fancy MacBook Pro.... But real production will expose brutal issues you never anticipated while building: - what happens when 50 users hit your endpoint at the same time? Race conditions that never appear with one user suddenly crashes your app - your localhost wouldn't properly simulate slow mobile network or flaky connections - real users will input garbage data and expose edge cases you never anticipated - state management bugs or session pitfalls or caching issues are things that will only emerge under real load conditions. I could go on and on but you already get the point. Stripe's early team constantly deployed to production because they discovered that they learnt more within an hour of real transactions than days of local testing. They found out that users could accidentally trigger double payments, requiring idempotency keys. Instagram had a photo upload feature that worked perfectly during testing but in production they discovered many users had poor connection issues, requiring the team to handle things like uploads in chunks, and robust retry logic.. The lesson here is: fix all obvious bugs on localhost and get the app to users early, even if it's just 5 people. Take advantage of the feedback loop and keep iterating. Localhost is for building but real users will expose what you built wrongly.

Added Redis caching to speed up our API. Traffic grew 5x over 6 months. What broke: - Redis memory usage hit 95% - Cache eviction started randomly - Cache misses caused database overload - Failover to uncached queries took down the DB - 4-hour outage on a Tuesday afternoon Lesson: Caching doesn't eliminate load. It just moves the problem to a different layer.

An article worth reading. 👏

@stanlee0nX Automated testing, performance monitoring.. So much more

I’ve never used swagger for building backend, just consuming APIs What can postman do that swagger can’t? 🤔

@honour_can_code Allow abeg

some of y'all here on X dont actually know how to code!!! jesus.

DevFest Abuja '25 . . . #DevFestAbuja #DevFestAbuja2025

It took me 4 years to reach the Senior band. Here are 5 things I mastered to get there: 𝟭. 𝗔𝗦𝗣.𝗡𝗘𝗧 𝗖𝗼𝗿𝗲 𝗜𝗻 𝗗𝗲𝗽𝘁𝗵 Knowing how to create a RESTful API is good for juniors, but Seniors must know dozens of advanced features available on the platform. Middleware, global error handling, async programming, structured logging, background services, authentication, and authorization are a must. 𝟮. 𝗗𝗲𝘀𝗶𝗴𝗻 𝗣𝗿𝗶𝗻𝗰𝗶𝗽𝗹𝗲𝘀 𝗮𝗻𝗱 𝗗𝗲𝘀𝗶𝗴𝗻 𝗣𝗮𝘁𝘁𝗲𝗿𝗻𝘀 Knowing these helps you write maintainable and scalable code. Seniors must know when each principle and pattern should be applied. SOLID, DRY, KISS, YAGNI, singleton, repository, circuit breakers, pub/sub, and competing consumers are good ones to get started. 𝟯. 𝗖𝗹𝗼𝘂𝗱 𝗖𝗼𝗺𝗽𝘂𝘁𝗶𝗻𝗴 𝗮𝗻𝗱 𝗔𝘇𝘂𝗿𝗲 The cloud is the backbone of modern software infra, and as a Senior dev, you should be familiar with several essential Azure services. Azure blob storage, SQL or Postgres Database, Key Vault, Managed Identities, Entra ID, App Insights, Container Apps or AKS, are essential these days. 𝟰. 𝗗𝗲𝘃𝗢𝗽𝘀 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀 𝗮𝗻𝗱 𝗖𝗜/𝗖𝗗 𝗣𝗶𝗽𝗲𝗹𝗶𝗻𝗲𝘀 CI/CD pipelines are key to modern agile development. As a Senior dev you should know how to build an effective pipeline. Azure DevOps is the most popular across Microsoft shops, followed by GitHub Actions. Mastering at least one of those is super valuable. 𝟱. 𝗠𝗶𝗰𝗿𝗼𝘀𝗲𝗿𝘃𝗶𝗰𝗲𝘀 𝗮𝗻𝗱 𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿𝗶𝘇𝗮𝘁𝗶𝗼𝗻 Microservices help you build cloud-ready .NET systems at scale, and as a Senior dev you must know how they work and when to use them. Plus microservices automatically earns you hands-on experience with Docker containers, Kubernetes and many cloud development patterns. And that is just the start. Need a step-by-step roadmap? Here 👇 juliocasal.com/roadmap

This guy... Has the perfect definition for any tweet.😂😂

Don’t make posts for external validation. Building in public means different things to people, but it is in your interest to do it as a way of ensuring accountability. If you’re focused on your own path, you won’t care about what other people are doing unless you are doing it for engagements. The way to measure your success or growth is not by the number of likes or followers you have on social media. This is different if your goal is to become a content creator. Regardless of the number of likes and followers, it all boils down to getting the job done. You’d need to convince interviewers that there’s more to your viral posts. I see a lot of takes on referrals and wonder what they mean. A company without proper recruitment processes, or even worse, one where the process is bypassed to hire someone without accessing them is not where you’d want to work. If posting cleavage is a good strategy to land a tech job, men would have been underrepresented in tech.

@Victor_Webflow Software Engineering

My clients are always surprised when they find out I studied Chemistry. Curious to know, what did you study in school, and what are you doing now?

✨ NOW on .NET Conf 2025 ✨ Welcome to .NET 10 & Visual Studio 2026 8:00 AM - 9:30 AM PST Join us LIVE ➡️ msft.it/6011tHomU #dotNETConf #CSharp #VisualStudio2026

@iamphantasm0 @richsongocrazy 😂😭

@richsongocrazy What where you doing 2023-2024 I signed an NDA 😭

People with NDA go avoid this post only if you have enough side projects 😂

My routine on X lately... Open X, scroll through the TL, see one weird take, laugh my a** out, close X ... RInse and repeat.😂

Where people don't save for 8 hours.... I'm trying to stop clicking Ctrl + S for every 1- 3 lines of code i write. It's already a reflex

Here are some tips for being a good debugger: 1. Don't just guess things, observe: - use debuggers and breakpoints - add logs (console and terminal) - try to reproduce the bug in a predictable way 2. Bugs are easier to find when it's small enough: - remove layers until it is small enough - disable parts of your code and test if you need to 3. Read the errors I can't emphasize this enough. Most of your bugs can be solved by just reading the error messages thoroughly. What file is responsible? What line is it happening? What's the error suggesting I do? 4. Reproduce the bug in an isolated sandbox environment: This might be a bit advanced but isolated code in a codesandbox or wherever makes it easier to compare how it behaves on its own versus your code environment. 5. Read other people's bug fixes: There are many articles, GitHub issues and pull requests that contain how people had solved a particular bug. This will save you time and help you learn how senior engineers think. Some bonus include: - always check the "silent" places like environment variables, configs etc - write tests for critical parts of your code if you can - document your previous bug fixes

The second dev 🙂↕️

Most people won’t understand what you’re building until it works. That’s okay.