arch-spatula
commented
1 year ago 만약에 글또에 번역도 투고할 수 있다면 이 소재는 훌륭해보입니다.
Open arch-spatula opened 1 year ago
arch-spatula
commented
1 year ago 만약에 글또에 번역도 투고할 수 있다면 이 소재는 훌륭해보입니다.
arch-spatula
commented
1 year ago 만약 이글을 읽고 있다면 스펀지밥의 친구 뚱이의 목소리를 상상하면서 읽어주시기 바랍니다.
의역이 많고 어색한 부분이 많습니다. 최대한 원시인스러운 어조를 살리려고 노력했습니다.
더 멍청하고 이해가 잘 되는 표현이 생각나면 얼마든지 제안해주시기 바랍니다.
여기서 그럭은 원시인의 이름을 말합니다.
원시인 두뇌 개발자(The Grug Brained Developer)
스스로 자근 두뇌라고 자각하고 있는 비전문가의 조언(A layman's guide to thinking like the self-aware smol brained)
arch-spatula
commented
1 year ago 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
자유로은 나라다. 그리고 머리가 좋고 나쁘고는 결국엔 상관없다. 하지만 그럭은 너가 이 글을 재미있게 읽기 바란다. 그리고 오랜 프로그램 생활 동안 저지른 아주 많은 실수들통 해서 배우기 바란다.
이 곳에 모인 소프트웨어 개발에 관한 생각들은 그루그 브레인 개발자에 의해 수집되었습니다.
그루그 브레인 개발자는 그렇게 똑똑하지 않지만, 그루그 브레인 개발자는 오랜 시간 동안 프로그램을 하며 몇 가지를 배웠지만 대부분은 여전히 혼란스럽습니다.
그루그 브레인 개발자는 배운 것들을 작고 소화하기 쉬운 재미있는 페이지로 모으려고 노력했습니다. 이것은 어린 그루그뿐만 아니라 그루그 브레인 개발자 자신을 위한 것이기도 합니다. 그루그 브레인 개발자가 나이를 먹으면서 중요한 것들을 잊어버리는데, 예를 들어 아침에 무엇을 먹었는지 또는 바지를 입었는지 같은 것들을요.
큰 두뇌를 가진 개발자들은 많으며, 그 중 일부는 이런 것을 좋아하지 않을 것으로 예상됩니다. 시큰둥한 얼굴을 만들 것입니다.
그들은 자신들이 큰 두뇌를 가진 개발자라고 생각합니다. 많은, 많은 사람들은 아마도 이런 것을 좋아하지 않을 것입니다. 많은 시큰둥한 얼굴들이 있을 것입니다 (인터넷이 그런 곳이니까요).
(참고: 그루그는 한 때 큰 두뇌를 갖고 있다고 생각했지만, 어려운 방법으로 배웠습니다.)
괜찮습니다!
어느 정도는 자유로운 나라이고 결국은 별로 중요하지 않습니다. 하지만 그루그는 여러분이 즐겁게 읽고 그루그가 오랜 프로그램 생활 동안 저지른 많은 실수들에서 어떤 것을 배울지 기대합니다.
이 소프트웨어 개발에 대한 생각들의 모음은 거친 두뇌 개발자들에 의해 수집되었다
grug brain developer 그리 똑똑하지는 않지만, grug brain developer는 많은 해 동안 프로그램을 하고 비록 대부분 여전히 혼란스럽지만 몇 가지를 배운다
거친 두뇌 개발자는 당신뿐만 아니라 젊은 거친 두뇌 개발자가 나이가 들수록 아침 식사나 바지를 입는 것과 같은 중요한 것들을 잊어버리기 때문에 작고 쉽게 소화되고 재미있는 페이지로 학습을 수집하려고 노력한다
뇌가 큰 개발자들은 많고, 이것을 좋아하지 않을 것으로 예상되는 일부는 시큰둥한 표정을 짓는다
그들은 많은, 더 많은, 더 많은 두뇌 개발자들이라고 생각하며, 아마도 더 확실히 이런, 많은 시큰둥한 얼굴(인터넷과 같은)은 아닐 것이다
(참고: 그루그는 한 번은 머리가 좋다고 생각하지만 열심히 배운다.)
괜찮아!
자유로운 나라의 일종이고 하루의 끝은 별로 중요하지 않지만, grug는 당신이 재미있게 읽기를 바라고 아마도 많은, 많은 실수들을 grug가 긴 프로그램 삶에서 만들기를 바랍니다
arch-spatula
commented
1 year ago 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
복잡성대 티라노사우르스렉스랑 1대1 맞다이로 벨런스 게임시키면 그럭 티나리노랑 맞다이 고른다. 그래도 티라노는 보이기라도 한다
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
복잡성은 코드베이스로 들어온 악령이다. 마음은 착하지만 뭉둥이질이 가능하고 그럭 두뇌가 없는 개발자들과 PM들 때문에 들어온다. 이 사람들은 복잡성 악령을 두려워하지 않거나 때로는 복잡성 악령의 존재도 모른다.
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
그럭 다시말하고 또 자주 말한다. 복잡성 아주아주 나빠
The apex predator of Grug is complexity. 그럭의 최상위 포식자는 복잡성이다.
Complexity is bad. 복잡성 나빠.
Say again: 다시 말해.
Complexity is very bad. 복잡성 아주 나빠.
You say now: 이제 너도 말해.
Complexity is very, very bad. 복잡성 아주아주 나빠.
Given the choice between complexity or a one-on-one fight against a T-Rex, Grug would take the T-Rex: at least Grug can see the T-Rex. 복잡성대 티라노사우르스렉스랑 1대1 맞다이로 벨런스 게임시키면 그럭 티나리노랑 맞다이 고른다. 그래도 티라노는 보이기라도 한다.
Complexity is a spirit demon that enters the codebase through well-meaning but ultimately very clumsy non-Grug-brain developers and project managers who do not fear the complexity spirit demon or are not even aware of its presence sometimes. 복잡성은 코드베이스로 들어오는 영혼 악령이다. 착한 뜻을 가진 그러나 궁극적으로 매우 서툴러서 그럭 뇌를 가지지 않은 개발자들과 프로젝트 매니저들 때문에 들어온다. 이들은 복잡성 악령을 두려워하지 않거나 때로는 그 존재 자체를 모른다.
One day, the codebase is understandable, and Grug can get work done, everything is good! 어느 날 코드베이스가 이해할만하고, 그럭이 일을 처리할 수 있었고, 모든 게 좋았다!
The next day, it becomes impossible: the complexity demon spirit has entered the code, and it's a very dangerous situation! 다음 날은 불가능했다: 복잡성 악령이 코드로 들어왔고, 매우 위험한 상황이다!
Grug cannot see the complexity demon, but Grug senses its presence in the codebase. 그럭은 복잡성 악령을 볼 수 없지만, 코드베이스에서 그 존재를 느낀다.
The demon of complexity spirit mocks him, making changes here and breaking unrelated things there. "What?! Mock, mock, mock, ha ha! So funny!" Grug loves programming and does not want to become a shiny rock speculator like Grug's senior advisor. 복잡성 악령은 그를 조롱하며, 여기서 변경하고 저기서 관련 없는 것들을 망가뜨린다. "뭐야?! 조롱, 조롱, 조롱, 하하! 정말 웃겨!" 그럭은 프로그래밍을 사랑하며, 그럭의 시니어 조언자처럼 반짝이 돌 투기꾼이 되고 싶지 않다.
Clubs do not work on the demon spirit of complexity, and it's a bad idea actually to hit the developer who let the spirit in with a club: sometimes, Grug himself does it! 몽둥이로 복잡성 악령을 해치울 수 없으며, 악령을 들여보낸 개발자를 때리는 것은 나쁜 생각이다: 가끔은 그럭 자신도 그렇다!
Sadly, often Grug himself. 슬프게도 대부분 그럭 자신이다.
So Grug says again and says often: complexity is very, very bad. 그럭은 다시 말하고 자주 말한다: 복잡성은 아주, 아주 나빠.
arch-spatula
commented
1 year ago 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?
괜찮다. 얼마나 많은 반짝이 돌이 그럭에게 필요하겠는가?
The best weapon against the complexity spirit demon is the magic word: "no." 복잡성 악령을 퇴치하는 최고의 무기는 마법의 단어 "안 돼"다.
"No, Grug will not build that feature." "안 돼, 그럭 그 기능 안 만든다."
"No, Grug will not build that abstraction." "안 돼, 그럭 그거 추상화 안한다."
"No, Grug will not put water on the body every day or drink less black think juice. You stop repeating the ask now." "안 돼, 그럭 매일 몸에 물 안 묻히거나 검정 생각 주스를 덜 마신다. 이제 물어보지 말아라."
Note: This is good engineering advice but bad career advice. "Yes" is the magic word for obtaining more shiny rocks and being put in charge of a large tribe of developers. 참고로, 이것은 개발에는 좋지만 커리어에는 나쁜 조언이다. "네"라고 말하는 것이 반짝이돌을 더 많이 얻고 큰 개발 부족을 지휘하는 마법의 단어다.
Sad but true: Learn to say "yes," then learn to blame other Grugs when you fail. It's the ideal career advice. 슬프지만 현실이다. "네"라고 말하는 것을 배우고 망하면 다른 그럭 탓을 배우라. 최상의 커리어 조언이다.
But Grug must be true to Grug, and "no" is the magic Grug word. It's hard to say at first, especially if you're a nice Grug and don't like to disappoint people (many such Grugs!), but it gets easier over time, even though the shiny rock pile may not be as high as it might otherwise be.
그러나 그럭은 자기 자신에게 진실해야 하며, "안 돼"가 그럭의 마법의 단어다. 처음에는 말하기 어렵다, 특히 다른 사람을 실망시키는 것을 좋아하지 않는 착한 그럭이라면(그런 그럭이 많다!), 하지만 시간이 지날수록 더 쉬워진다. 반짝이 돌의 더 높아질 수도 있을지 몰라도요.
It's okay: how many shiny rocks does Grug really need anyway? 괜찮아요. 그럭이 정말 몇 개의 반짝이 돌이 필요한가요?
Note: The text appears to be written in a playful and humorous manner, using fictional characters and terms. The underlying message emphasizes the importance of saying "no" to manage complexity and not being afraid to do so even though it may not always lead to immediate career advancements or shiny rewards. It's a reminder to prioritize simplicity and effectiveness over the constant pursuit of more achievements.
arch-spatula
commented
1 year ago 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
가끔 타협은 필요하다. 없으면 반짝이 돌이 없다. 반짝이 돌이 없으면 공룡 고기도 없다. 안 좋다. 와이프 집에있는 어린 그럭이 생각나게 한다. 지붕, 먹을 거 등 필요하다. 50번 넘게 이야기한 복잡성 악령에 관심없다.
in this situation, grug recommend "ok"
그럭은 이런 상황 속에서는 "ok"라고 말하는게 좋아보인다.
"ok, grug build that feature"
"ok, 그럭 그 기능 만든다"
then grug spend time think of 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
그러면 그럭은 80/20 해결책을 생각하고 해결책을 대신 만든다. 80/20 해결책은 "80 필요한 것을 20 코드"라 한다. 해결책은 PM이 제시한 모든 요구사항을 충족하지 않을 수 있다. 또 조금 못생겼을 수 있다. 하지만 일단 동작하고 대부분 가치를 제공한다. 그리고 대개 복잡성 악령을 쫓아낸다.
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
아마 가끔 PM한테 말 안하는 것도 최선이다. 그리고 80/20 접근으로 처리한다. 용서가 허락보다 쉽다. PM의 머릿속은 나비와 같다. 가끔은 다른 그럭들 상대하면서 과로한다. 기능이 뭐해야 하는지 아니면 너머가야 하는지 아니면 관둬야 하는지 아니면 해고 당하는지 자주 까먹는다. 그럭 이런 경우 꽤 많이 봤다.
anyway is in project managers best interest anyway so grug not to feel too bad for this approach usually
결국 PM입장에서 최선이다. 그래서 보통 그럭은 이런 접근은 너무 기부니가 나쁘지 않다.
arch-spatula
commented
1 year ago 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
arch-spatula
commented
1 year ago 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
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
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 "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 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
arch-spatula
commented
1 year ago 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 no silver club fix all software problems no matter what agile shaman say (danger!)
arch-spatula
commented
1 year ago 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 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 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!
arch-spatula
commented
1 year ago wise grug shaman 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!
arch-spatula
commented
1 year ago grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too
seem very confusing to grug
arch-spatula
commented
1 year ago 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
arch-spatula
commented
1 year ago 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!
arch-spatula
commented
1 year ago grug once like to minimize lines of code much as possible. write code like this:
if(contact && !contact.isActive() && (contact.inGroup(FAMILY) || contact.inGroup(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(FRIENDS);
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
arch-spatula
commented
1 year ago 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:
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
arch-spatula
commented
1 year ago 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 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!
arch-spatula
commented
1 year ago 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
arch-spatula
commented
1 year ago 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 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 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, 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
arch-spatula
commented
1 year ago 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
optimistic concurrency seem work well for web stuff
occasionally grug reach for thread local variable, usually when writing framework code
some language have good concurrent data structure, like java ConcurrentHashMap but still need careful grug work to get right
grug has never used erlang, hear good things, but language look wierd to grug sorry
arch-spatula
commented
1 year ago 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
arch-spatula
commented
1 year ago 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!
arch-spatula
commented
1 year ago grug love make programming language at drop of hat and say 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: 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!)
arch-spatula
commented
1 year ago arch-spatula
commented
1 year ago 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 htmx and 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
arch-spatula
commented
1 year ago 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
arch-spatula
commented
1 year ago 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
arch-spatula
commented
1 year ago 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 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
arch-spatula
commented
1 year ago grug like these:
그럭 이런거 좋아한다.
Worse is Better Worse is Better is Worse Is Worse Really Better? A Philosophy of Software Design
arch-spatula
commented
1 year ago you say: complexity very, very bad
너도 말한다. 복잡성 아주 아주 나쁘다
글쓰기 주제
참고할 자료