This is the story of how I found my way into software engineering.
I did not start with a plan to become a software engineer. I kept following whatever allowed me to build more interesting things. Graphic design led me to websites. Websites led me to small systems built with PHP and Laravel. University pulled me into robotics, and all of that eventually helped me get my first software engineering job.
Looking back, curiosity made most of those decisions before I understood where they were taking me.
Around 2010, while I was still in school, I started exploring graphic design. I also discovered oDesk, which later became Upwork, and the idea that people would pay someone online to create things for them.
I would not call myself a great graphic designer. I was probably above average at best. But I loved learning new tools, trying new styles, and seeing myself improve. At that age, becoming slightly better at something every few days was enough to keep me interested.
Graphic design gave me a way to create things people could see. But after a while, static designs were no longer enough.
That was when I discovered web development.
HTML and CSS felt immediately rewarding. I could write something, open it in a browser, and see the result. I could take a design that existed only in my head and turn it into a page that anyone could visit.
Then JavaScript made those pages react.
A button could do something. A section could appear or disappear. A page could change without being completely reloaded. I was no longer only designing what people saw. I was controlling how they interacted with it.
That difference fascinated me.
The moment I understood Facebook
Then I found PHP.
Learning PHP changed the way I understood the web. Until then, most of my attention was on what appeared inside the browser. PHP showed me that there was another side to every application.
Data could be stored in a database. A user could log in. Different people could see different information. Forms could send data somewhere, and that data could come back later.
For a brief period, learning PHP gave me the confidence that I finally understood how Facebook worked.
Facebook was still relatively young, and with my limited knowledge, the whole thing suddenly seemed simple. There was some PHP, a database, user accounts, and pages that displayed different content depending on who was logged in.
Mystery solved.
Obviously, I had no idea how Facebook actually worked. But that confidence was useful. It made large applications feel possible instead of magical.
Then came Laravel.
Laravel gave structure to many things I had been learning separately. Routes, controllers, models, validation, authentication, and databases started fitting together. I was no longer thinking only about individual pages or scripts.
I could imagine building complete applications.
Every new technology created the same feeling: now I can build anything I want.
That feeling was rarely accurate, but it kept pulling me forward.
Learning from clients
While exploring web development, I was also working with clients as a freelancer.
Freelancing taught me things that tutorials could not.
A tutorial usually gives you a clear problem and a clean solution. Client work is rarely that simple. A client may ask for one thing while actually needing something else. They may describe a feature without fully understanding the problem they are trying to solve.
I enjoyed trying to understand what was happening inside the client’s mind.
Why did they want this feature? Who would use it? How would it help their business? What would happen after I delivered it? Was the feature they requested actually the best solution?
I was never interested in receiving a requirement, writing the code, collecting the payment, and moving on without thinking about the result.
The business side interested me as much as the implementation.
At that time, I did not know terms such as product thinking or user-centered design. I simply understood that working software was not automatically useful software.
A page could look good and still confuse the user. A feature could work perfectly and still solve the wrong problem. A technically clever solution could be a poor business decision.
Freelancing slowly taught me to think beyond the code.
Discovering Java
I joined university in 2014, and that was where I encountered Java properly for the first time.
My reaction was simple: this is heaven.
PHP had made me feel that I could build websites. Java made me feel that I could build anything.
Classes, objects, inheritance, interfaces, and the general structure of the language felt powerful. Software no longer looked like a collection of pages connected to a database. It could be organized into larger concepts and responsibilities.
Once again, I had the confidence of someone who had learned a small part of a very large subject and immediately assumed the rest would be manageable.
This became a pattern in my life.
Every new technology made me feel more capable. It also revealed another layer I did not understand.
Learning HTML led me to JavaScript. JavaScript led me to backend development. PHP led me to frameworks. Frameworks led me to application structure. Java led me to object-oriented design.
Every answer created several new questions.
I did not find that frustrating. I loved it.
A socially approved addiction
By the middle of university, I had started to realize that my limited knowledge of PHP, Laravel, Java, or Python was not enough to build everything I imagined.
But I did not spend much time worrying about it because I had developed another addiction.
Fortunately, it was a socially approved addiction.
It was robotics.
I was constantly building things, breaking them, fixing them, and then building something more complicated. I worked on projects for senior students. I taught robotics. I joined national and international competitions.
Eventually, I became involved in autonomous underwater robotics through BRACU Duburi.
Robotics was perfect for my brain because there was always another problem.
If the software worked, the electronics might fail. If the electronics worked, the mechanical system might behave differently from the design. If everything worked on a table, it could stop working during the real test.
A web application usually fails inside the computer. A robot can fail because of code, wiring, power, communication, movement, water, pressure, or a loose connection that nobody noticed.
That uncertainty made robotics frustrating, but it also made it difficult to stop.
There was always something new to learn.
Robotics also changed how I handled problems. I became more comfortable starting without knowing the full answer. I learned to test assumptions, observe what happened, make adjustments, and try again.
More importantly, I developed the belief that even when I did not know how to build something, I could probably learn.
That belief stayed with me.
I could make things work
By the end of university, I had worked with different programming languages, built applications for clients, taught other people, participated in competitions, and worked on complicated robotics systems.
I had developed a dangerous amount of confidence.
I felt that I could make almost anything.
Maybe I did not know how to do it yet. Maybe it would take weeks of reading documentation, experimenting, and failing. But I believed I could eventually make it work.
At the same time, another realization had started bothering me.
I knew how to build things, but I did not understand how large software systems were built.
I did not know how companies maintained codebases that had existed for years. I did not understand how hundreds of engineers could work on the same product without constantly creating chaos.
I could write classes and functions, but I was beginning to ask harder questions.
How should responsibilities be divided? Which part of a system should know about another part? How could one feature change without breaking five others? How did teams decide where one module ended and another began?
I was already becoming curious about low-level design and high-level design, although I did not know those terms yet.
Until that point, most of my learning had been about making things possible.
The next stage of my career would be about making software understandable, maintainable, and safe to change.
Learning to code had made me believe I could build anything.
I was about to learn that making something work was only the beginning.