Published a new blog: Things DBs don't do - But should!
https://www.thenile.dev/blog/things-dbs-dont-do
It is based on my keynote at #ddtx23 - lots of people asked about it and there were no recordings. So I put my thoughts on writing.
I wrote a little bit about developer experience #dx and what I'm currently working at. https://zenzes.me/unlocking-productivity-understanding-the-importance-of-developer-experience/
Some thoughts on making all the work visible:
https://dannorth.net/2023/03/02/but-what-about-the-bau-work/
Just over a week ago I was laid off by SmartBear, who acquired Cucumber in the summer of 2019.
I've written more here: https://mattwynne.net/new-beginning
I'm still getting used to the news, and figuring out what I want to do next. In the mean-time I am available for hire as a remote freelance technical agile coach.
I'm based in the Pacific (West coast US) timezone, but I don't mind getting up (reasonably) early.
"The phrase smoke test comes from electronic hardware testing. You plug in a new board and turn on the power. If you see smoke coming from the board, turn off the power. You don't have to do any more testing." – https://en.wikipedia.org/wiki/Smoke_testing_(software)#Etymology
Love the tone of the last sentence.
emilybache@sw-development-is.social never stopped programming, as that is the fun part. #WhoIsagile #wia59
https://www.youtube.com/watch?v=rPYppl75F3U
Co-creating (pair/mob programming) is even more important in remote working times.
The emergent behavior (going for lunch together, chats near the water cooler, spending time in the shared physical space, etc.) that was helping gel the team is gone now. Trust and vulnerability probably with it, as well.
Communication and interactions have become a lot more bounded and transactional.
Creating together is not an option, but became a necessity in sustaining a healthy, productive environment.
Here is your must-read article for the day, a profile of @emilymbender, and her efforts to deflate the ridiculous hype around large language models such as ChatGPT.
It's also about the people who are behind that hype, and about what their way of thinking has the potential to do to us.
It's worth reading all the way to the end.
https://nymag.com/intelligencer/article/ai-artificial-intelligence-chatbots-emily-m-bender.html
I love my job, but I do find it frustrating how much of my job consists of repeatedly arguing obvious stuff like "phrenology is bad even if a computer does it" and "using probabilistic lossily-compressed text databases to guess next words is not sentience" and "understanding Merkle trees does not guarantee you'll make tons of money in speculative trading of unregulated currencies" to students and peers and occasionally university administrators.
RT @CACMmag
Code written by a single developer is usually hard for others to maintain later. This is the "lone developer #problem." http://bit.ly/3J0Km4e
@tastapod @thirstybear Ok, so I do have a bias, because I help build Quarkus. :)
But it is *so good* for TDD. It has a dev mode (`mvn quarkus:dev`) which does hot reload and continuous test running. It uses test-coverage techniques to only re-run tests that would be affected by a code change, so even in a big codebase, rerunning the tests is fast.
@edeandrea has some talks and also an article (https://developers.redhat.com/articles/2021/11/08/test-driven-development-quarkus) about TDD with Quarkus.
If you're writing software that people will send bugs from, make sure information such as version numbers and OS are in the stack traces, so you never need to ask for them.
Also, if the version number is displayed in the UI, that'll help when the bug report is a screenshot of the app misbehaving.
This message brought to you by today's wasted questions.
Nice article about quantifying 'toil' so managers pay attention https://jay.bazuzi.com/Toil-Scorecard/
@jbrains @nat I think we probably agree, too, and maybe this is conversation better had live.
When you say that "tests don't make refactoring easier" do you mean that they *sometimes* don't make refactoring easier, and this is a signal that something needs improvement? If so, I agree.
Or do you mean, "they generally don't make refactoring easier, even in code with good tests and design." If so, that's different than my experience, but l'm left wondering if it's a semantic difference.
1/
#Øredev call for presentations is up: https://oredev.org/callforpaper
It's one of the nicest commercial conferences I know: https://coderbyheart.com/%C3%B8redev-2022
@gergelyorosz "how long does it take" "13 days"
"How long does it take without tests" "15 days, including debugging"
"Today was a Difficult Day," said Pooh.
There was a pause.
"Do you want to talk about it?" asked Piglet.
"No," said Pooh after a bit. "No, I don't think I do."
"That's okay," said Piglet, and he came and sat beside his friend.
"What are you doing?" asked Pooh.
"Nothing, really," said Piglet. "Only, I know what Difficult Days are like. I quite often don't feel like talking about it on my Difficult Days either.
"But goodness," continued Piglet, "Difficult Days are so much easier when you know you've got someone there for you. And I'll always be here for you, Pooh."
And as Pooh sat there, working through in his head his Difficult Day, while the solid, reliable Piglet sat next to him quietly, swinging his little legs...he thought that his best friend had never been more right."
Sending thoughts to those having a Difficult Day today and hope you have your own Piglet to sit beside you.
Please note, I have been made aware that this is not taken from a Milne story, however the message is more important than who wrote it. 😎
@nixCraft #PHP is *great* because you can just drop a file in your web documents and the server will run it on request.
PHP is *terrible* because if anyone *else* drops a file in your web documents, the server will run it on request.
As @doriantaylor wrote, you will always be fighting this forever. But at least it keeps PHP cleaners, I mean, #developers, employed. And there’s so many that #employers have their pick—until they understand the racket. https://doriantaylor.com/the-only-argument-you-will-ever-need-against-php
Change failure rate is a lagging indicator of lead time to change.
If you halve the change size, your deployment frequency goes up twice, and now in order to keep the same change failure rate % as before you have to have twice as many failures per change.
As you keep halving the change size, it gets increasingly more difficult to keep the same change failure rate % as before, which is of course good news.
Technical Agile Coach, Conference Speaker, Author. https://coding-is-like-cooking.info/. tootfinder. she/her.