Network Protocols

IP – Internet protocol

This is the basic layer of the protocols. Almost all communication in the internet network is implemented using this protocol. This is the address (numeric labels) of all the devices connected to the computer network. IP addresses can be either public or private. There are two versions of IP addresses IPv4 and IPv6.  All other protocols (TCP, UDP etc) are built top of IP.

Messages over IP are communicated as packets, which are small bundle of information at 2^16 bytes. Each packet will have a Header and Data part. Header will have all the meta data about the packets and data



Engineering manager – steps to fails

Congratulations – you’re a new manager! No, really, I’m being sincere. You can hear the sarcasm in my voice? Sorry, I tried, but I know that along with some excitement, there’s plenty of doubt and angst. You have likely followed a path that’s similar to mine and many others. You‘ve been a software engineer (or insert role here) for many years. You became the “go-to” person, earned a senior title, and were known as an informal leader by those outside and within your team. Probably played the “tech lead” leading up to this point. You may have even been fighting this “promotion” for some time, didn’t want to get out of the code, lose your skills. But really, you were afraid that you wouldn’t be as good in the new role. Finally, somehow you were convinced to take the chance, and now here you are. From senior engineer to junior manager.

How do you succeed in this new role? How do you once again rise up through these new ranks and achieve the same level of results and credibility that everyone is expecting, especially yourself? There are decades of books and thousands of blogs dedicated to trying to answer these questions, so I‘m not here to pretend that I’ve got the secret to success. But I do know a few ways that I’m pretty sure can guarantee you’ll fail.

1. Keep coding.

That should get the comments flying. Your company may expect managers to do some coding, to be a manager and individual contributor. In my experience, and seemingly that of many others, that usually fails. You aren’t able to consistently give the attention that either role requires, so you fail at both. If you’re lucky, you work for a company like I do, where I practically signed an oath saying I wouldn’t code.

Ok, so even if some coding is expected of you, it certainly is no longer your primary purpose in the company. What I’m really talking about is when you fall back into coding because you are not sure what the heck to do in your new role. So you return to what you know, where you’re comfortable. That might provide short-term benefit to some projects and make you feel good, but I guarantee that you are not achieving your primary objectives. You’re hurting the long-term output of your team, and you’re also not growing in your new job.

I don’t think any of us want to simply give up on all that valuable and hard earned technical experience. This article provides some good options for managers that want to hold onto those coding chops.

2. Focusing only on the work, not the people.

As a manager you have two important duties: to grow the team and to deliver value to the business, and I’d argue that you should prioritize them in that order. The former amplifies the latter.

Our typical picture of delivering value is completing projects, shipping features, fixing bugs, etc. And if you’ve managed to escape not falling back into being the “lead engineer” and coding all day, then you are still probably trying to satisfy that need to complete tasks each day to get that feeling of utility. This often leads to one acting as a project manager or task master, focusing on assigning tickets, tracking metrics, asking for status updates, leading design discussions, story authoring and so on. In short, you’re focused on the work of the team. You can check things off the list each day and feel like you’re getting things done.

And you are. But just half of your job. The easiest half. Because the other half is hard, the most unlike what you’ve been doing your whole career and probably where you lack the most skill. That other half is growing your team. Helping individuals in their career not only technically but as productive people. Finding ways to make your team work better together. Having one on ones, listening, coaching. Turns out the “soft” stuff is the hard stuff. And if you ignore this part of your job you’re leaving a lot of value on the factory floor. You may deliver results, but they will be far short of the team’s potential. You may optimize some efficiency, but you’ll always lack true progress in the effectiveness of the team. You won’t ever meaningfully raise the bar, and you won’t know why.

The effectiveness of the team, and the ultimate value they produce, starts with the team members themselves not their work.

3. Measuring your value by your output

Back in your days as an individual contributor, as a builder, it was easy to quantify your output, your value. “I finished 2 stories today”, “I figured out that crazy bug”, “I’ve got all the tests passing”. These were tangible units of work, easily tied to the team’s deliverables. And those commits have your name on them. Its easy to see the work that is attributable to you and measure your value by how that output helps the team progress towards their goals.

But now much of your impact is seen in 2nd order effects. Its harder to draw the correlation of your work to that of the team’s. Adding to this confusion is the fact that your work is no longer neatly defined by well prescribed tasks. You might not even be really sure what “work” you do.

And so, as a new manager, you tend to grasp the few concrete tasks you have and use those to get a feeling of accomplishment, of adding value, and likely over-inflating the actual worth of that work. Powerpoint decks, budgets, status reports, scrum artifacts; these might be the output of work you do, but it’s not the job. In truth, your work is reflected in the work of the team. Having them accomplish their goals is your goal. Your value is ultimately measured by their success. Focus on the team and whatever is needed to help them succeed.

4. Expecting without expressing.

Do you have clear expectations in your head about what you need from your team? From each individual? Have you actually told them?

Its quite natural for us to think the mind of another will work similar to ours. That we share the same discipline, motivations and reasoning. And this leads to many assumptions. If you and I are both looking at the same set of work with the same information, then naturally, we should come to similar conclusions about how and when that work gets done. Uh-huh. So we hand out assignments with some amount of information but with unstated and assumed expectations. And you know what they say happens when you assume.

When tasks are assigned or work is delegated, make sure it includes the assumptions and expectations.

“Hey remember this is just a spike, I expect you to document your findings and then review them with the team before you move forward with any real coding.”

“This story is blocking QA, so it’s your top priority. I assume you’ll want to time-box yourself 30 minutes to get your current work paused. If this story can’t be done by the end of the day, communicate with the stakeholders asap.”

What’s much harder are your subconscious expectations, those you don’t realize that you have until they aren’t met. They’re your personal model for decision-making, the way you would have done it. You just assume that’s how its going to happen. But of course you didn’t communicate any of this, and when the result doesn’t fit into that mold you’ll be disappointed in others. This can be very demotivating and demoralizing to the team. If you have expectations about their work you’d better let them know. You can’t leave them guessing. And if you are unsure what your expectations are, then spend the time to go deep with yourself and figure it out. It’s your job, your responsibility to the team, and likely the expectation of your boss.

5. Leaving the team out of commitments

You’re a new manager, and you want to impress the boss. “Sure we can do that”, yes yes yes yes. Writing checks your team can’t cash. I’m pretty sure most of us have been on the other side of this. You are given deadlines that are impossible, expected to hit deliverables that you never agreed to. What did you think of your boss? Sure, maybe the team rallied a few times and hit their targets, but I bet that wasn’t enough. Your boss is looking great now and just keeps making those big promises. Pretty soon, the team’s had enough and people start to check out, move to other teams, or leave the company altogether.

You know what they say, shit rolls downhill, but to the best of your ability that needs to stop with you. You need to protect the team. So how do you do this? To start, don’t be the hero. Don’t immediately answer yes to every request from your boss, customers or business partners. Buy a bit of time and get your team involved in making the commitment. As much as possible, you want to lay out the bigger picture for the team and let them connect. Why is this important to the company? How are the customers being impacted? What are we actually being asked to solve? And most important, engage the team in the solution: “given what we know, what do you think we can do?”

There are going to be times when you have no choice but to receive and deliver marching orders, but when the team is involved in the commitment and has skin in the game, everything gets better.

6. Mistaking directing for leading

Standing on a chair and barking orders is not leadership. There are many times when its appropriate for the manager to be in the weeds and coordinate or direct the team through a set of work. But don’t mistake that with being a leader. Too much direction is often a symptom of what we like to call micro-management, and that leads to teams who are unable to work autonomously, requiring all decisions to go through you. And you will end up as the bottleneck for your team. You’ll have created a group that is inefficient and probably checked out, just going through the motions, waiting around for the next task and mindlessly executing.

Leadership inspires, it doesn’t dictate. A leader paints the picture of destination, setting a direction rather than giving directions. Instills a shared sense of purpose and meaning. Provides enough context via the mission, strategy and objectives to enable individuals to make the good decisions.

7. Avoiding hard conversations

If you’ve managed to avoid most of these failures, have I got a personal challenge for you. This is what separates team leads from people managers, learners from leaders, the noobs from the pros.

As an engineer, you likely had a few heated conversations with others about a project, the design, technology choices, coding techniques and such. But dealing with the people themselves, personal conflicts and complaints? Well, that usually got handled by the boss, if it was ever addressed at all. Guess what? You’re the boss now, and it’s coming your way. Sometimes it’s one of your employees bringing you into an issue, or someone outside the team that wants some incident addressed. But most often, it will be actions and behavior that you see yourself. They do not meet your values or those of the team, and you really need to deal with it. Your chest and stomach tighten up, and your mind starts coming up with all kinds of rationalizations and reasons to avoid it. But this moment right here is where you test your meddle, where you earn your paycheck. Its what separates the haves from the hacks. This is the best opportunity you have to make a difference in your organization. It’s these moments that can grow people and move them forward (including yourself). Dealing with these situations positively is the secret to building a highly effective team.

So how do you stop avoiding hard conversations and instead meet these challenges head on? Have hard conversations. Like so many other skills, the only way to learn how to do this is to do it, for real. You’re pretty much coding in production here. But there are ways to be more prepared and certainly tactics for improving your chances of a good outcome. The internet is filled with good advice here, so seek it out and pick a technique or two to try. You may want to start with the book Crucial Conversations.

Here’s some basics I’d suggest:

  • Try to address the issue as soon as possible. The longer it lingers, the harder the conversation.
  • Be specific and have examples. Another good reason to address an issue quickly, while the information is fresh in your mind.
  • Be prepared. Think about how you want to start the conversation, and most importantly, what you want to get from this conversation. What’s your main message and what is the desired outcome? Think ahead to possible reactions, questions and comebacks the individual may have and think about how you will respond.
  • The conversation should be focused on a person’s behavior or actions, not the person themselves. Instead of “you’re disrespectful” try “when you do X it’s disrespectful”. It’s also a good idea to focus on the impact of their actions. The effect on others or negative and non-obvious consequences they are bringing on themselves.
  • Pick an appropriate time and location. Grabbing someone in the hallway might be fine for some quick feedback, especially for reinforcing a previous discussion. But if you need to have a long hard talk with someone, make sure you have a private spot and that you also both have plenty of time. The worst thing you can do is try to squeeze an important conversation into some small time-slot and then have to cut it short, leaving it hanging unresolved.
  • Of course the best plan is to not need them. Avoid these difficult confrontations by addressing issues when they are small. Having regular and effective 1-on-1’s with your team members is a perfect opportunity to discuss problems while they are still small or before they exist at all.

The first time I had to have one of these conversations was scary, and I agonized for days. But it turned out much better than the apocalyptic episode my imagination had conjured. It really made an impact and made future dialog much easier. So face your fear, it’s not as bad as you think and the results are worth it. Your team deserves it and your future-self will thank you.

8. Stop learning your craft

Remember those years spent learning the latest technologies, tools, languages, frameworks in pursuit of becoming a great engineer? That doesn’t end when you become a manager. Management is a skill, an art, a practice. It is an ability you acquire over time and requires the same effort and dedication to learning that you devoted to engineering.

I’ve found I can use many of the same successful methods to learn about management that were already part of my engineering self-learning. Blogs, books, conferences and social media. For every blog post about container orchestration with Kubernetes, there’s one about scaling your teams using Lean methodologies. For every book about learning Golang, there’s a book laying out strategies for better 1 on 1s. And for every conference talk on monitoring your microservices, there’s one on best practices for understanding your team using data and metrics.

Ok, I decided that was too much hyperbole. In reality the ratio is more like 100:1 tech to management resources.

There are bad managers, and there are great managers. Novice and expert. Like engineering, it’s part natural inclination but mostly it’s the desire and constant pursuit of learning and improving your skills that makes the difference.

When I first made the move from engineer to manager, I found it to be overwhelming but also invigorating. To start anew with so much to learn, but so much I get to learn. Another chance to define myself in a completely new way with everything in front of me.

I still have a long way to go myself, and when I get there maybe then I’ll write about how to succeed. Until then I’m going to continue to focus on simply not failing.


Categorized as Noteworthy

When we need blockchain

Blockchain is not a solution for all the applications.

It’s good for applications with following characteristics.

Decentralized Problems

Peer to Peer transactions

Beyond boundaries of trust among unknown peers

Require validation, verification and immutable ledger

Autonomous operations guided by rules and policies

Revert(), Assert(), and Require() in Solidity

In this article, I will try to explain how Solidity compiler handles require(), assert() and revert() functions.

Earlier Solidty used throw() function, now it is deprecated, eventually it will be removed altogether.

This line:

if(msg.sender != owner) { throw; }

currently behaves exactly the same as all of the following:

  • if(msg.sender != owner) { revert(); }
  • assert(msg.sender == owner)
  • require(msg.sender == owner);

Note that in the assert() and require() examples, the conditional statement is an inversion of the if block’s condition, switching the comparison operator !=to ==.

Use require()to:

Validate user inputs ie. require(input<20);
Validate the response from an external contract ie. require(external.send(amount));
Validate state conditions prior to execution, ie. require(block.number > SOME_BLOCK_NUMBER) or require(balance[msg.sender]>=amount)
Generally, you should use require most often
Generally, it will be used towards the beginning of a function

Use revert()to:

Handle the same type of situations as require(), but with more complex logic.

If you have some complex nested if/else logic flow, you may find that it makes sense to use revert() instead of require(). Keep in mind though, complex logic is a code smell.

Use assert() to:

Check for overflow/underflow, ie. c = a+b; assert(c > b)
Check invariants, ie. assert(this.balance >= totalSupply);
Validate state after making changes
Prevent conditions which should never, ever be possible
Generally, you will probably use assert less often
Generally, it will be used towards the end of a function.

Basically, require() should be your go to function for checking conditions, assert() is just there to prevent anything really bad from happening, but it shouldn’t be possible for the condition to evaluate to false.

The revert is often referred to as cheap throw as it refunds unused gas to the sender.

assert(false) compiles to 0xfe, which is an invalid opcode, using up all remaining gas, and reverting all changes.

require(false) compiles to 0xfd which is the REVERT opcode, meaning it will refund the remaining gas. The opcode can also return a value (useful for debugging), but I don’t believe that is supported in Solidity as of this moment. (2018-09-12)

Merkle Tree

Named after Ralph Merkle.

Merkle tree is a  hash tree. Hash trees can be used to verify any kind of data stored, handled and transferred in and between computers. They can help ensure that data blocks received from other peers in a peer-to-peer network are received undamaged and unaltered, and even to check that the other peers do not lie and send fake blocks.

Robust mechanism to validate transactions

On distributed networks and peer to peer networks data is distributed across different locations .  Any alteration to these data’s needs to be verified. Even if we don’t have access to it’s true from.  Just the ability to validate whether the data is correct or not is necessary.

1. Every leaf node is the hash of it’s data block

2. Every non-leaf node is the cryptographic hash of it’s child nodes.

Algorithmic time complexity to search, validate and retrieve of merkle tree is same as that of binary trees.


Categorized as Blockchain

A Career Cold Start Algorithm

Several times in my career, I’ve joined a team whose work was already well under way, where I had a massive knowledge deficit, and didn’t have pre-existing relationships. None of those excuses relieved me from the pressure I felt to establish myself and contribute. Over time, I realized that the natural instinct to push for early impact leads many incoming leaders into challenging relationships as they expose their knowledge deficit and waste time. So, I developed an algorithm that has helped me ramp up quickly — and in several cases — have an impact in a relatively short period of time, while minimizing collateral damage.

The first step is to find someone on the team and ask for 30 minutes with them. In that meeting you have a simple agenda:

  • For the first 25 minutes: ask them to tell you everything they think you should know. Take copious notes. Only stop them to ask about things you don’t understand. Always stop them to ask about things you don’t understand.
  • For the next 3 minutes: ask about the biggest challenges the team has right now.
  • In the final 2 minutes: ask who else you should talk to. Write down every name they give you.

Repeat the above process for every name you’re given. Don’t stop until there are no new names.

The sum of the answers from the first 25 mins will not give you a complete picture of the team’s work. That will take months to develop. But they will give you a framework for integrating new information more quickly, which will speed up how fast you ramp. It will also heavily over index on the areas of work under active discussion, which will help you dive in productively to the most critical discussions immediately. The nature of what people choose to discuss is a very valuable signal about the problems the team face, as it may be about the work, the organization, or process. Finally, it will give you a sense of the language and terminology that can very often be a barrier to working smoothly with teams.

The answers from the second question give you a cheat sheet on how to impress the team with early positive impact. Some of the things you’ll hear will take time to fix, such as “we need a bigger team” or “our infrastructure isn’t scaling.” Those are important and it will be good for the team to hear you internalize those challenges. But a surprising number of the issues you’ll hear repeatedly will be things you can easily help with, like “we waste a bunch of time in meetings every week” or “we need a dedicated conference room.” I start with the latter as quickly as I can because those are the types of things teams often neglect to prioritize, in spite of a compounding negative impact on progress.

The third question will give you a valuable map of influence in the organization. The more often names show up and the context in which they show up tends to provide a very different map of the organization than the one in the org chart.

For all the value I just described, the greatest value in this process isn’t in the answers — it is in the asking. Taking these meetings and listening shows proper respect for the team that’s in place. It can be hard to remember, but while you may be insecure about taking a new role because you feel like you’re at a disadvantage, the people you’re speaking with may also be unsure about you taking that role and what it means for them. Demonstrating mutual respect builds the trust required to make progress.



Categorized as Career