[deleted]
The Grug Brained Developer
111–120 of 394 posts
Re: The Grug Brained Developer
#112> 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 know debugger good but grug often realize grug no need debugger on smaller cases and only run it when grug need it, grug try simple code like print and log first, if grug sad and no underst…
Relying on log and print statements is like giving up. I would claim that's not simplicity, that's inexperience, but I have no idea what language you're referring to. Sometimes I do it with JavaScript when I didn't setup the project, it's using a framework I don't know and I'm not willing to spend the time figuring out how to get real debugging working so there are caveats. But you definitely should not be doing that…
You can't run a system handling real money or real medical records in a debugger. Or if you are, you're violating a bunch compliance standards and will get sued into oblivion.
Re: The Grug Brained Developer
#113> 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. In my experience, I have to fight to keep my devs from over engineering their solutions and just get something going. I'd love to work with a dev who's happy to think about how to most quickly deliver value and who's willing…
Do you understand the basic reasons why? Developers are on the hook for bad code and complexity. Rushed code makes feature work take longer, it makes working more irritating, and creates operational work. Everyone is burned by a team that does these things poorly at some point in their career and it drains the life out of you. They need to trust that you'll schedule time to go back and do things correctly. Clean up t…
You nailed it.
Re: The Grug Brained Developer
#114Wise fellow, that grug.
Re: The Grug Brained Developer
#115Earlier quoted context omitted.
Undoing someone's copy-pasted for-loops and while-loops is called "factoring" and undoing someone's bad abstractions is called "re-factoring" and is about 10x as slow. At this point in my career I have seen way more crappy abstractions and needlessly abstracted code than grug-brain code. And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reaso…
> And, to be brutally honest, as much as I love those functional combinators, first-class functions, streams, etc, they suck to reason about. > Sometimes loops are better! That I think is backwards. A loop could be doing literally anything - it probably is futzing with global variables - so there's no way to reason about it except by executing the whole thing in your head. A map (or mapA) or a fold (or foldM) or a fi…
I like to write loops where they follow the functional map/filter/reduce paradigm where they don’t mutate anything except some initial variables you “fold” over (defined immediately prior to the loop) and which are treated immutable (or uniquely owned) after the loop.
I find this has good readability and by containing the mutation you can reason about it “at a distance” quite simply since further away it’s for-intents-and-purposes pure code.
What you might lose are the compiler-enforced guarantees that a functional language gives you. Some languages give you the best of both worlds - with rust you could put this in a pure function (immutable inputs, owned outputs) and the borrow checker even reasons about things like this within a function body.
Re: The Grug Brained Developer
#116Grug no talk of estimation spirit demon.
Re: The Grug Brained Developer
#117Re: The Grug Brained Developer
#118As funny as this post is to read, I don't want to see yet another developer say "complexity bad". I want to see a company deliver high-quality products with very few bugs at a fast cadence, and continue to make major changes long into the future without slowing down. _THEN_ I want developers from that company to share their opinions about how they do it. Do such companies/products even exist? Software is so bad these…
Complexity doesn't necessarily slow down feature development. In my experience it reduces the project longevity. At some point it will be too big and complex to rewrite all the while more glaring problems emerge and cannot be dealt with.
Re: The Grug Brained Developer
#119> 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 know debugger good but grug often realize grug no need debugger on smaller cases and only run it when grug need it, grug try simple code like print and log first, if grug sad and no underst…
Relying on log and print statements is like giving up. I would claim that's not simplicity, that's inexperience, but I have no idea what language you're referring to. Sometimes I do it with JavaScript when I didn't setup the project, it's using a framework I don't know and I'm not willing to spend the time figuring out how to get real debugging working so there are caveats. But you definitely should not be doing that…
It totally depends on the case at hand!
I use debugger all the time when I run into pointer related issue, or some checking some tensors in deep neural nets etc.
In some cases, I throw debugger just to see what is going on.
However, I have had few cases where debugger slowed me down. If you are doing something in graphics that requires you debugging issues that spans multiple frames, sometimes it's easier to notice the value over a period of time and see why things are behaving that way. From there you can reason what might be causing the issue. It can be done frame per frame inserting multiple breakpoints, recording them and viewing them accordingly! However, I prefer simple logs in such cases.
I have used both approaches as time demanded.
Re: The Grug Brained Developer
#120Earlier quoted context omitted.
> frontend Complexity Demon having a grip on the entire industry Is frontend web development more complex than it needs to be? If so, how?
npm, babel, webpack, module compatibility, et al
You are free to develop everything in vanilla JavaScript and run your coded scripts straight in the browser. Very non-complex.
But the team that uses npm, babel, webpack etc will crush you both on development speed and stability.