Fix It Later

Here is a mindset I’ve come across recently: ‘fix it later.’ In a culture of resourcing, waterfall-ing, and lackluster performers, fixing it later is exactly status-quo and is exactly what is wrong with your software project.

If they, reasons nefarious or not, don’t want the project to be workharder to make the project better they should be removed post haste. Pushing back because it is hard, or the task is annoying should be grounds for removal. Keeping in mind that the change should be well intentioned, and actually beneficial to the team. An example that I’ve come across recently is adding our internal gems to the continuos integration server. These gems are internal to the entire organization, not just our team. This code is shared, and these other teams have a right to know where the code stands.

Stepping off of my high horse for a moment to talk about my shortcomings, I will say that sometimes I don’t want to work on building out new infrastructure, or refactoring all of the view tests to run on webkit instead of Firefox but I do it. I grit my teeth, bite the belt and pull it together. This is why I am paid as a senior developer, this is why I am put in technical leadership positions. People trust me to do the right thing regardless of cost to my persons. Not pulling it together is a failure as a developer personally, and a failure as a team member. You fail, and the team will fail because of it.

No one really wants to work on technical debt. No one wants to put aside a shine-y new feature using all the coolest toys to make the CI server run better, but if no one does it it will not get done. It is your job Mr. Senior Developer to do it. A junior developer probably doesn’t have the skills either interpersonal, or technically, so it falls to us to swallow that pride and get it done.

This is a mindset I learned as a front-end developer that I carried over into the world of DevOps, and technical leadership. Internet Explorer sucks to write CSS for, but we have to. You have no choice. We must, as people, get our mindsets in line with doing what is best for ourselves, for the project, and for the team. They must align. You will grey, you will have high blood pressure, and you will suffer blows to your will to live but at the end of the day you’ve made things better for the entire project, the entire team, and you’ve gained important experience.


Direct quote:

It’s speculation, but I’d look for the re-enable event when creating a new user in our DB rather than un-deleting the existing one.

Please stop speculating when talking about an issue. Please take ten minutes of time to track down the source, and see what it could be.

Ready? You can find the actual, non-speculative answer in this many keystrokes in Textmate on a pretty large project:

  • Cmd + T → sche.rb → Return
  • Cmd + T → alreg.rb → Return
  • Cmd + F → unreg → Return

Twelve keystrokes and you are looking at the literal source of the issue.

Speculation is not to be confused with educated guessing. Educated guessing is when, after looking at the source, the developer says that it could have to do with this instance method. Huzzah! Let us dive in and see if that is the issue.

Adding to the confusion of the hunt by speculating only makes me wonder why you are on the team, let alone being trusted to debug issues timely in the future.