Always an Engineer

In today's episode, Asim sits down with Shailesh Kumar, the Senior Vice President of Engineering at ClickUp. Shailesh has over 18 years of experience in software engineering, architecture, and leadership, with a passion for scaling organizations, products, and processes. The duo breaks down the future of software testing with generative AI, why engineers are moving away from automation testing, and the evolving role of testers with Generative AI's rapid advancement.

[00:00] Introduction

[02:42] Shailesh's Journey to ClickUp

[06:10] Generative AI's Role in Software Testing and Quality Assurance

[08:31] Understand That We're Still Very Early in the Generative AI Era

[09:30] Unit Testing Before and After Gen AI

[13:14] The Future of Software Testing with Gen AI

[15:46] Generative AI for LLMs and UI Testing

[18:00] How to Uncover Which UI Testing Tool is Right For You

[20:44] Where to Start with Software Testing Using Gen AI

[24:18] Advice For Engineers Looking to Get Started with Gen AI

[27:50] How Gen AI will Reshape the Engineering Workforce

[30:57] Why You Must Be Open to Adopting New Technologies

[33:17] Parting Thoughts  

The Future of Software Testing in the Era of Gen AI

Imagine a world where testing software isn't a tedious chore but a dynamic playground where creativity meets efficiency. Welcome Generative AI - the game-changer shaking things up in the software testing arena. Shailesh compares it to having a brilliant assistant who takes care of the boring stuff so that you can focus on the exciting challenges. With Gen AI, you can forget the tedious manual testing of yesteryears. Gen AI will anticipate issues, predict vulnerabilities, and optimize performance effortlessly. 

While it's exciting, it also raises questions about ethics, accountability, and the role of human testers. Will they become AI's co-pilots or guardians? According to Shailesh, sure, generative AI in software QA is still in its early days, but it has superstar potential. With less manual testing, you can expect software quality to soar, time-to-market to reduce, and your budget to breathe easy. 

Links and Resources:

In today's episode, Asim sits down with Umair Akeel, a startup founder, passionate engineer, former distinguished engineer at Twilio Inc, and former VP of Engineering at Oracle. They discuss how to 5X your productivity with generative AI, the future of software development, and advice to engineers on using generative AI.

[00:00] Introduction

[02:05] Umair’s New Startup

[03:09] The Future of Software Development

[06:09] How Generative AI is Changing Code Development

[08:31] Software Developers Using Generative AI

[10:27] Productivity and Building Software Faster

[12:00] How to Increase Your Speed and Efficacy of Writing Code

[14:40] Rapid Iteration and Testing

[17:10] Technology is Changing Too Fast

[20:03] Advice to Early Career Engineers on Generative AI

[24:44] Advice For Mid-Career and Late-Career Engineers

[28:42] Where to Start with Generative AI

[30:46] Parting Thoughts  

How to 5X Your Developer Productivity Using Generative AI

Are you a developer looking to supercharge your productivity? Then you’re in luck. Generative AI can be your new best friend. Tools like GPT-3 can help streamline your development process by writing code snippets, creating documentation, and even assisting in debugging. According to Umair, generative AI is like a friend that generates code templates based on your description. This can save you valuable time to become more productive.

However, like all productivity tools, generative AI can take some getting used to. Plus, these tools are sometimes only useful for getting outcomes for known problems. For example, they only know how to produce code that they have seen in the past. 

Links and Resources:

In today's episode, Asim sits down with Arnold Goldberg, the VP/GM of Payments at Google. Over the last 30 years, Arnold has worked with four notable high-growth companies – PayPal, Box, LinkedIn, and eBay, primarily focusing on scaling people, processes, and technology. They discuss the what, why, and how of inner sourcing. They cover the inner source approach to engineering, how to get the most out of it, the mistakes to watch out for, and much more.

[00:00] Introduction

[02:29] What is Inner Sourcing?

[04:55] Changing Company Culture to an Inner Sourcing Culture 

[08:14] Engineers Control Their Own Destiny

[12:10] Who is the True Owner of an Inner Source?

[14:23] Inner Sourcing in Giant Companies Like PayPal

[16:27] Engagement Models For Team Success

[19:08] Talent Retention and Executive Buy-In

[22:23] How Arnold Pilots and Scales Inner Sourcing in Teams 

[23:20] Mistakes to Watch Out For with Inner Sourcing

[25:41] Where to Find an Inner Sourcing Community

[26:19] Teams and Organizations Where Inner Sourcing Cannot Work

[28:05] Parting Thoughts  

What is Inner Sourcing?

Inner Sourcing is a software development strategy where companies adopt an open-source engineering culture that teams can use to collaborate more effectively. This growing trend is often found in high-performing teams. Engineers and developers create proprietary software and open the work internally so everyone can contribute to the source code. 

According to Arnold, the best engineers use inner sourcing to build better software, faster. But how big or small should the organization be for an innersource to be effective? He explains that the strategy is effective for organizations of all types and sizes. As businesses grow and differentiate their products, they quickly realize that traditional development methods no longer work. The slow hierarchical practice of gathering information, holding daily meetings, and developing in silos is not what drives success for technology companies today. Arnold believes inner sourcing is the only way companies can keep pace with customer demands and guarantee speed, reliability, and functionality.

Links and Resources:

In today's episode, Asim sits down with Joe Lynch, an experienced engineering leader and the VP of Engineering at Twilio. Joe boasts comprehensive experience in bringing scalable SaaS products and platforms to market and leading world-class Engineering organizations, with a focus on quality, efficiency, rapid delivery, and continuous improvement. They discuss the best way to frame an engineering problem, how to overcome the solutions-based way of thinking, and effective ways to highlight a problem statement. 

[00:00] Introduction

[01:45] Joe's Passion For Solving Problems

[04:47] The Foundational Elements of Problem Framing

[09:15] What is Prescriptive Problem-Solving?

[10:30] How to Stop Reacting to Problems

[14:11] Ways to Effectively Frame a Problem Statement

[19:03] Analysis Paralysis When Solving Problems

[22:13] Defining Problems is Subjective, Not Objective

[25:50] Human Bias When Solving Problems

[28:18] Parting Thoughts  

The Critical Value of a Well-Framed Problem

As engineers, we often talk about the solution space, but unfortunately, we don't spend as much time talking about the problem space and alternative ways of defining a problem. You see, the critical value of a well-defined problem cannot be understated. Because if you don't frame the problem properly, the solution will only be as good as the thinking that went into it. We are taught to tackle problems by looking at the idea of there being an implicit problem statement. And that the requirements document given to us by the product manager is somehow perfect. 

According to Joe, it's better to spend some time exploring the problem space. The problem space is essential because it defines the problem that needs solving. It also helps to identify the scope of the problem and the constraints that need to be considered while solving it. This saves time and makes it possible for engineers to solve customer pain points, desires, jobs to be done, and needs.

Links and Resources:

In today's episode, Asim sits down with Mark Interrante, a technology leader who builds engineering and product development teams for companies ranging in size from startups to Fortune 100. He also enjoys getting involved in new technologies when they're going from early adoption to mainstream. They break down the seven habits of highly effective teams - and the outcomes you can expect from implementing these habits.

[00:00] Introduction 

[03:01] Building Habits in Engineering Teams

[05:23] How to Deal with Distractions

[08:40] Shutdown Habits and Why They're Important

[10:58] Starting with the End in Mind

[14:21] Behavior Prompts 

[15:52] Why You Need to Make Doable Commitments

[21:00] The Power of Having Clarity in Your Work

[23:56] The Habit of Continuous Improvement

[27:03] Essentials of an Effective Task Decomposition

[29:43] How to Get into a Flow State Effortlessly

[33:10] Seek to Understand Before Being Understood

[35:10] How to Find Anchors That Slow Down Your Day

[38:29] Parting Thoughts 

Habits in Engineering Teams

Habits are the building blocks of success for any engineering team. To create highly effective engineering teams, you must develop a culture of good habits. These habits range from effective communication to having clarity in tasks. Mark believes highly effective engineering teams also prioritize continuous learning and improvement. They are open to feedback, embrace change, and seek opportunities to expand their knowledge and skills.

Mark explains that habits are essential because they allow us to automate actions and behaviors, freeing up mental energy for other tasks. By establishing good habits, we create consistent patterns of behavior that enable us to achieve our goals and improve our overall well-being. Habits also help us to develop discipline, which is crucial for success in any area of life. When engineers commit to good habits, they are more likely to make small, incremental improvements over time, leading to significant progress in the long run. 

Links and Resources:

In today's episode, Asim sits down with Harry Max, an executive player-coach, consultant, and hands-on product design leader with vision and a solid grasp on operations. His experience includes being a founder/CEO, operational leader, and consultant with start-ups, innovators, and global brands, including Apple, Adobe, DreamWorks, Google, and PayPal. They discuss ways to make prioritization a habit, why Harry's Morning Boot Routine is so effective, and the fruits of proper prioritization.

[00:00] Introduction 

[01:40] Who is Harry Max?

[03:00] Why Harry Chose to Write a Book on Prioritization

[04:28] How to Make Prioritization a Habit

[07:44] The Expected Outcome of Proper Prioritization

[09:29] Why Prioritization is Important in an Organization

[11:45] Steps You Can Take Today to Become Better at Prioritizing

[13:34] Examples of People Prioritizing Effectively

[15:53] The Morning Boot Routine 

[19:37] Prioritization Hygiene and the Cost of Delay

[21:21] Why Some People Fail at Prioritizing

[23:45] The Benefits of Having an Accountability Partner 

[25:26] Parting Thoughts 

How to Make Prioritization a Habit

We all know prioritization is important. The challenge is when people think of prioritizing, they immediately confuse it with personal productivity or time management. The easiest way to differentiate between the three is to remember that prioritization is not a one-and-done event. It's an ongoing process that demands regular updates and adjustments. As your tasks and deadlines change, so should your priorities.

Making prioritization a habit is a matter of discipline and mindset. Firstly, it's important to understand what matters most to you and what you want to achieve in the short and long term. This can be done by developing a daily routine that includes time for reviewing tasks and adjusting priorities as necessary. It's also important to avoid distractions and focus on the task at hand. Always prioritize your highest-priority work around your most productive and high-energy hours. You are more likely to complete high-priority items when you have the most energy and focus.

Links and Resources:

In today's episode, Asim sits down with Ashmeet Sidana, the Founder and Chief Engineer at Engineering Capital. His experience includes managing venture capital funds, serving on multiple Boards of Directors, and helping build industry-leading products such as VMware ESX Server and WebFORCE. Before becoming a venture capitalist, Ashmeet was an executive with hands-on operating experience as a CEO and Entrepreneur. They discuss the incredible power of technical insights in engineering and how business opportunities form the core of engineering excellence.

[00:00] Introduction

[01:35] Ashmeet's Journey to Engineering

[02:57] What are Technical Insights in Engineering?

[05:38] You Don't Need a Ph.D. to Come up with Technical Insights

[08:01] Things That Make vFunction a Unique Cloud Modernization Platform

[12:20] How the Most Interesting Companies Come About

[16:20] Why Engineers Should Interact with Customers From Day One

[18:02] Business Insights Versus Technical Insights

[21:10] People Operate in These Two Basic Modes

[24:27] How to Assemble and Build Your First Founding Team

[28:10] The Best Way to Build a Successful Engineering Company

[29:54] Parting Thoughts

What are Technical Insights and Why are They Important?

A technical insight is an idea that if you tell a good engineer what you are doing, they wouldn't know how to do it. In other words, there is something unique about how you solve problems. If it's a very large technical insight, people will surely be surprised. For example, when Google started, there existed hundreds of search engines worldwide. But what made Google unique was its algorithm's ability to rank web pages. Revolutionary companies are created when people think about existing problems that could be solved better with technology. This is only possible when engineers work backward from a problem before coming up with a solution.

However, it's not enough just to have technical insights. You have to spend enough time thinking about business problems that can be solved with technical insights. Only then can you start thinking about starting a company. And if you can find a big enough, interesting enough business problem, you can build a massive company.

Links and Resources:

In today's episode, Asim sits down with Troy Toman, the Vice President of Engineering at Planet. He is a technology and services executive with an extensive background in systems and infrastructure solutions. His most recent focus is on agile development, continuous delivery, web-scale infrastructure, cloud computing and OpenStack. They discuss why authentic leadership matters and ways engineering leaders can build a more authentic leadership style based on trust.

[00:38] Introduction

[02:10] How Myers-Briggs Personality Test Shaped Troy's Leadership

[04:42] Troy's Leadership Journey and Developing a Leadership Style

[07:03] What Society Views as Great Leadership

[10:14] Figuring Out Who You Really Are as a Leader

[13:45] The Basics of Authentic Leadership

[15:09] Spending Your Energy More Intentionally

[16:42] Becoming More Comfortable with Not Having All the Answers

[20:20] Why Vulnerability is the Key to Authentic Leadership

[21:45] How to Motivate Your Team to be More Authentic

[24:09] Improving the Entire Organization Starts with You

[27:40] Parting Thoughts

Authentic Leadership and Why It's Important

Success in leadership starts with authenticity. Great leaders do their jobs without compromising on values and beliefs. Why is this important? Well, because people trust leaders when they are true to themselves - and that trust is the easiest path to getting things done.

If you are a leader and would like to develop authentic leadership, you first need to develop a healthy alignment between your internal values and external behavior. This stems from finding your way of leading and making decisions that reflect your values, ethics, and personality. According to Troy, a great aspect of authentic leadership is asking for and giving feedback. Great leaders create a feedback-rich environment with a strong foundation of safety and trust. It's clear that work environments would be a much better place if we were all authentic and treated each other as humans.

Links and Resources:

In today’s episode, Asim sits down with Ron Lichty to discuss the rude awakening of engineering management. Ron is a software engineering leader and product development consultant with a passion for making software developers and leaders thrive. They break down ways managers and aspiring managers can make engineering leadership predictable and reliable.

[00:38] Introduction

[02:07] Ron’s Back and Forth Movement from Engineering to Management

[07:03] Misconceptions About Engineering Management

[10:28] How to Feel Accomplished as a Manager

[11:32] Why Conflict is a Necessary Part of Management

[13:00] Good Managers are Not the Smartest People in the Room

[17:45] Learning How to Delegate

[20:46] How to Overcome the Fear of Delegation

[22:03] Recruiting and Why It’s the Most Important Role of a Manager

[26:15] The Role of Mentors in Becoming a Better Manager

[29:50] Parting Thoughts

How to Succeed as a Software Engineering Manager

Like in most industries, engineering managers are often promoted because they are good at software development. However, being a great manager is not the same as being a great engineer. The latter requires a drastic change of focus and a completely different way of doing things. So, if you would like to become a leader in engineering, there is a set of expectations to consider before making that leap into the deep end. The best management practice you can learn is to put together a team of people who can work together toward a shared vision. This means not necessarily being the smartest person in the room and learning how to delegate.

Links and Resources:

For today’s episode, Asim is joined by Luca Galante to discuss the spectrum of DevOps and platform engineering. Luca is a product manager at Humanitec, and has been on the development line of work for almost 6 years. He joins Asim to break down platform engineering and its community, goals, career, and history.

[00:51] Introduction of Luca Galante

[01:50] Backstory of Platform Engineering Community

[04:01] Defining Platform Engineering

[06:00] Examples of Coder Pads

[10:12] Balancing on Opinionated and Unopinionated

[12:49] Standards for Platform Products

[15:09] Brown-field Enterprise Setup

[19:04] DevOps Side

[22:30] Platform Engineering as Just DevOps

[26:24] Where to Learn More About Platform Engineering

About Platform Engineering

Platform engineers are the soul to most product applications that customers use nowadays for day-to-day and leisure activities. Learning about how the community works and understanding the operational side of how the workers under this career can shed light into some misconceptions or facts about how they deliver their work, particularly their essential and organizational structure. You’ll be able to take on a personal journey of an engineer who experienced a lot of need-to-improve systems in this career within organizations, as well as defining some key areas of work around the job as a platform engineer.

External Resources:

For today’s episode, Asim takes on the situation of tech employees going through layoffs. In recent months, there have been many layoffs in the tech industry, and people are either flustered or placed at their lowest points going through this predicament. Asim takes on a guide that can help those who have been laid off and those who are trying to avoid the situation.

[00:38] Introduction to Tech Layoffs

[01:16] Tips for Laid Off and Recent Grads

[01:20] Due to Downsizing

[02:20] Understanding Your First Downturn

[03:27] What Can We do?

[03:34] Networking In the Field Of Interest

[05:29] Seeking Part Time Roles

[05:58] Structure and Discipline

[06:35] Starting Your Own Company

[07:12] Avoid Companies of People Who Complain

[07:38] Habit of Reading

[08:44] Summary

Nowhere to Go But Up

In the position of being laid off, employees would often over analyze why they were let go or what they will do after being released. It’s important to have a quick understanding of the situation. Taking a scan of what could have been done or what can be done. In the event that this does happen to an individual, the mindset of being resourceful on how else you can build your career will be an essential tool. In the field of tech, there are many opportunities out there. While it is still valid to let out how you feel in private, what’s important is that you know how to get back up on your feet and you make a plan on how to do it.

Reading Materials

For today’s episode, Asim is joined by Adam Zimman, a recovering entrepreneur and an engineer who’s spent years developing software in the enterprise domains focused on infrastructure and engineering. He joins today’s show to talk about progressive software delivery to consumers and the key structure to help it roll-out efficiently.

[00:34] Introduction of Adam Zimman

[01:34] What Motivates Adam

[03:13] How Adam Applies to the Business World

[07:36] Feature Flagging Interplay

[09:15] Other Aspects of Feature Flagging

[14:48] Tooling Behind Continuous Delivery

[19:08] Key Aspect to the Roll-Out

[20:14] Companies That Adapt This Implementation

[23:18] Advice on Where to Pilot Software Delivery

[26:26] Where to Follow Adam’s Work

Progressive Software Delivery

Adam talks about the importance of progressive software delivery based on how companies can create products and tools that can be easily used by consumers from various generations. The tech industry is rapidly growing, paving way for more innovative ideas to run systems online or through various tech products. Companies now face the pressure to create softwares that can be easily accessible or user-friendly to all types of consumers. Adam talks about how companies can efficiently deploy a software product and ensure that consumers can still work around it. He backs this process by adding key driving factors that make a software roll out successful, as well as how the enterprise can adopt these practices in order to keep their customers loyal to their products.

How to Connect with Adam

For today’s episode, Asim is joined by Andrea Goulet, who has spent more than 20 years in the tech industry. She joins Asim as she tells her journey in the tech industry and how the idea of empathy has helped her develop some soft skills that may be productive for software engineers in the field.

[00:39] Introduction of Andrea

[2:00] About Empathy

[04:56] Andrea’s Journey in Software

[07:47] Frameworks on Empathy

[10:27] Applications of Framework to Engineers

[14:45] Taking Actions with Empathy

[20:10] Tangible Benefits of Empathy

[26:21] Task and Relationship Conflicts

[28:59] How to Reach Andrea

Defining Empathy

Empathy is the moment an individual experiences when they have the power to make decisions and then act upon it. It is that moment when one’s thought process can read the feelings or foresee the consequences of the actions they are about to do. In the world of software and tech, empathy is not the main highlight to the work system, however, this underlying skill can be the butterfly effect that can change the course of productivity and outputs of software engineers.

Essential Soft Skills

Empathy is a soft skill that can be harnessed as a metaphor to create a better working environment not just for yourself, but for your co-workers as well. Rooting back to the decision-making moments, there comes a time where you have to consider factors such as rational or logical thinking, setting up boundaries, and proper communications, these are the trigger points where empathy plays a big role in creating a good working environment. The soft skill has worked on many software developers in terms of better work productivity as well as healthier and professional working relationships with colleagues.

How to Connect with Andrea and Other References:

For today’s episode, Asim Razzaq is joined by Tim Chou, an entrepreneur and engineer-at-heart who’s had great career success at Oracle and speaking engagement in universities. Tim shares insights on the art of influence, a way to sell yourself and your ideas to clients. He crafts a unique process to let engineers become their very own entrepreneur.

[00:46] Introduction of Tim Chou

[02:45] The Art of Selling Ideas

[06:10] About Insight

[07:50] Selling the “Not”

[10:58] Strategizing Sales as Individuals

[13:29] Disadvantages of Staying

[15:34] Importance of Storytelling

[18:18] Other Analysis of Approach

[20:19] Building Your “Tribe” and Language

[27:39] Summary and Resources

Creating Your Story

If you are trying to sell yourself, crafting a story is one of the important elements to convince customers that your services and products resonate to their wants and needs. Simple descriptions are the basic foundations to any product or services, but the story behind them is what captures buyers to hook on to them. Storytelling can stem from factors such as background or personal history, insights from customers, breaking the status quo, and many other factors.

Crafting the Language

Influencing your customers is also gauging their language and niche. They say that it takes one to know one, and for influencing, sellers need to really grasp the idea that customers need to understand your language. Conversing with customers can impact the dynamic of influencing others. The butterfly effect of creating a community of dedicated customers or the sphere of influence of knowing who your crowd are and if they understand you can be beneficial for long term transactions.

Recommended Resources:

In this episode, Asim responds to listener questions about how they can build a successful and fulfilling career as a software engineer. There is a lot of information out there regarding tips and tricks, but ultimately it boils down to developing rare and valuable skills that set you apart from others. You have to be deliberate and disciplined about it. The reward is worth the effort. 

You must invest time and energy into honing your craft before the real passion and enjoyment comes. It can be a struggle before that. How do you hone in your craft? You must practice every single day.

• Find opportunities to work with software engineers who have distinguished themselves in their craft. 
• Earlier on in your career, focus more on the kind of work you will do that helps you stand out and develop rare skills stand out as opposed to the big salary/title/company hype.
• Work on side projects, ideally open source projects. Build something outside work that you are passionate about.
• Go deep in a particular domain e.g. fintech, healthtech, infra, etc.
• Specialize in skills that are in short supply, ML/AI/Data Engineering.
• Get great at refactoring and turnaround. Not easy, but most great opportunities out there need it.
• Attend meetups and participate in hackathons to keep yourself sharp.
• Be a collaborator and a problem solver and not the complainer and fault finder.
• Own every aspect of your code - performance, reliability, quality, cost and more.
• Surround yourself with people you respect and learn from.
• Have a growth mindset.

Additional resources: 

Join Asim Razzaq as he introduces the concept of antifragile software systems. This concept aims to demonstrate what happens during catastrophic scenarios inside the system. For today’s episode, he will highlight key principles that can lead to antifragile teams, processes, and code.

[01:11] What is Antifragile

[02:14] Modern Resilient Software

[03:17] Antifragile System

[03:51] Building the Software System

[04:11] Techniques for Antifragile System

[05:34] What Leads to Antifragility

[06:39] Summary

Thriving Not Surviving

Most software nowadays is rapidly adapting to more efficient use due to advanced machine learning capabilities. Developers, and even consumers, are keen to find ways to make their software products thrive rather than just surviving, which leads to the concept of the antifragile system. While it’s great that software can survive even the most dire of situations, consumers are also inclined to a system that can self-learn from these issues then provide its own solution to adapt moving forward.

Additional Resources

On today’s show, Asim Razzaq focuses on the importance of customer-centric software engineering. Software engineers should always be creating meaningful value for customers, and other stakeholders as well, not just writing code.

[01:03] Wasted Software Features

[01:25] Envisioning Success for Customers

[02:23] Misplaced Customer-Centric Service

[07:20] Ways to Be Part of the Conversation

[12:42] Summary

Always Put the Needs of Customers First

A fundamental for software engineers is that you always need to put the customer first. Many times, engineers fall into the trap of following only the directives coming from the product or internal teams. In a crowded marketplace, a lot of solutions are built in order to keep up with what competitors are doing. But what problem does the customer need to solve? What is the use case? Software usage, customer satisfaction, and even product reviews can be hit-or-miss if you don't deliver real value for users.

Communication is Key

Just like any other healthy working environment, having open dialogues can lead to great success and development stories. For software engineers, it is advised to always have an open mind and discussion with the internal teams on what they can contribute from a professional’s point-of-view. The thought process of knowing what the customer wants can trigger engineers to give plenty of recommendations on how their services can be more efficient. This would also allow them to build a meaningful and more established working environment with different stakeholders while keeping the customer satisfied on a steady to upward scale.

In this episode of Always an Engineer, Asim Razzaq breaks down four different types of engineering roles: platform engineering, site reliability engineering, development operations (DevOps), and application engineering. It’s important to know the difference to avoid confusion in tasks and improve overall productivity.

[01:11] Platform Engineering

[02:45] Site Reliability Engineering

[06:34] Development Operations

[09:11] Application Engineering

[10:10] Summary

Knowing Your Function and Expertise

As engineers, it’s important to know your strengths and forte in the field. Due to the nature of engineering having a wide net of work, you need to establish which particular field you are inclined to work for. Identify if you lean towards being a foundation of tools, goal-oriented for problem-solving types of work, hands on development procedures, or specialized field tasks. The main objective here is to set a boundary of tasks that you can work on in order to increase the productivity and better the quality of services or products for customers.

In this episode, Asim Razzaq talks about the pitfalls of joining the wrong startup when you are early in your software engineering career. While young engineers relish the opportunity to become part of the legacy of a new company and wear multiple hats, early-stage startups often don't have the best engineering culture or approach for grooming new software engineers or establishing the foundational skills for future success.

[ 1:40 ] Software Craftsmanship vs Speed of Delivery

[ 2:40 ] Limited Time for Mentorship

[ 3:42 ] How to Evaluate an Early-Stage Startup Early in Your Career

[ 5:55 ] Personal Stories and Lessons Learned

[ 7:30 ] Summary: Resist the Temptation

In this episode Asim Razzaq sheds light on the ongoing debate of whether companies should undertake a software rewrite or instead refactor. This age-old decision can often make or break an organization, especially when a specific software system reaches a certain point of evolution.

[01:23] Trade Offs on Rewrites and Refactoring

[02:55] Situation Analysis

[04:39] Fit Application for the Demand

[06:17] Refactor or Rewrite?

[09:20] Asim’s Recommendation

The Evolution of Systems and Market Demand

As companies develop new systems that would meet the market or client’s demands, the need to meet these expectations adds pressure for the organization to modify their products. Software engineers begin to evaluate whether or not the system should be revisited and modified or completely rebuilt. Hence the rewrite vs refactor debate emerges. Effectivity of these methods would vary per company, but there are many factors to also consider when choosing which method to go for.

Realistic Solutions

As both rewrite and refactor pose great ideas on how to adapt to the rapid market demand, companies have to make a realistic decision on which method they need to use. If the company already has an existing business format, and the time comes that they need to evolve this mainframe, then it would be wise to work on agility in order not to prolong or confuse the consumers. Consider that companies also have a fair share of employment flow, moving from one position to the next or if the system no longer applies to the knowledge scale of the person in charge.

In this episode, Asim Razzaq clears out the career path dilemma for software engineers, whether they should pursue a path as an individual contributor (IC), or in a managerial role. He will detail the difference as well as give guidance on how you should base your decisions and consider the payoffs.

[01:04] Wrong Ways of Choosing a Path

[02:22] Difference Between Contributor and Manager

[03:12] Advice on Decision-Making

[03:52] Management Role

[06:52] Individual Contributor Role

[08:32] Summary

Career Path Misconceptions

Software engineers often think that the only way to a successful career is up. But management isn't for everyone, and it's not the only way to advance your career. When choosing a career path, it is advised that you understand first the role that you are getting yourself into. Managers are dealing with  people operations the majority of the time, while the contributor role is often focused on the technical applications. It’s also important to note that being a contributor doesn’t always mean that you are choosing a less ambitious career path.

The Right Way to Choose

Being that IC and Manager roles are two entirely different things, it is advised that you should not go in too fast. It is important to really take a deep dive into the things that you can do and how the work is going to transpire once you start on a specific path. Sometimes it is okay to also give each path a try to truly immerse yourself. It is also good to openly discuss with management if you need training in particular job tasks or work-related matters.

In this episode, Asim Razzaq highlights the difference between a maker’s schedule and the manager’s schedule. In a company, it is important to consider the type of work your colleagues do, and Asim aims to shed some light on an underlying conflict between the two schedules and how one side needs to be more understanding of the other’s work.

[00:59] Difference Between Maker and Manager Schedule

[01:17] Makers’ Schedule

[02:22] Managers’ Schedule

[03:18] Clashing of Schedules

[03:55] Poorly Planned 1 on 1s

[05:00] Asim’s Experience of Managers vs Makers

[06:33] Pivoting from the Conflict

[11:24] Summary

Work-In-Progress

In the conversation of Maker vs Manager, it is important to understand the type of work each side does for the company. Makers often spend their work days highly focused on delivering technical and hands-on solutions to their products, while managers are there to oversee and give directives on the plans for the company. Managers need to be wary about the time and work makers put on their daily tasks. It does not take long before some managers notice that their need to have makers present in their managerial discussion is costing makers the time they need to be hands-on their tasks.

Workarounds

Companies need to establish a system that can work for their workers. An effective system can produce efficiency for day-to-day work and employee morale. Taking the time to acknowledge the productivity needs of both parties will essentially be the first step before crafting a work solution. In doing so, you get to know what helps for your colleagues, and what to avoid when giving directives. It also helps to have good communications between makers and workers, that way, a win-win situation can be established.

For today’s episode, Asim Razzaq takes on the topic of software estimation and how engineers can improve the quality of estimates through calibration and confidence intervals. Most engineers in companies are overestimating, and in some cases, underestimating, their software estimates. With the help of Doug Hubbard’s research, Asim can share how company engineers can train themselves for a more accurate estimation rate.

[01:19] Software Estimation

[02:02] Ways to Train Estimation

[02:45] Challenges Often Faced on Estimation

[05:37] Asim’s Experience

[09:39] Training From Doug Hubbard’s Book

[10:45] Solutions Based on Training

Missing the Mark

There are many ways to miss the points when it comes to software estimation. This varies depending on the person’s confidence level and mindset towards the estimation and creates their own bias. Some cases occur based on underestimation, overestimation, and similarities-based results. Thankfully, each error has a training method that applies to help better hit the right mark.

Practice Makes Perfect

Luckily for software engineers, estimation can be trained and be improved overtime. With the right tools, you can conquer the constant overestimation and underestimation results. Asim based his techniques on Doug Hubbard’s teaching materials. Here, he managed to showcase an estimation that was a lot more accurate than initial estimation on the population of Italy.

In this episode, Asim Razzaq tackles the motivational aspect of software engineering. A lot of companies miss the mark when it comes to motivating engineers, and Asim will elaborate why they leave and how they can be motivated to stay on longer.

[01:48] Defining Intrinsic and Extrinsic Motivation

[03:05] Problems with Extrinsic Motivation in Companies

[03:55] Three Pillar Solution for Companies

[04:32] Mastery

[05:11] Purpose

[06:31] Autonomy

[07:40] Conclusion

What Motivates You?

According to Daniel Pink, software engineers are often motivated by intrinsic aspects. This puts them in a state of mind in which they are driven by their work on personal and individualistic methods. With this, most companies are not aware that this type of motivation applies well to many experts in the field. Unfortunately, they seldom miss the mark, as most employees are accustomed to have a more extrinsic base of motivation, which is when a worker is highly swayed by material or external factors.

For the Long Haul

In order for companies to hold on to their engineers, they must be able to identify and evaluate what type of training and motivational methods they can use to keep them at high-performing levels. When it comes to engineers, the best solution allows them to flourish in their craft, help them define a purpose in what they do, and create an idea that explains why, how, and what their products can do.

In this episode, Asim Razzaq defines what is toxic heroism in the field of software engineering. Many engineers do not see this trait, and for Asim, it is important that he shows how this trait manifests and how it could affect the performance and output of a company on a long-term basis.

[01:37] Problem of Hero Hailing Engineers

[02:50] Why it gets Toxic

[03:17] Asim’s Experience

[07:18] Solution

Going Against Morale

While it is important to credit engineers for all the daily tasks and solutions they provide for companies, it is still important to check in on them and see if these little success stories aren’t going to their head. When someone is afflicted by a “toxic hero” state of mind, they’d often take shortcuts or rely on small and temporary wins, these achievements are materialized externally to a point that how they think is always right. This, in return, creates a bad environment for colleagues who may be discouraged to work as a team or craft new ideas to solutions, which may not be aligned with the aforementioned “hero's” point of view.

Taking a Step Back

When you feel like these wins are getting to your head or if you notice that your colleagues are no longer contributing ideas to your group huddles, then it is definitely time to take a self-evaluation on whether or not you are creating a toxic hero environment for your workplace. The sooner you identify these signs, the better it is to help reconnect with your team.