\n\n# Introduction\n\nthis collection of thoughts on software development gathered by grug brain developer\n\ngrug brain developer not so smart, but grug brain developer program many long year and learn some things\nalthough mostly still confused\n\ngrug brain developer try collect learns into small, easily digestible and funny page, not only for you, the young grug, but also for him\nbecause as grug brain developer get older he forget important things, like what had for breakfast or if put pants on\n\nbig brained developers are many, and some not expected to like this, make sour face\n\n*THINK* they are big brained developers many, many more, and more even definitely probably maybe not like this, many\nsour face (such is internet)\n\n(note: grug once think big brained but learn hard way)\n\nis fine!\n\nis free country sort of and end of day not really matter too much, but grug hope you fun reading and maybe learn from\n many, many mistake grug make over long program life\n\n# [The Eternal Enemy: Complexity](#grug-on-complexity)\n\napex predator of grug is complexity\n\ncomplexity bad\n\nsay again:\n\ncomplexity *very* bad\n\n_you_ say now:\n\ncomplexity *very*, *very* bad\n\ngiven choice between complexity or one on one against t-rex, grug take t-rex: at least grug see t-rex\n\ncomplexity is spirit demon that enter codebase through well-meaning but ultimately very clubbable non grug-brain\ndevelopers and project managers who not fear complexity spirit demon or even know about sometime\n\none day code base understandable and grug can get work done, everything good!\n\nnext day impossible: complexity demon spirit has entered code and very dangerous situation! \n\ngrug no able see complexity demon, but grug sense presence in code base\n\ndemon complexity spirit mocking him make change here break unrelated thing there what!?! mock mock mock ha ha so funny \ngrug love programming and not becoming shiney rock speculator like grug senior advise\n\nclub not work on demon spirit complexity and bad idea actually hit developer who let spirit in with club: sometimes grug\nhimself!\n\nsadly, often grug himself\n\nso grug say again and say often: complexity *very*, *very* bad\n\n## [Saying No](#grug-on-saying-no)\n\nbest weapon against complexity spirit demon is magic word: \"no\"\n\n\"no, grug not build that feature\"\n\n\"no, grug not build that abstraction\"\n\n\"no, grug not put water on body every day or drink less black think juice you stop repeat ask now\"\n\nnote, this good engineering advice but bad career advice: \"yes\" is magic word for more shiney rock and put in\ncharge of large tribe of developer\n\nsad but true: learn \"yes\" then learn blame other grugs when fail, ideal career advice\n\nbut 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\ndisappoint people (many such grugs!) but easier over time even though shiney rock pile not as high as might otherwise be\n\nis ok: how many shiney rock grug really need anyway?\n\n## [Saying ok](#grug-on-saying-ok)\n\nsometimes compromise necessary or no shiney rock, mean no dinosaur meat, not good, wife firmly remind grug\nabout young grugs at home need roof, food, and so forth, no interest in complexity demon spirit rant by grug for\nfiftieth time\n\nin this situation, grug recommend \"ok\"\n\n\"ok, grug build that feature\"\n\nthen grug spend time think of [80/20 solution](https://en.wikipedia.org/wiki/Pareto_principle) to problem and build that instead. \n80/20 solution say \"80 want with 20 code\" solution maybe not have all bell-whistle that project manager want, maybe a \nlittle ugly, but work and deliver most value, and keep demon complexity spirit at bay for most part to extent\n\nsometimes probably best just not tell project manager and do it 80/20 way. easier forgive than permission, project managers\nmind like butterfly at times overworked and dealing with many grugs. often forget what even feature supposed to do or move on or \nquit or get fired grug see many such cases\n\nanyway is in project managers best interest anyway so grug not to feel too bad for this approach usually\n\n## [Factoring Your Code](#grug-on-factring-your-code)\n\nnext strategy very harder: break code base up properly (fancy word: \"factor your code properly\") here is hard give general\nadvice because each system so different. however, one thing grug come to believe: not factor your application too early!\n\nearly on in project everything very abstract and like water: very little solid holds for grug's struggling brain to hang \non to. take time to develop \"shape\" of system and learn what even doing. grug try not to factor in early part of project\nand then, at some point, good cut-points emerge from code base\n\ngood cut point has narrow interface with rest of system: small number of functions or abstractions that hide complexity\ndemon internally, like trapped in crystal\n\ngrug quite satisfied when complexity demon trapped properly in crystal, is best feeling to trap mortal enemy!\n\ngrug try watch patiently as cut points emerge from code and slowly refactor, with code base taking shape over time along\nwith experience. no hard/ fast rule for this: grug know cut point when grug see cut point, just take time to build \nskill in seeing, patience\n\nsometimes grug go too early and get abstractions wrong, so grug bias towards waiting\n\nbig brain developers often not like this at all and invent many abstractions start of project\n\ngrug tempted to reach for club and yell \"big brain no maintain code! big brain move on next architecture committee\nleave code for grug deal with!\"\n\nbut grug learn control passions, major difference between grug and animal\n\ninstead grug try to limit damage of big brain developer early in project by giving them thing like\nUML diagram (not hurt code, probably throw away anyway) or by demanding working demo tomorrow\n\nworking demo especially good trick: force big brain make something to actually work to talk about and code to look at that do\nthing, will help big brain see reality on ground more quickly\n\nremember! big brain have big brain! need only be harness for good and not in service of spirit complexity demon on \naccident, many times seen\n\n(best grug brain able to herd multiple big brain in right direction and produce many complexity demon trap crystals, large\nshiney rock pile awaits such grug!)\n\nalso sometimes call demo approach \"prototype\", sound fancier to project manager\n\ngrug say prototype early in software making, _especially_ if many big brains\n\n# [Testing](#grug-on-testing)\n\ngrug have love/hate relationship with test: test save grug many, many uncountable time and grug love and respect test \n\nunfortunately also many test shamans exist. some test shaman make test idol, demand things like \"first test\" before grug\neven write code or have any idea what grug doing domain! \n\nhow grug test what grug not even understand domain yet!?\n\n\"Oh, don't worry: the tests will show you what you need to do.\"\n\ngrug once again catch grug slowly reaching for club, but grug stay calm\n\ngrug instead prefer write most tests after prototype phase, when code has begun firm up\n\nbut, note well: grug must here be very disciplined! \n\neasy grug to move on and not write tests because \"work on grugs machine\"!\n\nthis very, very bad: no guarantee work on other machine and no guarantee work on grug machine in future, many times\n\ntest shaman have good point on importance of test, even if test shaman often sometimes not complete useful\nfeature in life and talk only about test all time, deserve of club but heart in right place\n\nalso, test shaman often talk unit test very much, but grug not find so useful. grug experience that ideal tests are not \nunit test or either end-to-end test, but in-between test\n\n[unit tests](https://en.wikipedia.org/wiki/Unit_testing) fine, ok, but break as implementation change (much compared api!)\nand make refactor hard and, frankly, many bugs anyway often due interactions other code. often throw away when code change. \n\ngrug write unit test mostly at start of project, help get things going but not get too attached or expect value long time\n\n[end to end](https://smartbear.com/solutions/end-to-end-testing/) tests good, show whole system work, but! hard to \nunderstand when break and drive grug crazy very often, sometimes grugs just end up ignoring because \"oh, that break all \ntime\" very bad!\n\nin-between tests, grug hear shaman call [\"integration tests\"](https://en.wikipedia.org/wiki/Integration_testing) sometime \noften with sour look on face. but grug say integration test sweet spot according to grug: high level enough test correctness \nof system, low level enough, with good debugger, easy to see what break\n\ngrug prefer some unit tests especially at start but not 100% all code test and definitely not \"first test\". \"test along\nthe way\" work pretty well for grug, especially as grug figure things out\n\ngrug focus much ferocious integration test effort as cut point emerge and system stabilize! cut point api hopefully stable\ncompared implementation and integration test remain valuable many long time, and easy debug\n\nalso small, well curated end-to-end test suite is created to be kept working religiously on pain of clubbing. focus of important \nend-to-end test on most common UI features and few most important edge cases, but not too many or become impossible maintain\nand then ignored\n\nthis ideal set of test to grug\n\nyou may not like, but this peak grug testing\n\nalso, grug dislike [mocking](https://en.wikipedia.org/wiki/Mock_object) in test, prefer only when absolute necessary\nto (rare/never) and coarse grain mocking (cut points/systems) only at that\n\none exception \"first test\" dislike by grug: when bug found. grug always try first reproduce bug with regression test \n_then_ fix bug, this case only for some reason work better\n\n# [Agile](#grug-on-agile)\n\ngrug think agile not terrible, not good\n\nend of day, not worst way to organize development, maybe better than others grug supposes is fine\n\ndanger, however, is agile shaman! many, many shiney rock lost to agile shaman!\n\nwhenever agile project fail, agile shaman say \"you didn't do agile right!\" grug note this awfully convenient for agile\nshaman, ask more shiney rock better agile train young grugs on agile, danger!\n\ngrug tempted reach for club when too much agile talk happen but always stay calm\n\nprototyping, tools and hiring good grugs better key to success software: agile process ok and help some but sometimes hurt taken\ntoo seriously\n\ngrug say [no silver club](https://en.wikipedia.org/wiki/No_Silver_Bullet) fix all software problems no matter what agile\nshaman say (danger!)\n\n# [Refactoring](#grug-on-refactoring)\n\nrefactoring fine activity and often good idea, especially later in project when code firmed up\n\nhowever, grug note that many times in career \"refactors\" go horribly off rails and end up causing more harm than good\n\ngrug not sure exactly why some refactors work well, some fail, but grug notice that larger refactor, more\nlikely failure appear to be\n\nso grug try to keep refactors relatively small and not be \"too far out from shore\" during refactor. ideally system work\nentire time and each step of finish before other begin. \n\nend-to-end tests are life saver here, but often very hard understand why broke... such is refactor life.\n\nalso grug notice that introducing too much abstraction often lead to refactor failure and system failure. good example\nwas [J2EE](https://www.webopedia.com/definitions/j2ee/) introduce, many big brain sit around thinking too much abstraction, nothing good came of it many project hurt\n\nanother good example when company grug work for introduce [OSGi](https://www.techtarget.com/searchnetworking/definition/OSGi) to help \nmanage/trap spriit complexity demon in code base. not only OSGi not help, but make complexity demon much more powerful!\ntook multiple man year of best developers to rework as well to boot! more complex spirit and now features impossible \nimplement! very bad!\n\n# [Chesterton's Fence](#grug-on-chestertons-fence)\n\nwise grug shaman [chesterton](https://en.wikipedia.org/wiki/G._K._Chesterton) once say \n\n> 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.”\n\nmany older grug learn this lesson well not start tearing code out willy nilly, no matter how ugly look\n\ngrug understand all programmer platonists at some level wish music of spheres perfection in code. but danger is here,\nworld is ugly and gronky many times and so also must code be\n\nhumility not often come big brained or think big brained \neasily 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\nworse even\n\ngrug early on in career often charge into code base waving club wildly and smash up everything, learn not good\n\ngrug not say no improve system ever, quite foolish, but recommend take time understand system first especially bigger system is and\nis respect code working today even if not perfect\n\nhere tests often good hint for why fence not to be smashed!\n\n# [Microservices](#grug-on-microservices)\n\ngrug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too\n\nseem very confusing to grug\n\n# [Tools](#grug-on-tools)\n\ngrug love tool. tool and control passion what separate grug from dinosaurs! tool allow grug brain to create code that \nnot possible otherwise by doing thinking for grug, always good relief! grug always spend time in new place learning \ntools around him to maximize productivity: learn tools for two weeks make development often twice faster and often\nhave dig around ask other developers help, no docs\n\ncode completion in IDE allow grug not have remembered all API, very important! \n\njava programming nearly impossible without it for grug!\n\nreally make grug think some time\n\ngood debugger worth weight in shiney rocks, in fact also more: when faced with bug grug would often trade all shiney rock and\nperhaps few children for good debugger and anyway debugger no weigh anything far as grug can tell \n\ngrug always recommend new programmer learn available debugger very deeply, features like conditional break points, expression\nevaluation, stack navigation, etc teach new grug more about computer than university class often!\n\ngrug say never be not improving tooling\n\n# [Type Systems](#grug-on-type-systems)\n\ngrug very like type systems make programming easier. for grug, type systems most value when grug hit dot on keyboard and\nlist of things grug can do pop up magic. this 90% of value of type system or more to grug\n\nbig brain type system shaman often say type correctness main point type system, but grug note some big brain type system \nshaman not often ship code. grug suppose code never shipped is correct, in some sense, but not really what grug mean\nwhen say correct\n\ngrug say tool magic pop up of what can do and complete of code major most benefit of type system, correctness also good but not \nso nearly so much\n\nalso, often sometimes caution beware big brains here!\n\nsome type big brain think in type systems and talk in lemmas, potential danger!\n\ndanger abstraction too high, big brain type system code become astral projection of platonic generic turing model of \ncomputation into code base. grug confused and agree some level very elegant but also very hard do anything like \nrecord number of club inventory for Grug Inc. task at hand\n\ngenerics especially dangerous here, grug try limit generics to container classes for most part where most value add\n\ntemptation generics very large is trick! spirit demon complex love this one trick! beware!\n\nalways most value type system come: hit dot see what grug can do, never forget!\n\n# [Expression Complexity](#grug-on-expression-complexity)\n\ngrug once like to minimize lines of code much as possible. write code like this:\n\n```js\n if(contact && !contact.isActive() && (contact.inGroup(FAMILY) || contact.inGroup(FRIENDS))) {\n // ...\n }\n```\n\nover time grug learn this hard debug, learn prefer write like so:\n\n```js\n if(contact) {\n var contactIsInactive = !contact.isActive();\n var contactIsFamilyOrFriends = contact.inGroup(FAMILY) || contact.inGroup(FRIENDS);\n if(contactIsInactive && contactIsFamilyOrFriends) {\n // ...\n }\n }\n```\n\ngrug hear screams from young grugs at horror of many line of code and pointless variable and grug prepare defend self with club\n\nclub fight start with other developers attack and grug yell: \"easier debug! see result of each expression more clearly and good name! easier\nunderstand conditional expression! EASIER DEBUG!\"\n\ndefinitely easier debug and once club fight end calm down and young grug think a bit, they realize grug right\n\ngrug still catch grug writing code like first example and often regret, so grug not judge young grug\n\n# [DRY](#grug-on-dry)\n\n[DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) mean Don't Repeat Self, powerful maxim over mind of most\ndevelopers\n\ngrug respect DRY and good advice, however grug recommend balance in all things, as gruggest big brain aristotle recommend\n\ngrug note humourous graph by Lea Verou correspond with grug passion not repeat:\n\n\n\nover time past ten years program grug not as concerned repeat code. so long as repeat code simple enough and obvious \nenough, and grug begin feel repeat/copy paste code with small variation is better than many callback/closures passed arguments\nor elaborate object model: too hard complex for too little benefit at times\n\nhard balance here, repeat code always still make grug stare and say \"mmm\" often, but experience show repeat code\nsometimes often better than complex DRY solution\n\nnote well! grug encourage over literal developer not take does work line too serious, is joke\n\n# [Separation of Concerns (SoC)](#grug-on-soc)\n\n[Separation of Concern (SoC)](https://en.wikipedia.org/wiki/Separation_of_concerns) another powerful idea over many developer\nmind, idea to separate different aspects of system into distinct sections code\n\ncanonical example from web development: separation of style (css file), markup (html file) and logic (javascript file)\n\nhere grug much more sour faced than DRY and in fact write big brained essay on alternative design principle\n[locality of behavior (LoB)](https://htmx.org/essays/locality-of-behaviour/) against SoC\n\ngrug much prefer put code on the thing that do the thing. now when grug look at the thing grug know the thing what the\nthing do, alwasy good relief!\n\nwhen separate of concern grug must often all over tarnation many file look understand what how button do, much confuse \nand time waste: bad!\n\n# [Closures](#grug-on-closures)\n\ngrug like closures for right job and that job usually abstracting operation over collection of objects\n\ngrug warn closures like salt, type systems and generics: small amount go long way, but easy spoil things too much use\ngive heart attack\n\njavascript developers call very special complexity demon spirit in javascript \"callback hell\" because too much closure \nused by javascript libraries very sad but also javascript developer get what deserved let grug be frank\n\n# [Logging](#grug-on-logging)\n\ngrug huge fan of logging and encourage lots of it, especially in cloud deployed. some non-grugs say logging expensive\nand not important. grug used think this way no more\n\nfunny story: grug learn idol [rob pike](https://en.wikipedia.org/wiki/Rob_Pike) working on logging at google and decide: \n\"if rob pike working on logging, what grug do there?!?\" so not pursue. turn out logging _very_ important to google so\nof course best programmer work on it, grug! \n\ndon't be such grug brain, grug, much less shiney rock now!\n\noh well, grug end up at good company anyway and rob pike dress habit \n[increasingly erratic](https://www.youtube.com/watch?v=KINIAgRpkDA), so all work out in end, but \npoint stand: logging very important!\n\ngrug tips on logging are:\n\n* log all major logical branches within code (if/for)\n* if \"request\" span multiple machine in cloud infrastructure, include request ID in all so logs can be grouped\n* if possible make log level dynamically controlled, so grug can turn on/off when need debug issue (many!)\n* if possible make log level per user, so can debug specific user issue\n\nlast two points are especially handy club when fighting bugs in production systems very often\n\nunfortunately log libraries often very complex (java, [why you do?](https://stackify.com/logging-java/)) but worth investing \ntime in getting logging infrastructure \"just right\" pay off big later in grug experience\n\nlogging need taught more in schools, grug think\n\n# [Concurrency](#grug-on-concurrency)\n\ngrug, like all sane developer, fear concurrency\n\nas much as possible, grug try to rely on simple concurrency models like stateless web request handlers and simple\nremote job worker queues where jobs no interdepend and simple api\n\n[optimistic concurrency](https://en.wikipedia.org/wiki/Optimistic_concurrency_control) seem work well for web stuff\n\noccasionally grug reach for [thread local variable](https://en.wikipedia.org/wiki/Thread-local_storage), usually when \nwriting framework code\n\nsome language have good concurrent data structure, like java [ConcurrentHashMap](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html)\nbut still need careful grug work to get right\n\ngrug has never used [erlang](https://en.wikipedia.org/wiki/Erlang_(programming_language)), hear good things, but language \nlook wierd to grug sorry\n\n# [Optimizing](#grug-on-optimizing)\n\nultra biggest of brain developer once say:\n\n> premature optimization is the root of all evil\n\nthis everyone mostly know and grug in humble violent agreement with ultra biggest of big brain\n\ngrug recommend always to have concrete, real world perf profile showing specific perf issue before begin optimizing. \n\nnever know what actual issue might be, grug often surprise! very often!\n\nbeware only cpu focus: easy to see cpu and much big o notation thinking having been done in school,\nbut often not root of all slowness, surprise to many including grug\n\nhitting network equivalent of many, many millions cpu cycle and always to be minimized if possible, note well big brain\nmicroservice developer!\n\ninexperienced big brain developer see nested loop and often say \"O(n^2)? Not on my watch!\"\n\ncomplexity demon spirit smile\n\n# [APIs](#grug-on-apis)\n\ngrug love good apis. good apis not make grug think too much\n\nunfortunately, many apis very bad, make grug think quite a bit. this happen many reasons, here two:\n\n* API creators think in terms of implementation or domain of API, rather than in terms of use of API\n* API creators think too abstract and big brained\n\nusually grug not care too deeply about detail of api: want write file or sort list or whatever, just want to call\n`write()` or `sort()` or whatever\n\nbut big brain api developers say:\n\n\"not so fast, grug! is that file *open for write*? did you define a *Comparator* for that sort?\"\n\ngrug find self restraining hand reaching for club again\n\nnot care about that stuff right now, just want sort and write file mr big brain!\n\ngrug recognize that big brain api designer have point and that _sometime_ these things matter, but often do not.\nbig brain api developers better if design for simple cases with simple api, make complex cases possible\nwith more complex api\n\ngrug call this \"layering\" apis: two or three different apis at different level complexity for various grug needs\n\nalso, if object oriented, put api on thing instead of elsewhere. java worst at this! \n\ngrug want filter list in java\n\n\"Did you convert it to a stream?\"\n\nfine, grug convert to stream\n\n\"OK, now you can filter.\" \n\nOK, but now need return list! have stream! \n\n\"Well, did you collect your stream into a list?\"\n\nwhat?\n\n\"Define a Collector<? super T, A, R> to collect your stream into a list\"\n\ngrug now swear on ancestor grave he club every single person in room, but count two instead and remain calm\n\nput common thing like `filter()` on list and make return list, listen well big brain java api developer! \n\nnobody care about \"stream\" or even hear of \"stream\" before, is not networking api, all java grugs use list mr big brain! \n\n# [Parsing](#grug-on-parsing)\n\ngrug love make programming language at drop of hat and \nsay [recursive descent](https://en.wikipedia.org/wiki/Recursive_descent_parser)\nmost fun and beautiful way create parser\n\nunfortunately many big brain school teach only parser generator tool. here grug usual love of tool is not: parser \ngenerator tool generate code of awful snakes nest: impossible understand, bottom up, what? hide recursive nature of \ngrammar from grug and debug impossible, very bad according grug!\n\ngrug think this because while complexity demon bad for code base and understand, complexity demon very good for generation\nof much academic papers, sad but true\n\nproduction parser almost always recursive descent, despite ignore by schools! grug furious when learn how simple parse \nis! parsing not big brain only magic: so can you!\n\ngrug very elated find big brain developer Bob Nystrom redeem the big brain tribe and write excellent book on recursive\ndescent: [Crafting Interpreters](https://craftinginterpreters.com/)\n\nbook available online free, but grug highly recommend all interested grugs purchase book on general principle, provide\nmuch big brain advice and grug love book _very_ much except visitor pattern (trap!)\n\n# [The Visitor Pattern](#grug-on-visitor-pattern)\n\n[bad](https://en.wikipedia.org/wiki/Visitor_pattern) \n\n# [Front End Development](#grug-on-front-end-development)\n\nsome non-grugs, when faced with web development say: \n\n\"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\nover HTTP (which is funny because I'm not transferring hypertext)\"\n\nnow you have two complexity demon spirit lairs\n\nand, what is worse, front end complexity demon spirit even more powerful and have deep spiritual hold on entire front end\nindustry as far as grug can tell\n\nback end developers try keep things simple and can work ok, but front end developers make very complex very quickly and \nintroduce lots of code, demon complex spirit\n\neven when website just need put form into database or simple brochure site! \n\neveryone do this now! \n\ngrug not sure why except maybe facebook and google say so, but that not seem very good reason to grug\n\ngrug not like big complex front end libraries everyone use\n\ngrug make [htmx](https://htmx.org) and [hyperscript](https://hyperscript.org) to avoid\n\nkeep complexity low, simple HTML, avoid lots javascript, the natural ether of spirit complexity demon\n\nmaybe they work for you, but no job post, sorry\n\nreact better for job and also some type application, but also you become alcolyte of complexity demon whether you like \nor no, sorry such is front end life\n\n# [Fads](#grug-on-fads)\n\ngrug note lots of fads in development, especially front end development today\n\nback end better more boring because all bad ideas have tried at this point maybe (still retry some!)\n\nstill trying all bad ideas in front end development so still much change and hard to know\n\ngrug recommend taking all revolutionary new approach with grain salt: big brains have working for long \ntime on computers now, most ideas have tried at least once\n\ngrug not saying can't learn new tricks or no good new ideas, but also much of time wasted on recycled bad ideas, lots of\nspirit complexity demon power come from putting new idea willy nilly into code base\n\n# [Fear Of Looking Dumb](#grug-on-fold)\n\nnote! very good if senior grug willing to say publicly: \"hmmm, this too complex for grug\"!\n\nmany developers Fear Of Looking Dumb (FOLD), grug also at one time FOLD, but grug learn get over: very important senior \ngrug say \"this too complicated and confuse to me\"\n\nthis make it ok for junior grugs to admit too complex and not understand as well, often such case! FOLD major source of \ncomplexity demon power over developer, especially young grugs! \n\ntake FOLD power away, very good of senior grug!\n\nnote: important to make thinking face and look big brained when saying though. be prepare for big brain or, worse and\nmuch more common, *thinks* is big brain to make snide remark of grug\n\nbe strong! no FOLD! \n\nclub sometimes useful here, but more often sense of humor and especially last failed project by big brain very useful, \nso collect and be calm\n\n# [Impostor Syndrome](#grug-on-imposter-syndrom)\n\ngrug note many such impostor feels in development\n\nalways grug one of two states: grug is ruler of all survey, wield code club like thor OR grug have no idea what doing\n\ngrug is mostly latter state most times, hide it pretty well though\n\nnow, grug make softwares of much work and [moderate open source success](https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date)\n, and yet grug himself often feel not any idea what doing! very often! grug still fear make mistake break everyone code and \ndisappoint other grugs, imposter!\n\nis maybe nature of programming for most grug to feel impostor and be ok with is best: nobody imposter if everybody imposter\n\nany young grug read this far probably do fine in program career even if frustrations and worry is always to be there, sorry\n\n# [Reads](#grug-reads)\n\ngrug like these:\n\n* [Worse is Better](https://www.dreamsongs.com/WorseIsBetter.html)\n* [Worse is Better is Worse](https://www.dreamsongs.com/Files/worse-is-worse.pdf)\n* [Is Worse Really Better?](https://www.dreamsongs.com/Files/IsWorseReallyBetter.pdf)\n* [A Philosophy of Software Design](https://www.goodreads.com/en/book/show/39996759-a-philosophy-of-software-design)\n\n# [Conclusion](#lol-lmao)\n\n_you_ say: complexity *very*, *very* bad\n"
},
{
"path": "jobs.rss",
"content": "\n\n\n\n Grug Brained Jobs\n https://grugbrain.dev/\n Jobs seeking Grug-brained Developers\n \n Example\n https://google.com\n Example Job (Google could use some more grug brains...)\n \n\n\n"
},
{
"path": "package.json",
"content": "{\n \"name\": \"grugbrain.dev\",\n \"version\": \"0.0.1\",\n \"description\": \"\",\n \"repository\": {\n \"type\": \"git\",\n \"url\": \"git+https://github.com/bigskysoftware/grugbrain.dev.git\"\n },\n \"keywords\": [],\n \"author\": \"\",\n \"license\": \"BSD\",\n \"bugs\": {\n \"url\": \"https://github.com/bigskysoftware/grugbrain.dev/issues\"\n },\n \"homepage\": \"https://grugbrain.dev\",\n \"devDependencies\": {\n \"@11ty/eleventy\": \"^1.0.1\"\n }\n}\n"
}
]
![\"grug\"](\"grug.png\")
\n \n ![\"code](\"over-time.png\")
\n\nover time past ten years program grug not as concerned repeat code. so long as repeat code simple enough and obvious \nenough, and grug begin feel repeat/copy paste code with small variation is better than many callback/closures passed arguments\nor elaborate object model: too hard complex for too little benefit at times\n\nhard balance here, repeat code always still make grug stare and say \"mmm\" often, but experience show repeat code\nsometimes often better than complex DRY solution\n\nnote well! grug encourage over literal developer not take does work line too serious, is joke\n\n# [Separation of Concerns (SoC)](#grug-on-soc)\n\n[Separation of Concern (SoC)](https://en.wikipedia.org/wiki/Separation_of_concerns) another powerful idea over many developer\nmind, idea to separate different aspects of system into distinct sections code\n\ncanonical example from web development: separation of style (css file), markup (html file) and logic (javascript file)\n\nhere grug much more sour faced than DRY and in fact write big brained essay on alternative design principle\n[locality of behavior (LoB)](https://htmx.org/essays/locality-of-behaviour/) against SoC\n\ngrug much prefer put code on the thing that do the thing. now when grug look at the thing grug know the thing what the\nthing do, alwasy good relief!\n\nwhen separate of concern grug must often all over tarnation many file look understand what how button do, much confuse \nand time waste: bad!\n\n# [Closures](#grug-on-closures)\n\ngrug like closures for right job and that job usually abstracting operation over collection of objects\n\ngrug warn closures like salt, type systems and generics: small amount go long way, but easy spoil things too much use\ngive heart attack\n\njavascript developers call very special complexity demon spirit in javascript \"callback hell\" because too much closure \nused by javascript libraries very sad but also javascript developer get what deserved let grug be frank\n\n# [Logging](#grug-on-logging)\n\ngrug huge fan of logging and encourage lots of it, especially in cloud deployed. some non-grugs say logging expensive\nand not important. grug used think this way no more\n\nfunny story: grug learn idol [rob pike](https://en.wikipedia.org/wiki/Rob_Pike) working on logging at google and decide: \n\"if rob pike working on logging, what grug do there?!?\" so not pursue. turn out logging _very_ important to google so\nof course best programmer work on it, grug! \n\ndon't be such grug brain, grug, much less shiney rock now!\n\noh well, grug end up at good company anyway and rob pike dress habit \n[increasingly erratic](https://www.youtube.com/watch?v=KINIAgRpkDA), so all work out in end, but \npoint stand: logging very important!\n\ngrug tips on logging are:\n\n* log all major logical branches within code (if/for)\n* if \"request\" span multiple machine in cloud infrastructure, include request ID in all so logs can be grouped\n* if possible make log level dynamically controlled, so grug can turn on/off when need debug issue (many!)\n* if possible make log level per user, so can debug specific user issue\n\nlast two points are especially handy club when fighting bugs in production systems very often\n\nunfortunately log libraries often very complex (java, [why you do?](https://stackify.com/logging-java/)) but worth investing \ntime in getting logging infrastructure \"just right\" pay off big later in grug experience\n\nlogging need taught more in schools, grug think\n\n# [Concurrency](#grug-on-concurrency)\n\ngrug, like all sane developer, fear concurrency\n\nas much as possible, grug try to rely on simple concurrency models like stateless web request handlers and simple\nremote job worker queues where jobs no interdepend and simple api\n\n[optimistic concurrency](https://en.wikipedia.org/wiki/Optimistic_concurrency_control) seem work well for web stuff\n\noccasionally grug reach for [thread local variable](https://en.wikipedia.org/wiki/Thread-local_storage), usually when \nwriting framework code\n\nsome language have good concurrent data structure, like java [ConcurrentHashMap](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html)\nbut still need careful grug work to get right\n\ngrug has never used [erlang](https://en.wikipedia.org/wiki/Erlang_(programming_language)), hear good things, but language \nlook wierd to grug sorry\n\n# [Optimizing](#grug-on-optimizing)\n\nultra biggest of brain developer once say:\n\n> premature optimization is the root of all evil\n\nthis everyone mostly know and grug in humble violent agreement with ultra biggest of big brain\n\ngrug recommend always to have concrete, real world perf profile showing specific perf issue before begin optimizing. \n\nnever know what actual issue might be, grug often surprise! very often!\n\nbeware only cpu focus: easy to see cpu and much big o notation thinking having been done in school,\nbut often not root of all slowness, surprise to many including grug\n\nhitting network equivalent of many, many millions cpu cycle and always to be minimized if possible, note well big brain\nmicroservice developer!\n\ninexperienced big brain developer see nested loop and often say \"O(n^2)? Not on my watch!\"\n\ncomplexity demon spirit smile\n\n# [APIs](#grug-on-apis)\n\ngrug love good apis. good apis not make grug think too much\n\nunfortunately, many apis very bad, make grug think quite a bit. this happen many reasons, here two:\n\n* API creators think in terms of implementation or domain of API, rather than in terms of use of API\n* API creators think too abstract and big brained\n\nusually grug not care too deeply about detail of api: want write file or sort list or whatever, just want to call\n`write()` or `sort()` or whatever\n\nbut big brain api developers say:\n\n\"not so fast, grug! is that file *open for write*? did you define a *Comparator* for that sort?\"\n\ngrug find self restraining hand reaching for club again\n\nnot care about that stuff right now, just want sort and write file mr big brain!\n\ngrug recognize that big brain api designer have point and that _sometime_ these things matter, but often do not.\nbig brain api developers better if design for simple cases with simple api, make complex cases possible\nwith more complex api\n\ngrug call this \"layering\" apis: two or three different apis at different level complexity for various grug needs\n\nalso, if object oriented, put api on thing instead of elsewhere. java worst at this! \n\ngrug want filter list in java\n\n\"Did you convert it to a stream?\"\n\nfine, grug convert to stream\n\n\"OK, now you can filter.\" \n\nOK, but now need return list! have stream! \n\n\"Well, did you collect your stream into a list?\"\n\nwhat?\n\n\"Define a Collector<? super T, A, R> to collect your stream into a list\"\n\ngrug now swear on ancestor grave he club every single person in room, but count two instead and remain calm\n\nput common thing like `filter()` on list and make return list, listen well big brain java api developer! \n\nnobody care about \"stream\" or even hear of \"stream\" before, is not networking api, all java grugs use list mr big brain! \n\n# [Parsing](#grug-on-parsing)\n\ngrug love make programming language at drop of hat and \nsay [recursive descent](https://en.wikipedia.org/wiki/Recursive_descent_parser)\nmost fun and beautiful way create parser\n\nunfortunately many big brain school teach only parser generator tool. here grug usual love of tool is not: parser \ngenerator tool generate code of awful snakes nest: impossible understand, bottom up, what? hide recursive nature of \ngrammar from grug and debug impossible, very bad according grug!\n\ngrug think this because while complexity demon bad for code base and understand, complexity demon very good for generation\nof much academic papers, sad but true\n\nproduction parser almost always recursive descent, despite ignore by schools! grug furious when learn how simple parse \nis! parsing not big brain only magic: so can you!\n\ngrug very elated find big brain developer Bob Nystrom redeem the big brain tribe and write excellent book on recursive\ndescent: [Crafting Interpreters](https://craftinginterpreters.com/)\n\nbook available online free, but grug highly recommend all interested grugs purchase book on general principle, provide\nmuch big brain advice and grug love book _very_ much except visitor pattern (trap!)\n\n# [The Visitor Pattern](#grug-on-visitor-pattern)\n\n[bad](https://en.wikipedia.org/wiki/Visitor_pattern) \n\n# [Front End Development](#grug-on-front-end-development)\n\nsome non-grugs, when faced with web development say: \n\n\"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\nover HTTP (which is funny because I'm not transferring hypertext)\"\n\nnow you have two complexity demon spirit lairs\n\nand, what is worse, front end complexity demon spirit even more powerful and have deep spiritual hold on entire front end\nindustry as far as grug can tell\n\nback end developers try keep things simple and can work ok, but front end developers make very complex very quickly and \nintroduce lots of code, demon complex spirit\n\neven when website just need put form into database or simple brochure site! \n\neveryone do this now! \n\ngrug not sure why except maybe facebook and google say so, but that not seem very good reason to grug\n\ngrug not like big complex front end libraries everyone use\n\ngrug make [htmx](https://htmx.org) and [hyperscript](https://hyperscript.org) to avoid\n\nkeep complexity low, simple HTML, avoid lots javascript, the natural ether of spirit complexity demon\n\nmaybe they work for you, but no job post, sorry\n\nreact better for job and also some type application, but also you become alcolyte of complexity demon whether you like \nor no, sorry such is front end life\n\n# [Fads](#grug-on-fads)\n\ngrug note lots of fads in development, especially front end development today\n\nback end better more boring because all bad ideas have tried at this point maybe (still retry some!)\n\nstill trying all bad ideas in front end development so still much change and hard to know\n\ngrug recommend taking all revolutionary new approach with grain salt: big brains have working for long \ntime on computers now, most ideas have tried at least once\n\ngrug not saying can't learn new tricks or no good new ideas, but also much of time wasted on recycled bad ideas, lots of\nspirit complexity demon power come from putting new idea willy nilly into code base\n\n# [Fear Of Looking Dumb](#grug-on-fold)\n\nnote! very good if senior grug willing to say publicly: \"hmmm, this too complex for grug\"!\n\nmany developers Fear Of Looking Dumb (FOLD), grug also at one time FOLD, but grug learn get over: very important senior \ngrug say \"this too complicated and confuse to me\"\n\nthis make it ok for junior grugs to admit too complex and not understand as well, often such case! FOLD major source of \ncomplexity demon power over developer, especially young grugs! \n\ntake FOLD power away, very good of senior grug!\n\nnote: important to make thinking face and look big brained when saying though. be prepare for big brain or, worse and\nmuch more common, *thinks* is big brain to make snide remark of grug\n\nbe strong! no FOLD! \n\nclub sometimes useful here, but more often sense of humor and especially last failed project by big brain very useful, \nso collect and be calm\n\n# [Impostor Syndrome](#grug-on-imposter-syndrom)\n\ngrug note many such impostor feels in development\n\nalways grug one of two states: grug is ruler of all survey, wield code club like thor OR grug have no idea what doing\n\ngrug is mostly latter state most times, hide it pretty well though\n\nnow, grug make softwares of much work and [moderate open source success](https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date)\n, and yet grug himself often feel not any idea what doing! very often! grug still fear make mistake break everyone code and \ndisappoint other grugs, imposter!\n\nis maybe nature of programming for most grug to feel impostor and be ok with is best: nobody imposter if everybody imposter\n\nany young grug read this far probably do fine in program career even if frustrations and worry is always to be there, sorry\n\n# [Reads](#grug-reads)\n\ngrug like these:\n\n* [Worse is Better](https://www.dreamsongs.com/WorseIsBetter.html)\n* [Worse is Better is Worse](https://www.dreamsongs.com/Files/worse-is-worse.pdf)\n* [Is Worse Really Better?](https://www.dreamsongs.com/Files/IsWorseReallyBetter.pdf)\n* [A Philosophy of Software Design](https://www.goodreads.com/en/book/show/39996759-a-philosophy-of-software-design)\n\n# [Conclusion](#lol-lmao)\n\n_you_ say: complexity *very*, *very* bad\n"
},
{
"path": "jobs.rss",
"content": "\n