Grug took their muse too far. Had much hard time try parse meaning from grug.
The Grug Brained Developer (2022)
161–170 of 201 posts
Re: The Grug Brained Developer (2022)
#162Earlier quoted context omitted.
> The worst sort of tests are integration tests which secretly depend on another integration test having run first That's an example of bad integration tests. Well engineered integrations tests don't do that.
It's a property of the code under test, not the tests themselves. If the system is crappy/stateful/implicit, and you somehow manage to write nice/clean/stateless integration tests against it, I'd argue that the tests won't be close enough to the expected running of the system to tell you anything useful about it.
Nice and clean in the context of an integration doesn't mean no state it just means no state outside of the context of that test.
If I set up an integration test that sets up a database from scratch and tears it down and tests only the behavior of the app in that rigidly defined context, then yes, it will be useful. It will tell you how the code behaves in the scenario you've created.
Bad integration tests will share state with each other - e.g. by using the staging DB.
Re: The Grug Brained Developer (2022)
#163It's weird how smart people are naturally attracted to complexity like moth to a flame. It takes years to learn to fight the urge to over-engineer. Once you learn to see it though, it's hard to ignore. Now I can tell instantly if code is over-engineered. Unfortunately It seems like maybe 99% of code is over-engineered. The developer's incentive to maximize their own lock-in factor and billable hours are powerful forc…
I sometimes over-engineer / over provision my own pet projects as a way of learning / exercising some technology that's new to me.
Re: The Grug Brained Developer (2022)
#164Earlier quoted context omitted.
There’s also a third reason: a form of anti-intellectualism where you think that designs that are hard to derive are intrinsically more complex than just doing the straightforwardly obvious thing.
why is this ”anti-intellectualism”? intuition is a strong quality to have in your code.
What is intuitive is strongly dependent on what you have been taught. For example, if you have only been taught to use loops, then iterator functions like map and filter seem less intuitive. However, once you have learned them, iterator functions are dramatically more intuitive than loops.
Re: The Grug Brained Developer (2022)
#165Grug Inc. -- Fantastic! I really enjoyed reading this and feel like im guilty of unleashing the complexity spirit demon, even though im not even a big brain. Out of curiosity, are there any programming languages that naturally steer people away from complexity? but still "get the job done".
Of the languages I’ve used, Go comes closest. The language is small and boring, but it means I stay focused on the problem and hand instead of getting fancy.
There are two ways that a system can get unworkably complex. The most obvious is to overengineer and introduce too many excessively complex abstractions. However, it is equally harmful to become dogmatically obsessed with using the most "straightforward" implementation when more sophisticated approaches would make things easier to understand.
I have not used Go, but what I have heard makes it seem like it is designed in a way that would encourage the second approach.
Re: The Grug Brained Developer (2022)
#166I have a beef with the typing section: > 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 Juniors at my job routinely ship code that breaks due to null access in production, Sentry tells me. During intensive development periods that's about 1 detected null-a…
> That's just rude and uncalled for. But is it wrong? Based on your stated experience, not even you seem to buy into type systems that force formal proofs – instead accepting lesser type systems that make tradeoffs between catching some problems (along with, most importantly, providing popup magic!) and not bogging you down in every little detail needed to prove total correctness.
I think that it might be misguided. Excessively prioritizing how quickly you ship code is probably the single quickest way to summon the complexity demon.
Re: The Grug Brained Developer (2022)
#167If you need nuanced behavior, you need a complex controller. And you always need more nuanced behavior, this is the inherent nature of software development. Sometimes the appearance of simplicity is achieved by making the behavior simpler (e.g. dropping the support for old versions, not implementing parts of the specification, and so on). This is degradation, not simplicity. The right simplicity is an art of having t…
i don't think grug actually disagrees with you here but takes the position that skill both can't be counted on and doesn't scale. And this matches my own dev experience cathedrals of complexity pale into comparison that code that's easy to throw away and rewrite to meet changing requirements or scope.
My experience has been that the powers that be generally won't give developers time to rewrite to meet changes in the requirements. Personally as I see it:
iterative development with time to rewrite > cathedral development > "iterative" development without time to rewrite
I think that most teams actually do "iterative development without time to rewrite" so cathedrals of complexity would actually be an improvement.
Re: The Grug Brained Developer (2022)
#168I love the section on tests. It really is exactly what I've come to learn over the years. Integration tests are the sweet spot for finding bugs. Mocks tend to over complicate things (I still use them sometimes but I avoid using them systematically) and unit tests are too brittle in face of refactoring whereas integration tests help with refactoring.
For what it's worth, the conclusion that I've come to with respect to tests is:
If a team has simple code, then tests can help a lot. However, if a team does not have simple code (and usually they don't) then it's better to spend time simplifying the code than writing tests.
Re: The Grug Brained Developer (2022)
#169Earlier quoted context omitted.
> That's just rude and uncalled for. But is it wrong? Based on your stated experience, not even you seem to buy into type systems that force formal proofs – instead accepting lesser type systems that make tradeoffs between catching some problems (along with, most importantly, providing popup magic!) and not bogging you down in every little detail needed to prove total correctness.
I think that it might be misguided. Excessively prioritizing how quickly you ship code is probably the single quickest way to summon the complexity demon.
Or maybe naïve would be more accurate? I could see how strict typing might not be needed if the developers write simple code on their own. However, in practice strict typing is necessary to protect yourself from developers who are unwilling to put in the effort to write simple code.
Re: The Grug Brained Developer (2022)
#170I love the section on tests. It really is exactly what I've come to learn over the years. Integration tests are the sweet spot for finding bugs. Mocks tend to over complicate things (I still use them sometimes but I avoid using them systematically) and unit tests are too brittle in face of refactoring whereas integration tests help with refactoring.
I think a lot depends on what you think a "unit". If you use a leaf function as your unit I think that that's often much too low level but larger modules with relatively stable interfaces can make good units that are productive to test.