Tag: technology

Technical Debt

~ Veselin ~ 1 Comment

This is Bruce Wang from Netflix with his inspiring talk about Technical Debt. I enjoyed his talk and wanted to write about it but as it turns out, I’m opinionated on the subject and would like to share my thoughts rather than his. Bruce says Technical Debt is the delta between the current code and the ideal code. I think Technical Debt is when a coding team takes a shortcut and comes up with a solution that mostly works but needs future changes. The work that’s needed and may never be done is the debt.

Samples of technical debt from my experience:

  • Copy/paste, quick and incomplete fixes
  • Slowly building obscure God classes or long chains of ifs in long functions. All changes are tiny but the final result is bad
  • Quickly building large and complex pattern-based solutions to simple problems
  • Using old and unmaintained libraries
  • Insufficient test coverage or test coverage that’s guaranteed to break for legitimate changes
  • Agreeing on any kind of a second system and then insisting the old system is the technical debt until either the old or the new system is removed

Out of these, the second system presented the biggest and the most time-consuming challenges. All the other problems can be improved with small iterations but when you have two competing systems, you’ll keep having two until the very end of whatever the solution is.

This code is bad, it will be better to rewrite it from scratch

— An engineer getting in trouble

To my understanding, this is the worst type of technical debt – one that’s hard to repay because the best outcome of the work is that nothing visually changes. Some issues with rewriting:

  • Old code that’s in heavy use tends to cover many cases. Easy to miss them and produce regressions
  • The new code tends to focus on the area unsupported by old code so it quickly deviates from compatibility
  • The old code tends to accumulate changes that are unsupported by the new system while the new system is in progress
  • The amount of work is usually much larger than the wildest estimates
  • Migrating from one system to another is hard, and may even be cost-prohibitive
  • It never gets easier to complete it, and it keeps draining life from engineers doing this or that but never achieving the final result (one system)

Before I continue, note that sometimes rewriting is the only option. 20-ish years ago, I saw a complete ASP/MS SQL website that used horizontally expandable tables. A new record would need a new column. I was contacted as a freelancer to fix it because the owner ran out of columns. The whole thing felt bad beyond repair. It, however, was not a high-traffic or high-responsibility service.

In many cases, the rewrite is initiated when other solutions exist.

Here’s what I’d do if a rewrite of a heavy-use code is suggested. First, I’d come up with a vision for what the final result needs to be, then challenge that vision with honest questions like “Do I need this?”. Most of the time the answer is no, You aren’t gonna need it (YAGNI). With the vision in mind, I’d need to reach the most simplified version of the future version of the code with small iterations that go to production so that there are never two systems and there is no migration between them, for example, by using the Strangler Fig pattern. I’ve done this and it works well enough that nobody notices. And if the second system is started and never gets completed, it soon becomes everyone’s problem.

Bad Grammar Can Be a Feature

~ Veselin ~ 29 Comments

Engines love to consume lengthy content and rank it higher on search. ChatGPT can generate tons of additional meaningful text for the idea. However, as a reader, I prefer to read content written by humans and for humans. I’d rather read meaningful ideas in ugly sentences with simple words and poor grammar than AI-assisted beautiful novellas with a summary and headlines.

In that context, bad grammar, slang, lower-case text, and such can be a form of anti-language that identifies the post as human-written and non-AI-augmented. It can be a feature, not a bug (now I have an excuse to turn off Grammarly lol).

Headphones for calls – JBL Quantum 200 vs JBL Quantum 400.

~ Veselin ~ 9 Comments

I do many calls and my environment is often noisy – coffee shops, kids around, and ninja turtles on TV. I’ve tried finding headphones that have a good microphone and are comfortable for my ears. I believe the headphones need to be wired so I don’t charge them. I like retractable microphones. Over the last months, I used JBL Quantum 200 with a good success. Unfortunately, they broke so I bought a replacement. The local electronics shop only had Quantum 100 and 400, and here we are.

JBL Quantum 100 doesn’t have a retractable microphone but otherwise looks like my old headphones.

JBL Quantum 200 has a retractable mic with no cover and a roller for volume control. When folded, the mic is muted. That roller was a bit inconvenient until I got used to it because it would roll while the headphones were in my backpack. They broke soon-ish but come with a 2-year warranty.

Quantum 400 has a retractable mic with some cover, volume control, some other roller with unclear purpose, and a mute button. They also mute when the mic is folded.

Here are some mic samples from Starbucks, the speakers are right over my head and quite loud:

Quantum 200

Quantum 400

My backup Devia headphones for reference

Here is how they look.

The patch is not the broken old headphones, it’s the new ones. The reason is that the mute button is loose and makes a clicking noise that annoys me. So here I fixed it. I’ll upgrade myself with a fancier patch at some point.

Out of those three, my old JBL Quantum 200 headphones were the top pick. Sure, the 400s come with buttons, rollers, extra cables, and flashy LED lights packed in a fancy box. But, the loose mute button and the extra roller with no clear purpose actually made them worse. The microphone quality is sufficient in both.

Matt Mullenweg wrote a much more detailed post on the same subject – his recommendation was for a Sennheiser, which I followed 5-6 headphones back. The locally available set didn’t have a retractable microphone and couldn’t use it for calls from coffee shops. I moved on quickly.

UPDATE 2025-03-10

The JBL Quantum 400 also broke down. It’s a very minimal problem but nevertheless I’m going to look for a replacement in the following weeks. Overall, I think the Quantum 400 are significantly better than the 200 because of the better cable that can be replaced.

I think they’re better overall than the other headphones I used over the last 10 years but the build quality is not fantastic.

Disappointed by the second roller on my Quantum 400, I bought a pair of Quantum 100 as well. These are not up to the bar needed for my daily work needs. They’re less comfortable, the mic is located on a piece of wire, which is much less convenient than the Quantum 200/400 mic. I didn’t use them much and actually kept doing calls with the slightly broken Quantum 200s.

A measure for good code

~ Veselin ~ 5 Comments

Today we discussed with a colleague what is good code and what isn’t. We somewhat agreed that good code is code that can be understood and changed by people who aren’t the author. Hours later, I found this quote in the book I’m reading and wanted to share it:

The true test of good code is how easy it is to change it.

Martin Fowler, Refactoring

There’s code people understand, change, and create a mess. There’s code people understand, change, and don’t create a mess. There’s code people don’t understand and don’t change. It stays perfect until somebody decides to start over and create a two-headed Hydra because they see no other way.