Articles for category: Delivery

October 21, 2019

Greg Thomas

Focus on How You Code

The WHAT you code will always be the requirements of what you are working on. The WHY you code will always be about your love for it or desire for a paycheck. The WHEN you code will be determined by when you are delivering and could be up to other people. But the HOW you code – what error handling you employ, what libraries you continually update, what syntax you employ, how you push yourself to get better each time, how you always want to try something new – that is always up to you.

October 15, 2019

Greg Thomas

Always To Win

Always Lead to Win Always Play to Win. Always Code to Win. Always Bake to Win. Always Ship to Win. Always Wake up to Win. Always Debate to Win. Always Knit to Win. Always Create to Win. Always Check-In to Win. Always Compile to Win. If your whole purpose is to win, in everything you do, how will you focus on growth? What does you being first to complete your code, leaving the team behind do for the overall feature delivery? What does having checking in your work before the interfaces are completed do for builds? What does having all

October 11, 2019

Greg Thomas

Stories over Dates

Dates are great to hit, but if you get there with nothing, with poor quality, with lackluster user support, with no excitement from your team. Did you really hit a date? Better, to focus on the Story, what are we delivering, what are we giving users, what are they getting. If the Story is going to take too long to deliver in the date you have in mind, then perhaps you need to change the Story so it can fit in the date. The only caveat to changing the story is to make sure that it is still a story

October 10, 2019

Greg Thomas

Incomplete Experiences

Have finished feature are okay. Work that gets pushed off to the next sprint, it happens. Features that get canned, it’s not going to stop. All of these “events” happen that shift the development of what we are doing in the delivery of software. However, what is not okay, is to leave what half of the work has been done in the code that renders a feature partially unusable and/or changes the experience the user has when interacting with your product. When this happens, we deliver an Incomplete Experience to the end-user and that is the worst experience. We force

October 9, 2019

Greg Thomas

(Code)Blocked

You might not know it, but for a while, I was (Writer)Blocked. Couldn’t think of anything new to write. Was tired with what was out there that I was reading. Thought everything that had been said had already been said. Couldn’t get started. It made me think of how many times I sat down to start a new project and stared at the screen as it asked me what I wanted to name my class for the umpteenth time. Did I know what to call it? Did it sound any better than what it was before? Would it really matter

© 2025 Rambli by Greg Thomas. All rights reserved.