u/AdorablSillyDisorder

I did some napkin math around droprates and farming speed for offline (SSF but with player count control access), and expected average of completing chronicle is approximately 1.5 years playing 6-8 hours a day assuming average drop luck. I assumed some mixed farming methods (LK, Trav, terror zones/terrorized acts, chaos) - largely to cover both runes and more rare uniques for full chronicle completion, but also to not burn out on running LK for half a year non-stop.

Not even that unlucky, landing two Fissures in a row is 9% chance, which is more likely than any single attack to be a crit (without any crit boosting).

The problem with Spirit is that it has too much everything caster in single easily accessible package. I wouldn’t nerf it as the go-to early caster/progression package, but it should lack sufficient amount of desired stats to not be a default every time. I’m talking mostly weapon here - shield is generally in a fine spot.

My idea would be:
* replace 22 vitality with 22 energy, to force survivability elsewhere.
* Set FCR to fixed 30, this already should require more tradeoffs for major FCR breakpoints compared to handing a better roll - 63/75/105 suddenly require more FCR elsewhere.
* Get rid of FHR. Completely. It has no place on a caster weapon. If you really want something to stay here, make it Defense vs Missiles.

There’s already White for necro, sin has Pattern/Mosaic, there are multiple bow runewords, and don’t forget each class has their own midgame armor RW.

Not as much "wrong decisions" as specifically "tradeoffs". Some skills are better for levelling, some are great at low gear investment, some work better against groups/bosses, you need to pick and choose what your character will suck at. Some skills that full on suck are either synergies (inferno synergies meteor damage and gets use for skill points), or happen to be just good levelling choices that fall off hard (Charged Bolt).

Some tweaks wouldn't be unwelcome to make sure each skill has at least some niche (why not make Inferno be highest potential single target DPS for fire sorc, assuming you can afford to stand still against immobile target?) - but making every build be equally good is arguably wrong direction and homogenises the game/builds far too much.

Sunders should be less of a core build piece and more of a late game enabler/season chase that enables you to respec into single damage type builds. Resistances/immunities could use some rebalance so every single-damage-type build suffers to similar degree depending on area (physical is mostly fine, lightning could use some higher res on immune monsters to make conviction/amp damage less “free”, magic immunity should be more common and maybe replace poison immunity as 2nd one for souls etc).

Jak masz papiery z prawa, pakuj się w temat compliance - niekoniecznie jako QA/programista, a bardziej jako analityk, osoba od dokumentacji, kontroli wymagań, zgodności z procedurami itd. O ile sam tej ścieżki nie przechodziłem, mamy trochę osób po administracji, rachunkowości itd, które wylądowały na pół-technicznych stanowiskach w naszym IT, gdzie ogarniają punkt styku między częścią formalną a programistami/QA.

Przy takim podejściu patrzysz bardziej po ogłoszeniach gdzie wymagają wykształcenia/wiedzy domenowej (tematy formalne, prawne) z dodatkową wiedzą/umiejętnościami technicznymi - mając taki punkt startu, możesz potem się specjalizować i przechodzić w mniej lub bardziej techniczne tematy, zależnie jak ci będzie pasowało. 2-3 lata doświadczenia "w rozkroku" na takich stanowiskach powinno dać ci całkiem sporo opcji na przyszłość.

Model evaluation is quite good at finding direct contradictions or recategorizing findings into contextual - say, treating "moon is made of cheese" as some fanfiction/fantasy or parody.

Better trick is to feed something that is plausible but subtly wrong, and - when used as base of AI output generation - will escalate into wrong output. Functionally it's similar to "hallucination injection" - if you have something wrong early in token stream, that wrong will propagate further down.

To paraphrase my boss' boss (who is an AI enthusiast) - "LLM is less of a programmer, and more of a fancy, nondeterministic compiler" - it still requires programmer to manage whole process, check the output and keep all requirements in check.

If anything, AI in software dev has major problem of making plausible-but-wrong output very easy, that makes catching problems harder, more tedious and requires user to put a lot of extra care to not produce slop.

Actual issue I see here is not "AI can't code", and more "things AI is good at are also things you usually use to train juniors" - straightforward tasks that they can take on, while being exposed to overall complexity of software engineering, and learning what to pay attention to when being given a new task. I have no idea what will happen few years down the line, when we'll need more senior devs and nobody is training anyone anymore; especially since AI usage is exercising a lot of "senior skills" in terms of review, requirement handling, ambiguity resolution etc.

I swear I've seen develop more frequently than master out there in the wild (corporate wild). Overall - doesn't matter, as long as it's default branch that sets up after clone, you set up new repo about once per repository lifetime anyway.

This exactly, and "no bezel" was very much worth paying extra for - 1:2:1 layout with terminal/IDE/teams is one I use most often, and in dual-screen setup bezel would cut halfway through IDE.

This also gives you time to migrate whatever you had set up there to approved browser before you hit uninstall - bookmarks, plugins, you name it. The "you're breaching rules, please fix it" is a standard practice whenever there's no malicious intent or immediate major risk assumed.

Not sure what class exactly, but doing some light "rule-breaking" similar to Warlock/Assassin could be nice. Could make a ranged dual-wielder (people mentioned demon hunter and dual crossbow) that has independent attack animation speed for each weapon, could go for a skill tree that pushes "mobility as a way of dealing damage" well past what barbs jump/whirlwind does (also pairs neatly with range) or maybe even for comboing movement abilities with in-movement ones - multiple different movement skills and skills that are usable while you're moving.

In general, I feel there's a lot of unexplored space in dynamic/flexible combo skill use that martial assassin sort of touches on, but nothing really leans onto on-the-fly combo decisions past maybe having 2 different usable skills for different situations.

MIT-adjacent permissive licenses are very much a "this is a thing, do whatever you want with that thing" and opting to minimize potential friction license could cause - unlike various copyleft licenses (CC-SA, GPL family) that are okay causing some licensing friction to protect rights of downstream users.

This is a common theme for all permissive licenses in general - thing under license exists, can be used, and license or author do not concern themselves with what happens next, it's largely a "free for all" model.

The "learn to code" episode was not as much about turning everyone into programmers, as it was about non-programmers picking up enough basics to handle simple repetetive stuff with code. Going by the assumption that it's generally easier and faster to each accountant how to write some python/vbscript, than to teach programmer about accounting. Just making software less of a magic and more of a tool with quite low barrier of entry.

Funnily, this exact part of "non-programmers write code around their normal job" is something LLMs do a lot to cover, which mostly automates away programmers that were doing menial tedious tasks manually - systems engineering is still going strong, and arguably needs even more people, since "writing code" part got heavily streamlined.

Wiadomo że część tych L4 to nadużycia, problem tylko określić jak duża i czy warto to szczegółowo weryfikować w każdym przypadku. Zwykły rachunek korzyści - czy lepiej przymknąć oko na zdarzające się urL4opy, czy kontrolować i dodatkowo stresować ludzi, którzy takiego zwolnienia naprawdę potrzebują?

Inna sprawa, że sam zawsze traktowałem urlop jako "zwolnienie na potrzeby psychiczne" i - mimo historii leczenia - tego się mocno trzymam.

Jak masz takiego managera to chyba wiadomo gdzie leży problem, agile niestety przyciąga tego typu ludzi, zostaje mi tylko współczuć.

My w końcu (częściowo za moimi naciskami) dorobiliśmy się procedury krytycznych hotfixów na prod, która w praktyce sprowadza się do "zrób ticket, wyślij maila z ticketem do 3 konkretnych osób + twój bezpośredni PM w CC, rób w międzyczasie czekając na okejkę" - co sobie cenię bo pozwala mi się skupić na fixowaniu zrzucając decyzję czy i kiedy wrzucamy na kogoś kto ogarnia same wrzutki.

A jak taki hotfix poleci - to już problem PMa jak to wpisać w excele, inna sprawa że akurat obecnego PMa mam na tyle ogarniętego że jak mówię że coś się pali i wymaga naprawy już teraz, to nie marudzą i sami ogarniają co wyciągnąć ze sprintu żeby zrobić na to miejsce. Jedyne za co dostaję zjeby to jak tak robię bez informowania - tu jestem gotów na 5 minut poświęcenia i napisanie wiadomości na teamsach.

Tymczasem ja do prywatnego jednoosobowego projektu sobie (prostą) Jirę postawiłem - i całkiem się sprawdza. Backlog dobrze mieć, bo oddziela worek "co jest do zrobienia" od "w jakiej kolejności to robię" (co w sumie oznacza też planning); retro nie potrzebuję (ewentualne poprawki do procesu dorzucam do backlogu i łapię jak akurat mi na oko wpadną), sprintów nie trawię (kanban > scrum generalnie).

W praktyce kwestia preferencji - zacząłem doceniać rozdzielanie planowania od robienia jak się okazało, że bardzo sprawnie odciąża model mentalny i pomaga uniknąć "implementacji cieknącej w górę do planu"; nie zaskoczyłoby mnie gdyby innym bardziej freestyle'owe podejście pasowało.

> To jak przez dekady firmy pracowały, mając inne metodyki?

Planując projekty odgórnie i oddając je do programistów jako wykwalifikowanych wyrobników - to był przed-agile standard dla średnich i większych projektów. W praktyce podobne jak agile, tylko zanim ticket w ogóle do progrmisty dotarł, przechodził przez całą ścieżkę akceptacji i był dorzucany do planu na jakąśtam wersję, może za pół roku.

A to co opisujesz, gdzie loop od zgłoszenia do zmiany na produkcji zamyka się w "support i dev" to - za przeproszeniem - patologiczny przypadek. W myśl zasady "wszyscy patrzymy sobie nawzajem na ręce" jak dla mnie brakuje tu minimum dwóch dodatkowych osób - kogoś na wejściu kto nie ma presji na dowiezienie zmiany i może ocenić czy i kiedy to robimy (bo coś się przesunie) i kogoś na wyjściu żeby upewnić się że absolutnie nic nie wybuchło i że sama wrzutka na prod nie rozbije komuś czegoś innego. Agile czy bez, takich kowbojskich wrzut już bym się nigdy nie podjął, za stary na to jestem.

Klepanie możesz zostawić AI - skup się na wszystkim wokół. Czytaj tickety, patrz w kod (samemu, ale też mów AI co ma dla ciebie znaleźć/sprawdzić), szukaj na co twoje zmiany będą miały wpływ, czy wszystko niedopowiedziane w taskach jest w jakiś sposób wzięte pod uwagę itd.

Całkiem przyjemny do nauki (sam teraz używam przy kilku nowych technologiach) AI-friendly loop to: analiza - plan prompt - AI wypluwa plan - review planu - AI implementuje plan - review wyników - AI review - sprawdzenie rezultatu. To jednocześnie daje ci bieżącą kontrolę nad halucynacjami i dziwnymi pomysłami AI, sygnał że może trzeba będzie task rozbić na mniejsze części (jak plan jest nieogarnialny), ale też przy okazji bieżący wgląd w każdą część systemu, nad którą z użyciem LLMów pracujesz.

Generalnie, traktuj LLM jako translator tłumaczący twoje prompty na kod i automatyzujący typowe boilerplate kroki - build, odpalenie testów, zrobienie commitów, pisanie dokumentacji itd. Cała reszta to twoja praca i tego przede wszystkim chcesz się uczyć - język/składnię można podłapać relatywnie szybko (im więcej znasz, tym szybciej), analiza zgłoszeń i decydowanie jak implementacja powinna wyglądać to ta część, gdzie "doświadczenie" siedzi i się buduje.

In programming especially, fully autonomous AI is still very far from actually replacing humans - there's far too much context, implicit assumptions and necessary human input to get anything non-trivial out and working. At best LLMs can replace writing code - and even that only to a degree - but everything surrounding in software dev is left to human: making decision, intepreting (conflicting) requirements, clarifying expectations, weighing tradeoffs, you name it.

Issue with programming is juniors being replaced - there's no good place for new programmers to be exposed to all this non-code part of programming safely and under supervision of more experienced people, so in few years we'll have a major problem of not enough people capable of handling this kind of work. And, to be honest, I'm still figuring out how to properly guide juniors when most manual coding they usually did can skip them completely (alongside all non-code aspects).

Not cheating, abstractions happen in every language (even assembler instructions are converted to different opcodes inside CPU).

Part that makes C++ “hard” is general assumption it makes about users - language is and always was designed with assumption that average user is CompSci expert, with proper theoretical background. This means both a lot of trust in user, and giving enough freedom to settle a lot of what other languages handle by design as just conventions.

Obvious downside: C++ is atrocious language to learn programming with, and comparably bad as “just get things done” tool with enough guardrails to avoid major incidents when cooperating. Still, recommendations and practices like MISRA exist, and they do what they’re supposed to - being conventions to ensure correctness.

Still, proper good C++ course should probably start with good chunk of math (at least enough to internalize proofs and transitive properties) and compiler theory before even touching code. Potentially a problem, but hey - average compsci grad should know all that already, no?

Well-defined boundaries, well-defined contracts, Sol seems to be doing pretty good job sticking to those if given.

...which is essentially providing manually level of edge case and safety coverage Sol is aiming for in first place.

I did, it refused to work on my 2060S, I returned it immediately after thinking I'll wait until it's stable enough to re-purchase. Turns out, it never got to that point.

Defensive programming - actually encoding explicitly all assumptions you make at each step, and having them error reliably at check point rather than produce crashes or weird results down the line. It both helps immensely with testing/debugging, finding actual mistakes (expected guarantee is not provided by caller), and makes actual test surface much cleaner since you don't have to add extra test coverage for "illegal cases".

As a concept/habit it came from me dealing with platform that had questionable log reliability and only debugging tool being error codes on app exit, but applies just about everywhere - even high-performance code you can just use assertions and disable them in release build after you thoroughly checked they can't be broken.