Derek Logan Hancock
dhancock@purdue.edu
I think all of my experiences at Purdue have prepared me for important challenges that lie ahead in the workplace. Coming into Purdue University not having any programming experience and wanting to be a Computer Engineer seems strange. Before freshman year, the only programming feats I had accomplished came in the form of simple calculator programs to alleviate the repetitiveness of chemistry's periodic table. Learning to write a program in assembly was my first real taste of programming. Then jumping up to C showed me what I would write could be useful. Starting from assembly level, jumping into C, I would never include files I didn't need. I can write in assembly how to multiply two numbers together, than I do not need to import string to do simple string functions in C. When I write any program, now I know what I could should write myself and what made more sense to include. Moving outside of my old comfort zone of C, learning new languages got easier as I gathered more. Every language I learned not only added its knowledge to me, but improved upon other languages. Learning the finer parts of optimizing coding in C translates into other languages. While hardware and software separately and jointly comprise a lot of important information needed to complete different tasks, they are not the alpha and omega of being an engineer. I have many qualities that describe me. At the very least, I have very different thinking patterns. Many programs expose bugs to me that have not been found by other people. While working on TSCreator, a Java program designed for geologists, I managed to discover a long standing bug where you press a certain button followed by another button. My co-worker asks me why in the world I would press these two buttons in succession, and I could only respond it made sense to me in the GUI. I also manage to discover bugs in course software. A program written for the course behaved strangely. We were asked to comment out several lines, which a comment in that program was two dashes. I for some reason use three dashes which was alright because the comments applies to the whole line and there was not a way to escape the comments, so an extra dash should have just been part of the comment and not read by the compiler which up until this incidence held true. When the program falied to work, after removing the lines completely, everything was fine. I asked the TA and the professor, and apparently nobody had encountered such a problem. Organization is also a very important skill as a programmer. Working over the summer on TSCreater, one thing that I took away was more importantly than programming a GUI in an object oriented language, but organization in code is important. Even though I can read code thats disorganized, it is a huge time detriment, and makes it tough to update and impossible for others to read. Trying to update and fix code that someone wrote before I came to TSCreator who we could not ask what anything code was supposed to do. Senior Design where I would help design a system that measured airbag pressure and then would estimate a weight for semi-truck tailors for a wireless device showed me many of the skills that I have and will utilize in future projects. Designing a system for continued use that should be usable for people with minimal computer background came with many considerations. It was very obvious to me that in such design decisions that it was important for everyone to voice their opinion so we could be confident that we were making the best design decision we could so that the best I feel that this is an adequate description of myself and what is to be expected of me in the workplace while working for a company that where I can utilize my skills to the potential that I have myself applied to other projects as described here.
Back to ECE400 Spring 2012 Student Professional Statements
