• Blog
  • About
  • Blog
  • About
Darian Shimy

Standups Are NOT Poisonous

3/30/2013

0 Comments

 
Gareth Rees’ article titled, Standups are Poisonous hit HN today which I strongly disagree with every point and his solution. Almost to the point where I couldn’t fall back asleep and felt compelled to write something. The purpose of our standups are to do the following:
  • Make sure everyone is working on the right thing
  • Help out other team members by taking work off their plate or helping them by sharing domain-specific knowledge
  • Keeping everyone informed
Easy. It’s important to point out, they are NOT status meetings. Status meetings suck and should be avoided. Gareth made the following arguments (which I respond as follows):
Morning standups force people to be in work before 10:00. Great when you’re supposed to have the benefit of flexi-time.
We don’t have any set working hours. Some come in at 8:00 and some at 12:00. Our standups start at 1:31 every day. No need to set your alarm clock. This time is perfect since people have finished lunch, had time to play a few games of ping pong, and are ready to get back to work. We chose one minute past 1:30 since everyone was late to the 1:30 meeting. WFH that day, no problem, we have a Google Hangout for you to tap into. Have a hot date during that time, no worries, shoot over an email. Super busy that day, fuck it, I’ll catch up with you tomorrow.
They always overrun. Rarely are standups shorter than 10 minutes. 6 person team * 30 minutes = 3 hours lost.
Our meetings NEVER go over the time limit. Period. I’m not sure why people have this problem. The person running the meeting needs to cut of sidebar conversations and take long running discussions offline.
Action points are rarely produced, so the value of the outcome is questionable.
The goal of the meeting is to eliminate action points (or impediments). If this is the case, your project may be progressing as it should.
Others switch off if they’re not interested in the current monologue.
When you build a talented team, they show respect to other team members by paying attention. Perhaps people switch off when the meeting hits the three hour mark.
Notes are rarely taken, so by the time the weekly update gets compiled the team have to scratch their heads about what they did over the last week.
I don’t take notes unless I need to follow up on something. Notes are not needed as this is very transient information. It has no value 24 hours past the meeting.

The root of the problem is he feels standups are status meetings, they’re not! The solution calls for an email system where a team leader compiles daily and weekly updates from the team. This has its own problems:
  • The leader needs to hound the team to get their update (doesn’t sound like a fun job)
  • No one will read the daily email (or weekly for that matter)
  • Information is stale once things get sorted out (you lost a day)
  • There is no emotion carried with this process (seeing someone’s stress level and realizing they need help does a long way)
  • You should care about what was done, not worked on (there is a difference)
Standups are not poisonous or evil. They are a great tool when run correctly. Remember, they are not status meetings.
0 Comments

Scoped IDs in Rails

3/29/2013

0 Comments

 
Rails by default will use the auto-increment value for the ID which is global to the application. Sometimes, you want to have the IDs scoped to a parent object. For example, if I were building a multi-user bug tracking application I would want to have the IDs scoped to the project allowing each bug ID to start at 1 (one). As it turns out, this is fairly easy to do.

First create a column on the parent object to keep track of the next scoped_id:
Code Editor

    
Next, create a column to store the scoped_id in the child object:

    
Finally, update the Bugs model to support the scoped ID:

    
That’s pretty much it. No gem needed here. When you are ready to access the bug by the scoped_id, just find it from the project:

    
0 Comments

Texatar: Texual Avatar

2/5/2013

0 Comments

 
​Texatar is a server that generates images with text to replace default gravatar image.
The problem we face is not everyone has a gravatar image linked to their email address. When we show images in place of names, they all look the same and there is no way to differentiate between people. Texatar will generate an image based on text for the user. The color scheme is equally important and is based on a hash of the user’s email.

Usage

Images are generate from http://texatar.jabwire.com/:size/:text.png

The following parameters used to control the generated image:
  • :text = the text to display in the texatar
  • :size = the size of the image in pixels
For example, the link, http://texatar.jabwire.com/200/ds.png, would create a 200 x 200 image with the text ds in the center.
Picture

Gravatar Integration

Gravatar allows developers to supply their own default image with the d= or default=parameter. Be sure to URL encode the parameter’s value.

    
See https://en.gravatar.com/site/implement/images/#default-image for more information.
0 Comments

    RSS Feed

    Archives

    March 2013
    February 2013

Proudly powered by Weebly
✕