What Enterprises are really, desperately looking for in AI is a brainy person to come in and
1) tell them what to do
and
2) take the fall when things go sideways
They will never frame it like this, but this is exactly how it is. And so nothing has changed.
"How do I know I am growing in my career?" An engineer asked me this question in their 1:1. Here was my reply. Sharing it here so it benefits everyone.
I have a relatively simple formula to see if I am growing in my career. I look at the code I wrote 6 months ago. If I find ways to improve the code, I know I am growing. If I can't find any way to improve the code, I need to learn more.
Replace code with design, architecture, writing, document, blog, talk, business understanding - anything that you worked on. If you can't find ways to improve it, you haven't grown.
It's that simple. Work on your craft.
A Head of Engineering at a Series A company once told me something interesting: "We spend more time in meetings talking about what we should build than actually building it." This resonates with most technical leaders I talk to. The constant back-and-forth, the unclear requirements, the technical decisions made in isolation - it all adds up to massive inefficiency.
This is precisely why we structured Sprint Zero as a 4-6 week intensive process. It's not arbitrary timing - it's based on the reality of how long it takes to properly define a technical product when you're not trying to squeeze it between feature development cycles.
Week 1 focuses on technical discovery and stakeholder alignment. Week 2 dives into architectural planning and technology selection. Week 3 covers detailed technical specifications and risk assessment. Week 4 finalises implementation roadmaps and documentation. Weeks 5-6 are for validation, refinement, and knowledge transfer.
The magic happens when you dedicate time to this work. When technical product definition is squeezed into spare moments between sprints, it never gets the depth it needs. Important decisions get made quickly without proper analysis. Documentation gets skipped because there's always another feature to ship.
But when you dedicate 4-6 weeks specifically to technical product definition, something shifts. You have time to think through edge cases. You can properly evaluate technology choices. You can create documentation that helps your team move faster, not slower.
The engineering leaders who invest in this upfront work consistently report the same outcomes: faster feature development, easier technical hiring, more transparent communication with stakeholders, and significantly reduced technical debt accumulation.
How to apply first-principles thinking to web development for higher ROI:
- Identify the problem: Break down the issue into fundamental components.
- Challenge assumptions: Question existing beliefs and practices.
- Reconstruct solutions: Build new solutions from the ground up based on fundamental truths.
This is exactly why I created @wednesdaysol. An obsession with the craft of software development fuels our entire team. Every detail matters. The beauty is in the tiny things.
In 2012, a stranger booked a call from my website
and that changed everything for me….
Here's what happened -
Back in 2012, my startup was thriving.
- Selling to my network.
- Landing deals through referrals.
- Feeling unstoppable.
Then—it all stopped.
No more warm intros. No more easy deals. Just silence.
So, I did what every founder does:
I built a website.
I thought, “If I just put everything online—clients will come.”
They didn’t.
Zero leads.
Zero emails.
Zero calls.
I had built a mere website, not a sales engine.
The fix:
I asked myself:
"If I needed just ONE lead per month, how would I do it?"
→ Clear messaging: No fluff. No random details. Just:
"Mobile app development with a money-back guarantee."
→ Showed up where my audience was: Directories, forums, niche communities.
→ Turned my website into a funnel: Every page, every CTA, designed to convert.
And, guess what?
It worked!
For the first time, a stranger found my website and booked a call.
That moment changed everything.
What I learned (so you don’t waste a year like I did):
→ Is your website designed to generate leads—or just “look good”?
→ Are you speaking to your ideal customer—or just shouting into the void?
→ Do you have one clear success metric for your website?
You don’t need more traffic.
You need a website that SUPPORTS your GTM strategy.
Fix that, and your website will finally do its job: sell.
Yesterday: Crypto.
Today: AI.
Tomorrow: Quantum.
Trends rise and fall, but great software engineering stays timeless. Master the craft, use the best tools, and outlast every hype cycle. @wednesdaysol
As a developer, you must ask this one question.
What to expect from your manager?
Here's @rameeznkhan, our Head of Delivery, sharing his thoughts.
Want to join us? We're hiring: https://t.co/HIuWqbWHRD
"It feels like yesterday that we started Wednesday. As I keep saying, this is one the best teams I've been a part of." - @Ali_hafizji , CEO at Wednesday.
Here's to many more years of innovation, growth, and success!
Cheers 🥂
How ANRs Sparked Conversations with hundred plus mobile devs
As an Android engineer for over a decade, I've encountered my fair share of Application Not Responding (ANR) errors. These pesky issues that freeze apps and frustrate users have been a constant thorn in developers' sides. Little did I know that ANRs would become the unlikely catalyst for overcoming my introverted tendencies and connecting with fellow mobile developers.
It all begin when I started reaching out to mobile engineers, on LinkedIn, to discuss about how they monitoring their mobile apps in production. As an introvert, initiating conversations with strangers was far outside my comfort zone. However, I quickly discovered that ANRs were a universal pain point that resonated with developers across the globe.
The shared frustration with ANRs provided an instant connection point. Engineers from various companies and backgrounds shared their experiences, challenges, and solutions related to monitoring mobile apps in production. What began as hesitant outreach transformed into engaging discussions about tools, techniques, and best practices. Before I knew it, I had connected with over hundred mobile developers, each bringing unique insights to the table. I learned about different approaches to debugging, monitoring tools I hadn't considered, and creative solutions to common performance issues.
Those frustrating app freezes - ultimately led me to "unfreeze" my social interactions.
We are using these learnings to build Measure; an open source tool to monitor mobile app. You can check it out here- https://t.co/2zGQ0qT7HA