Skip to content
View syedhassaanahmed's full-sized avatar

Organizations

@microsoft

Block or report syedhassaanahmed

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Please don't include any personal information such as legal names or email addresses. Maximum 100 characters, markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
syedhassaanahmed/README.md

Hi there 👋

I'm a curious Engineering Manager with 18+ years of experience in developing software and leading engineering teams. Having lived in 5 countries, I've developed a strong ability to collaborate effectively with cross-functional and geo-distributed teams. Having worked across industries such as Retail, Telco, Manufacturing and Energy, enables me to drive engineering excellence, business value, and customer success.

Well-rounded Software Engineers from my observation (in no particular order)

  • teach themselves multiple ways of solving the same problem and understand that code is just one of the many ways to achieve the solution. As a consequence, they treat code as a liability, not an asset.
  • consider the term best practices as relative. Since best practices constantly evolve over time, great engineers brace themselves to unlearn and re-learn. They never settle in learning in-depth how something works.
  • put people over processes.
  • judge people on their contributions, not on how confident they seem.
  • don't let their own desire to get things done quickly, turn into undue pressure on peers.
  • are happy with others' success and acknowledge that success is not a zero-sum game.
  • recognize that out of all the agile practices commonly used, estimating work items and trying to measure project velocity is the least productive.
  • acknowledge that new systems are best designed by a small number of minds, not committees.
  • instead of only doing their parts, help out in dependent workstreams too if needed.
  • are aware that their team is only as good as the weakest code reviewer.
  • are cautious when dealing with hyped/fashionable tech (e.g. Kubernetes) and understand that CS fundamentals don’t change much over time.
  • understand that knowledge of specific frameworks, libraries or tools is not that important in the long run.
  • keep the documentation as close to the actual source code as possible.
  • ensure that all code must have good tests regardless if the tests were written first, last, or in the middle.
  • have the same high standards for all the code they write, from tests, little scripts to the inner loop of critical system.
  • deploy from main branch to prod from the very beginning of a project.
  • automate all the things that are worth automating.
  • know the importance of being able to tell what the system is doing, so they make sure it’s observable.
  • As managers/leads, if things go well, they give their team the credit. If things go sideways, they take the blame themselves.

Pinned Loading

  1. databricks-notebooks databricks-notebooks Public

    Collection of Databricks and Jupyter Notebooks

    Jupyter Notebook 22 15

  2. neo-to-cosmos neo-to-cosmos Public

    Copy Neo4j data to Azure Cosmos DB

    C# 11 3

  3. azure-kusto-load-test azure-kusto-load-test Public

    Containerized tool for load testing Azure Data Explorer (ADX)

    Python 5 2

  4. northwind-sql-db-container northwind-sql-db-container Public

    Docker container which initializes SQL Server with the Northwind database

    Shell 2

  5. iot-simulator-influxdb iot-simulator-influxdb Public

    Simulate synthetic IoT telemetry and ingest into InfluxDB

    Shell

  6. spark-with-engineering-fundamentals spark-with-engineering-fundamentals Public

    E2E Spark data pipelines with engineering fundamentals

    HCL 2 2