The Grug Brained Developer

Post by eurasiantiger » Thu, Jun 23, 2022, 5:46 AM UTC

jeffparsons wrote: post #157

maest wrote: post #87

> 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…

I think I have a near-pathological experience of coding these days that just so happens to make me the exact kind of developer you want: 1. I still want to produce excellent code that will deliver value, work predictably, be fast, and be robust against future grugs. I am driven to do this by forces I don't understand myself. 2. I also feel a deep dread of being stuck with a piece of code for any longer than absolutel…

Post by thaneross » Thu, Jun 23, 2022, 5:49 AM UTC

zero_shift wrote: post #128

maest wrote: post #87

> 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…

It's a question of incentives and accountability. PMs aren't usually accountable when their shortcuts come and bite the team further down the line. Developers feel the pain instead. PMs won't be honest with the business that they sold an undercooked product. Need to suddenly scale up that "pragmatically" designed database? I know in my heart that too many PMs will _never_ manage expectations with their superiors if t…

Post by [deleted] » Thu, Jun 23, 2022, 6:02 AM UTC

agentultra wrote: post #270

pkulak wrote: post #95

Earlier quoted context omitted.

Whoa now, I was with you until you seemed to imply that "simple" software means shitty code. Simple in this context means a solution with as little complexity as possible. Hopefully written elegantly and carefully, with lots of thought for future maintenance and readability. Maybe you use a 10-year-old, constantly maintained and thoroughly tested library to do 90% of the work instead of writing everything yourself. W…

> Hopefully written elegantly and carefully, with lots of thought for future maintenance and readability. Those are fine things to value even if they are highly subjective. You might think it’s easier to read a while loop with a handful of mutating variables and a few branches. I might disagree. I think it’s easier to read an accumulating function that uses traverse. It’s wishful thinking that we should both hold the…

Post by JetAlone » Thu, Jun 23, 2022, 6:06 AM UTC

sdfhdhjdw3 wrote: post #93

Too difficult to read, can't be bothered. Does this style really appeal to anyone at all?

Post by rob74 » Thu, Jun 23, 2022, 6:13 AM UTC

eurasiantiger wrote: post #278

galaxyLogic wrote: post #124

Earlier quoted context omitted.

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…

Refactoring is probably a sign of problems, unless by refactoring one means ”giving abstract structure to yet unstructured code”, i.e. factoring for the first time. That needs to happen after feature-completeness, but before a project goes into maintenance.