Articles for category: Delivery

April 27, 2021

Greg Thomas

The Mistakes You Make

Everyone is their own worst critic. I can pick out mistakes I made on a project, team or code a mile away. Heck I’m looking at flooring I laid down and there might as well be bright red ink painted around all the mistakes I made in what I installed. But when other people look at the finished product, they don’t see them. They probably don’t see them until you point them out. And even, they are in the tiniest of corners that they make little to no sense as to why you are worrying about them. These are the

April 24, 2021

Greg Thomas

Delivery Definitions

“It’s a prototype” “It’s an MVP” “It’s a Proof of Concept” “It’s an evolutionary product build” “This is the beta” Whatever it is you decide to call it, everyone on the team needs to decide what it is and who it is for. You need to define what you are delivering. One person having a different notion of what it is during the delivery of the project will only yield confusion during the work that is being done to deliver the final solution. You can switch what your delivery definition is but this should always, always be done as a

April 23, 2021

Greg Thomas

You Owe Them Something

Shipping code is a partnership between you and your customer. If you are late on something (for whatever reason), like any good partner you probably owe them a gimme, a goody, something extra. That little bit of UI trickery they were looking for that they didn’t originally ask for, give it to them. That back-end functionality that correlates their data, find the time and make it happen. No one is saying you need to give them everything in the world to make them happy. But you need to remember it’s a partnership, almost like a marriage, where there is give

April 21, 2021

Greg Thomas

Just In Case Coding

You wouldn’t put a cast on a completely healthy leg – just in case you broke it later that week would you? Probably not. So don’t fall into the trap of doing extra coding – “just in case they want this or they want to do this or someone asks for this”. There is a line between accepting edge cases into your code and embarking on “just in case coding”. If you are using the wording – “just in case” – it’s probably that type of coding.

April 20, 2021

Greg Thomas

Getting Better vs Looking Better

There is a difference between getting better and looking better. When you are getting better – you are focused on your team, their growth, their skills, their objectives, delivering the work that you do – in doing so you might have to change gears on the fly, you might have to shift your approach, you might have to try out new ideas. To the outside, it might not look great, but you’re in it for the long run, you’re in it for the growth and the betterment of your team. That is all that you are in it for –

© 2025 Rambli by Greg Thomas. All rights reserved.