MiyamotoAkira

6 ms·

1.
by MiyamotoAkira 3y ago
That's interesting. Whenever I have an issue with a flag it gets picked up on dev/test/uat environments (all gets tested, especially around the code behaving the same as before with the flag off). The code change never reache
2.
by MiyamotoAkira 3y ago
Regarding checklist people like Hollnagel, Wears, Braithwaite, Dekker, ... have done a bit on investigation (Hollnagel mostly on Healthcare, Dekker started on air industry but spread from there). Read the "Safety-I vs Safety-II" p
3.
by MiyamotoAkira 3y ago
I've used quite extensively Pair Programming, and at its best is better when both people tend to be senior, as you can bounce design ideas out of each other much easier, and is more likely that a bad decision (or test, or ...) gets cau
4.
by MiyamotoAkira 3y ago
Going from nothing to some quality control is always an improvement. The point being made is that is not as good as other options.
5.
by MiyamotoAkira 3y ago
After having used both PRs and Pair programming with a strong CI setup I found the later much better for quality, design and efficiency.
6.
by MiyamotoAkira 3y ago
Pascal had indexes starting at 1 too. Starting indexes at 0 makes sense when you want to enable the developer to manipulate memory (for example, C) Indexes starting at 1 matches with a more natural ordinal sequencing.
7.
by MiyamotoAkira 3y ago
Bulk, for a mail delivery company, refers exclusively to volume. You get discount on volume. Creating massive volumes of customized mails has been trivial for years.
8.
by MiyamotoAkira 3y ago
GDPR is the best thing since sliced bread
9.
by MiyamotoAkira 4y ago
done today on python someMock = SomeMock() Also, inconsistency. The example that they put is SHOWLN and showln, and they use all over the place showln, but then they write ReadLN. Driving me cranky :-)
10.
by MiyamotoAkira 4y ago
Not case sensitive.
11.
by MiyamotoAkira 4y ago
> This might be unusual but I would prefer to read someone's mental model of how the code works than the code itself. The hypothesis under Peter Naur's (the N on BNF) "Programming as Theory Building" paper is that tra
12.
by MiyamotoAkira 4y ago
> as a code-input robot while developers around him bark commands at him is actually productive. Nothing to do with mob/ensemble programming. At the end, is a discussion that a) make code easy to understand b) create shared knowledg
13.
by MiyamotoAkira 4y ago
Some writing from Martin Fowler about the project: https://www.martinfowler.com/bliki/C3.html
14.
by MiyamotoAkira 4y ago
> Sounds like you would just have people breaking `master` constantly to me. And how do you do code review? Or don't you? Pair and Ensemble programming
15.
by MiyamotoAkira 4y ago
I love TBD. But it has its places. For mobile apps I've used (and would use) release branches. You have a hard requirement on the way that app stores work. You can still do TBD for most of the development of new features, though.
16.
by MiyamotoAkira 4y ago
Point two: Alternatives to source control branches are dark launches, branch by abstraction and feature flags. Point three: The best results that I have had on developing systems were doing exactly that. You need more discipline (like make
17.
by MiyamotoAkira 4y ago
Is even easier with a small team to do TBD. Because the amount of integration is reduced the possible need of branches (or their TBD equivalents dark launch/branch by abstraction/feature flags) is greatly reduced. So the branches
18.
by MiyamotoAkira 4y ago
Sadly that is the case with most ideas/techniques, because we misinterpret them or we hear about them 10 reinterpretations down from the original. Nothing like going back to the source. Edit:it->them
19.
by MiyamotoAkira 4y ago
The Agile manifesto was created by devs, for the benefit of creating software. Everyone gets the benefits. After having used release and feature branches, and trunk based development, as a developer I see mostly benefits (there are some dra
20.
by MiyamotoAkira 4y ago
So the problem is not the feature flags. If the code/system doesn't get improved bit by bit (is ok to have technical debt), then, whatever the technique, you are going to end in a bad place.
21.
by MiyamotoAkira 4y ago
Release integration branches bring the behaviour of big releases. The bigger the release, the bigger the risk, therefore the less you want to do it. With release integration branches you not only integrate for release (which the bigger the
22.
by MiyamotoAkira 4y ago
I like that write up on [2]. I have not really been exposed to C in a very long time, and that has been quite informative. I also like that Set of Unit Testing Rules. That is basically correct, external systems are a no-no on unit testing.
23.
by MiyamotoAkira 4y ago
I just want to point about that sentence of "goal posts get shifted". In his book Test Driven Development by Example (2003), Kent Beck, on the preface, page X says: "Red-Write a little test that doesn't work, and perhaps
24.
by MiyamotoAkira 4y ago
Being in the bench is not unusual for Consultancy companies, where there is no necessarily alignment between finishing with a client and starting with the next one. Or even starting directly on a client when you join them. Quite useful time
25.
by MiyamotoAkira 4y ago
Rebranding wouldn't help. The same people doing Fauxagile will be doing FauxX after. The underlying issues of why Fauxagile exists don't get removed because of rebranding
26.
by MiyamotoAkira 4y ago
For number 1 I use perspective with projectile. https://github.com/nex3/perspective-el https://github.com/bbatsov/persp-projectile
27.
by MiyamotoAkira 4y ago
Separate deployment from release (Feature flags). Then you can do QA and show to stakeholders whenever in whichever environment. You can even use it for Code Review, though I prefer pair/ensemble programming to CR (better to correct t
28.
by MiyamotoAkira 4y ago
That last example, as you recognise at the end, was an agile flow, as per the Manifesto, they found what worked for them well. However they wanted to call it. Any other flow in which management wants to standarized the process, fails at agi
29.
by MiyamotoAkira 4y ago
This graph did the rounds on Friday, comparing it to Slack on daily users: https://twitter.com/Carnage4Life/status/1558054445237149697?... The graph doesn't include Zoom or Google Meet, so is not a perfect re
30.
by MiyamotoAkira 5y ago
Pair programming is quite intensive when done correctly. You build stamina with time. But even so, using the Pomodoro technique is the way forward. Someone driving for 20/25 minutes, then 5/10 rest, and switch the driver. Even so,

More ›