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.
Today was the day. May 3rd, 2008. RIT would open it’s doors to the community, and then some, to show off over 400 exhibits and presentations about what makes RIT an “innovation university”.
Sure. I like the concept. Lets get a lot of people to campus and show off all of our cool stuff. Show that while we are immensely technical and artistic, we can learn how to combined the two. RIT has something that more ‘prestigious’ universities such as Yale, MIT, or Harvard will never have… practicality. Students here are well trained (at least in the fields I am closest with) in how to make things happen. We have the theoretical background, but we don’t spend so much time in it that it takes away from the practical application. This is where me and President Destler disagree with how the university should be going, but I really do believe the idea behind Imagine RIT is a good one. Lets show off what we can do.
Now ideas are one thing, implementation is always something very different (again, another practical versus theoretical argument). I really do believe RIT did the best we could to make this event go awesome, but I’ll be honest, I only saw one or two things today that really made me go “wow. this is cool.” Sure, I didn’t see everything, in fact I was very upset that I missed out a fairly large portion of presentations, including missing Dan’s booth about The College Blog Network, but there still wasn’t much that was amazing with what I did see.
Maybe I am just the wrong demographic? Maybe since I get to see all the interesting technical things anyway, they aren’t that exciting to me? It’s possible. I do think that Imagine RIT is a good thing for RIT, but I don’t believe that it is something that is going to be as big as they want it to be… at least not yet.
So, I guess overall, I commend RIT for attempting to do something that will make us ‘prestigious’ and have us become the ‘innovation university’ that President Destler longs for us to be, but I don’t think today was really worth all the money and the resources that I know were poured into 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.
Not going to lie, I can’t believe I am even posting this horribly geeky joke.
Yeah. I went there. Thanks Matthew and Dan for the inspiration to do a binary joke.
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.
I find that I don’t ask myself this question enough.
No, I am not getting myself into any bad situations, but I think every now and then you should try to step back and examine where you are in life. What decisions do you make that put you on the path that you are currently following. I tend to hope that nothing I do now will ever put me on such a poor path that I regret it, but you never know for sure.
I could go on and on about how one can examine life, and choose the ‘moral’ routes, or the ‘right’ routes. I can go on about how some people use religion as their guide, and others use the community that they are in. Really, that only thing that I feel is important is that you can step outside of yourself and take a look, ask yourself “What the hell am I getting myself in to?”, and answer truthfully. If you are happy with your answer, then the path you are on will be the right one.
Trust me.
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!
