diff --git a/content/notes/first-it-must-work/index.md b/content/notes/first-it-must-work/index.md new file mode 100644 index 0000000..59b4d8d --- /dev/null +++ b/content/notes/first-it-must-work/index.md @@ -0,0 +1,20 @@ +--- +title: "First, It Must Work" +date: 2023-05-11T23:00:26-04:00 +draft: false +references: +- title: "The Grug Brained Developer" + url: https://grugbrain.dev/ + date: 2023-05-12T13:08:33Z + file: grugbrain-dev-dzqozx.txt +--- + +### Thoughts on priorities in software development + +* So much stuff doesn't work -- bugs stop you from accomplishing your desired task +* Over time, complexity creeps in, making changes gets harder +* Focus on performance, serverless, microservices, etc. -- increase complexity, reduce reliability +* [The Grug Brained Developer][1] + +[1]: https://grugbrain.dev/ + diff --git a/content/notes/misc/index.md b/content/notes/misc/index.md index a12addd..b26b1c0 100644 --- a/content/notes/misc/index.md +++ b/content/notes/misc/index.md @@ -1,8 +1,5 @@ --- title: "Misc." date: 2023-05-11T23:00:26-04:00 -draft: false +draft: true --- - -* "First, it must work" - * Thoughts on priorities in software development diff --git a/static/archive/grugbrain-dev-dzqozx.txt b/static/archive/grugbrain-dev-dzqozx.txt new file mode 100644 index 0000000..5f0143f --- /dev/null +++ b/static/archive/grugbrain-dev-dzqozx.txt @@ -0,0 +1,855 @@ + [1]grug + +The Grug Brained Developer +A layman's guide to thinking like the self-aware smol brained + + Introduction + + this collection of thoughts on software development gathered by grug + brain developer + + grug brain developer not so smart, but grug brain developer program + many long year and learn some things although mostly still confused + + grug brain developer try collect learns into small, easily digestible + and funny page, not only for you, the young grug, but also for him + because as grug brain developer get older he forget important things, + like what had for breakfast or if put pants on + + big brained developers are many, and some not expected to like this, + make sour face + + THINK they are big brained developers many, many more, and more even + definitely probably maybe not like this, many sour face (such is + internet) + + (note: grug once think big brained but learn hard way) + + is fine! + + is free country sort of and end of day not really matter too much, but + grug hope you fun reading and maybe learn from many, many mistake grug + make over long program life + + [2]The Eternal Enemy: Complexity + + apex predator of grug is complexity + + complexity bad + + say again: + + complexity very bad + + you say now: + + complexity very, very bad + + given choice between complexity or one on one against t-rex, grug take + t-rex: at least grug see t-rex + + complexity is spirit demon that enter codebase through well-meaning but + ultimately very clubbable non grug-brain developers and project + managers who not fear complexity spirit demon or even know about + sometime + + one day code base understandable and grug can get work done, everything + good! + + next day impossible: complexity demon spirit has entered code and very + dangerous situation! + + grug no able see complexity demon, but grug sense presence in code base + + demon complexity spirit mocking him make change here break unrelated + thing there what!?! mock mock mock ha ha so funny grug love programming + and not becoming shiney rock speculator like grug senior advise + + club not work on demon spirit complexity and bad idea actually hit + developer who let spirit in with club: sometimes grug himself! + + sadly, often grug himself + + so grug say again and say often: complexity very, very bad + +[3]Saying No + + best weapon against complexity spirit demon is magic word: "no" + + "no, grug not build that feature" + + "no, grug not build that abstraction" + + "no, grug not put water on body every day or drink less black think + juice you stop repeat ask now" + + note, this good engineering advice but bad career advice: "yes" is + magic word for more shiney rock and put in charge of large tribe of + developer + + sad but true: learn "yes" then learn blame other grugs when fail, ideal + career advice + + but grug must to grug be true, and "no" is magic grug word. Hard say at + first, especially if you nice grug and don't like disappoint people + (many such grugs!) but easier over time even though shiney rock pile + not as high as might otherwise be + + is ok: how many shiney rock grug really need anyway? + +[4]Saying ok + + sometimes compromise necessary or no shiney rock, mean no dinosaur + meat, not good, wife firmly remind grug about young grugs at home need + roof, food, and so forth, no interest in complexity demon spirit rant + by grug for fiftieth time + + in this situation, grug recommend "ok" + + "ok, grug build that feature" + + then grug spend time think of [5]80/20 solution to problem and build + that instead. + 80/20 solution say "80 want with 20 code" solution maybe not have all + bell-whistle that project manager want, maybe a little ugly, but work + and deliver most value, and keep demon complexity spirit at bay for + most part to extent + + sometimes probably best just not tell project manager and do it 80/20 + way. easier forgive than permission, project managers mind like + butterfly at times overworked and dealing with many grugs. often forget + what even feature supposed to do or move on or quit or get fired grug + see many such cases + + anyway is in project managers best interest anyway so grug not to feel + too bad for this approach usually + +[6]Factoring Your Code + + next strategy very harder: break code base up properly (fancy word: + "factor your code properly") here is hard give general advice because + each system so different. however, one thing grug come to believe: not + factor your application too early! + + early on in project everything very abstract and like water: very + little solid holds for grug's struggling brain to hang on to. take time + to develop "shape" of system and learn what even doing. grug try not to + factor in early part of project and then, at some point, good + cut-points emerge from code base + + good cut point has narrow interface with rest of system: small number + of functions or abstractions that hide complexity demon internally, + like trapped in crystal + + grug quite satisfied when complexity demon trapped properly in crystal, + is best feeling to trap mortal enemy! + + grug try watch patiently as cut points emerge from code and slowly + refactor, with code base taking shape over time along with experience. + no hard/ fast rule for this: grug know cut point when grug see cut + point, just take time to build skill in seeing, patience + + sometimes grug go too early and get abstractions wrong, so grug bias + towards waiting + + big brain developers often not like this at all and invent many + abstractions start of project + + grug tempted to reach for club and yell "big brain no maintain code! + big brain move on next architecture committee leave code for grug deal + with!" + + but grug learn control passions, major difference between grug and + animal + + instead grug try to limit damage of big brain developer early in + project by giving them thing like UML diagram (not hurt code, probably + throw away anyway) or by demanding working demo tomorrow + + working demo especially good trick: force big brain make something to + actually work to talk about and code to look at that do thing, will + help big brain see reality on ground more quickly + + remember! big brain have big brain! need only be harness for good and + not in service of spirit complexity demon on accident, many times seen + + (best grug brain able to herd multiple big brain in right direction and + produce many complexity demon trap crystals, large shiney rock pile + awaits such grug!) + + also sometimes call demo approach "prototype", sound fancier to project + manager + + grug say prototype early in software making, especially if many big + brains + + [7]Testing + + grug have love/hate relationship with test: test save grug many, many + uncountable time and grug love and respect test + + unfortunately also many test shamans exist. some test shaman make test + idol, demand things like "first test" before grug even write code or + have any idea what grug doing domain! + + how grug test what grug not even understand domain yet!? + + "Oh, don't worry: the tests will show you what you need to do." + + grug once again catch grug slowly reaching for club, but grug stay calm + + grug instead prefer write most tests after prototype phase, when code + has begun firm up + + but, note well: grug must here be very disciplined! + + easy grug to move on and not write tests because "work on grugs + machine"! + + this very, very bad: no guarantee work on other machine and no + guarantee work on grug machine in future, many times + + test shaman have good point on importance of test, even if test shaman + often sometimes not complete useful feature in life and talk only about + test all time, deserve of club but heart in right place + + also, test shaman often talk unit test very much, but grug not find so + useful. grug experience that ideal tests are not unit test or either + end-to-end test, but in-between test + + [8]unit tests fine, ok, but break as implementation change (much + compared api!) and make refactor hard and, frankly, many bugs anyway + often due interactions other code. often throw away when code change. + + grug write unit test mostly at start of project, help get things going + but not get too attached or expect value long time + + [9]end to end tests good, show whole system work, but! hard to + understand when break and drive grug crazy very often, sometimes grugs + just end up ignoring because "oh, that break all time" very bad! + + in-between tests, grug hear shaman call [10]"integration tests" + sometime often with sour look on face. but grug say integration test + sweet spot according to grug: high level enough test correctness of + system, low level enough, with good debugger, easy to see what break + + grug prefer some unit tests especially at start but not 100% all code + test and definitely not "first test". "test along the way" work pretty + well for grug, especially as grug figure things out + + grug focus much ferocious integration test effort as cut point emerge + and system stabilize! cut point api hopefully stable compared + implementation and integration test remain valuable many long time, and + easy debug + + also small, well curated end-to-end test suite is created to be kept + working religiously on pain of clubbing. focus of important end-to-end + test on most common UI features and few most important edge cases, but + not too many or become impossible maintain and then ignored + + this ideal set of test to grug + + you may not like, but this peak grug testing + + also, grug dislike [11]mocking in test, prefer only when absolute + necessary to (rare/never) and coarse grain mocking (cut points/systems) + only at that + + one exception "first test" dislike by grug: when bug found. grug always + try first reproduce bug with regression test then fix bug, this case + only for some reason work better + + [12]Agile + + grug think agile not terrible, not good + + end of day, not worst way to organize development, maybe better than + others grug supposes is fine + + danger, however, is agile shaman! many, many shiney rock lost to agile + shaman! + + whenever agile project fail, agile shaman say "you didn't do agile + right!" grug note this awfully convenient for agile shaman, ask more + shiney rock better agile train young grugs on agile, danger! + + grug tempted reach for club when too much agile talk happen but always + stay calm + + prototyping, tools and hiring good grugs better key to success + software: agile process ok and help some but sometimes hurt taken too + seriously + + grug say [13]no silver club fix all software problems no matter what + agile shaman say (danger!) + + [14]Refactoring + + refactoring fine activity and often good idea, especially later in + project when code firmed up + + however, grug note that many times in career "refactors" go horribly + off rails and end up causing more harm than good + + grug not sure exactly why some refactors work well, some fail, but grug + notice that larger refactor, more likely failure appear to be + + so grug try to keep refactors relatively small and not be "too far out + from shore" during refactor. ideally system work entire time and each + step of finish before other begin. + + end-to-end tests are life saver here, but often very hard understand + why broke... such is refactor life. + + also grug notice that introducing too much abstraction often lead to + refactor failure and system failure. good example was [15]J2EE + introduce, many big brain sit around thinking too much abstraction, + nothing good came of it many project hurt + + another good example when company grug work for introduce [16]OSGi to + help manage/trap spriit complexity demon in code base. not only OSGi + not help, but make complexity demon much more powerful! took multiple + man year of best developers to rework as well to boot! more complex + spirit and now features impossible implement! very bad! + + [17]Chesterton's Fence + + wise grug shaman [18]chesterton once say + + here exists in such a case a certain institution or law; let us say, + for the sake of simplicity, a fence or gate erected across a road. + The more modern type of reformer goes gaily up to it and says, “I + don’t see the use of this; let us clear it away.” To which the more + intelligent type of reformer will do well to answer: “If you don’t + see the use of it, I certainly won’t let you clear it away. Go away + and think. Then, when you can come back and tell me that you do see + the use of it, I may allow you to destroy it.” + + many older grug learn this lesson well not start tearing code out willy + nilly, no matter how ugly look + + grug understand all programmer platonists at some level wish music of + spheres perfection in code. but danger is here, world is ugly and + gronky many times and so also must code be + + humility not often come big brained or think big brained easily or grug + even, but grug often find "oh, grug no like look of this, grug fix" + lead many hours pain grug and no better or system worse even + + grug early on in career often charge into code base waving club wildly + and smash up everything, learn not good + + grug not say no improve system ever, quite foolish, but recommend take + time understand system first especially bigger system is and is respect + code working today even if not perfect + + here tests often good hint for why fence not to be smashed! + + [19]Microservices + + grug wonder why big brain take hardest problem, factoring system + correctly, and introduce network call too + + seem very confusing to grug + + [20]Tools + + grug love tool. tool and control passion what separate grug from + dinosaurs! tool allow grug brain to create code that not possible + otherwise by doing thinking for grug, always good relief! grug always + spend time in new place learning tools around him to maximize + productivity: learn tools for two weeks make development often twice + faster and often have dig around ask other developers help, no docs + + code completion in IDE allow grug not have remembered all API, very + important! + + java programming nearly impossible without it for grug! + + really make grug think some time + + good debugger worth weight in shiney rocks, in fact also more: when + faced with bug grug would often trade all shiney rock and perhaps few + children for good debugger and anyway debugger no weigh anything far as + grug can tell + + grug always recommend new programmer learn available debugger very + deeply, features like conditional break points, expression evaluation, + stack navigation, etc teach new grug more about computer than + university class often! + + grug say never be not improving tooling + + [21]Type Systems + + grug very like type systems make programming easier. for grug, type + systems most value when grug hit dot on keyboard and list of things + grug can do pop up magic. this 90% of value of type system or more to + grug + + big brain type system shaman often say type correctness main point type + system, but grug note some big brain type system shaman not often ship + code. grug suppose code never shipped is correct, in some sense, but + not really what grug mean when say correct + + grug say tool magic pop up of what can do and complete of code major + most benefit of type system, correctness also good but not so nearly so + much + + also, often sometimes caution beware big brains here! + + some type big brain think in type systems and talk in lemmas, potential + danger! + + danger abstraction too high, big brain type system code become astral + projection of platonic generic turing model of computation into code + base. grug confused and agree some level very elegant but also very + hard do anything like record number of club inventory for Grug Inc. + task at hand + + generics especially dangerous here, grug try limit generics to + container classes for most part where most value add + + temptation generics very large is trick! spirit demon complex love this + one trick! beware! + + always most value type system come: hit dot see what grug can do, never + forget! + + [22]Expression Complexity + + grug once like to minimize lines of code much as possible. write code + like this: + if(contact && !contact.isActive() && (contact.inGroup(FAMILY) || contact.inGro +up(FRIENDS))) { + // ... + } + + over time grug learn this hard debug, learn prefer write like so: + if(contact) { + var contactIsInactive = !contact.isActive(); + var contactIsFamilyOrFriends = contact.inGroup(FAMILY) || contact.inGroup(FR +IENDS); + if(contactIsInactive && contactIsFamilyOrFriends) { + // ... + } + } + + grug hear screams from young grugs at horror of many line of code and + pointless variable and grug prepare defend self with club + + club fight start with other developers attack and grug yell: "easier + debug! see result of each expression more clearly and good name! easier + understand conditional expression! EASIER DEBUG!" + + definitely easier debug and once club fight end calm down and young + grug think a bit, they realize grug right + + grug still catch grug writing code like first example and often regret, + so grug not judge young grug + + [23]DRY + + [24]DRY mean Don't Repeat Self, powerful maxim over mind of most + developers + + grug respect DRY and good advice, however grug recommend balance in all + things, as gruggest big brain aristotle recommend + + grug note humourous graph by Lea Verou correspond with grug passion not + repeat: + code concerns over time + + over time past ten years program grug not as concerned repeat code. so + long as repeat code simple enough and obvious enough, and grug begin + feel repeat/copy paste code with small variation is better than many + callback/closures passed arguments or elaborate object model: too hard + complex for too little benefit at times + + hard balance here, repeat code always still make grug stare and say + "mmm" often, but experience show repeat code sometimes often better + than complex DRY solution + + note well! grug encourage over literal developer not take does work + line too serious, is joke + + [25]Separation of Concerns (SoC) + + [26]Separation of Concern (SoC) another powerful idea over many + developer mind, idea to separate different aspects of system into + distinct sections code + + canonical example from web development: separation of style (css file), + markup (html file) and logic (javascript file) + + here grug much more sour faced than DRY and in fact write big brained + essay on alternative design principle [27]locality of behavior (LoB) + against SoC + + grug much prefer put code on the thing that do the thing. now when grug + look at the thing grug know the thing what the thing do, alwasy good + relief! + + when separate of concern grug must often all over tarnation many file + look understand what how button do, much confuse and time waste: bad! + + [28]Closures + + grug like closures for right job and that job usually abstracting + operation over collection of objects + + grug warn closures like salt, type systems and generics: small amount + go long way, but easy spoil things too much use give heart attack + + javascript developers call very special complexity demon spirit in + javascript "callback hell" because too much closure used by javascript + libraries very sad but also javascript developer get what deserved let + grug be frank + + [29]Logging + + grug huge fan of logging and encourage lots of it, especially in cloud + deployed. some non-grugs say logging expensive and not important. grug + used think this way no more + + funny story: grug learn idol [30]rob pike working on logging at google + and decide: "if rob pike working on logging, what grug do there?!?" so + not pursue. turn out logging very important to google so of course best + programmer work on it, grug! + + don't be such grug brain, grug, much less shiney rock now! + + oh well, grug end up at good company anyway and rob pike dress habit + [31]increasingly erratic, so all work out in end, but point stand: + logging very important! + + grug tips on logging are: + * log all major logical branches within code (if/for) + * if "request" span multiple machine in cloud infrastructure, include + request ID in all so logs can be grouped + * if possible make log level dynamically controlled, so grug can turn + on/off when need debug issue (many!) + * if possible make log level per user, so can debug specific user + issue + + last two points are especially handy club when fighting bugs in + production systems very often + + unfortunately log libraries often very complex (java, [32]why you do?) + but worth investing time in getting logging infrastructure "just right" + pay off big later in grug experience + + logging need taught more in schools, grug think + + [33]Concurrency + + grug, like all sane developer, fear concurrency + + as much as possible, grug try to rely on simple concurrency models like + stateless web request handlers and simple remote job worker queues + where jobs no interdepend and simple api + + [34]optimistic concurrency seem work well for web stuff + + occasionally grug reach for [35]thread local variable, usually when + writing framework code + + some language have good concurrent data structure, like java + [36]ConcurrentHashMap but still need careful grug work to get right + + grug has never used [37]erlang, hear good things, but language look + wierd to grug sorry + + [38]Optimizing + + ultra biggest of brain developer once say: + + premature optimization is the root of all evil + + this everyone mostly know and grug in humble violent agreement with + ultra biggest of big brain + + grug recommend always to have concrete, real world perf profile showing + specific perf issue before begin optimizing. + + never know what actual issue might be, grug often surprise! very often! + + beware only cpu focus: easy to see cpu and much big o notation thinking + having been done in school, but often not root of all slowness, + surprise to many including grug + + hitting network equivalent of many, many millions cpu cycle and always + to be minimized if possible, note well big brain microservice + developer! + + inexperienced big brain developer see nested loop and often say + "O(n^2)? Not on my watch!" + + complexity demon spirit smile + + [39]APIs + + grug love good apis. good apis not make grug think too much + + unfortunately, many apis very bad, make grug think quite a bit. this + happen many reasons, here two: + * API creators think in terms of implementation or domain of API, + rather than in terms of use of API + * API creators think too abstract and big brained + + usually grug not care too deeply about detail of api: want write file + or sort list or whatever, just want to call write() or sort() or + whatever + + but big brain api developers say: + + "not so fast, grug! is that file open for write? did you define a + Comparator for that sort?" + + grug find self restraining hand reaching for club again + + not care about that stuff right now, just want sort and write file mr + big brain! + + grug recognize that big brain api designer have point and that sometime + these things matter, but often do not. big brain api developers better + if design for simple cases with simple api, make complex cases possible + with more complex api + + grug call this "layering" apis: two or three different apis at + different level complexity for various grug needs + + also, if object oriented, put api on thing instead of elsewhere. java + worst at this! + + grug want filter list in java + + "Did you convert it to a stream?" + + fine, grug convert to stream + + "OK, now you can filter." + + OK, but now need return list! have stream! + + "Well, did you collect your stream into a list?" + + what? + + "Define a Collector to collect your stream into a + list" + + grug now swear on ancestor grave he club every single person in room, + but count two instead and remain calm + + put common thing like filter() on list and make return list, listen + well big brain java api developer! + + nobody care about "stream" or even hear of "stream" before, is not + networking api, all java grugs use list mr big brain! + + [40]Parsing + + grug love make programming language at drop of hat and say + [41]recursive descent most fun and beautiful way create parser + + unfortunately many big brain school teach only parser generator tool. + here grug usual love of tool is not: parser generator tool generate + code of awful snakes nest: impossible understand, bottom up, what? hide + recursive nature of grammar from grug and debug impossible, very bad + according grug! + + grug think this because while complexity demon bad for code base and + understand, complexity demon very good for generation of much academic + papers, sad but true + + production parser almost always recursive descent, despite ignore by + schools! grug furious when learn how simple parse is! parsing not big + brain only magic: so can you! + + grug very elated find big brain developer Bob Nystrom redeem the big + brain tribe and write excellent book on recursive descent: [42]Crafting + Interpreters + + book available online free, but grug highly recommend all interested + grugs purchase book on general principle, provide much big brain advice + and grug love book very much except visitor pattern (trap!) + + [43]The Visitor Pattern + + [44]bad + + [45]Front End Development + + some non-grugs, when faced with web development say: + + "I know, I'll split my front end and back end codebase up and use a hot + new SPA library talking to a GraphQL JSON API back end over HTTP (which + is funny because I'm not transferring hypertext)" + + now you have two complexity demon spirit lairs + + and, what is worse, front end complexity demon spirit even more + powerful and have deep spiritual hold on entire front end industry as + far as grug can tell + + back end developers try keep things simple and can work ok, but front + end developers make very complex very quickly and introduce lots of + code, demon complex spirit + + even when website just need put form into database or simple brochure + site! + + everyone do this now! + + grug not sure why except maybe facebook and google say so, but that not + seem very good reason to grug + + grug not like big complex front end libraries everyone use + + grug make [46]htmx and [47]hyperscript to avoid + + keep complexity low, simple HTML, avoid lots javascript, the natural + ether of spirit complexity demon + + maybe they work for you, but no job post, sorry + + react better for job and also some type application, but also you + become alcolyte of complexity demon whether you like or no, sorry such + is front end life + + [48]Fads + + grug note lots of fads in development, especially front end development + today + + back end better more boring because all bad ideas have tried at this + point maybe (still retry some!) + + still trying all bad ideas in front end development so still much + change and hard to know + + grug recommend taking all revolutionary new approach with grain salt: + big brains have working for long time on computers now, most ideas have + tried at least once + + grug not saying can't learn new tricks or no good new ideas, but also + much of time wasted on recycled bad ideas, lots of spirit complexity + demon power come from putting new idea willy nilly into code base + + [49]Fear Of Looking Dumb + + note! very good if senior grug willing to say publicly: "hmmm, this too + complex for grug"! + + many developers Fear Of Looking Dumb (FOLD), grug also at one time + FOLD, but grug learn get over: very important senior grug say "this too + complicated and confuse to me" + + this make it ok for junior grugs to admit too complex and not + understand as well, often such case! FOLD major source of complexity + demon power over developer, especially young grugs! + + take FOLD power away, very good of senior grug! + + note: important to make thinking face and look big brained when saying + though. be prepare for big brain or, worse and much more common, thinks + is big brain to make snide remark of grug + + be strong! no FOLD! + + club sometimes useful here, but more often sense of humor and + especially last failed project by big brain very useful, so collect and + be calm + + [50]Impostor Syndrome + + grug note many such impostor feels in development + + always grug one of two states: grug is ruler of all survey, wield code + club like thor OR grug have no idea what doing + + grug is mostly latter state most times, hide it pretty well though + + now, grug make softwares of much work and [51]moderate open source + success , and yet grug himself often feel not any idea what doing! very + often! grug still fear make mistake break everyone code and disappoint + other grugs, imposter! + + is maybe nature of programming for most grug to feel impostor and be ok + with is best: nobody imposter if everybody imposter + + any young grug read this far probably do fine in program career even if + frustrations and worry is always to be there, sorry + + [52]Reads + + grug like these: + * [53]Worse is Better + * [54]Worse is Better is Worse + * [55]Is Worse Really Better? + * [56]A Philosophy of Software Design + + [57]Conclusion + + you say: complexity very, very bad + +References + + 1. https://www.redbubble.com/i/sticker/Programmer-Grug-by-colossalbreaker/42915272.EJUG5 + 2. https://grugbrain.dev/#grug-on-complexity + 3. https://grugbrain.dev/#grug-on-saying-no + 4. https://grugbrain.dev/#grug-on-saying-ok + 5. https://en.wikipedia.org/wiki/Pareto_principle + 6. https://grugbrain.dev/#grug-on-factring-your-code + 7. https://grugbrain.dev/#grug-on-testing + 8. https://en.wikipedia.org/wiki/Unit_testing + 9. https://smartbear.com/solutions/end-to-end-testing/ + 10. https://en.wikipedia.org/wiki/Integration_testing + 11. https://en.wikipedia.org/wiki/Mock_object + 12. https://grugbrain.dev/#grug-on-agile + 13. https://en.wikipedia.org/wiki/No_Silver_Bullet + 14. https://grugbrain.dev/#grug-on-refactoring + 15. https://www.webopedia.com/definitions/j2ee/ + 16. https://www.techtarget.com/searchnetworking/definition/OSGi + 17. https://grugbrain.dev/#grug-on-chestertons-fence + 18. https://en.wikipedia.org/wiki/G._K._Chesterton + 19. https://grugbrain.dev/#grug-on-microservices + 20. https://grugbrain.dev/#grug-on-tools + 21. https://grugbrain.dev/#grug-on-type-systems + 22. https://grugbrain.dev/#grug-on-expression-complexity + 23. https://grugbrain.dev/#grug-on-dry + 24. https://en.wikipedia.org/wiki/Don't_repeat_yourself + 25. https://grugbrain.dev/#grug-on-soc + 26. https://en.wikipedia.org/wiki/Separation_of_concerns + 27. https://htmx.org/essays/locality-of-behaviour/ + 28. https://grugbrain.dev/#grug-on-closures + 29. https://grugbrain.dev/#grug-on-logging + 30. https://en.wikipedia.org/wiki/Rob_Pike + 31. https://www.youtube.com/watch?v=KINIAgRpkDA + 32. https://stackify.com/logging-java/ + 33. https://grugbrain.dev/#grug-on-concurrency + 34. https://en.wikipedia.org/wiki/Optimistic_concurrency_control + 35. https://en.wikipedia.org/wiki/Thread-local_storage + 36. https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html + 37. https://en.wikipedia.org/wiki/Erlang_(programming_language) + 38. https://grugbrain.dev/#grug-on-optimizing + 39. https://grugbrain.dev/#grug-on-apis + 40. https://grugbrain.dev/#grug-on-parsing + 41. https://en.wikipedia.org/wiki/Recursive_descent_parser + 42. https://craftinginterpreters.com/ + 43. https://grugbrain.dev/#grug-on-visitor-pattern + 44. https://en.wikipedia.org/wiki/Visitor_pattern + 45. https://grugbrain.dev/#grug-on-front-end-development + 46. https://htmx.org/ + 47. https://hyperscript.org/ + 48. https://grugbrain.dev/#grug-on-fads + 49. https://grugbrain.dev/#grug-on-fold + 50. https://grugbrain.dev/#grug-on-imposter-syndrom + 51. https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date + 52. https://grugbrain.dev/#grug-reads + 53. https://www.dreamsongs.com/WorseIsBetter.html + 54. https://www.dreamsongs.com/Files/worse-is-worse.pdf + 55. https://www.dreamsongs.com/Files/IsWorseReallyBetter.pdf + 56. https://www.goodreads.com/en/book/show/39996759-a-philosophy-of-software-design + 57. https://grugbrain.dev/#lol-lmao