Always an Engineer

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.

Got questions or suggestions for future episodes? Just visit www.alwaysanengineer.org

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

Got questions or suggestions for future episodes? Just visit www.alwaysanengineer.org

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.

Got questions or suggestions for future episodes? Just visit www.alwaysanengineer.org

Additional Resource Materials:

Martin Fowler’s Blog

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.

Got questions or suggestions for future episodes? Just visit www.alwaysanengineer.org

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.

Got questions or suggestions for future episodes? Just visit www.alwaysanengineer.org

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.

Got questions or suggestions for future episodes? Just visit www.alwaysanengineer.org

Additional Resource Materials:

Doug Hubbard’s Website

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.

Got questions or suggestions for future episodes? Just visit www.alwaysanengineer.org

Additional Resources:

Drive by Daniel Pink

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.

Got questions or suggestions for future episodes? Just visit www.alwaysanengineer.org

If you could go back in time and give your less experienced self some advice, what would it be? 

Today, Asim Razzaq is a founder and CEO,  but he started out as a software engineer. The career path he chose wasn't easy, even with mentors to help guide him. He's learned the hard way and acquired a lot of unconventional wisdom — wisdom he wishes he had not just when he was an individual contributor but as he moved up the ladder to lead engineering teams, and eventually lead a company. Because it’s true what they say… Once an engineer, always an engineer. 

In this podcast, Asim shares software engineering perspectives and lessons learned on a variety of topics: from technical decisions engineers have to make every single day, to the ways leaders can get the most out of their teams, to the pros and cons of career choices throughout the journey. Understanding that engineering perspective… and exploring both success and failure from that perspective… can be valuable in helping people make better decisions, work better together, and ultimately be better versions of themselves.