This is a long winded way of saying we don't know how to write software, so we opt for 'ha ha, funny' instead.
The Grug Brained Developer
241–250 of 394 posts
Re: The Grug Brained Developer
#242This might be the best text on programming I've read since Why's Poignant Guide
Re: The Grug Brained Developer
#243As 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…
> 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. I think maybe Reaper fits the bill. http://reaper.fm/ As far as I can tell, it's two people.
Yeah but one of those people is the winamp guy. His cape is easily two extra people woven into a simple cloth fabric.
Re: The Grug Brained Developer
#244Earlier quoted context omitted.
developer see javascript think "looks frozen yogurt came out wrong end, but can do job". end up building castle of wrong end frozen yogurt. some say better than no castle. grug say why building with no-no soft serve in first place. (grug know answer: more shiny rock)
Please stop the grugposting, it is impossible to read.
always be grugposting
Re: The Grug Brained Developer
#245> 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…
> Either you are using a shitty language with a crap debugger or you need to learn how to use your IDE.
or you are working in a domain where debug builds are intolerably slow.
Re: The Grug Brained Developer
#246Earlier quoted context omitted.
Unfortunately, you don't have to work with bad PMs very often, to occasionally experience a year or more of misery due to their ineptitude. Good PMs are a bit of a paradox. They are immensely impactful and bring value to every project they touch. Yet they are also far overqualified for what is often a thankless job. I also have come to the view that even good PMs will rarely allocate the work that is truly impactful.…
What are the downsides to "going rogue" too often? Where do politics come into play here?
PMs promised the business X would get done because it was great. Now they have to explain developer Y didn't deliver that. Disappointment ensues and PM has to sell rogue work as also great (so why wasn't it planned instead of the other less great thing).
As someone already said, it's a thankless job and I empathize.
Signed: frequently rogue developer.
Re: The Grug Brained Developer
#247> 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…
You have the right insight I think. The thing about putting lots of effort into "refactoring" is that the code you refactor may actually not end up in the product at all. I think "prototyping" is better than "refactoring". Prototyping basically means that you write your app more than once. On the 2nd round you know what needs to be there and what not. You may have come up with a much better much simpler design for th…
I definitely think prototyping should be more common but the problem is I've been burned before.
"Just build a version of this thing as quickly as you can. Don't worry about performance or anything so much, the goal is to get an idea of what these features might actually feel like to use so this is just a proof-of-concept project"
Then "Oh hey we are going to give that proof-of-concept project to a client to try out and give us feed back. Don't worry they know it's just demo code at this point"....
Shortly after that though it's "The client wants these changes and you're who has to support it now. The client says it's slow, why is it slow? Client wants a new feature, add a new feature!"
And I'm left dealing with a horrid, awful, garbage piece of code because I'm the one that wrote it. I was explicitly told to write it entirely as a proof of concept and not as anything production ready which is why it's shit. This has happened to me more than once.
So until I have my PMs and Team lead tell me a thing is going to be a prototype/PoC and it turns out to actually be one at least once at this point I assume it's a lie
Re: The Grug Brained Developer
#248>grug brain developer not very smart, but grug brain developer program many long year and learn some things although mostly still confused
grug admit confusion is puzzle. grug blame complexity for confusion. grug make better relation to grug's target. grug reduce complexity and confusion. grug win woman and shiny rock.
Re: The Grug Brained Developer
#249Microservices grug wonder why big brain take hardest problem, factoring system correctly, and introduce network call too That made me laugh. The microservices madness of the past decade is now starting to settle down to more mature understandings, but there are still a lot people biting off large testing, operational, and data transactionality/ reporting costs. People often don't recognise beforehand the magnitude of…
I don't know if this is universal, but in my circles "microfrontends" are now all the rage. How do you bring up concerns with that in good faith? It's so obviously terrible that I've no idea where to begin.
I must run in different circles because I had to Google it. Probably the only thing that made me laugh audibly today.
Re: The Grug Brained Developer
#250> 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 amazing
These literally just get better and better. > big brain type system shaman often say type correctness main point type system, but grug note 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 need start shiney rock deposit ritual for grug similar program shaman so grug has more club. maybe some club have spik…
More
> grug warn closures like salt, type systems and generics: small amount go long way, but easy spoil things too much use give heart attack