Photo by Javier Allegue Barros on Unsplash

Build Better Software By Going Farther Together

TL;DR: Growing up in an immigrant community in the New York Metro area, you never think the unique, random, and crazy experiences you have in such a setting could have a direct impact on your career in tech, until it does. And I've learned many lessons, and here's one of them. If you get out of your own way, you along with your team, will accomplish great things.

Growing up, my family was quite plugged into a faith community that comprised mostly of people who were at the time recent immigrants to the United States from Egypt. We were the beginnings of the Coptic Orthodox community in America. Most of the non-liturgical music generated by the community was geared towards the ears and culture of those who immigrated here. I was part of a different generation, born in the USA, but very much Egyptian. It was very difficult to relate to some of the art and music that had been imported and shared with us.

By the time I got to high school, I had different ambitions than my peers. While most kids were out there being kids, I had felt a deep responsibility to help create art that we could connect with. After a few attempts, my work was often dismissed as dissenting, and non-adherent to our traditions. My team of musicians and I stayed persistent, despite doors (sometimes literally) being closed in our faces. While there was an initial rejection by community leaders, our work was getting recognition. The youth of the New York/New Jersey metro area started to know and enjoy our music.

Making A Record

In college I had a new vision: an album. My hope was that it would be an album that would embody the values and essence of our traditions, while connecting them with the creation of something original that our generation could resonate with. I wanted to send a message that even though a ton of art and music was handed to us, that we could be empowered to become creators of art and music, ourselves!

I found an excellent team of like-minded individuals. We sought funding, and eventually partnered with a local church who liked our idea. They offered to bankroll an album, in exchange for inventory. This did mean however, that I did not have complete creative control over the outcome. (dun.dun.dunnnnn!)

While most of our ideas were welcomed, quite a few were met with concern. I was often asked to hold back, edit, or even omit, for the sake of not rocking the boat too much. I had to make a choice, was I going to "compromise" on our vision, or was I going to trust this collaboration with an outside partner? This partner was older, a lot more experienced, and had a perspective that was a lot broader than my own. He knew intimately the ins-and-outs of our community, across multiple generations. He obviously believed in me enough to work with me, but seemed to restrict what we were trying to create for reasons I couldn't understand at the time.

There were moments I really wanted to lead and just create, yet felt like I had to be a team player, and there were a lot of reluctant compromises.

Unexpected Outcomes

We powered through, and the record was produced. The end result surprised me, and was beyond what I could have imagined: two sold-out printings, and an east coast tour that lasted four years. In 2001, I even got a phone call from office of the Ambassador from Egypt to the United States. On behalf of His Excellency, the office invited us to perform at a gathering of dignitaries and officials from all over the world, at an event honoring the music of Egypt. It was pretty incredible and completely unexpected!

But aside from all this "big stuff" that I'm mentioning, it was the people-impact that mattered most to me. We met and received letters from youth all around the world, with stories about how our work had impacted them, or encouraged others to follow suit and create music of their own.

I am convinced that had it been all up to me, and my direction alone, we would not have had the impact we experienced. We would have had total creative freedom, but we may have never reached such broad audience. I was satisfied, although there was less “getting my way” and more “getting out of my own way”.

Ok, great. You may be reading this, and thinking "what on earth does this have to do with building software?" and my answer is: "Everything."

"Don't Throw The $necessary Out With The $unnecessary"

As a hot-headed 21 year old, although I was committed to achieve something for my community, there was a blurred line between the overall desired outcome and the means to achieving that outcome. Art is highly personal. Making the art is as much of a goal as the outcome. If there was a particular song that was going to be cut from the record, or a direction that needed editing, I didn't always handle it gracefully. I nearly quit the project until my mentor told me, "don't throw the baby out with the bathwater". I had no idea what he was talking about. Once it was explained to me, I thought that was the weirdest metaphor ever.

But if you replace baby and bathwater, with the necessary/unnecessary thing of your choosing, the lesson starts to take shape. I was given a choice, if I stayed in this partnership, would the vision still be achieved? As I looked around, and saw how much freedom we actually had, was I willing to throw the whole project out the window because of 1 or 2 cut songs? I eventually decided to trust, and to refocus my attention on the goal, and preserve the relationship through the details. Had I disengaged, or quit, I would have missed out on something huge. The proverbial baby would have been lost.

That piece of advice kept me in the game, but the actual lesson I needed to learn was one that has to do with the importance of "us" over "me". It's the fact that if I'm working on something with a group of people, it's more important for us to be aligned than for each of us to do things their own way.

But, I'm an Artist and I Cannot Be Stifled!

They say that building software is an art. And there are a ton of similarities between those who make art, and those who write software. Unlike the building of a car or a house, where there are clear specifications for how each part comes together, building software retains the imprint of the developer. Even with strict team standards, the developer's personal style finds its way into the code. By looking at a piece of code, I can usually tell who on my team wrote it. It's why we say that we "write" software as opposed to "assemble" or "manufacture" it.

Unless you're one of the unicorns of 1-2 person teams, who get acquired by multi-billion dollar corporations, it usually requires more than 1 or 2 engineers to create something that can see the light of day. Our VP of Engineering has a saying, "Software is a people endeavor". We build software together. "Together" would mean, a group of people who have spent various durations of time (from months to decades) perfecting their craft, each with their own sense of "the right way" to do something.

When Being Skilled Isn't Enough

Looking back at the production of that record, yes I had the musical expertise, but our partner had a much deeper understanding of the community we were serving. As a musician who was mostly American, I wanted the album to be much more progressive than it was shaping up to be. I wanted to take more creative risks, but the brakes kept getting put on. I wasn't taking into consideration what my mentor was prioritizing, and that was the needs of the "customer". The community I was making music for wasn't necessarily interested in the risks I was trying to make nor would it have benefitted them much. He reminded me of the needs of our audience, and his user-centered perspective helped pave a way for this new thing to take root and land on listening ears. Luckily, I had wonderful, and much-wiser team members who reminded me of this.

And we find similar predicaments in engineering teams today. We want to build on the latest and greatest tech. We want to take technical risks or work on things because it is a more cutting-edge way of doing things. Maybe we want to upgrade a major version of a library that would cost several weeks of development on our roadmap. While these may be great ideas in isolation, we may not always be able to tie these changes to features that directly benefit the business. Sometimes, we as engineers need to be edited to keep our work focused on the goals we are trying to achieve.

So yes, I can now appreciate the lessons learned by these fierce negotiations of my past. I see now, that we were able to create something that was familiar enough to be mostly* accepted, however different enough to challenge, inspire, and spark conversations among communities in our diaspora. Smart and talented people can accomplish some amazing things, but only if they're aligned. Make no mistake, getting alignment is challenging.

* Actually, we got banned in one of the dioceses. I received a letter from a well-respected Bishop, telling me that our music was not allowed in any of the churches in his geography. While that may seem like a setback, at the time it reminded me that we didn't keep it too safe. 

Letting Go: Side-Effects May Include...

Getting on the same page as a group, requires individuals to give up a degree of control. This is required when building software as a team. Usually, letting-go is usually met with the acceptance that comes with being a professional. But software engineering often attracts people who put so much of themselves into their work. Because of this, letting-go can be met in with the following emotional responses:

  • Frustration: Often times, including myself, I've witnessed engineers be frustrated when a particular course of action, or even a pull request, is not approved, or requires changes that would move the outcome in a completely different direction. You think to yourself, "would the Sistine Chapel been what it was today had Michaelangelo been ruled by a committee?" Righteous indignation takes over, or maybe it's the blow against one's ego that can happen when work is challenged in its current state. Been there? I know I have.
  • Apathy: Tables aren't flipped, but hands are up in the air. (And I don't mean this celebratory emoji 🙌.) Apathy leads to detaching from both the work and the goal. While the impact of this is not immediate as the previous item, it does make teams vulnerable to morale being slowly chipped away. This will have long-term and debilitating effects.
  • Acceptance: There are others, however, who can remain detached enough from their work, but see it as part of a collective, and will welcome changes and advice, because ultimately, there's a shared trust in the team, and a strong commitment to what the team is trying to achieve.

But Don't Follow Blindly

We have to be aligned to make great things happen. And alignment means letting go. That's not to say that blood doesn't get spilled, or tears won't flow. That should happen with a team of experienced individuals, however, there's a mutual respect and striving for what's best, collectively. And this sort of refinement by an engineer and their peers, can lead to some great outcomes. (I'm not advocating for decisions by consensus, but that's another blog entry.)

As engineers who work on teams, we have to constantly manage an important balance. It's one between what each of us brings based on our individual experiences, convictions, and baggage, with the roles we're assigned, with the goals of the organizations we work for. Now there's absolutely a place to draw some hard lines, and offer non-negotiables, when you see a particular course of action is going to put the big goal at risk. Those should be rare occurrences. Be sure you understand the difference between risks to the goal, vs. risks to the way you want to do things.

But There Is Hope: Some Helpful Tips

Having trouble letting-go? Like my experience with making music, and my experiences in the present: here are some strategies that help me do just that:

  • Focus on the goal: The shared goal you and your team have, should be one that you really believe in. If you're not on board with the goal, you may want to reconsider your employment situation. But let's assume you're still on board with what your team is trying to achieve. Having a larger goal that drives you is extremely important for satisfaction in one's career. That goal has to sit a step beyond how you write code. Commit to a goal and it will  help you entertain other possibilities of achieving it. This will make it possible to let go and try things a different way.
  • Make it about the work: Don't take things personally! It's not about you, and most of the time, your team isn't focused on you, it's about the work. By having the discipline to not take things personally, you allow your team to challenge you, and then it builds trust that allows you to challenge your team. Because collectively you care about the same thing, the work.
  • Get a hobby: Ok, so your team has a norm of doing very strict test-driven development. (I've been on such a team, before.) The engineering lead wants to see the tests written out before a single line of code is written. What a drag, right? You love building software by running and gunning it. So do that! Just don't do it at work. By having interests and outlets outside of what you're doing at work, allows you to get go of things that may be very personal to how you work, because you have other areas in life where you get to do these things. You can let go of the small stuff, so you and your team can work better together to achieve the big stuff!

Parting Words

Decades later, I barely remember the things I argued about while making that album. I value the music we made and the things we achieved so much more than what we had to lose. I tell this to all my fellow engineers out there who find themselves sometimes frustrated.  In the constant negotiation and struggle, we hope to make each other become better engineers and help refine our individual an collective crafts. By staying committed to a bigger picture, we give ourselves a better chance to achieving the things we want to. And it goes back to an old proverb that has come across my path time and time again: alone, we can move quickly, but together, we can go far.


Staatus: Exploring the Slack API

Back in April, Slack released a cool new feature that allows you to set a status message on your account. Some of the examples they provide are:

  • In a meeting
  • Commuting
  • Out sick
  • Vacationing
  • Working remotely

"This is awesome!," I thought. "Now I can do what did on AIM in 1997!"

Slack did sprinkle this status in various places in the UI, but it's still a pain to go searching for it, especially if you haven't chatted with a person in a while. Plus, there doesn't seem to be an easy way to see a compiled status for a group (e.g. @engineering-team).

Enter: Staatus

I built Staatus on a PHP framework called Silex. It's a microframework based on Symfony that provides the guts for building simple single-file apps. Here's an example:

require_once __DIR__.'/../vendor/autoload.php';

$app = new Silex\Application();

$app->get('/hello/{name}', function($name) use($app) {
    return 'Hello '.$app->escape($name);
});

$app->run();

Staatus allows you to see a compiled status of an individual, a particular team, or everyone in a channel. The code is over on our Github.

I have to hand it to the devs at Slack. The API was super-easy to work with. I made use of these REST commands:

With that, I was able to display both status emojis/messages, but also a blue diamond if the person is online:

The Code

Coding this up was very straightforward. I'd say the only quirk I ran into is that the calls take too long, and Slack does not like that. If your plugin doesn't return within a few seconds, you get an error message. My plugin is hosted on Heroku, so between the lag of Heroku waking up instances and the time it takes to run all the API calls (which can amount to many, especially when Staatus is run against a team name), I needed to figure out a way to return a delayed response. Normally, in a single-threaded language like PHP, that's not easy. Most frameworks follow a very "serial" manner of generating a response:

  1. A request comes in (possibly with parameters).
  2. A response is generated.
  3. The response is returned and the request dies.

So if step 2 was taking too long, how was I going to work around Slack's request time limits? The answer comes in Silex's $app->finish() method. It is documented as:

A finish application middleware allows you to execute tasks after the Response has been sent to the client (like sending emails or logging)

Here's how I used it:

$process = function(Request $request) use($app) {

// first, validate token
 $token = $request->get('token');
 if (empty($token) || $token !== VERIFY_TOKEN) {
 $app->abort(403, "Invalid token.");
 }

$response = [
 'response_type' => 'ephemeral',
 'text' => 'Gathering staatus...'];

// just return; the rest of the processing will happen in finish()

return $app->json($response);
};

$app->get('/', $process); // for testing
$app->post('/', $process);

$app->finish(function (Request $request, Response $response) use($app) {
...
}

As you can see, my $process method returns immediately and I do the rest of the processing in a finish() method. This allows me to take as long as I'd like (give or take) to return a response back to Slack using a one-time response URL they provide. (Technically, you can't take as long as you'd like to respond. Slack has a hard limit of "up to 5 times within 30 minutes"):

$response = [
 'response_type' => 'ephemeral',
 'text' => $text];

$client2 = new Client(['base_uri' => $responseUrl]);
 $response2 = $client2->post('', [
 'json' => $response,
 'verify' => false
 ]);

And that's all, folks. So, go ahead and download Staatus, deploy it on Heroku, and you'll be partying like it's 1997 all over again. BOOYAH!


Traackr :hearts: Instagram

As we continue to support the influencer marketing programs of our clients, we have found it imperative to consume and dig as much as we can out of influencer content created on Instagram. Adding to the consumption of post captions and metrics for engagement reports, Traackr also gives users the ability to harvest the photo tags on influencer posts and make them searchable !!! :)  

Ready? Check it out.
Let’s look at the Traackr profile of the most decorated olympian in history:

Michael Phelps' Traackr influencer profile.

Now, let’s find a post that has photo tags on it.   Oh look...here’s a good one (they seem to be having a lot of fun eh?):

Michael Phelps' instagram post viewed from his Traackr influencer profile.

Now let’s search for one of those tags. I like @casamigos too… read my mind :wink:wink:  Voilà!

Searching photo tags through Traackr.

But … I thought keyword queries only matched the actual content of the post. All I see is ‘Boys will be boys!!! #meldman’. How did you do it?”  

Well… here’s an oversimplified explanation of how it works.

Making photo tags searchable at Traackr.

So, at step (1) we get the post from Instagram’s public API. At step (2), we store it in our search engine and at step (3) we query for “@casamigos”.  And yea...you guessed it! The real magic happens at step (2).

When we’re indexing content, we append the photo tags to a secret field that keyword queries are executed against. But what we surface in the UI is a field that contains the original post “Boys will be boys!!! #meldman”.

Since you’re such a curious cat, here’s an excerpt of what the record looks like in our search engine:

{
  "_type": "post",
  "_source": {
    "postUrl": "http:\/\/instagram.com\/p\/BTIKhMygox-",
    "rootDomain": "instagram",
    "author": "m_phelps00",  
    "postContent": "Boys will be boys!!! #meldman @randegerber @makenagbc @jjd7007 @stuttsydlc @casamigos @romanstutts",
    "postDisplay": "Boys will be boys!!! #meldman"
  }
}

Hint: See the difference between postContent and postDisplay?

So why do we do this?

We want to do more than just track Instagram content to compute the metrics that allow us to analyze an influencer’s reach and resonance. We believe that with Instagram’s ever growing outreach and business impact, the more value we derive from its content, the more meaningful will be the insights we provide to organizations that invest in the practice of influencer marketing.

As it pertains to this particular feature, our customers are able to get more insights on brand mentions by using our platform to match mentions on photo tags and get further analytics and reports on them :)


Git Driven Release Management

Like many engineering teams, here at Traackr we like to streamline our workflow to spend as much time as possible building cool features. We also like to release early and often. And our product team likes being able to answer pesky questions like "has feature X been deployed?" or "there was a regression with feature Y, what release was that included in?". At times, these requirements can be a give and take. Using an issue tracker helps answer questions about when things were released, but navigating an application like Jira is a context switch. Plus, it's easy to click the wrong buttons. Releasing often means these context switches and mistakes happen frequently. Can we do better?

Some of our teams release more often than others.
Some of our teams release more often than others.

We think so, which led us to look at what we like about our tooling. One great thing about using Jira and Bitbucket is the way they seamlessly links commits to issues by including a ticket ID in your commit message. Because of this, we've standardized on a "<Ticket ID> <Message>" commit message format. We enforce this standard using a commit hook. This got us thinking... If we can link Jira tickets to commit messages, can we also map our git tags to Jira fix versions? It turns out the answer is yes!

Out of the box integration is nice, but sometimes you need to do it yourself.
Out of the box integration is nice, but sometimes you need to do it yourself.

The prototype

There were two main problems to solve. How do you identify a range of commits associated with a release? How do you interact with Jira to tag the issues with a new fix version? Enter release_fix_versioner.py.

At Traackr, we use a git-flow tagging and branching strategy; this is very convenient because for every release we already have a tag to reference. By providing our script with a new git tag, we can grab all commits between this tag and the previous tag to represent all of the commits to create a new release. With startTag and endTag, git has a handy command "git log --format=%s startTag...endTag" to print a list of commit messages in an easy to parse format. From there, it's a simple matter of parsing the commits to come up with a unique set of issue IDs. In order to support a variety of commit formats across different teams in our organization, the parsing is done using a regular expression with named groups to identify the key and message: "(?P<key>[\w]*-[\d]*)[ :-](?P<value>.*)".

Interacting with Jira turns out to be simple as well; the interface is extensive and does anything you could ask for. To start with, we decided to add some validation to each ticket prior to dealing with tags. We check things like making sure the work is finished by verifying the state equals "Done". This method is really all there is to it:

After creating two more similar methods to create a new fix version and add that fix version to each ticket, we've got ourselves a prototype:

Next Steps

Now that we have this script, we can start using it to simplify the manual issue management. If it works out, we'll include it as an automated step in our one button deploy job, and we'll never have to worry about Jira being out of date again. This could even be used to generate release notes for our public facing applications.

All the code for this hackweek project is available on github. Give it a try and let us know how it went!


Great Scott! HackWeek 5/1 Recap

Prologue

It’s 6am on a Thursday morning, and I’m realizing the feature I had built last night to demonstrate Vue.js’s double-binding capabilities has regressed due to some code-reorganization I decided to do last-minute.  I thought I had done a good thing, but I ignored my sensibilities to quit while I was ahead and just do that “one last thing”.

So I put on a pot of coffee, and I spent the next few hours not only fixing what I had broken, (in order to make sure my demo doesn’t fall flat on its face in front of my esteemed colleagues), but I also tried to strategize the best way to communicate the week-long and tearful journey towards carving out a path to refactoring an important yet 3-year old feature on our app, in a way that employs the best that VueJS has to offer without throwing the jQuery baby out with the bathwater, all in 360 seconds. Why? because it’s our Hack Week Demo Day!

Hack Weeks @ Traackr

Once a quarter, we take a collective pause from roadmap-focused development, and carve out an entire week for the engineering team to work on projects of their own. What started out as a monthly hack day, we quickly realized that a single day was not enough for any of us to really flesh out let alone implement our ideas. Experimentation needs time and iteration if it would materialize into something solid; we needed more than a day to experiment, fail, retry, and repeat!  So, we decided to have our hacks less frequently but for a much longer period of time, and thus Quarterly Hackathon was born.

The 5/1 Hackweek Recap

This particular Hack Week arrived shortly after we completed a project that the entire Engineering team had been working on for the good part of 6 months. The project was a set of tremendous improvements and new functionality added to the Analytics Suite of the Traackr App, altogether has been named Integrated Influencer Intelligence (or I3).

The temptation after such a sizable release, is to use this unstructured time to make all those small improvements to what we just released vs. spending the time looking at new problems with fresh eyes. This time around, most of the team spent time on fairy new ideas, with some folks improving on existing ones.  By the time the week ended we a whole collection of demos and proof of concepts ranging from: Devops dashboards, to Slack integrations, to enhancements to security, just to name a few.  But like most Hack Weeks at Traackr, it was a great time to shift gears, recharge, and inspire new ideas not just for our team, but for the company as a whole.

So, without further ado, let’s dig into some of the Traackr team’s Hack Week projects, in the gallery below:

Our 5/1 Hackweek Projects Gallery

The gallery below only describes high level info on the projects.  More in-depth articles about our Hack Week is still to come!


Boston ElasticSearch Meetup, 3.27.13 - Language Search presentation

External link: http://www.slideshare.net/bwarner77/language-search


The Simpsons Love Traackr

The Simpsons are very impressed with Traackr (@ SF office)


Just Dave: How to use Traackr influencers monitor as your screen saver.

Just Dave: How to use Traackr influencers monitor as your screen saver.

8 Reasons To Choose A Startup Over A Corporate Job

8 Reasons To Choose A Startup Over A Corporate Job