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...
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...
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...
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...
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...