Hello and welcome! My name is Abdur-Rahman Ayyaz Qureshi and I am a first year student enrolled in the Engineering Science program at the University of Toronto. I am currently 18 years old and I go by the name ‘Rahman,’ or ‘Ray’ (but preferably ‘Rahman’)! This website is an Engineering Design Portfolio I am required to write for Praxis (my design course) but intend to show to potential employers.
This website will have three sections: professional statement, engineering design process, and design experiences. The professional statement will be an introduction of sorts. It will highlight my core design achievements, list of areas of strength and list my areas of weakness. The engineering design process will contain my definition of engineering design and a detailed description of the methodology I have adopted when confronted with design challenges. Finally, the design experiences section will contain descriptions and images of design experiences of which I am most proud.
The Importance of Praxis and Design
I wrote the segment below approximately half a semester ago. I believe it is very important and I hope it will be inspiring to any future engineering science students or any person in general who happens to be reading my blog.
I begin my Engineering Design Portfolio with a resounding passion and burst of excitement such that I only fear that it will escape too quickly and hope that it will last through the year.
Indeed, it was never this way and I admittedly slacked quite a lot with regards to this assignment due to the nature of my attitude. I held a very condescending outlook on the nature of Praxis and its importance with respect to what I then defined to be “real” courses. But a certain event triggered a new perspective. Namely, it was when I sat down to write the resume I would eventually be submitting to Google.
I thought resume writing would be a simple affair; write out what you can do and make it sound modest and professional. I wrote out a “Technical Skills” heading and filled it with everything I’ve had experience with and knew how to do. As relatively impressive as it was, two things stuck out; it barely filled a fifth of a page and there were a lot of people whose technical skills and experience far outmatched mine. Why should Google hire a first-year over a second, third or fourth? If experience and knowledge was all there was to this game, I was in way over my head.
But at the same time, any API, any syntax, any programming concept or programming language can be taught in a few days. In this respect, the difference between me and even a fourth year, the difference of four years, is very petty to a company that serves hundreds of millions while implementing massively scaled system that may run for decades. I can impress the layman by saying I know C++ but definitely not a Google Software Engineer. Google is not looking for someone that can hack together code in a certain language or someone with a certain set of superficial skills just so that they will not have to spend time and money to teach them. They want someone with a good design philosophy. They want people that can design for scalability, design for repair, and design for simplicity. After all, the cost of debugging, repair and maintenance of bad code far outweighs the cost of teaching semantics of a language. Google is looking for someone who can design good programs because they are in it for the long run.
In this respect, you have to be able to sell yourself as a promising investment as a designer; a quality which is not so easily attained and naturally exists only in a few. As I sat to write my resume, I realized that I was at a loss. I truly had only a vague idea about what truly was this thing called “engineering design.” My mind was only alit with buzz words such as “elegance, problems, solutions, creativity and simplicity” but I could not pin down what I found most important. I found that the more I thought the more emphasis would change from economy to safety to usability and back again. Often as I imagined scenarios, my definition would change and I was unable to find an underlying abstraction that fit the pieces together.
This was exactly the thought process I followed as I stared at my empty resume and I realized that each and every single one of these concepts actually came up in Praxis. Honestly, my mind was blown. My most important course was the one I had foolishly been neglecting. Praxis made me think a lot about what I truly valued, but the passage of time wore down those ideas and now I only look back with regret that I did not seriously consider them and record those thoughts.
During my first semester of Praxis I had the opportunity to learn, develop and apply a personal engineering design process. The second biggest I developed in Praxis was research, observatory and reflective skills which streamlined my learning process. With my new learning and design processes I tackled design challenges thrown at me like the CIV102 Bridge project and personal and classroom software projects as well as reflect on past design experiences with a new light.
My biggest design achievements are a program visually depicting binary search, an 3-D RGB LED Cube I built in grade 12 and the Praxis “splash-proof bowl” Concept Design project. I chose these projects because they speak the most to what I believe good design is in very unique ways. I discuss them at length under ‘design accomplishments’ but in summary, the program showcases my software design principles, the RGB LED cube is a symbol of ‘bad design’ and how it directly stemmed from a lack of formal process and the Praxis design concept is a symbol for my current design process.
My greatest strength is creative and broad thinking. I can think of new, bizarre and often completely impractical solutions to problems. The broad component is being able to ‘step-back’ and look at wider pictures by reframing and by moving up multiple levels to draw knowledge from various fields and resources. My other great strength is being able to analyze solutions for flaws from the perspective of the end user. I am great at looking at designs from all angles and finding the ‘corner-cases’ from this end-user perspective; but this is a double edged sword.
My weakness lies in my inability to create a comprehensive list of stakeholders. Lying in my inability to understand who my design affects is the neglecting of other considerations. This is the area I must improve. I have a natural ability to critique and analyze from a given perspective, but I do not intuitively do it from every perspective. I do not consider every stakeholder and this limits my capacity to critique and analyze a solution to its fullest and therefore progress toward the best design.