As 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…
The Grug Brained Developer
231–240 of 394 posts
Re: The Grug Brained Developer
#232Earlier quoted context omitted.
I'm sorry that you've apparently only worked with bad PMs.
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.…
> Some of the best work of my career has been when I've gone off piste and prototyped something that has surprised my managers or disrupted the way a team thought they had to work.
When I came to this realization myself, it was both sad (losing faith in the system which I had, until then, trusted to allocate work effectively) and liberating (I can just trust myself and do what I believe to be best)
Re: The Grug Brained Developer
#233As 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 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. you want eat cake and have cake.
...and now you have 2 cakes.
Re: The Grug Brained Developer
#234> 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…
PMs represent the customer. That being the case, they push hard for features and leave it to engineers to keep features coming out at predictable speed.
Engineers represent themselves. They are accountable for feature delivery speed and product stability. That being the case they push hard for hardening, automating, and maintaining.
The two have to balance each other out. PMs need to push to keep Eng focused on growing business value, otherwise the company will never make money. Eng needs to push PMs to focus on long term product delivery, otherwise customers will leave as quickly as they come, and new one's will stop showing up, no matter how pretty the UI looks.
If you had a team of engineers like you describe it would only be heaven for about 6 months in my experience. I've seen two separate teams of engineers run this way. Everything was kick-ass until it was suddenly horrible and engineers started bailing.
Re: The Grug Brained Developer
#235Nice article but a bit tedious to read improper English. It is fun for paragraph or two but wears out rather quickly. If you got something important to say why not just say it as clearly as possible?
grugspeak imply that message self-evident and that complexity is not really in world but invented by badspeakpeople but world is complex, and babytalk is denial
I am groot
Re: The Grug Brained Developer
#236Earlier quoted context omitted.
Hehe, good one! Oh, you're serious? :D
If it's so bad, you're welcome to write your applications in vanilla JavaScript, with no shims, in flat files without modules calling 1998 era DOM APIs. There's a reason most people don't, however.
Meh, grug just and ES6 at past job. Way less headache not needing build crap, just one blub maven Spring repository. Big ball of whatever may be seen as bad practice, but is honestly no worse than "best practices". Maybe not best for resume oriented development.
Guess I had the luxury of only needing to support one browser.
Re: The Grug Brained Developer
#237>> over time grug learn this hard debug, learn prefer write like so:...
I thought grug would say, "grug used to use debugger but now grug stare at code until grug understand code - debugger bad brain drug for grug".
Re: The Grug Brained Developer
#238This is like if Code Monkey[1] wrote a whole manifesto.
Re: The Grug Brained Developer
#239> 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 spike or some club have more big size. me no idea what grug need but me know grug need more.
me is mere artoo not big brain like grug but me has big sympathy for grug. like grug test shaman make artoo skeptical. like grug artoo wish spread word of grug. grug too is shaman. artoo most good disciple grug.
Re: The Grug Brained Developer
#240Earlier quoted context omitted.
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…
Hi. Former engineer turned PM here. Wow, you're spinning some wild stereotypes here, and while some are based in truth (as are all good stereotypes), I'm going to take issue with this: > 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 many PMs will _never_ manage expectations with their superiors if…
> Anyway, it might be good to talk to your PMs and not assume they're evil villains.
I've always thought PM's to be more or less aliens with a ray gun tapping at their watch. Communicating with them goes nowhere since they don't empathize with your point of view. The only thing they're concerned with is when something's going to get done. The only form of motivation is threat of existence in the company.
> While I've certainly seen incompetent, bureaucratic and/or poorly incentivized PMs, I don't think I've ever met one who wants to throw their developers under the bus to get a job done.
Perhaps, it's also possible you've never worked at enough shops to see it.
> one reason PMs might not "care" about scaling up that database, is that it almost never needs to be scaled. Seriously.
You're not the one going to be called at 4am when postgres takes a dump. If you volunteer to cycle into the on-call hours, I'd feel more compassionate for your point of view. Until PM's do this, I decline to see it that way.
I guess I feel like the PM is worthless position unless the PM is writing code along side the team, and can fully appreciate the technical problems -- and more importantly -- offer technical solutions.