Czy potrafisz dostrzec cały las za drzewami?
Jak często widziałeś programistów, którzy utknęli w recenzji kodu, omawiając optymalizację metod lub „doskonałość kodu”? Spędzają godziny lub nawet dni, próbując uczynić kod doskonałym? Czy to naprawdę pomogło w stworzeniu dobrze zaprojektowanego rozwiązania?
Programiści często utkną w drobnych szczegółach i całkowicie tracą z oczu ogólny obraz. To bardzo częsty błąd, który widzę w zespołach inżynieryjnych. W rezultacie mamy doskonałe klasy lub funkcje i kompletny bałagan w ogólnej strukturze.
Właściwa recenzja powinna zawsze zaczynać się od ogólnego spojrzenia:
🔸 Struktura komponentów: Czy zmiany są wdrożone w komponentach/usługach, które są faktycznie odpowiedzialne za tę logikę?
🔸 Struktura modułów: Czy zmiany w modułach są takie, jakich się spodziewałeś (publiczne vs prywatne, pkg vs wewnętrzne itd.)?
🔸 Kontrakty publiczne: Sprawdź, jak Twoje API będą wykorzystywane przez inne aplikacje. Czy są one jasne, wygodne, łatwe w użyciu i łatwe do rozszerzenia?
🔸 Nazewnictwo: Czy nazwy modułów, klas i funkcji są jasne i łatwe do zrozumienia? Czy nie dublują istniejących podmiotów?
🔸 Model danych: Czy model jest prawidłowo modelowany? Czy model postępuje zgodnie z zasadą pojedynczej odpowiedzialności?
🔸 Testy: Czy główne przypadki są uwzględnione? A co z negatywnymi scenariuszami? Czy mamy właściwe podejście do obsługi błędów?
W większości przypadków nie ma sensu sprawdzać szczegółów kodu, dopóki powyższe elementy nie zostaną sfinalizowane. Kod prawdopodobnie zostanie przepisany, być może nawet więcej niż raz.
Dlatego konkretne linie kodu powinny być ostatnią rzeczą do sprawdzenia.
Szczegóły są łatwe do naprawienia.
Struktura i kontrakty nie są.
#engineering #codereview
Jak często widziałeś programistów, którzy utknęli w recenzji kodu, omawiając optymalizację metod lub „doskonałość kodu”? Spędzają godziny lub nawet dni, próbując uczynić kod doskonałym? Czy to naprawdę pomogło w stworzeniu dobrze zaprojektowanego rozwiązania?
Programiści często utkną w drobnych szczegółach i całkowicie tracą z oczu ogólny obraz. To bardzo częsty błąd, który widzę w zespołach inżynieryjnych. W rezultacie mamy doskonałe klasy lub funkcje i kompletny bałagan w ogólnej strukturze.
Właściwa recenzja powinna zawsze zaczynać się od ogólnego spojrzenia:
🔸 Struktura komponentów: Czy zmiany są wdrożone w komponentach/usługach, które są faktycznie odpowiedzialne za tę logikę?
🔸 Struktura modułów: Czy zmiany w modułach są takie, jakich się spodziewałeś (publiczne vs prywatne, pkg vs wewnętrzne itd.)?
🔸 Kontrakty publiczne: Sprawdź, jak Twoje API będą wykorzystywane przez inne aplikacje. Czy są one jasne, wygodne, łatwe w użyciu i łatwe do rozszerzenia?
🔸 Nazewnictwo: Czy nazwy modułów, klas i funkcji są jasne i łatwe do zrozumienia? Czy nie dublują istniejących podmiotów?
🔸 Model danych: Czy model jest prawidłowo modelowany? Czy model postępuje zgodnie z zasadą pojedynczej odpowiedzialności?
🔸 Testy: Czy główne przypadki są uwzględnione? A co z negatywnymi scenariuszami? Czy mamy właściwe podejście do obsługi błędów?
W większości przypadków nie ma sensu sprawdzać szczegółów kodu, dopóki powyższe elementy nie zostaną sfinalizowane. Kod prawdopodobnie zostanie przepisany, być może nawet więcej niż raz.
Dlatego konkretne linie kodu powinny być ostatnią rzeczą do sprawdzenia.
Szczegóły są łatwe do naprawienia.
Struktura i kontrakty nie są.
#engineering #codereview
Forwarded from TechLead Bits
Can you see the forest for the trees?
How often have you seen developers stuck in code review discussing some method optimization or "code excellence"? Spending hours or even days trying to make code perfect? Did that really help build a well-architected solution?
Developers often get stuck in small details and completely lose sight of the bigger picture. That's a very common mistake that I see in engineering teams. As a result, there are perfect classes or functions and complete mess in overall structure.
A proper review should always start with a bird’s-eye view:
🔸 Component structure: Are changes implemented in the components\services that are actually responsible for this logic?
🔸 Module structure: Are changes in the modules you expect them to be (public vs private, pkg vs internal, etc.)?
🔸 Public contracts: Review how your APIs will be used by other parties. Are they clear, convenient, easy to use, and easy to extend?
🔸 Naming: Are module, class and function names clear and easy to understand? Don't they duplicate existing entities?
🔸 Data model: Is the domain modeled correctly? Does the model follow single responsibility principle?
🔸 Testing: Are main cases covered? What about negative scenarios? Do we have proper failure handling approach?
In most cases, there’s no point in reviewing code details until the items above are finalized. The code will likely be rewritten, maybe even more than once.
That’s why specific lines of code should be the last thing to check.
Details are cheap to fix.
Structure and contracts are not.
#engineering #codereview
How often have you seen developers stuck in code review discussing some method optimization or "code excellence"? Spending hours or even days trying to make code perfect? Did that really help build a well-architected solution?
Developers often get stuck in small details and completely lose sight of the bigger picture. That's a very common mistake that I see in engineering teams. As a result, there are perfect classes or functions and complete mess in overall structure.
A proper review should always start with a bird’s-eye view:
🔸 Component structure: Are changes implemented in the components\services that are actually responsible for this logic?
🔸 Module structure: Are changes in the modules you expect them to be (public vs private, pkg vs internal, etc.)?
🔸 Public contracts: Review how your APIs will be used by other parties. Are they clear, convenient, easy to use, and easy to extend?
🔸 Naming: Are module, class and function names clear and easy to understand? Don't they duplicate existing entities?
🔸 Data model: Is the domain modeled correctly? Does the model follow single responsibility principle?
🔸 Testing: Are main cases covered? What about negative scenarios? Do we have proper failure handling approach?
In most cases, there’s no point in reviewing code details until the items above are finalized. The code will likely be rewritten, maybe even more than once.
That’s why specific lines of code should be the last thing to check.
Details are cheap to fix.
Structure and contracts are not.
#engineering #codereview
Forwarded from r/Linux memes
Czy naprawdę przyszłość ludzkości jest w rękach programistów? A może już "w rękach" #AI?
https://www.youtube.com/watch?v=mpQQIpwmXi8
[#Dragan]
https://www.youtube.com/watch?v=mpQQIpwmXi8
[#Dragan]
YouTube
S2E1 - Przyszłość naszego gatunku jest w rękach programistów. Prof. Andrzej Dragan o AI
Przyszłość naszego gatunku jest w rękach programistów. Prof. Andrzej Dragan o AI
Profesor Andrzej Dragan tłumaczy krok po kroku jak działa generatywne AI i jak to możliwe, że czaty znają odpowiedzi na najdziwniejsze pytania. Czy twórcy AI rozumieją swoje…
Profesor Andrzej Dragan tłumaczy krok po kroku jak działa generatywne AI i jak to możliwe, że czaty znają odpowiedzi na najdziwniejsze pytania. Czy twórcy AI rozumieją swoje…
Forwarded from Programmer Humor
#TSMC musi podwoić produkcję tylko dla jednego klienta z USA - zgadnij którego 😁
https://ithardware.pl/aktualnosci/tsmc_produkcja_jeden_klient_zgadnij_usa-48396.html
Odp: https://t.me/ProgramowanieLinux/2056
https://ithardware.pl/aktualnosci/tsmc_produkcja_jeden_klient_zgadnij_usa-48396.html
Odp: https://t.me/ProgramowanieLinux/2056
ITHardware
TSMC musi podwoić produkcję tylko dla jednego klienta z USA - zgadnij którego
Producent chipów musi się rozrosnąć dwukrotnie dla jednego klienta.
LINUX &&|| PROGRAMMING
#TSMC musi podwoić produkcję tylko dla jednego klienta z USA - zgadnij którego 😁 https://ithardware.pl/aktualnosci/tsmc_produkcja_jeden_klient_zgadnij_usa-48396.html Odp: https://t.me/ProgramowanieLinux/2056
Niezły numer...
🤹♀️🤹🤹🤣
Fun Fact: Microsoft Azure Wont Run On Windows Server But Runs On Linux
https://redd.it/1qyow14
@r_linuxmemes
🤹♀️🤹🤹🤣
Fun Fact: Microsoft Azure Wont Run On Windows Server But Runs On Linux
https://redd.it/1qyow14
@r_linuxmemes
Reddit
From the linuxmemes community on Reddit: Fun Fact: Microsoft Azure Wont Run On Windows Server But Runs On Linux
Explore this post and more from the linuxmemes community
Forwarded from Gospodarka, towary, ceny 🏦
"Po fali entuzjazmu nadszedł czas korekty i perturbacji gospodarczych. Firmy zostały zmuszone do optymalizacji kosztów i redukcji zatrudnienia."
Czyli bez doświadczenia nie dostaniesz pracy, ale w takim razie gdzie junior ma zdobyć to doświadczenie?
https://nofluffjobs.com/insights/60-ofert-dla-seniorow-czy-juniorzy-w-it-maja-jeszcze-szanse/?utm_source=email&utm_medium=newsletter_k&utm_campaign=insights-promo&utm_content=90226
PS: Pewnie w Niemczech... Jak to zwykle za rządów PO.
Czyli bez doświadczenia nie dostaniesz pracy, ale w takim razie gdzie junior ma zdobyć to doświadczenie?
https://nofluffjobs.com/insights/60-ofert-dla-seniorow-czy-juniorzy-w-it-maja-jeszcze-szanse/?utm_source=email&utm_medium=newsletter_k&utm_campaign=insights-promo&utm_content=90226
PS: Pewnie w Niemczech... Jak to zwykle za rządów PO.
Gospodarka, towary, ceny 🏦
"Po fali entuzjazmu nadszedł czas korekty i perturbacji gospodarczych. Firmy zostały zmuszone do optymalizacji kosztów i redukcji zatrudnienia." Czyli bez doświadczenia nie dostaniesz pracy, ale w takim razie gdzie junior ma zdobyć to doświadczenie? htt…
Winna #AI? Seniorzy stawiają na jakość, nie na hype
Nie da się analizować dzisiejszego rynku bez uwzględnienia sztucznej inteligencji. Według najnowszych dostępnych danych Stack Overflow z 2025 roku, znaczna część programistów i programistek korzysta już z narzędzi AI, jednak widać tu ciekawą zależność między stażem pracy (seniority) a podejściem do technologii.
Wraz z rosnącym doświadczeniem, bezkrytyczny entuzjazm wobec AI często ustępuje miejsca pragmatyzmowi. Seniorzy korzystają z narzędzi AI rzadziej lub w sposób bardziej wybiórczy. Wynika to z ich większej wiedzy domenowej – potrafią oni szybciej ocenić, kiedy AI „halucynuje” i kiedy optymalniej jest napisać kod samodzielnie.
W tym kontekście juniorzy w IT stają przed nowym wyzwaniem: muszą udowodnić swoją wartość w świecie, gdzie jeden Senior wsparty AI staje się wydajniejszy niż dwóch początkujących pracowników.
https://t.me/ProgramowanieLinux/2059
#VibeCoding
Nie da się analizować dzisiejszego rynku bez uwzględnienia sztucznej inteligencji. Według najnowszych dostępnych danych Stack Overflow z 2025 roku, znaczna część programistów i programistek korzysta już z narzędzi AI, jednak widać tu ciekawą zależność między stażem pracy (seniority) a podejściem do technologii.
Wraz z rosnącym doświadczeniem, bezkrytyczny entuzjazm wobec AI często ustępuje miejsca pragmatyzmowi. Seniorzy korzystają z narzędzi AI rzadziej lub w sposób bardziej wybiórczy. Wynika to z ich większej wiedzy domenowej – potrafią oni szybciej ocenić, kiedy AI „halucynuje” i kiedy optymalniej jest napisać kod samodzielnie.
W tym kontekście juniorzy w IT stają przed nowym wyzwaniem: muszą udowodnić swoją wartość w świecie, gdzie jeden Senior wsparty AI staje się wydajniejszy niż dwóch początkujących pracowników.
https://t.me/ProgramowanieLinux/2059
#VibeCoding
Telegram
LINUX &&|| PROGRAMMING
"Po fali entuzjazmu nadszedł czas korekty i perturbacji gospodarczych. Firmy zostały zmuszone do optymalizacji kosztów i redukcji zatrudnienia."
Czyli bez doświadczenia nie dostaniesz pracy, ale w takim razie gdzie junior ma zdobyć to doświadczenie?
ht…
Czyli bez doświadczenia nie dostaniesz pracy, ale w takim razie gdzie junior ma zdobyć to doświadczenie?
ht…
Forwarded from Explain🇵🇱Poland!
“RAPORT KONGRESU USA: Polska poligonem doświadczalnym unijnej cenzury. Szokujące kulisy walki z „dezinformacją"
Komisja Sądownictwa Izby Reprezentantów Stanów Zjednoczonych opublikowała wstrząsający raport, który rzuca nowe światło na mechanizmy kontroli słowa w Unii Europejskiej. Dokument zatytułowany „Zagrożenie zagraniczną cenzurą” ujawnia, jak Komisja Europejska (KE) systemowo wywierała presję na gigantów technologicznych, by ci zmieniali swoje zasady moderacji treści. Z ustaleń Amerykanów wynika, że Polska, obok innych krajów Europy Środkowo-Wschodniej, została potraktowana jako swoisty „poligon doświadczalny” dla wdrażania mechanizmów cenzury pod pretekstem walki z dezinformacją”
⬇️
https://niezalezna.pl/swiat/raport-kongresu-usa-polska-poligonem-doswiadczalnym-unijnej-cenzury-szokujace-kulisy-walki-z-dezinformacja/562952
♨️
https://x.com/i/status/2019951703651455355
#cenzura
Komisja Sądownictwa Izby Reprezentantów Stanów Zjednoczonych opublikowała wstrząsający raport, który rzuca nowe światło na mechanizmy kontroli słowa w Unii Europejskiej. Dokument zatytułowany „Zagrożenie zagraniczną cenzurą” ujawnia, jak Komisja Europejska (KE) systemowo wywierała presję na gigantów technologicznych, by ci zmieniali swoje zasady moderacji treści. Z ustaleń Amerykanów wynika, że Polska, obok innych krajów Europy Środkowo-Wschodniej, została potraktowana jako swoisty „poligon doświadczalny” dla wdrażania mechanizmów cenzury pod pretekstem walki z dezinformacją”
⬇️
https://niezalezna.pl/swiat/raport-kongresu-usa-polska-poligonem-doswiadczalnym-unijnej-cenzury-szokujace-kulisy-walki-z-dezinformacja/562952
♨️
https://x.com/i/status/2019951703651455355
#cenzura
niezalezna.pl
RAPORT KONGRESU USA: Polska poligonem doświadczalnym unijnej cenzury. Szokujące kulisy walki z „dezinformacją″ | Niezalezna.pl
Komisja Sądownictwa Izby Reprezentantów Stanów Zjednoczonych opublikowała wstrząsający raport, który rzuca nowe światło na mechanizmy kontroli słowa w Unii Euro
Trwałe przeobrażenia w sektorze #IT. Zawód programisty w centrum zmian
[#XYZ] https://share.google/Hih0liAQhWKf448Hx
#AI #vibecoding ?
[#XYZ] https://share.google/Hih0liAQhWKf448Hx
#AI #vibecoding ?
XYZ
Trwałe przeobrażenia w sektorze IT. Zawód programisty w centrum zmian
Polski sektor IT stopniowo wychodzi z korekty, która w latach 2023–2024 zachwiała poczuciem stabilności wielu firm i pracowników. Modele biznesowe firm technologicznych musiały się zmienić. Kluczowe znaczenie zyskały projekty związane ze sztuczną inteligencją.…
W 1991 roku pewien 21-latek napisał na forum internetowym: „to tylko hobby, nic wielkiego z tego nie będzie”. Dziś to jego „hobby” napędza większość serwerów WWW na świecie oraz 3 miliardy telefonów. Korzystałeś już z niego dzisiaj… i nawet o tym nie wiedziałeś.
⬇️ https://t.me/ProgramowanieLinux/2067
♨️
https://www.facebook.com/share/p/17zXtQKeLN/
Zdjęcie 📸: Linus Torvalds (1991–obecnie): student, którego „hobby” zmieniło wszystko… bo oddał je za darmo.
#Linus i jego #linux
⬇️ https://t.me/ProgramowanieLinux/2067
♨️
https://www.facebook.com/share/p/17zXtQKeLN/
Zdjęcie 📸: Linus Torvalds (1991–obecnie): student, którego „hobby” zmieniło wszystko… bo oddał je za darmo.
#Linus i jego #linux
LINUX &&|| PROGRAMMING
W 1991 roku pewien 21-latek napisał na forum internetowym: „to tylko hobby, nic wielkiego z tego nie będzie”. Dziś to jego „hobby” napędza większość serwerów WWW na świecie oraz 3 miliardy telefonów. Korzystałeś już z niego dzisiaj… i nawet o tym nie wiedziałeś.…
25 sierpnia 1991. Helsinki, Finlandia.
Student informatyki o imieniu Linus Torvalds był sfrustrowany.
Właśnie wydał wszystkie wakacyjne oszczędności na nowy komputer 386 — potężny jak na swoje czasy, ale bezużyteczny bez systemu operacyjnego, który mógłby naprawdę dostosować do własnych potrzeb.
Używał MINIX-a, edukacyjnego systemu stworzonego przez profesora do nauczania. Działał, ale był celowo ograniczony. Profesor chciał, aby był prosty dla studentów. Linus chciał czegoś, czego mógłby używać naprawdę.
Zrobił więc coś, co wydawało się szaleństwem: postanowił napisać własny system operacyjny.
Od zera. W swoim małym mieszkaniu w Helsinkach. Jako hobby.
25 sierpnia opublikował wiadomość na mało znanym forum comp.os.minix:
„Tworzę system operacyjny (darmowy) (to tylko hobby, nie będzie duży ani profesjonalny jak GNU) dla klonów 386(486) AT.”
Był skromny. Niewiarygodnie, historycznie skromny.
To „hobby” stało się Linuksem — systemem operacyjnym, który ostatecznie zaczął działać na większości komputerów świata, choć prawie nikt nie znał jego nazwy.
We wrześniu 1991 Linus miał coś ledwie działającego: 10 239 linii kodu. Wystarczająco, by się uruchomić, odpalić powłokę i wykonywać podstawowe operacje.
Wtedy podjął decyzję, która wydawała się niepozorna, ale okazała się rewolucyjna:
Opublikował wszystko w internecie. Za darmo. Z pełnym kodem źródłowym widocznym i możliwym do modyfikacji.
„Jeśli chcesz z tego korzystać — proszę bardzo. Jeśli możesz to ulepszyć — zrób to.”
To było radykalne.
Rok 1991 był erą oprogramowania zamkniętego. Microsoft, Apple, IBM… wszyscy chronili swój kod jak tajemnice państwowe, sprzedawali drogie licencje i utrzymywali ścisłą kontrolę.
Linus zrobił odwrotnie. Oddał wszystko za darmo.
I wydarzyło się coś nieoczekiwanego.
Programiści z całego świata zaczęli pobierać jego kernel. Znajdowali błędy i je poprawiali. Dodawali funkcje. Udostępniali ulepszenia dalej.
Powstawała społeczność.
W 1992 Linus podjął kolejną kluczową decyzję: objął Linuksa licencją GNU GPL, co oznaczało, że każdy może go używać, modyfikować i rozpowszechniać, ale wszelkie ulepszenia również muszą pozostać darmowe.
Żadna firma nie mogła przejąć Linuksa i zamknąć go. Miał pozostać otwarty na zawsze.
To wszystko przyspieszyło.
W połowie lat 90. Linux przekształcił się z projektu studenckiego w poważny system operacyjny. Firmy tworzące strony internetowe potrzebowały serwerów niezawodnych i tanich. Linux oferował dokładnie to: za darmo, stabilnie i bezpiecznie.
Firmy z ery bańki dotcomów działały na Linuksie.
Potem przyszedł rok 2008: Google wypuścił Androida, zbudowanego na kernelu Linuksa.
Nagle #Linux nie był już tylko dla serwerów. Był w miliardach kieszeni na całym świecie.
Taka #historia...
⬇️ https://t.me/ProgramowanieLinux/2068
Student informatyki o imieniu Linus Torvalds był sfrustrowany.
Właśnie wydał wszystkie wakacyjne oszczędności na nowy komputer 386 — potężny jak na swoje czasy, ale bezużyteczny bez systemu operacyjnego, który mógłby naprawdę dostosować do własnych potrzeb.
Używał MINIX-a, edukacyjnego systemu stworzonego przez profesora do nauczania. Działał, ale był celowo ograniczony. Profesor chciał, aby był prosty dla studentów. Linus chciał czegoś, czego mógłby używać naprawdę.
Zrobił więc coś, co wydawało się szaleństwem: postanowił napisać własny system operacyjny.
Od zera. W swoim małym mieszkaniu w Helsinkach. Jako hobby.
25 sierpnia opublikował wiadomość na mało znanym forum comp.os.minix:
„Tworzę system operacyjny (darmowy) (to tylko hobby, nie będzie duży ani profesjonalny jak GNU) dla klonów 386(486) AT.”
Był skromny. Niewiarygodnie, historycznie skromny.
To „hobby” stało się Linuksem — systemem operacyjnym, który ostatecznie zaczął działać na większości komputerów świata, choć prawie nikt nie znał jego nazwy.
We wrześniu 1991 Linus miał coś ledwie działającego: 10 239 linii kodu. Wystarczająco, by się uruchomić, odpalić powłokę i wykonywać podstawowe operacje.
Wtedy podjął decyzję, która wydawała się niepozorna, ale okazała się rewolucyjna:
Opublikował wszystko w internecie. Za darmo. Z pełnym kodem źródłowym widocznym i możliwym do modyfikacji.
„Jeśli chcesz z tego korzystać — proszę bardzo. Jeśli możesz to ulepszyć — zrób to.”
To było radykalne.
Rok 1991 był erą oprogramowania zamkniętego. Microsoft, Apple, IBM… wszyscy chronili swój kod jak tajemnice państwowe, sprzedawali drogie licencje i utrzymywali ścisłą kontrolę.
Linus zrobił odwrotnie. Oddał wszystko za darmo.
I wydarzyło się coś nieoczekiwanego.
Programiści z całego świata zaczęli pobierać jego kernel. Znajdowali błędy i je poprawiali. Dodawali funkcje. Udostępniali ulepszenia dalej.
Powstawała społeczność.
W 1992 Linus podjął kolejną kluczową decyzję: objął Linuksa licencją GNU GPL, co oznaczało, że każdy może go używać, modyfikować i rozpowszechniać, ale wszelkie ulepszenia również muszą pozostać darmowe.
Żadna firma nie mogła przejąć Linuksa i zamknąć go. Miał pozostać otwarty na zawsze.
To wszystko przyspieszyło.
W połowie lat 90. Linux przekształcił się z projektu studenckiego w poważny system operacyjny. Firmy tworzące strony internetowe potrzebowały serwerów niezawodnych i tanich. Linux oferował dokładnie to: za darmo, stabilnie i bezpiecznie.
Firmy z ery bańki dotcomów działały na Linuksie.
Potem przyszedł rok 2008: Google wypuścił Androida, zbudowanego na kernelu Linuksa.
Nagle #Linux nie był już tylko dla serwerów. Był w miliardach kieszeni na całym świecie.
Taka #historia...
⬇️ https://t.me/ProgramowanieLinux/2068
❤1