Month: April 2022

April 12, 2022

Greg Thomas

Separating Code from Ownership

We all hate when our code breaks. You put all this time and energy into creating the most beautiful piece of software known to mankind and then it blows up on the launchpad. It stings.  Even after so many years of programming, it stings. But code is code and it will blow up (I believe this to be its second purpose in life). Owning the problem when this happens is good, blaming yourself and hiding it, is not so good. Own the problem, not the code, conditions change, if you gave it your best effort, great, learn, fix, move forward.

April 11, 2022

Greg Thomas

If it Blows up, it’s Broken

There is no talking your way out of it. If it blows up, it’s broken, there is no if, then, that – it blew up, it broke and now it’s time to move on. Admit it’s broken, put together the plan to fix it, and make it happen. Don’t waste time arguing if it’s broken, get past that and fix it.

April 10, 2022

Greg Thomas

What’s in our Head

The Hidden List is what we keep at the back of our minds, keep track of, and keep adding to as we progress thought-out the day. As a Developer, the list is going to be small, but as a Leader, that list is going to be very long.  Therefore it’s imperative that you get it out, write it down, and get it into the system of record. By not getting it out of your head, all you are doing is holding your team back from what they truly need to focus on.

April 9, 2022

Greg Thomas

The Hidden List

The hidden list is the one we all have at the back of our heads, in the dark recesses of our minds where we are all trying to work things out.  All those nasty bugs and issues that have laid waste to our systems that we don’t store in JIRA and DevOps and instead we let them take up space in our minds until it beats us down because we are so consumed by the weight of what is and isn’t being tracked. There is a solution to the Hidden List. Write it down, put it in JIRA, put it

April 8, 2022

Greg Thomas

When it’s no longer a Bug

When you’ve spent an entire day trying to figure out what the issue is, it’s no longer a bug. When it’s going to take longer to fix it, than it did to build it, it’s no longer a bug. When you need to pull in the entire team to diagnose and troubleshoot the issue, it’s no longer a bug. When you are trying things that you aren’t sure are going to work, but hope that they do, it’s no longer a bug. There are many other reasons and scenarios here, the point that matters is that you define when a

© 2025 Rambli by Greg Thomas. All rights reserved.