Usmon
How to Grow as a Software Engineer Growth can have different meanings depending on the context. Here, I want to talk about growth within a company—how to get a promotion. As software engineers, we are not paid for writing code, drawing diagrams, or sitting…
How to Grow as a Software Engineer (Part 2)
Contribution is not always measured by the lines of code you write. At the end of the day, it all boils down to the impact you bring to the team. One of the best ways, which I like the most, is sharing knowledge and refining internal processes. In most cases, individual contributors tend to work in a more isolated environment compared to other roles, and not every engineer likes to take initiative outside their responsibilities. Based on my experience, one of the best ways to contribute is through mentoring your teammates, helping them level up, and refining internal processes, as this can have a greater impact on the team and help achieve your career goals much faster.
Contribution is not always measured by the lines of code you write. At the end of the day, it all boils down to the impact you bring to the team. One of the best ways, which I like the most, is sharing knowledge and refining internal processes. In most cases, individual contributors tend to work in a more isolated environment compared to other roles, and not every engineer likes to take initiative outside their responsibilities. Based on my experience, one of the best ways to contribute is through mentoring your teammates, helping them level up, and refining internal processes, as this can have a greater impact on the team and help achieve your career goals much faster.
Vibe Coding
This term became very popular among developers and startup builders after Karpathy coined this word. In retrospect, all those tools (cursor composer, windsurf, etc.) let you quickly build MVP and secure your first customers with less effort and cost. However, the downside is that you don't know the fundamentals of what you are building, and things may easily messed up as if you have no idea what is going on in your project. Also, he mentioned it was experimented on a one-off weekend project. Think of it as living in a "vibe constructed" house lol. On the other hand, having these tools as a developer may boost your productivity to some extent.
This term became very popular among developers and startup builders after Karpathy coined this word. In retrospect, all those tools (cursor composer, windsurf, etc.) let you quickly build MVP and secure your first customers with less effort and cost. However, the downside is that you don't know the fundamentals of what you are building, and things may easily messed up as if you have no idea what is going on in your project. Also, he mentioned it was experimented on a one-off weekend project. Think of it as living in a "vibe constructed" house lol. On the other hand, having these tools as a developer may boost your productivity to some extent.
Usmon
Vibe Coding This term became very popular among developers and startup builders after Karpathy coined this word. In retrospect, all those tools (cursor composer, windsurf, etc.) let you quickly build MVP and secure your first customers with less effort and…
Pitfalls
I decided to give Cursor a try and tried to vibe code. For context, I had a production system running for 2 years. Most of the stuff was implemented in the backend and no frontend at all. I decided to rewrite the backend and write the frontend. Due to the models' context window, I introduced the backend functionality step by step. Initially, it all went well, but as the number of functions grew, I observed inconsistencies in code structure, style, etc and constantly provided the necessary context to make the code more consistent. Then I started prompting to build the frontend side using react stack. Unfortunately, things didn't go quite well. Given I'm not good at frontend stuff, I completely relied on generated code. At some point, I noticed deprecated packages, poorly organized code, and a bunch of unnecessary boilerplate. Moreover, I constantly go through the error cycle, which I didn't quite understand.
To conclude, I quickly ended up having a mess than expected. I'd instead read corresponding documentation (react stack) and accept the outcome of those models carefully.
I decided to give Cursor a try and tried to vibe code. For context, I had a production system running for 2 years. Most of the stuff was implemented in the backend and no frontend at all. I decided to rewrite the backend and write the frontend. Due to the models' context window, I introduced the backend functionality step by step. Initially, it all went well, but as the number of functions grew, I observed inconsistencies in code structure, style, etc and constantly provided the necessary context to make the code more consistent. Then I started prompting to build the frontend side using react stack. Unfortunately, things didn't go quite well. Given I'm not good at frontend stuff, I completely relied on generated code. At some point, I noticed deprecated packages, poorly organized code, and a bunch of unnecessary boilerplate. Moreover, I constantly go through the error cycle, which I didn't quite understand.
To conclude, I quickly ended up having a mess than expected. I'd instead read corresponding documentation (react stack) and accept the outcome of those models carefully.
Usmon
Pitfalls I decided to give Cursor a try and tried to vibe code. For context, I had a production system running for 2 years. Most of the stuff was implemented in the backend and no frontend at all. I decided to rewrite the backend and write the frontend. Due…
We still need substantial improvements. That is to say, the error rate should be close to zero to achieve what we call autonomous AI agents.
Forwarded from Bob Usmonov
💰 They donate to get richer
Giving away is a necessity for rich people to become even wealthier. When billionaires spend a ton of money to build hospitals, schools, donate millions to fight homelessness and similar problems, people may think - what a generous and kind person. In reality they are doing it to earn more. It sounds counterintuitive, I know, but let me explain.
For an economy to thrive 2 things need to happen. The first is obvious - people should be spending actively. You're working your butt off and stacking all the Benjamins under your pillow? What a horrible person you are! No, just kidding, but it hurts the economy as well as it hurts yourself. What rich people do is just giving away some of their money to poor, so that they can return it to them by spending and incentivising economy. And they don't simply give away money for regular people, because it may demotivate them from working hard.
The second is about working productively. If people are actively working and producing goods and services, they are pure gold for riches. They give them back twice, first working for them and then spending their earnings. And this is the reason why they donate to education and healthcare. Their goal is to cure sick people and educate uneducated to eventually get back their investments.
It's not evil to be rich, earn a ton of money. It's evil and irrational not to return a portion of it back to your community. Remember - money is just the means to exchange your work to something else. If spent wisely it may bring more good than you could imagine
#financeandbusiness
Giving away is a necessity for rich people to become even wealthier. When billionaires spend a ton of money to build hospitals, schools, donate millions to fight homelessness and similar problems, people may think - what a generous and kind person. In reality they are doing it to earn more. It sounds counterintuitive, I know, but let me explain.
For an economy to thrive 2 things need to happen. The first is obvious - people should be spending actively. You're working your butt off and stacking all the Benjamins under your pillow? What a horrible person you are! No, just kidding, but it hurts the economy as well as it hurts yourself. What rich people do is just giving away some of their money to poor, so that they can return it to them by spending and incentivising economy. And they don't simply give away money for regular people, because it may demotivate them from working hard.
The second is about working productively. If people are actively working and producing goods and services, they are pure gold for riches. They give them back twice, first working for them and then spending their earnings. And this is the reason why they donate to education and healthcare. Their goal is to cure sick people and educate uneducated to eventually get back their investments.
It's not evil to be rich, earn a ton of money. It's evil and irrational not to return a portion of it back to your community. Remember - money is just the means to exchange your work to something else. If spent wisely it may bring more good than you could imagine
#financeandbusiness
👍1🏆1
How to Learn While Having a Full-time Job?
Some developers struggle to find time to learn topics they are interested in while working full-time. If you are a junior or mid-level engineer, the chances that you are learning fun stuff at work are high. Some mid-level+ engineers often invest into learning outside of working hours and some stop investing time into what they are interested in or want to pursue. In general, it's your choice whether or not you invest your free time into learning. The truth is you quickly stop acquiring new knowledge at your work unless you are working in fast-changing fields like artificial intelligence. If you want to keep making good growth while working full-time, there are a few things you need to keep in mind.
A few years ago, I tried to develop a habit of consistent learning, as I didn't always find myself learning what I was interested in. However, after I burnt out, I did different experiments to figure out how to learn effectively while keeping a balance. My key takeaway was managing your energy correctly. I discovered morning learning works best for me, as my brain would be fresh and not have much information to process. While learning after working hours works for some individuals, I often find myself having less/no energy to do something after work. So, it's important to find out what kind of schedule works for you.
You learn everything but nothing. You should commit enough effort to see progress. Unless you are learning a small topic, it may take from a few weeks to several months to cover the topic. Because of this, It's important to stay motivated to make good learning progress while having a full-time job. Prioritize things you want to learn and only learn 1 or max 2 topics at the same time. Otherwise, you end up learning nothing because of choice paralysis. Instead of setting a large, overwhelming learning goal, break it down into smaller milestones, and remember to take regular breaks to make good progress in the long run.
Some developers struggle to find time to learn topics they are interested in while working full-time. If you are a junior or mid-level engineer, the chances that you are learning fun stuff at work are high. Some mid-level+ engineers often invest into learning outside of working hours and some stop investing time into what they are interested in or want to pursue. In general, it's your choice whether or not you invest your free time into learning. The truth is you quickly stop acquiring new knowledge at your work unless you are working in fast-changing fields like artificial intelligence. If you want to keep making good growth while working full-time, there are a few things you need to keep in mind.
A few years ago, I tried to develop a habit of consistent learning, as I didn't always find myself learning what I was interested in. However, after I burnt out, I did different experiments to figure out how to learn effectively while keeping a balance. My key takeaway was managing your energy correctly. I discovered morning learning works best for me, as my brain would be fresh and not have much information to process. While learning after working hours works for some individuals, I often find myself having less/no energy to do something after work. So, it's important to find out what kind of schedule works for you.
You learn everything but nothing. You should commit enough effort to see progress. Unless you are learning a small topic, it may take from a few weeks to several months to cover the topic. Because of this, It's important to stay motivated to make good learning progress while having a full-time job. Prioritize things you want to learn and only learn 1 or max 2 topics at the same time. Otherwise, you end up learning nothing because of choice paralysis. Instead of setting a large, overwhelming learning goal, break it down into smaller milestones, and remember to take regular breaks to make good progress in the long run.
❤2👍2
Usmon
In-person interviews are back
I believe online assessments and coding interviews have been effective so far. However, I expect many companies will start rethinking their interview processes. The main challenge is that it’s difficult to truly evaluate a candidate’s abilities in just an hour.
leetcode-style problems and system design interviews have helped raise the bar, but as tools and AI models become more advanced, it will get easier to perform well on these types of interview questions. Because of that, I think mid-sized companies will begin to focus more on “How…” questions—emphasizing a candidate’s real-world experience rather than just testing their ability to solve leetcode-style problems.
As coding becomes less of a bottleneck in software development, interviews should shift toward evaluating a candidate’s practical experience, decision-making, and approach to solving real problems.
leetcode-style problems and system design interviews have helped raise the bar, but as tools and AI models become more advanced, it will get easier to perform well on these types of interview questions. Because of that, I think mid-sized companies will begin to focus more on “How…” questions—emphasizing a candidate’s real-world experience rather than just testing their ability to solve leetcode-style problems.
As coding becomes less of a bottleneck in software development, interviews should shift toward evaluating a candidate’s practical experience, decision-making, and approach to solving real problems.
There Is No Perfect Code
The idea of clean code and clean architecture is often widely promoted by people of varying levels of experience. I sometimes hear folks discussing or debating this concept, making arguments based on commonly cited "best practices"—that it should be this way or must follow that convention. But in reality, there is no such thing as perfect code in production systems.
Over the past several years, I've worked on a variety of projects with different teams, and each project had its own level of quality, its own quirks and constraints. Not once have I encountered a codebase that could genuinely be called "perfect" (maybe I will one day).
What seems like perfect code today can easily become tomorrow's technical debt. Code doesn't remain static unless it's part of a small, throwaway project. What we write today is shaped by our current understanding and context, but it will inevitably change. Shifting business goals, changing requirements, and new constraints like latency, scalability, or compliance force us to adapt. That adaptation affects the code.
What we think is clean and ideal today can turn into a mess later. Or the opposite, something that seemed messy at first might end up being a practical solution. Building systems is always about trade-offs. Every system has different needs and goals: performance vs. readability, flexibility vs. simplicity, speed of development vs. stability. Improving one thing often means giving up something else.
Even the cleanest codebase decays. Without continual refactoring and maintenance, even well-written code degrades over time. I've seen many codebases slowly rot due to accumulating tech debt and a lack of care. That's why I believe the notion of "perfect code" is inherently short-lived.
In some cases, a team's obsession with clean code can even lead to project failure. In my experience, striving for perfection has delayed projects delivery and sometimes caused more harm than good. That's why I recommend avoiding over-engineering. There's no point in having beautifully crafted code if no one ends up using your product.
The idea of clean code and clean architecture is often widely promoted by people of varying levels of experience. I sometimes hear folks discussing or debating this concept, making arguments based on commonly cited "best practices"—that it should be this way or must follow that convention. But in reality, there is no such thing as perfect code in production systems.
Over the past several years, I've worked on a variety of projects with different teams, and each project had its own level of quality, its own quirks and constraints. Not once have I encountered a codebase that could genuinely be called "perfect" (maybe I will one day).
What seems like perfect code today can easily become tomorrow's technical debt. Code doesn't remain static unless it's part of a small, throwaway project. What we write today is shaped by our current understanding and context, but it will inevitably change. Shifting business goals, changing requirements, and new constraints like latency, scalability, or compliance force us to adapt. That adaptation affects the code.
What we think is clean and ideal today can turn into a mess later. Or the opposite, something that seemed messy at first might end up being a practical solution. Building systems is always about trade-offs. Every system has different needs and goals: performance vs. readability, flexibility vs. simplicity, speed of development vs. stability. Improving one thing often means giving up something else.
Even the cleanest codebase decays. Without continual refactoring and maintenance, even well-written code degrades over time. I've seen many codebases slowly rot due to accumulating tech debt and a lack of care. That's why I believe the notion of "perfect code" is inherently short-lived.
In some cases, a team's obsession with clean code can even lead to project failure. In my experience, striving for perfection has delayed projects delivery and sometimes caused more harm than good. That's why I recommend avoiding over-engineering. There's no point in having beautifully crafted code if no one ends up using your product.
TypeScript's Dark Sides
I have been working within the TypeScript (TS) ecosystem for the past 4.5 years. During this time, I have worked on various codebases written in TS, each employing different approaches and mental models. Before discussing the problems associated with TypeScript, it's important to first consider the benefits it offers. TypeScript promises better tooling, improved type safety, and several other advantages. One of the key assertions often made by TS developers is that the type safety provided by TS facilitates the early detection of pre-compilation errors and improves the maintainability of projects. I agree with these statements to some extent. However, these claims no longer hold true once your codebase starts growing.
I believe one of the biggest issues is that TS was invented to solve JS issues. Most of the design decisions were made with compatibility with untyped legacy code in mind. TS prioritizes developer ergonomics over rigorous correctness, which has led to many poor design decisions. It opens the door to bypassing type-level checks, which in turn contradicts its promises.
You don't get a true sense of type safety. Even if the code compiles successfully, the chances of runtime errors persisting are high. In large projects, one of the most important things is strong compile-time guarantees, which TS cannot provide. This is because it's so easy to use any, unknown, type coercion, or abuse type assertions. Moreover, another significant issue is that the ecosystem itself is not reliable. As your project grows, you'll need to integrate different software and libraries, which in turn affect your codebase. If an SDK, library, or any external tool is not well-maintained or well-designed, you'll end up breaking things on your end or rewriting everything that those things provide (which is less likely to happen).
Additionally, the testing ecosystem sucks. As your project becomes larger, testing becomes very important. In TS, most popular testing frameworks and tools do not provide good type safety. From my experience, most of the teams that use TS end up using various workarounds, which significantly lowers the quality of your tests. I've encountered tests that appear to work due to low type safety (even they are broken). When you have large objects involved in testing, things get really complicated as you make changes to parts of your codebase.
To recap, I would say TS is good for shipping small projects on time. However, as the complexity of a project increases, the more you'll suffer from the fundamental issues the language has.
I have been working within the TypeScript (TS) ecosystem for the past 4.5 years. During this time, I have worked on various codebases written in TS, each employing different approaches and mental models. Before discussing the problems associated with TypeScript, it's important to first consider the benefits it offers. TypeScript promises better tooling, improved type safety, and several other advantages. One of the key assertions often made by TS developers is that the type safety provided by TS facilitates the early detection of pre-compilation errors and improves the maintainability of projects. I agree with these statements to some extent. However, these claims no longer hold true once your codebase starts growing.
I believe one of the biggest issues is that TS was invented to solve JS issues. Most of the design decisions were made with compatibility with untyped legacy code in mind. TS prioritizes developer ergonomics over rigorous correctness, which has led to many poor design decisions. It opens the door to bypassing type-level checks, which in turn contradicts its promises.
You don't get a true sense of type safety. Even if the code compiles successfully, the chances of runtime errors persisting are high. In large projects, one of the most important things is strong compile-time guarantees, which TS cannot provide. This is because it's so easy to use any, unknown, type coercion, or abuse type assertions. Moreover, another significant issue is that the ecosystem itself is not reliable. As your project grows, you'll need to integrate different software and libraries, which in turn affect your codebase. If an SDK, library, or any external tool is not well-maintained or well-designed, you'll end up breaking things on your end or rewriting everything that those things provide (which is less likely to happen).
Additionally, the testing ecosystem sucks. As your project becomes larger, testing becomes very important. In TS, most popular testing frameworks and tools do not provide good type safety. From my experience, most of the teams that use TS end up using various workarounds, which significantly lowers the quality of your tests. I've encountered tests that appear to work due to low type safety (even they are broken). When you have large objects involved in testing, things get really complicated as you make changes to parts of your codebase.
To recap, I would say TS is good for shipping small projects on time. However, as the complexity of a project increases, the more you'll suffer from the fundamental issues the language has.
👍3👎3
Using the conversations plugin feels so much better after years of using a mix of session based routers and state based step functions.
BotNews
• Manager bots are used to bootstrap and control other bots on behalf of their owners – easily orchestrating any number of AI agents, Business Accounts and custom tools.
• Out of the box, manager bots can prompt users to create a bot in one tap and easily fetch their token to start piloting them.
Good starting point for AI agents and agentic flows.