If you prefer to watch then it’s also available as my first youtube video !

I studied chemical engineering for four years. I even did a full year working in industry at a petrochemical plant. And then I walked away from it all.

I want to talk about something a lot of people go through but rarely discuss openly: why so many engineering students never actually become engineers.

Why I Chose Chemical Engineering

Three words: prestige, finance, and opportunity. I’d say these are the 3 reasons that drive people to study engineering.

I was good at maths and chemistry. I’d spent a few days at Manchester university during a summer school exploring different subjects, and engineering clicked with me the most. That’s more exposure than most people get before committing to a degree. I thought I’d found my path.

But I was still confused. Confused enough to take a gap year. I remember sitting at my computer, scrolling through the University of Manchester’s website, scanning every course from accounting to zoology, only to find myself drawn back to engineering.

Part of me wonders if that attraction was influenced by the “Big 3 pathways” that immigrant parents typically pre-approve: engineering, law, or medicine. Anything else almost requires an explanation for why you've deviated from that expected path.

One big motivation was my long-term goal of moving to the Middle East. Chemical engineering felt like the degree that could open that door. And when I found out chemical engineers had some of the highest starting salaries for graduates? That sealed the deal.

Reality of Studying Chemical Engineering

Chemical engineering is one of the hardest degrees, primarily due to the breadth and depth of the modules studied and the short turnaround time for assignments and projects.

Your typical week will be full of coursework, labs, reports and problem sets.

You will be pretty sure after the first semester if chemical engineering is for you. Once people grasp what chemical engineering truly involves, some quickly realise it’s not the career path they want. Of course, the actual job differs from studying.

I thought the course layout + structure did not leave room for too much outside of studying like other courses did.

It felt like the intensity the course was high for not much benefit gained. Unlike other courses where you might have time to explore other interests, build side projects, or even properly prepare for job applications, chemical engineering felt like running on a treadmill that kept speeding up.

And job applications? They're their own beast. Borderline deserving their own module. Nothing at university prepares you for the interview processes these companies have. And the best (read: worst) part? They're all completely different from each other.

Why I Decided to Leave

So why do people actually leave? Three reasons:

1. Job Availability

This is the first and foremost reason. There simply aren’t as many engineering jobs out there as advertised when you start your course. You get sold this dream that engineers are in short supply and that you’ll essentially get snapped up after graduation.

That simply isn’t true.

Not only do you face competition from the ever-growing engineering cohorts across the country in your discipline each year — you’re also competing against other engineering disciplines for the same roles.

2. Salary

Funnily enough, this is the same reason many of us applied in the first place.

The reality is engineers aren’t paid that well compared to what that same person could earn by taking their smarts and effort into other fields — like consulting or tech. When someone puts in the effort to secure top grades and then sees they could get paid significantly more in another field, you can understand why they make the switch.

3. Geographic Inflexibility

This is the biggest thing I would tell any prospective chemical engineer about. It’s a massive downside that no one talks about during undergrad.

Most process facilities aren’t in cities. A good percentage of people end up having to commute a fair distance to reach their workplace. If you’re someone who wants to live in a big city, your options are limited. I’m not saying it’s impossible but it’s something to seriously consider.

If you clicked on this article, you’re likely in one of three categories:

1. A student thinking about studying engineering

2. You’re already studying it

3. You’ve graduated and you’re questioning everything

Wherever you are in that journey — know that you’re not alone. Making a pivot doesn’t mean you failed. Sometimes it means you’re finally being honest with yourself about what you actually want.

Have you ever had to make a tough decision like this? Let me know in the comments.

Plugs

A collection of interesting links I’ve found from trawling the internet

Surah Yusuf - Qari Fatih Seferagic

My Personal Website

Clawdbot Setup - Setting up Clawdbot the proper way

Claude Import Memory - Switch from ChatGPT to Claude easily

Engineers debating architecture before users.
Creators polishing branding before distribution.
Founders perfecting pricing before demand.
Builders refactoring code nobody uses.

It’s a pattern I keep seeing.

People optimise before reality has pushed back.

Before users complain.
Before something breaks.
Before there’s friction, load, or demand.

Optimisation becomes the work — not because it’s needed, but because it’s safe.

Trust me, I fall for it too sometimes.

Why this happens

Early optimisation is especially tempting if you’re competent.

A few reasons why:

• Optimisation feels like progress
  It’s concrete. Bounded. You can “finish” it.

• Feedback is uncomfortable
  Shipping invites judgment. Optimising delays it.

• Polish protects identity
  If it’s not done yet, it can’t fail yet.

• You get to stay in control
  Reality is messy. Optimisation happens on your terms.

It all looks productive. It feels responsible.
And most of the time, it’s a mistake.

Optimisation is often fear disguised as productivity.

A lesson I learned early on

Early in my career at a B2B startup, we were serving real customers with real expectations.

The product was live.
Money was coming in.
The system had to stay up.

We ran it on small servers.

No Kubernetes.
No clustering.

It worked.

It handled the load we had, shipped features quickly, and kept the business moving.

Around me, there was plenty of discussion about the “right” language and the architecture we’d need when this scales.

But that wasn’t today’s problem.

Today’s problem was revenue.

We hadn’t earned the right to optimise yet.

“Revenue is the strongest form of validation — and it rarely cares how modern your stack is.”

Competent engineers optimise for business survival first, technical elegance second.

Don’t take my word for it — history is full of companies that scaled despite their early tech choices, not because of them.

When optimisation does make sense

There isn’t anything wrong with optimisation.

I just have a problem with premature optimisation.

Optimisation makes sense when:

• Something is being used

• Something is breaking

• Something is slow because of real demand

• A constraint is proven, not imagined

In other words:

“Optimisation is a reward you earn after something survives contact with reality.”

A simple test

Before you optimise anything, ask:

• Has anyone actually used this yet?

• Has anything broken yet?

• Am I fixing a real constraint or an imagined one?

• Would shipping faster teach me more than refining longer?

If nothing hurts yet, optimisation is probably avoidance.

The Pattern to remember

Good engineers don’t start with the stack.
They start with the problem.

Whether you’re a founder or an engineer:

Build.
Ship.
Measure what hurts.

Optimise only what reality forces you to.

PS: If you haven’t checked out hudeyfajama.com - what are you even doing here?

Plugs

A collection of interesting links I’ve found from trawling the internet

Surah Hud - Qari Sheikh Abdul Muhsin Al Qasim

Cool Products - Cool website with cool products

OpenClaw/ClawdBot - you’ve probably already seen this

The Engineering Trap - why some guy left ChemEng

So what are you actually paying for when you join a paid online community?

Let’s explore the case for and against.

Case For

Curation and structure

In my opinion primary elements you are paying for with a community is two fold:

• Collation - An opinionated view on what information is necessary to succeed in a role. No decision fatigue about what to learn next.

• Ordering - Everything in one place, presented sequentially, each lesson building on the last.

This element becomes more valuable the newer you are to a field or industry.

Accountability and connection

Transitioning into a tech role can be isolating. It sometimes feels like your in a dark tunnel with no end in sight. Rejection after rejection.

Having people at your level, going through the same struggles, can give you the motivation to keep going. Especially when you start seeing people who were once in your position land roles.

For those who lack the discipline to grind alone, being financially and socially committed to something can make the difference between breaking in and quitting.

Tailored support

Good communities offer:

• Interview prep

• CV reviews

• Mock tech tests

• Direct mentorship

All in one place. This kind of personalised feedback is hard to find for free. Alongside that you get a selection of mentors within that community so it can be more cost effective than seeking direct mentorship

Network effects

Your network is your net-worth

We’ve all heard it but actually building that network is not easy, especially when you’re early in your career or transitioning into a new field.

Communities lower that barrier. The people you meet aren’t random contacts; they’re peers on the same path, sharing context, goals, and struggles.

As people progress in their journeys, your network compounds. Former peers land roles, gain seniority, and move companies. What starts as peer conversation can later become referrals ,introductions and insider knowledge.

Signal over noise - staying current

For communities that are in fast moving fields like AI, it’s increasingly difficult to know what actually matters. New tools, models, and frameworks appear weekly, and most public content quickly becomes outdated, shallow, or repetitive.

Well-run paid communities often surface current, production tested implementations, real failure modes, and practical use cases that rarely get shared publicly. That kind of up-to-date signal is especially valuable when the field is evolving faster than formal courses or documentation can keep up.

Case Against

You can find structure elsewhere

There are plenty of free or cheap resources already do the curation for you. Roadmap.sh, structured YouTube playlists, well-sequenced Udemy courses and of course well written Reddit posts. If you’re resourceful, you can piece together a learning path without paying a premium.

You don’t need external accountability

Some people are self-motivated. If discipline isn’t your issue, this benefit disappears.

Personalised help doesn’t scale

As communities grow, access to mentors becomes diluted. The person you actually want help from might be unavailable. And if you only need support at the interview stage, it might make more sense to pay someone for a one-off session or tap into free resources/communities.

The price doesn’t match the value

Even if all five benefits apply to you, there’s a threshold. A £500/month community offering what you could get from a £50 course and some free Discord servers probably isn’t worth it. Always compare against alternatives.

Financial reality

You might simply not be in a position to take on that commitment. Other responsibilities come first and that’s a valid reason on its own.

Paid communities aren’t inherently good or bad. The question is whether the specific benefits they offer are things you actually need, can’t get elsewhere, and are priced appropriately for your situation.

Be honest about where you are in your journey. Early on, structure and accountability might be invaluable. Further along, you might only need targeted help with interviews. The worst outcome is paying for something you won’t use or could have found for free.

Plugs

A collection of interesting links I’ve found from trawling the internet

Yunus - Anas Al Emadi

Antigravity - The new AI IDE on the block. Check out the demo video.

Claude Skills - Another way of trying to 10x your workflow

Pile - Desktop app for reflective journaling. AI powered ofcourse.

TL;DR

Hackathons aren't about writing perfect code - they're about moving fast, telling a great story, and working as a team. You get 24 hours to 2 weeks to build something that actually works and solves a real problem. Focus on creating a solid demo, throwing in one cool feature that makes people go "wow," then pitch it like you mean it.

The best part isn't winning prizes - it's learning new skills on the fly, meeting amazing people, and getting that incredible rush from building something from scratch in record time.

First Hackathon

My first hackathon wasn’t even on my radar.

I was looking up a startup’s pitch deck for work, when I stumbled across an old video of them presenting at Startup X. Checking out the website I noticed they had a healthcare-themed hackathon running.

I thought: Why not?

I ended up building a platform for eczema sufferers to track symptoms via a food diary, then used AI to flag potential dietary triggers. It was rough, but it worked well enough to demo.

That one event turned into five hackathons over time, because once you’ve had that rush of building and presenting something in such a short burst, you want to do it again and again.

But lets take a step back…

What is a hackathon?

A hackathon is a time-boxed build, anywhere from 24 hours to two weeks. You (solo or in a team) get a theme or problem statement and create a proof of concept to present/submit at the end.

Typically, there are different tracks that you can pursue within each theme where in there several problem statements for each track. As an example, I recently did a Hack for Gaza hackathon of which the overall theme was building a solution to help our brothers and sisters in Gaza. These were the following 3 tracks:

• Healthcare

• Political activism

• Humanitarian aid/NGO support

The goal: demo something that convinces people your idea is a potential solution to the problem statements, not ship production ready code.

Why should you join a hackathon?

The upside of a hackathon is uncapped. You potentially are building something that could be the foundation of a startup. Hackathons give you that short focused time to work on a real problem that matters with domain experts judging. That is not something that is necessarily available outside of hackathons readily.

But, let’s be brutally honest. Most ideas are not one that are going to break you out of your 9-5 job, so what might motivate you then?

Well, the following might:

• Cash prizes. Enough said.

• You’re forced to learn new tools on the fly. like I did with learning about AI agents orchestration and that pressure cements skills in a way tutorials can’t

• You get to build fast without overthinking, often around real world themes like healthcare or humanitarian aid, which makes the work feel meaningful.

• It’s a way to organically grow your network. You get to meet developers, designers, PMs, and domain experts you might never cross paths with otherwise, and sometimes those relationships turn into future collaborations.

• You walk away with a portfolio ready project that can be shown off on LinkedIn or in interviews. puts it bluntly: a CV alone isn’t enough anymore. Employers want to see proof of execution. A hackathon project is tangible evidence you can ship under pressure.

Do I need to be experienced?

A common misconception is that hackathons are only for developers and experienced ones at that. In reality, I’ve worked with:

• Product managers — e.g. Google PMs who shaped the vision and pitch.

• Designers — UI/UX engineers who made the product feel real.

• Domain experts — doctors, lawyers, educators who kept us solving the right problem.

And now, with vibe coding and tools like Replit, Lovable, and Codewords, you can go from an idea to a working prototype without needing a computer science degree.

The bar to entry has never been lower. The advantage goes to those who can frame a clear problem and move fast, not just those who can write the cleanest code.

Of course the same is true for developers with tools like Cursor and Claude Code.

How does a hackathon go?

While formats vary, most hackathon teams follow a similar rhythm. Here’s how a short single day hackathon typically plays out:

• 9:00 AM – Check-in & Networking
  Get your badge (or log into Slack/Discord if it’s online), grab some food, and start talking. This is where I would scout potential teammates and get a feel for the event.

• 10:30 AM – Kickoff
  Organisers outline the theme, tracks, and problem statements. I’d listen closely as the judging criteria are hidden between the lines of this intro.

• 11:00 AM – Team Formation & Ideation
  Lock in your team. Brainstorm freely, but cut ruthlessly — a small, focused idea will beat an ambitious mess.

• 12:00 PM – Domain Expert Check-in
  Validate early. At the Hack for Gaza hackathon, doctors who had worked on the ground gave instant feedback on healthcare ideas — I found this to be the fastest way to kill bad assumptions.

• 12:30 PM – Core Build
  Define your must haves and skip the “nice to haves.” Winning teams get a demo running fast, then layer extras only if there’s time.

• 4:00 PM – Halfway Checkpoint
  Have a bare bones internal demo by now. It doesn’t need to be pretty, but it should already prove your core idea works.

• 6:00 PM – Enhancement Phase
  Now add one memorable “wow” feature and tighten the UI. This is what sticks in judges’ minds after they’ve seen 20 demos.

• 8:00 PM – Final Push & Submission
  Merge your code, fix last minute bugs, and polish your pitch deck. Even the best builds lose if the story isn’t clear.

By 9 PM, you’ve gone from strangers with a theme to a proof of concept worth showing off and, if you’ve done it right, a serious shot at the win.

Hackathon priorities pyramid

Heres how I’d prioritise during a hackathon.

At the very least you should aim to have a working demo, as previously mentioned.

My winning pitch template

So look one of the most daunting parts about is on top of building the demo you may then need to pitch that idea.

This is how I structure a 2-minute live pitch with a pitch deck. Use Loom.com to record your pitch if you need to submit a recorded demo.

Remember: The deck isn’t there to mirror your words, it’s there to make them stick.

• ⏱ 0:00 – 0:20 → Hook & Problem
  Open with a short, human story or relatable scenario.
  Example: “Last week, Sarah missed her hospital appointment, not because she was sick, but because the hospital couldn’t coordinate her ride.”
  End with a sentence that makes the pain obvious: “This happens to thousands every year, costing hospitals millions.”
  On the slide, this is just a single powerful image or one striking stat, nothing else. You want the audience to feel the problem before you explain it.

• ⏱ 0:20 – 0:40 → One-Line Solution
  Introduce your product name and deliver a simple, clear value proposition: “CareConnect matches patients with real-time transport options in seconds.”
  Your slide here is your logo, tagline, and maybe one sentence — clean and uncluttered.

• ⏱ 0:40 – 1:40 → Demo in One Seamless Story
  Pick a single user scenario. Keep it realistic and relatable.

  Example: “Sarah books hospital transport on her phone.”
  
  Break it into three or four micro-steps:

  Step 1: Sarah opens the app.

  Step 2: AI matches her with a driver instantly.

  Step 3: Booking confirmed, driver en route.

  Step 4 (Optional): A quick behind the scenes visual if it’s technically impressive.
  
  Narrate while you click through — your slides here are just screenshots, short clips, or clean visuals of each step. Avoid “imagine this” — preload data or use short videos so nothing breaks. The goal is to show the value, not describe it.

  
  End this section with the “aha moment”: “Now Sarah gets to her appointment on time and the hospital sees fewer missed visits.”

• ⏱ 1:40 – 1:55 → Results & Impact
  Quantify the benefits. “This reduces missed appointments by 40%, saving hospitals £500k a year.”
  On the slide, one chart or big-number metric is enough. Tie it back to your opening story so it feels like a complete loop.

• ⏱ 1:55 – 2:00 → Memorable Close
  One emotional or clever tagline. “CareConnect - because no one should miss care for lack of a ride.”
  
  The final slide is just that tagline with one image that reinforces it. End on something that will stick in their heads when you walk off stage.

Where to find hackathons?

Hopefully the above has inspired you to venture off into your first hackathon or at least think about it. So I couldn’t leave you without links to a few places where you can find them:

1. Deen Developers

2. lablab

3. hellofuturehackathon

4. Dorahacks

5. Devpost

6. Luma

And of course keep on eye out on social media platforms like LinkedIn and X

Plugs

A collection of interesting links I’ve found from trawling the internet

At-Tawbah (The Repentance) - Nasser al Qatami

tldraw - Very good white boarding tool. Think of it as excalidraw but better.

SnitchBench - bench mark for which language models will snitch (spoiler: its all of them)

GPT-5 - A good read on a blog giving a more realistic insight on GPT5s performance improvement.

Read the previous articles on opportunity here and perception here.

Soft

Skills break down into two main types, technical and soft. But that covers a broad spectrum. In this article, we will dive into the soft skills aspect.

Grit

If I had to identify one skill as the key to success in any career, especially in tech, it would be grit. As you can see, there are weekly updates on AI, and the tech landscape is constantly evolving. It's vital to have the mental fortitude to keep learning continually. It does at times feel very much like a ‘sink or swim’ type of industry. But that is part & parcel of what we signed up for.

Communication

Communication is arguably more important than technical skills. While it doesn't necessarily solve problems directly, it goes a long way. Here are some my communication tips:

1. Don't Waffle: If you don't know something, simply say, "I don't know, but I'll research it." I've been on countless calls where someone is clearly waffling and the worst part is everybody knows they are.

2. Understanding: Ensure you fully grasp the problem or task at hand before proceeding.

3. Status Updates: Provide status updates without being prompted. You don't want your manager messaging you asking, "Did you do that thing?" or "What's the status on this?" It makes you appear disorganised. Unless you're being micromanaged, most people won't ask for a status update until they really need it. I’ve found that updating the Jira ticket proactively or posting updates in the relevant channel to be the most effective.

4. Present Solutions: Be the person who presents solutions, not just problems. If you encounter an issue and want to seek help don't say, "I'm facing this issue. Can you help me?" Instead, say, "Here's the problem I've encountered. I've looked into it, and I think the root cause is X. Here are some proposed solutions. What are your thoughts?"

Organisation

We all know the importance of being organised. But this becomes crucial when wanting to perform at a senior level. So what is important here is to develop your own system of being organised. Different systems work for different people. I’ve watched countless productivity videos over the years and have stolen bits and bobs of people systems that work for me.

My organisation method is simple:

1. Daily To-Do List: Daily to-do list with tick boxes next to each item. It gives me a sense of accomplishment when I tick them off.

2. Team Update: Summarise work completed for the day in this section

3. Standup: During standup, I reference my team update. This way, I don't forget what I did yesterday, and I have my updates ready.

4. Notes: Throughout the day, I add notes to my to-do list if someone asks me to do something on the fly

5. Tickets: I keep separate page to add more details about the ticket I’m working. This includes things like; one sentence summary, useful links, approaches taken. This is also useful when it comes to write your promotion packet as you will be able to reference all of the details of the work completed for the ticket.

I use Notion to keep track of all this. Each day, I duplicate the previous day's to-do list and remove completed tasks. This creates a rolling to-do list. I do this for each month and year. This allows me to see what I did each month and put together my promotion packet more easily.

Time Management

As an engineer in tech, you'll encounter various requests. I've found it crucial to set boundaries early on and learn to say no when necessary.

If your manager is pushing you, try saying, "I'm currently working on these three tickets. Which one should I deprioritize to accommodate this new task?"

Don't automatically accept tasks just because your manager asked—they might not be aware of your current workload.

This is especially important if someone outside your team makes a request. Redirect them to your manager and give your manager a heads-up.

For example, "This person is asking me to do X. Given my full plate right now, I'm directing them to you." Use your manager as a buffer for incoming requests.

Lastly, avoid excessive multitasking. Constantly switching contexts can be mentally draining. Working on four completely different tickets simultaneously is exhausting. Instead, aim to work on related, interconnected tickets—it's more efficient and less taxing on your brain.

That’s it for our promotion series, thanks for tuning in !

Plugs

A collection of interesting links I’ve found from trawling the internet

Al-Anfal (The Spoils of War) - Sheikh Ali Abdur Rahman al Huthaify

Codecrafters - Become a better software engineer through practical labs. More coming on this soon !

Explain shell - Explains shell commands

Swapfile - A digital swapfile for inspiration

Read the previous articles on opportunity here and perception here.

But first …

Technical

Skills break down into two main types, technical and soft. But that covers a broad spectrum. In this article, we will dive into the technical aspect.

Fundamentals

Early on in my career, I struggled with increasing my technical chops.

I just never felt confident committing myself to any one direction.

I didn’t know if I should I study courses, youtube tutorials, certification pathways, or just pick up what I needed as I went along. I was in a state of analysis paralysis.

So the biggest question of all that loomed over me was, what should I study?

“Fundamentals, fundamentals, fundamentals. You’ve got to get the fundamentals down because otherwise the fancy stuff isn’t going to work”

The place to start, of course like with all things, was the fundamentals.

You can’t build a great career on weak foundations.

The Senior role was an important milestone that I was striving towards, but it came with the expectation of well-rounded expertise.

Imagine being asked a straightforward question about Docker, only to realise you’re stumped due to a lack of foundational knowledge.

A situation like that would’ve challenged my credibility and as discussed in a previous article I wanted to be considered senior at the industry standard, not just in my current role.

The next logical question becomes: how can we identify these fundamental weaknesses and, more importantly, work to upskill in those areas?

Let’s deal with the first part of the question. I've identified four ways to help pinpoint areas for improvement:

• Challenging Tickets - Trust your intuition. We often intuitively know our weaknesses. They're typically reflected in the kind of work we avoid due to knowledge gaps

• Job Specifications - Look at job postings! I noticed particular tools or technology would appear frequently and If I lacked that knowledge, it was time to study it—even if my company didn't use it. Ideally, I could introduce that tool or technology to my company. This approach offered dual benefits: I was acquiring market relevant skills while also enhancing the company's infrastructure

• Roadmaps - Roadmaps maps were a great way of gaining an understanding the types of tools and knowledge areas in the sector. However, I used this resource cautiously— roadmaps often expanded to include every technology in the field, which is not always be helpful. I cross-referenced it with job specifications to highlight the most relevant technologies

• Feedback - As discussed in the first article, regular feedback was crucial. Colleagues have been a great resource in providing a different perspective on my performance as an engineer

Great, so we’ve identified our weakness. Whats next? Well its time to start hands on by doing labs.

Labs

I've often seen people spend time on theory without actually putting into practice what they've learned. They might be able to explain the theory of Docker, but wouldn't know how to write the first line of a Dockerfile.

Make sure you get your hands dirty and build things with the tools you're learning. Better yet, try to document your work so you can look back on it and take it away with you.

To put it simply, I found hands-on labs a far more effective learning tool than just reading about technologies in articles or watching tutorials.

Troubleshooting as a Learning Tool

Troubleshooting has been my greatest teacher. The most valuable learning experiences often occur on the job.

"A fool learns only from his own mistakes. A wise man learns from the mistakes of others."

I prefer a modified version of this famous quote: You should learn not only from others' mistakes but their experiences as well.

I believe the true value in articles like these lie in sharing experiences so that you can progress more quickly on your own journey.

With that in mind, I'd like to help you identify some key areas to focus on.

I've gained the most knowledge when faced with obscure errors, forcing me to scour documentation, Stack Overflow, or ChatGPT for solutions. This is where true learning occurs. It also enhances your reputation as an engineer. If you become the go-to person for any random issue—thanks to your persistence and work ethic—it significantly boosts your standing.

These are my two tips for troubleshooting:

Occam's Razor: When faced with several possible explanations for a problem, the one with the fewest assumptions is usually correct. Most issues have simple solutions. For example, a permissions problem is often caused by a typo or a misunderstanding of Identity and Access Management (IAM). Early in my career, I believed that issues raised by senior engineers had to be complicated. However, I discovered that they are often straightforward—like a simple mistake or a misunderstanding of a service. Always look for the simplest explanations before considering more complex ones.

Tenacity: When you're stuck, push yourself to find a solution independently. Imagine your manager is on vacation and you're the only one available. How far would you go to resolve the issue? Be reasonable—don't spend days on a problem your manager could quickly solve. But don't immediately turn to them at the first sign of trouble. Tenacity. This approach helped build my confidence. When I persisted a little longer, I was able to find the solution myself. Sometimes, stepping away and returning with a fresh perspective the next day can make all the difference. I was often surprised how often it was a minor issue all along.

Plugs

A collection of interesting links I’ve found from trawling the internet

Al-A'raf (The Heights) - Sheikh Ahmed bin Talib

Hacking with PDF - How to hack via PDF 😭

A real 10x engineer - Have you ever met a 10xer ?

Justinmath - Roadmap to get from high school math to cutting-edge ML/AI

I recently got promoted from Mid to Senior Engineer, and I thought I would share my insights in a promotion article series for those looking to achieve the same. The opportunity to get promoted has to be available and to be considered is dependant on the perception of you, which is influenced by your skills.

In this article, I will be going over the perception aspect.

Read the first article on opportunity here

Perception

I would break down perception into 3 categories; self, internal and external.

• Self - how you view yourself

• Internal - how you are viewed inside the company

• External - how you are viewed outside the company

Lets dive into each one separately.

Self

Your perception is your reality.

How you perceive yourself, dictates how you move in the world. So its crucial to have the mindset that you can achieve senior.

In a industry rife with imposter syndrome that, isn’t an easy task as it first appears.

It starts with reflection. It's easy to look forward and compare yourself to others. But first take a step back and compare yourself now to back when you first started trying to break in. In a similar vein, this is just the next mountain to climb.

It has always been you vs you.

I’ve talked about dealing with imposter syndrome more in a previous article.

Lets take some practical examples of how low perceived self value can dictate how you move in the world:

• Staying quiet in meetings. You don’t value your input and so you don’t contribute much, if anything.

  • Instead, give your thoughts first, whatever they may be. That creates opportunities to discuss your line of thoughts and explore your ideas more e.g. “I had a think about this problem earlier and have some thoughts I’d like to share…”

• Getting overwhelmed at complex tasks. You don’t have confidence in your ability to break down complex tasks into smaller more solvable components.

  • Instead, publicly break down the problems your working on into smallest constituents, say in a slack thread, and get feedback from the team lead/senior engineers e.g. “This task feels like there are a lot of moving parts I have broken the problem into logical steps in the ticket, could you take a look when you get a chance”

Internal

To build positive perception of you, work on what matters and make it visible.

Work on What Matters

Ideally you want to work on low-effort, high-impact tasks.

In a large and established organization, most of the low-hanging fruit has already been picked. You don't want to work on high-effort, low-impact tasks because that's a waste of time.

You end up with two main categories of work as a result: low-effort, low-impact, which is comfortable but doesn't contribute much, and high-effort, high-impact, which is where the real growth happens.

As good as this sounds in theory, how do we actually identify those tickets?

Well, some tell tale signs (not all in one ticket of course) include:

• Collaboration - Involves cross-functional collaboration

• Automation - Automates a tedious repetitive manual task

• Pain points - Removes major pain points that teams have been facing for a while

• Hard - It may well be difficult to implement with a lot of moving parts

I once picked up a ticket to investigate an intermittent error affecting many pipelines. The error was challenging to trace, but after thorough investigation, I discovered it was tied to the authentication process.

Updating this was far from simple. The pipeline was used by multiple teams, and the fix required implementing a new authentication workflow. However, I knew the value in making the change—it would save tens of hours of developer frustration and boost productivity as they were not having to rerun pipelines uncessarily.

I developed the new workflow, rigorously tested it, and documented the changes and benefits in Confluence to help teams transition smoothly. Completing this work meant tackling a high-impact challenge that wasn't easy and required cross-team collaboration since everyone relied on that pipeline.

Make Your Work Visible

Don’t hesitate to present your technical work and highlight its impact. Many of us shy away from this. If you've worked on a sizable ticket and think it was high impact, share it with your department.

Often, other teams aren't aware of what you're working on, so take the opportunity to present it at a company-wide forum, like a "show and tell." If your company doesn't have something like that, you could:

• Propose starting a “show and tell” for your department

• Post in the relevant channel when you accomplish something notable

Your manager can support you in this. If you've done something worth sharing, ask your manager to post about it in the channel. It might feel a bit uncomfortable, but visibility is important. You want people to recognize your competence and contributions.

For example, I created a “Platform Release Notes” page in Confluence, where any major changes to the platform would be documented. Individuals could follow this page for updates, and I would also post in the Slack channel to keep everyone informed. For the authentication issue I mentioned earlier, my Slack message was something like:

“Hey team, I’ve updated the auth process to resolve the ephemeral issue we’ve been experiencing in our pipelines. For details on the specific changes you need to make, check out the Platform Release Notes here.”

This approach also had the added benefit of creating a catalog of work that I and others on my team had completed, making it easier to track and showcase our contributions over time.

External

Even if you have a good internal perception, it's crucial to have an external presence.

When you leave your company, people may not fully recognise how hard you worked, whether you tackled the most impactful tasks or the quality of the work you delivered. You can talk about it your CV of course, but that requires for it to be read in some depth.

If you were to view your effort it in terms of currency, its one that doesn’t hold much value outside of the company.

So its important to also work on things that can take with you. I call these ‘take awayables’.

Lucky for us with some effort we can exchange that ‘local’ currency for a global one. To do this it needs some effort on your part into transforming your work into take awayables.

Here are some ways you can do that:

1. Write Articles: If you've worked on a technically complicated ticket, even if it wasn't a major project, write an article about it. Chances are, other people in the industry have faced similar issues.

   1. Here is an article I wrote on centralised log monitoring in GCP.

2. Create Technical Videos: Making videos about topics you have working familiarity with helps in two key ways, even if you are still in the process of learning it. It will help solidify your own understanding and positions you as an expert in that field.

   1. Here is my friends Youtube Channel where he was creating Kubernetes tutorials as he was preparing for his Kubernetes exams - saedf0

3. Give Talks: If you're not comfortable giving talks publicly, do a small talk for friends/colleagues (in the same field ideally) privately. Putting into practice explaining technical work helps build your confidence.

4. Side Projects: We all know about side projects. They're a great way to showcase your ability.

   1. Here is a project I built whilst trying to break into DevOps - infra-get-scheduled

5. Certifications: Not only is it a take awayable but often one that you can get your company to pay for !

   ---

   I hope reading this article has changed your perception on the importance of perception. Stay tuned for more articles in our Promotion series !

   Leave a comment

   ---

Plugs

A collection of interesting links I’ve found from trawling the internet

Al-An'am (The Cattle) - Sheikh Abdullah Al Juhany

git shortcuts (oh-my-zsh) - ZSH Configuration manager that makes me feel like a 10x developer

Let me google that - Just got asked a question that is easily Googleable ? I’ve got the perfect plug for you !

How to be tax resident in no country and pay 0% tax - Anyone else tired of being taxed to no end ?

R2D3 - A visual introduction to machine learning. Incredibly clean website.

Keyboard University - I’ve started getting into custom keyboards recently and used this website to learn more.

Subscribe now

In this article, I will be going over the opportunity aspect.

Opportunity

Availability & Intention

Make sure the role is available and your manager is aware that you want to move up

We all like to be rewarded for our efforts and so before putting in the work to get promoted to senior internally, it’s important to clarify availability of the role and your intentions with your manager.

Quite simple, right? But you would be surprised at the number of people that I’ve spoken to that haven’t clarified either with their manager.

They put in the effort only to get responses like "Sorry, we don't have the budget right now", "The position is no longer available" or, worst of all, "We'll consider you for the next cycle". Frustrating to hear to say the least.

This is what one-to-ones are for.

Instead of just giving status updates on your tickets (which really is what the daily stand-ups are for!) you should be using them for strategic discussions about your career.

In the context of working towards a promotion it should be:

• About the work you’re doing to level up

• Any status updates on the availability of the budget/position

So, up to this point, perhaps it’s been a little bit theoretical, what are some practical talking points?

• Weaknesses - "I've noticed I have a weakness in this particular area. Are there any tickets in the upcoming sprint or quarter that can help me address that?"

• Prioritisation - "I’m being pulled in multiple directions, can you help me prioritise the work?”

• Certification - “I’m interested in sitting this certification, can you get the company to help pay for it?”

• Progression Framework - “Can we put together a framework that outlines what it means to be senior”

• Feedback - “Do you have any feedback for me on my overall performance?”

In addition to active support from your line manager, you also want support from your skip manager where possible. As I’ve already mentioned, there is always a political element in securing funding for a senior position or a salary increase. Other departments might be fighting for the same budget or you may even have intradepartmental competition.

Defining "Senior"

Understand what it means to be senior at your company

But let’s take a step back. What does it even mean to be a "senior engineer" in industry? There are many definitions and even more countless arguments about the definition online.

Is it years of experience? Is it quality of experience? Is it somewhere in the middle or a combination of both?

Big tech companies usually have a progression framework to help define this. This framework outlines the roles and responsibilities at each position. In an ideal world meeting all the competencies from your companies’ progression framework should result in you obtaining the promotion.

Of course, reality is different. Other factors come into play, but having this framework is key. Speak to your line manager to find out if you have one.

However, even if you do, I recommend creating your own. "Senior" means different things to different people, and you want to be considered senior across the industry. If you don't know where to begin, examples can be found online e.g. Dropbox

Why is this important? If you want to leave your organisation and what's considered senior at your place doesn't meet the industry standard, it will be challenging to get a senior position elsewhere.

Promotion Packet

Gather evidence in the form of a promotion packet

A promotion packet contains evidence demonstrating that you meet the criteria defined in your progression framework.

For example, if one criterion is "I demonstrate deep technical expertise in my area" you would include evidence of this in your promotion packet. You might say, "I demonstrated deep technical expertise by resolving…” and then detail the specifics.

I also included curated feedback from all the senior engineers I worked I collaborated with regularly. I asked for it at the end of each ticket and by the end of the review period, I had detailed feedback from about 20 engineers.

Here are the questions I asked:

• What are some things I’m doing well?

• How could I improve or develop further?

• What have been my best achievements so far? What behaviours did you observe that led to these?

• How engaged was I during the work?

• Any further notes

When the senior position became available, I applied internally and had to do an interview. During the interview, I cited evidence from my promotion packet, which I had sent ahead of time.

If you've agreed on a progression framework with your manager, listed all the evidence that you've met the criteria, received excellent feedback and smashed the interview it makes it should make it very difficult for them to say no. Of course, they still can. I'm sure some people have experienced that. If that does happen, it might be time to move on.

Company Culture

Consider the intangibles to getting promoted

Beyond the progression framework there may be intangibles that need to also be met. You might be at a place where the people getting promoted are working significant number of hours beyond the contracted hours or are engaging in social activities that you're not comfortable with.

A great way to find out what those intangibles may be, is to speak someone thats recently got promoted. They will be able to give you company specific insights.

Once you’ve identified those intangibles its time to assess. Think about if the unofficial checkboxes you need to tick are ones that you would be willing to. If not, it's time to consider moving elsewhere.

External

The grass may actually be greener on the other side

Now imagine you’ve spoken to your manager and after assessing the situation, you’ve come to the conclusion promotion isn't available or realistic. At this point, you have two options:

1. Apply elsewhere for leverage: Get an offer externally. Either for more pay or a senior position. You can then leverage that offer to negotiate a counter offer with your current company.

2. Accept the external offer: If they decide not to match the compensation package/title increase, you can accept the senior position elsewhere.

A general rule of thumb is that if you've gone through the effort of applying elsewhere, you should consider leaving unless your current place is exceptional. This is especially true if you've been with them for longer than 2 years.

I hope you’ve found this article useful, leave your thoughts down below and watch out for the following articles next time on Dragonball Z The Pattern!

Leave a comment

Plugs

A collection of interesting links I’ve found from trawling the internet

Al-Ma'idah (The Table Spread) - Sheikh Bandar Baleelah

C2PA - How do we know if content has been AI generated or not? Check out this video by Fireship summarising the work being done to help identify AI generated content

Prepare.sh - Latest real technical FAANG (+ others) interview questions with practical labs

Dribbble - Website for showcasing coolest website on the internet, great for web design inspiration

Midjourney - Check out MJ if you want to be able to create AI generated images. Note: it does, sadly, require a monthly subscription

Subscribe now

You're at a coffee shop, laptop open, trying to decide on a database for your new project. Your caffeine-fuelled brain is bouncing between SQL and NoSQL - I call it the coder’s block. Sound familiar?

I recently found myself in this exact situation, debating the database dilemma with a colleague over some questionably strong espresso. Here’s what I found:

Choosing a database is a lot like picking the right coffee order – it all depends on what you need and when you need it.

Let's start with the classic espresso of databases:

Relational

You know, the classics like MySQL, PostgreSQL, and Oracle. They're the perfectly structured shots that keep the data world running. When do you order this particular brew?

• When your data is organised and structured

• When you need reliable transactions

• When you need to combine data

But sometimes, you need something a little more... flexible. Enter…

NoSQL

You’ve probably heard of MongoDB, Cassandra, and Redis . They come in different flavours:

• Document Stores: For when your data is as varied

• Key-Value Stores: These are super fast and great for things like caching or session management.

• Column-Family Stores: Cassandra falls into this category. They’re designed for high write and read throughput, perfect for big data applications.

• Graph Databases: Neo4j is a popular one here. If you’re dealing with complex relationships (think social networks like Facebook), these are your go-to.

So, how do you choose?

Well, it's not always as simple as "I'll have my usual"

Sometimes you need the structured reliability of a classic espresso (relational). Other times, you need the flexibility of a create-your-own brew (NoSQL). And occasionally, you might even need both – a database blend, if you will.

Consider this:

• Is your data changing fast? NoSQL might be the one.

• Need rock-solid consistency? Go with relational.

• Expecting more users than a coffee shop on a Monday morning? NoSQL scales like nicely.

• Don't be afraid to mix and match. Use relational for your financials and NoSQL for your user profiles. It's like pairing the right cake with your coffee.

Remember, there's no one-size-fits-all in databases. It's about finding the right brew database for your specific needs.

So, take a deep breath, consider your options, and make your choice.

What's your go-to database 'brew'?

Drop your thoughts in the comments – who knows, your insight might save another developer from a database disaster!

Leave a comment

Plugs

A collection of interesting links I’ve found from trawling the internet

An-Nisa - Recitation by Sheikh Saud Ash Shuraim

AI Playground - A playground for giving inputs to two AI models at once

18 Things From WWDC 2024 - Short summary of latest Apple event which was jam packed with a lot new updates

Comos.so - A Pinterest like website for creatives which allows you to do cool things like create a inspo board on specific colours

Neural Networks Intro - Short series of visual explanation of how neural networks and by extension transformers work

Drive Around - Drives you around dozen cities with background noise to get a vibe for the city

Sacrifice development time to write documentation or give the order to go full steam ahead?

This wasn’t just a hypothetical scenario for me — it was my daily reality at a recent startup gig. Our dev team was small, scrappy, and racing against the clock. Our product? Promising. Our resources? Limited but highly skilled (shout out to my dev team!) Our to-do list? Never-ending.

In this pressure cooker environment, our tech lead became our human Wikipedia. Need to know why that function was named after someone’s cat? He knew. Curious about that cryptic comment from two years ago? He remembered. His brain held the master key to our digital kingdom.

But here’s the thing: This wasn’t poor planning or negligence. It was survival.

With investors breathing down our necks and customers clamoring for features, every minute counted. Formal documentation often took a backseat to immediate development needs. Our lead’s encyclopedic knowledge became our secret weapon, allowing us to move at breakneck speed and tackle complex issues on the fly.

However, even secret weapons have their drawbacks:

1. Information bottlenecks during crunch times (and let’s face it, it was always crunch time)

2. Our poor tech lead was constantly bombarded with questions

3. The terrifying “what if” of potentially onboarding new developers (if we ever got the funding)

Despite our best efforts and coding marathons, our startup story didn’t have a happy ending. Economic headwinds proved too strong, and we ultimately faced liquidation.

But the lessons we learned about balancing development and documentation in a high-pressure environment? Those are invaluable.

So, how do you juggle knowledge sharing when you’re trying to keep the startup dream from sinking?

In retrospect, our situation highlights how external pressures can shape internal practices. While comprehensive documentation is ideal, sometimes teams must adapt to their circumstances and rely on other methods of knowledge sharing.

For teams in similar situations, here are some lightweight approaches that helped us:

1. Quick debriefing sessions after solving complex problems

2. Encouraging detailed commit messages and inline code comments

3. Regular, informal knowledge-sharing talks

To team leads who find themselves as the primary knowledge holder: Your role is crucial, especially in challenging times. While you may not have time for extensive documentation, even small efforts to share and record information can be incredibly valuable.

In short…

Ultimately, every team’s situation is unique. While robust documentation is a worthy goal, it’s important to balance it with other pressing needs. The key is to find sustainable ways to share knowledge that fit within your team’s constraints and support your current objectives.

What are your tips on knowledge sharing in a startup environment?

Now, I'm curious: What knowledge-sharing hacks have you discovered in your startup adventures? How do you balance the pressing need for development with the long-term benefits of documentation?

Drop your wisdom in the comments below—who knows, your tip might just save another team from drowning in their own code!

Leave a comment

Plugs

A collection of interesting links I’ve found from trawling the internet

Al-Imran - Recitation by Sheikh Abdul Mohsin Al Qasim

talhaakhoon.dev - Check out the personal website I’ve been working on ! Comment below if you would like an article explaining how to building something similar end to end.

What I do to remember everything I read - Anas Nuur Ali - Another insightful video from one of my favourite youtubers !

Why I LOVE Cold Showers - On the fence about cold showers ? Check this out to see potential benefits

Imposter Syndrome - “The condition of feeling anxious and not experiencing success internally, despite being high-performing in external, objective ways. Often results in people feeling like ‘a fraud’ and doubting their abilities.”

I had just started a new job in tech and I was starting to feel this sense of impending doom. That I was going to be exposed as a fraud in a matter of weeks, no, days.

I knew I was experiencing imposter syndrome.

In some ways, I thought because I was already aware of the concept, it wouldn’t affect me.

Alas dread it, run from it, imposter syndrome arrived all the same. Which got me to thinking…

Why does imposter syndrome occur?

The root causes of imposter syndrome is something that is deeply intertwined with someone’s personal history.

Its likely to show up if someone ties their self worth to what they know and/or how they perform i.e. doing well academically and getting things right

Performance and knowledge. This felt like the crux of the problem.

Rumsfeldian knowledge refers to a way of categorizing knowledge into three types, based on a famous quote.

Here's a simple explanation:

1. Known Knowns

   • Definition: Things we know that we know

   • Example: You know how to use Amazon S3 to store and retrieve data.

2. Known Unknowns

   • Definition: Things we know that we don’t know

   • Example: You’re aware of AWS Lambda's existence but know that you don’t know how to set it up

3. Unknown Unknowns

   • Definition: Things we don’t know that we don’t know

   • Example: There might be a new AWS service that has just been launched, and you’re completely unaware of it. Because you don’t know about this new service, you can’t consider its potential benefits or how it might solve problems you didn't realize you had.

Representing this visually, inside the circles was my knowledge and outside of it was knowledge I didn’t have. As I gained experience and my knowledge expanded over time so too did the “known unknowns”. The challenge for me was the number of "known unknowns" and the rate at which I was converting those known unknowns into knowledge.

So what to do when imposter syndrome strikes?

In short, I had to challenge the problematic thinking patterns and beliefs.

To tackle the perceived subpar performance I had to get feedback and reflect.

To overcome the knowledge gap I had to mentor and grow.

Feedback

The most objective way I kept my imposter syndrome in check was getting regular feedback from my colleagues.

It gave me an understanding of how I was being perceived by others and as a result I had a more complete picture of where I stood with my strengths and weaknesses.

Reflect

Reflecting on past achievements, no matter how small, helped me to realize that I had a body of work that flew in the face of the feelings I was experiencing.

Completed a ticket? That was a win. Unblocked a colleague? That was a win.

The more I started to recognise those wins as wins, the more the feeling of being an imposter waned.

Mentor

It was hard for me to realize how far I had come as I was always looking at how far I had to go.

Particularly as I had transitioned from a different career path and felt like I should have already known concepts x, y and z.

I found that mentoring tech aspirants provided a good baseline for gauging the knowledge I had gained, as I saw my past self in my mentees doubts and frustrations.

Grow

The reality is tech is a continuously evolving space.

It’s what attracted me in the first place.

There will always be “known unknowns” and to survive and thrive subsequently requires the adoption of a growth mindset. Once I became comfortable with that idea and adopted that mindset the symptoms started to fade.

What are your tips on dealing with imposter syndrome?

I’d be interested to hear your experiences in dealing with imposter syndrome, so comment down below.

Leave a comment

Plugs

A collection of interesting links I’ve found from trawling the internet

Al-Baqarah - One of my hobbies is finding new recitations. Beautiful recitation by Abdulrahman Almajed

Google Graveyard - A graveyard for all of the Google products that have been (killed) shutdown over the years

How I Made $10m - An Ultimate Guide to Online Courses - Ali Abdaal walking through how to create an online course, as well as what the numbers can look like.

IDX - New online IDE by Google that comes with AI features

Klack - Mechanical keyboard sounds for your Mac. Perfect for those who don’t want to spend $$$ on actual mechanical keyboards

Secrets of the Surahs - New lecture series by Sheikh Mostafa Shaibani on the secrets of the surahs in the Quran. Incredibly insightful.

You’ve read that you need to create your own project to stand out in the market and set out to create something novel.

You realise you are completely lost and don’t know where to even start. So you reach for more tutorials, better tutorials.

Slowly, it dawns on you that you are constantly following step-by-step instructions and never applying the skills learned in a meaningful way.

You my friend, are in tutorial hell 🔥

Where did things go wrong?

When you encounter difficulties in learning, trying to overcome them by seeking out more tutorials and exploring new topics can often make the situation worse.

Constant exposure to new information without practice will lead to increase in the gap between what you know and what you’ve been exposed to, resulting in anxiety and self-doubt.

The question then is how does one escape it ? 🤔

In short, you need to increase your competency without increasing your exposure.

Here are some pointers on how to do that:

🎮 Play — Iterate with what you’ve already learnt and built. Let’s say you built a To Do List app, great. Now, can you add an extra feature e.g. ability to set a reminder. Playfully adding features that you want and pushing the boundaries of what you know is a great way to practice.

🧐 Reframe — creating something, even if it’s not a complete application, is still an accomplishment. It’s common for students to say “I don’t know how to build anything”. You’ve created a pipeline that runs a basic script? You’ve built something. You made hello world appear on a web page? You’ve built something. By reframing what you consider to be building “anything” you can reduce imposter syndrome and increase confidence.

📚 Revisit — Go back and revisit topics you’ve already studied, especially the foundational ones. Sometimes abstract concepts take a while to sink in and revisiting a topic can highlight that. Watch more tutorials, if necessary, but stay on the same topic until you get a good understanding. It can be easy to get distracted by shiny new technologies, but it’s important to master the basics before moving on to more advanced topics.

These tips might not get you all the way out of the maze, but I hope it gets you closer to the gate 🙂