devmorgan.com

So. In an attempt to keep myself occupied today during layovers and waiting in the airport, I’ll write about my graduation.

Why not, right?

So, I graduated… again. Of course, in true style, I still am not actually done with my grad degree. I still have a couple independent studies ahead of me and my capstone project. Alas this is nothing new, as I also “graduated” my undergrad degree early as well.

Anyway, I hate graduations. Why? Let me count the ways:

1. You have to say goodbye to friends.
2. You (usually) have to move.
3. You have to start thinking about the future.

Saying goodbye is never fun. A friend of mine wrote a note in facebook, asking the question: “Who would willingly spend several years of their life building a new group of friends and family in a place far away from home, and then at the end of those years, leave?” It’s a good question. I know the chances of seeing a lot of the people I saw every day ever again is quite low. Now it’s easier than ever to keep in touch, but like my old roommate, sometimes communication completely breaks down. It’s a damn shame, but it’s apart of life.

Moving sucks. Lets put that out there right now. In the past 2 years, I’ve moved six times. Six. Friggin. Times. Moving gives you some time to be nostalgic, going through the stuff in your life as you pack it all up. This time while packing up, I was remembering the parties and fun that had happened at the apartment… something that will not likely occur again to the same scope or scale. Oh well.

Now, I know we are supposed to think about our futures before we are walking across the stage for graduation, but once you shake the hands - its official (almost), you have to get a real job. I know in the fall I will be going back to StormFrog, but it’s always scary thinking about where you want to end up. Do I really want to be a code monkey all my life? Do I want to become more ‘business-y’ even if it means more money? Do I still want to end up in Boston? Who knows.

Well. Flight is about ready to board. Maybe I’ll write more or draw a comic on a layover.

High quality art this time. Clearly.

Of course, I could have spent the time I spent on this, ya know, doing real work. Thanks RIT for the inspiration for this comic. Actually, I would have been much better off without this inspiration I suppose.

Alright, here comes a rant. Sorry about this, but tutoring a student in PHP is painful. In fact, it’s not just PHP, but I am using PHP as an example.

Don’t get me wrong, I love PHP, but there is a single reason why tutoring people in it is so hard. The people.

People can need help with various technologies, and that’s fine. In fact, I really adore helping someone that knows how to program with a small problem. The problem with PHP is, most of the people that require assistance, don’t know how to program.

Setting people up for failure

PHP is used in the multimedia / web realm here at RIT. Sure, it’s used in database as well, but I rarely get asked for assistance from database students on how to use PHP, and when I do, it is more of a technical issue. The problem is, most students that focus in multimedia / web are not programmers. In the Information Technology program at RIT, you are required to take 3 courses in Java. Once you complete these courses, it is relatively easy to avoid programming in most of your courses for the rest of your tenure here. Students that did poorly in Java tend to go towards multimedia / web because it is easy. You can get away with almost no programming (writing HTML is not programming), and you are not forced to push yourself constantly when it comes to programming.

Enter PHP. As students hit the mid level courses, after trying to avoid programming for a long time, they have a new paradigm, stateless programming. Each time you post to a page, you lose all the data from the last page (unless you pass it along through POST or GET). Students struggle. Constantly, I have to work through basic programming concepts, and these frustrations are made worse by the lack of understanding of the state problem. Combine these weaknesses with a grasp of simple programming with the introduction of a database (which happens in some mid-level courses) only having phpMyAdmin as a guide, and students begin to drop like flies.

What is the problem?

Students pass the initial Java courses, and they are expected to be programmers. Unfortunately they aren’t. In fact, I know first hand that many students that finish the last course in Java couldn’t program anything remotely complicated if they were required to. Beyond this, with a weak foundation, they can not easily grasp another language. They never learned what makes a good programmer, and spend most of their time shotgunning their way through. Professors in later courses never cover the foundations again, and students get lost.

How do we solve it?

I suppose if I had a say, the Information Technology department would be much smaller. What it really comes down to is, students should be flunked in the early Java classes if they are not solid programmers. Yes, it’s a mean thing to say, but if you can not be solid at the core concepts, you are going to be struggling for the rest of your career. Programming is a major part of Information Technology. I will make a claim now that goes against what many of the “higher ups” in the department think, and what they would hate for me to say…

If you can not program, you will not be successful.

I admit, there are likely some people that couldn’t program their way out of a paper bag that are successful in the IT industry, but this is rare, and partly dependent on the definition of ’success’. Someone that gets a job isn’t necessarily successful (my definition may differ from others on this point). However, someone that can be innovative and inventive in the industry is what I would consider to be successful, and frankly, I can not see someone that can meet my criteria for success in IT without being at least a ‘decent’ programmer.

Whole rant aside, I want to make it clear that just because someone is in the IT program here at RIT, and focusing in multimedia / web, it doesn’t make them a slacker or bad at programming, because the concentration is, as with life, what you make of it.

This weekend I went to a concert here on campus, it featured Paramore and Jimmy Eat World. I am actually a fan of both bands, so I was very happy to go and see them. Overall the show was amazing, and it really made me think about the concept of energy.

Energy is exactly what myself and many of my classmates are going to need over the next couple weeks. As the quarter starts to come to an end, coursework and stress levels begin to rise. When I was at the concert, I was noticing two different kinds of energy coming from Paramore and Jimmy Eat World. Paramore’s energy clearly comes from their performance capability. Moving around on stage, feeling the music and looking the part. Jimmy Eat World’s energy was different. They had less of the charisma, but the energy came from the music. You could feel the energy with each beat, and they were able to sound the part. To be honest, at the end of the show, I felt energized. It made me feel like I can make it through the next few weeks. Kinda cliche, but it was a great feeling.

So, the real question is, how do you keep this energy? How does one make it through the stress of the end of the quarter, and even worse, the end of the last quarter. I have never really figured it out. I usually start burning out at the very end no matter what I try. I have had some good ideas to make it through the crunch time, but I think the best thing you can do is remember to relax. Replenish your energy when you can. If that means going out to a concert, do it. If it means having a few drinks with friends on Thursday night, do it. Making it through with a healthy mind is far more important than grades.

At least, that’s what I say now. Lets see if I am saying the same thing when week 10 rolls around, and I end up like last quarter, sick with the flu, having chills and barely being able to remain coherent, but still coding for a final project.

For the last several months, I have been a programming and database tutor here at RIT in the Information Technology department. I have seen many students come and go for help, with varying levels of skill and motivation when it comes to programming.

I hate to say it, but I usually find my self disappointed in some students. I have been trying to figure out why they struggle with programming so much, and I want to try to help them get past the roadblock they are having… I have determined that one of the biggest roadblocks that students run into is having a profound lack of attention to detail and no patience.

Many times I get asked a question that could really be answered if someone just took some time to look at the code in detail, or think through a concept fully. I believe that people are fully capable of logical thought, so just taking some time is all that is really needed.

Step 1: Determine the problem you are trying to solve.

Even at the low academic level, you are programming for a reason. Before being able to code anything of value, you need to be able to abstract the fundamental essence of what it is you are trying to accomplish. If you are writing a program that will calculate area of shapes, that is one paradigm, another is connecting to a database. You must tune your brain to the frequency of the problem, and attack it from there.

Step 2: Develop a plan

Over the past few years, I have determined, I am not one to spend lots of time on design. In fact, I find that most design methodologies are too much overhead or too optimistic. I do however believe that you must always have a plan for what you are doing. A complex UML diagram is not needed, but a simple “WTF Napkin-gram” should usually suffice. Sure, part of this post is about detail, but the detail is most important in the code, not in the plan (this is my opinion… methodologists will wholeheartedly disagree).

Step 3: Code, and follow the plan

Here is where things start to go awry, and this is where I want to focus on a few key problems that I run in to.

People tend to write code blindly. You need to think about what you are writing. Every line should have purpose, and should be directly trying to accomplish the goals in your plan. Every line of code that you write that deviates from that plan is code that is considered ‘junk’. Look at the documentation for your language, and make sure you are not reinventing the wheel, but more importantly, understand what each function call you make does. Does it return a specialized object that behaves in a certain way? What are the bounds of your parameters? Take the time you need to make sure you understand each piece of what you write.

Focus on the error messages. A lot of the problems that I get asked to help with are (relatively) simple compile/syntax errors. Every language has some way that it can get these error messages to you, use them! This is where your attention to detail really comes in handy. You can look at a block of code and see things you might have missed, incomplete statements, and most common (but not always an error) incorrectly named variables. Make sure you understand the code you are touching, and be very explicit in fixing problems with it. Don’t shotgun debug, be precise about what you are trying to do,

Copying code is a bad idea… usually. This is one I am guilty of, in fact, most programmers are. There are several major flaws you need to worry about when you notice yourself copying code. The first problem is the most obvious, if you can copy code, there is a chance that the branch of code you are copying should be in a reusable function. Look at the code, see if you can abstract it to be a function call, and if so, do it! The second major problem with copying code is that its extremely easy to miss any changes you need to make to the code. For example, if you copy a few lines that are modifying variable xmlDoc, and you want the copied code to modify xslDoc, you might miss a change in going from xmlDoc to xslDoc. Happens all the time… so be careful. The third major point I want to touch on with copying code is this: I don’t recommend copying more then 3-5 lines of code at a time from another project. Be sure that you actually need the code you are copying. If you just grab an entire class file, you will likely need to change it enough that it might be a safer bet to just rewrite it… of course on that note…

Don’t reinvent the wheel. If code exists that does what you need, use it. In academia it is a little different, since we are trying to build up core concepts, but, in reality, if it has been done, you likely do not need to do it again. Many people could go on for hours about how important it is that programmers be lazy. I agree, programmers need to be lazy so they can see the way they can save time while coding, but remember that programmers also need to be proactive. You need to be able to spend time looking at documentation, and just playing with existing code to see what is already out there. Save yourself a headache later by taking some time to discover things now.

Program for programming’s sake. I guess this will be my last big point. A lot of people only code because they have to. Sure, this stuff isn’t for everyone, but if you want to be a good programmer, you need to do it a lot. Practice is how you begin to learn all the documentation, and all the tricks about a certain language (To Students: Yes, that is why I know where everything is in the javadocs). Really, the best thing I can recommend is to come up with a pet project, and do it. If it suits, trash the code and write it from scratch after you work out the initial kinks and know the problems you will run in to. The more you code, the better you will become.

These are only a FEW tips for becoming a good programmer. They are just some of the big issues that I see on a day to day basis with students here.

Yesterday I was fortunate enough to be able to attend BarCamp3 here at RIT. While I really do want to write a lot about how it went, I didn’t exactly take great notes. Here are the few things I really want to say:

jQuery is cool. Sure, I know everyone else already knew this, but now I am a believer. John Resig gave a nice presentation just demonstrating the basics of the library, and I was sold. I have already started working with it for my XML Transformation class’ web projects.

Discussion is cool. One of the best parts of BarCamp is just meeting up with a bunch of intelligent people, and having chats. My presentation time was used doing just that. I put up the topic of “Social Implications of Technology” and I got about 10 participants, ranging from college age to much older, and the discussion was GREAT. The chat bounced around a few central ideas, which included communication etiquette, hyperconnection, and personalized expectation of behavior. Really interesting stuff.

Meeting people is cool. I met a lot of people yesterday, and even got some business cards to maintain professional contact. Very exciting stuff. Of course, now I have an incredible urge to build my own personal brand so I can make personal business cards. We’ll see if that happens any time soon.

All in all, it was a very long day, but it was a lot of fun. Thanks to the organizers, and I look forward to attending next year.

So, I am pretty sure, if I was presented this exam right before I decided to come to grad school, I might have thought twice.

I find that every week or so I mentally take this test. Trying to balance all three becomes quite difficult.

Laughter Everywhere.

Some people may be satisfied with the yearly Google prank, but not us. The idea to pull off some kind of April Fools joke was discussed as far back as December. Of course, we didn’t plan much, but I think it has turned out great… so… here is how it all went down:

Coming up with names for as many professors as possible was really hard. We should have thought about it more then we did, but with three of us, we came up with about 90% of the target names. Professors we had no experience with were generally left out because we didn’t know much about them, or what they would find ‘funny’. Names ranged all over the place, from simple nicknames and titles like “Resident Hippie | Weez” to “Minivan Driver | Humpty Dumpty”. Overall, the names took about 3 hours to come up with, but I think it was worth it.

The next step was putting the signs up. Mike, Zack and I walked around the floor and started putting the signs up. We only ended up having to reprint 2 signs due to typos… that we noticed. Putting the signs up was actually a lot of fun because we started to really see the scope of what we were doing.

We finished about 1:30am, and headed home. Overall the entire process for the night took a little over 4 hours. Not to bad considering. The only downside was that we don’t usually come in until much later in the day, so for now the plan was for me to wake up early and come see the reactions…

I walked in to building 70 at about 9:15am. I headed up the stairs and started walking towards the grad lab- I mean the “I CAN HAZ TUTORING” room. I got about halfway down the hall, then I heard a voice saying “Yeah, they’ve all changed”. Immediately a smile came. It was going to be a success, I could just tell from the sound in the voice. I started walking around, and I would run in to the occasional professor walking around the halls looking at all the signs. All smiling. Giggles here and there.

Some of the professors immediately could tell I was partially behind it, I mean, why else would I be in 70 before noon… carrying a camera and snickering? I walked back to my lab, waiting patiently for Deb to see her new sign. A few seconds later, I hear her laugh from around the corner. Got her! I walk down the hall to see her facial reaction. She knew it was me right away. I look down the hall and I start to see something I didn’t expect… people taking pictures. First I saw Dr. Kang taking a picture of his sign, then I saw a student walking down taking pictures as well.

What a great success!

Even as I write this blog entry, I can hear laughter as people walk by. Every now and then a good chuckle. The best part, is laughter lifts the spirits. I am happy to be here today, and everyone that is doing their walk around the building is smiling and giggling. I wonder how long everyone will keep their signs up? :).

Thanks to Zack Panitzke and Mike Galey for helping make this prank possible. You guys rock.

P.S. To any professors that might read this, Mike is up for a GA position next year — you should support him!

To learn more about why this comic was drawn, look at RIT’s new policy regarding professors.

Alright. Finally I drew another comic. The quality is down, but intentionally… since I think drawing non-stick figure penises may be considered inappropriate.

Overall this comic is a critique of the current situation here at RIT about the push to become a more research oriented university and the decision that Ph. D’s are required for professors here.

I promise my next comic won’t be stick figures, but I can’t guarantee no penises ;)

Recently here at RIT, there has been a discussion (read: controversy) about a new “requirement” (not actually policy) that professors are required to have a “Terminal Degree” to get a promotion. Several professors that are currently in the pipeline for promotion risk being passed up because of this new decision. This decision is against my interpretation of the real policy. The policy itself is fairly lengthy, but I think it is best described by this paragraph:

The view that teaching is the foremost activity of the RIT faculty is deeply rooted in the traditions of the institution, and the primacy of teaching continues to be a hallmark of RIT. Consequently, the basic consideration, both in initial appointments and matters pertaining to salary adjustments, promotion and tenure, is the extent to which high standards of teaching can be achieved and maintained.

Which mentions nothing about terminal degree. Basically, for a promotion, a professor needs to be a Good Professor. To me, a Good Professor needs expertise, the ability to do good research, must be a good educator, and must have a passion for what they do.

What is expertise?
I find that expertise is one of those “fuzzy areas” that you can’t define easily, but you can determine after knowing someone for only a little while. Expertise is the having of significant knowledge in your topic area. Unfortunately, in academia this significant knowledge can only be expressed in the form of a piece of paper that says Ph.D on it. The most recent statement by the current RIT administration says that if you have many years of industry experience, that it is enough to be qualified as an “expert” as well, but I believe that has only recently come to the current administration’s mind because of the push back from students and professors on the recent “terminal degree” decision. Personally, the expertise of someone should be measured by the people that work him or her every day. Even for students, it’s easy to find out which professors “knows their stuff” pretty quickly in their time here.

What is the ability to do good research?
In the academic world, research is kind of the “my house is bigger then your house” debate. Professors with the most published papers and articles are highly regarded. Ok, fair enough. I am not one to change the way the academic world works. So, when evaluating professors for promotion and tenure, look at their research. It is very clear that this was not considered for the pipeline of the current professors (as some have many published articles, in several prestigious journals), but it should be a consideration overall. With the drive here at RIT to become an innovation university, of course research needs to be done… We just need to remember that academic research is only so good, and that applied research is what will actually cause innovation.

What makes a good educator?
The age old question of every student: Is Professor X any good? Students care about this… a lot. Here at RIT, it’s not that hard to figure out which professors are the good ones: look at the course evaluations. A professor that has good evaluations usually ends up being pretty good. It’s possible to see the signs of a good educator just by sitting in the classroom for a few classes: Look for professors that are actively trying to incorporate different teaching methods to reach more students. Look for professors that encourage questions, and answer them well. Look for professors that have their class fill up immediately. Look for professors that can connect with students to solidify concepts and ideas.

What is passion?
Passion is the most important thing that a professor can have. Passion is the drive and the emotion that gives a professor credibility in the eyes of the students. The professor cares about what he or she teaches, and can show that passion to spark student interest and allow them to develop that passion themselves. Passion is hard to quantify, but it can be found easily. A person that has a passion for what they are doing or teaching has a certain presence and charisma about them that can be picked up by everyone in the room. They truly care about the material and the ideas that they are involved with. I challenge anyone to think of someone who they consider their “best professor” or “best teacher” that didn’t have passion.

What will happen here at RIT? I’m not sure. The professors in the pipeline may or may not get passed up for promotion. Currently, the administration is “reevaluating” the situation, while waiting on input from the various deans. The administration seems to be hard lining to make RIT a “World Renowned” university by increasing the amount of research that happens here. While I would love to see RIT become even more famous, I would hate to see RIT lose what it already is, one of the best teaching institutions in the nation. When I came here, it wasn’t the number of Ph.D’s that attracted me, it was that I was going to learn how to do what I wanted to do… and do it well.