DEV Community: Divyakush Punjabi

A completed foundation is a starting point, not a finish line

Divyakush Punjabi — Sun, 23 Aug 2026 18:59:10 +0000

Completing a formal education in a field isn't the end of learning it — in something moving as fast as AI, it's barely the start. Having my Major in Artificial Intelligence conferred at IIT Ropar by Prof. Sudarshan Iyengar, and then spending a long conversation afterwards about what the field leaves open for the future, crystallized that for me. I wrote about it in this reflection.

A completed foundation is a starting point, not a finish line

There's a temptation to treat a credential as an arrival — the learning is done, the box is checked. In a field like AI, that mindset ages badly within months. The real value of a rigorous foundation isn't that it's complete; it's that it gives you the depth to keep learning the field intelligently as it changes.

The conversation after the ceremony was, fittingly, not about what had been settled but about what the field leaves open — the unanswered parts, the direction of travel. That's the right frame for finishing any serious education: less "I now know this" and more "I'm now equipped to keep understanding this as it evolves."

What completion actually signals

Depth enables adaptation. A formal grounding is what lets you absorb the next development in a field with judgment instead of hype — you can tell what's genuinely new from what's repackaged.
The best practitioners stay curious. A conversation about open problems, at the moment of completion, is the healthy posture — the field's frontier matters more than its settled core.
Learning is a permanent posture. Finishing a demanding program is best understood as building the capacity to keep going, not permission to stop.

The takeaway

Having the AI major conferred was a real milestone — but the most valuable thing I carried out of it was the orientation toward what comes next: treating a completed foundation as the platform for continuous learning in a field that will keep changing. The credential is the floor, not the ceiling.

The full account, including that conversation, is on the page below.

👉 Read it: www.divyakush.com/insights/iit-ropar-complete

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

The underrated professional trait: seeing a long thing through

Divyakush Punjabi — Sun, 23 Aug 2026 18:53:39 +0000

Eighteen months is a long time to hold a commitment when the finish line is that far out and nothing forces you to keep going. Standing outside the hall in Rupnagar before the ceremony — in front of the banner for the Major in Artificial Intelligence, eighteen months after the first module opened — was a moment about one deeply underrated professional trait: the ability to see a long thing through. I set it down in this note.

Long commitments are where most people fall off

Short bursts of intensity are common. Sustained commitment across many months, especially alongside everything else demanding your attention, is rare — and it's exactly what meaningful work requires. The interesting parts of a long program are the start and the end; the middle is just showing up, repeatedly, when novelty has worn off and no one is watching.

Reaching the convocation for an eighteen-month AI major wasn't a single achievement so much as the sum of a hundred unremarkable days of continuing. That's the part worth respecting: not the ceremony, but the consistency that earned it.

What seeing a long thing through teaches

Consistency outperforms intensity. A steady standard held over eighteen months beats bursts of effort that don't last. Careers are built on the former.
The middle is the real test. Anyone can be motivated at the beginning and the end. The professional trait that matters is continuing through the unglamorous middle.
Completion compounds credibility. Finishing a long, demanding commitment is evidence — to yourself and others — that you can be trusted with the next one.

The takeaway

The convocation marked eighteen months of not stopping. I've come to believe that the capacity to sustain a commitment over a long horizon — to keep a standard through the quiet middle stretch — is one of the most valuable and least visible professional traits there is. It's what turns intention into a track record.

The full note, taken outside the hall that day, is on the page below.

👉 Read it: www.divyakush.com/insights/iit-ropar-convocation

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

End-to-end ownership is a different discipline from building a part

Divyakush Punjabi — Sun, 23 Aug 2026 18:48:08 +0000

Being shortlisted out of more than 400 teams at Smart India Hackathon 2025 came down to one thing more than any other: owning a system end to end. Not a component, not a slice — the whole architecture of an AI and IoT rockfall early-warning system, from the sensors in the field to the model to the alert. I wrote about what that scale of ownership taught me in this reflection.

End-to-end ownership is a different discipline

There's a large gap between building a part well and being responsible for a whole system working. When you own the architecture end to end, no interface is someone else's problem — the sensors, the data pipeline, the model, and the way a warning finally reaches a human all have to fit together, and every seam between them is yours.

Architecting the rockfall system across AI and IoT meant thinking about the entire chain: how noisy field data becomes a trustworthy signal, how the model's output becomes an actionable alert, how the pieces hold together under real conditions. Standing out among 400+ teams wasn't about one clever part — it was about the whole thing cohering.

What owning a full system teaches

The seams are the system. Individual components are the easy part; making them integrate reliably across two very different domains — machine learning and physical hardware — is where the real engineering lives.
You design for the whole outcome. End-to-end ownership forces you to keep the actual goal in view — an early warning someone can act on — rather than optimizing a piece in isolation.
National selection rewards coherence. Being shortlisted at that scale reflects a system that works as a whole, which is a higher bar than any single impressive module.

The takeaway

Architecting a system end to end, across AI and IoT, taught me to think in whole outcomes and to treat the integration between parts as the core of the work rather than an afterthought. That systems-level ownership — being accountable for the entire chain, not a link in it — is exactly the capability serious engineering organizations are built around.

The full account of the system and the selection is on the page below.

👉 Read it: www.divyakush.com/insights/smart-india-hack

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

Finishing is a skill, and it is rarer than starting

Divyakush Punjabi — Sun, 23 Aug 2026 18:42:36 +0000

There's a half of engineering nobody photographs: the hour every deliverable is finally filed, every document is complete, and the unglamorous work of finishing is actually done. It's not the demo or the award — it's the closeout. I marked that exact hour for my FPGA hardware project in this note, because that quiet moment is where a lot of real professional value lives.

Finishing is a skill, and it's rarer than starting

Starting is easy and exciting. Finishing — filing every deliverable, closing every loose end, meeting every requirement of a submission down to the last item — is neither, which is exactly why it separates people. Plenty of promising work never gets fully delivered because the last, tedious ten percent is where energy runs out.

The hour the submissions went in wasn't glamorous, but it represented something professional work runs on: follow-through. The discipline to take a project all the way to genuinely complete, not just "basically working," is one of the most reliable markers of someone you can trust with real responsibility.

What the closeout teaches

Done means done, including the paperwork. In any serious setting, a deliverable isn't complete until every requirement around it is met — documentation, formatting, the lot. Treating that as part of the work, not an afterthought, is professionalism.
The last ten percent is the test. Anyone can carry a project through the interesting middle. Carrying it through the boring, exacting end is where reliability is proven.
Quiet consistency compounds. The moments nobody photographs — the diligent closeouts — are what build a reputation over time, far more than the visible highlights.

The takeaway

I've learned to respect the unglamorous half of engineering as much as the visible half. Shipping isn't the moment of the demo; it's the moment every last deliverable is genuinely filed and the thing is complete. Being the person who reliably reaches that moment is worth more, professionally, than being the person with the flashiest start.

The full note, taken outside the lab that hour, is on the page below.

👉 Read it: www.divyakush.com/insights/submissions-closed

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

Hardware refuses to let you be sloppy — and that is a gift

Divyakush Punjabi — Sun, 23 Aug 2026 18:37:02 +0000

Hardware engineering is unforgiving in a way software often isn't — there's no hotfix after deployment, and timing is measured in nanoseconds you can't hand-wave away. Taking a Verilog traffic controller on FPGA from first-in-its-track at the IIC IdeaThon through to ElectroUtsav 2025 — with a sub-10-nanosecond emergency response — was a lesson in the precision that hardware demands and software forgives.

Hardware doesn't forgive imprecision

In software, "fast enough" is often a feeling. In hardware with a hard real-time requirement, it's a number you either meet or you don't. A sub-10-nanosecond emergency response isn't a nice-to-have benchmark; it's a specification the design has to honor at the level of the physical circuit, every cycle, deterministically.

That constraint changes how you engineer. You can't rely on averages or optimistic paths — you design for the guarantee. Being recognized first in track and carried through to ElectroUtsav 2025 came from treating that timing requirement as non-negotiable and building to it from the start, rather than hoping to optimize toward it later.

What hardware discipline teaches

Determinism over "usually." A real-time hardware system is judged on its worst case, not its typical one — which is a rigor worth importing into software too.
The specification is the contract. A number like sub-10ns is a promise the design makes to the world. Engineering becomes the work of keeping that promise under all conditions.
Recognition follows rigor. Placing first in track and advancing to a larger showcase wasn't about ambition on paper — it was the result of meeting an exacting requirement precisely.

The takeaway

Working in silicon taught me a standard of precision that has made me a more careful engineer everywhere, software included: define the guarantee, design for the worst case, and treat the specification as a contract rather than a target. Hardware simply refuses to let you be sloppy — and that's a gift.

The full account of the project and the recognition is on the page below.

👉 Read it: www.divyakush.com/insights/electroutsav

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

The first internship is where student becomes professional

Divyakush Punjabi — Sun, 23 Aug 2026 18:31:31 +0000

The gap between academic work and professional work is real, and you only feel it once you've crossed it. School optimizes for correct answers; industry optimizes for shipped outcomes alongside other people, on someone else's timeline, to someone else's standard. My first internship — four months of UI/UX and front-end work at LayOver — was where I first felt that shift, and I marked the moment it closed out in this reflection.

The first real engagement changes how you work

The first time your work has to hold up in a professional setting, a few things become concrete that were abstract before. Code isn't graded and forgotten — it's used, maintained, and depended on by teammates. "Done" stops meaning "it runs on my machine" and starts meaning "it's ready for other people to build on."

Four months of front-end and UI/UX work taught me that professionalism is largely about consistency and reliability: showing up to a standard every day, communicating clearly, and delivering work that fits into a larger whole rather than standing alone.

What the first professional engagement teaches

You're building for a team, not a grade. The measure of good work becomes whether it serves the people and product around it — which raises the bar on clarity and maintainability.
Craft and communication travel together. UI/UX work in particular made clear that building the thing and explaining the thinking behind it are two halves of the same job.
Reliability is the real reputation. In a professional setting, being someone whose work can be counted on matters more than any single impressive output.

The takeaway

The first internship is where the transition from student to professional actually happens — where you learn that engineering is a team sport played to a standard, not a solo exam. Closing out those four months of front-end and design work at LayOver was a small milestone, but the working habits it built are the durable part.

The full note, taken the evening it wrapped, is on the page below.

👉 Read it: www.divyakush.com/insights/first-internship

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

The room is the resource: what senior conversations teach you

Divyakush Punjabi — Sun, 23 Aug 2026 18:25:59 +0000

There's a specific kind of learning that only happens in a room with people far more senior than you — the kind you can't get from documentation or a course. A single conversation with the right people can compress years of perspective into an afternoon. On the exhibition floor of a major startup summit, I spent one with two presidents of TiE Surat, the man who conceived 21BY72, and a Vodafone India chief technology officer — an experience I set down in this note.

The room is the resource

We tend to think of learning as reading and building. But a large part of professional growth is proximity — being in rooms with people who operate at a level you're aiming for, and paying close attention. The calibre of the people around you sets the ceiling on what you absorb, and few things accelerate perspective like a real conversation with someone who has already done the thing.

Talking with a CTO and seasoned founders isn't about collecting names. It's about hearing how people at that altitude actually think — how they frame problems, weigh decisions, and judge what matters — which is exactly the tacit knowledge that never makes it into writing.

What senior conversations give you

Framing, not just facts. The value isn't a specific tip; it's watching how experienced leaders structure a problem before they solve it. That framing is transferable to almost anything.
A calibrated sense of scale. Hearing how someone runs technology or ventures at real scale resets your intuition for what "big" and "hard" actually mean.
Judgment by osmosis. Sit with people who've made a thousand decisions and you pick up the shape of good judgment — the thing that's hardest to teach directly.

The takeaway

I've come to treat access to high-calibre rooms as something to seek out deliberately, not stumble into. Learning technical skills is table stakes; learning how the best people think — by being near them and listening well — is the compounding advantage. One good conversation can move you further than a month of solo study.

The full account of that conversation is on the page below.

👉 Read it: www.divyakush.com/insights/summit-floor

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

Why engineers need commercial awareness, not just technical depth

Divyakush Punjabi — Sun, 23 Aug 2026 18:20:28 +0000

Engineers who only understand the technology, and never the business it serves, hit a ceiling early. The best ones develop commercial awareness — a real sense of how value is created, funded, and sold. Two days at 21BY72 Season 4, one of Bharat's leading startup summits — eighty-five ventures on the floor and live pitches in front of six hundred investors — was a concentrated lesson in exactly that, and I wrote about it in this reflection.

Technology is a means; the business is the point

It's easy, as an engineer, to treat the product as the whole world and the commercial side as someone else's problem. Sitting in a room where eighty-five ventures pitched to investors makes the truth obvious: the technology is a means to a business end, and understanding that end makes you a better engineer, not a distracted one.

Watching founders pitch — being judged not on how clever the build was but on whether it solved a real problem people would pay for — reframes how you think about your own work. It pushes you to ask "who is this for and why does it matter" before "how do I build it."

What the summit floor teaches an engineer

Investors buy problems solved, not features built. The pitches that landed were about a real need and a credible path to meeting it — a discipline that improves engineering priorities directly.
Commercial context sharpens technical decisions. When you understand the business constraints — cost, speed to market, who the customer actually is — you make better trade-offs in the architecture, not worse ones.
Exposure recalibrates ambition. Being around people building real ventures at scale resets your sense of what's possible and what "serious" looks like.

The takeaway

The most rounded engineers I've come to admire pair technical depth with genuine commercial awareness. Spending two days inside a major startup summit, watching how businesses are pitched, funded, and built, was a deliberate investment in the half of the picture that a pure engineering education tends to leave out.

The full account of the two days is on the page below.

👉 Read it: www.divyakush.com/insights/startup-summit

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

The most valuable professional skill is a system for continuous learning

Divyakush Punjabi — Sun, 23 Aug 2026 18:14:58 +0000

The half-life of technical knowledge keeps shrinking, and AI is the sharpest example. The most valuable professional habit isn't knowing today's tools — it's building a system for continuously learning the next ones. That conviction is why I took on an eighteen-month Major in Artificial Intelligence at IIT Ropar, run with NSDC and Masai, and read it in parallel with my core engineering degree rather than after it.

Depth on purpose, not by accident

It's easy to pick up AI in fragments — a course here, a tutorial there — and end up with a patchy, self-assembled understanding. I wanted the opposite: a structured, sustained, formal grounding in the field, long enough and rigorous enough to build real depth rather than familiarity.

Choosing an eighteen-month program is a deliberate bet that depth compounds. Fragmented learning gives you the ability to use a tool; formal depth gives you the ability to understand why it works, which is what lets you adapt when the tool changes — and in AI, it always changes.

Why parallel, not sequential

Parallel learning forces integration. Reading the AI major alongside the engineering core meant the two constantly informed each other, instead of sitting in separate mental boxes. Applied understanding beats sequential memorization.
It's a statement about time. Doing two demanding tracks at once is a commitment to using the window you have fully, rather than deferring the harder investment to "later."
It builds the muscle that actually matters. The specific models will date. The capacity to absorb a rigorous technical field while already carrying a full load — that's the durable, transferable skill.

The takeaway

The professionals who stay valuable over a career are the ones who treat learning as a permanent, structured part of the job, not a phase that ends with a degree. Committing to a formal AI major in parallel with my engineering core was my way of building that discipline early — depth on purpose, sustained over time.

The full context of the program is on the page below.

👉 Read it: www.divyakush.com/insights/iit-ropar-major

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

A hackathon is a compression test for how you actually work

Divyakush Punjabi — Sun, 23 Aug 2026 18:09:27 +0000

A hackathon is a compression test for how you work. Everything you'd normally have weeks for gets squeezed into a window measured in hours — scoping, building, integrating, presenting — and what survives that compression tells you a lot about an engineer. Leading SYNTAX TERMINATOR to the top 12 of more than 250 teams at GDSC DevJams 2024, with a voice-controlled home system built entirely inside that window, was one of the clearest lessons in execution under constraint I've had.

Constraint forces the right decisions

With unlimited time, you can afford to be indecisive — try everything, polish endlessly, avoid hard cuts. A hackathon removes that luxury, and that's precisely its value. When the clock is the dominant constraint, you're forced to answer the question that actually matters: what is the smallest thing that proves the idea works?

Ranking top 12 out of 250+ teams didn't come from building the most; it came from building the right slice and making it work reliably enough to demonstrate. Knowing what to leave out under time pressure is a more advanced skill than knowing what to put in.

What leading a build sprint teaches

Scope is the first deliverable. Before any code, the team has to agree on a target small enough to finish and meaningful enough to matter. Getting that boundary right up front decides everything downstream.
Integration is where hackathons are won or lost. Individually working parts mean nothing if they don't come together in time. You budget for integration deliberately, because it always takes longer than the optimistic estimate.
A working demo beats an ambitious idea. In the room, a smaller thing that actually runs outperforms a grander thing that half-works. Reliability under demonstration is its own discipline.

The takeaway

Delivering a functioning voice-controlled system inside a hackathon window taught me to work backward from the deadline, scope ruthlessly, and protect time for the integration that turns parts into a product. Those instincts — decisiveness, ruthless prioritization, delivery under pressure — are exactly what professional engineering rewards.

The full account of the build and the result is on the page below.

👉 Read it: www.divyakush.com/insights/devjams

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

Twelve people, four functions: what running a cross-functional team taught me

Divyakush Punjabi — Sun, 23 Aug 2026 18:03:55 +0000

Twelve people, four functions, one deadline. Running Visionary Ventures — the team that carried VIT Vellore to All India Rank 140 at the national entrepreneurship challenge — was, in hindsight, a lesson in the thing every large organization actually runs on: structure. Not talent alone, not effort alone, but how you organize talent and effort so twelve people pull in one direction. That's what the Visionary Ventures experience really taught me.

A team without structure is just a crowd

Put twelve capable people on a problem with no structure and you don't get twelve people's output — you get overlap, gaps, and quiet confusion about who owns what. The instinct is to think a strong team succeeds on raw ability. It doesn't. It succeeds when ability is organized into clear functions with clear ownership.

Splitting the team into four functions was the decision that made the rest work. Each function knew its remit; the seams between them were where I spent my attention as lead. That mirrors exactly how real companies scale — not by hiring smarter people, but by defining who owns what so the smart people don't collide.

What running a cross-functional team taught me

Ownership beats supervision. People do their best work when a function is genuinely theirs to own, not when they're waiting to be told the next step. The lead's job is to set direction and then get out of the way.
The interfaces are where things break. Within a function, work flows. Between functions is where dropped handoffs and misaligned assumptions live — so that's where coordination has to be deliberate.
Alignment is a continuous job, not a kickoff. Twelve people drift. Keeping a shared picture of the goal current, as circumstances change, is most of what leading actually is.

The takeaway

I came away understanding that organizing a team is itself an engineering discipline — defining boundaries, assigning ownership, and managing the interfaces between people the same way you'd manage the interfaces between modules in a system. It's a skill that matters more, not less, as the teams and the stakes get bigger.

The full story of the team and the result is on the page below.

👉 Read it: www.divyakush.com/insights/nec-visionary-ventures

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub

Leading a team to a national ranking taught me more than any codebase

Divyakush Punjabi — Sun, 23 Aug 2026 17:58:24 +0000

Representing an institution on a national stage is a different kind of engineering problem — the system you're building is a team, under pressure, against the clock, in front of people who evaluate for a living. Leading Visionary Ventures as the only team to carry VIT Vellore into E-Cell, IIT Bombay's National Entrepreneurship Challenge — to an All India Rank of 140 — taught me more about execution than most technical projects have.

A national result is a team result

It's tempting to remember competitions as individual achievements. They aren't. An All India Rank comes out of a group of people staying aligned over weeks — dividing work sensibly, covering each other's gaps, and holding a shared standard when it would be easier to let things slide. The technical idea is maybe a quarter of it. The rest is coordination.

Being the team lead meant my real job wasn't to do the most work; it was to make sure twelve people's work added up to something coherent. That's a skill that transfers directly to any serious engineering organization: the output that matters is the team's, not any one contributor's.

What a competitive national stage teaches

Standards are set by the room. Competing at a national level against the country's strongest teams recalibrates what "good" means — you stop grading yourself against your immediate surroundings and start measuring against the best.
Deadlines are non-negotiable, so plan backward from them. A competition doesn't move for you. That forces the discipline of scoping to what can actually be delivered, and cutting cleanly what can't.
Representation raises the bar. Being the only team from an institution means the work carries more than your own name — and that responsibility is a genuine forcing function for quality.

The takeaway

The experiences that shaped how I work professionally weren't only the ones where I wrote the most code. Leading a cross-functional team to a national ranking taught me execution, coordination, and how to hold a standard under real pressure — the parts of engineering that don't show up in a repository but decide whether anything ships.

The full context of the challenge and the team is on the page below.

👉 Read it: www.divyakush.com/insights/nec-iit-bombay

Divyakush Punjabi — Full-Stack & AI Systems Engineer

🌐 https://www.divyakush.com · 💼 LinkedIn · 💻 GitHub