HN user

silentpuck

22 karma

Tools for invisible people. GitHub: https://github.com/SilentPuck Email: SilentPuck@proton.me [ my public key: https://keybase.io/silentpuck; my proof: https://keybase.io/silentpuck/sigs/ukzZ9iiMHy-0COnCy0f59f9RWMsd9LBlEEVoG8hzXE4 ]

Posts5
Comments29
View on HN

I don’t want to sound discouraging, but I’ll be honest.

First of all, you need to figure out what you really want and what you’re willing to do to get there.

Some people mentioned starting your own project above. I think that’s a really great path. I was in a similar situation: I started learning programming about five years ago. I don’t have a technical background at all — I’m actually a humanities student. I didn’t choose programming because it was trendy. I chose it because something inside me said, “This is my path.”

At the time, I lost my job. I had several children to take care of. It was a tough time, but I kept learning every day - step by step.

And now? I create things. Not for money yet - for craftsmanship, for freedom, for the future. And little by little, doors are opening.

That’s why I say: follow your heart, but don’t forget about your mind.

No problem is unsolvable. Sometimes the road is long. But it’s still a road.

Yeah, that’s a fair point. Abstraction is part of progress — and we do rely more and more on things “just working.”

But that trust can be dangerous when we don’t even know what we’re trusting. And when something breaks, it can leave us completely blind.

I’m not saying everyone needs to go all the way down to the metal — but I do think it’s important to at least understand the boundaries. Know what’s underneath, even if you don’t touch it every day.

Otherwise, it’s not engineering anymore — it’s guessing.

And I’ve never been good at just “believing” things work. I need to poke around, break them, fix them. That’s how I learn. Maybe I’m just stubborn like that.

Yes, I think many people are starting to feel this exact tension.

The key, I believe, is to mentally reframe the AI: it's not the driver, it's your assistant — a helper, a debugger, maybe even a silent teacher. But you're still the architect. You're still the creator.

The problem begins when we forget that. When we let the AI lead the design, the structure, the reasoning. That’s when we start losing ownership — and understanding.

Ironically, AI was built to help us — not to replace our thinking. But without solid fundamentals, it's easy to let it take over. And then we're just directing prompts, not building things we truly understand.

I think the real sadness is that many developers may stop learning the deeper fundamentals — the things that AI can't replace.

When people start relying on the "I just want it to work this way" mentality and let AI take over, they can lose track of how things actually work under the hood. And that opens the door to a lot of problems — not just bugs, but blind trust in things they don't understand.

For me, the joy is in understanding. Understanding what each part does, how it all fits together. If that disappears, I think we lose something important along the way.

Absolutely fair.

If I needed to ship a product quickly and prove something to investors or customers, I would choose a higher-level language too.

For me, C programming is not about speed, it's about deep understanding, intention, and creating things that I truly understand and can control.

But I get it - at the end of the day, we all have bills to pay. Thanks for sharing your insight.

That’s a really insightful way to put it.

I think you're right — being in the driver seat gives one kind of experience, but leading a team under pressure is a different challenge entirely.

I guess every generation of developers finds their own balance between freedom and safety.

Appreciate your perspective.

I really appreciate you sharing that journey — it reads like a personal history of programming. I’ve heard others mention the elegance of Turbo Pascal and Delphi, especially the string handling. And yes — C macros and pointer syntax can absolutely feel like arcane incantations sometimes.

I guess in the end, we all gravitate toward the languages that feel like home.

I use LLMs mostly for learning and understanding.

When a book doesn’t explain something clearly, I ask for a deeper explanation — with examples, and sometimes exercises.

It’s like having a quiet teacher nearby who never gets frustrated if I don’t get it right away. No magic. Just thinking.

I also started building my own terminal-based GPT client (in C, of course). That’s a whole journey in itself — and it’s only just begun.

That’s a great point — C# really does hit a sweet spot between control and convenience.

I’ve never spent serious time with it, but I’ve heard a lot of good things about the tooling and the ecosystem.

Maybe one day I’ll give it a try — especially if I ever need something with more abstractions but less ceremony than Python.

Thanks for sharing your take — it’s always helpful to hear how others find their flow.

Yeah, I think you’re right — Python really shines in many areas.

Honestly, a lot comes down to the person, the kind of problems they solve, their mindset… and sometimes, their scars.

I don’t even fully know why Python didn’t click with me. I understood it. I saw how fast it can be. But for some reason, I kept drifting back to C.

Maybe it’s just how my brain works. Maybe it’s where I found meaning. Hard to explain.

I’ve heard similar thoughts from others who went into Rust expecting something radically freeing — and found themselves wrestling with the borrow checker and unexpected heap usage.

I still want to explore Rust at some point, but I think it’s important to hear real experiences like yours.

Sometimes the simplicity of C — for all its sharp edges — feels more honest.

That’s a really fair question.

For me, it’s not just about building tools — it’s about understanding what I’m building.

I like knowing where the bytes go. What the memory looks like. How the binary behaves. It slows me down, sure — but it teaches me things I didn’t even know I didn’t know.

I’m not building for scale or clients. I’m building to see.

That kind of closeness makes the machine feel less like a mystery, and more like a partner.

I’m really glad to hear that. It’s easy to feel alone in that view these days — but the more I talk to people who build things close to the metal, the more I realize we’re not as rare as it seems.

I remember trying Python once — it didn’t click. Then C++ — and when I hit memory management, I didn’t turn away… I got curious.

So I looked deeper — into C. And somehow… I stayed.

Thanks for sharing that.

That’s fascinating. I never thought Java could get that close without tripping on GC. Must’ve taken a lot of careful design and deep understanding.

I’d honestly love to read more about setups like that — maybe in my quiet hours. Feels like something worth studying, even if I keep walking the C path for now.

I truly appreciate the depth of your response. I can see that it comes from long experience and serious thought.

I don’t claim to be immune to the sharp edges of C. I’ve already cut myself more than once. Maybe I’m bleeding now and don’t even know it yet.

But there’s something in me that still wants that control — even if it hurts. I’m not building for clients or large teams. I’m building for myself with intention.

Maybe I’ll shift later. Maybe I’ll come to hate C myself. But for now, every time I compile a C binary and see it run exactly as I built it — without layers, runtimes, or abstractions — I feel like I’m touching something real.

I’ll take a look at Rust. Not to escape C — but to understand memory from a different angle.

Thanks for your honesty.

Thanks! That's a solid method and definitely a good fallback when openssl or base64 are available.

passgen is more of a "C-first, offline, no-dependencies" tool — aimed at setups where even those might be unavailable or untrusted. But I’ll definitely keep developing it further, and may add some of the ideas you mentioned. Appreciate the input!