commit 21f1c9b2009f00ff24e894a49abb496ca92068a7
parent be82887e3db35c36b7bfbe50dc65cfe8472d54c4
Author: David Eisinger <[email protected]>
Date: Fri, 12 May 2023 09:11:11 -0400
first it must work
Diffstat:
3 files changed, 876 insertions(+), 4 deletions(-)
diff --git a/content/notes/first-it-must-work/index.md 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
@@ -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
@@ -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<? super T, A, R> 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
