My most recent post on Reddit got a reader’s attention, and they remarked that rqlite 5.10.0 memory usage grew during the load test, but no such increase in memory usage was seen during the same testing of 5.6.0. Sure enough, there was a memory leak in 5.10.0.
Tag Archives: quality
Gresham’s law and Slack
“Bad money drives out good.”
When is the last time you spoke with your fellow developer? I mean actually spoke? Or was it just over Slack?
I like really Slack, Flowdock, Hipchat and the like. I couldn’t do my job without them. But as with Gresham’s law, bad communication is driving out good.
Continue reading Gresham’s law and Slack
Testing InfluxDB Storage Engines
Another post for the InfluxDB blog — on testing the storage engines within InfluxDB.
You can check it out here.
Code reviews still rule
Recently at InfluxDB we discussed how code reviews fit in during the various stages of development. It’s great to see the team reach consensus about how we should develop software. It made me think more deeply about why I remain a big believer in the code review process.
How you should write software design documents
In my last blog post I explained why writing design documents is such a powerful approach to building well-engineered systems. But what should one document?
Continue reading How you should write software design documents
Why you should write software design documents
Many software engineers never write design documents. Design documentation takes time, and implementations often proceed so far without any documentation that if it happens, it’s an act of recording what has been done — a tedious task at the best times.
Many software engineers argue “the code exists, it’s running, it’s working, let’s move on and build the next thing.”
Continue reading Why you should write software design documents
Always thinking of the next guy
My father worked for many years in QA at Beckman, an American medical instruments firm. His job was to ensure that newly-manufactured centrifuge rotors would hold up when spun at thousands of RPMs. He used to tell me that the Beckman philosophy could be summarised in one sentence — “There is no substitute for quality”.
Technical Leadership through Testing
As technical lead at Loggly, responsibility for a well-engineered infrastructure ends with me. And one way to ensure the system is designed and implemented well is to stay as close as possible to the code, ensuring that the team and I write quality software.
But it can be difficult to complete the design and implementation of the features I am responsible for, ensure that what the team produces is well-implemented, and understand every line of code — there is only so much time in the day.