InRhythm

Your partners in accelerated digital transformation

Software Engineering

Unleashing The Potential Of Your Offsite Team

Business photo created by freepik – www.freepik.com

Thriving vs Surviving

Are You Unleashing Your Team’s Potential? Or, are you an engineering Practice Lead or Manager who’s unconsciously capping your team’s potential? While there may be the odd diabolical leader who intents on deliberately holding his or her team back, I like to think that doing so is not the norm. Leaders of agile craftsmen want their teams to flourish and fly through each sprint. Doing so will require creating an environment and work culture that fosters improvement and unleashes a team’s potential.

With a new year and decade here upon us, the idea of making resolutions to catalyze changes isn’t new. It’s a centuries-old tradition that has begun to fall out of favor. Given that < 8%  of us make it through the year, performance and motivation coaches suggest that we set goals for the year instead of resolutions. By setting a goal, we know which direction we’re headed for and it allows us to “slip back” or go off-course occasionally yet still track towards the goal unlike resolutions, which do not offer the same latitude. 

Here at InRhythm, we’re looking forward to achieving continued success in 2020. With increased efforts to build and empower our 10x teams and to better enable our clients, we have set several key goals for the year ahead.

2020 Goals

  1. Continue to put our customers first and make every effort towards 100% customer satisfaction
  2. Foster a culture that truly embodies the Agile Manifesto
  3. Grow our footprint in new markets and industries 

As the Practice Lead , I’m conscious of how well my team is performing and how the toll of being onsite at clients’ workspaces affects them. I’m also aware that I need to give the team space to work together on a sprint and to figure things out on their own. When they hit an obstacle or begin struggling with forward progress, that’s the time to jump in. Until then, leaders must encourage their teams to experiment and err, support them, and back them when the choices they’ve made may not be the ones anticipated by their employer but they’re exactly the right ones needed for the client.

In addition to giving your team some latitude and space so that they can creatively solve problems without you helicoptering over them, you also need to think about giving them recognition. Of course, nobody wants to celebrate repeated failure, but, if a software developer made an informed decision to try to do something in a new way and everyone could extract lessons learned from that effort, then s/he/they should be celebrated for making a bold move and trying to do something different. It should go without saying that the successes also need to be celebrated. Recognition motivates teams to try harder.

Efforts in the opposite direction will have – no surprise – the opposite effect. For example, a lack of recognition for doing well or finger-pointing when there is an error will demotivate teams and start to put restraints on their ability (and desire) to flourish. Powering up 10x teams requires motivation and support so that members can dig deep and unlock their potential. Motivation should be a weekly or monthly focus and not reserved for the one day each year when companies formally recognize their employees, clients or management team. 

Here at InRhythm, we’re encouraging more dialogue between members and practice leaders and added the role of a liaison designed to facilitate open and honest discussion. We’re creating a culture where it’s safe to respectfully voice an opinion and to try new things that could make a difference for our clients. It’s also about accountability. If a team member come forward and voices a concern or a need that does not get addressed with an effort towards closed-loop communication, that member’s potential becomes thwarted. 

Have you made 2020 all about your team’s potential? Are you subconsciously thwarting it or actively boosting it? Be the practice leader that helps teams thrive – not just survive.

The Importance of Placing Individuals Above Processes and Tools

Empathy should be regarded as a super-power. Not enough people have it and the workplace – indeed, the entire world – would be a better place if more people did have it. When you have project deadlines or you’re in the midst of an intense all-hands scrum, it’s easy to forget about the people factor. That is, there are people working with you and for you who are missing celebrations, concerts or the opportunity to just chill out at home because their effort is critical to your product development effort.

But you’re on a tight timeline. You have key deliverables. Your client has worked backwards from the launch and expects that you will deliver a bug-free software solution by the date circled on the calendar. As the Practice Lead, you may be luckier than most in your role if you have a dedicated team cranked up on caffeine and working late into the evening – every evening, in fact. This is great for deadlines but it can have far-reaching negative consequences if this pace is expected to  be sustained.

The Agile Value #1 requires that we value individuals and interactions over processes and tools. Yet you’re conflicted. Project deadlines and deliverables are what they are and you’ve explained them to your team. Missing a due date and delaying a launch is not going to happen on your watch. Processes for coding, testing, documenting must happen as prescribed, regardless of the yeoman’s effort required to get it done. Your team understands this, right? Surely you told each team member that they were doing great work when you met last year for their performance review?

Maybe they do. Or maybe they don’t. Agile product development places enormous demands on the people doing the work. Both the team members and their practice leads have to grapple with the relentless pressure and the temptation to skip part of the process to move things along faster. 

When you’re building high velocity teams, you need to make daily investments in your people, processes and infrastructure. Take any and every opportunity to express empathy, understanding and gratitude for the work that your team, and each individual on your team, is doing. Expressing appreciation once per year during a performance review will likely end up becoming a one-and-done experience because that employee likely won’t be around this time next year.

There are simple ways to bolster your team’s productivity and motivate them to stay on track with respect to processes. The easiest way is to say, “Thank you.” If you want a high velocity team who is loyal, dedicated to the needs of your customers and proud of the work they do, then say what you mean and mean what you say. Be sincere. 

To help ensure that your agile engineers remain “your” agile engineers, go one step further and acknowledge the efforts of individuals in front of others. People are human and their efforts, sacrifices and basic needs must be openly acknowledged. As software engineers in a hot market, we have the flexibility to go wherever we like towards the goal of being part of a community that values our membership. Agile leaders must reinforce appreciation of these “extra efforts” through grace, gratitude and occasionally, through special dispensation. Catering dinner (that’s not pizza) for the team every once in a while is a good expression of gratitude. This is how to build trust and long-term relationships, as well as high velocity, agile teams. 

Staying strong on execution and adhering to process is critical for success. Acknowledging the personal efforts that it took to enable that success must be acknowledged. Remember, as per agile Value #1 –  if you put people first, ahead of processes and tools, you will have created a space that fosters a high performing team’s success.

Iterate Your Way to Success

“A learning experience is one of those things that says, ‘You know that thing you just did? Don’t do that.’” — Douglas Adams, The Salmon of Doubt

Here’s a thinking tool: when you’re having difficulty finding a solution, guess. Then you have something to work with.

In other words, when you don’t know what to do next, oversimplify and self-monitor. Iterative development strategies like The Agile Method are just versions of this idea. It’s also fundamental to many machine learning (or AI) strategies.

Daniel Dennett once gave a nice breakdown of how evolution works:

How To Create a Chicken:

1. Take a dinosaur
2. Let it replicate
3. Select for flightworthiness
4. Repeat steps 1-2-3
5. Repeat step 4
6. …until you get a chicken

The thing about evolution is that nobody really knows what will be selected for, or how future conditions will impact individual survival, or just how all of that will produce chickens or ocelots or the particular way an owl turns its head. There is no intelligence to it — it’s a thoughtless process. The lesson is to keep moving, to keep iterating. Progress is always better than stagnation.

The great news is that you are an intelligent designer. You can observe and change reality at will; you need not wait on randomness to discover working designs—but don’t be afraid to guess. The mistake is in assuming that you’re designing the perfect final state of a solution (complex) instead of the first working state (simple).

Try to promote continuous improvement through ongoing positive change, keeping on an open mind about unconventional solutions. Foster a culture of accountability, have a clear purpose, and keep checking if you’re any closer to your goal. Trust that useful properties will emerge out of creative interactions, in unpredictable ways. Be open to surprises:

1. Intelligently analyze complex systems to find weaknesses and inefficiencies.
2. Create a range of solutions and intelligently determine both the right solution and the right success criteria.
3. Model and test the solution in collaboration with all stakeholders to validate the solution
4. Analyze the results, measure against success criteria, and restart the process on failure.
5. Standardize success into repeatable guidelines and share that knowledge with all stakeholders
6. Repeat 1-5, continuously.
7. …until you get a chicken (Okay, maybe not a chicken. But you get the point.)

At InRhythm, we work tirelessly to ensure that our engineers are prepared to succeed in any engineering culture. Our training program, InRhythm University (IRU), is designed to ensure that every graduating engineer has mastered the technologies and techniques that we know work at the highest levels of the industry through continuous repetition of the above process. As we continue to train and teach new engineers through IRU, we will also continue to pass along what we learn. Keep learning and keep growing.

 

WebAssembly Will Change the Way You Code

WebAssembly (WASM) is a new type of code that runs in browsers. Previously, developers of browser-based web applications had only one choice of programming language and/or environment: JavaScript. This was good and much gold did the people earn; nevertheless, some weren’t happy that they had only one choice. WASM is here to change that. WASM, according to Mozilla, “is not primarily intended to be written by hand, rather it is designed to be an effective compilation target for low-level source languages like C, C++, Rust, etc.” This is the key point. You can now write “web scripts” using the language of your choice. That’s huge.

Is WASM trying to kill JavaScript? No, says the inventor of JavaScript, Brendan Eich. The goal of WASM is to enable a more linguistically-diverse development ecosystem delivering extremely fast (native or near-native speed) code through efficient compilation and parallelization (the ability for web software to take advantage of multiple processors). More huge.

This last point is maybe the most important. InRhythm engineer Will Bratches pointed out in a recent lightning talk that increases in speed are no longer achieved at the chip level—Moore’s Law is no more. What we do now is spread work across cores, leveraging parallelization and managing concurrency. Client-side JavaScript is not designed for that world. New languages like Go and Rust are. WASM unifies the two. 

Here comes the “hello world!” moment. Head over to WebAssembly Explorer—it’s sort of a CodePen for WASM. On the left panel, paste this code:

int plusOne(int num) {
return num + 1;
}

Next, click “compile”. You’ll see something like this:

WASM WebAssembly Screenshot

Yes, that’s assembly code on the right (I know!). A more human, readable version is in the center column, the WAT view, which you can read more about here.  Just scan through it—you’ll see our function name plusOne represented as $_27plusOnei. You’ll also see that we’re establishing 32-bit integer parameters, setting their scope to “local” and so forth.  You can, for example, see how the assembly code  (add)s one to the (ex)tended (a)ccumulator register for 32-bit numbers:

add eax, 1

…is represented in the WAT:

(i32.const 1)

You can now hit the “download” button, which will deliver a .wasm file.  That’s really it—you have the WASM binary to use. There’s a tiny bit of work you have to do to compile the WASM so it works in your browser. The easiest thing to do is clone this simple example and load the index.html in your browser. Check the console. Now read through the code.

There’s a lot more to this subject, so start exploring. You’ll be creating first-person shooters in your browser in no time!

GraphQL: The API Query Language


Overview

GraphQL is an API query language used to obtain data from a server. It serves a similar purpose to a RESTful API, but with some distinct advantages.

The first advantage is that the you will only receive the data that you request. Part of the payload of a GraphQL request is the list of fields to return. This can help reduce load time for a request by only including the data that the consumer needs.

Another advantage of GraphQL is that you can get all the data you need in a single request. By defining the data you want from related fields, you can get all that data you need from those in one API call.

You can also very simply update the API without versioning. Adding new data to your endpoint will not cause any issues as the client will still only receive the data requested.

You can also use GraphiQL to test and document your API.

Example

Creating and consuming a GraphQL API is very simple. Let’s briefly go through setting up the server and then creating a simple client. In this article, we will be using Apollo and Node.js for the server, but GraphQL libraries are available in many languages.

First we need to define our data. We do this in GraphQL by defining type`s. Let’s consider a simple contact model:

type Contact {
name: String!
email: String!
}

This tells GraphQL that we have a type that is Contact that will include two strings, name and email. The next thing we need to do is define our queries:

type Query {
contacts: [Contact]
contact(name:String!): Contact
}

In this case we have two different queries. The first will return a list of Contacts and the other will return one Contact identified by the required name parameter.

Third we can define any Mutations that will allow for any changing of the data:

type Mutation {
addContact(name:String!, email:String!): Contact
}

The last step here is letting GraphQL know how to resolve these queries and mutations. To do this we will define resolvers:

var contacts = [
{name: "Test User", email: "test@user.com"},
{name: "Other User", email: "other@user.com"}
];
const resolvers = {
Query: {
contacts: () => contacts,
contact: (_, { name }) => contacts.find((c) => c.name === name)
},
Mutation: {
addContact: (_, { name, email }) => {
newContact = {name: name, email: email};
contacts.push(newContact);
return newContact;
}
}
};

Now all that is left is to hook it up. This depends on your exact setup, so I won’t go into detail. here.

Client

Creating a client to consume your new GraphQL endpoint is very simple.

Let’s create some GraphQL queries:

{
contacts{
name
email
}
}
query Contact($name:String!){
contact(name: $name){
name
email
}
}

Mutations will look something like this:

mutation addContact($name:String!, $email:String!) {
addContact(name: $name, email: $email) {
name
email
}
}

You can find a simple version of this application here: https://github.com/thomascking/graphql

More information: https://graphql.org/ https://www.apollographql.com/ https://www.robinwieruch.de/graphql-apollo-server-tutorial/