vaughandroid

"...if governments would abandon the goal of aggregate economic growth across all sectors..."

You've obviously thought about this topic quite deeply - have you heard any realistic proposals on how to achieven this? I have yet to hear any, and until I do I'll be devoting my energy to changes that have at least some chance of being enacted, like a carbon tax.

You've obviously thought about this quite a bit... Do you have any ideas as to how projects could avoid this problem?

Please could someone explain the "Bob Martin Sudoku Solver energy" reference?

I imagine that's a good place to be, but I don't know if it's possible without going through a lot of trauma and building up substantial mental scar tissue.

Getting on 15 years into my career and not sure I'll ever get there. On the other hand, I actually work on a project I care about and for a company that treats me like a human being and not a "resource". Think I'm OK with that.

I'm not a fan of this post as it seems to be pointing the blame at the wrong thing: the problem isn't the shiny new thing, it's the environment that allowed the situation to develop: people working in isolation, key decisions being made by individuals in private, lack of oversight.

There are plenty of arguments in favour of allowing teams to use shiny new tech. Done responsibly, it can help with engagement, job satisfaction, retention, and recruitment.

IIRC the meaning of that was specifically someone that was willing to bodge things in order to ship - someone that prioritised getting it done over getting it "done right" (whatever that means). I think it's a little different from the "plumber" label.

FWIW I like both terms. I just wouldn't use them interchangeably. :)

Cautionary Tales is my favourite podcast. Most episodes concern either interesting (mis)use of statistics or cognitive biases, both of which are topics I find inherently interesting, but Tim Harford and team do a brilliant job of the storytelling too.

Tim Harford's other podcasts are great too - More or Less, and 50 Things Which Made the Modern Economy.

Does anyone have any recommendations along similar lines?

"Personally I like dark and gritty." On the offchance you haven't given Joe Abercrombie a try, you really ought to.

Thank you for sharing. Intuitively I think your point makes a lot of sense. I don't think there's really enough data to really prove it, but I liked your approach.

I do think there's other stuff going on as well though. For example, newer languages are often designed to address perceived problems with existing popular languages. I'm a long-time Kotlin and Java developer, and Kotlin feels a lot like Java 2.0 - it specifically addresses a number of pain points people were experiencing with Java. So of course I'd rather be working with Kotlin, and going back to Java can feel like a drag.

We use at both in my department at work. They is some overlap, but since each have different strengths I think they work well together.

RFCs are great for capturing discussions and exploring ideas in depth. You can get deep into the details if needed. ADRs are all about capturing a decision. They should capture the important bits of context and consequences, but without a huge amount of detail.

In terms of the process for producing these documents, if a decision is straightforward we will go straight to writing an ADR. If there are multiple options or we want to explore some corner cases, we'll start with an RFC. An ADR is often part of he output of an RFC which reaches consensus, but not always. Related RFCs and ADRs include links to one another.

If people are looking to get up to speed on something, their first port of call is the ADRs. If they have concerns, disagree with a past decision, or simply want to know more then they can dig into the RFCs.

That sounds like a tricky message to deliver:

1. It could easily come across as "my time is more important than yours". 2. Depending on what they are asking for and how urgently they are treating it, they might not want a lesson in solving their own problems. They just want help fixing the problem. 3. A lot of people are self-centred. Of course their problem should be your top priority and you should drop what you're doing! /s

...So yeah, I'd be surprised if it didn't get a bad reaction sometimes. Perhaps seek to promote this approach when their problem is resolved. I would imagine they would be more receptive then.

I would say yes they are, in general. The title of the post is an absolute, but as the author says in the second paragraph:

> As with all HeuristicRules, this is not a rule that applies 100% of the time. Code is generally clearer and easier to maintain when it does not use globals, but there are exceptions.

For me, the root of the problem with them is that they introduce coupling (or to put it another way, they break modularity). When you introduce global state, you introduce it everywhere. In reality there are probably only a handful of places that it relates to, but "is the global state involved here?" becomes a question you need to ask yourself whenever you write/update any part of the code.

The same argument can apply at more fine-grained levels. If you introduce a module-level variable, you need to keep it in mind whenever dealing with any code in that module. Similarly for class-level and instance-level variables.

There is a trade-off: ease-of-access and clarity vs the extra cognitive load you are introducing to every part of the scope. In my opinion, that balance determines whether a variable is good or bad. For any non-trivial piece of code, the sum almost always works out on the side of reducing the cognitive load.