Here are some notes, ideas and links to talks mainly (and some blog posts) on productively producing software. They are not intended for beginners or anyone happy to be mediocre. I have found them useful or insightful. At the time of writing this is an extremely early draft.
I'm assuming you can program proficiently in at least one language and framework.
I first came across this idea from: What's not to love about Reason, Kiera Hodgkison. In the talk Kiera introduces the idea of cognitive load: basically we have a finite amount of mental resources. Some amount will be taken up by the frameworks/systems/tools we use. Whatever is left over is what we have to understand, tackle problems and build solutions. I find this idea hugely practical in thinking about lots of approaches. In particular thinking about offloading things onto a type system, ensuring encapsulation, not mutating things where possible.
Context is nearly everything
Depending on the context completely different approaches may be preferred. For beginners a simple, clear rule based approach might be invaluable. But we should try not get stuck in this mindset. When working on large projects a high level of test coverage is good. See Justin Searl's recent talk on being 'selfish'.
Everything is not just 'a trade off'
One frustrating and very British idea is something along the lines of: every solution is roughly equaly valid, it is just a matter of trade offs. This is nonsense. Like giving equal time to idiotic ideas like climate change denial or Brexit. Some stuff is just bad (or at least worst than other solutions). While the multidimensional nature of any reasonable evaluation means there isn't going to typically be a 'best' solution there are often going to be Pareto improvements to be made e.g. moving from Java to Kotlin is almost always going to be a good idea.
Size, significance, sign
3 key things to consider in empirical research are the size of an effect (how big), the significance (how confident we can be about it) and the sign (is it good or bad). This can and should be applied to ideas and approaches in software. It forces us to quantify how big and in what direction an effect something will have and how strongly we believe it. I'm often puzzled by how certain many people are about a particular best practice or approach.
Best practices are dead, or at best local optima
I love React's idea of 'rethining best practices'. Often these are just local optima... we should be willing to consider quite different approaches, especially if the context has changed.
Dynamic heuristics not static best practices
Often in organisations we want to figure out the approach. This has benefits, but means we may miss out on incrementally and radically better solutions. Taking an idea from search: early on we definitely don't want to go all in on a single approach. It may be globally very un-optimal. Better to pursue multiple diverse approaches, learning what works and evolving. Perhaps we'll end up combining multiple solutions.
While we might spend most of our time at computers usually people are the most important thing.
UX and DX, sacrifice either and you are fucked
(From Dan North, link to follow) There are different stages of learning: Novice, Advanced Beginner, Competence, Proficient and Expert. But it gets worse: when you have two people you might have two different levels. At a lower lever you want very simple, easy to follow rules and guidance; but at an expert level this typically holds you back.
Learn all the languages
Always Rethinking Best Practices
I'm a former academic, puzzled by the interest among a, admittedly tiny and self-selecting, group of developers in academic computer science. Here's the thing academic papers and talks, with exceptions, are really boring. The whole system is set up to very zero sum, you give talks and write papers for your enemies (people in very similar research areas, competing for publications and grants). With the caveat out of the way here are a few talks of a more academic nature that might be useful.
In no particular order