Redis Ordered Set WITHSCORES into JSON Object (NodeJS)

A note for myself before I stop using this ordered set.

Redis Ordered Sets can return the members of a set with their scores. Its an option on the zrange command, so to get all the values in an ordered set with their scores:

`redis.client.zrange( key, 0, -1, 'WITHSCORES')`. 

Of course, the returned array is pretty specific, something like:

user1 135000 user2 384000 . . .

Using the handy lodash library, I wanted to keep track of this little hack:

//this is a synchronous operation and would block the event loopvar testScores = _.fromPairs(_.chunk(testValuePairs, 2));

I've seen it done with for-loops that skip every other array item, but I liked the single line of this approach. It does go through the array twice, once to turn into paired array, and once through that array to create the object, but for my purposes the array sizes were going to be small and the succinctness was useful.

Team Focus

One of the intangibles of software teams, or any team that is working together on something, is team focus. Focus is vital to keep everything flowing and to meeting expectations, but a lot harder to turn into a metric or graph because it is a soft measure. It is not quantifiable. It is almost a . . .  feeling!

Team Focus is how well a team works together, towards the same goal, and are self-motivated to achieve that goal.

Focus among individuals varies and some need a little more coaching than others. Some will get into "the zone" quickly and may even seem anti-social. Some are too addicted to their phones or Facebook, and that's just an employment concern. Some need the instructions once and it gets done and some need reminding more often, and it still gets done! However, these are mostly all personality traits. While a team should have a few different personalities to avoid freaking out the other departments a la The Stepford Wives or The Borg, an individual's ability to focus is just part of the equation.

The team's focus cannot be measured in the way we can measure tickets, sprints or SLOC. You won't see a graph or color chart indicator. You might think you would be able to deduce your team's focus based on the measurements of your process, but measuring the wrong things or good planning could be factors there. Just look at the components of that "team focus" definition above and see how you would describe your team.

"Works Together"

How your team works together is paramount to being focused, and it is affected by the company culture and personalities. Teammates who are willing to help and explain make a team work better together. Questions are not a bad thing. Whiteboard sessions are a group effort and all opinions are heard. People smile. There are inside jokes at the office about non-project, and non-people things.

To many, it is obvious when a team works well together, and is not "just working." They actually get along, and that is part of keeping them focused.

• Does your team have a loud-mouth or know-it-all? That does not build morale, and it is already a factor as to why people aren't staying on your team.
• Are coding opinions bashed as inferior? If the "right way" is not written down (and, if possible, automated by tooling), just deal with it. You can still read the code.
• Is there any blame or names at bug review, or deploy time, or at demos? Double-check the review process and steps prior to release, because the team released the software.
• Does one part of the team have the inside track for project decisions, and the others are only informed later? Be careful if these are not documented roles, because saying "this is how it is now" leaves one part of your team on the outside. 
• Are there two sets of standards? Billy can skip writing a few tests because his work is important and needed right now, but Bobby gets dinged for skipping tests. Susie is made to follow the coding conventions during review, while Peggy doesn't run the auto-formatter. Watch out for this, it is divisive and will chip away at the team focus.

"Toward the Same Goal"

The team knows what it is working on, and you have a process that proves it.  There is business buy-in, so the team knows it's the right thing to work on. The stakeholders will be happy, so the team expects some kudos. Everyone knows where their piece fits into the current sprint/milestone/demo, and why that is important for the future of the project.  This, all wrapped together, is the object of the team's focus.

Know the priorities of your goal. Is it better to build performant or functioning software this cycle? Should the code be good or perfect? Tests too? Can your schedule accommodate "all of the above"? Different approaches to those questions can still look like the "same goal" but if each person has a different answer to the questions, there is a lack of focus.

Also, and this may sound obvious, but do not change your goals mid-sprint/cycle/sentence! If a sprint is defined, don't add to it after starting. If a feature is planned and started, don't add to it until the next planning phase. Changing goals are ludicrous to track. Your team cannot anticipate when new work will suddenly be added. No one can answer the question of "When will it be ready?" The dev team just sees arbitrary buckets of tasks, that can change or be added to, which certainly does not help them focus, and sometimes crushes morale.

"Self-Motivated to Achieve"

Did you team catch the fire? Do they believe in the project? Are they excited to show off the demo? Can they hang their hat on a day/week/sprint worth of work? Would they call it their own?

Like many things, people make more an effort and achieve better results when they are passionate about what they are doing. Being a creative bunch, software developers need a little room to grow their ideas, so don't force opinions all the time. Make important tasks, not just filler or "grunt work"; even test writing can be meaningful. Open up parts of the process and operations to others, to grow their experience and to give more responsibility. Be careful of someone hogging all the hard-stuff/glory/blame - this is a team. Compliment a nicely developed feature, or a sweet algorithm. Tangibly celebrate team accomplishments! (FYI - an email barely counts.)

The more involved someone feels in the team, and in the process, the more meaningful their work becomes, and the more ownership they will take. And they will be self-motivated to reach team goals and achieve higher standards.


While one cannot use their software process to measure team focus, the focus of a team will directly impact a team's results. Hard to measure yet highly important. Strive to keep your team working together toward the same goal, and self-motivated to achieve that goal.