The Athlete-Engineer: A Framework for Peak Performance

October 25, 2025 Personal, Sports 2 comments

Me training my climbing on a MoonBoard

I consider myself a bit of a recreational athlete, meaning I do sports for fun and health: rock climbing, Muay Thai, running, and occasionally visiting conventional gyms. In 2021 I worked out 365 days straight and as of now have 2.3K logged activities on Strava with a 140 weeks long streak. I haven’t been like this 9 years ago or earlier, barely doing any activities back then, but over time I realized that health and time are the most valuable assets I have. This post is a few things: self reminder to stay on track, potentially some inspiration for you, and an attempt to drive analogies between athletic performance training and software engineering careers.

LEVEL 0: Non-Compromisable Fundamentals

There are only three fundamentals in my opinion. Compromising these is the worst thing you can do to your health, not just physical, but also mental performance, yes including your software engineering career.

Sleep

  • I cannot stress enough how important sleep is: lack of sleep is a slow form of self-euthanasia. The shorter your sleep, the shorter your life.
  • Reducing your sleep time to do more work is counterproductive and all the way detrimental to your health and creativity. It may work short term only or if you have some special super-human abilities. I don’t.
  • For a software engineer, sleep deprivation doesn’t just hurt your health. It destroys creativity and makes complex problem-solving nearly impossible. My productivity is extremely low if I haven’t had enough sleep two days in a row.

Nutrition

  • You become what you eat.
  • I don’t want to expand too much here. We all know the basics: not skipping meals, proper balance of macro and micro, no junk food, less sugar, little or no alcohol. It’s all common knowledge. Consistency is hard.

Physical activity

  • The basic amount of physical movement is a MUST unless you want to die earlier.
  • To cite AHA: “at least 150 minutes per week of moderate-intensity aerobic activity or 75 minutes per week of vigorous aerobic activity, or a combination of both, preferably spread throughout the week”.
  • For those of us sitting all day, this is non-negotiable. Even a 10-minute walk can be that ‘garbage collection’ our brain needs to consolidate thoughts.

LEVEL 1: Improving and Growing

Improving Sleep

I am going over sleep again but this time with more practical recommendations if you are targeting greater benefits.

  • Adjust your sleep duration to your needs. For example, my baseline sleep need is 7h50min, but after very intense kickboxing class >600kcal my need increases by about 50 minutes or if I had an easy day it may reduce a bit. I get this info from my Garmin’s “sleep coach”, the way I address this is by going to sleep earlier or later, not by changing my morning alarm.
  • Improve quality of sleep. Tracking sleep phases helps, and general recommendations also help (darkness, cooler temperature, regular timing), but what I found helped me a lot was to reduce my coffee consumption to single coffee very early in the morning. What might help you might be different.
  • Here is my old post reviewing the “Why We Sleep” book. Practical tips for posterity:
    • Stick to a sleep schedule
    • Don’t exercise too late in the day
    • Avoid caffeine & nicotine
    • Avoid alcoholic drinks before bed
    • Avoid large meals and beverages late at night
    • Avoid medicines that delay or disrupt your sleep (where possible)
    • Don’t nap after 3pm
    • Make sure to leave time to relax before bed
    • Take a hot bath before bed
    • Have a dark, cool (in temperature), gadget free bedroom
    • Get the right sunlight exposure
    • Don’t stay in bed if you (really) can’t sleep

Getting more out of your nutrition

Besides all of the regular recommendations I would like to mention few additional ones:

  • Gut Health: a diverse gut microbiome supports overall health. Strive for a variety of foods.
  • Blood Sugar and Mood: High blood sugar correlates with mood fluctuations, so stable blood sugar levels are ideal. Watch sugar consumption.
  • Creatine is a safe, extensively studied supplement shown to benefit both power and endurance performance. Ok and beneficial to consume creatine. I do. And yes, after a few months of consistent consumption I noticed a small increase in my strength when climbing.
  • Protein. If you are building muscle, it is ok to add some extra protein if you are not getting enough with regular food. I do, though I’m not building muscle actively.
  • A sugar crash is the enemy of deep work. I sometimes take an energy drink – but that’s a horrible idea as it’s like taking on high-interest tech debt. A cheap ‘boost’ now that you’ll pay for all afternoon.

Physical activity

  • My personal weekly target is minimum 300 active minutes (or 150 vigorous), though this is challenging with intense software engineering jobs. I hit my 300 active minutes with 2 Muay Thai classes, 1-2 climbing, 1-2 runs, 1-2 weights exercise or some other activity.
  • Studies show that maximum health benefit is reached up to 600 active minutes after which you are really optimizing for performance and not health. I just changed my target to 400.

Recovery

  • Once you are doing a lot of activities recovery becomes a “thing”. Not only this is needed for physical activities but also mental. We need to take vacations from time to time. We need to take rest at weekends to avoid burnout.
  • Recovery should be periodized to support long-term training. Rest well and enough before next training which should be harder (longer & intense) than previous one(s).
  • For us, software engineers, it is also crucial to have mental recoveries. Also just as muscles grow during rest, our best ideas often surface when our brain is in ‘recovery’ mode.
  • I personally prefer to work extra hard during the week but then keep my weekend completely to myself and avoid logging-in to work on weekends (unless I’m oncall).

LEVEL 2: Optimization 

Optimization comes last. Once you have all of the key ingredients and are consistent only then you can start thinking about all of the niche nitty-gritty optimizations, not before.

Choices

  • We can only optimize on one of the three — health, body composition, or performance. A balanced approach might be best for recreational athletes, but you cannot reach maximum in all three. At the moment I seem to be doing a bit of all of them, with the intention to optimize for health rather than the other two. It is tempting to build muscle or push for that next climbing grade or a new personal record on a 10k run.
  • I think in our careers we might be also facing some choices – do we optimize our hard technical skills or do we develop soft skills, do we build breadth of knowledge or go very deep. It’s a choice and we can only optimize one of them and others could still improve but you won’t reach peak in them.

Deliberate Training

  • When you go running, you can just run regular 5k at whatever pace you find manageable, or you can do a variety of specific training – you can do interval training, long easy runs, tempo runs, etc. Combination of these different dedicated runs help with your race time.
  • When you go climbing, you can just climb whatever for fun, or you can dedicate a session to endurance, do bouldering 4×4, do handboarding, do dedicated climbing specific stretching, etc. This pushes your max grade.
  • Same with all other sports…
  • This can be extrapolated to software engineering as well. You can just be doing your work from day to day or you can be deliberately spending some time to advance. This can come in the form of taking courses, reading books, working with your mentor, trying new technologies out, etc.

Mental resilience

  • Elite athletes frequently employ self-talk such as “You will move up” and “You are #1” to boost performance. Experiment with positive self-talk. Maybe read book “Unf*ck youself”. I know this sounds odd and so on – but if top elite athletes are doing this there must be merit to it.
  • At work we should try to fight imposter syndrome. Too often than not we think that we don’t know enough and are not good enough, while the correct way is to think otherwise and if you are in a leadership position you should assure people you lead with their skills.

Metrics

  • I love measuring and tracking my health and sports progress. I’ve been doing so since 2016. Buying a Garmin sports watch was one of my best purchases of my entire life. My latest one is Garmin’s Fenix 7X Pro Sapphire. The reason this is one of the best purchases is because it is motivating to know how you are progressing (at least for me) and unlike regular apple/google watches this one is sport oriented and battery lasts 28 days (yup ‘days’).
  • I’m creating this health/sports snapshot for myself and will be able to compare it a year from now. Around birthday seems to be a good cadence:
    • Age: 37
    • Weight: 150lbs (68kg)
    • Sleep: avg 7h17m vs. avg sleep need: 8h02m
    • Vo2Max: 56 mL/kg/min
    • Heart: HRV: 47ms, rest: 53bpm, max: 166bpm(avg/year)
    • Run PRs: 5k 22m53s, 10k 48m17s, Half: 1h58m
    • Weekly minutes: 348m (avg weekly over year 10/2024-10/2025).
    • Calisthenics: Max pullups: 21 Max pushups: 102, max pushups in session: 600
    • Max climbing grade: V7 (boulder) and 5.11+ (rope)
    • Max barbell: deadlift: 255lbs, bench: 150lbs, squat: 140lbs (yeah, I know, bench more than squat 😂)
    • Swim: barely making it across the pool, but something I want to improve
    • Bike: 10mi – 35:30, 30k – 1:09, though I never tried to push for anything here
  • This is a direct parallel to our work in engineering. We are judged by metrics as well, like how many pull requests we do, the impact of projects, operational metrics, code quality metrics. I do personally pay attention to these as well and rigorously track them. I will share my weekly work methodology one day on this blog.

Risks

Pushing for anything in performance can have negative effects as well. Here are some personal notes (not universally applicable):

  • Chronic Traumatic Encephalopathy (CTE). A risk associated with repetitive micro-concussions, particularly in contact sports like MMA. Since I’m sparring with people who actively take part in competitions occasionally I get hit fairly hard (even though we try to be careful).
  • Injuries. I’ve had periods where I climbed 3-4 days a week resulting in shoulder injury which needed at least 3 weeks to recover. The key here is to listen to your body and to alternate activities and load.
  • Supplementing. Taking any supplements other than creatine, protein and, maybe, some generic vitamins is very questionable. I recommend against it, but you do you.
  • Burnout. Applying a “max-effort” training mindset to work 52 weeks a year can lead directly to burnout.
  • Metric Fixation. Over-focusing on a new running PR can lead to a physical injury, obsessing over proxy metrics (number of code changes or lines of code) can lead to a career injury which is optimizing for the wrong thing, and missing the actual business impact.

Consistency

Probably the most challenging part of the any of the above levels is consistency. It’s just hard. It’s hard to go on a run when you just don’t enjoy it or when the weather sucks, it is hard to go climbing when the mood isn’t striking, it is hard to find time when you have an intense work schedule. So how do you solve these? I found a few ways that helped me, maybe something would work for you.

  • Cut off low value activities from your life. I do not watch any TV whatsoever. My social media usage is very low. I don’t play video games. I try to recognize time wasters, but may have blind spots. AI seems to be good at helping me unblind things.
  • Curve out time were you have opportunity. My company provides breakfast, lunch, dinner in the office so I leverage these for time saving. I specifically looked for place close to work so I don’t spend time commuting. Cut off nonsense and optimize time – time is the only thing you will never ever get more of.
  • Work on establishing habits. Books like ‘Atomic Habits’ and ‘the power of habit’ give great recommendations, but basically you need to build a clue to kick-off something automatically over time.
  • Find joy in your activities. I didn’t really like running at the beginning – it felt boring, but now I enjoy it and it definitely helps with anxious or depressing thoughts. I’m just going for a run when I need to clear your head. Climbing often is a social activity – solving problems with other guys and gals in a gym is fun.
  • Pair up. If you’ve got friends sharing similar sport interests it is always great to be done socially. I definitely miss those weekly 10k with friends back in Vancouver.
  • Find an accountability partner. Another thing I do in addition to everything above is having someone I am accountable to. It could be either through challenges I’ve been running or by simply promising someone. I hate breaking promises.

Conclusion

Our cognitive performance is inseparable from our physical health. The same principles that build a 10k PR or a V7 climbing grade are the exact same ones that build a high-impact, sustainable engineering career: you need fundamentals, deliberate training, and recovery.

You can’t sprint a marathon, and you can’t sprint a career without burning out. By investing in your physical platform, you are directly investing in your mental output. The return on that investment is a career and a life that is more performant, resilient, and sustainable.

Let me know what you think!

P.S. This post was in part inspired by my personal trainer from Vancouver. Thank you for your recommendations! And now I promise to incorporate compound barbell training once a week back into my routine and will report back after some time! 🫡


2 comments

The Practical Ceiling: AI, Diminishing Returns, and Our Future

October 19, 2025 AI, Opinion No comments

I would like to discuss a dilemma between near science fiction predictions of development of AI and grounded practical applications of AI.

Image credit: me + Gemini
Gemini or any other LLM does NOT take credit for the contents of the blog post, though!

First of all, it is completely undeniable that AI is changing our lives and will have a transformative effect on the future. We can argue that humanity has lived through many transformative events over and over again: invention of fire, agriculture, writing, electricity, industrialization, information technologies, so AI can be seen as just one more invention on our part. Now, is AI really just one more invention or something that would absolutely change what it is to be a human as we know it? Is this our last invention?

I just finished reading the book “The Singularity is Nearer”. The book is arguing that we will eventually extend the capabilities of our biological brains and go beyond the limits of our organic bodies. At first we would come up with inventions that would greatly extend and improve our lives (reaching “longevity escape velocity” in mid 30s) and that we will build brain-computer interfaces (think of phones now, AR glasses or something of the like next, brain implants next, nanorobots next, with eventual consciousness upload to the information network). As another book “Homo Deus” (my review) argues – we eventually become god-like and gain the ability to control life and environment and Homo Sapiens go extinct. We might eventually lose our carbon-based existence and just become information.

To my way of thinking, while much of that, like nanorobots repairing our bodies, may sound like science fiction, as long as it doesn’t break the laws of physics I’m on board that it can and may happen.

Now, let’s look at some more practical examples.

  • From transportation technology: Crossing the Atlantic would be 6 weeks sailing in the 1800s, 6 days in early 1900s with fast liners, 1950s – 8 hours by plane, 1970s – concorde doing that in <4h, and technically 90min possible from anywhere on planet to anywhere by rockets, but we are still flying boring 8h from London to NY.
  • Military: We came up with ever larger nuclear bombs, but post “Tsar Bomba” in 1961 it simply doesn’t make sense to make any larger ones.
  • Digital: digital camera resolution, audio quality, single processor’s clock speed, and many more examples where more has diminishing returns and becomes impractical.

This same pattern of hitting a practical limit is not just a historical curiosity because I can see it already happening in the world of AI. Let’s have a look at some examples:

  • LLMs are now reaching the plateau of information saturation where they basically learned everything there is to learn from the internet.
  • Vibe coding is mostly hype in my opinion. Yes, I do vibe-coding as well for fun, like my previous post about doing 3h multiplayer typing game, and it is a huge productivity booster, but I believe it fundamentally is like many other tools [post pending] – having logarithmic benefits – huge at the beginning and eventually ever more diminishing.
  • Plateau in image recognition. This once was a grand challenge of computer science, and is now a largely solved problem for most practical purposes, but pushing models to 99.9% accuracy is not practical.
  • Parameter count race. All those 7B to 70B to 1T parameter models. There is no point in multi-T models and the cost is just not worth it. I recently ran 7B LLM model on my mac air and it is not that bad at all. 

My point is that in many individual fields where AI is applicable we will be reaching the some kind of optimal point between theoretical possibility and practical application. In the process we will be seeing major transformations, like the entire sector of jobs associated with driving will be replaced by self-driving vehicles. There is a good chance this could create socio-economic disruptions and ripple effects. Just imagine, some rich “haves” can give their child superpowers while some poor “have nots” could not afford that. But I agree to the point that this is only “in-transite”, because now people in some poor countries can afford a phone that would be multi-billion worth of technology if this was mid last century.

My own predictions are that:

  • AGI is still very far away, a much longer time-frame than “The singularity is nearer” is arguing for. Maybe 10-30 years from now.
  • Each and every AI application will reach its optimal practical point.
  • Human lives will improve as they did with other technologies. 
  • Software engineering jobs won’t get extinct, but they will transform and we need to adopt.
  • I will die, but someone born next century might not.


No comments

Vibe Coding & Designing Typing Multiplayer Game

October 11, 2025 AI, Fun 2 comments

The other day my daughter showed me the typing game her teacher encouraged kids to play. My daughter was impressed with my typing speed. This blog post is to impress her even more.

The game she played was online typing practice – you type text and compete with other players for speed and accuracy. Players are represented as racing cars. If you win races you qualify to higher league of players. In this post I want to do few things:

  1. Vibe code standalone JS file – you can try it out right in this blog post.
  2. Vibe design a full fledged online game.
  3. Vibe implement the backend for the multiplayer game.

Vibe Coding Typing Trainer

Here is the result of about 30 minutes of work. You can play it yourself (if reading from e-mail you may need to open the blog).

This was achieved with 13 prompts, summarized like this:

1. Initial project creation prompt
2. CORS issue fix request
3. Container class addition request
4. HTML demo update request
5. Simple version (typing.html) request
6. Visual version creation request
7. Error display duration adjustment
8. Error display fix attempt
9. Revert request for error display
10. UI enhancement with "click to activate" label
11. Visual version adjustment request
12. Final revert request
13. History documentation request

Vibe Designing Multiplayer Game

Now instead of working with Claude, I started working with Gemini to create a design for the multiplayer game.

Here is the high level system design document: opens in another page.

Given that I explicitly prompted it to be fully stateless, relying only on client side local history, no login and no other complications this seems to be a fairly good start. My prompt was:

Now I want you to create a comprehensive system design to build the game described above. We need:
- simple website with JS logic
- backend that can create rooms of gamers based on their levels
- the game should protect user privacy so there is no user info stored on backend
- game history is only stored as long as user has local cookies
- backend should handle at least 10k users
- single game has max 6 players
- if user wins the game they are placed into higher league

As a next step I fed the generated system design document back to Claude in Visual Code. This time I had to fight a lot more with the AI as it was running into issues connecting players but finally arrived at the multiplayer game:

Prompting history:

- Initial setup of multiplayer backend server
- Setup Node.js with Socket.IO and databases
- Create basic server structure
- Implementation of matchmaking system
- Create skill-based queue system
- Handle player matching logic
- Game room and state management
- Implement room creation and management
- Handle player synchronization
- Create typing texts table
- Add sample data
- Visual keyboard integration
- Add keyboard visualization to multiplayer version
- Implement key highlighting


The backend is powered by:

- Node.js
- Socket.IO (for real-time WebSocket communication)
- Redis (for server-side data/caching)
- PostgreSQL (for the database)

Conclusion

I have complete confidence that if I had 2 or 3 days to spend on this I could actually create a game that can be put out there on some servers and be actually playable by actual human beings! The new world of AI is nuts. I’m out of my time allocated to blogging, but I’m convinced over and over again, that the old times of programming are over – the only way to survive is to adopt.

P.S. Another thought: I have a friend who works on Linux kernel stuff. You would imagine that hardcore stuff like that would not be affected by the era of AI, but no, he says that AI helps to properly review pull requests to the kernel and catch real issues, moreover it does help to build more complex things. Caveat, of course, is that the proper knowledge is still required. Who knows, if I knew nothing about programming, maybe, I wouldn’t be able to build this typing game so quickly? Or, maybe, this is just a matter of time?

Github: https://github.com/andriybuday/typing-trainer


2 comments

Finding Your Voice at Work

October 5, 2025 Opinion, RandomThoughts No comments

“If you stay silent as a mouse you will just stay where you are.“

This was the advice I got from a team lead at my first job, right after I’d rushed through the office to complain about a broken system that endangered a delivery to our client the next week. He praised me and didn’t want to shut me down, even if I might have overdone it. For many of us, finding that voice is the hardest part. We hold back our ideas, questions, and concerns for a number of reasons. Let’s break down the four most common ones:

  • We assume that something is obvious.
  • We assume that others know better.
  • Deference to authority.
  • Physiological: not feeling safe, fear of judgement.

Stating the Obvious

One of the biggest mistakes we make is assuming that others have the same knowledge or perspective as we do. What seems obvious to you is often the result of your unique experiences, learning, and context. But others may not have the same background.

One of my university professors used to say there are only three types of proof: by contradiction, by reasoning, and obvious. I struggled with the 3rd one because when something is somehow “obvious”, it wasn’t that obvious to me at all.

Quickly re-stating that “obvious” part often removes the ambiguity from the discussion and sets the common baseline. Without being aligned on the same baseline the entire conversation doesn’t make sense, that’s why it is super-important to simply re-state the “obvious” and explicitly list what the assumptions are.

Sometimes I notice how very senior leaders would ask very basic questions about something only to witness that not everybody in the room was on the same page about this basic truth.

Sharing the “obvious” has very little drawback. While there may be a small cost, say a bit more document space or an extra minute in a meeting, that cost is a cheap insurance policy against catastrophic misalignment. A little information overhead is always better than massive miscommunication.

Others know Better

It is oftentimes true that others know better (to state the obvious). But this shouldn’t be a blocker, rather it should be an incentive! If you speak up and you’re wrong, you become the main beneficiary: you get corrected and learn a critical piece of information. If you’re silent, you leave the meeting still misinformed. If a question is forming in your mind, it’s highly likely that several other people in the room are thinking the exact same thing but are too afraid to ask. By asking, you don’t expose your ignorance; you serve the collective need for clarity.

Deference to Authority

Sometimes it’s not fear or lack of clarity, but simple deference to authority. When senior leaders are present, people instinctively stay quiet, assuming their ideas matter less or that others will take the lead. This one is tricky as it also includes some cultural aspects of how you were raised and also cultural aspects of your company.

More often than not, however, leaders actually want more people to speak. They value a challenging question or divergent perspective far more than a room full of nodding heads. In fact, leaders sometimes speak first precisely to kick-start the conversation, and they often intentionally hold back because they don’t want their presence to silence the room. In fact, sometimes leaders don’t speak at all precisely because they want to ensure others feel there is room to contribute. Silence out of deference is perceived as alignment, which can lead to misguided decisions. Don’t assume your idea matters less. Assume your perspective is a critical puzzle piece the decision-maker needs.

Physiological Safety

This one is a tough one because it’s rooted in our fundamental human desire for psychological safety. This is a need that is not always easy to satisfy in high-pressure environments, such as the big tech corporate world.

Google has done this famous study “Project Aristotle” which concluded that psychological safety was the number one predictor of a team’s effectiveness, more so than the individual skills, intelligence, or seniority of the team members. The “how” a team worked together was more important than the “who.” Safety there means that team members are confident that no one will embarrass or punish them for admitting a mistake, asking a question, or offering a new idea.

Being comfortable taking “interpersonal risks,” such as challenging the status quo, offering divergent ideas, or asking for help is a lot more beneficial than taking another risk of closing in and solving the problem on your own.

Conclusion

The path from “mouse” to “wolf” isn’t about aggression or volume. It’s about recognizing that your unique perspective is a crucial piece of the collective intelligence. Your job isn’t to be an expert on everything, but to ensure that the room has all the information it needs: whether that’s stating the obvious, asking the ‘dumb’ question, or challenging the senior leader. So:

Ask the ‘n00b’ question. Challenge the status quo. State the obvious. Share your ideas. You lose virtually nothing, but the collective clarity and your growth is a big win. Speak up!


No comments

Talk Is Cheap; The Smallest Code Change Speaks Loudest

September 28, 2025 Opinion No comments

How many times have you been in a meeting where a brilliant idea was discussed, only to have it disappear into thin air? “Talk is Cheap; Show me the code” by Linus Torvalds perfectly captures the frustration, which roughly means that ideas, promises, or arguments don’t carry much weight until they’re backed by action. In software, the ultimate proof is working code. To be brutally honest, I often talk more than I code, and while talking is important at more senior roles, the ultimate delivery is still code.

From “Wouldn’t It Be Nice” to “I Did It”

I have been in multiple discussions where we were talking about some tool or some product and we all thought, “oh, it would have been nice if the tool had this capability or just this extra command flag we can use”, but because none of us had familiarity with the tool it basically stayed with that “would have been nice”. Over time I noticed: diving into the code is usually less intimidating than it looks. Once you do, you not only solve the problem but also gain familiarity others don’t have.

Why don’t people do this more often? It’s simple: it requires effort taking time away from your main project and has a high risk of failure. My proposal is to time-box your effort. There is definitely a sweet spot where you can spend y hours on the thing, where uncertainty reduces the most drastically, to make the final call if more effort is worth it. The ‘y’ should be somewhat proportional but limiting to the benefit ‘x’ you get, maybe y = sqrt(x).

The Approval Stamp: Reducing Friction

Another example: I was using some internal tool and it had a simple UI validation bug. One path to take was to file a ticket with the team owning the tool, someone would look it up, which would definitely be low priority on their plate, and this would get fixed in few weeks or not at all, but I needed the fix right now to avoid workarounds, so I published the fix code change – literally 2 lines of code. It would have probably taken 2x more time to file the ticket and communicate with the tool owners. They only had to stamp the change.

A bit more abstract: let’s say you are using a system owned by someone else, and you need to change something from x to y. In one way you know that’s a simple change and the person is likely to agree, but explaining it and waiting for them to apply the change causes friction. Instead if you just do the change on your own, and getting Y instead of X is just an “approve” stamp on the other side you will get your stuff really soon.

How about Alignment?

But won’t you come across as someone for pushing for a change without aligning first? – Yup, there is such a risk. There is a very simple way to avoid this: just soften how you propose the change. Ideas: 1) give a quick short “heads-up” message “I have this idea to improve Z by changing x to y, I will share a preview change to show what I mean”; 2) frame your code change as a light proposal, a “preview”, a “suggestion”.

Conquering Uncertainty with Code

This is perhaps where the ‘smallest code change’ provides the most value. Many of us, myself included, can get lost in the abstraction of system design by drawing diagrams and talking through every possibility. While this is a necessary step, it’s not a substitute for engaging with the actual code. I’ve worked with software architects in the past who were so detached from the codebase that their designs were completely unworkable. They simply didn’t know what they were talking about. The solution is to complement your high-level design with ‘on the ground’ code.

The key learning for myself: whenever working on the design of something: do more code digging and make small refactorings along the way (even if a bit unrelated).

Feeling of Doing instead of Talking

This one is a bit subjective, but we are humans as well as software engineers. There’s a fundamental difference between talking about progress and actually making it. Pushing code feels a lot better than just talking about it. Wouldn’t you agree?

Next time you’re tempted to keep talking, try the smallest code change instead. It speaks louder than a hundred conversations. This is one lesson for me.


No comments

Conway’s Law Is Bi-Directional: How Teams Shape Systems and Systems Shape Teams

September 20, 2025 Opinion, TeamWork No comments

I once worked on a product where two Tech Leads couldn’t agree on direction. The result? Two different UIs for the same set of users. That’s Conway’s Law in action: systems mirrored organizational misalignment.

My personal observations over 17 years in large enterprise companies align with Conway’s. But I also believe this goes deeper. Causality runs both ways: organizations shape systems, and systems reshape organizations. In addition to this I think the technical problems the system is experiencing are reflections of communication dynamics.

Conway’s Law and Examples

A quick reminder of Conway’s Law: “Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”. There are other variations of this. A simpler one I like to personally use in my conversations could be “Organizations design and build systems that mirror their own communication structure”.

For instance, if the company has extremely autonomous teams/orgs the company may end up in a situation where different systems are built with different tech stack and are fully decoupled but also hard to integrate if needed, but, let’s say if within an individual team/org communication is frequent and multi-directional their system might be tightly coupled and un-modular.

Direction of Causality: Org <=> System

So is it that once you have your organization you will end up with a particular system or is it while you build the system the organizational structure will simply organically mimic it?

That’s an important question and I’m of the opinion that this works both ways, meaning you can do re-orgs which will eventually lead to changes in technical aspects of the system, or you can make and push for design choices that over time will lead to org changes (like creating a team for a sub-module).

Companies sometimes deliberately reorganize teams or how they communicate (“Inverse Conway Maneuver”) to influence product architecture. This is one of the other reasons why re-orgs happen, but probably less frequently.

Take Amazon’s mandate for all of the internal teams to use AWS? I was on one of such teams and had to migrate some of our services to use AWS. This approach allowed Amazon to mimic external communication internally (external companies using AWS => internal teams using AWS). Internal engineers were both users and builders, so AWS could iterate quickly on real pain points. In this way feedback loop was that new communication channel that influenced how the systems evolved.

While Conway’s Law is usually stated as “organizations shape systems,” in practice I’ve seen a feedback loop. As soon as you draw a boundary in code, questions of ownership arise, and soon an organizational boundary emerges. Conversely, when leadership merges teams, systems often collapse back into monoliths or shared modules. Architecture creates new communication needs, which shape team structure, and team structure in turn reinforces or redefines architecture. This is why I argue causality is bi-directional: the system and the organization co-evolve.

When Communication Breaks Down

Communication bottlenecks eventually show up in code. Where teams don’t talk, APIs and integration points often become pain points. One team might be making assumptions about how the system behaves, they built their system based on that assumption and eventually operational issues show up. I personally observed this more frequently in micro-service based architectures, but monolithic systems are also susceptible to this.

Sometimes it takes introducing a liaison or two between two teams/orgs to fix things up. I have been working for one division at IAEA (UN) but was given to work on the project for another division, we were able to successfully integrate systems owned by two divisions. It is not so much just my contribution but rather a good decision to introduce new communication channels which resulted in changes to system integration.

Highly cross-functional teams often produce more rounded, cohesive, end-to-end systems. I’ve been on teams where many different roles were involved and worked very closely together (Meta seems to be very strong at this) as well as on teams where product management, database engineers were working in disconnected mode, producing outputs in sequence, which resulted in delays and systems that didn’t really do what they were supposed to. 

Conclusion

Over and over I’ve observed mirroring between systems and communications structures, and I believe the causality is bi-directional, as such you can influence the system not just directly via design but by making organizational changes. The practical lesson is that you don’t always fix a broken system in the codebase alone. Sometimes the fastest path is changing how people talk, or who talks at all.


No comments

Vibe Coding AI that learns to play Snake game

September 14, 2025 AI, Uncategorized No comments

Today I’m Vibe Coding something and inviting you to follow along. This is not a very serious post. The purpose of this blog post is just to see how quickly we can build a NN that plays snake game and if we can improve it:

Steps we we will follow:

  1. Generating simplest snake game you can play with WASD keys.
  2. Generating AI that learns to play and watch it play.
  3. Attempt to improve generated code so it reaches better scores.

Step 1: Generating simplest snake game you can play

Obviously, I need to write a prompt to generate such a game, but being lazy (and not knowing too much about IA) I offloaded prompt generation to GPT:

Generate a good prompt for copilot AI in Visual Code so it generates code for the snake game. Snake game can be the simplest possible terminal based game on a small field.

The output was pretty reasonable prompt, which I could have written (but, hey, that takes time). The only thing I updated in the prompt was the very last line to keep track of the score of the game:

# Write a simple snake game in Python that runs in the terminal.
# Requirements:
# - Keep the game as simple as possible.
# - Use a small fixed grid (e.g., 10x10).
# - The snake moves automatically in the last chosen direction.
# - Use WASD keys for movement (no fancy key handling needed, blocking input is fine).
# - Place food randomly; eating food makes the snake longer.
# - The game ends if the snake runs into itself or the walls.
# - Print the field after each move using simple ASCII characters:
#   - "." for empty space
#   - "O" for snake body
#   - "X" for snake head
#   - "*" for food
# - Keep the code in a single file, no external libraries beyond Python standard library.
# - Keep it short and readable.
# - Keep the score of the game. The score equals the total number of food eaten.

The generated code (with gpt-4o) was 73 lines of code and I could play the game in the terminal: https://github.com/andriybuday/snake-ia/blob/main/snake_game.py

Step 2: Generating AI that learns to play and watching it play

Again, prompt to get the prompt:

Now we need another prompt. This time we want to use pytorch and will be building a simple 2 hidden layers neural network with reinforcement learning. Use large punishment for loosing the game and small rewards for each eaten food. We want to achieve quick learning without too many iterations.

The prompt it generated this time was much more extensive. Here are all of the prompts: https://github.com/andriybuday/snake-ia/blob/main/README.md I then fed that prompt to both GPT-4o and Claude.

Claude generated a much better AI. GPT generated something that couldn’t even get more than one food score, which Claude was in the territory of 10-20 score. Note, that max theoretical score on 10×10 is 99. You can see above a gif showing last few epochs of training and game play of the Claude version.

The code for this version: https://github.com/andriybuday/snake-ia/blob/main/snake_game_ai_claude.py

Step 3: Improving AI so it reaches better scores

Ok, so what can be done to make this reach better scores? I asked GPT to recommend some improvements. It gave me general recommendations out of which I created a prompt for prompt:

Generate prompt I can give to Claude to improve performance of the Snake AI, potentially with these improvements: Change head to Dueling DQN, Add Double DQN target selection, Add PER (proportional, α=0.6, β anneal 0.4→1.0), Add 3-step returns, Add distance-delta shaping + starvation cap.

To be honest, at this point I don’t know if these improvements make sense or not, but I took the generated prompt and fed it to Claude. And what I got was broken code, which crashes on the “IndexError: Dimension out of range”. I was hoping to run into something like this. Finally. Now I can probably debug the problem and try to find where we are running out of range, but no, I’m sharing the error and stack trace to Claude again. It was able to fix it BUT things got worse, the snake would run into infinite loops.

Turns out generated “upgraded” version is much worse. So I decided to take a different path and get back to simple first version and see what can be updated. The only things I did were increasing training time (# episodes), allowing for more steps for training, and slightly decreasing time penalty. This is the change: https://github.com/andriybuday/snake-ia/commit/796ad35924700dcb73ac6aaecf8df39ec8069940

With the above changes the situation was much better but still not ideal.

Conclusion

Sorry for the abrupt ending, but I don’t really have time to fine-tune the generated NN or create new models to achieve the best results. The purpose here was to play and see what we can get really quickly. Also another purpose of this post is to show that people, like me in this case, who just do Vibe Coding without knowing underlaying fundamentals cannot really achieve best results really quickly. Happy Vibe Coding!

Try it yourself:

git clone https://github.com/andriybuday/snake-ia.git

cd snake-ia

python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

python snake_game_ai_claude.py

..........
......OOO.
....OOOXOO
....OOOOOO
....O.....
..O.O.....
..OOO.....
..........
......*...
..........
Length: 21  Steps: 161
Game Over! Final Score: 8.9


No comments

My Framework for Dealing with Ambiguity

September 7, 2025 Opinion, Personal No comments

Dealing with ambiguity is one of the key skills sought after in software engineers. The more senior you are the more you are expected to know how to handle it. But even outside of work we have to make decisions in uncertain situations. In this post I would like to share some thoughts on this go over existing frameworks, and synthesize a new framework.

Before we dive in, so that you know, I don’t like uncertainty and ambiguity that much and would like to briefly revisit a point from a previous post, that a person has to be a psychopath not to worry about uncertainties at all, but at the same time uncertainty is a core part of our lives and we should learn to embrace it.

Baselining

Let’s first expand a bit, mainly because “dealing with ambiguity” has some ambiguity to it. The word itself could mean uncertainty but it can also mean something bearing multiple meanings. Multiple meanings to the same definition is a more strict meaning of the word, but:

  • If you interpret it as purely ambiguity (multiple interpretations), you might miss the fact that your company also expects you to handle incomplete, uncertain futures.
  • If you interpret it as just uncertainty, you might miss the expectation that you actively clarify, simplify, and drive alignment when things are already vaguely defined.

So for the sake of this post it is both: uncertainty and multiple interpretations.

Expanding

What are some existing frameworks and approaches  for dealing with ambiguity?

  1. Cone of Uncertainty
    1. What: Early estimates are highly uncertain but converge as more information is discovered.
    2. Personal take: I really like to point to this one whenever someone isn’t too sure about a project. I don’t only frame it as estimates but overall uncertainty and ambiguity reduces as the time passes. This also helps me put any project into perspective and 
  2. Double Diamond
    1. What: The Double Diamond is a structured approach to tackle design or creative challenges in four phases:
      1. Discover/Research → insight into the problem (diverging)
      2. Define/Synthesis → the area to focus upon (converging)
      3. Develop/Ideation → potential solutions (diverging)
      4. Deliver/Implementation → solutions that work (converging)
    2. Personal take: Honestly, the double-diamond framework isn’t something I knew about before writing this post, but I could see how it is similar to what I’m used to doing anyways whenever designing a system at work or even approaching something creating, like writing a blog post.
  3. OODA: Observe–Orient–Decide–Act
    1. What: Borrowed from the military framework for fast-moving, changing situations and decision making. This is particularly useful for competitive environments.
    2. Personal take: while software engineering isn’t so dynamic and competitive, some elements of this framework are useful, especially quick re-orientation based on observations.
  4. Cynefin framework
    1. What: Cynefin offers four decision-making contexts or “domains”:
      1. Obvious (Clear): Cause–effect obvious → apply best practices.
      2. Complicated: Cause–effect requires expertise → apply good practices.
      3. Complex: Cause–effect only clear in hindsight → probe, sense, respond.
      4. Chaotic: No cause–effect → act to stabilize, then respond.
      5. Confusion (Disorder): Domain unclear → break down into parts.
  5. First Principles Thinking
    1. What: When ambiguity comes from assumptions, noise, or convention, break down a problem to its fundamental truths, then build reasoning from the ground up.
    2. Personal take: this seems to be the best approach when you observe that people talk about the same thing but in different ways or they use same words but mean different things.
  6. Lean / Agile
    1. What: Build → Measure → Learn loop to reduce uncertainty with fast experiments.
    2. Personal take: In a way agile was specifically created to deal with ambiguity by prioritizing adaptability over too much upfront planning (waterfall). I personally was a big proponent of agile methodologies. Sometimes there are too many rituals associated with these methodologies, but otherwise it’s great.
  7. Others…

Map -> Reduce by Priority

Can we synthetize these approaches into something that works specifically for us, software engineers? Maybe, yes, maybe not. What I mean is that sometimes one particular tool works best in one situation but doesn’t work too well in another. But regardless, I think there are enough similarities and here is my attempt, based on my experience:

  1. Step 1: Baseline: quickly document known knowns, known unknowns, and range for unknown unknowns. Potentially something like Cynefin categorization can be used here, but I normally just go with a format that best works for a given situation. 
  2. Step 2: Expand: Go on a quest to discover and collect even more of the unknown. Yeah, this step is actually hard to do, because instead of formulating some hypothesis or making assumptions this asks to seek more uncertainty. Practically, most of the time, this boils down to talking to more people and asking them to give more points of contact to talk to. Obviously, the more people you talk to the more perspectives you get. I think this overlaps with “Discover/Research” from the double-diamond or “observe” from OODA.
  3. Step 3: Map -> Reduce by Priority: Analyze information collected in the “Expand” step, identify key similarities, and group where possible, thus reducing the number of possible interpretations and meanings. One important thing could be to see which of the collected artifacts might have the outsized end result on the project. For example, an increase in latency of a service is uncertain, but it simply could be a complete blocker for the project, so this uncertainty should be prioritized. No point in reducing uncertainty elsewhere if this one shows the entire idea is no-go. There might be multiple tracks to reduce uncertainty here and this can be parallelized (similarly to map-reduce). This roughly maps to “decide->act” from OODA or “Define”/”Deliver” phases from double-diamond, or “measure” phase from Agile / Lean.
  4. Step 4: Synthesize and Iterate: Some of the most critical uncertainties and ambiguity was reduced in the previous step, so now it is a good time to converge on a new revised state of the things and suggest a course of action based on gained knowledge. Practically this means answering all of the questions about most critical unknowns, and how remaining unknowns will be mitigated.

Synthesize and Iterate

The Framework:

  1. Baseline: List what’s known and unknown (use Cynefin or a simple format).
  2. Expand: Actively seek more perspectives and data to surface hidden unknowns.
  3. Map and Prioritize: Group findings, reduce interpretations, and tackle the highest-impact uncertainties first.
  4. Synthesize and Iterate: Converge on a clearer picture, decide actions, and repeat as needed.

Conclusion

In fact, I used this same framework while writing this blog post. Baselining what I knew, expanding with research, mapping frameworks, and finally synthesizing a new approach. Ambiguity is unavoidable in code, projects, and life. I’d love to hear how you personally deal with ambiguity, are you using any structure or framework for it?


No comments

How I Finally Made Early Mornings Work for Me (After 20 Years of Failing)

August 31, 2025 Opinion, Personal 2 comments

I found a “cheat code” for my productivity, which is getting about 3 hours of deeply focused work before any meetings.

Sunrise from the top of a volcano (credit: me). Waking up early feels like catching this view: hard to get to, but worth it.

Yes, it does sound like a cliche to say “wake up at 5AM and get most work done before others wake up”. But for most of my life this was pure fantasy. In the past during early AM I used to be a brainless zombie. More often than not I would snooze all of my alarms (like seven times, not joking). Whenever I tried to go to bed early I would get laughed at and it didn’t actually work.

Sometimes I would get these 3 hours of focused work in the very late afternoon once meetings are over or at night. This worked, but the consistency was missing. The problem with evenings is that life has its own plans and oftentimes you get some commitments in the evenings. Super early mornings, on the other hand, are different. There are no meetings, no interruptions, no notifications, no nothing. You are in full control of your time.

Here is what finally worked for me (and no, I’m not selling anything):

  • Enough sleep. The single most important factor was to get enough sleep the night before. My needs for sleep change depending on the amount of physical activity and the quality of sleep the previous night. I had to learn to adjust. I’m using Garmin “sleep coach” and if it says to sleep +40min this is what I target to go to bed earlier. I found that, for instance, a super-intensive kickboxing class increases my needs by about 50 minutes. Not getting enough sleep wrecks the next day.
  • Autopilot morning. I removed all of the friction from early morning routines. I prepare all my clothes, work stuff, keys, everything the night before. Everything is in the exact same spot every morning. When I wake I don’t have to think. I just go on fast autopilot and 25 minutes from wake-up (no joke) I’m in the office sipping my reward: espresso coffee freshly made by myself in the office. By now it is a bit of a ritual for me.
  • Commitments. I keep running accountability growth challenges with friends. That additional accountability layer keeps me honest.

The results?

The biggest change isn’t just productivity but it’s how I feel.

When I used to start my day around 10AM I felt agitated. I’d go through early meetings half-asleep while knowing there was real work piling up in the background.

Instead now, as a huge contrast, I enter the day having already accomplished something of substance. The other day, before the first 10AM meeting, I published 3 code changes and wrote 2 documents. I don’t always do this much early on but this shows the scale of the difference those few early hours make. I enter meetings calmer, more confident, and less reactive. 

Conclusion

I failed for 20 years before I was able to do this. I didn’t want to write this blog post until I had at least half a year of consistent early mornings, because that’s the hard part. For me, waking up early stopped being a punishment and became a secret weapon. I’m actually looking forward to working hard and focused early when no one can distract me. If you are struggling with something, don’t give up, try again. It might take time, but eventually it can work out for you too.

I’m curious what’s your cheat code for creating time for deep work?


2 comments

On AI and Adaptability: AI is an asteroid and your software engineering job is a dinosaur

August 24, 2025 AI 2 comments

AI is the asteroid. Your job is the dinosaur. The question is: will your career evolve like mammals, or go extinct like T-Rex? I’m not saying that software engineering jobs will disappear, I am saying they will transform from their current form. Dinosaur jobs are things like writing boilerplate CRUD. New mammal jobs are things like designing AI-integrated systems. There is a lot in between that evolves.

Tech companies are now piloting AI powered interviews where you have to build something using AI during the interview. Are you ready for such an interview? I’m definitely not ready. Would you be able to survive this change next time you are on the lookout for the new job?

These days, with AI, being productive as a software engineer is not the same. A bit of a challenge with AI tools is that they are all new and rapidly evolving. One day, writing good prompts is good skill, next day building AI agents to do the job for you is the next thing, one model is good at this, another one is good at that. The amount of things available is also quite overwhelming.

I remember at one point in my career I felt I got really good at using Visual Studio with Resharper, so good that it actually felt like a significant differentiator in my speed compared to others. Then when I had to switch to other tools/tech (frontend, java, aws, other IDEs, etc) it felt unnatural and was leveling the playing field or placing me at disadvantage compared to people who already knew how to use the other tools. At the same time, the more I had to learn new tools the easier it was to switch the next time.

Adaptability is probably one of the best skills to work on during this rapid evolution in tech. We simply cannot afford to ignore AI, that would be the biggest career mistake you could make right now.

And to make one more point very clear: I believe that software engineering requires strong fundamental knowledge that doesn’t change: understanding of how computers work and interact with each other, understanding of how software runs, algorithms. There will always be a need to figure out how to translate business needs into these fundamental concepts, it is just that the translation tooling landscape is changing and we need to get good at them.

The asteroid has already hit. Your career’s survival depends on adaptability and fundamentals. Learn fast, stay curious, and don’t bet your career on yesterday’s tools. I’m writing this as much for myself as for you. I need to step up a lot.

What is a new AI tool/concept you learned last month?

(for me it was about the architecture of AI agents, incl. MCP protocol)


2 comments