grugbrain-dev-dzqozx.txt (31194B)
1 [1] grug 2 3 The Grug Brained Developer 4 A layman's guide to thinking like the self-aware smol brained 5 6 Introduction 7 8 this collection of thoughts on software development gathered by grug brain 9 developer 10 11 grug brain developer not so smart, but grug brain developer program many long 12 year and learn some things although mostly still confused 13 14 grug brain developer try collect learns into small, easily digestible and funny 15 page, not only for you, the young grug, but also for him because as grug brain 16 developer get older he forget important things, like what had for breakfast or 17 if put pants on 18 19 big brained developers are many, and some not expected to like this, make sour 20 face 21 22 THINK they are big brained developers many, many more, and more even definitely 23 probably maybe not like this, many sour face (such is internet) 24 25 (note: grug once think big brained but learn hard way) 26 27 is fine! 28 29 is free country sort of and end of day not really matter too much, but grug 30 hope you fun reading and maybe learn from many, many mistake grug make over 31 long program life 32 33 [2]The Eternal Enemy: Complexity 34 35 apex predator of grug is complexity 36 37 complexity bad 38 39 say again: 40 41 complexity very bad 42 43 you say now: 44 45 complexity very, very bad 46 47 given choice between complexity or one on one against t-rex, grug take t-rex: 48 at least grug see t-rex 49 50 complexity is spirit demon that enter codebase through well-meaning but 51 ultimately very clubbable non grug-brain developers and project managers who 52 not fear complexity spirit demon or even know about sometime 53 54 one day code base understandable and grug can get work done, everything good! 55 56 next day impossible: complexity demon spirit has entered code and very 57 dangerous situation! 58 59 grug no able see complexity demon, but grug sense presence in code base 60 61 demon complexity spirit mocking him make change here break unrelated thing 62 there what!?! mock mock mock ha ha so funny grug love programming and not 63 becoming shiney rock speculator like grug senior advise 64 65 club not work on demon spirit complexity and bad idea actually hit developer 66 who let spirit in with club: sometimes grug himself! 67 68 sadly, often grug himself 69 70 so grug say again and say often: complexity very, very bad 71 72 [3]Saying No 73 74 best weapon against complexity spirit demon is magic word: "no" 75 76 "no, grug not build that feature" 77 78 "no, grug not build that abstraction" 79 80 "no, grug not put water on body every day or drink less black think juice you 81 stop repeat ask now" 82 83 note, this good engineering advice but bad career advice: "yes" is magic word 84 for more shiney rock and put in charge of large tribe of developer 85 86 sad but true: learn "yes" then learn blame other grugs when fail, ideal career 87 advice 88 89 but grug must to grug be true, and "no" is magic grug word. Hard say at first, 90 especially if you nice grug and don't like disappoint people (many such grugs!) 91 but easier over time even though shiney rock pile not as high as might 92 otherwise be 93 94 is ok: how many shiney rock grug really need anyway? 95 96 [4]Saying ok 97 98 sometimes compromise necessary or no shiney rock, mean no dinosaur meat, not 99 good, wife firmly remind grug about young grugs at home need roof, food, and so 100 forth, no interest in complexity demon spirit rant by grug for fiftieth time 101 102 in this situation, grug recommend "ok" 103 104 "ok, grug build that feature" 105 106 then grug spend time think of [5]80/20 solution to problem and build that 107 instead. 108 80/20 solution say "80 want with 20 code" solution maybe not have all 109 bell-whistle that project manager want, maybe a little ugly, but work and 110 deliver most value, and keep demon complexity spirit at bay for most part to 111 extent 112 113 sometimes probably best just not tell project manager and do it 80/20 way. 114 easier forgive than permission, project managers mind like butterfly at times 115 overworked and dealing with many grugs. often forget what even feature supposed 116 to do or move on or quit or get fired grug see many such cases 117 118 anyway is in project managers best interest anyway so grug not to feel too bad 119 for this approach usually 120 121 [6]Factoring Your Code 122 123 next strategy very harder: break code base up properly (fancy word: "factor 124 your code properly") here is hard give general advice because each system so 125 different. however, one thing grug come to believe: not factor your application 126 too early! 127 128 early on in project everything very abstract and like water: very little solid 129 holds for grug's struggling brain to hang on to. take time to develop "shape" 130 of system and learn what even doing. grug try not to factor in early part of 131 project and then, at some point, good cut-points emerge from code base 132 133 good cut point has narrow interface with rest of system: small number of 134 functions or abstractions that hide complexity demon internally, like trapped 135 in crystal 136 137 grug quite satisfied when complexity demon trapped properly in crystal, is best 138 feeling to trap mortal enemy! 139 140 grug try watch patiently as cut points emerge from code and slowly refactor, 141 with code base taking shape over time along with experience. no hard/ fast rule 142 for this: grug know cut point when grug see cut point, just take time to build 143 skill in seeing, patience 144 145 sometimes grug go too early and get abstractions wrong, so grug bias towards 146 waiting 147 148 big brain developers often not like this at all and invent many abstractions 149 start of project 150 151 grug tempted to reach for club and yell "big brain no maintain code! big brain 152 move on next architecture committee leave code for grug deal with!" 153 154 but grug learn control passions, major difference between grug and animal 155 156 instead grug try to limit damage of big brain developer early in project by 157 giving them thing like UML diagram (not hurt code, probably throw away anyway) 158 or by demanding working demo tomorrow 159 160 working demo especially good trick: force big brain make something to actually 161 work to talk about and code to look at that do thing, will help big brain see 162 reality on ground more quickly 163 164 remember! big brain have big brain! need only be harness for good and not in 165 service of spirit complexity demon on accident, many times seen 166 167 (best grug brain able to herd multiple big brain in right direction and produce 168 many complexity demon trap crystals, large shiney rock pile awaits such grug!) 169 170 also sometimes call demo approach "prototype", sound fancier to project manager 171 172 grug say prototype early in software making, especially if many big brains 173 174 [7]Testing 175 176 grug have love/hate relationship with test: test save grug many, many 177 uncountable time and grug love and respect test 178 179 unfortunately also many test shamans exist. some test shaman make test idol, 180 demand things like "first test" before grug even write code or have any idea 181 what grug doing domain! 182 183 how grug test what grug not even understand domain yet!? 184 185 "Oh, don't worry: the tests will show you what you need to do." 186 187 grug once again catch grug slowly reaching for club, but grug stay calm 188 189 grug instead prefer write most tests after prototype phase, when code has begun 190 firm up 191 192 but, note well: grug must here be very disciplined! 193 194 easy grug to move on and not write tests because "work on grugs machine"! 195 196 this very, very bad: no guarantee work on other machine and no guarantee work 197 on grug machine in future, many times 198 199 test shaman have good point on importance of test, even if test shaman often 200 sometimes not complete useful feature in life and talk only about test all 201 time, deserve of club but heart in right place 202 203 also, test shaman often talk unit test very much, but grug not find so useful. 204 grug experience that ideal tests are not unit test or either end-to-end test, 205 but in-between test 206 207 [8]unit tests fine, ok, but break as implementation change (much compared api!) 208 and make refactor hard and, frankly, many bugs anyway often due interactions 209 other code. often throw away when code change. 210 211 grug write unit test mostly at start of project, help get things going but not 212 get too attached or expect value long time 213 214 [9]end to end tests good, show whole system work, but! hard to understand when 215 break and drive grug crazy very often, sometimes grugs just end up ignoring 216 because "oh, that break all time" very bad! 217 218 in-between tests, grug hear shaman call [10]"integration tests" sometime often 219 with sour look on face. but grug say integration test sweet spot according to 220 grug: high level enough test correctness of system, low level enough, with good 221 debugger, easy to see what break 222 223 grug prefer some unit tests especially at start but not 100% all code test and 224 definitely not "first test". "test along the way" work pretty well for grug, 225 especially as grug figure things out 226 227 grug focus much ferocious integration test effort as cut point emerge and 228 system stabilize! cut point api hopefully stable compared implementation and 229 integration test remain valuable many long time, and easy debug 230 231 also small, well curated end-to-end test suite is created to be kept working 232 religiously on pain of clubbing. focus of important end-to-end test on most 233 common UI features and few most important edge cases, but not too many or 234 become impossible maintain and then ignored 235 236 this ideal set of test to grug 237 238 you may not like, but this peak grug testing 239 240 also, grug dislike [11]mocking in test, prefer only when absolute necessary to 241 (rare/never) and coarse grain mocking (cut points/systems) only at that 242 243 one exception "first test" dislike by grug: when bug found. grug always try 244 first reproduce bug with regression test then fix bug, this case only for some 245 reason work better 246 247 [12]Agile 248 249 grug think agile not terrible, not good 250 251 end of day, not worst way to organize development, maybe better than others 252 grug supposes is fine 253 254 danger, however, is agile shaman! many, many shiney rock lost to agile shaman! 255 256 whenever agile project fail, agile shaman say "you didn't do agile right!" grug 257 note this awfully convenient for agile shaman, ask more shiney rock better 258 agile train young grugs on agile, danger! 259 260 grug tempted reach for club when too much agile talk happen but always stay 261 calm 262 263 prototyping, tools and hiring good grugs better key to success software: agile 264 process ok and help some but sometimes hurt taken too seriously 265 266 grug say [13]no silver club fix all software problems no matter what agile 267 shaman say (danger!) 268 269 [14]Refactoring 270 271 refactoring fine activity and often good idea, especially later in project when 272 code firmed up 273 274 however, grug note that many times in career "refactors" go horribly off rails 275 and end up causing more harm than good 276 277 grug not sure exactly why some refactors work well, some fail, but grug notice 278 that larger refactor, more likely failure appear to be 279 280 so grug try to keep refactors relatively small and not be "too far out from 281 shore" during refactor. ideally system work entire time and each step of finish 282 before other begin. 283 284 end-to-end tests are life saver here, but often very hard understand why 285 broke... such is refactor life. 286 287 also grug notice that introducing too much abstraction often lead to refactor 288 failure and system failure. good example was [15]J2EE introduce, many big brain 289 sit around thinking too much abstraction, nothing good came of it many project 290 hurt 291 292 another good example when company grug work for introduce [16]OSGi to help 293 manage/trap spriit complexity demon in code base. not only OSGi not help, but 294 make complexity demon much more powerful! took multiple man year of best 295 developers to rework as well to boot! more complex spirit and now features 296 impossible implement! very bad! 297 298 [17]Chesterton's Fence 299 300 wise grug shaman [18]chesterton once say 301 302 here exists in such a case a certain institution or law; let us say, for 303 the sake of simplicity, a fence or gate erected across a road. The more 304 modern type of reformer goes gaily up to it and says, “I don’t see the use 305 of this; let us clear it away.” To which the more intelligent type of 306 reformer will do well to answer: “If you don’t see the use of it, I 307 certainly won’t let you clear it away. Go away and think. Then, when you 308 can come back and tell me that you do see the use of it, I may allow you to 309 destroy it.” 310 311 many older grug learn this lesson well not start tearing code out willy nilly, 312 no matter how ugly look 313 314 grug understand all programmer platonists at some level wish music of spheres 315 perfection in code. but danger is here, world is ugly and gronky many times and 316 so also must code be 317 318 humility not often come big brained or think big brained easily or grug even, 319 but grug often find "oh, grug no like look of this, grug fix" lead many hours 320 pain grug and no better or system worse even 321 322 grug early on in career often charge into code base waving club wildly and 323 smash up everything, learn not good 324 325 grug not say no improve system ever, quite foolish, but recommend take time 326 understand system first especially bigger system is and is respect code working 327 today even if not perfect 328 329 here tests often good hint for why fence not to be smashed! 330 331 [19]Microservices 332 333 grug wonder why big brain take hardest problem, factoring system correctly, and 334 introduce network call too 335 336 seem very confusing to grug 337 338 [20]Tools 339 340 grug love tool. tool and control passion what separate grug from dinosaurs! 341 tool allow grug brain to create code that not possible otherwise by doing 342 thinking for grug, always good relief! grug always spend time in new place 343 learning tools around him to maximize productivity: learn tools for two weeks 344 make development often twice faster and often have dig around ask other 345 developers help, no docs 346 347 code completion in IDE allow grug not have remembered all API, very important! 348 349 java programming nearly impossible without it for grug! 350 351 really make grug think some time 352 353 good debugger worth weight in shiney rocks, in fact also more: when faced with 354 bug grug would often trade all shiney rock and perhaps few children for good 355 debugger and anyway debugger no weigh anything far as grug can tell 356 357 grug always recommend new programmer learn available debugger very deeply, 358 features like conditional break points, expression evaluation, stack 359 navigation, etc teach new grug more about computer than university class often! 360 361 grug say never be not improving tooling 362 363 [21]Type Systems 364 365 grug very like type systems make programming easier. for grug, type systems 366 most value when grug hit dot on keyboard and list of things grug can do pop up 367 magic. this 90% of value of type system or more to grug 368 369 big brain type system shaman often say type correctness main point type system, 370 but grug note some big brain type system shaman not often ship code. grug 371 suppose code never shipped is correct, in some sense, but not really what grug 372 mean when say correct 373 374 grug say tool magic pop up of what can do and complete of code major most 375 benefit of type system, correctness also good but not so nearly so much 376 377 also, often sometimes caution beware big brains here! 378 379 some type big brain think in type systems and talk in lemmas, potential danger! 380 381 danger abstraction too high, big brain type system code become astral 382 projection of platonic generic turing model of computation into code base. grug 383 confused and agree some level very elegant but also very hard do anything like 384 record number of club inventory for Grug Inc. task at hand 385 386 generics especially dangerous here, grug try limit generics to container 387 classes for most part where most value add 388 389 temptation generics very large is trick! spirit demon complex love this one 390 trick! beware! 391 392 always most value type system come: hit dot see what grug can do, never forget! 393 394 [22]Expression Complexity 395 396 grug once like to minimize lines of code much as possible. write code like 397 this: 398 399 if(contact && !contact.isActive() && (contact.inGroup(FAMILY) || contact.inGroup(FRIENDS))) { 400 // ... 401 } 402 403 over time grug learn this hard debug, learn prefer write like so: 404 405 if(contact) { 406 var contactIsInactive = !contact.isActive(); 407 var contactIsFamilyOrFriends = contact.inGroup(FAMILY) || contact.inGroup(FRIENDS); 408 if(contactIsInactive && contactIsFamilyOrFriends) { 409 // ... 410 } 411 } 412 413 grug hear screams from young grugs at horror of many line of code and pointless 414 variable and grug prepare defend self with club 415 416 club fight start with other developers attack and grug yell: "easier debug! see 417 result of each expression more clearly and good name! easier understand 418 conditional expression! EASIER DEBUG!" 419 420 definitely easier debug and once club fight end calm down and young grug think 421 a bit, they realize grug right 422 423 grug still catch grug writing code like first example and often regret, so grug 424 not judge young grug 425 426 [23]DRY 427 428 [24]DRY mean Don't Repeat Self, powerful maxim over mind of most developers 429 430 grug respect DRY and good advice, however grug recommend balance in all things, 431 as gruggest big brain aristotle recommend 432 433 grug note humourous graph by Lea Verou correspond with grug passion not repeat: 434 435 code concerns over time 436 437 over time past ten years program grug not as concerned repeat code. so long as 438 repeat code simple enough and obvious enough, and grug begin feel repeat/copy 439 paste code with small variation is better than many callback/closures passed 440 arguments or elaborate object model: too hard complex for too little benefit at 441 times 442 443 hard balance here, repeat code always still make grug stare and say "mmm" 444 often, but experience show repeat code sometimes often better than complex DRY 445 solution 446 447 note well! grug encourage over literal developer not take does work line too 448 serious, is joke 449 450 [25]Separation of Concerns (SoC) 451 452 [26]Separation of Concern (SoC) another powerful idea over many developer mind, 453 idea to separate different aspects of system into distinct sections code 454 455 canonical example from web development: separation of style (css file), markup 456 (html file) and logic (javascript file) 457 458 here grug much more sour faced than DRY and in fact write big brained essay on 459 alternative design principle [27]locality of behavior (LoB) against SoC 460 461 grug much prefer put code on the thing that do the thing. now when grug look at 462 the thing grug know the thing what the thing do, alwasy good relief! 463 464 when separate of concern grug must often all over tarnation many file look 465 understand what how button do, much confuse and time waste: bad! 466 467 [28]Closures 468 469 grug like closures for right job and that job usually abstracting operation 470 over collection of objects 471 472 grug warn closures like salt, type systems and generics: small amount go long 473 way, but easy spoil things too much use give heart attack 474 475 javascript developers call very special complexity demon spirit in javascript 476 "callback hell" because too much closure used by javascript libraries very sad 477 but also javascript developer get what deserved let grug be frank 478 479 [29]Logging 480 481 grug huge fan of logging and encourage lots of it, especially in cloud 482 deployed. some non-grugs say logging expensive and not important. grug used 483 think this way no more 484 485 funny story: grug learn idol [30]rob pike working on logging at google and 486 decide: "if rob pike working on logging, what grug do there?!?" so not pursue. 487 turn out logging very important to google so of course best programmer work on 488 it, grug! 489 490 don't be such grug brain, grug, much less shiney rock now! 491 492 oh well, grug end up at good company anyway and rob pike dress habit [31] 493 increasingly erratic, so all work out in end, but point stand: logging very 494 important! 495 496 grug tips on logging are: 497 498 • log all major logical branches within code (if/for) 499 • if "request" span multiple machine in cloud infrastructure, include request 500 ID in all so logs can be grouped 501 • if possible make log level dynamically controlled, so grug can turn on/off 502 when need debug issue (many!) 503 • if possible make log level per user, so can debug specific user issue 504 505 last two points are especially handy club when fighting bugs in production 506 systems very often 507 508 unfortunately log libraries often very complex (java, [32]why you do?) but 509 worth investing time in getting logging infrastructure "just right" pay off big 510 later in grug experience 511 512 logging need taught more in schools, grug think 513 514 [33]Concurrency 515 516 grug, like all sane developer, fear concurrency 517 518 as much as possible, grug try to rely on simple concurrency models like 519 stateless web request handlers and simple remote job worker queues where jobs 520 no interdepend and simple api 521 522 [34]optimistic concurrency seem work well for web stuff 523 524 occasionally grug reach for [35]thread local variable, usually when writing 525 framework code 526 527 some language have good concurrent data structure, like java [36] 528 ConcurrentHashMap but still need careful grug work to get right 529 530 grug has never used [37]erlang, hear good things, but language look wierd to 531 grug sorry 532 533 [38]Optimizing 534 535 ultra biggest of brain developer once say: 536 537 premature optimization is the root of all evil 538 539 this everyone mostly know and grug in humble violent agreement with ultra 540 biggest of big brain 541 542 grug recommend always to have concrete, real world perf profile showing 543 specific perf issue before begin optimizing. 544 545 never know what actual issue might be, grug often surprise! very often! 546 547 beware only cpu focus: easy to see cpu and much big o notation thinking having 548 been done in school, but often not root of all slowness, surprise to many 549 including grug 550 551 hitting network equivalent of many, many millions cpu cycle and always to be 552 minimized if possible, note well big brain microservice developer! 553 554 inexperienced big brain developer see nested loop and often say "O(n^2)? Not on 555 my watch!" 556 557 complexity demon spirit smile 558 559 [39]APIs 560 561 grug love good apis. good apis not make grug think too much 562 563 unfortunately, many apis very bad, make grug think quite a bit. this happen 564 many reasons, here two: 565 566 • API creators think in terms of implementation or domain of API, rather than 567 in terms of use of API 568 • API creators think too abstract and big brained 569 570 usually grug not care too deeply about detail of api: want write file or sort 571 list or whatever, just want to call write() or sort() or whatever 572 573 but big brain api developers say: 574 575 "not so fast, grug! is that file open for write? did you define a Comparator 576 for that sort?" 577 578 grug find self restraining hand reaching for club again 579 580 not care about that stuff right now, just want sort and write file mr big 581 brain! 582 583 grug recognize that big brain api designer have point and that sometime these 584 things matter, but often do not. big brain api developers better if design for 585 simple cases with simple api, make complex cases possible with more complex api 586 587 grug call this "layering" apis: two or three different apis at different level 588 complexity for various grug needs 589 590 also, if object oriented, put api on thing instead of elsewhere. java worst at 591 this! 592 593 grug want filter list in java 594 595 "Did you convert it to a stream?" 596 597 fine, grug convert to stream 598 599 "OK, now you can filter." 600 601 OK, but now need return list! have stream! 602 603 "Well, did you collect your stream into a list?" 604 605 what? 606 607 "Define a Collector<? super T, A, R> to collect your stream into a list" 608 609 grug now swear on ancestor grave he club every single person in room, but count 610 two instead and remain calm 611 612 put common thing like filter() on list and make return list, listen well big 613 brain java api developer! 614 615 nobody care about "stream" or even hear of "stream" before, is not networking 616 api, all java grugs use list mr big brain! 617 618 [40]Parsing 619 620 grug love make programming language at drop of hat and say [41]recursive 621 descent most fun and beautiful way create parser 622 623 unfortunately many big brain school teach only parser generator tool. here grug 624 usual love of tool is not: parser generator tool generate code of awful snakes 625 nest: impossible understand, bottom up, what? hide recursive nature of grammar 626 from grug and debug impossible, very bad according grug! 627 628 grug think this because while complexity demon bad for code base and 629 understand, complexity demon very good for generation of much academic papers, 630 sad but true 631 632 production parser almost always recursive descent, despite ignore by schools! 633 grug furious when learn how simple parse is! parsing not big brain only magic: 634 so can you! 635 636 grug very elated find big brain developer Bob Nystrom redeem the big brain 637 tribe and write excellent book on recursive descent: [42]Crafting Interpreters 638 639 book available online free, but grug highly recommend all interested grugs 640 purchase book on general principle, provide much big brain advice and grug love 641 book very much except visitor pattern (trap!) 642 643 [43]The Visitor Pattern 644 645 [44]bad 646 647 [45]Front End Development 648 649 some non-grugs, when faced with web development say: 650 651 "I know, I'll split my front end and back end codebase up and use a hot new SPA 652 library talking to a GraphQL JSON API back end over HTTP (which is funny 653 because I'm not transferring hypertext)" 654 655 now you have two complexity demon spirit lairs 656 657 and, what is worse, front end complexity demon spirit even more powerful and 658 have deep spiritual hold on entire front end industry as far as grug can tell 659 660 back end developers try keep things simple and can work ok, but front end 661 developers make very complex very quickly and introduce lots of code, demon 662 complex spirit 663 664 even when website just need put form into database or simple brochure site! 665 666 everyone do this now! 667 668 grug not sure why except maybe facebook and google say so, but that not seem 669 very good reason to grug 670 671 grug not like big complex front end libraries everyone use 672 673 grug make [46]htmx and [47]hyperscript to avoid 674 675 keep complexity low, simple HTML, avoid lots javascript, the natural ether of 676 spirit complexity demon 677 678 maybe they work for you, but no job post, sorry 679 680 react better for job and also some type application, but also you become 681 alcolyte of complexity demon whether you like or no, sorry such is front end 682 life 683 684 [48]Fads 685 686 grug note lots of fads in development, especially front end development today 687 688 back end better more boring because all bad ideas have tried at this point 689 maybe (still retry some!) 690 691 still trying all bad ideas in front end development so still much change and 692 hard to know 693 694 grug recommend taking all revolutionary new approach with grain salt: big 695 brains have working for long time on computers now, most ideas have tried at 696 least once 697 698 grug not saying can't learn new tricks or no good new ideas, but also much of 699 time wasted on recycled bad ideas, lots of spirit complexity demon power come 700 from putting new idea willy nilly into code base 701 702 [49]Fear Of Looking Dumb 703 704 note! very good if senior grug willing to say publicly: "hmmm, this too complex 705 for grug"! 706 707 many developers Fear Of Looking Dumb (FOLD), grug also at one time FOLD, but 708 grug learn get over: very important senior grug say "this too complicated and 709 confuse to me" 710 711 this make it ok for junior grugs to admit too complex and not understand as 712 well, often such case! FOLD major source of complexity demon power over 713 developer, especially young grugs! 714 715 take FOLD power away, very good of senior grug! 716 717 note: important to make thinking face and look big brained when saying though. 718 be prepare for big brain or, worse and much more common, thinks is big brain to 719 make snide remark of grug 720 721 be strong! no FOLD! 722 723 club sometimes useful here, but more often sense of humor and especially last 724 failed project by big brain very useful, so collect and be calm 725 726 [50]Impostor Syndrome 727 728 grug note many such impostor feels in development 729 730 always grug one of two states: grug is ruler of all survey, wield code club 731 like thor OR grug have no idea what doing 732 733 grug is mostly latter state most times, hide it pretty well though 734 735 now, grug make softwares of much work and [51]moderate open source success , 736 and yet grug himself often feel not any idea what doing! very often! grug still 737 fear make mistake break everyone code and disappoint other grugs, imposter! 738 739 is maybe nature of programming for most grug to feel impostor and be ok with is 740 best: nobody imposter if everybody imposter 741 742 any young grug read this far probably do fine in program career even if 743 frustrations and worry is always to be there, sorry 744 745 [52]Reads 746 747 grug like these: 748 749 • [53]Worse is Better 750 • [54]Worse is Better is Worse 751 • [55]Is Worse Really Better? 752 • [56]A Philosophy of Software Design 753 754 [57]Conclusion 755 756 you say: complexity very, very bad 757 758 759 References: 760 761 [1] https://www.redbubble.com/i/sticker/Programmer-Grug-by-colossalbreaker/42915272.EJUG5 762 [2] https://grugbrain.dev/#grug-on-complexity 763 [3] https://grugbrain.dev/#grug-on-saying-no 764 [4] https://grugbrain.dev/#grug-on-saying-ok 765 [5] https://en.wikipedia.org/wiki/Pareto_principle 766 [6] https://grugbrain.dev/#grug-on-factring-your-code 767 [7] https://grugbrain.dev/#grug-on-testing 768 [8] https://en.wikipedia.org/wiki/Unit_testing 769 [9] https://smartbear.com/solutions/end-to-end-testing/ 770 [10] https://en.wikipedia.org/wiki/Integration_testing 771 [11] https://en.wikipedia.org/wiki/Mock_object 772 [12] https://grugbrain.dev/#grug-on-agile 773 [13] https://en.wikipedia.org/wiki/No_Silver_Bullet 774 [14] https://grugbrain.dev/#grug-on-refactoring 775 [15] https://www.webopedia.com/definitions/j2ee/ 776 [16] https://www.techtarget.com/searchnetworking/definition/OSGi 777 [17] https://grugbrain.dev/#grug-on-chestertons-fence 778 [18] https://en.wikipedia.org/wiki/G._K._Chesterton 779 [19] https://grugbrain.dev/#grug-on-microservices 780 [20] https://grugbrain.dev/#grug-on-tools 781 [21] https://grugbrain.dev/#grug-on-type-systems 782 [22] https://grugbrain.dev/#grug-on-expression-complexity 783 [23] https://grugbrain.dev/#grug-on-dry 784 [24] https://en.wikipedia.org/wiki/Don%27t_repeat_yourself 785 [25] https://grugbrain.dev/#grug-on-soc 786 [26] https://en.wikipedia.org/wiki/Separation_of_concerns 787 [27] https://htmx.org/essays/locality-of-behaviour/ 788 [28] https://grugbrain.dev/#grug-on-closures 789 [29] https://grugbrain.dev/#grug-on-logging 790 [30] https://en.wikipedia.org/wiki/Rob_Pike 791 [31] https://www.youtube.com/watch?v=KINIAgRpkDA 792 [32] https://stackify.com/logging-java/ 793 [33] https://grugbrain.dev/#grug-on-concurrency 794 [34] https://en.wikipedia.org/wiki/Optimistic_concurrency_control 795 [35] https://en.wikipedia.org/wiki/Thread-local_storage 796 [36] https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html 797 [37] https://en.wikipedia.org/wiki/Erlang_(programming_language) 798 [38] https://grugbrain.dev/#grug-on-optimizing 799 [39] https://grugbrain.dev/#grug-on-apis 800 [40] https://grugbrain.dev/#grug-on-parsing 801 [41] https://en.wikipedia.org/wiki/Recursive_descent_parser 802 [42] https://craftinginterpreters.com/ 803 [43] https://grugbrain.dev/#grug-on-visitor-pattern 804 [44] https://en.wikipedia.org/wiki/Visitor_pattern 805 [45] https://grugbrain.dev/#grug-on-front-end-development 806 [46] https://htmx.org/ 807 [47] https://hyperscript.org/ 808 [48] https://grugbrain.dev/#grug-on-fads 809 [49] https://grugbrain.dev/#grug-on-fold 810 [50] https://grugbrain.dev/#grug-on-imposter-syndrom 811 [51] https://star-history.com/#bigskysoftware/htmx&bigskysoftware/_hyperscript&Date 812 [52] https://grugbrain.dev/#grug-reads 813 [53] https://www.dreamsongs.com/WorseIsBetter.html 814 [54] https://www.dreamsongs.com/Files/worse-is-worse.pdf 815 [55] https://www.dreamsongs.com/Files/IsWorseReallyBetter.pdf 816 [56] https://www.goodreads.com/en/book/show/39996759-a-philosophy-of-software-design 817 [57] https://grugbrain.dev/#lol-lmao