About Me - Omar Codes A Lot

About Me

DevOps Engineer at team Valori, with a background as a .NET developer. I'm originally from Afghanistan and grew up in the Netherlands. I have a wife and two children. And yes, I like pineapple on my pizza.

My Beliefs

  • Everything can be changed. If something isn't changing, it's because someone gave up too early.
  • Everything can be learned. Learning how to learn is the key to success.
  • The most impactful people want to understand the "why". That hunger to understand the reasons behind things separates chefs from cooks. Cooks execute; chefs create. You can't successfully create without understanding how things work, why, and what ultimate needs you're trying to satisfy.
  • Resilience requires diversity. Diverse solutions come from diverse input. A diverse set of solutions can mitigate blind spots. The quality of your ideas and decisions reflects the quality of the information and debate that went into them. Diversity comes in many forms: diversity of experience, beliefs, and backgrounds.
  • In the long run, you can't tell people what to do. They'll do what they want. Power by authority is naturally short-lived. You can get away with telling people what to do for a short time, but eventually they'll leave or revolt. For lasting change, you need to (1) persuade others and then (2) design a system that reinforces the change you want.

My Work Style

  • Real-time collaboration – I believe in teamwork and prefer to collaborate in real-time rather than through handoffs. Decisions are made much faster by working together on a prototype than by passing a spec back and forth. Mob/pair programming for topics where we learn together, not for trivial tasks.
  • Quickly available – Feel free to interrupt me. Unblocking team members almost always has more value than my own focus work.
  • Agile and Engineer – Working iteratively doesn't mean we skip design and research. We do both.

Calendar & Availability

My calendar is always up-to-date. If I'm free, I can meet. If not, I can't. I strictly adhere to my work and personal hours – that's also in my calendar. I live close to the office so I'm easy to meet there.

Communication

  • Inbox zero – I aim for an empty inbox. If you email or send me a Teams message, I will always respond.
  • Start with the why – I can do better work if you tell me why something is needed, in addition to what is needed.
  • In person or video call – For complex or sensitive topics
  • Teams message – For quick questions
  • Email – For async discussions with multiple people, especially conversations that will be held over a longer period

Meetings

I have little patience for poorly-run meetings that lack an objective or agenda, are too long, have too many people, or could have been a video recording or an email instead.

Feedback

I prefer to give and receive feedback directly and close to the moment. Compliments in public, constructive feedback preferably in private. I like to use the NVC framework: observation, feeling, need, request.

"You cancelled our last three meetings last-minute (observation), that frustrates me (feeling) because I need predictability (need) – can you let me know earlier if you can't make it? (request)"

What Gives Me Energy

I get energy from a team that collaborates, helps each other, and has a "we can learn it" mentality. The word "yet" is important: "We don't do X yet, but we're going to learn it."

What Drains My Energy

What drains my energy is working in an environment where everyone works for themselves, problems are seen but ignored, and no one has the will to improve.

Trust

Win
Be friendly, helpful, and do what you say
Lose
Break promises, be unreliable, or say yes when you mean no

In Case of Disagreement

I share my objections with reasons, but I don't push. I give the team room to experiment and will do my best to prove myself wrong and the team right.

What You Can Expect From Me

I'm experienced in .NET, AWS, Domain-Driven Design, and Test-Driven Development. Feel free to reach out to collaborate on design, programming, or testing strategies. I'm currently diving into Kubernetes and Azure – tips and help are welcome. I don't just want to be technically strong in our stack, but also become a domain expert. So feel free to take me along on the business side of what we do.