W tym momencie mój PC jest częścią środowiska testowego...
🔥 Gdy twój sprzęt staje się benchmarkiem dla monitora systemu, który tworzysz.
Debugging at 90°C: Old Laptop Chronicles
Coding PC_Workman on hardware older than some juniors...
Featured Posts
Best moments from my building in public journey
From Job Loss to Indie Success
Lost my job in December. Today PC_Workman has 1000+ stars...
AI That Actually Explains
How I built AI that speaks human, not just numbers...
2D Component Map - Deep Dive
Automatic motherboard detection and PC interior visualization...
Building in Public: 6 Months Later
What worked, what didn't, why transparency beats marketing...
Detecting Crypto Miners with AI
Pattern recognition + machine learning for suspicious processes...
LinkedIn - More technical, but also personal!
Professional updates and career reflections
HCK
I built publicly for 5 months. Nobody was watching. Then I got fired.
What happens when you lose everything three days before the holidays? 680 hours of code on a dying laptop. 4 complete rebuilds. 12 people watching. Then came December 22...
[Article featured image - PC_Workman v1.5.7 screenshot]
Hey! If you have 10 minutes and coffee, I wrote something personal about 680 hours of code, 4 complete rebuilds, a laptop that nearly caught fire, and what happened 3 days before the holidays.
No "5 steps to success". Just an honest story and what I learned along the way. Maybe it helps. Maybe it doesn't. But if you're building something on your own and sometimes wonder "does this even make sense?", this is for you.
A scenario nobody romanticizes: Not for IT work. Not for a startup. For warehouse work. Order fulfillment. The kind of job where you walk 15-20 kilometers a day between shelves.
By day: warehouse worker earning to survive. By night: building software on a 2014 laptop that hits 94°C just running VS Code. Nobody posts about this version of "building publicly" on LinkedIn.
The idea that wouldn't leave me alone: I was frustrated with PC monitoring tools. MSI Afterburner, HWMonitor, GeForce Experience, Task Manager. They all say the same thing: "Your CPU is at 87%." Great. But WHY?
Which process? What background app? Is it Chrome with 47 tabs? Discord? That Windows update you forgot about? I wanted a tool that doesn't just show numbers. I wanted a tool that explains what's actually happening. So I started building PC_Workman.
Rebuild #1: The "Just Make It Work" Disaster - The first version looked like a fever dream of Windows 95. Information spam everywhere. Vertical stacks of metrics requiring endless scrolling. Zero visual hierarchy. Everything screaming for attention. None got it.
But technically? It worked. Numbers updated. Data was accurate. I was proud of it for exactly two weeks. Then I tried using it daily. And I learned the first brutal lesson: "It works" is not the same as "it's good".
Lines of code written: ~15,000. Lines of code deleted: ~15,000. Lesson: Don't fall in love with the first version. Fall in love with solving the problem.
Rebuild #2: The "Now I Know What I'm Doing" Trap - Version two had everything "the right way": Event-driven architecture. Modular plugin system. Clean navigation patterns. Proper code structure. Looked like... a bad mobile app. On desktop. Perfect structure. No soul.
Then I made the most expensive mistake. I spent two full weeks building automatic fan control. Technically impressive. Drag-and-drop curves. Live preview. Beautiful code. Then I tested it properly. One wrong curve setting = potentially fried graphics card.
I deleted everything. Features built and immediately killed: 29. Coffee consumed: about 150 cups. Lesson: Just because YOU CAN build something doesn't mean YOU SHOULD.
The 3 AM moment that changed everything: One specific night stayed with me. 3 in the morning. Laptop fans screaming at 94°C, just from running the dev environment. Just finished a 10-hour warehouse shift. Body destroyed. Brain burned out.
And I stared at over 400 commits in Git history. Most of them saying things like: "fix", "maybe this time", "why doesn't this work", "trying something", "please work".
And sitting there in the blue glow of an overheating laptop, I asked myself the question I'd been avoiding: What am I actually doing? Not in the sense of giving up. In the sense of honestly, truly.
I was building a tool for people who want to understand their computer. But I was building it like someone trying to prove they can code. Those are two completely different things. That night I threw out the entire interface. Again.
Rebuild #3: Finally, the right question - This time I completely changed my approach. Instead of asking "What features can I add?" I asked "What does someone actually NEED to see?"
The answer was embarrassingly simple: CPU and RAM bars side by side. Gradient backgrounds for processes. Click to see details. Real hardware names. Not "8GB RAM" but "7.9 GB Total" pulled from actual system queries.
I deleted 15,000 lines of code during this refactor. Started with 39,000 lines. Ended with 24,000 lines. Almost 40% of everything I wrote - thrown out. And the product got BETTER.
The hardest part wasn't writing new code. It was killing my darlings - removing features I was proud of but users didn't need. Result: 50% smaller UI elements. 200% more information density. Laptop temperature during testing: peaked at 94°C. Laptop survived. Barely.
Then everything fell apart: December 22. Three days before the holidays. The phone rang. The agency. "The trial period didn't work out." A month and a half of work. Done.
I was sitting in a temporary agency apartment in a country that wasn't mine. My family was in Poland. My two dogs were in Poland. I missed them every day. The laptop was literally falling apart. And my project was 70% done.
Logical reaction? Panic. Give up. Focus on finding a new job. What did I actually do? Started rebuild #4.
Rebuild #4: When you have nothing left to protect - Here's what I understood during that rebuild week being unemployed: Constraints weren't obstacles. They were filters.
Dying hardware meant every feature had to justify its RAM footprint. Zero bloated code. Exhausting shifts meant I couldn't waste time on elegant code that didn't solve real problems. Ship or sleep. No middle ground.
Building alone meant every mistake was mine. But every win proved I wasn't wasting time. No team to hide behind. When you have nothing left to protect, you stop protecting. You just build.
What PC_Workman became: Full system health diagnostics and monitoring. Interactive 2D system map with real compatibility checking. Custom fan curves with safety validation. Network analysis broken down by application. Gaming performance tracking with bottleneck detection.
And TIME TRAVEL - that came from pure frustration. How many times have you noticed your computer was slow earlier, but now everything looks fine? Traditional monitors show only the present. PC_Workman shows the past. Click any point on the performance graph. See exactly which processes were running at that moment.
Numbers nobody publishes: 680+ hours of coding. Every evening after warehouse shifts. Every weekend morning. Holidays included. 39,000 → 24,000 lines. 4 complete UX rebuilds. 29 features killed before shipping. 6 different GPU monitoring approaches (5 failed). 340+ cups of coffee. 94°C laptop peak.
The uncomfortable truth about AI: I need to be honest. I woke up late to AI. As an IT tech, I watched AI tools evolve and thought "interesting". I didn't realize they were eating my field while I watched.
But "nearly eaten" is not "completely eaten". I'm catching up. Every night. With Claude as my actual strategic partner. With HCK_GPT integrated directly in PC_Workman for intelligent diagnostics. With the understanding that the future belongs to people working WITH AI, not against it.
The irony isn't lost on me: By day a warehouse worker loading pallets. By night building AI-assisted software. Future and past, living in the same person.
What I actually learned: Not motivation. Motivation was gone by week 2. Not natural talent. I'm average at best. Stubbornness. Refusing to let another project die in the graveyard of "80% done, never shipped".
Showing up after warehouse shifts even when every part of me wanted to sleep. Accepting that progress happens in microscopic, invisible steps - not in dramatic breakthroughs. The difference between abandoned projects and shipped products isn't talent. Not resources. Not ideal conditions. It's showing up when it's no longer fun.
What's next: PC_Workman is coming in a few weeks. Not because I'm fast. Because I didn't quit. New hardware is coming - finally upgrading from a laptop hitting 94°C. Not just for gaming. For building. For learning. For achieving.
My 2026 goal: Take PC_Workman from 70% to production-ready. Completely optimized. Silent in the background. Rock solid. Then: the next projects start. No more juggling ten unfinished ideas. Finish one thing. Then start the next. That's how you really build a portfolio.
For everyone building something alone: If you're building something and it feels slow - that's not failure. That's the process. If you've rewritten the same component three times - you're learning, not wasting time. If you've googled "why doesn't this work" 47 times today - welcome to development.
90% invisible work? Debugging at 2 AM when the fix makes no logical sense but somehow works? Features you build, test, and delete because something's off? That's not imposter syndrome. That's craftsmanship.
One more thing: 2025 taught me resilience. 2026 tests execution. The only real consequence of losing my job? A one-month delay on new laptop hardware. That's it. I'll keep coding on the old one. As long as it doesn't exceed 95°C too often.
If you're looking for someone who ships despite dying hardware, job loss, and 4 complete rebuilds... Someone who learned that constraints aren't obstacles, but filters. That nobody's coming to save you. And that the last wall is closer than it seems. My DMs are open. Let's build something.
HCK
365 days. One question: Did you start or are you still planning?
The year is ending. Did you build something real, or just add another year to "I was planning..."? Here's what happened when I stopped waiting for perfect conditions...
[New Year GIF - 2026 celebration]
For me, 2025 was the year I finally stopped waiting. 5-6 months ago something clicked. Done with "I'll start when I have better hardware". Done with "I'll build it when I have more time". Just: open the laptop after the warehouse shift. Code. Repeat. That decision changed everything.
What I learned this year: You don't need perfect conditions. You need to start anyway. Progress isn't linear. Some nights you build features. Some nights you delete them. But showing up > not showing up. Always.
The difference between people who ship and people who plan? They started on a random Tuesday and didn't stop.
2026 is different. New hardware is coming (finally upgrading from a laptop hitting 94°C during testing). Not just for gaming - though let's not kid ourselves, there'll be some of that! For building. For learning. For achieving. Can't wait to start our Kacper Kielbasa project!
Done with "we should do that sometime". This year we're actually doing it.
My 2026 goal: Take PC_Workman from 70% to production-ready. Completely optimized. Silent in the background. Rock solid. Then: the next projects start. Done juggling ten unfinished ideas. Finish one. Then start the next. That's how you really build a portfolio.
To everyone reading this: If you've been thinking about starting something - start this week. Not January 15, when you "feel ready". Not "after researching more tools". This week. One commit. One sketch. One prototype.
In a year you'll have something real or another year of "I was planning...". Choose real.
What I'm betting on in 2026: Solo developers can build things that matter. Consistency beats motivation. Collaboration amplifies what you can't do alone. And action always beats intention.
2026: The year we stop planning and start shipping. See you on the other side - with products, not just ideas. Happy New Year! Developer | Order Picker | Netherlands. Building 2026, line by line.
HCK
Reality Check
Everyone sees the wins. Nobody sees the grind. Here's what 4.5 months of building PC_Workman actually looked like - 90% invisible work nobody talks about...
[GIF showing development progress]
Social media shows polished screenshots. Clean demos. "Just shipped this feature!" Reality? Messier.
What people see: "Cool project! Must be exciting to build!" Progress updates. New features. Celebrating milestones.
What's actually happening: 6 different approaches to GPU monitoring. 5 completely failed. 2 weeks building automatic fan control. Thrown out - too risky, could fry hardware. Complete UI rebuild because "it works" is not the same as "it's good". 400+ commits that just say "fix" or "maybe this time" or "why doesn't this work".
The truth: 90% of development is invisible work. Debugging at 2 AM when the fix makes no logical sense but somehow works. Features you build, test, and delete because something's off. Rewrites nobody sees because you're too embarrassed to show v1.
It's normal. If you're building something and it feels slow - that's not failure. That's the process. If you've rewritten the same component three times - you're learning, not wasting time. If you've googled "why doesn't this work" 47 times today - welcome to development.
What kept me going: Not motivation (gone by week 2). Not natural talent (average at best). Stubbornness. Refusing to let another project die in the "80% done, never shipped" graveyard. Showing up after warehouse shifts even when I didn't feel like it. Accepting that progress happens in microscopic steps, not breakthrough moments.
PC_Workman stats you don't see in updates: 29 features considered, partially built, then killed (good decisions, painful to make). 15,000 lines of code deleted during refactor (started with 39k, now 24k - leaner is better). 340+ cups of coffee consumed (rough estimate, probably more). 94°C - highest laptop temperature during stress tests (yes, it survived).
If you're building something alone: You're not alone in feeling like it takes forever. You're not alone in questioning if it's good enough. You're not alone in rewriting things that "worked fine" because your standards evolved. That's not imposter syndrome. That's craftsmanship.
The difference between abandoned projects and shipped products? Not talent. Not resources. Not perfect conditions. Showing up when it's no longer fun.
PC_Workman is shipping in a few weeks. Not because I'm fast. Because I didn't quit. That's the only secret.
HCK
December 22. I lost my job in the Netherlands.
One-month trial period through an agency. Didn't work out. Holidays away from family and dogs. But here's what 9 months in the Netherlands and 5 months of coding taught me about resilience...
[Video collage from Netherlands]
One-month trial period through an agency. Didn't work out. It happens. Holidays in an agency apartment, z away from family, z dala od moich psów (tęsknię za nimi every day).
Ale oto czego taught me 9 miesięcy w pięknej Holandii 🇳🇱 i 5 miesięcy intensywnego kodowania:
💛 By day: Picking orders in warehouses.
🖤 By night: Building PC_Workman and my HCK_Labs portfolio.
❕ I learned that nikt nie przyjdzie cię ratować. Zajęło mi za długo, żeby to zrozumieć. Twój rozwój, twoje możliwości, twoja przyszłość - to zależy od ciebie. Tylko od ciebie.
I learned that ostatnią ścianą do sukcesu są ludzie. Brzmi prosto, prawda? Ale co mam na myśli: Każdy projekt, który wcześniej zbudowałem, kończyłem go, publikowałem i... cisza. Zero wyświetleń. Zero reakcji. I rzucałem. Dokładnie tam przy ostatniej ścianie.
Byłem niezaspokojony, bo zatrzymywałem się krok przed przełomem. Teraz wiem: Musisz podejść do tej ściany z różnych stron. Próbować dalej. Iterować. Pojawiać się.
I learned that praktyka to nie tylko ważna rzecz - to wszystko. Dawny ja przewróciłby oczami. "Praktyka? Oczywiste." Ale jest różnica między wiedzą intelektualną a życiem tego. Kodowanie każdej nocy na laptopie osiągającym 95°C, podczas pracy na 10-godzinnych zmianach - to nie inspiracja, to praktyka. Wysyłanie pomimo zerowej początkowej trakcji - to nie talent, to praktyka. Uczenie się kodowania, gdy AI zjadało moją dziedzinę jako technika IT? To też praktyka.
I learned that ograniczenia to nie przeszkody - to filtry. Oddzielają tych, którzy tego chcą, od tych, którzy tego potrzebują. I odmawiam pozwolenia jednej porażce - albo miesięcznemu opóźnieniu, albo umierającemu sprzętowi, albo ciszy w dniu premiery - wykolejić to.
So what's next:
1. Wracam do Polski na Nowy Rok (psy! rodzina! prawdziwe biurko!)
2. Waiting for my desktop setup: two monitors, proper dev environment
3. Decyzja, czy zabrać to z powrotem do NL/DE (logistyka...)
4. New laptop still en route - just delayed a month
5. PC_Workman alpha nadal wychodzi - ograniczenia się zmieniły, misja nie.
Jedyna realna konsekwencja utraty tej pracy? Miesięczne opóźnienie materiałowe laptopa. To wszystko. I będę dalej kodować na starym. Dopóki nie przekracza zbyt często 95°C. 😉
2025 taught me resilience. 2026 przetestuje wykonanie. Do wszystkich stawiających czoła niepewności w tym sezonie: Jesteś silniejszy, niż myślisz. Ta ostatnia ściana jest bliżej, niż się wydaje. Nie przestawaj.
A jeśli szukasz kogoś, kto wysyła pomimo umierającego sprzętu, utraty pracy i cichych premier - kogoś, kto nauczył się, że nikt nie przyjdzie cię ratować, więc lepiej się sam uratuj... Moje DM są otwarte.
Wesołych świąt! Zbudujmy coś w 2026.
HCK
Building PC_Workman on a 2014 Laptop Hitting 90°C
Większość ludzi by zmieniła maszynę. Ja używam tego jako badania rynku. Oto co zostało zbudowane - i o co chcę zapytać społeczność...
[GIF showing changelogs]
Buduję PC_Workman na laptopie z 2014 roku, który osiąga 90°C tylko przy nagrywaniu. Większość ludzi by zmieniła maszynę. Teraz używam tego jako badania rynku.
Co zostało zbudowane:
Twój PC: Pełna diagnostyka i monitoring zdrowia
Your components: 2D system map with compatibility checking
FAN PANEL: Custom fan curves with AI-assisted tuning
Analiza sieci: Śledzenie pasma z podziałem na aplikacje
Analiza gier: Wykrywanie wąskich gardeł wydajności dla poszczególnych gier
What's not here yet: It starts when new hardware arrives in early January. Then I'll be able to test features that old silicon can't handle. Then I'll unlock privacy features.
Do tego czasu: funkcje sprawdzone na dekadowym krzemie. Szczerze: Wychowałem się na MS Afterburner, uwielbiam Experience, i próbowałem wielu narzędzi GPU. Zbudowałem swój pierwszy zestaw około 14 roku życia z Abit NF7-S i przyzwoitym ATI Radeon.
❗ Więc oto czego chcę zapytać społeczność: Co powinno faktycznie zawierać nowoczesne narzędzie do monitorowania i optymalizacji PC? Co cię frustruje? Czego brakuje? Za co byś zapłacił?
Aktualny postęp: v1.0.1 - v1.6.5 builda Alpha na żywo (jako 0.6 PMG). Wszystkie podstawowe funkcje działają płynnie. Usługa w tle całkowicie zoptymalizowana. HCK_GPT zintegrowany perfekcyjnie. Gotowy do codziennego użycia.
To nie chodzi o sprzedawanie jakiegoś arbitralnego deadline'u. Chodzi o wysłanie czegoś prawdziwego. PC_Workman się dzieje. Z twoim feedbackiem, dzieje się lepiej. Rzuć swoimi myślami. Kształtuj to, co wychodzi.
HCK
Co powinno mieć oprogramowanie do optymalizacji PC?
I need your honest, quick opinion. What should PC optimization software have that MSI Afterburner, GeForce Experience, and Advanced SystemCare don't?
[4 screenshots from PC_Workman]
Potrzebuję twojej szczerej opinii. Rozwijam PC_Workman, narzędzie do monitorowania i optymalizacji systemu. Jestem na etapie, gdzie każda sugestia może bezpośrednio wpłynąć na finalną wersję.
Trochę o me najpierw: Koduję nocą. W dzień pracuję jako kompletator zamówień w magazynie w Holandii. Jestem imigrantem, który przeniósł się tu w poszukiwaniu lepszych możliwości. Po 8-10 godzinnych zmianach wracam do domu, otwieram laptopa i pracuję nad tym, na czym naprawdę mi zależy.
PC_Workman zaczął się jako prosty skrypt do monitorowania CPU. Teraz zawiera:
- Monitoring w czasie rzeczywistym (CPU, GPU, RAM, temperatury)
- Advanced performance graphs and stats
- System optimization toolkit (16 different tools)
- AI-assisted insights (in development)
- Nowoczesny, responsywny interfejs
Jestem coraz bardziej dumny z tego, czym się stało. Ale wiem, że może być lepsze. Z twoim wkładem.
Moje pytania do społeczności: Jeśli używasz MSI Afterburner, GeForce Experience, IObit Advanced SystemCare, HWinfo, REALIX Realix lub podobnych narzędzi:
1. Co cię w nich frustruje? - Przytłaczający UI? Za dużo reklam? Brakujące funkcje?
2. What functionality is missing? - Better automation? System integration? Specific monitoring capabilities?
3. Co byś zmienił, gdybyś mógł? - Projekt interfejsu? Łatwość użycia? Konkretne narzędzia?
4. Za co byś zapłacił (i co powinno pozostać darmowe)?
Dlaczego to ma znaczenie: Nie jestem korporacją. Nie mam zespołu deweloperskiego ani budżetu marketingowego. Jestem jedną osobą z laptopem, determinacją i prawdziwą pasją do budowania użytecznego oprogramowania. Twój feedback staje się moją mapą drogową. Każdy komentarz, każda sugestia się liczy. Chcę zbudować coś, co naprawdę pomaga ludziom, nie tylko kolejną zasobożerną aplikację.
Prośba: Jeśli kiedykolwiek używałeś narzędzi do optymalizacji PC, masz opinie o istniejących rozwiązaniach, lub wiesz czego brakuje w tej przestrzeni, proszę skomentuj. Nawet jedno zdanie pomaga. Każda odpowiedź czyni finalny produkt lepszym. Jeśli znasz kogoś, kto mógłby mieć cenny wkład, proszę udostępnij ten post. Razem możemy zbudować coś naprawdę użytecznego.
Marcin
Developer | Order Picker | Holandia
PC_Workman - Your PC Masterdude!
HCK
I Did Something… Kind of Crazy!
I participated in tests of a large project comparing AI models. I pomyślałem: "zrobię swoją wersję. Od zera. Po wersji HCK_Labs!" Zero theory - pure practice...
[LinkedIn article link]
I participated in tests of a large project that compared different AI pod kątem wydajności i jakości kodu. I w pewnym momencie pomyślałem: "To co… zrobię swoją wersję. Od zera. Po wersji HCK_Labs!"
No i poleciałem.
🔧 I created complete structures .json do telemetrii systemowej, przetestowane na 10 urządzeniach, przerobiłem to przez 6–7 różnych agentów AI, i złożyłem z tego pełny raport techniczny, który właśnie wrzuciłem w formie artykułu.
Zero theory - pure practice: processes, sampling, GPU, I/O, telemetry, retry-backoff… Everything that AI can't trick with a simple prompt.
If you want to see, jak naprawdę wypadają dzisiejsze modele w zadaniu, które wymaga prawdziwej inżynierii. I invite you to the article!
HCK
A Few Hours. One Idea. Everything Changed.
My laptop CPU... 90°C 😅 What if PC_Workman had two different faces? Jedna minimalistyczna. Druga... epic. Pełna kontrola. Zero compromises "Tryb rozszerzonego widoku"...
[2 screenshots of PC_Workman]
I was working yesterday on an old laptop with a cracked screen. Pisałem kod. Normalny dzień. Potem --- completely randomly, an idea hit me:
What if PC_Workman had two different faces? Jedna minimalistyczna (do pracy w tle). Druga... epic. Pełna kontrola. Wszystkie informacje na jednym ekranie. Zero compromises "Tryb rozszerzonego widoku".
A few hours later I look at what came out i myślę: to nie jest to samo narzędzie, które pisałem rano.
What happened? Extended main mode. Centralized panel z motherboard models. Zaawansowana fan control with temperature curves i RPM monitoring. Component health checking. Autostart manager. Real-time monitoring with charts, które actually do the job.
But it's not about features. Chodzi o coś zupełnie innego. Over the past months we have been building PC_Workman publicznie. Every day. Z każdym pomysłem, with every iteration. I coś changed - nie in the code, but in me.
I learned that sometimes the best solutions nie come from planning. They come from experimentation. Że design is not creating something perfect. To tworzenie something you really want to use every day. Że narzędzie, które truly understands your system. That something worth building, even on a decade-old laptop.
For me this is another major milestone. But for you? It is a moment where PC monitoring tool becomes something more. Thanks for watching this journey!
HCK
Widgety tekstowe cię okłamują.
Wyglądają prosto. Wyglądają niezawodnie. Dopóki nie spróbujesz zbudować panelu na żywo. I learned this yesterday evening on my own skin during a rebuild PC_Workman...
[GIF from program]
Widgety tekstowe cię okłamują. Wyglądają prosto. Wyglądają niezawodnie. Dopóki nie spróbujesz zbudować z nich panelu na żywo.
I learned this yesterday evening on my own skin during a rebuild PC_Workman. Widget Text w Tkinter jest ok do… no właśnie, tekstu. Ale uderz w niego ponad 100 procesami odświeżającymi się co 0,5s i nagle dostajesz:
• UI lag that gets worse every minute
• Scroll position teleporting to Narnia
• Memory leaks like a broken faucet
• Random ghost artifacts
• Czystą wściekłość użytkownika 😅
My old approach:
self.process_text.delete('1.0', tk.END)
self.process_text.insert('1.0', new_data)
Technicznie działało. Tylko nie dla czegokolwiek rzeczywistego. Więc to wyrzuciłem.
Nowa architektura? Dynamiczny układ oparty na ramkach. Czysty. Przewidywalny. Zero dramatu.
for widget in self.process_widgets:
widget.destroy()
self.process_widgets = []
for proc in processes:
row = tk.Frame(...)
self.process_widgets.append(row)
Ten sam rezultat dla użytkownika. Totalnie inny wynik dla wydajności. Bez laga. Bez wycieków. Po prostu płynne aktualizacje co 0,5s - jak zawsze powinno być.
PC_Workman v1.5.0 - kluczowe ulepszenia:
Przeprojektowanie panelu:
• Architektura Text → Frame
• Paski CPU i RAM obok siebie (bez przewijania)
• Gradient rows for TOP 5
• Kliknij-aby-pokazać szczegóły procesu (hover = zawodny)
New "Your PC" page:
• Real hardware detection (platform + psutil)
• Symulacja temperatury: temp = base + (load × factor)
• Status kodowany kolorami (🟢 → 🟡 → 🟠 → 🔴)
• 50% smaller panels, 2× more info
Technical wins:
• 0.5s refresh with zero UI freeze
• Safe widget destruction (no RAM buildup)
• Cache'owane info o sprzęcie dla natychmiastowego ładowania
• Gradient rendering without flicker
Buduję to publicznie. Uczę się publicznie. Jeśli jedna osoba uniknie moich błędów, to już wygrana. Jaki był twój moment "zły widget do zadania"?
v.1.5.0 - nie jest jeszcze publicznie wypuszczona.
HCK
Security: Are We Overcomplicating It?
19:10. Krótka przerwa, zanim wrócę. Ciągle dodajemy warstwy do bezpieczeństwa. Więcej sprawdzeń. Więcej kroków. Ale rzecz w tym - większość porażek nie wynika z tego, że technologia nie była wystarczająco dobra...
[No image]
19:10. Quick break before I get back. Been thinking about something lately.
Ciągle dodajemy warstwy do bezpieczeństwa. Więcej sprawdzeń. Więcej kroków. Więcej "zweryfikuj, że to naprawdę ty". I jasne, działa. Technicznie.
Ale rzecz w tym - większość porażek bezpieczeństwa, które widziałem, nie wynika z tego, że technologia nie była wystarczająco dobra. Wynika z tego, że ludzie jej nie używali. Słabe hasła. Pominięcie konfiguracji 2FA. Kliknięcie w ten jeden podejrzany link.
The technology is already there. The problem is getting people to actually use it.
Może prawdziwym przełomem nie jest kolejna metoda uwierzytelniania. To uczynienie bezpieczeństwa tak płynnym, że po prostu... dzieje się. Bez myślenia.
Ok, break's over. Back to work.
Quick question - do you think we're overcomplicating security, or is that extra friction actually necessary?
HCK
Ekran telefonu: martwy. Laptop: i5-5200U z 2015 roku.
PC_Workman: shipped anyway. Cracked screen. 4-core CPU from a decade ago. Yet I'm building real-time system monitoring with AI that detects performance issues before you...
[Photo with broken phone. PC_Workman code in background]
Ekran telefonu: martwy. Laptop: i5-5200U z 2015 roku. PC_Workman: wypuszczony mimo wszystko.
Cracked screen. 4-core CPU from a decade ago. VS Code barely breathing. Yet I'm building real-time system monitoring with AI that detects performance issues before you.
3 tygodnie do wypłaty. Potem upgrade sprzętu. Ale wysyłka nie czeka na idealne warunki.
Building publicly.
Building in the Netherlands.
Building between work shifts.
Building despite everything.
PC_Workman - because even broken hardware can create tools that optimize other systems.
HCK
More stories coming soon...
The journey continues. Stay tuned for more updates from HCK_Labs.
[Future content]
GitHub - Code speaks louder
Open source commits, releases, and technical updates
HCK
Wydanie v2.0.0 - System Projektowania Geometrycznego
Główna przebudowa z profesjonalnymi kształtami geometrycznymi w CSS...
[Placeholder obrazu]
Główna przebudowa z profesjonalnymi kształtami geometrycznymi w CSS, ulepszone znaczniki Schema.org i optymalizacje wydajności. -90KB z eliminacji czcionek emoji!
Każdy detal się liczy. Każdy bajt ma znaczenie.
HCK
Kamień milowy - 100 Gwiazdek!
Osiągnąłem 100 gwiazdek GitHub dla PC_Workman...
[Placeholder obrazu]
Osiągnąłem 100 gwiazdek GitHub dla PC_Workman! Co było potrzebne, żeby zostać zauważonym bez budżetu marketingowego. Autentyczność > Reklamy.
Medium - Deep Insights
Honest stories from product development
I built publicly for 5 months. Nobody was watching. December 22. I got fired.
A personal story about building PC_Workman on a dying 2014 laptop, losing my job 3 days before the holidays, and why constraints might be the best teachers you'll ever have.
There's a moment in every project when you realize you built the wrong thing.
For me, that moment came three times. Actually four, if I'm being honest.
Let me back up.
The Setup Nobody Romanticizes
Nine months ago, I moved from Poland to the Netherlands.
Not for a tech job. For a warehouse position - order picking, to be specific. The kind of work where you walk 15-20 kilometers a day between shelves, scan barcodes, and load pallets.
By day: warehouse worker
By night: building software
The gap between those two realities is where this story lives.
I had this idea for an HCK_Labs project: PC_Workman.
A system monitoring tool. Think of it as the love child of MSI Afterburner, HWMonitor, and GeForce Experience - but designed by someone who actually uses these tools every day and gets frustrated by what they DON'T do.
The concept was simple: don't just show me my CPU is at 87%. Tell me WHY.
Show me that Chrome is eating 43%, Discord is taking 22%, and there's a Windows update running in the background I forgot about. The difference between monitoring and understanding.
Simple concept. Brutal execution.
Rebuild #1: The "Just Make It Work" Phase
My first version looked like something from Windows 95. I'm not exaggerating.
• Vertical stacks of metrics requiring scrolling
• Emoji spam everywhere (I thought it looked "cool" - made process names unreadable)
• Text widgets that couldn't update smoothly
• Zero visual hierarchy
• No way to identify what's actually wrong with your system
But it worked. Technically.
Numbers updated. Data was accurate. You could see CPU temperature.
I was proud of it for about two weeks.
Then I actually tried using it every day and realized: working ≠ good. There's a massive gap between "code works" and "this is something I'd actually want on my screen".
📊 Lines of code written: ~15,000
🗑️ Lines of code deleted: ~15,000
💡 Lesson: Don't fall in love with the first version. Fall in love with solving the problem.
Rebuild #2: The "Now With Structure" Phase
Okay, I thought. Now I know what I'm doing.
Version two had proper architecture. Event-driven updates. A modular plugin system. Cleaner UI with actual navigation. Early flow patterns that made sense.
It looked like... a bad mobile app. On desktop.
The structure was there, but the soul wasn't. I got so caught up in "doing it right" that I forgot why I was building it in the first place.
Two weeks later, I killed the feature I'd spent all that time on: automatic fan control.
It was technically impressive. It was also dangerous - one bad curve and you can fry your hardware. The kind of thing that sounds good on a feature list and terrible in a support ticket.
⚙️ Features built and immediately discarded: 29
☕ Coffee consumed: somewhere around 150 cups
💡 Lesson: Just because you can build something doesn't mean you should.
The Night That Changed Everything
There's a specific night I remember vividly.
It was around 3 AM. My laptop was hitting 94°C just from running the dev environment. Fans screaming. I'd just finished a 10-hour warehouse shift. My body was exhausted, my brain was fried, and I was staring at 400+ commits that said things like "fix" or "maybe this time" or "why isn't this working".
And I thought: what am I doing?
Not in a giving-up sense. In a real, honest assessment sense.
I was building a tool for people who want to understand their PC. But I was building it like someone trying to prove they can code. Those are two completely different things.
That night I threw out the entire UI. Again.
Rebuild #3: The "Actually Useful" Phase
Third time's the charm, right?
Version three had a completely different philosophy. Instead of asking "what features can I add?", I asked "what does someone actually NEED to see?"
The answer was embarrassingly simple:
✅ CPU and RAM bars side by side. No scrolling. One glance = complete picture.
✅ Gradient backgrounds for processes. Top consumer? Darkest shade. Top 5? Lighter shades. Instant visual hierarchy without reading numbers.
✅ Click to investigate. See a suspicious process? Click. Instant details.
✅ Real hardware names. Not "8GB RAM" but "7.9 GB Total" from actual system queries.
I deleted 15,000 lines of code during this refactor.
Started at 39,000, ended at 24,000. Leaner is better.
The hardest part wasn't the code. It was killing my darlings - removing features I was proud of but users didn't need.
📊 Result: 50% smaller UI elements, 200% more information density
🔥 Laptop temperature during testing: peaked at 94°C. Survived.
Then I Lost My Job
December 22. Three days before the holidays.
A month and a half trial period through an agency. It didn't work out. These things happen.
I was sitting in an agency apartment, away from family, away from my dogs (missed them every day), with a laptop literally falling apart and a project that was 70% done.
The logical reaction? Panic. Give up. Focus on job hunting.
What I actually did? Started rebuild #4.
Rebuild #4: When You Have Nothing Left to Lose
You might think I'm crazy. Maybe I am.
But here's what I learned during this unemployed-rebuilding phase:
Constraints weren't obstacles. They were filters.
🔧 Dying hardware = every feature had to justify its RAM footprint. Zero bloat.
⏱️ Building after exhausting shifts = I couldn't afford to waste time on elegant code that doesn't solve real problems.
👤 Building alone = every mistake was mine, every win proved I wasn't wasting time. No team to hide behind.
Version four is what PC_Workman became:
🖥️ YOUR PC: Full diagnostics and health monitoring
🗺️ YOUR COMPONENTS: 2D system map with compatibility checking
🌡️ FAN DASHBOARD: Custom fan curves with AI-assisted tuning
📡 NETWORK ANALYTICS: Bandwidth tracking with per-app breakdown
🎮 GAMING ANALYTICS: Per-game performance bottleneck detection
⏰ TIME TRAVEL: Click any point on the performance graph, see exactly what was running at that moment
That last feature - time travel for system monitoring - came directly from my own frustration.
How many times have you noticed your PC was slow earlier, but now everything looks fine? You'll never know what caused it, because traditional monitors only show the present. PC_Workman shows the past.
The Numbers Nobody Posts on LinkedIn
Let me be honest about what building this actually looked like:
⏰ 680+ hours of coding. Every evening after warehouse shifts. Every weekend morning. Holidays included.
📝 39,000 → 24,000 lines. Not just adding. Mostly cutting. The best code is code you don't write.
🔄 4 complete UI rebuilds. First looked like Windows 95. Second like a bad mobile app. Third made sense. Fourth shipped.
🗑️ 29 features killed before shipping. The hardest part wasn't building features. It was saying no to them.
🎮 6 different approaches to GPU monitoring. 5 completely failed. The sixth works on NVIDIA, AMD, and Intel.
☕ 340+ cups of coffee. Rough estimates. Probably more.
🔥 94°C — highest laptop temperature during stress tests. Laptop survived. Barely.
What I Actually Learned
Not motivation. That disappeared in week 2.
Not natural talent. I'm mediocre at best.
Persistence.
Refusing to let another project die in the graveyard of "80% done, never finished".
Showing up after warehouse shifts even when every part of me wanted to sleep.
Accepting that progress happens in microscopic steps, not dramatic breakthroughs.
The difference between abandoned projects and shipped products isn't talent. It's not resources. It's not perfect conditions.
It's showing up when it stops being fun.
The AI Section (Because Someone Will Ask)
Here's an uncomfortable truth: I woke up late to AI.
As an IT technician, I watched AI tools evolve and thought "interesting". I didn't realize they were eating my field while I watched.
But "almost" doesn't mean "completely".
I'm catching up. Every night.
With Claude as my strategic partner (yes, literally - we've spent hundreds of hours together on this project).
With HCK_GPT integrated into PC_Workman for intelligent diagnostics.
With the understanding that the future belongs to people working WITH AI, not against it.
The irony doesn't escape me: I was building an AI-powered tool while working as an order picker. The future and the past, living in the same person.
What's Next
PC_Workman launches in a few weeks.
Not because I'm fast. Because I didn't quit.
New hardware is coming (finally, an upgrade from the laptop hitting 94°C during tests). Not just for gaming - though let's be honest, some of that will happen. For building. For learning. For shipping.
My 2026 goal: Take PC_Workman from 70% to production-ready. Fully optimized. Silent in the background. Rock solid.
Then: the next projects begin. I'm already planning a game with my friend Kacper.
Done with juggling ten half-finished ideas. Finish one. Then start the next. That's actually how you build a portfolio.
For Everyone Building Something Alone
If you're building something and it feels slow - it's not failure. It's process.
If you've rewritten the same component three times - you're learning, not wasting time.
If you're googling "why isn't this working" for the 47th time today - welcome to development.
90% invisible work? That's where it all happens.
Debugging at 2 AM when the fix makes no logical sense but somehow works.
Features you build, test, and delete because something is off.
Rewrites nobody sees because you're ashamed to show version 1.
It's not imposter syndrome. It's craftsmanship.
One More Thing
2025 taught me resilience.
2026 will test execution.
The only real consequence of losing my job? A one-month material delay for a laptop. That's it.
I'll keep coding on the old one. As long as it doesn't hit 95°C too often.
If you're looking for someone who ships despite dying hardware, job loss, and 4 complete rebuilds - someone who learned that constraints aren't obstacles but filters, that nobody is coming to save you, and that the finish line is closer than it feels...
Let's build something.
X (Twitter) - Szybkie aktualizacje i przemyślenia
Budowanie publicznie w czasie rzeczywistym
5 miesięcy budowania publicznie. 680 godzin. 12 obserwujących. Potem me zwolniono.
Historia o tym, jak budowałem PC_Workman na umierającym laptopie, traciłem pracę 3 dni przed świętami i dlaczego ograniczenia to nie przeszkody - to filtry. Wątek 🧵
📌 WPIS 1/9
5 miesięcy budowania publicznie.
Moje statystyki:
💻 680 godzin kodowania
🔄 4 kompletne przebudowy
📝 39 000 linii napisanych
🗑️ 15 000 linii usuniętych
👀 12 osób obserwujących
Potem me zwolniono December 22.
Cool. Cool cool cool.
WPIS 2/9
Setup, którego nikt nie dodaje do bio na LinkedIn:
📦 Za dnia: kompletacja zamówień w magazynie w Holandii
(15-20km chodzenia, skanowanie kodów, ładowanie palet)
💻 Nocą: budowanie na laptopie, który masowo osiąga 94°C
Laptop przeżył. Ledwo.
Moje plecy? Wciąż się regenerują.
WPIS 3/9
Pierwsza wersja wyglądała jak Windows 95 w ataku paniki.
• Za dużo spamu wszędzie
• Przewijanie, żeby zobaczyć użycie RAM
• Zero hierarchii wizualnej
• Commity mówiące "fix" i "czemu to nie działa"
Byłem z tego dumny dokładnie 2 tygodnie.
Potem tego użyłem.
WPIS 4/9
Przebudowa #2: "Teraz wiem co robię"
Budowałem automatyczną kontrolę wentylatorów przez 2 tygodnie.
Przetestowałem.
Zrozumiałem: jedna zła krzywa = spalona karta graficzna.
I deleted everything.
✂️ Funkcji zabitych przed wysyłką: 29
💀 Śmierci ego: też 29
WPIS 5/9
3 w nocy. Laptop wyje. Właśnie skończyłem 10-godzinną zmianę.
Gapiłem się na 400+ commitów.
Większość z nich: "może tym razem"
I pomyślałem: czy buduję coś użytecznego?
Czy tylko udowadniam, że potrafię pisać kod?
Różne pytania.
Bardzo różne produkty.
WPIS 6/9
December 22.
Agencja: "Okres próbny się nie udał."
Ja: "Spoko, 3 dni przed świętami, jestem w innym kraju, moje psy są w Polsce, a laptop umiera."
Logiczna odpowiedź: panika.
Co zrobiłem: zacząłem przebudowę #4.
Speedrun bezrobocia any%
WPIS 7/9
Czego taught me bycie spłukanym i zwolnionym:
Ograniczenia to nie przeszkody. To filtry.
🔧 Umierający sprzęt = każda funkcja musi uzasadnić swój RAM
⏱️ Brak czasu = zero eleganckiego kodu, który nic nie rozwiązuje
👤 Brak teamu = nikt do obwiniania oprócz siebie
Okazuje się, że ograniczenia budują lepsze produkty.
WPIS 8/9
Niewygodna prawda:
Obudziłem się późno na AI.
Jako technik IT obserwowałem jak ewoluuje, myśląc "ciekawe".
Nie zauważyłem, że me zjada.
Teraz nadganiam. Każdej nocy.
Z Claude jako prawdziwym partnerem (setki godzin razem).
Ironia: pracownik magazynu budujący narzędzia AI.
✅ WPIS 9/9 - KONIEC
PC_Workman wychodzi za kilka tygodni.
Nie dlatego, że jestem szybki.
Dlatego, że nie rzuciłem, gdy przestało być fajnie.
📖 Pełna historia (4 przebudowy, laptop 94°C, zwolnienie):
medium.com/@firmuga.marcin.s
Jeśli budujesz sam i wydaje ci się, że to idzie wolno - to nie porażka.
To po prostu wtorek.
December 22. Straciłem pracę. Ale oto czego me to nauczyło.
One-month trial period in the Netherlands. Didn't work out. Ale 9 miesięcy za granicą + 5 miesięcy kodowania 40k+ linii taught me czegoś cennego.
📌 WPIS 1/6
December 22. Straciłem pracę.
One-month trial period in the Netherlands. Didn't work out.
Ale oto czego taught me 9 miesięcy za granicą + 5 miesięcy kodowania 40k+ linii.
WPIS 2/6
📦 Za dnia: Kompletacja zamówień w magazynach. (było)
💻 Nocą: Budowanie PC_Workman.
I learned that nikt nie przyjdzie cię uratować.
Twój rozwój. Twoje możliwości. To jest NA TOBIE.
Zajęło mi zdecydowanie za długo, żeby to zrozumieć.
WPIS 3/6
Ostatnia ściana do sukcesu to ludzie.
Każdy projekt, który wysłałem wcześniej? Cisza.
I rezygnowałem. Tam właśnie. Krok przed przełomem.
Teraz wiem: podejdź z różnych kątów. Iteruj dalej. Pokazuj się dalej.
WPIS 4/6
Praktyka to nie tylko ważne - to WSZYSTKO.
💻 Kodowanie na laptopie 95°C + 10h zmiany? Praktyka.
📦 Wysyłanie pomimo zerowej trakcji? Praktyka.
🤖 Uczenie się kodu, gdy AI zjadało moją karierę IT? Praktyka.
WPIS 5/6
Co dalej:
🇵🇱 Polska na Nowy Rok (psy! rodzina! prawdziwe biurko!)
🖥️ Desktop: dwa monitory, porządne środowisko dev
💻 Nowy laptop opóźniony o miesiąc (misja bez zmian)
🚀 PC_Workman alpha dalej się rozwija
Jedna utrata pracy, miesiąc opóźnienia. To wszystko.
✅ WPIS 6/6 - KONIEC
2025 taught me resilience.
2026 przetestuje wykonanie.
Szukasz kogoś, kto dostarcza pomimo umierającego sprzętu, utraty pracy, niepewności?
Dzięki za przeczytanie moich myśli ;)
P.S. Pełna historia z wideo na moim LinkedIn (piszę tam zdecydowanie za dużo)
Europa reguluje AI. Ameryka buduje AI. Chiny wdrażają AI.
Kto wygra w 2030? O tym, dlaczego Europa ma 1 firmę AI na 450 milionów ludzi, a USA ma 14.
📌 WPIS 1/5
Europa reguluje AI.
Ameryka buduje AI.
Chiny wdrażają AI.
Kto wygra w 2030?
WPIS 2/5
🇺🇸 USA: 14 firm
🇨🇳 Chiny: 5 firm
🇪🇺 UE: 1 firma (może)
450 milionów Europejczyków.
1 globalnie konkurencyjna firma AI.
Dlaczego?
WPIS 3/5
🇺🇸 Startup w USA:
• Mondayek: Pomysł
• Piątek: MVP
• Następny tydzień: Finansowanie
• Miesiąc 1: Skalowanie
🇪🇺 Startup w UE:
• Mondayek: Pomysł
• Tydzień 1: Przegląd prawny
• Tydzień 2: Audit GDPR
• Miesiąc 2: Zgodność z AI Act
• Miesiąc 6: "Może launch?"
Który wygrywa rynek?
WPIS 4/5
Zanim startupy UE wypuszczą "etycznie perfekcyjne" AI:
Firmy z USA już mają:
✅ 10M użytkowników
✅ Efekty sieciowe zablokowane
✅ Dominację rynkową
✅ Stać je na zgodność, której startupy UE nie udźwigną
Gra skończona zanim się zaczęła.
✅ WPIS 5/5 - KONIEC
Opcje Europy:
A) Dalej regulować
→ Moralne wyżyny + technologiczna nieistotność
B) Poluzować zasady
→ Innowacje + ryzyko
C) Masowe publiczne finansowanie
→ Europejscy championsi AI (drogie, mało prawdopodobne)
Wybierz swoją truciznę.
Nie ma dobrych opcji.
Większość przełomów UX nie wydarzyła się przy biurku.
Wydarzyły się na toalecie. I później na spacerze. Jakoś to tam UI w końcu kliknęło - minimal vs expanded mode.
📌 WPIS 1/4
Większość przełomów UX w PC_Workman nie wydarzyła się przy moim biurku.
Wydarzyły się…
🚽 na toalecie
🚶 i później na spacerze
Jakoś to tam UI w końcu kliknęło.
WPIS 2/4
Przełączyłem PC_Workman na czysty Tryb Minimalny
i zbudowałem PEŁNOFUNKCJONALNY Tryb Rozszerzony obok niego.
Ta sama apka.
Dwa sposoby myślenia.
I tak. Expanded mode absolutnie miażdży.
WPIS 3/4
Expanded View teraz pokrywa ~70% planowanych funkcji:
🖥️ Your PC → płyta główna, info o sprzęcie, zdrowie PC, optymalizacja startupu
🗺️ Mapa 2D wszystkich komponentów (tak, PSU też)
⚙️ Optymalizacja → 18 narzędzi (niektóre już zautomatyzowane przy starcie)
✅ WPIS 4/4 - KONIEC
Zabawne:
W momencie gdy przestałem forsować UX przy klawiaturze,
samo się rozwiązało.
Expanded View Mode po prostu teraz działa.
Czasem najlepsze IDE to spacer na zewnątrz.
Zrobiłem screenshot podczas pracy na PC_Workman. Temperatura CPU: 90°C
PC_Workman: monitor systemu + asystent AI do diagnostyki
v1.3.3 właśnie wyszła z:
📊 Real-time tracking CPU/RAM/GPU
🎨 Lepsze UI (w końcu nie wygląda jak 2010)
🤖 Fundament dla funkcji hck_GPT
Wciąż wczesna faza, ale działa.
Opera idealnie. Chrome bez styli. Cache pokazywał nieistniejące pliki.
7h nocnego refactoru HCK_Labs. Z chaosu w porządek - modularyzacja, SASS, Node.js pipeline.
📌 WPIS 1/3
Opera: działa idealnie ✅
Chrome/Edge: zero styli 💀
Dlaczego?
Cache wyświetlał pliki, których już nie było 😂
📂 1300 linii JS + 1000 CSS → moduły
🗑️ legacy.css → emerytura
Następny krok:
SASS + Node.js
Lekcja: zawsze czyść cache. Zawsze.
WPIS 2/3
BEFORE:
→ main.js: 1300 linii
→ main.css: 1000 linii
→ Cache pokazuje pliki, które nie istnieją 💀
AFTER:
→ Moduły ✅
→ legacy.css → śmietnik ✅
→ SASS/Node.js incoming ✅
7h nocnego codingu = stabilny HCK_Labs
✅ WPIS 3/3 - KONIEC
"Szybko poprawię jedną rzecz i idę spać"
...7h później przepisałem pół frameworka 😅
Problem?
Cache trzymał pliki, których już nie było
• Opera ✅
• Chrome/Edge 💀
Fix:
⚙️ Modularyzacja JS/CSS
🎨 SASS incoming
🔧 Node.js pipeline
HCK_Labs → z chaosu w porządek 🔧
Hej wszyscy! (NIKT TEGO NIE WIDZI)
I know you don't know who I am - and you probably won't, because you'll scroll past in a second. Historia zwykłego gościa z Polski, który buduje coś większego, nawet jeśli algorytmy udają, że nie istnieje.
📌 WPIS 1/4
Hej wszyscy! (NIKT TEGO NIE WIDZI).
I know you don't know who I am - and you probably won't, because you'll scroll past in a second.
Całkowicie fair. Chrońcie swój czas.
Moja powoli rosnąca "społeczność" na LinkedIn robi dokładnie to samo xD.
Brutalne początki. Tak, obudziłem się za późno.
WPIS 2/4
Ale HEJKA!
Jestem Marcin z Polski - niestety po prostu zwykły gość z IT, który chciał nim być długo zanim w ogóle usłyszał o AI…
które potem postanowiło nas wszystkich zjeść ;P.
Teraz?
Buduję swój mały HCK_Labs...
WPIS 3/4
...projekt rosnący nocami, podczas gdy wszyscy inni scrollują Netflixa.
Studiuję AI, inżynierię, cyberbezpieczeństwo i wszystkie te rzeczy, które brzmią fajniej niż wyglądają o 3 w nocy.
I co najważniejsze… mam marzenia.
Nic szalonego: tworzyć, rosnąć, być konsekwentnym przez miesiące, i...
✅ WPIS 4/4 - KONIEC
...i któregoś dnia pracować nad prawdziwymi przełomami technologicznymi.
Jeśli zostaniesz tu na chwilę, obiecuję tylko jedno: szczerość.
❌ Żadnego fejkowego "growth hackingu"
❌ Żadnej korporacyjnej persony
Po prostu gość z Polski gonący coś większego - nawet jeśli algorytmy udają, że nie istnieję. ;)
Reddit - Co napisałem
Dyskusje społecznościowe i feedback
680 godzin na moim pierwszym "prawdziwym" projekcie. Wszystko, co zepsułem i co w końcu zadziałało.
Właśnie... zakończyłem 5 miesięcy budowania czegoś od zera. Bez dyplomu informatycznego, samouczek, nauczyłem się masowo więcej z błędów niż z jakiegokolwiek tutorialu. Pomyślałem, że podzielę się porażkami dla każdego, kto zaczyna.
Mój setup:
• Praca: magazyn w Holandii (nie tech)
• Kodowanie: noce/weekendy
• Sprzęt: laptop z 2014, regularnie osiąga 94°C
• Doświadczenie: samouczek, masowe googlowanie
Projekt:
Narzędzie do monitoringu PC, które faktycznie mówi ci DLACZEGO twój CPU umiera, a nie tylko że umiera.
BŁĄD #1: Budowanie tego co fajne vs tego co użyteczne
Pierwsza wersja miała WSZYSTKO. Emoji jako wskaźniki statusu (wyglądało okropnie). Animacje. 15+ paneli. Przewijanie wszędzie.
Byłem z tego taki dumny.
Potem używałem tego do rzeczywistego codziennego monitoringu i chciałem to wyrzucić przez okno. Za zagracone. Za mylące. Wyglądało "imponująco" ale było denerwujące w użyciu.
Lekcja: używaj swoich rzeczy. Codziennie. Szybko znajdziesz problemy.
BŁĄD #2: Monolityczne pliki
Zacząłem z w zasadzie wszystkim w 2 ogromnych plikach. "Działa, nieważne."
Działało dopóki nie przestało.
Spędziłem 4 dni tylko rozdzielając rzeczy na odpowiednie moduły. Powinienem był to zrobić od dnia 1, ale hej, nauczyłem się trudną drogą.
BŁĄD #3: Demon cache
To zabiło masę godzin.
Debuguję "zepsuty" kod. Nic nie działa. Panika.
Okazuje się, że przeglądarka pokazywała pliki z cache, które dosłownie już nie istniały na dysku.
• Opera: działa idealnie ✅
• Chrome: chaos 💀
Ten sam kod.
Czyść cache. Przed debugowaniem CZEGOKOLWIEK. Zaoszczędziłoby mi to masy czasu.
BŁĄD #4: Niewystarczające usuwanie
Start: 39 000 linii
Koniec: 24 000 linii
Usunąłem prawie 40% wszystkiego co napisałem.
I projekt się POPRAWIŁ. Brzmi sprzecznie z intuicją, ale usuwanie rzeczy poprawiło go bardziej niż dodawanie rzeczy.
CO FAKTYCZNIE ZADZIAŁAŁO:
✅ Zapytaj "co użytkownik widzi jako pierwsze" i dopracuj to
✅ Nie buduj funkcji. Buduj podstawowe doświadczenie
✅ Jedna rzecz działająca świetnie > dziesięć rzeczy działających "w porządku"
✅ Przebuduj gdy jest kiepsko. Zrobiłem to 4 razy. Bez żalu
✅ Ograniczenia pomagają. Mój wolny laptop zmuszał me do optymalizacji wszystkiego
📊 Losowe statystyki:
• 680 godzin łącznie
• 4 kompletne przebudowy UI
• 29 funkcji zbudowanych i zabitych
• Masa zakładek Stack Overflow otwartych cały czas
Dla każdego, kto zaczyna: twoja pierwsza wersja BĘDZIE zła. To normalne.
Faktyczna umiejętność to rozpoznanie, że jest zła i naprawienie tego, nie udawanie, że jest w porządku.
Straciłem pracę tuż przed świętami. Czego nauczyła me porażka i dlaczego jestem naprawdę optymistą co do 2026.
Więc 22 grudnia straciłem pracę. To był miesięczny okres próbny w Holandii, który po prostu nie wyszedł, i szczerze mówiąc, timing był... niezbyt dobry. Tuż przed świętami i tak dalej.
Jestem Polakiem, mieszkam za granicą, a moje psy są w Polsce. Ta część najbardziej boli. Naprawdę tęsknię za nimi every day.
Ale coś dziwnego się stało, gdy przestałem się nad sobą użalać: zdałem sobie sprawę, że przez lata popełniałem ten sam błąd.
Błąd, który w końcu zauważyłem
Kończyłem projekt. Wrzucałem go tam. Nikomu nie zależało. Rzucałem.
I zawsze myślałem: No cóż, chyba nie jestem do tego stworzony.
Czego nie zdawałem sobie sprawy: Rzucałem jeden krok przed przełomem.
Szukałem kogoś, kto me "uratuje" - dobrej okazji, właściwej pracy, idealnego momentu. Ale tak to nie działa.
9 miesięcy za granicą taught me wiele
Przeniosłem się do Holandii z w zasadzie niczym. Przez ostatnie 5 miesięcy pracowałem na zmianach magazynowych w ciągu dnia (10 godzin, czasem więcej) i kodowałem nocą na laptopie, który regularnie osiąga 95°C.
Czy jestem szalony? Może trochę.
Ale oto czego się nauczyłem:
Jedyną osobą, która może poprawić twoją sytuację, jesteś ty.
Nie twój szef. Nie szczęście. Nie okoliczności. Ty.
Ostatnia ściana to nie talent
To ludzie. I wytrwałość. I chęć podejścia do rzeczy z różnych kątów, gdy pierwszy kąt nie działa.
Każdy projekt, który widzę, że "się udał" - to nie dlatego, że osoba była najbardziej utalentowana. To dlatego, że nadal się pojawiała, gdy nic jeszcze nie działało.
Więc o tej utracie pracy
Szczerze? To miesięczne opóźnienie. Tyle.
Nadal koduję. Nadal buduję. Nadal wysyłam.
Wracam do Polski zobaczyć się z rodziną i psami (serio, muszę je przytulić). Potem zastanowię się, czy zostać w Holandii, czy spróbować Niemiec.
Ale misja się nie zmieniła. Jedyne co changed, to timeline cofnął się o miesiąc.
Dlaczego jestem optymistą
2025 nauczył me, że jestem twardszy niż myślałem.
Że potrafię poradzić sobie z niepowodzeniami bez zawalenia się.
Że ograniczenia nie muszą cię zatrzymać - tylko testują, czy naprawdę tego chcesz.
Chcę. Więc się nie martwię.
Po prostu się pojawiam. Every day. Na umierającym laptopie. Z psami czekającymi na me w Polsce i setupem desktopowym z dwoma monitorami czekającym na me w nowym roku.
To mi teraz wystarczy.
Mam nadzieję, że wszyscy radzicie sobie w tym sezonie. Jeśli mierzycie się z czymś podobnym - utratą pracy, niepowodzeniem, czymś co wydaje się was wykoleić - pamiętajcie: ostatnia ściana jest bliżej niż się wydaje.
Idźcie dalej.
Siedzę teraz w Polsce, Fallout 4 na pauzie, psy chrapią obok me.
3 miesiące temu byłem w magazynie w Holandii. 10 godzin kompletacji zamówień. Potem 2 godziny kodowania nocą na laptopie osiągającym 95°C.
Ludzie ciągle pytali, kiedy rzucę. Kiedy się "uspokoimy."
Nigdy nie rzuciłem. Po prostu przedefiniowałem, co znaczy "serio".
HISTORIA:
22 grudnia: Straciłem pracę.
Zamiast panikować: przywiozłem mój PC z Polski (zostawiłem go 9 miesięcy temu).
Zacząłem: Projekt PC_Workman (monitoring systemu z AI).
Rezultat: 40 000 linii kodu w 5 miesięcy.
Ale oto co dziwne - nie było trudniej podczas zmiany magazynowej. Było JAŚNIEJ.
Ograniczenia nie zabijają projektów.
Wyjaśniają je.
Gdy twój laptop umiera, nie budujesz rozdętych funkcji.
Gdy masz 2 godziny, nie marnujesz czasu na spotkania ze sobą.
Gdy jesteś sam, uczysz się szybko decydować.
To nie są przeszkody. To filtry.
CO SIĘ ZMIENIŁO:
❌ Nie moje okoliczności.
❌ Nie moje zasoby.
❌ Nie mój talent.
Tylko moja definicja "gotowości".
Nigdy nie miałem czuć się gotowy.
I tak wysłałem.
Dla każdego budującego coś solo teraz:
Nie jesteś w tyle. Jesteś dokładnie tam, gdzie musisz być.
Niewidzialne 90% developmentu (przepisywanie, nieudane podejścia, sesje debugowania o 2 w nocy) - to nie porażka. To proces.
Przestań czekać na lepsze warunki.
Zacznij wysyłać to, co masz.
To dosłownie jedyna różnica między ludźmi, którzy wysyłają, a ludźmi, którzy mówią o wysyłaniu.
Cel na 2025: Przywieźć mój PC do Holandii. Wysłać PC_Workman porządnie. Aplikować na zdalne stanowiska dev.
Nie dlatego, że warunki są idealne.
Dlatego, że nigdy nie będą.
Po prostu dlatego, że to czas.
Zbudowałem narzędzie do monitoringu/optymalizacji systemu Windows przez 4 miesiące. Szukam technicznego feedbacku.
Spędziłem ostatnie 2 miesiące budując PC Workman, desktopową aplikację Windows do monitoringu systemu, śledzenia zdrowia sprzętu i optymalizacji.
KONTEKST:
Niczego nie sprzedaję. To nie jest pitch produktu.
Jestem solo deweloperem, który zbudował to początkowo dla siebie, a teraz jestem w punkcie, gdzie potrzebuję feedbacku od ludzi, którzy faktycznie zarządzają systemami every day - nie tylko entuzjastów.
Co robi (przegląd techniczny):
🔍 Monitoring systemu:
• Metryki real-time: CPU (per-core), RAM (użyta/dostępna/cache), GPU (użycie, temp, VRAM), disk I/O, network throughput
• Detekcja sprzętu: WMI + zapytania registry dla płyty głównej, CPU, RAM (prędkość, timings), GPU (model, VRAM, wersja driver)
• Sensory temperatury: CPU (per-core via WMI), GPU (NVIDIA/AMD APIs), płyta główna (SuperIO jeśli dostępne)
• Tracking procesów: Top konsumentów zasobów, wzorce użycia historycznego, analiza wpływu startupu
⚙️ Narzędzia optymalizacji (18 planowanych, ~12 funkcjonalnych):
• Zarządzanie programami startupowymi (HKEY_LOCAL_MACHINE + Task Scheduler)
• Dostrajanie priorytetu procesów (SetPriorityClass API)
• Czyszczenie cache (przeglądarki, Windows temp, prefetch, thumbnail cache)
• Optymalizacja planu zasilania (powercfg wrapper)
• Automatyzacja czyszczenia dysku (cleanmgr scripting)
• Zarządzanie usługami (identyfikacja nieistotnych usług, kontrolowane wyłączanie)
🏗️ Architektura:
• Język: Python 3.14
• UI: Tkinter (natywny, lekki, bez rozdęcia web wrapper)
• System APIs: psutil (cross-platform base), GPUtil (GPU), WMI (Windows-specific), ctypes (direct Win32 API calls)
• Wydajność: ~30MB RAM idle (Minimal Mode), ~60MB (Expanded View z aktywnym monitoringiem)
• Częstotliwość update: 1-sekundowe polling (konfigurowalne), event-driven dla niektórych metryk
🎨 Podwójne tryby UI:
• Minimal: App w zasobniku systemowym, hover dla szybkich statystyk, klik dla akcji
• Expanded: Pełny dashboard z zakładkami (Your PC, Optimization, Statistics)
Dlaczego tu piszę:
Potrzebuję technicznej krytyki od sysadminów, nie entuzjastów.
Konkretne obszary, gdzie chcę feedbacku:
1️⃣ Wybór metryk - co jest faktycznie użyteczne?
2️⃣ Narzędzia optymalizacji - gdzie jest linia zagrożenia?
3️⃣ Niezawodność Windows API - jakie są pułapki?
4️⃣ Eskalacja uprawnień - kiedy wymagać admina?
5️⃣ Kompatybilność - szerokość testowania
⚠️ Dług techniczny, którego jestem świadomy:
• Brak automatycznych testów (tylko manualne - wiem, wiem)
• Obsługa błędów jest niespójna (niektóre API failures crashują, inne cicho failują)
• Brak logowania jeszcze (utrudnia troubleshooting problemów użytkowników)
• Ustawienia w JSON (powinno używać registry lub AppData poprawnie)
• Responsywność UI (niektóre operacje blokują main thread - potrzeba async refactor)
Jestem w punkcie, gdzie budowanie w izolacji przynosi malejące zwroty.
Potrzebuję ludzi, którzy faktycznie wdrażali narzędzia monitoringowe, zarządzali flotami, troubleshootowali dziwny sprzęt - żeby powiedzieli mi, czego mi brakuje.
Jeśli dotarłeś do tego miejsca, dziękuję.
Jeśli masz techniczną krytykę, dawaj. Dlatego tu jestem.
Dev.to - Społeczność deweloperów
Tutoriale techniczne i poradniki
I built publicly for 5 months. Nobody was watching. December 22. I got fired.
Jest moment w każdym projekcie, kiedy zdajesz sobie sprawę, że budowałeś złą rzecz. Dla me ten moment przyszedł cztery razy.
Setup
9 miesięcy temu przeniosłem się z Polski do Holandii.
Nie na pracę w tech - na stanowisko w magazynie. Kompletacja zamówień. 15-20km chodzenia dziennie, skanowanie kodów, ładowanie palet.
Za dnia: magazynier
Nocą: budowanie oprogramowania na laptopie z 2014 osiągającym 94°C
Chciałem zbudować narzędzie do monitoringu PC. Nie kolejny dashboard pokazujący "CPU: 87%", ale coś, co mówi DLACZEGO. Który proces. Która aplikacja w tle. CO SPRAWIA, ŻE NAPIĘCIE SKACZE?
Różnica między monitoringiem a rozumieniem.
Prosty koncept. To co nastąpiło było masowo mej proste.
Rebuild #1: Pułapka "to działa"
Moja pierwsza wersja wyglądała jak Windows 95 mający atak paniki.
Co zbudowałem:
• Spam emoji wszędzie (myślałem, że to "nowoczesne")
• Pionowe stosy wymagające niekończącego się przewijania
• Zero hierarchii wizualnej
• 15+ funkcji, o które nikt nie prosił
Ale działało. Technicznie. Liczby się aktualizowały. Dane były dokładne.
Byłem dumny przez około dwa tygodnie.
Potem używałem tego every day i nauczyłem się pierwszej brutalnej lekcji:
"Działające" ≠ "Dobre"
Jest masywna przepaść między "kod działa" a "faktycznie chciałbym to mieć na ekranie".
📝 Napisanych linii: ~15 000
🗑️ Usuniętych linii: ~15 000
⏰ Zmarnowanego czasu: 2 miesiące
Rebuild #2: Faza Architecture Astronaut
Klasyczny błąd. Poszedłem full "proper engineering":
Co myślałem, że ma znaczenie:
✓ Architektura oparta na zdarzeniach
✓ Modularny system wtyczek
✓ Czysta separacja concerns
✓ Właściwe design patterns
Co użytkownicy widzieli:
💀 Złą aplikację mobilną działającą na desktopie
💀 Mylącą nawigację
💀 Funkcje, których nikt nie potrzebował
Spędziłem 2 tygodnie budując automatyczną kontrolę wentylatorów. Piękny kod. Drag-and-drop krzywych. Real-time preview.
Potem przetestowałem to porządnie.
Jedna zła krzywa = potencjalnie spalona GPU.
I deleted everything.
🗑️ Zbudowanych i zabitych funkcji: 29
💡 Lekcja: To, że MOŻESZ to zbudować, nie znaczy, że POWINIENEŚ
Moment o 3 w nocy
Wyobraź sobie:
⏰ Czas: 3 w nocy
🔥 Temperatura laptopa: 94°C
💨 Wentylatory: wrzeszczą
😫 Me: just finished a 10-hour warehouse shift
📝 Git log: 400+ commits saying "fix" and "maybe this time"
And I asked myself: what am I actually building?
I was building a tool for users who want to understand their PC.
But I was coding like someone trying to prove they could code.
Different goals. Different products.
That night I threw out the UI. Again.
Rebuild #3: Asking the Right Question
Instead of "what features can I add?"
I asked "what does someone actually NEED to see?"
The answer was embarrassingly simple:
┌─────────────────────────────────────┐ │ CPU [████████░░] 78% RAM [██████░░░░] 62% │ ← Obok siebie. Bez przewijania. ├─────────────────────────────────────┤ │ TOP PROCESY: │ │ ▓▓▓ chrome.exe 43% │ - Najciemejsze = top konsument │ ▓▓ discord.exe 22% │ │ ▓ windows_update 12% │ - Natychmiastowa hierarchia wizualna │ ░ vscode.exe 8% │ └─────────────────────────────────────┘ Click any process → instant details
I deleted 15,000 lines during the refactor.
39 000 do 24 000.
The product got BETTER when I deleted code.
Then I got fired
December 22. Three days before the holidays.
Agency: "The trial period didn't work out."
Ja: W tymczasowym mieszkaniu. Psy w Polsce. Laptop umiera. Projekt w 70% gotowy.
Logiczna reakcja: panika, szukać pracy, porzucić projekt.
What did I do: I started rebuild #4.
How 680 Hours Actually Look
Let me be honest:
⏰ Zakodowanych godzin: 680+ (po zmianach magazynowych)
📝 Napisanych linii: 39 000
✅ Zachowanych linii: 24 000
🔄 Complete UI rebuilds: 4
🗑️ Zabitych funkcji: 29
🎮 GPU monitoring attempts: 6 (5 failed)
☕ Coffee consumed: 340+ cups
🔥 Max laptop temperature: 94°C (somehow survived)
Tech Stack (dla ciekawskich)
🐍 Core: Python 3.11+
🎨 UI: Tkinter + CustomTkinter
📊 System data: psutil, GPUtil, WMI
⚙️ Architektura: Event-driven, modular
💾 RAM footprint: ~30MB (zoptymalizowane dla potato hardware)
Why Tkinter? Because 30MB RAM footprint beats 300MB Electron bloat. And it works great on decade-old hardware.
What I Actually Learned
✅ Motivation is useless. Gone by week 2. Stubbornness remained.
✅ "Working code" is a trap. My first version worked perfectly. It was also garbage to use.
✅ Delete more. Seriously. I deleted 40% of the code and the product improved.
✅ Constraints = resources. Dying hardware = zero bloat allowed. Every feature earned its place.
✅ Show up when it's not fun. That's the only difference between shipped and abandoned.
Obecny status
Shipping in a few weeks. Not because I'm fast - because I didn't quit.
Features that shipped:
✅ Real-time monitoring with actual process breakdown
✅ Time travel debugging (see what was running 3 hours ago)
✅ Custom fan curves with safety validation
✅ Diagnostyka wspomagana AI
✅ 30MB RAM footprint
If you're building something solo and it feels painfully slow - it's not failure.
To po prostu development.
*Currently at 70%. Documenting the rest of the journey on my LinkedIn and GitHub!
What's your "I rebuilt this way too many times" story?
Drop a few words ;)
I'm not pasting my links here. Because this is my first post. And maybe the algorithm doesn't like it ;)
HackerNoon - Tech Stories
Innovation and technological insights
Posts coming soon...
IndieHackers - Startup Journey
Building business as a solo founder
Posts coming soon...
Facebook - Broader Updates
Community engagement and announcements
Posts coming soon...