Teaching an IT class (JavaScript, XML, C#, VB, CMS/PHP)

I've taught part-time at SAIT for 11 years now.  I've had more than 30 different classes with 5 different courses.  Recently I've been challenged by a colleague (also a part-time teacher here at SAIT) to make my courses better and more interactive.  While I thought my courses were pretty interactive to begin with, his ideas have definitely pushed me further in a good way.

All the courses I've taught have been introduction to different code languages or working with code:
Visual Basic, C#, XML, Javascript, PHP, and Content Management Systems like WordPress and Drupal.  Up until recently, my courses had been - at a high level - structured as follows:  I demonstrate a new concept/code idea to the class and I have them follow along.  Once they are reasonably comfortable with implementing it (perhaps an exercise or two of following along like this) I give them an exercise that they have to try and do themselves.  Sometimes I'll add a twist to make them think a bit.  For the most part this has worked great.  Its looked like this (an example with XML):

• Intro to the Language and syntax - I'll go through several power point slides that discuss: 
• What does well formed XML mean?  
• How do you ensure your XML is well formed?  
• What are the keys/rules to well formed XML? 
• I'll ask the class questions as we go along and get them to answer.
• We'll code a simple XML file together.  I'll make intentional mistakes along the way and see if the class is paying attention, or just call them out and ask 'Do you think this is right?'  I will also put comments in my code so the students can refer to them later.  Once done, I'll give this complete exercise to the students so they have it to refer to.
• Then I'll give them an XML file that is not well-formed (completely broken) and get them to try and fix it.  
• After about 15 minutes, I'll try and fix it myself in front of them, getting them to help me.
• Once that's done with my comments, I'll again put it in a shared folder for the students to grab so they can refer to it later.
• I'll give them another broken XML file and get them to fix it. 
• Again, after about 15 minutes, I'll try and fix it myself in front of them, getting them to help me.
• Once that's done with my comments, I'll again put it in a shared folder for the students to grab so they can refer to it later.
• Then, next concept.... and repeat.

This has worked quite well.  I've followed this process with all my courses and it seems to keep students engaged and helps them grasp new concepts.

As I mentioned earlier, I've been challenged by a colleague to make my courses better, even more collaborative, and (hopefully) gets the students more return on their tuition investment.  Here's what I'm changing and improving:

• Using a Repo.  Instead of using a shared folder to give files to students and have them turn in assignments, I'm using BitBucket with SourceTree (and forcing them to use it too).  This is great practice for them for the industry, and so far has worked really well.  My SourceTree client does get bogged down at times (with over 30 repositories) but it hasn't been a major deal.
• Commenting. I continue putting lots of comments in my code for the class to refer to.  They really like this and find it helpful when they review after class.  I'll definitely keep doing this
• Error Challenge.  I tend to fat-finger a bit when I'm coding in front of the class (even when I'm working off of a printed copy of a complete exercise).  Sometimes these errors are hard to catch and I waste some class time while I try and figure out what I did.  So instead of waste our collective time and to help them pay attention, I instituted a little game.  If a student catches an error I make in my code, they get a point.  Points accrue for the duration of the course.  The student at the end of the course with the most points gets a free Starbuck's gift card (or something like it).  This worked really well, and I'm definitely going to do it again.
• Student Journal. Student feedback is key for me.  I teach in 'Fast-Track' programs where the students know that they are going to get inundated hard and fast with new concepts all the time.  Ensuring I'm not bull-dozing them with new stuff is key, so having a feedback loop helps.  Up to this point I've just been asking them in class 'How's the speed - am I going to fast?'  But my colleague suggested getting the students to journal and having them  commit that to their repo so I can see it as another feedback loop.  I did this in my last course and it worked quite well.  I don't have them journal every day - just once a week or so, but the feedback I got from them individually was great. 
• Group Projects.  Out in the industry, most of these students are going to be working on teams, so having them do exercises in class as teams seems logical.  It turns out that students, for the most part, really like having group projects to work on.  They can collaborate together and learn from each other.  It also pushes them to compete a little which makes for an even better result.  I have them create a team repo for the project(s), and this also gives them experience with some BitBucket administration (branching and merging, etc.) which also prepares them for the industry.

Get Hired as an IT Newbie Part 2 - Soft Skills

I participated in a focus group this past week at SAIT where we discussed their 'Web Developer Fast-Track Program' and its relevance to the industry.  The goal behind the meeting was how can we make the course more relevant to the changes and continual evolution of technology that is happening in the industry so students are more prepared for positions when they leave.  The discussion was engaging and took some interesting turns.  Here's what I took away related to Soft Skills:

Soft Skills
Employers like student hires to be reasonably technically adept.  Their technical expectations aren't in the stratosphere.  However, they want their student hires to have more than just technical ability.  Students should be well versed in soft skills.

Soft skills is (to some degree I'm sure) an ambiguous subject for many students.  I can hear you thinking 'What do people mean when they say that??'  In the context of our discussion  yesterday,  it meant prospective IT employers in the focus group yesterday were looking for students to have, in addition to technical skills:

• An ability to communicate well with a client - verbally, directly in front of them or over the phone.  Also having the discernment to know when to send an email versus when to talk verbally.  Poorly written emails are notorious for communicating the wrong things - particularly negative feelings where there were none.
• An ability to know what good work is.  Does the design and function of a web site fit the purpose/company it was designed for?  For example, does a sales/marketing website have lots of good calls to action?  Does the site feel right?  Would 'Joe's Mom' know how to navigate and use the site.
• A can-do attitude.  Students will likely get the soul-crushing repetitive work that senior developers/designers don't want to do (or don't have time to do).  Students should accept this and be prepared to do it with gusto.  If you're in an interview and you don't have a clue about a technology they asked you about, reply: "I don't know about that, but I will know about it tomorrow" and mean it.
• An ability and desire to collaborate and work in a team setting.  Its a fact of the industry - if you want to work in an agency, you're going to need to be able to work on a team and collaborate with team members. 

Also discussed was: What habits should students have (or start to form if they don't have them)?

• Students coming out of school should love learning and know how to learn things/solve problems on their own.
• Students should be able to receive constructive criticism without responding with excuses about bad instructors, poor course material, or the speed at which things were taught.  You don't get much chance for excuses on the job.  Employers are looking to 'break even' economically on their student resource investment within 4 months.  

Get Hired as an IT Newbie Part 1 - Have a Good Portfolio!

I participated in a focus group this past week at SAIT where we discussed their 'Web Developer Fast Track Program' and its relevance to the industry.  The goal behind the meeting was how can we make the course more relevant to the changes and continual evolution of technology that is happening in the industry so students are more prepared for positions when they leave.  The discussion was engaging and took some interesting turns.  Here's what I took away related to portfolios:

Student Portfolios
15 years ago I had gone through a similar IT fast-track program and we had to do portfolios of our work for potential employers.  I wasn't aware of a single employer who looked at my portfolio and as
a result I haven't placed much emphasis on it in my classes.  BIG MISTAKE.

It turns out that prospective employers for SAIT students DO look at their online portfolios.... and generally weren't super impressed.  Here's why:

• Industry attendees said that a student's portfolio should reflect the position or career track that the students are looking to get into.  There should be evidence in the portfolio that the student tried on their own to investigate, explore, and work with technologies and code that interests them.  Posting student projects (with every student having very similar projects) doesn't help anyone in making a hiring decision.
• Prospective employers are not just interested in the technologies that students used, but also: 
• Thought processes that the students went through in completing their projects - why they chose to make certain decisions (for example, use a canned WordPress theme instead of design/develop their own)
• Challenges students encountered in design and development and how they overcame those problems in their journey to the completed project - Employers are interested in soft skills like perseverance,  the ability to google a problem and uncover a solution on your own, the ability to asking for help when you are stumped (not before you've tried googling the problem)... etc.
• Is the student willing to go the extra mile, put in some extra effort and explore interesting tools and technologies outside the classroom?  The industry was quite clear that this was one of the main things they were looking for  - a motivated individual with the right attitude.  This kind of motivation should be clearly seen in a student's portfolio.

There was also some suggestions during the focus group that students should be given the opportunity to provide constructive feedback to their peers on their portfolios.  A good critique is a gift.  Can students accept constructive feedback and use it to improve?  Could providing peer critiques give them a better perspective and more experience with what is good (design, code, functionality, etc.) versus what is not good.  We thought so.

Finally, here's a couple of links to student portfolios that 'make the grade' so to speak, in my humble opinion.  One was a student of mine this past semester, the other is a current student at the University of Calgary:

- Gary S. Jennings (former SAIT student)

- Carrie Mah (U of C student)

IT New Hire/Contract? Thoughts on IT On-Boarding

Being a contractor, I get to see and experience the on-boarding practice of different companies in different industries on a regular basis. This gives me an opportunity to provide a 'value-add' for the companies that I'm contracted with. Because of my fresh perspective, I can more easily pinpoint areas of opportunity for improvement in the first week on the job.

One thing that has always surprised me, and remained fairly consistent in all of the companies that I've worked with is that they don't seem to have the infrastructure ready for new hires.  I always seem to spend the first week doing one of the following:

• waiting for a computer or even a desk to sit at.
• waiting for access to my computer or to files, folders, applications, servers, etc.
• setting up/configuring my computer - installing required applications, setting up internal website bookmarks in browsers, etc.
• waiting for licenses for the applications I need to run to do my job.

I find this lack of organization dumbfounding.  HR knows that a new hire is getting on-boarded weeks in advance.  Similarly, the team/department should know as well.  I don't think there are any real good excuses for having new hires sit on their hands for the first week while everyone gets organized.  Bringing new hires on board should be a Standard Operating Procedure.

While I'm waiting for access or a license, I busy myself with looking for things that people with history at the company would view as the 'status-quo', but are really issues that could/should be considered problematic or improvable.

Opportunities like:

• Single Points of Failure.  (email server(s), monitoring server(s), shared drive(s), VPN access, etc)
• Lack of network segregation between environments (can I ping/telnet from a dev or staging server to production?)
• Misnamed or legacy names for servers or monitoring notifications that are understood by employees but a source of confusions for newbies
• Lack of templates for common documentation
• Lack of exportable outlook email rules that can be shared with the team
• Lack of exportable browser favorites that can be shared with the team
• Consolidating and organizing documentation (critical documentation in 12 different folders scattered through different directories is a recipe for confusion)
• Lack of Automation - continuous integration through to automating deployment.  Automating monitoring
• Preventing Fat-Finger errors (adding confirmation messages in start scripts)

Granted, not all of these will be applicable for every IT position.  Also, share your findings with your new supervisor and get his blessing before going and changing everything.  Suggest with encouragement, don't criticize! You don't to come across like your trying to relieve someone of their position.  You are there to make things better for everyone.

So, next time you are on-boarded for a new IT position, keep these things in mind.  Hopefully they can help both you and your new company.  Also, if anyone has some other suggestions of things to look for, please add a comment!

IT Professional - Know Thyself

What are you good at?  It pays to know - literally.  It will also make you happier and more productive on the job.

The more I work in IT, the more I see where I'm most effective. I also see in comparison where others blow past me in their individual skills.  It's important for multifunctional teams to have a good idea of different team member's areas of expertise.  Leveraging (knowing when and who to ask for a specific kind of help) these team skills can greatly improve the effectiveness of a team.

Here's some real life examples:

I'm rather weak on writing complex sql statements.  I can profile sql, and can get most sql work done.  But if I've got a difficult query I'm working on, I'll go ask my team mate who is an expert on putting together complex sql.  Later on, he'll ask me for help with a visual studio or server/service configuration related question.  Its a good, productive working relationship that keeps everyone happy.  The BA's are happy because the data looks right.  My PM is happy because my task was finished on time. And my team mate and I our happy because we both learned something and did it faster than trying to google for it on our own.

I'm great at problem solving software related issues - particularly in a domain I'm familiar with.  Whether it's missing permissions, configuration, network connectivity, everyone sitting around me will tell you I'm very, VERY persistent at solving problems that are brought to me.  My neighbor one cube west is fantastic at IIS/MSTDC/COM related bug/configuration debugging.   She also knows our software domain better than almost anyone else in the building - she seems to have it memorized.  When I have an issue with our software that I don't know how to fix, or a business related problem in the software,  I talk to her without hesitation.  Conversely, when she is stuck on an issue that she doesn't know how to solve, she will buzz it past me.  Again, a productive working relationship that makes everybody happy.  The business is happy they got their patch as fast as they did.  Once again our PM is happy, etc....

In meetings I will keep quiet and not say very much unless I feel there is an important point being missed.  I'm not super great at arguing a point.  I'm not the person that's always called on to go to a meeting to convince another group of people that 'our way is the right way'.  Part of this is my personality, part of it is my belief that there is multiple ways to get 'a good enough' answer for the problem we are looking to resolve.  However, we have another fellow in our group that will absolutely blow you away with his gift of logical persuasion.  He's the guy that gets sent to those 'convince the group' meetings.  On the other hand, I'm called on when diplomacy and a consensus is required.

Know what you are good at.  Seek to know what your team mate's strengths are.  Become a happier, more productive development team.

The importance of soft skills in IT

Soft skills are crucial to being a successful developer in the IT industry.  Some of the soft skills I've found beneficial in my career are:

• Being a good communicator.  It's not just about talking, but listening as well.  Dirareah of the mouth is never cool, especially when a job needs to get done.  Strive for mutual understanding in a conversation. Communicating in the IT world isn't just limited to talking and listening though.  
• Having the discernment to know when to write an email versus actually talking to a person is important as well. I do not recommend doing all your communication through email.  Communication in emails can easily be mis-understood or mis-construed and take on an entirely different meaning and tone than you originally intended.  Emails are great for documenting decisions.  
• Make sure that the content of your email deals with the subject you've put in  your subject line.  For example, having a subject line of 'Quote for project XYZ' but then talking about quotes for that project AND other projects in that email is bad news.  Send you quotes for the other projects in a different email with a more relevent subject line (I know this from experience).
• Developing relationships.  Extending communication a bit further and actually developing relationship with people in the office is huge as well.  Questions like "How was your vacation?", "Where are you going on vacation?", or "What did you do over the weekend?" are great for this. When you've got a relationship in place, there's trust.  Many times I've been granted exceptional privileges and become more productive in my work because I've had a relationship with a key person who trusts me.  These relationships can also help in the future as well when you are looking for that next gig.
• Having patience.  Whether it's letting somebody else go to the front of the 'line' for access to production, or having forbearance when dealing with a difficult client, patience can go a long way to strengthening that 'trust' in your relationships.  Sometimes work (or working with clients) in IT can get frustrating.  Things I do to help me step back and get some perspective are:

• go for a walk
• find something else to do for a while
• talk to someone - use them as a sounding board
• take a day off or go on vacation

• Positive Attitude. I like to keep my workplace fun, interesting, and upbeat.  To promote this around me I'll sometimes:
• Bring baking from home to share
• Audibly rejoice in small victories (getting a solution migrated and compiling from VS2005 to VS2010 for example)
• Write thank-you notes (either hard or soft copy) to others who help me
• Encourage people who are down. We had a large project I was helping with and the lead was concerned that between the time and the technical challenges he had, he wasn't going to be able to finish on time.  I believe he could and I told him so (and backed it up with my help).  In the end, he did finish.
• Being Flexible.  Generally, you are always working for a client.  Invariably, they will change their mind or want an enhancement.  Microsoft will upgrade their software, the US president will change daylight savings time one more time, the CTO will be convinced that Tibco will solve all the business problems again.  I've found that being able to take these changes in stride is crucial to maintaining my mental health (avoid being overcome with frustration).  It's all part of the territory - and frankly, job security.