DEV Community: Norbs' Notes

The World Was Built on Broken English

Norbs' Notes — Mon, 14 Apr 2025 21:08:56 +0000

The world runs on broken English ... I work at a large multinational company with employees from all over the world, and I constantly hear basic grammar mistakes like: "we has" "I has" "I doesn't ... and so on, with horrible pronunciation — like 'health check' becoming 'hols check,' or 'I think' turning into 'I sink.' And I could go on. And these people are highly educated — with degrees, even PhDs.

The other day I made a mistake too — I wrote "Don't spoiler it" and my friend corrected me: 'It's don't spoil it.' And yeah, he's right. But honestly? I'd still use "Don't spoiler it" because I feel like more people would understand what I mean that way.

And this isn’t just a few people — it’s the majority. And I doubt it’s unique to this company; it’s probably the same across most multinational companies and organizations.

That’s the thing with English — compared to languages like German or French, it’s shockingly easy to learn badly… and still get by.

But the truth is, I end up picking up their bad habits too. Just look at the example above.

I don’t know… I have mixed feelings. I don’t like it when people butcher a language. Sometimes it’s not even broken English, to be honest — It’s shattered English, but I highly doubt that most people care. I once asked a few people, and they said they don’t mind it — so I guess I have to accept it.

The lingua franca of the world is NOT English ... It's BROKEN English.

Public Speaking: Tips and Insights from My 2024 Experience as a Software Engineer

Norbs' Notes — Fri, 10 Jan 2025 22:33:48 +0000

In 2024, I attended an event for Software Engineers where I delivered a 30-minute speech, participated in a 20-30-minute interview, and also gave a 5-minute Toastmasters speech. These opportunities helped me refine my speaking skills, gain more confidence, and develop a better understanding of public speaking. Now, I’m going to share some of the key lessons I learned last year.

Overprepare - Preparation is key. Even a complete beginner can give a life-changing speech if they put an immense amount of practice into it.
Practice it as if you were already giving the speech: Don’t just sit there and read your prompt. Stand up, use your voice, and move your body as if your audience were already sitting in front of you.

Be like a snail - Talk veeeeery slow. Don't worry, it won't sound stupid.
Overpronounce — Exaggerating your pronunciation helps improve clarity and makes it easier for your audience to follow along. It also forces you to slow down, giving your speech a more deliberate, confident rhythm. Don’t worry — it won’t sound unnatural. What feels exaggerated to you often sounds just right to your listeners.Don't be afraid to pause - It helps your audience process information
Don't try to pack everything into one speech - I tried to do this with my first 5-minute speech. It was a clusterfuck.
It's much easier to talk about topics (that) your audience is interested in - The audience wants to get something from you. It great to see how much they appreciate it when you give them a piece of information that's useful to them. (Funny story: One guy constantly brought me food and drinks because I was the "speaker.")
Remember: The speech is for your audience — you're just the host.Set an intention to "open"—Before you worry about what others think of you, Don't try to look cool, pretty, or smart. Just be open. Have an open mindset, ready to connect with your audience.
Memorize bullet points: Instead of (or after) memorizing your whole speech, memorize the key points of your speech.

Use the "Oreo" method:

Start with something positive – Like the top of an Oreo cookie. Begin. with a compliment or positive point to set a positive tone.
Present the core content or critical feedback – This is the filling, where you deliver your main message, share constructive feedback, or address the core topic.
End with another positive or encouraging point – The bottom cookie wraps it up with a motivational or optimistic note, leaving a good final impression.

Reframe nerves as excitement — Instead of focusing on fear, try to shift your mindset and view the adrenaline as excitement. This can help reframe the way you approach your presentation.Breathe deeply — Slow, deep breaths before and during your talk can help calm your nerves and center your mind.

How to be less shy when speaking publicly:

Destroy the pedestal: Don't put anyone on a pedestal - the only difference between you and them is the amount of time they practiced.
You have nothing to prove: "The most certain sign of wisdom is cheerfulness."
Labels are for food: "Shy" is just a label. You are under no obligation to be the same person you were five minutes ago.

And Focus on your message, not yourself

Book Recommendation as a Software Engineer: Atomic Habits

Norbs' Notes — Fri, 27 Dec 2024 00:05:07 +0000

I have read several books on both software development and personal development, from Design Patterns, Data Structures and Algorithms, to How to Win Friends and Influence People. But if someone asked me what books I would recommend to improve as a software engineer, it would only be one*: Atomic Habits.

Atomic Habits teaches you how to build good habits and get rid of bad ones. In software development, the most important thing is to improve every single day. It won’t be easy, but as long as you keep improving, you’ll achieve your goals.

After implementing the ideas from Atomic Habits, I found myself more consistent in coding every day, even when the tasks felt overwhelming. This gradual improvement over time led to better problem-solving skills, increased productivity, and ultimately, my current job.

One of the main takeaways that I read in Atomic Habits and that helped me the most is: Just be consistent. Do it every day. Even if it's just for 5 minutes, open your laptop and code. It doesn't have to be good, it doesn't have to be a lot but do it. If you open your laptop and start coding, that's a small victory. And these small victories lead you to big wins.

For me, the hardest part was getting started. Some days, it felt like I just didn't have the energy to code. But because opening the book for 5 minutes felt like a victory in my mind, I could do that, and once I started, I ended up coding for hours. This approach not only helped me develop consistency in coding but also in other areas of my life, as I learned the power of small, sustainable actions over time.

In the end, Atomic Habits showed me that success isn’t built on one big leap, but on countless small steps, taken consistently. And those small steps, no matter how insignificant they may seem at first, are the foundation for achieving long-term success.

*For the same reason, I don't talk about specific technologies here on my blog or in my speeches. Technologies are tools that you have to learn by experimenting and experiencing them. I could write about fancy frameworks, but: 1. there are already enough bloggers covering them, and 2. there's no point because you'll learn them by doing.

Microservices vs Monoliths: The Battle of Architectures!

Norbs' Notes — Tue, 17 Dec 2024 22:42:21 +0000

In the world of software engineering, the debate between breaking things down into smaller services (microservices) or keeping them unified in a single, solid block (monolith) is real.

Which approach wins the race? Let's take a look!

First of all, let me explain what Microservices and Monoliths are:
Microservices: Small, independent services that communicate with each other, offering flexibility and scalability.
Monoliths: A single, unified codebase that handles all tasks, often simpler but harder to scale and maintain.

MICROSERVICES PROS:

Scalability and Flexibility: You can easily add new services and quickly adapt to evolving changes.
Clear Responsibilities in the Team: Encourages delegated responsibility and clear ownership, making it obvious who does what and where the lines of responsibility lie.
Fits the Reality: Business needs change constantly—microservices adapt better to these changes.
Easier Maintenance: You can modify, fix, or remove a service without breaking anything else.
Smaller Features Are Easier to Fix: + My personal opinion: Developers rarely read each other’s code, so smaller modules help (this is my unpopular opinion).

MICROSERVICES CONS:

Increased Complexity: Managing multiple services requires a more complex architecture, including inter-service communication, dependency handling, and data consistency.
Deployment Complexity: Deploying microservices involves orchestrating multiple builds, configurations, and monitoring tools, which can complicate CI/CD pipelines.
Operational Overhead: Running a microservices architecture increases operational tasks like monitoring, logging, and maintaining infrastructure for numerous services. This often requires more sophisticated tools and additional resources.

JavaScript: The "English" of Programming Languages

Norbs' Notes — Mon, 16 Dec 2024 23:10:40 +0000

Even though I'm a backend developer, my main programming language is JavaScript, and the reason is simple:
JavaScript, like English, has many inconsistencies, historical quirks, and flaws, but it is EVERYWHERE.

Atwood's law: "Any application that can be written in JavaScript, will eventually be written in JavaScript".

There is a JavaScript runtime environment on almost every phone and computer—your browser.
You can’t run away from it - One of my friends hates English and uses it only because he needs it for his PhD. Same with JS. It’s everywhere.

Personal Opinion: I didn’t struggle much because of my choice of main programming language. Other issues are more challenging.

*Why Use JavaScript on the Backend? *

Unified Language Stack (Full-Stack Development) - You don’t need another programming language. No Context Switching.
An asynchronous, single thread, Non-Blocking I/O Model
- Asynchronous means that tasks can run independently of the main program flow
  - A single-threaded system means the program can only execute one task at a time
  - Input/Output: Great for I/O tasks like Network requests, Data queries, API calls
Scale applications horizontally AKA Use multiple servers
Fast Execution Speed

When to avoid it:

Scale applications vertically AKA CPU-intensive processes.

Tip: Match your language choice to your goals
Don’t use Javascript to develop an AAA video game

Technically, you could achieve this using worker threads or child processes, but this is not Node's default or ideal use case.

Next topic: Monolits vs Microservices. Stay Tuned!

Lessons Learned from My Tech Lead: Wisdom for Developers

Norbs' Notes — Mon, 09 Dec 2024 11:46:32 +0000

I've been working at a multinational American tech company for about 2 years now. These are the things that I've learned from my tech lead:

“Communicate like a 5-year-old." - Clarify everything. Explain things as if you're talking to a 5-year-old.
"Laugh at the stupid things." - Many times you'll face miscommunication, bad engineers, or just overwhelming processes which can be really stressful. You need to be able to laugh at these things.
"Do your best, do what you can, and if it’s too much, well… dahh... sorry." - Not everything is within your control. Don’t overwhelm yourself with impossible tasks. Just try your best and let go of what you can’t control."
"Years of experience often doesn’t mean anything" - Experience on paper doesn’t always reflect actual competence or skill. I've met many incompetent developers despite their years of experience.
"You have to be pushy, assertive" - Be like Donkey from Shrek 2: ask the same question repeatedly if needed. It might be annoying, but it gets results.

And the most important: "You only truly learn when you suffer with an issue long enough to never forget the solution."

Overcoming Impostor Syndrome in Software Development

Norbs' Notes — Mon, 09 Dec 2024 02:05:33 +0000

Overcoming Impostor Syndrome in Software Development

Hi, I’m a Node.js Developer, and today I want to talk about impostor syndrome. It’s a real thing in our field, and not just for beginners. Many aspiring developers, as well as those who've been in the industry for years, experience it.

I personally don’t feel any impostor syndrome anymore, but when I started in this field of software development, I felt like this profession wasn’t for me and even questioned whether I should leave. However, I’ve realized that this field is like any other: anyone can learn it with enough time and practice. You have to build studying habits — figure out how you want to achieve what you want to achieve. In my opinion, the best way to learn something is to make it simple and do it every. single. day.

*Lesson learned: Overcome challenges by discovering your own unique solutions. *

My example: I found a JS tutor on Preply, a Ukrainian JavaScript developer, and he taught me everything related to JavaScript. I had classes three times a week for almost a year with him.

Engineering the Unseen: My Work as a Software Engineer

Norbs' Notes — Mon, 11 Nov 2024 18:11:42 +0000

I signed an NDA, and I'm not sure what I can say about my daily work, but I'll try my best to explain it without going into too much detail.

I’m a software engineer at an American multinational company, and I’m programming a middleware that ensures safe and smooth communication between a chatbot AI and various services in order to be able to provide information to the customers related to those services.

I primarily use JavaScript and Node.js, which is a runtime environment for Javascript on the backend. The app runs on multiple Red Hat Linux (RHEL) servers.

We chose Node.js because early development is fast in Node, and we needed to show progress to management as soon as possible. Node.js uses an asynchronous model, which is excellent for efficiently handling a high volume of I/O operations, such as requests to and from APIs. Node is also well-suited for horizontal scaling, meaning you can easily add additional servers running the application to handle increased traffic or workload.

I develop on Windows, but the app itself runs on RHEL servers. We chose RHEL because it’s highly customizable and known for its strong security practices. Managing configurations at a deep level is so much easier on Linux than on Windows, which is essential when handling multiple security layers and certifications. Additionally, we are less dependent on external companies like Microsoft. RHEL is optimized for high-performance applications, offering better memory and resource management than standard Linux. It’s also widely compatible with other enterprise-grade software and includes tools for monitoring, logging, and system performance management, making it easier to integrate into a complex tech stack.

The app is based on the microservices architecture, which allows the app to have as many modules as possible, making it adaptable for various purposes. My middleware, for example, will support not only AI but other applications where secure I/O and API communication are essential.

The team consists of around 30-40 people, but I primarily develop this middleware on my own, although I do have an intern assisting me

I’d say the most difficult part of the job is communicating with others. When I need to reach out to other teams for an API or an app to implement services, or when I need input from other engineers, sometimes they don’t respond—or they give unhelpful answers, which can be frustrating. You really have to be pushy, which I don’t particularly like doing.

The most challenging part of my work is that we always have to rush, which leaves us with little time to follow best practices like Test-Driven Development.

The best part of the job is the coding itself and figuring out solutions for implementing different functionalities into the middleware.

My future goal is to become a recognizable figure in the technology field—writing blogs and speaking on programming topics. That's why I find English so important, and I am working on improving my speaking and writing skills. I want to be a strong public speaker and tech writer.

I’d also like to code more in TypeScript. At the moment, we ensure type safety with JSDoc, but I want to focus more on TDD and incorporate TypeScript in my work.

Do you have any other questions related to my field or me? Feel free to let me know in the comments.

AI takeover?

Norbs' Notes — Wed, 06 Nov 2024 20:02:53 +0000

I'm pretty sure you've all heard about the famous new AI hype and that it's going to replace us all But will it really?

Well, I just happened to become a software engineer by accident, and I've been working with AI for a while now. So, let me share my experience so far.

As you may have already realized, this will be an opinionated topic. This is only my personal opinion and not factual.

I'm a Software Engineer at an F500 multinational company, my tech stack is Node.js related, and we're actually working on an AI Customer Service Chatbot right now.

First of all, we have a coding copilot AI on our company computers, but it's heavily restricted, likely for security reasons, and frankly, it’s almost completely useless—it’s so limited that it’s hardly worth mentioning.

ChatGPT: You're probably familiar with ChatGPT. For relatively simple tasks, it’s pretty useful. But if it doesn’t get it right within the first few tries, it likely won’t be able to solve the problem we're facing, no matter how many times you ask. You also need a solid understanding of the topic to make good use of it—if you don’t, it is the gate to hell.

Other Coding AIs: On my personal computer, I use other AI tools for coding. At the moment I use Codium. It's a free coding AI but actually pretty useful. This, I believe, is the most interesting part. These tools can be really useful, though they tend to struggle with large codebases and a lot of contexts.

But will it replace us? Yes. No. Yes and No. It will definitely change many industries. However, with more code, there will be more software, and with more software, there will be bigger competition and higher expectations for quality. So I think the amount and quality of software will only increase in the future. I give us like 20 years before AI starts fully replacing us. However, before that happens, I definitely see an AI bubble explosion similar to the dot-com bubble of the early 2000s. These tools have incredible potential, and I believe these products will be great. The hype is just too early. But I also think AI will plateau again, as it did before, and the hype will die down due to unfulfilled prophecies, which will cause investment declines.

Embrace your voice

Norbs' Notes — Wed, 06 Nov 2024 20:00:03 +0000

Have you ever felt insecure about your accent, wishing you sounded more like a native English speaker? If you're anything like me, you've definitely been there. I used to feel insecure speaking publicly, worried that my accent would overshadow my message. But let me tell you something—when I learned that I could embrace my accent, everything changed. Here’s why.

A while back, I introduced two friends of mine to each other. One is from Italy, and the other is from Texas. Both now live here in Hungary. My Italian friend is a head chef at a fancy restaurant and manages a team of over 80 people in English, every day. His English is excellent. You’d think engaging in conversation with a native speaker would be a breeze for him, right? But here’s the catch...… Despite his fluency in the language, he struggled to follow my American friend’s English.

Why, you might ask? It had nothing to do with my American friend's vocabulary or grammar. It was something more subtle but just as important: enunciation and clarity. When native speakers talk, they often take shortcuts. They blend words together, drop sounds, and speak at a pace that is natural and comfortable for them, but can sound incredibly fast and daunting to the non-native ear, regardless of your level of proficiency. For example, instead of saying 'I am going to,' they might say 'Amana.' Or 'Did you eat?' becomes 'D’ya eat?' These shortcuts make their speech faster and more fluid, but less clear to non-natives. So, even though my Italian friend speaks English incredibly well, he struggled to keep up with my American friend because he's used to a more structured, clearer form of English.

Like most non-native speakers, he’s accustomed to hearing and using English spoken with clarity. He’s an expert at communicating in a way that’s easy to understand because he focuses on pronouncing each word clearly. But when faced with the fast, connected speech of a native speaker, he found himself havin' to slow down and adjust.

I know this from experience because when I lived in Birmingham, UK, I couldn’t understand anything British people said, and I thought it was my fault. I felt ashamed for not knowin' as much English as I should. Now that I’m an experienced English speaker and I've had more exposure to the language, I realize it wasn’t me—it was them! Even if you dropped me in Birmingham today, I probably wouldn't be able to make out one word they were saying. Birmingham is notorious for having an accent that’s difficult to understand, and even a native speaker might struggle with it. The people in Birmingham are native speakers, yet their English can be hard to follow — to the point that even other Brits find it hard to understand them. So, what’s the point of being a native speaker if others can’t understand you?

The truth is that being a native speaker doesn’t automatically make you good at communication. A lot of non-native speakers are insecure about their accents. But what if I told you that your accent can be your strength? Do you know why? Because most non-natives focus on clarity. They speak with purpose. They’re not rushing, they’re not blending words together—they’re making sure every word is understood. My Italian friend, with his distinct accent, is one of the clearest speakers I know because he takes the time to be understood. He’s intentional. And that’s what makes him a better communicator than most native speakers.

I’ve spent a lot of time practicing American English, and sure, I still have a strong Hungarian accent. You might say I’ve failed to lose it. But here’s the surprise: I still recommend accent practice. You might wonder why. It's because it helps you stop worrying about whether your pronunciation is correct. Instead of stressing over how you sound, you can focus on what you’re saying and be fully present in the moment.

So here’s the takeaway: your accent doesn’t matter. Your clarity does. It’s not about blending in or sounding like a native speaker. It’s about speaking in a way that gets your point across. Because in the end, the only thing that really matters in communication is whether people understand you.

Forget the accent. Focus on clarity. Speak clearly, speak with purpose, and watch what happens to your communication. It gets better. You’ll connect with people more, you’ll be understood, and your message will have a bigger impact. And isn’t that the whole point?