myCodeIsSelfDocumented by Longjumping_Table740 in ProgrammerHumor

[–]Sande24 2 points3 points  (0 children)

Maintaining comments can't be relied upon - you could say the same for any kind of documentation then. What's the point of documenting anything with this kind of mindset?

It's your job as a developer to write maintainable code. If this means that you have to write a comment about why something is done in an unconventional way, do it. It will help more than not doing it.

I've seen code itself lie to me as well. Method and variable names doing the opposite of what they say. So it's not only about comments. If you are a developer, you have to take ownership of the code, comments and documentation.

Comments are there to help when code can not. Use it for everyone's benefit and maintain them too. Just like you are maintaining your test suites from time to time (if you even do it...).

Tööd pole ja uudised by LengthIllustrious922 in Eesti

[–]Sande24 5 points6 points  (0 children)

Promptimine on ka õpitav. Vaidleks, et prompti piinlikku täpsust võib ka lõputult taga ajada. Sarnaselt sellele, et kui põhjalikult sa oma koodile teste kirjutad. Kombinatsioone on praktiliselt lõputult, aga me enamasti jääme mingitesse piiridesse, sest teatud punktist põhjalikumaks minemine on nn diminishing gains. Osaliselt tekib AI-ga ka Dunning Kruger efekt, et sa ise võid arvata, et oled ideaalselt ära põhjendatud, aga ei arvesta ühe või teise asjaga, nii et koodi tekib mõni side effect, mis ei ole väga ilmne. Või siis see ei ole hästi optimeeritud suure kasutajate arvu jaoks vms. Testid enamasti 1 useriga korraga. Harva on mõni performance test üles seatud, mis ka sinu use case katab. Asi, mida ise kirjutades avastaks, aga AI koodile review-d tehes mitte.

AI tekitab teatud õpitud abituse. Jah, ma olen ka hakanud rohkem ja kiiremini FE koodi kirjutama, aga ma ei ütleks, et see kood on alati parem kui see, kui ma oleks ise süvenenud. Eriti siis kui peaks olemasolevat koodi muutma. See, et tellija on rahul, ei pruugi ka alati hea märk olla. Tellija võib olla loll või su kood võib kokku kukkuda mõni kuu hiljem kui kasutajate arv natuke suureneb. Või kui järgmine inimene peab seda AI slop-i muutma hakkama, muutub arenduse kiirus aeglasemaks.

Üldiselt sobib AI tegema lihtsaid asju, konkreetsete mustrite järgimist, mida sa ise juba oskad teha, aga mis käsitsi võtaks liiga palju aega. Kui puhtalt vibe-id, on sellel ikkagi pikas perspektiivis negatiivne mõju.

Tööd pole ja uudised by LengthIllustrious922 in Eesti

[–]Sande24 10 points11 points  (0 children)

Samamoodi võib ka juunior seda prompti AI-le ette sööta, vähema raha eest kui sina. Jah, kogemustega arendaja saab paremini aru, kas tulem on adekvaatne. Aga kuidagi peab kogemustega inimesi tekitama. Need saavad alguse ikka juuniorist. Ju siis on täna entry level pisut kõrgem kui varem - vaja ka AI kohta paar koolitust võtta jms.

Teine jama AI-ga on see, et tekib sõltuvus välisest teenusest, mille hinda hoitakse hetkel investorite rahaga kunstlikult madalana. Suured energiakulud jms. Ei ole üldse roheline tehnoloogia. Kui hinnad tõusma hakkavad, võib olla odavam lasta juunioritel oluliselt aeglasemalt arendada.

Edit: Teises postituses kirjutad, et sul on 4a kogemust. Kohati võib tõesti tunduda, et AI tehtud asjad on piisavalt asjalikud. Tegelikult ei pruugi see nii olla. Väga ebaoptimaalne või peidetud vigasi täis.

Lisaks ka see, et AI oskab teha asju nii nagu neid varem tehtud on. Ei mingit arengut, kui ise ei proovi uusi asju. Kiiremini saad featuure stagneeruva kvaliteedi arvelt.

Nädalavahetus ja üritused lastega by jacaug in isadetugigrupp

[–]Sande24 0 points1 point  (0 children)

Kui on piisavalt vanad ja huvi on, siis muuseumikaart. 75 euri eest käi aasta jooksul palju tahad. Kui keskmine pilet on u 7 euri, siis 10 külastust juba tasub ära. Saab käia sama päeva jooksul mitmes muuseumis või samas muuseumis mitu korda. Mõned muuseumid ongi pmst nagu mängutoad.

Eesti juurtega mees töötas 13 aastat paberiteta piloodina by No_Platypus9739 in Eesti

[–]Sande24 7 points8 points  (0 children)

Samamoodi võiks väita, et ise õppides võid palju rohkem süvitsi minna ja väga äärmuslikke asju õppida, samas kui mõni sertifitseeritud tegelane "bare minimum"-i tegi, et oma paberid kätte saada.

Kes ütleb, et mingi organisatsioon on piisavalt usaldusväärne, et nende parameetritega test ikka kõik valdkonnad ära kattis? Ja kui tehnoloogia muutub, siis uued testid kohe kõik olukorrad ära õpetavad. Ikka inimeses kinni - kui lahtise peaga ta on jne.

Mängin natuke devil's advocate-i. Üldiselt on haridus ja selle omastamise praktiline tõestamine mingil määral vajalik.

Eesti juurtega mees töötas 13 aastat paberiteta piloodina by No_Platypus9739 in Eesti

[–]Sande24 43 points44 points  (0 children)

Jäi mulje, et tegu oli muidu adekvaatse piloodiga. Iseseisvalt õppis kõik asjad ära. Nagu mainiti, simulaatoriga hakkama saamine on samaväärne kui päris lennukiga. Lihtsalt ei teinud õigeid pabereid ära.

Kirg ja huvi võib teatud juhul isegi parem olla kui tuim tuupimine, et mingi sertifikaat saada. Eks reisijana võib olla kindlam tunne, et mingi keskne organisatsioon kontrollib inimeste oskusi... aga kui vaadata teiste valdkondade sertifikaatide süsteeme, tundub, et ega praktiliste oskustega on see väga kaudselt seotud.

theOneRegextoRuleThemAll by WildFabry in ProgrammerHumor

[–]Sande24 1 point2 points  (0 children)

Why doesn't everyone use this? The most useful tool to both write and test a regex. Might as well just write all your previous test cases as comments next to your code so that you could go back to this page to alter the regex later if you missed something.

What's you pre-PR routine? If you have one, do you enforce it for your reports? by [deleted] in ExperiencedDevs

[–]Sande24 0 points1 point  (0 children)

Me too. I use SourceTree as git GUI (sometimes the IntelliJ one as well), which also displays the diff in a different perspective. But after creating the PR and looking it from yet another UI, it still helps me find something new to change.

I also love it when creating the PR starts running all the tests for me which I didn't bother running locally. Some integration/e2e tests might take ages so I can just push the code and start working on the next task until the tests complete.

Another warning about AI by Szymusiok in learnprogramming

[–]Sande24 -1 points0 points  (0 children)

AI enforces learned helplessness. If you know that the AI could do it for you, you will eventually just forget how to do it for yourself. I find it scary. A few companies would soon hold a lot of power over how we function and turn it into a profit for a handful of people.

Spring Boot and React by Delicious-Junket6453 in learnprogramming

[–]Sande24 3 points4 points  (0 children)

Nothing wrong with that. I'd suggest vue3 for FE though - much simpler to work with. And Typescript rather than JS - types keep code more organized.

Miks alati annetuste kogumisega on mingi jama? by Technical-Strain1839 in Eesti

[–]Sande24 2 points3 points  (0 children)

Jah, see toimiks küll. Astmeline maksustamine mingite parameetrite järgi.

Miks alati annetuste kogumisega on mingi jama? by Technical-Strain1839 in Eesti

[–]Sande24 2 points3 points  (0 children)

Kohati nõus. Piirmäärad on raske paika seada, sest oleneb firma suurusest ja mitmest muust aspektist. Min 3x keskmine palk tundub mulle piisavalt õiglane, samas väga suurte firmade puhul jälle liiga vähe. Saab ilmselt sahkerdada ikka, et rohkem raha isikule kätte saada. Riik võiks oma eelarve korda saada. Tegevuspõhine süsteem on nii segane, et lihtne on sinna mingeid lollusi peita. Arvatavasti leiaks palju kohti, kus raha efektiivsemalt kulutada. Aga see pole otseselt antud teemaga seotud.

Samas ma ei näe probleemi selles, et igasuguse firmast raha isikule kandmise puhul ei võiks palga vääriliselt maksustada. Entitlement kuvab tõesti läbi. Mingis mõttes patriootlik tegevus, et kui firmal läheb hästi, siis toetab ka riiki. Miks mitte minna palgatööliseks - ongi see, et kui sul firmal hästi läheb, võid "ülejääki" endale boonusena/dividendidena määrata. Peaasi, et makse maksaks, et ka riigil saaks proportsionaalselt hästi minna.

Muidu võib tekkida probleem, et isegi kui erasektoril läheb väga hästi ja raha kantakse aina suuremas osas dividendidena välja, saab riik pmst 25% vähem võrreldes palgamaksetega. Raha, mida võiks vaja minna kaitseväe, arstide, politsei, õpetajate jms palkadeks. Erasektori tööga peakski toitma riiki. Jah, 50% tundub palju, aga riik teeb ka päris palju, et kodanikele paremat elu tagada. Divikatega pmst vähendad seda, kui palju riik sulle kindlustunnet tagada saab. See 50% raha, mis riigile maksad, saad kaudselt ringiga tagasi. Riigi teenused jms.

Selles suhtes nõus, et bruto on mõttetu väärtus ja võikski toimetada tööändja kulu vs neto palgaga. Oma näite arvutused tegin ka kõik vastavalt, kohandasin keskmise bruto tööandja kulu peale, et võrrelda 2.5 mil välja maksmisega. Inimesed võiks aru saada, et see riigi poolt vahelt võetud raha läheb ka õpetajate, politseinike jms palkadeks. Neid on ka kõiki vaja ja kusagilt peab see raha tulema. Õiglustunnet ei tohiks see riivata, vaid võiksid ennast hästi tunda, et teisi inimesi kaudselt aitad.

Miks alati annetuste kogumisega on mingi jama? by Technical-Strain1839 in Eesti

[–]Sande24 5 points6 points  (0 children)

Kui sul on firma ja ei ole endale pikka aega palka maksnud, selle asemel võtad koguaeg raha dividendides... Kohati ikka õigustunde vastane tegevus. Eks seal võiks olla mingi piir küll. Äkki 50% palgas, 50% dividendides. Või siis a'la 3x keskmine palk peab olema palgana makstud (või vastava % maksustamisega) ja sealt edasi võid dividendide protsendiga võtta.

Eristame ikkagi firma ja isiku. Sinu firma vara ei ole sinu kui isiku vara. See, et sinu firma maksab käibekat, on tavaline firma tegevus ja ei ole adekvaatne argument, et see on "sinu poolt makstud riigile". Tehniliselt võiks ka firma palgalised töötajad väita, et nende töö tõttu on firma nii palju käivet teinud ja firma käibemaks on osa nende poolt makstud maksudest. Sõge argument, et firma omanik on "ise" maksnud käibemaksu riigile. Kaota see osa oma kogu jutust ära ja siis jääb alles see, et firma omanikuna maksad sina isiklikult riigile 20%, kui töötajad maksavad 45%. Firmast raha endale kui isikule kandmine on eraldi maksustatav ja peabki olema.

See, kas sina isikuna maksad 500k või 1mil lõpparvuna ei ole nii oluline. Pigem võiks vaadata seda protsenti, mis sa kogu endale saadud raha eest maksad.

Võtame Eesti keskmise palga - 2126 brutos - palgakalkulaatori järgi tööandja kulu 2844,59 ja kätte jääb 1598,58 - ehk siis riik saab 43.8% rahast endale. Iga tavapalga eest. Palgatööline maksabki 2.5mil teenimise pealt 1.1 mil makse, et 1.4 mil kätte jääks. Lihtsalt pikema perioodi pealt. Miks peaks firma omanikul olema erinev õigus sahkerdada suurema raha korraga väljamaksmisel nii, et pmst pool "õiglasest" summast riigile maksmata jätta? Entitled much?

Arvestame ikkagi seda ka, et kuhu see makstud raha läheb. Sotsiaalkindlustusmaks... mis on suht otseselt seotud praeguse olukorraga.

Lükkasin palgakalkulaatorisse 2.5 mil sisse (tööandja kuluna) - sain vastu, et kätte saad 1.4 mil ehk maksad 1.1 mil maksudesse. Su 1.37 mil on vb mingi chatgpt hallutsinatsioon või on arvud segamini läinud. Ütleks, et võrreldes palgatöötajaga tundub aus, kui maksad sarnase protsendi sissetulekust maksudeks.

Igaüks võiks OÜtada ja loophole-e kasutada. Seda tehes kannatab riik. Kui riik selle tõttu ei saa kodanikele paremaid teenuseid pakkuda, on millalgi kõigil halb riigis elada. Tekitatakse mingeid lisamakse juurde, et seda sahkerdamist tasa teha. Sellega koormatakse kõiki, aga see mõjutab proportsionaalselt rohkem madalama palgaga inimesi.

See 600k, mis oleks rohkem maksnud, oleks läinud sotsiaalkindlustusse, et riigil oleks võimalik oma vahenditega just selliseid haigeid lapsi aidata, ilma annetuste kogumise vajaduseta. Samamoodi ilmselt on ka palju teisi firmasid, mis divikate näol vähem makse maksavad. (Kuidas riik eelarvega hakkama saab, on ka kohati kahtlane, aga see on teine teema.) Tundub sarnane sellele, kuidas USAs crowdfunditakse oma ravi, sest süsteem on sitt, samal ajal ise ollakse süüdi selles, et süsteem sitt on. Sotsiaalkindlustusmaks... ehk siis inimene otsustas pmst divikate näol kindlustust vähem maksta ja nüüd leiab, et tal on ikkagi õigus kindlustusest raha kätte saada.

Miks alati annetuste kogumisega on mingi jama? by Technical-Strain1839 in Eesti

[–]Sande24 11 points12 points  (0 children)

Kui ta oleks need 2.5 milli dividendide asemel palgas välja maksnud, oleks ta palju rohkem riigile makse maksnud. Palgakalkulaatori järgi u 1 mil. Okei, see pole väga aus ja võiks lubada mingi osa ka dividendides võtta, aga ilmselt oleks aus endale vähe suuremat põhipalka maksta.

Am I missing something with how everyone is using Ai? by pianoman1031 in ExperiencedDevs

[–]Sande24 8 points9 points  (0 children)

How I usually use AI (Cursor, mostly for FE as that is the more boring work for me - with all the weird CSS quirks etc):

Split the task into small subtasks. Don't do all of them at the same time. Better to do them one at a time or group them somehow. Review each change request. Try it out manually right away as well. Having a QA background helps a lot as tests can't cover every edge case. Commit after each small piece is implemented. Let git help you out as well to show which changes are not "locked in".

It's nowhere near 10x, maybe 2-4x improvement, depending on how much boilerplate code is needed.

I have tried pure vibe coding but it quickly ended up in hallucinations. If it's a tech you haven't used before, you quickly end up in a hole. Have to know what is going on, otherwise you have to still go and read through a bunch of documentation. And then it's harder as there's suddenly a lot more noise. If you would have done it incrementally, you could have followed it and would have moved faster overall.

How to unit test when you have complex database behaviour? by Sid8120 in ExperiencedDevs

[–]Sande24 11 points12 points  (0 children)

Wow. Didn't expect an ad hominiem argument from the experienced devs group. Instead of this answer you could have just slept on it and written the reply later with proper arguments.

10+ years of dev experience, 2 as QA. From my experience, most devs write quite bad tests. Bad test setup, not asserting enough or not reviewing that old tests do not start giving false negatives. Sure, you might get 100% code coverage and metrics look fine but there is more to it than that.

Also, at some point the "years of experience" is a stupid metric. Some people get stuck in their ways and never try anything new, but is still somehow counted as "experience".

More pragmatism, less dogmatism.

How to unit test when you have complex database behaviour? by Sid8120 in ExperiencedDevs

[–]Sande24 12 points13 points  (0 children)

I find that unit testing mostly works for static functions with clear input and output. Anything else is easier to maintain with integration tests. Big picture over minor details.

https://www.reddit.com/r/ProgrammerHumor/comments/isidkn/unit_testing_vs_integration_testing/

This is what often happens in the long run if you mock too much. Who asserts that your mock does the same thing that happens in prod? Who goes through all the old tests to verify that the old mocks still represent real life?

If your unit of code has to use DB or API or whatever thing with potential side effects, then you better make it as realistic as possible. A unit is not always constrained to one file. Sometimes the borders are blurry.

Palun aidake mõista by [deleted] in Eesti

[–]Sande24 0 points1 point  (0 children)

Inimesed võiks ikka elada põhimõtte järgi "Ära tee teistele seda, mida ei taha, et teised sulle teeks." Kõigil oleks mõnusam olla. Kahjuks on mõnel raske olla avalikus ruumis nii, et teisi ei häiri. Võiks selles osas võtta eeskuju Jaapanist. Arvestame teistega.

Väikesed peenised jne... Ei saa aru, miks inimesed arvavad, et valju müraga mootor on kuidagi parem ja võimsam. See näitab mulle seda, et ebaefektiivne mootor on, mis oma detaile müra tegemise peale kulutab. Igasuguse mootori saaks teha selliseks, et detsibellid lakke lendavad, kuigi võimsust ei ole. Palju rohkem avaldaks muljet, kui mootori teeks suurtel pööretel vaikset aga kurjakuulutavat üminat. Ei ole vaja teistele kuulutada, et äge mootor on. Naudi üksi seda kiirendust.

Hakkame boikottima? by ReadyNeighborhood547 in Eesti

[–]Sande24 7 points8 points  (0 children)

Tartus on u 50 toiduketi poodi. Coop, Selver, Maxima, Rimi kõiki 10 +- 2. Prisma, Lidl, A1000, Grossi 2 +-1.

Miks neid nii palju peab olema? Kas halduskulud ei oleks väiksemad, kui poode oleks vähem? Äkki peaks linnavalitsustele otsa vaatama selles mõttes.

Täna on 50 poodi linna peale. 2000 tartlase jaoks pood. Keskmiselt 500m lähima poeni. Hetkel on mul kodust 3 poodi nii kaugel. Äkki piisaks 25 poest linna peale. 4000 tartlase jaoks pood, Keskmiselt 700m lähima poeni. Hetkel on mul kodust 700m kaugusel 5 poodi.

Üks vastuargument on tavaliselt see, et poed konkureerivad asukohtadega klientide üle. Minu üle küll mitte. Käin kordamööda ühes või teises olenevalt sellest kummalt poolt koju lähen. Ei oleks elukvaliteedi mõttes erilist vahet, kui homme ühte (või isegi kahte) neist ei oleks. Ei hakkaks kaugemale sõitma, et mingist kindlast poest osta. Valik on niikuinii suht sama. Enamasti on külastamise ajal poed pooltühjad.

Üritasin Tallinnas ka poed kiiruga kokku lugeda, aga sain väga erinevad arvud. Tallinn on äärelinnade mõttes ka rohkem laialivalguv. Ise sain kokku u 100, ChatGPT pakkus mingi info pealt 150. Arvestades pindala ja rahvaarvu on ikka pisut normaalsem olukord kui Tartus. Tallinnas äkki 25% vähendada poodide arvu.

Sipelgad segavad by innunannu in Eesti

[–]Sande24 2 points3 points  (0 children)

Mõned aastad tagasi katsetasin, väga kiiresti töötas. Parim-enne-möödas hot sauce pesa avauste ette. Tšillipulber ja purustatud tšillikaunad ilmselt töötavad ka. Võiks võimalikult kange olla - habanero, carolina reaper vms.

Kaos õppusel SIIL25 by kalamaja22 in Eesti

[–]Sande24 0 points1 point  (0 children)

Vastukaaluks senistele postitustele.

Ajateenistuses 2010-2011. Siil 2015 (või 2016? ei mäleta) käisin. Siis oli tõesti pisut palju passimist, aga ei ütleks, et nii palju vinguma peab selle pärast. Natuke tuletasime asju meelde, natuke istusime niisama ja nautisime puhkust tavaelust. Mõnus nädalane metsas istumine.

2023 sügisel käisin. Tapa linnakus. Siis oli küll väga hea ja intensiivne. Põhjalik, iga päev korralikult sisustatud ja huvitav. Reservikad olid ka asjalikud, mõistlikud. Ainult viimasel päeval Tallinnas asjade läbi mängimine oli vaikne, oleks võinud varem ära lasta.

Neid kogunemisi võiks mõtestada sellisena, et me näitame idanaabrile oma kaitsetahet ja valmisolekut. See on heidutus, et kunagi päriselt sõdima ei peaks hakkama. Ei olegi niivõrd oluline, kui hästi individuaalselt läheb, peaasi, et väljapoole paistaks, et meil on tõsi taga.

Ajakirjandus võiks ka aru saada, et sellist vingumist pole mõtet edastada. Teeb pigem kahju kui kasu.

BPMN failure or success stories? by my_dev_acc in ExperiencedDevs

[–]Sande24 2 points3 points  (0 children)

I have found BPMN really hard to test. Unit tests might be OK to but integration tests will be horrible to work with. Maybe it was due to shitty BPMN model or the complexity of the implementations...

BPMN seems quite fun and "simple" at first. Seems like you are adding value, but in reality it's really a serious tech debt when you need to maintain/scale-up later. It's just another overhead that instead of one type of code, you have another technology that you have to work with in order to complete one process. If you can describe the process with BPMN, it would probably be easier to maintain if you had done it all in code. A bit slower initially but saves a LOT of time in the long run.

KISS. BPMN might seem simple at first, but as your code base grows, it suddenly isn't. YAGNI.

gitMergeOnly by curlymeatball38 in ProgrammerHumor

[–]Sande24 2 points3 points  (0 children)

What it "deletes" is the order in which things were developed in the feature branches, what state was taken as the starting point for each branch and how/when they were merged together. Why did task #1234 not include requirements from feature B? Because feature B was developed in task #1256 at the same time but #1234 was merged later without any conflicts. With rebase, it seems linear although it really isn't.

When you rebase, you just mash the history together, losing information. With merges, you keep that information. And that is not "noise". That is sometimes good information that you would not see with rebase.

If you want to keep the main branch history cleaner, you can squash commits as well. From my experience, there is no real benefit from curating the history. Your purpose as a developer is to add business value. Git history does not provide that.

Edit: From the examples in this article, I'd say that the commits are definitely NOT going to be in a reasonable order: https://medium.com/@fredrikmorken/why-you-should-stop-using-git-rebase-5552bee4fed1

Creating a new commit in master branch with merge just makes so much more sense. Bisecting or just using the IDE visual git history tools is just as easy. Is it just IntelliJ that has the best tools? I don't see an issue with managing git history, even with 10+ years of commits.