6 Lessons On Work Ethic I Learned In One Year Of Professional Career

vagnini_101317_4227_hero_lg

Time flies. Recently I had completed one year as a full-time employee at my current employer Squad. A year has passed, and I decided it was time to revisit instances, memories, and experiences and to recollect what I had learned as a professional in this past year.

It was also a wake-up call to reassess and redirect the ship named professional career to make sure it doesn’t get stuck in a whirlpool.

After all, our career is our responsibility and we all should make efforts to “Own our story!”.

This is going to be a list of 6 important lessons in professionalism and work ethic that I learned working as a Product Engineer at one of the most innovative startups in India.

1. Know your field

Do you know what a facade pattern is? Do you know what sprint and story points are? Do you know how to work your way with the debugger your IDE provides?

A wealth of ideas, disciplines, techniques, tools, and terminologies have decorated the last fifty years of our field. And if we want to be a professional we want to know a sizeable chunk of it.

The motto that I believe in is, “If you want to see far, stand on the shoulder of the giants”.

 

2. Continuous Learning

The frenetic range with which the industry is changing, it means that we as engineers also need to learn colossal amount just to keep up.

Read books, read articles, watch talks. Keep adding deltas to your learning daily.

 

3. Practice

This stuck me around 2 months back. Tennis is my favorite sport, and players believe that playing in the tournaments continuously actually makes their game less polished.

It’s the deliberate practice of doing things right, which makes it gleamy again.

Is it true about our jobs also? Cutting corners to meet deadlines, working on the outdated stack at the company, working with legacy code, can all this make us less sharp.

At least I find it to be true, and practice to deliberately improve your craft is a vital component of one’s work ethic.

 

4. Know your domain

It is the duty of every software developer to understand the domain of the solutions that they are programming. If you are writing software for healthcare, get at least a basic understanding of healthcare, if you are writing for sales, know about sales.

Read a book or two on the domain, ask the domain experts.

We should be able to know enough about the domain to question the product direction and feature requests that we get.

 

5. Collaboration and mentoring

We all must make special efforts to collaborate, mentor and get mentored by other developers.

Whatever I have learned in this course of one year, a major portion of it due to learning from others.

 

6. Humility

Programming is an act of creation. It feels like magic when we can write code that can do things that can produce tremendous value.

We all should take pride in our work, but never be arrogant about it. We should be confident in our abilities and take risks.

But we must know that we will fail. Things that we create will break, risks will be proven wrong and we will be called upon for these mistakes.

And when all this will happen, all we can do is be humble and take Howard’s advice, laugh and move on.

 

That’s all, folks!

 

Advertisements

Creating Outbound Call Warm Transfer Using Twilio In Python and Django

twilio-730x365

Have you ever been connected to a call where it was transferred to a third person for further assistance? Well, that’s call transferring.

Warm transfer of calls, in contrast to cold transfer, doesn’t disconnect the call in between and thus gives the customers a  more seamless experience.

Recently at work, I was building a system to convert regular calls to a warm transfer if needed. And in this post, I’ll be sharing what I learned while building the warm transfer system.

Outbound calling and warm transfer

An outbound call is a call initiated by a call center agent to the customer. Warm transfer in the case of an outbound call means, a transfer to the second agent while the first agent is also on the call and can drop off later after introducing the customer to the new agent.

For the rest of the post, we’ll be referring the parties as:

  1. The First Agent (Leg 1 of the call)
  2. The Customer (Leg 2 of the call)
  3. The Second Agent (Leg 3 of the call, warm transferred to this agent)

We’ll be using Twilio to build our warm transfer system.

Overview of the system

The system mainly follows the workflow given below:

  1. A call is created to the first agent (leg 1).
  2. Once the first agent is connected, call to the customer is initiated (leg 2).
  3. When the customer picks the call, the agent and the customer are connected by a regular call.
  4. The agent triggers the warm transfer.
  5. The customer’s leg is updated to be in a new conference call.
  6. The first agent also joins the same conference call (Negligible delay).
  7. Now the first agent and the customer are on a conference call.
  8. The second agent is connected to the conference directly (leg 3).
  9. The call is warm transferred to the second agent.

Connecting the customer and the first agent by a regular call was done both to retrofit the existing system that supported only regular calls and also not all calls will be needing warm transfers.

Connecting the first agent and the customer

First, we’ll connect the first agent and then the customer. Note that customer is connected in the second leg making it an outbound call.

‘twiml_second_leg_url’ is the URL that Twilio will hit to get the TwiML once the first agent picks the call.

We want our URL to return a TwiML Dial verb to connect the second leg to the customer.

Ideally, we would want our TwiML views to be stateless. Thus all the parameters needed by these views are passed as query parameters.

Note the action URL. Action URL is the URL Twilio will hit when the first leg is disconnected.

We’ll use this action URL callback to connect the first agent to the conference call.

At this point, the first agent and the customer are in a regular call.

Next, we’ll start the process of warm transfer.

Triggering warm transfer

The process of warm transfer looks like following:

  1. We move the customer the conference.
  2. We move the first agent to the same conference. (negligible delay for humans to perceive).
  3. We add the second agent as the participant to this conference.

1. Updating the customer leg to be in the conference

We did the following:

  1. Created a URL that the Twilio will hit to get the updated TwiML.
  2. Updated the URL for the customer’s leg by its call sid.

As soon as we update the URL, Twilio will hit the TwiMLDialConferenceView written below and will put the customer’s leg in the conference.

2. Putting the first agent’s leg in the conference.

Remember we gave an action URL (“first_leg_disconnected_url”) for the first agent’s leg when dialing the customer’s leg. This is where we’ll leverage it to put this leg into the same conference as the customer.

Twilio will hit this view when the first leg gets disconnected because we’ve moved the second leg of the agent to the conference call.

As we can see, we are returning TwiML to put this leg also on the conference call.

For the cases when we don’t want the first leg to go into the conference upon disconnect, we can simply return TwiML HangUp verb to end the call.

So, at this point, the first agent and the customer are on a conference call.

Now, we’ll take the final step towards warm transferring the call, connect the second agent to this conference call.

3. Connecting the second agent to the conference call

As we can see, to connect the second agent on the conference call we use the conferences API of the Twilio python client.

With early media set to true, we are able to listen live call status of the second agent on the conference call like ringing, busy or answered.

4. Bonus step

Treat yourself to a chocolate pudding! We ‘ve implemented a warm transfer system using Twilio, Python, and Django!

Conclusion

Outbound calls are an important factor in inside sales. Creating a seamless warm transfer can help the businesses drive conversions by connecting the customer to the right person at the right time.

In this post, we implemented an outbound call warm transfer system using Twilio, Python, and Django.

References

1. https://www.twilio.com/docs/voice/tutorials/warm-transfer

2. https://www.twilio.com/docs/voice/twiml/conference

 

That’s all, folks!

 

Devops and The Principle Of Flow

lean-software-development-1-728

In the technology value stream, work typically flows from Development to Operations, steps consisting of functional areas between our business and our customers.

As stated in the lean principles developed by Toyota, we should optimize to get a single-piece fast and smooth flow for our releases.

We increase flow by:

  1. Making work visible,
  2. Reducing batch sizes and intervals of work
  3. Building in the quality, preventing defects from being passed to downstream work centers.

Why a fast flow is needed?

By speeding up the flow through the technology value stream, we reduce the lead time required to fulfill internal and external customer requests, further increasing the quality of the work while making us more agile.

Our goal is to decrease the amount of time required to deploy the changes into production and increase the reliability of those services.

Make our work visible

agile-pm-kanban-board

A significant difference between manufacturing and technology value streams is that our work is invisible.

It’s so easy for work to keep bouncing off between teams and yet have no visual control over it.

To prevent this and make out work more visible, we can use something like a Kanban board. (I prefer Trello for this).

Ideally, our Kanban board will span the entire value stream, defining work as completed only when it reaches the right side of the board.

Work is not done when development completes, but only when our application is running successfully in production.

Limit Work In Progress (WIP)

In technology, our work is far more dynamic than manufacturing. Teams have to satisfy demands of multiple stakeholders. As a result daily work gets dominated by urgent requests for work coming through every communication channel possible.

We can limit multi-tasking by using Kanban board, such as by codifying and enforcing WIP limits for each column on the board.

For example, we may set a WIP limit of three cards of testing. When there are already three cards in the testing column, no new cards can be added.

Using Kanban ensures that work is visible and WIP doesn’t get piled up.

Reduce Batch Sizes

one-piece-flow

Another key component to creating smooth and fast-flow is performing work in small batch sizes. Prior to the lean manufacturing revolution, it was common practice to manufacture work in large batches.

However, large batch sizes result in skyrocketing levels of WIP. According to lean principles, the ideal is a single piece flow, where each batch size is of just one.

Let’s take an example:

Suppose we have ten brochures to mail and mailing each one of them requires 4 steps:

  1. fold the paper
  2. insert the paper into the envelope
  3. seal the envelope
  4. stamp the envelope

Now in the traditional batch processing flow, we will perform each step sequentially for all ten envelopes.

In the lean one-piece flow, only one envelope can be at any given step. In other words, we fold the paper, insert it into the envelope, seal the envelope and stamp it before starting the next one.

How is one-piece flow dramatically better?

In the above example, suppose each step takes 10 seconds. In batch processing, we get our first complete envelope after 310 seconds, but with the one-piece flow we get it just after 40 seconds.

Worst, what if we find that the way we have folded the paper, doesn’t allow the envelope to be sealed. In which case we’ll be in a bigger trouble?

Eliminating hardships and wastes in the value stream

According to the Toyota Production System pioneer Shiego Shingo, a waste is:

The use of any material or resource beyond what the customer required or is willing to pay for

In software development value stream, a waste is anything that causes a delay for the customer, such as activities that can be bypassed without affecting the result.

The following are some common categories of waste that we encounter when implementing lean in software value stream.

  1. Partially done work
  2. Extra processes
  3. Extra features
  4. Task switching
  5. Waiting on QA or testing or acceptance testing
  6. Defects and bugs
  7. Non-standard or manual work

Explaining each of the above point deserves a post of its own. Will do that soon.

Conclusion

Improving flow through the technology value stream is essential to achieving DevOps outcomes. We do this by making work visible, limiting WIP, reducing batch sizes and eliminating wastes from our processes.

All of this will allow us to become more agile and will help in reducing lead times dramatically, and at the same time increasing the quality of releases.

That’s all, folks!

 

7 Tips On Making Your Engineering Workflow Faster

One of the most important thing that I like about pair programming with other awesome engineers is you get to see their workflows. How they get things done? How they get find and make their way around tools, terminal, and editors?

After witnessing and getting awestruck by many such experiences I realized that having an effective workflow can increase your day to productivity many folds.

The next step was to take action, and while doing so, I have compiled few tips to make your engineering flow faster too.

1. Identify waste:

lean-manufacturing-identifes-waste-in-workflows

According to the Toyota Principles:

A waste is any hardship and drudgery that doesn’t align itself with what customer requires and is willing to pay for.

The First step towards developing a ninja workflow is to do an audit and identify waste.

Identifying waste is the first step towards eliminating it.

Ex. My workflow had many wastes like not automating enough, not harnessing the power of IDEs, waiting for the large codebase to reload etc.

2. Get proficient with your IDE:

8rljtzts_400x400

Today, IDEs are super power packed. To develop an awesome workflow, we must learn how to harness the power of our IDEs.

I use PyCharm for my day to day work and have witnessed very considerable efficiency increase once I took steps to become proficient with it.

Features like:

  • Custom live templates
  • Smarter code navigation
  • Custom keyboard shortcuts
  • Debugger
  • Distraction free mode
  • Plugins

All make you a power user. It’s worth investing time given the return on investment.

3. Get familiar with Unix shell commands:

Getting familiar with Unix shell commands is a game changer. First, it makes you look smart and second it helps you automate stuff.

I noticed that I used to do a set of repeated tasks every day when I started working.

  1. Login to office WiFi network
  2. Open browser
  3. Open Slack in tab
  4. Open mail in a tab
  5. Start the IDE
  6. Activate virtual environment
  7. Checkout VCS repository etc.

And now all it looks like is:

~$ startwork

You get the idea. Invest some time and become a Unix power user.

4. Automate your manual workflows:

Developing skills to automate takes time. Whether they are using shell scripts, browser extensions or little code snippets.

Investing time in automating workflows is a high leverage activity.

Ex. You don’t need to manually follow a certain flow of the app to test out something every time, which takes 2-3 mins.

Can we automate this and do this in 2-3 seconds.

How much time will it save if suppose we do this 25-30 times on average?

Ex. Or automating generating search tags for blog posts 😛

5. Prefer keyboard over mouse:

Screenshot from 2018-04-23 01-02-17

We all will agree. Using mouse is slow. Using keyboard over mouse helps decrease the time it takes to perform actions by many folds.

The action that was buried under 3 sub-menus can now be performed just by pressing a key combination.

Personally, for this, I would highly recommend a plugin for JetBrains IDEs called key promoter. It’ll help big time in getting over our mouse addiction.

6. Learn at least one productive high-level language:

Getting things done in a language like Python is way faster than something like say,  Scala.

Learning at least one high-level language allows us to quickly test out ideas and implement them.

No more resistance of writing a 20 line class just to test out an API call to a service.

Move fast and test out ideas on an interactive interpreter instead of compiling code files.

7. Make it easy and fast to run the unit tests associated with just your current changes:

Screenshot from 2018-04-23 01-22-07

Running the entire test suite or even the test suite of the module you touched can be time-consuming. Life is too short for that.

To quickly validate things, make it super easy and fast to run the unit tests of just your current changes.

Personally for this, I use the copy reference feature of PyCharm a lot, and obviously, I use the keyboard shortcuts to do so.

Conclusion

With this post, I wanted to share some ways that I’ve been consciously working on to making my engineering workflow as efficient as possible. Still, there is a big room for improvement, but hopefully, this article would’ve been of a little help at least.

That’s all, folks!

 

Fail Fast: Hone Your Ability to Recover and Respond Quickly

veteran-turned-software-engineer-e1485204975427

It’s close to midnight and you are about to wrap your day off. Suddenly you get a pager-duty to resolve a critical bug that’s failing some of the automated reporting emails.

You go on to check the logs in the log management tool. This is not the ideal time to find out that logs are not getting streamed to the log management service properly.

Next, you decide to check the performance metrics of the email API and you realize that you don’t know the new monitoring tool well enough to get the right metrics quickly.

That sets the theme to why as effective engineers we should fail fast and hone our abilities to recover and respond quickly to failures.

Another post I wrote on failing fast:

https://priyankvex.wordpress.com/2017/07/08/philosophy-behind-the-offensive-programming/

“The best defense against major unexpected failures is to fail often.”

Netflix knows its way around when we talk about creating reliable systems. What engineers at Netflix have done may sound counter-intuitive, but they have made a tool called Chaos Monkey. It randomly kills services in their own infrastructure.

It turns out that this strategy helps Netflix to increase site’s reliability. Failing services during office hours when all the engineers are available, helps them perform recovery drills effectively and prepares them well enough for actual emergencies.

Why is it so important to prepare for failures?

As software engineers, our systems are bound to fail at some point and some releases certainly will have some bugs. In such scenarios, learning and investing time in the ability to recover quickly becomes a high leverage activity. It gives you the confidence to move fast with your product having peace of mind that you are ready to tackle problems if they arise.

Few reasons to invest time in recovering from failures:

  1. Prepares the team to write scripts for success via mock drills.
  2. Surfaces gaping holes in the systems used for monitoring and debugging.
  3. Helps develop better tools and processes to handle emergencies.
  4. Helps control stress and panic in the cases of actual failures.

Write your contingency plans

what-if-800x435

Ask yourself “what if” questions and work-through contingency plans:

  1. What if a critical bug gets deployed with a release?
  2. What if a user raises an urgent ticket?
  3. What if my message broker goes down?
  4. What if my systems face a spike in usage?

This can be applied to even more aspects of software engineering:

  1. What if the due date for a feature gets preponed?
  2. What if a critical team member goes sick?
  3. What if there is a dilemma in the product plan and prioritization?

Conclusion

No matter how careful we are and what we are working on, things will go wrong some of the time.

The better our tools and processes for recovering quickly from failures, and the more we practice using them, the higher our confidence and the lower our stress levels will be. This allows us to move forward much more quickly.

That’s all, folks!

 

Strive to learn : 8 Ways to optimize for learning at work as a software engineer

avi-richards-183715-e1499951479114

A large open space with amazing ergonomic chairs where people discuss and execute upon disrupting ideas. It’s right next to company’s game room where you unwind after a hard work day.  Here is we as engineers, get to work on products that our customers love and we love delivering that delight by continuous delivery (or something else :P).

Yet the most prominent thing that excites and should excite an effective engineer is the opportunity for learning at work. Optimizing for learning is a high leverage activity and should be on the top priority for every engineer.

Here are 8 ways to optimize our work for learning, deeply inspired by the book The Effective Engineer.

1. Study code for core abstractions written by the best engineers at your company

pydev_refactoring

I have been lucky enough to be the dumbest engineer at Squad. But that has allowed me to learn very aggressively during working hours just by reading through libraries and modules written by other awesome engineers.

So next morning, open that black box that you’ve been importing for so long in your code and dig through it.

2. Do more of what you want to improve

In more relatable terms, if you think you want to improve writing SQL queries, do more of that. If you want to improve at doing code reviews, do more of that.

Practice and deliberately touch your weak points instead of cutting corners. You’ll be amazed how helpful your fellow engineers/friends will be in helping you do so.

3. Go through as many technical materials available

We at Squad have a dedicated slack channel where engineers share good to read articles, blogs and podcasts.

I’ve made a pact to go through each and every article that is shared on that channel irrespective of the domain or the tech it. And so far this has been a catalyst for my learnings on things that I didn’t even know were there to learn.

4. Master the programming language that you use

Read a good book or two on them. Get to the internals of the language that you use primarily at work. We at Squad use python heavily for the back-end, machine learning, data analytics and everything.

Personally, I’ve added 2 great books to my reading list that I’ll be picking next:

  1. Fluent Python
  2. Mastering Python Design Patterns.

5. Send your code reviews to the hardest critics

1_INwRDJ_vspfJKkyFpv5jww

At Squad, code reviews are in the DNA of engineering processes. I’ve been very fortunate to be on-boarded to the Squad codebase by one of the best and hardest code critics at the company. It really helped me in developing high code quality standards and also the art of reviewing code.

Not only that taught me how to write better code but also how to deliver your code reviews in a respectful manner that the other person doesn’t feel discouraged, something that I always keep in mind while doing code-reviews myself.

6. Enroll in classes on areas where you want to improve

Courses on sites like edx, coursera, Udacity have amazing courses that we can take in our spare time. Let it be compilers, database, machine learning, infrastructure, these platforms have amazing courses on all of them.

Personally, I try to keep exactly one online course in-progress all the time.

7. Participate in design discussions of projects you are interested in

pu2ppth4dc2fsg0i

Don’t ask for an invitation. Ask the engineers if they’d mind you being a silent observer or even a participant in the design discussion.

8. Make sure you are on a team with at least a few senior engineers whom you can learn from

This will help increase your learning rate at least 80% of the time.

At Squad, I get to work with one of the most awesome engineers I’ve got an opportunity to work with. That has helped me in learning and polishing things like estimations, product thinking, designing, communication etc.

Conclusion

Our work fills a large part of our life. Making sure that our work is driving our learning and improvements helps big time in maintaining contempt and keep progressing on the path to become a better effective engineer.

Resources

  1. http://www.effectiveengineer.com/
  2. https://blog.fogcreek.com/the-effective-engineer-interview-with-edmond-lau/

That’s all, folks!

 

Practical Problem Solving Framework: Inspired By The Toyota Way

toyota-7-step-pratical-problem-solving-process

We all will agree to a certain point that having a system/process for anything reduces chances of errors.

As an engineer or someone people look forward to propose solutions to problems it’s beneficial to have a framework in place to solve problems effectively.

Recently I was reading The Toyota Way, and it suggested a framework to Practical Problem Solving. It almost felt trivial that this sort of framework would be invaluable to software engineers too (in fact for everyone).

When confronted with a problem, first we want to make it crystal clear and get a grasp of the real point of cause. That’s followed by a series of 5 WHYs? to investigate the root cause. And finally countermeasures, evaluations, and countermeasures.

1. Initial Problem Perception

Large, vague and complicated problem is presented. The first step is to perceive all the information available at this point information of time.

Ex. “Hey! Metric X is showing incorrect value”

This doesn’t show the actual problem, but just a perception of how some internal user saw it.

2. Clarify The Problem

Next step is to clarify the problem to scope it down. Go and see the problem yourself. Analyse it and get a clear understanding.

As you are seeing the problem first hand, we want to gather as much information as possible.

Ex. So the entire analytics data was actually not consistent.

3. Locate Point Of Cause

Next step is to dig a little deeper and try finding the point fo cause.

Where is the problem observed? Where is the likely cause? This will lead us to the vicinity of the root cause, which we find in step 4.

Ex. Analytics system is working correctly, just that it sometimes doesn’t get updated every 5 minutes like it’s supposed to.

Here we rule out other possible causes, like a bug in the code or wrong data was tracked in the first place.

4. Ask, 5 WHYs? Investigation of  the root cause

Here from the direct cause, we expose and go deep to the root cause of the problem by asking WHY five times.

Ex.

1. 1st why – Why was data inconsistent: Because analytics didn’t get updated on time.

2. 2nd Why – Why analytics were not updated on time – Because scheduled ETL jobs didn’t run on time.

3. 3rd Why – Why the schedule jobs didn’t run on time – Because CPU usage was 100%

4. 4th Why – Why CPU reached 100% – Because server instance size was not enough to handle increased number jobs.

5. 5th Why – Why server size was not enough to handle the spike in usage –  Because our auto-scaling is slow.

By asking a series of 5 whys, we can generally get to the root cause of the problem and fix it there instead of just duct-taping it and be waiting for it to rise again.

5. Countermeasures

This step is fixing the root cause of the problem so that this doesn’t come up again.

Ex. Moved to a more sophisticated auto-scaler to manage spikes in usages and setting up alerts to monitor the performance.

6. Evaluate

After the countermeasure have been executed, it’s important to evaluate the effect post that. Was the problem solved?

Ex. “Now analytics are always in sync and even if they miss getting updated, we get an alert to know it beforehand and take action.”

7. Standardize

This resonates with another Toyota principle of jidokameaning building in the quality.

How can we standardize the countermeasures such that similar problems are not faced again? How can we propagate our learnings across the organization?

Ex. “Document and standardize the process that for all our instances and jobs proper alerts must be in place so that we know when they are malfunctioning”

Conclusion

This was my take on how we can learn from a cross-discipline organization like Toyota on how to have a process and framework in place to solve problems effectively.

Afterall, problem-solving is supposed to be fun and having a proper framework in place, helps us keep it that way!

That’s all, folks!