Skip to main content

Posts

ArchUnit: enforce architecture in Java codebases

Today , I came across ArchUnit  which lets you enforce architectural choices on any Java codebase. For example you might want to enforce that certain domain object methods are only accessed by the persistence layer classes, but not in, let's view-related classes, with the exception of tests. This can be helpful to avoid spaghetti code, with all classes depending on each other. Java packages can help in this regard, but they are a rather coarse filter. Additionally, a unit test adds an immediately clear and conspicuous layer of intention to the codebase by expressing certain design choices that might be otherwise overlooked, unless a careful code review catches them. It's pretty clear to me that Java, even with all its shortcomings and despite Oracle efforts to sabotage it , offers the best development environment in terms of tooling, IDEs, support, and libraries. Notice that in the video, the host Ted M. Young is wearing the Change Behavior beanie, the other beanie is Refactor
Recent posts

Ducker: the manager

I recently picked up People and Performance by  Peter F. Drucker . If you're keen on understanding what is this manager job that everybody talks about (especially if you're new to management) this book will set you on the right path. I've thoroughly enjoyed reading it and I wanted to make a visual summary for my own use. I think it came out nice enough that it might be worth sharing it, so here it is:

Brain dump on the recent Figma database infrastructure articles

Warning: this post is in a stream-of-consciousness form. Approach it accordingly. Figma recently posted a couple of articles ( one and two ) on the challenge they are facing to keep their database infrastructure up with the massive growth they are going through, and how they're solving it. The last article especially was re-shared in some of my circles, and my initial gut reaction to the articles can be summed up in the immortal words of Jeff Goldblum in Jurassic Park : “Your Scientists Were So Preoccupied With Whether Or Not They Could, They Didn’t Stop To Think If They Should” . After I (admittedly) quickly read the article a couple of times, I still did not "get it". IMHO is a red flag as critical infra stuff like that should be simple: simple to understand, simple to operate, simple to troubleshoot, simple to restore. Had I been in their position, what would I have done? I could have left the article at it, but I've made it an habit to never say something "n

How do we get out of the fear of failure?

Once again I am writing about a few things I learned from the Knowledge Project podcast. In this episode Sean Parrish (host) and Dr. Gio Valiante talk about getting out of the fear of failure . I found the discussion supremely valuable and decided to draw a small diagram to make sure I assimilated and retained the essential points. The diagram is below and is provided without further comments, as those are, well, in the podcast itself. Diagram from "The Knowledge Project Ep. #181"

Higher Order Thinking: Bloom’s Taxonomy

I came across Bloom's taxonomy of higher order thinking while listening to another Knowledge Project podcast episode  Dr. Gio Valiante (Part 2): Failure and Success . I found the concept intriguing, with reference to learning organizations and learning in organizations. I made a little drawing to help me remember the hierarchy, and then did a bit of research on the topic based off the first Google search results for "Bloom’s taxonomy of higher-order thinking". First thing to note is that this is Bloom's taxonomy of the Cognitive domain. The wikipedia page lists two additional taxonomies in the Affective and Psychomotor domains. Other online resources about higher order thinking rename or reposition the last three levels, as shown in the bottom part of the drawing above. How can I use this newly discovered information? I guess really my question is: how can I use this newly discovered information? And right now I am thinking at two ways: how can I index the hiring

XY problem: not only in software

The XY problem is something I've been acutely aware and watching out forever. In software development. I usually refer to it as  describing the issue in terms of the solution instead of the problem. And as with all things, they're very easy to see in one context, and jump at us unexpected and undetected in others. This is how I felt when I came across what is essentially a ROI question for a platform team (in the Team Topologies declination) and in the thread somebody simply unpacked it for me and everybody else: you have a XY problem: X: are we spending too much on product + engineering? Y: we need to determine the appropriate level of investment or budgeting And there it is, a problem I can work with, instead of responding to the trap. The conversation happened in the Rands Leadership Slack , which I wholeheartedly recommend you join regardless of your role.

Why are we still using C?

Youtube rarely makes great recommendations anymore, but this time it did. Yday found this recording of a CppCon presentation from 2016  ( slides ) in my feed and made some time to watch it. It's pretty long, due to an extended Q&A section at the end which I mostly skipped, but well worth watching. The presentation itself is great and masterfully explores the reasons why we're still using C instead of C++ (especially if C++ is such a better alternative?) from a psychological/sociological point of view. The presenter quickly shows that technical arguments are just not effective, and also explains why. I've greatly enjoyed it because it aligns with some of my leadership beliefs, and also because I don't understand (or I guess I don't have the same frame of reference) people who pick C as their preferred programming language. I've done a bit of C programming while I served in Mapserver PSC maintaining the Swig/Java bindings and to sum my experience up: what