1. Tutorial hell. I finished course after course and still couldn’t build anything on my own. It felt like progress, but it wasn’t. Things got better when I picked one small project and worked through the hard parts on my own.
2. Learning too many languages. I jumped between [C], [C++], [Java], [JavaScript], [Python], and [Dart] because the next one always looked cooler. Ended up knowing a little of everything and not much of anything. Should’ve just picked one language and stuck with it. For me, that’s [Python].
3. Leaning on AI too much. I used chatgpt for everything early on. My code worked, but I had no idea why. Then I had to debug something without it and I just sat there lol. Now I write it first and only use AI to explain stuff.
4. Not reading error messages. I’d paste every error into AI without reading it. It gave me a fix, but I never learned what went wrong. Now I read it line by line first.
5. Not knowing where to find real projects. I only found out about this GitHub search for “good first issue” way too late: https://github.com/issues/search?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 Reading real code and getting feedback on my pull requests taught me a lot, honestly more than most courses lol.
6. Comparing myself to others. I kept looking at people who were years ahead and felt behind. It killed my motivation. Comparing myself to me a few months ago works way better.
7. Never finishing projects. I’d get bored after a few weeks and start something new. I ended up with a pile of half-done projects and nothing to show. Finishing one small, bad project taught me more than starting ten.

Curious what others would add, especially people who are years ahead of me.

It starts like many such stories do, boy meets girl json meets postgres and it seems like a good idea at the time. Probably still is, too: the records are small enough (~1KB) and accessed often enough that putting them on-disk is detrimental and a bother, but they're variable and complex enough that splatting them onto normalised tables is not a big gain, and also a hassle.

And at one point you find out that one table, that one column, is 90% of the database, and growing. TOAST compression does a bit, each value only takes ~800B, but that's not really enough. External compression is considered and at 70% gains (300MB per GB) it's not bad, but it feels insufficient, and things are not urgent yet.

And you keep seeing cool news and articles about columnar storage and the ability to compress across records.

And then one day the brain finally draws a line between two dots: columnar storage can compress well because it's able to provide cross-record compression context and leverage that, per-record compression isn't that great because it has to start from nothing on each value. Dictionary compression is a means for per-record compression to not start from scratch on every record.

Dictionary compression has been a thing for a long time, but it's been making the rounds as it's been standardising as web tech with really nice savings, and pretty regularly zstd's great (though by no means unique) support for it makes the rounds again. It's a way to initialise the compressor "out of line", such that per-record compression starts from a known state instead of from scratch, and can immediately start creating backreferences into the dictionary instead of building up a compression window to reference into. It has the drawback of being static, but if your JSON records are all variable subsets of a large schema... that's a pretty good fit.

So gave it a shot, handed zstd's --train-cover a sample (default parameters), used the resulting dict on the full dataset, and got a cool... 92% savings (80MB per GB). Now we're cooking, that's definitely worth considering.

Sadly zstd is not an option in that application, however zlib also supports dictionary compression, a zlib dictionary is pretty much just the priming of the compression window. And the tail end of a zstd dictionary happens to also be the priming of the compression window, so chop off the last 16~32KiB of the zstd dictionary, pass that to a zlib compressor, apply to the dataset... 92% savings as well, with just your friendly neighbourhood zlib, and 3KiB of ancillary data (the difference between a 16KiB and 32KiB dictionaries was 0.1% so the smaller dictionary seemed enough — 8KiB lost an entire percent performance so that was a bit much — and the dictionary itself can be compressed with zlib, in this case the 16KiB dictionary compresses to 2900 bytes while the 32KiB one compresses to 4500 bytes).

So yeah TIL: if you have large per-record datum and can not use columnar storage, consider dictionary compression, it's surprisingly effective.

I ran into this in my own setup. A second model reviews the commits of my coding agent, and it flagged 17 lines of a Markdown log as deleted. The raw patch did show 17 minus lines.

When I compared the exact minus lines with the plus lines, all 17 were back in the same commit, word for word. Nothing was lost; the entries had just moved. A line diff has no "moved", only "removed here, added there".

Here's the check I put together for it:

bash

c=<commit>; f=log.md
d=$(git show "$c" --format= --unified=0 -- "$f")
comm -23 \
  <(printf '%s\n' "$d" | awk '/^@@/{h=1;next} h&&/^-/{print substr($0,2)}' | sort) \
  <(printf '%s\n' "$d" | awk '/^@@/{h=1;next} h&&/^\+/{print substr($0,2)}' | sort)

It prints only the removed lines that don't come back as added lines. Empty output means nothing was lost.

When I want to see it myself, git show --color-moved=zebra <commit> colors moved blocks differently from real changes.

It only catches exact moves, though. A line that was moved and edited still shows up as removed, so that one needs a second look.

In my Windows project, `git commit -- path` began exiting 139 while `.git` lived on a streamed Google Drive G: drive. A scratch repo tested the same behavior: with a 129,747-byte index, 0 of 15 commits crashed; at 131,464 bytes, 12 of 15 crashed. The larger index on C: had 0 crashes in 30 tries. Index v4 shrank it to about 89 KB and had 0 crashes in 15 tries. The project now keeps `.git` on C: and the working tree on G:.

I do not know which part of Git or the Drive mount causes that boundary. For a similar crash, checking the index size and repeating the partial commit with the Git directory on a local drive helped narrow it down here.

Hey everyone,

​I recently built a Telegram media downloader using Python, yt-dlp, and ffmpeg. When I was testing it locally on my phone via Termux (using my regular home ISP), it worked flawlessly. Every link, every platform, zero issues.

​Then, I decided to host it 24/7 on an AWS EC2 Ubuntu instance. That's when the nightmare started.

​It turns out YouTube absolutely despises AWS datacenter IPs. Here is the endless loop of issues I ran into:

​The Anti-Bo Wall: Immediately got hit with the dreaded Sign in to confirm you're not a bo and HTTP 403 Forbidden errors.

​The Format Mess: To bypass the block, I spoofed mobile clients (iOS/Android) in the extractor\\_args. It worked briefly, but YouTube stopped serving standard MP4s or MB3s, not only YouTube but every another platform, throwing Requested format is not available unless I completely relaxed the format selection to bv\\\*+ba/b and let ffmpeg do the heavy lifting.

​What I've tried so far to fix it:

​Imported a fresh Netscape cookies.txt (helped, but eventually gets flagged).

​Enforced IPv4 (source\\_address: '0.0.0.0').

​Spoofed iOS Safari User-Agents and player clients.

​Since this is just a free, non-profit personal project, I'm trying to avoid expensive overhead. I already know public APIs (like Cobalt) or free proxies are a dead end due to strict rate limits and constant downtime.

​So my question is: Is buying a cheap Residential Proxy my only real way out of this AWS block? Or is there some magic yt-dlp config/workaround I'm missing to make cloud IPs fly under YouTube's radar?

​Would really appreciate any advice

Nytril is a new programming language and IDE that looks a lot like C# and shares much of its syntax, but allows you to "program into" a typeset document. Think of it as a markup language and a programming language in one.

It is perfect for creating documents that contain data, charts, images, equations and text that are stored in other places or calculated on the fly, like product spec sheets. It's also perfect for making many documents at once that share the same style and source of truth. How many times have you been writing markup and wished that you could do some math or read a database in order to make a table?

Nytril runs natively on your desktop (Windows or Mac) so its fast and you can access data stores that are local to your network. It's easy to do version control on GitHub as well.

Free Community Edition installs in less than a minute and does not drag in any other libraries or drivers or junk.

GitHub https://github.com/auysh8/System-design-notes

The Authentication Stack: 7 Concepts Every Software Engineer Should Understand

https://github.com/Aviskar-1/Java-OOP-And_More-Learning

Check it out my Java codes on my GitHub Repository.

[Java]

https://docs.github.com/en/repositories/working-with-files/using-files/getting-permanent-links-to-files

Specific line: Just click the line number in the left side

Range of lines: Click the line number of the first line, then shift+click the line number of the second line to select the range

Range of characters: Select the text you want the range for, then click the line number of any line that contains the selected text

https://github.com/free-news-api/news-api

How to Pass a System Design Interview (The 45-Minute Blueprint)

There is no button in github to collapse all files, but you can do that if you click to collapse one of them while pressing Alt

https://youtu.be/NQZqET-jjws

https://youtu.be/ASF6snvxZUE

https://youtu.be/LLBrV5qRT3o

Right now, it’s in experimental stage. You can check out the repo here: https://github.com/ruxen-lang/ruxen

Thanks for taking a look!

TLDR; going from a curved monitor immediately to a flat monitor gives me a visual distortion that my flat monitor curves backwards.

I am a curved monitor convert. My last flat monitor was a pair of 4k 27" monitors. Love them. Then, I tried a pretty wide curved monitor. That was it, I'm never going back. I will never go to dual monitors either, I will just get a bigger curved monitor. I always loved the 4:3 ratio for programming and with a really wide monitor now have a left side and right side with that wonderful 4:3 ratio going. Rust rover on the left, and whatever on the right. Sometimes even 3 windows across with the IDE in the center.

But, I am working on a project where I need a monitor for a whole other system. For reasons it has to be entirely separate. I dug out one of my old 27" 4k monitors and I swivel about 150 degrees to use it, it is only for a few minutes every day. When I look at it, the left and right edges seem like the monitor is bent backwards.

This doesn't happen with my laptop monitors, 20 inch monitors, nor if I walk any distance and sit at a large monitor.

It is creepy as hell, but kind of fun.

I’m currently in 3rd year B.Tech CSE, 6th sem, from a tier 3 college, and I feel like I spent most of my college life being confused instead of moving in one direction properly.

In the beginning I learned C and C++, understood basic programming concepts from them, then switched to Python for some time. After that I found Java way more interesting than the other languages, so during 5th sem I started learning Java seriously.

I practiced a lot of Java questions on GFG to improve my basics and honestly I enjoyed it. Then recently I started learning Spring Boot because backend development looked interesting to me. I learned some basic concepts and somehow made a REST API project, but while building it I was confused half the time and kept depending on tutorials/documentation.

Now my 6th sem exams are coming in around 1.5 months, my CGPA is only 6.48, and suddenly reality is hitting me hard that college is almost over.

The thing is, I genuinely like Java and Spring Boot and I want to get a backend developer job in this field. But at the same time I feel like I started too late and don’t know if I still have enough time to become job ready, especially coming from a tier 3 college with an average CGPA.

I keep thinking:

• Should I fully continue with Java + Spring Boot now?
• Is it realistic to get a job if I focus properly from now?
• Should I spend more time on DSA or projects?
• What skills are actually expected from a fresher backend developer?
• How much Spring Boot do companies expect from freshers?
• Am I overthinking too much or am I actually behind?

I don’t want fake motivation honestly. I just want practical advice from people who have been through this or are already working in tech.

What would you do if you were in my position right now?

Everyone on LinkedIn and Reddit keeps saying "coding is dead" because of vibe coding and AI agents. But I think we are just entering the "Smartphone Era" of development

Think about photography. Smartphones didn't kill professional cameras, they just made "good enough" accessible to everyone. Even professional photographers use their iPhones every day to take quick pictures of documents or their pets because it’s incredibly convenient. But when they are hired for a high-end gig, they pull out the DSLR because they need total control over the raw output

The exact same thing applies to scale. If you are shooting a quick vlog, a smartphone is perfect. But if Marvel is shooting the next Avengers movie, they aren't going to film it on an iPhone. They need massive, dedicated cinema cameras for ultimate reliability

This is exactly what is happening in tech right now:

• Vibe coding is the smartphone. It’s perfect for the "vloggers" of tech (prototypes, simple CRUD apps, internal dashboards).
• Traditional coding is the cinema camera. You still need it for the "Marvel movies" of tech (think large-scale fintech, complex architecture, high-concurrency systems). AI currently struggles with big-picture system design and tends to just brute-force messy spaghetti code when the codebase gets too large.

The real problem right now is the marketing.

AI companies are giving us the software equivalent of those Apple "Shot on iPhone" commercials. Yes, the video was technically captured on an iPhone... but they conveniently leave out the $50,000 professional cinema rig it was strapped to, the Hollywood lighting crew and the master colorist behind the scenes

AI startups are doing the exact same thing by hiding the senior engineers who are manually fine-tuning prompts, debugging hallucinations and untangling the code to make these viral 2-minute Twitter demos work

So how should we actually look at vibe coding?

Think of it like an Uber driver. You aren't physically pressing the gas pedal or steering the wheel anymore, but you must know your exact starting point and your final destination. If the AI takes a wrong turn or starts hallucinating bad logic, you need to have enough foundational coding knowledge to tap it on the shoulder and direct it back to the right path

Learning to code isn't dead. It's just evolving from typing syntax to directing the machine

I made a video breaking down this whole analogy in depth, MKBHD's take on computational photography, and the reality of the AI hype cycle. You can check it out here if you are interested: https://youtu.be/7CtYToAYpWE

But honestly, the core of my argument is all in this post. Would love to hear what you guys think. Are we overreacting to the vibe coding hype?

I started my Patreon recently to document my learning journey and post helpful cheatsheets, full source code for my projects and more

[Patreon](https://www.patreon.com/posts/welcome-to-build-154186254?utm_medium=clipboard_copy&utm_source=copyLink&utm_campaign=postshare_creator&utm_content=join_link)