As a consultant, I have to track my time. I have to track the amount of time that I work on every project in a single day. On days that I am not on-site with a client, I will jump from project-to-project across six active, busy projects. Tracking time is a solved problem. There are a plethora of apps, web apps, and tools that you can use. I won’t list them here, but search for ‘time tracking.’ I’ve titled this blog post ‘Simplification’ because I’d like to talk about how I track time.

The tools that I’ve successfully used to track time for the last year and two months listed: iOS That is right! I only need a single, built-in app on my iOS device to track my time. A simple, one function stop watch has allowed me to track all of the required information correctly, and accurately.

Stopping the clock, jotting down that information in our billing software before switching to a new task also gives a few needed minutes of respite from thinking. It is like eating ginger between sushi pieces. Cleanse the palate of your mind, figuratively.

But I digress, this post really isn’t about how I track time, or cleansing your palate but how we can all simplify our tools and still be successful, albeit less distracted day-to-day. Do we need a super-duper tricked out ZSH, or can a well appointed Bash do the same job? Is managing an entire directory of vim configurations better than using just the default code highlighting?

Progress will tell you that we’ve come to find that simplification isn’t needed. Amazon will sell you anything made, and have it at your door within 24 hours. While this an incredible service, does selling everything make them the best at selling everything? Is a greater scope of service conducive to greater quality? I argue, maybe. iTunes for instance is an example of something that is one-stop shopping, but it really doesn’t do all of those stops perfectly. Search for instance is a constant issue. Discoverability is also a problem.

What if iTunes was broken into iApps, iBooks, iVideos, iMusic, and each was given the directive to perfect that field. I would be willing to bet that simplifying each project, without affecting the overall feature set would allow Apple to create better, more useable products. As a side note, I realize that Apple has figured this simplification out at the hardware level, but not the software level.

Simplification is hard. It is difficult to do less. It is easy to add more features that will attract more customers, and in turn generate more revenue. I propose that we stop thinking of simplification at the macro-level, but at the micro-level. This will allow companies, like Apple, to have five pieces of software, which each is perfectly suited for it’s task instead of a single piece of software that misses the mark across the board.

Circling back to consulting, I see this conundrum often. We have ten features, and five developers to build them. Each developer is then required to build two features. This means that they will only be able to devout fifty percent of their time to each feature. Would it be better to do five features, across five developers so each can focus fully on each feature? From the macro level, you’d see that half of the work was done in the same amount of time, but from a micro-level the quality of work could potentially be twice as great.

We must simplify everything. Whether it is the tools we use, the features we must complete, or the products we are building, simpler is harder upfront but with the long-tail gains — success should be synonymous with simplification.

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.

Code Like It Is For A Blog

Be hard on your own code.

Your job, as a programmer, is to write ‘good’ code. Regardless of if it is working or not, human beings will need to read it to understand what it does. This means that you should follow convenstions, remove extra whitespace, and apptly name things.

You should write code just like it is going to be reviewed by the entire world. You should feel embarrased if you commit whitespace errors. You should be shunned by your teamates, and you should in turn shun your teamates. It is not just for the aesthetics. Imagine if your diffs were littered with various changes that didn’t have a lot to do with the commits intent.

Please join me in writing code like it will end up on a blog, and that blog has unfiltered commenting with everyone in the world invited to comment.


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.

Technical Leadership Is Not Hard

I will outline what you can do to successfully be a technical lead:

  1. Buy a notepad
  2. Write it down
  3. Do it
  4. Cross it out
  5. Goto 2

Knowing what needs to be done is your most important job. Do I need to talk to Steve about the commit he made? Write it down. Did John ask me to make sure that the team knows about the upcoming changes? Write it down. Just spoke with Steve, cross it out.

Being the barrier against stupidity for your team is job number one. Job number 1.01 is to make sure that what is asked of you is taken care of. Simply remembering what a manager or developer asks you is impossible. As a developer, if I ask my technical lead to handle something and it isn’t handled, trust will be lost. Just like management, gaining your managers trust takes effort. It is hard to gain, and very easy to lose. This works both ways. Managers trust their employees, and employees trust their managers. If the developer asks the status of said request, and the technical lead can say, “Here is my list of 20 things to do and your request is next.” The developer will feel much better about the task actually being handled.

An example situation (including a task list):

  1. Developer asks Technical Lead about length of caching of a domain object
  2. Technical Lead adds it to his list of things to follow up on
  3. Developer asks Technical Lead about length of caching of a domain object
  4. Technical Lead looks at his list and tells the developer that he is tracking down the answer.
  5. Technical Lead finds out about cache expiration of said domain object, crosses off the task, and let’s the developer know
  6. Technical Lead gains developers trust that said technical lead will follow through when given a task

An example situation (without a task list):

  1. Developer asks Technical Lead about length of caching of a domain object
  2. Time passes
  3. Developer asks Technical Lead about length of caching of a domain object
  4. Goto 2