first it must work
This commit is contained in:
David Eisinger
20
content/notes/first-it-must-work/index.md
Normal file
20
content/notes/first-it-must-work/index.md
Normal file
@@ -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/
|
||||||
|
|
||||||
@@ -1,8 +1,5 @@
|
|||||||
---
|
---
|
||||||
title: "Misc."
|
title: "Misc."
|
||||||
date: 2023-05-11T23:00:26-04:00
|
date: 2023-05-11T23:00:26-04:00
|
||||||
draft: false
|
draft: true
|
||||||
---
|
---
|
||||||
|
|
||||||
* "First, it must work"
|
|
||||||
* Thoughts on priorities in software development
|
|
||||||
|
|||||||
855
static/archive/grugbrain-dev-dzqozx.txt
Normal file
855
static/archive/grugbrain-dev-dzqozx.txt
Normal file
@@ -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
|
||||||
Reference in New Issue
Block a user