Notices by Martijn Faassen (faassen@fosstodon.org)

Wherein I have a few words to say about best practices in software development https://blog.startifact.com/posts/question-best-practices/

#programming

@datarama

@inthehands

I really love getting context myself. Though perhaps others might be impatient and want to get to the thing already. But the context is part of the thing.

@grimalkina

@nshephard @diazona @inthehands @jenniferplusplus

Yes, I think so. And against uncertainty, which is related.

@nshephard

@inthehands @grimalkina @jenniferplusplus

Not a fan of the term either. "Best practices" can also devolve into dogma to be applied in all contexts.

@diazona

@nshephard @inthehands @grimalkina @jenniferplusplus

When people say "X is a best practice" any context is at best implied.

> Whereas if you're using the best practice, it can't really be argued that you should have been using a different practice instead which would have prevented the thing from going wrong.

"Nobody ever got fired for using the best practice"?

If something goes wrong, and this can be solved or prevented, improvement is possible, isn't it?

@diazona

@nshephard @inthehands @grimalkina @jenniferplusplus

In the first case labeling a practice "best" may prevent learning or change for the better.

For the second case, if there are trade-offs that depend on context, then you pick a practice that fits them to the best of your ability, and I see little value in labeling it "best".

You may have practices to follow as a requirement - say, for space hardware. One could call this a best practice.

@grimalkina

@nshephard @diazona @inthehands @jenniferplusplus

Meta stuff leading to improved processes and people are indeed more likely to be generally applicable good practices. Like "get enough sleep" or "fix the system rather than individual".

But "do code review when an individual submits changes" is way dodgier already. So is "use microservices". And I am pretty sure many people consider both best practices.

@inthehands

@grimalkina @jenniferplusplus

I love this! The idea that confusion is actually a productive state that should be accepted as part of learning is one I embrace. I imagine you wrote this as you have experienced people who are scared by this confusion? Related to fixed/growth mindset.

@inthehands

@grimalkina @jenniferplusplus

Mastery also implies a summit of skill, whereas there is always more to learn. I think people who are great at something through continuous self motivated application are also often the most aware of what they want to do next that they aren't good at yet, or what they cannot do.

@grimalkina

@jenniferplusplus @inthehands

I am very much talking about intrinsic motivation. I enjoy learning new stuff, doing stuff I couldn't do before, write code I am proud of, find good ways to express and share my experiences and insights with others. And indeed deliver something others appreciate.

"Best" implies comparison. I look at others who impress me, as examples to learn, or just to marvel, though I admit sometimes it's nice if people are impressed by what I can do.

@jenniferplusplus

@inthehands @grimalkina

I don't think I could function in a performance oriented organization anymore. I did once, in school. It just sounds so stressful.

Not that the mastery goal doesn't have its own stressors. I can give 110% for a while because I know how to manage myself into it and have learned the skills. Because I really want to make something work and improve. But it costs me too.

This is neat: someone has used PyPy by accident and they didn't even notice as it just works

https://utcc.utoronto.ca/~cks/space/blog/python/PyPyQuietlyWorking

#python

@futurebird
I read twostopbits partially for this reason: simple systems that can be understood. The other reason is nostalgia.

http://twostopbits.com/

@mcc
Shall I simulate being one of those systemd haters for you? Shouldn't be necessary as I am sure they are showing up

My motivations in picking a #programming language have shifted over the years:

BASIC - it was there
Assembly - fast
C - fast
C++ - abstraction (oop), fast
Python - easy, dynamic, abstraction (oop)
JS - only game in town on fe
TS - avoid bugs early (object is not a function)
Rust - fast, avoid bugs early, abstraction

What were your motivations?

@arendjr
I think you are talking about the risks of premature organisation. I am indeed not proposing you create empty libraries in advance speculatively; that would be terrible. Or build the framework before you build the application.

This process needs to be an active integrated part of developing an application. It can happen in all stages but the needs of application needs to drive it.

One trick in problem solving is that generalizing it can sometimes make it easier to solve.

Reuse is not the primary goal of creating libraries for your application, (though it helps to pretend it is): separation is.

A little known fact is that libraries and frameworks are in many ways easier than applications; the main hard part is getting the boundaries and abstractions right. Everything else is easier. In particular, you can do TDD more easily!

Getting traction with TDD in production code is hard and this I found helps a lot.

2/2

#programming #tdd

The architectural trick I use over and over again to help make more production code more maintainable is the "pull it into a library" move. Extract/create functionality as a separate library, with its own API, tests, docs.

1/2

#programming #tdd

@darnell

@Mina @bertwells @futurebird

If a kid is spanked, isn't there a risk they learn violence is a solution?