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

Organization Archetypes And The Concept Of Market-Oriented “Solver Teams”

depositphotos_44074529-stock-illustration-flat-design-illustration-concept-of

Organizations which designs systems are constrained to produce designs which are copies of the communication structure of the organization.

In other words, how we organize our teams has a powerful effect on the software we produce, as well as our resulting architectural and production outcomes.

Thus, in order to get a fast flow of work from Development to Operations, with high quality, great customer outcomes and fast speed of delivery,  we must organize our teams to bring the team structure to our advantage.

Done poorly, this can prevent teams from working safely and independently, instead, they’ll be tightly coupled, all waiting on each other for work to be done.

At SQUAD, teams are structured as market-oriented teams, to quickly respond and solve customer needs. At SQUAD, we call them “Solver Teams”.

 

Organizational Archetypes

meaning-of-life

There are primarily three types of organization structures that inform how we design our DevOps value stream: functional, matrix and market.

Functional-oriented:

Organizations optimize for expertise, division and reducing cost. These organizations centralize expertise and have tall hierarchical structures.

Ex. Server admins, SREs, Data admins

Matrix-oriented:

Organizations attempt to combine functional and market orientation. This results in complicated organization structures like a single person reporting to multiple managers etc.

Market-oriented:

Organizations optimize for responding quickly to customer needs. These organizations tend to be flat, composed of multiple cross-functional disciplines (ex. marketing, engineering, machine learning).

Each market-oriented team is responsible for feature delivery, operational tracking and service support.

Market-Oriented “Solver Teams” at SQUAD

At SQUAD, we have a bunch of interesting problems to solve that highly impact and solve customer needs.

Broadly speaking, solver teams at SQUAD are market-oriented teams, composed of cross-disciplinary work like engineering, marketing, machine learning, data analysis etc to “solve” a customer problem.

These teams are responsible not only for feature development but also for user experiments, testing, optimizations, deployment and operational tracking of services, from idea conception to, successful launch, to retirement, all without dependencies on other solver teams.

Advantages of Market-Oriented Teams

  1. Small teams working independently and safely.
  2. Faster execution and delivery of work.
  3. Enables team members to be “E-Shaped” specialists.

 

Enable every team member to be a generalist

Screenshot from 2018-05-05 21-03-30

As we rely on ever increasing number of technologies. We want engineers who can contribute to multiple areas of value stream.

Another major advantage of the market-oriented teams is that, because of their innate nature of being cross-disciplinary and covering entire value stream from development to operations, it provides opportunities for the team members to develop and multi-specialist capabilities, also called as E-Shaped specialists.

When team members start becoming “E-Shaped” experts, business benefits of enabling faster flow are overwhelming.

As the same team member is able to contribute to multiple points in the value stream, the flow of the stream is much smoother and faster than a specialist working on a single point in the stream without having comprehensive knowledge of the entire value stream.

 

Conclusion

We saw how organization architecture dramatically improves our outcomes. Done well, organizational structure plays as an advantage and helps teams move and deliver faster.

At SQUAD, we structure teams as “solver teams”, which are responsible to own the entire value stream of the problem they are solving.

Solver teams are small and can move fast and safely without having dependencies on other solver teams.

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!

 

Estimation Peril: How To Estimate Software Projects Effectively(or How Not To Lie)

road-1668916_960_720

Consider, you are a rockstar engineer and you are given a task by your favorite person, your project manager, to show some new fields in the dashboard.

As usual, you are asked to estimate it as soon as possible. You think that well, seems like a quickie and you are tempted to estimate it a day. But you, being burnt before, decided to look at the fields that are to be added carefully. These fields are for analytics. You think, ok, let’s make it 2 days then. But being more cautious, you dig deeper and find that those analytics are not even being tracked on the app.

Now to complete the story, you’ll have to track the analytics, send them to the server, make the backend accept those and store them, show these on the dashboard, write tests etc….

What seemed a simple task is now a 1-2 week thing. Very hard to estimate. And your manager was expecting a response like, “would be done by end of day”.

What is the problem with estimates?

The main problem with an estimate is that the “estimate” gets translated into commitment. And when you miss a commitment, you breed distrust.

Most estimations are poor because we don’t know what they are for. They are uncertain. A problem that seemed simple to you on the whiteboard, turned out not to be so simple. There were non-functional requirements, codebase friction, some unfortunate bugs etc. We deal with uncertainty.

There is a rule in software engineering that everything takes 3X more time than you think it should, and this holds true even when you know this and take it into account!

Estimates can go the other way too, that is when you overestimate. This is as dangerous as underestimating.

What should an estimate look like?

An estimate should have 3 characteristics :

  1. Honest (Hardest)
  2. Accurate
  3. Precise

1. Honest : 

You have to be able to communicate bad news when the news is bad. And when the continuous outrage of your managers and stakeholders is on your face, you need to be able to continue and assert that the news is bad.

Honesty is important as you breed trust. You are not eliminating disappointment, rage and people getting mad, but you will eliminate distrust.

2. Accurate :

You are given a task and you estimate it to take somewhere between now to the end of the universe. That’s definitely accurate, it’ll be done within that time.

We won’t breed distrust, but we definitely will breed something else.

Which brings us to the 3rd characteristic.

3. Precise : 

An estimate should have just the right amount of precision.

What is the most honest estimation that you can make? I don’t know!

This is as honest as it can get. You really don’t know. But this estimation is neither accurate not precise.

But when we try to make precise estimates, we must note that we are assuming that everything goes right. We get the right breakfast, traffic doesn’t suck, your co-worker is having a good day, no meetings, no hidden requirements, no non-functional complexities etc.

Estimating by work break down

The most common way to estimate a complex task is to break it down into smaller tasks, into sub-tasks. And then those sub-tasks into sub-sub-tasks and so on until each task in hand is manageable and ideally not more than 4 hours of work.

Imagine this forming a tree, with executable tasks at the bottom as leaves. You just estimate the leaves and it all adds up.

This approach works, but there are 2 problems :

  1. We missed the integration cost
  2. We missed some tasks

There is a fundamental truth to work break down structure estimates:

The only way to estimate using work break down chart accurately, to know what are the exact sub-tasks, is to implement the feature!

What to expect from an estimate?

Estimates are uncertain. There is no guarantee that your estimate will work itself out. And that’s OK. It’s your manager’s job to manage that risk. We are not asking them to do something outside of their job.

The problem arises when you make a commitment. If you make a commitment, you must make it. Be ready to move heaven and earth to make it. But if you are not in a position to make a commitment, then don’t make one.

Because he’s going to set up a whole bunch of dominos based on that commitment, and if you fail to deliver, everything fails.

Some interesting links :

https://medium.com/swlh/your-app-is-an-onion-why-software-projects-spiral-out-of-control-bb9247d9bdbd

Uncle Bob on Estimates: https://www.youtube.com/watch?v=eisuQefYw_o

Happy Estimating!

That’s all, folks!

Mastery By Robert Greene : Reading Experience

Mastery_Cover

“The problem with all students, he said, is that they inevitably stop somewhere. They hear an idea and they hold on to it until it becomes dead; they want to flatter themselves that they know the truth. But true Zen never stops, never congeals into such truths. That is why everyone must constantly be pushed to the abyss, starting over and feeling their utter worthlessness as a student. Without suffering and doubts, the mind will come to rest on clichés and stay there, until the spirit dies as well. Not even enlightenment is enough. You must continually start over and challenge yourself.”

Mastery is a book that takes a deep dive into the so-called “superpowers” of masters in various fields and connects it directly to the pillars of mastery like grit, dedication, patience, creativity and intuition.

It contains life studies of legends like Vinci, Darwin, Faraday etc to contemporary legends like Carlo Rodriguez, Santiago Calatrava, Paul Graham etc. And time, again and again, it stands upon elusive pillars like grit, creativity, patience, etc which drives one towards mastery, not just god gifted super powers.

The book condemns that people are not willing to do what it really takes to become masters in their fields and label it as something that can be only achieved by born geniuses.

It starts with covering the importance of the apprenticeship phase. The phase that constitutes the beginning of everyone’s career, even of true masters like Faraday, who did the apprenticeship  at a scientist’s lab for 7 years before going on his own to make history.

During the apprenticeship,  one should focus immensely on learning the vocabulary of the field in depth with patience. Then experiment with his/her own tastes.

Next, comes the creative active phase, where after learning the tools of the trade and becoming proficient in important skills, masters experiment. They mix and match things, blend various fields and concepts and bubble up ideas.

The book presents various strategies for the creative active phase like:

  1. The Authentic voice: Learn the vocabulary of the field first.
  2.  The Fact of Great Yield: Look for anomalies with profound ramifications.
  3. Mechanical Intelligence: Key to building anything right is repetition.
  4. Natural Powers: Enjoy the laborious process.
  5. The Open Field : Create space for yourself in crowded space.
  6. The Evolutionary Hijack: Creativity and adaptability are inseparable.
  7. The Dimensional Thinking: Feel the breathing element in your field.

My favorite quote from this segment of the book was:

Languages evolve in haphazard manner, influenced by the influx of new groups into a society and stages by passage of time. They are not mathematical formulas but living, evolving organism.

Next, the author puts the spotlight on the vitality of “the ultimate reality“. Life is interconnected and it all started with a single cell two billion years ago.

Mastering a field can not be done in isolation with other things. Any field that we are working on, it has been shaped by events, minds that have worked on it and time. It is simply not right to build artificial walls around subjects and study them in isolation.

Strategies suggested in the book to get the rational intuitive feel:

  1.  Connect to Your Environment: Become a consummate observer.
  2. Play to Your Strengths: Have a supreme focus on your strengths.
  3. Transform Yourself Through Practice: Get the fingertip feel.
  4. Internalize the Details: Have the patience to give attention to even the most minute details
  5. Widen Your Vision: Get the global perspective.
  6. Submit to the Other: Loose the sense of superiority when learning from someone.
  7. Synthesize all forms of knowledge

My favorite quote from this part was:

Things push and pull into each other and breathe together, and are one.

To conclude, Mastery is a great book to help people shape their mind in a way that knows what to expect and what it takes to travel on the path of mastery. And that mastery is not a destination but a lifelong journey. One should maintain a beginners mind as they grow old like zen masters.

When you read a great book at the right time, it can only go in the category of Supremely Fucking Awesome.

Thanks!