Archive for July, 2012

There was a great question on Programmers about graduating with a programming degree, but not knowing how to program. I see this kind of question a lot, and I felt the same way when I first got my degree, so I thought I’d write about my experiences and what I learned when first started programming.

Start with baby steps

First off, don’t expect to be able to code enterprise-level applications or the next Facebook right away. You really can’t become a good programmer without a lot of practice, so practice any way you can. This can include hobby projects, reading books or source code, or even answering questions on Stack Overflow.

The book Outliers: The Story of Success frequently states that to become a master in any field you need to practice it for a total of 10,000 hours. In case you don’t want to do the math, that’s about 3.5 years of programming 8 hours every single day. If you only program during business hours at work, that’s almost 5 years.

Don’t discount your education

When I first started working, I felt my education was worthless; that it just taught me stuff that was never used in the workplace. I soon realized it provided me with something better than syntax: it provided me with a good foundation for programming. For example, it didn’t teach me design patterns, but it did teach me what design patterns were and how / when to use them. And I might not have built a data access layer in my class projects, but I knew what they were for and when to use them.

It also provided me with resources such as books, an online library, and networking contacts in the industry. In addition, it gave me a fancy piece of paper which can be very useful for getting your foot in the door when you don’t have experience.

Of course, it didn’t teach me everything. Looking back, I wish I had been taught about things like Version Control and Unit Testing. But the institution did their best to provide me with a solid foundation to build upon in the short time I was there, providing I was willing to go out there and keep learning.

Always be learning

One of the first things I got taught in college was that to be an IT professional, you really need to be a life-long learner. You can’t just graduate and expect you’ll have everything you need to get a high-paying job for the rest of your life. You’ll need to be willing to spend the rest of your life learning new technologies and languages.

Whenever I come across something new, something I don’t understand, or something I’m not sure of how to do, I Google it. Most of the time I can find a simple definition or samples, and I can start from there. If I do start from samples, I hate just blindly copying/pasting. I always take the time to understand what the code does. It might be slower to start with, however once understood it makes me that much better of a programmer.

Remember, N years of experience means nothing if it was simply 1 year repeated N times. There are plenty of jobs out there that are that will let you accumulate years of experience without you ever needing to learn anything new, however I feel you simply cannot be a great programmer without continuing to learn.

Steps to success in programming projects

Here is a list of steps to success in any project as a new programmer:

• Be positive when asked if you can do something.
  
  

  If someone asks you if you can do something, be positive in your response. Answering negatively, or even indecisively, will often result in a lost opportunity to learn and grow, so avoid that unless the task is truly outside the realm of possibility.

  I usually use terms like “I don’t see why not” or “shouldn’t be too hard”. You may not know how to do it right away, but you should have the tools (Google!) and intelligence needed to figure out how to get it done. I like to avoid actually saying “yes” unless I know I can actually do what is being asked.

• Determine requirements.
  
  

  Sit down with your client (boss, customer, etc) and figure out what they want. I’m not going to go into details of gathering requirements here, but do take the time to draw out the screens they expect to see, and to determine the expected input / output. My favorite tool for screen mock-ups is Balsamiq.

• Figure out how to build it.
  
  

  This is one of the most important steps. A huge part of programming (especially early on) is figuring out what your client wants, and then learning how to do that. Don’t just stick with your own knowledge base!

  For new programmers, I would suggest just focusing on just getting the desired results. Don’t get bogged down trying to learn design patterns, architecture, test-driven development, etc. Learn the basics of how to program first, then expand on that knowledge. And remember, keep it simple! You don’t need an enterprise-level solution for the FizzBuzz problem.

  At this point, if you determine that the project is completely out of your scope, say so. Even if you determine the project is far too large or complex for you to build, you will have at least increased your own knowledge, so I always see it as a win-win situation.

• Build it.
  
  

  You might think this is the hardest step of all, but in reality it will eventually become one of the easiest ones. Gathering the requirements and figuring out how you’re going to build the application are much more important, and if done right, it will make this step a breeze.

  Of course, early on in your career this step will be the most time-consuming and frustrating one. It will likely consist of a lot of trial and error, but don’t be disheartened because this means you are learning! We learn much more from our mistakes than from our successes, and the more you learn, the better your programming skills will become.

Summary

So to summarize, don’t worry too much about not being able to build/understand enterprise-level applications straight out of college. Start small, and keep an always be willing to learn. Work on programming for results first, and worry about best-practices later on. Hobby projects are a great way to gain experience. And remember, don’t ever stop learning!

Students programming in main room

Each year the Belgian Microsoft Innovation Center (MIC) runs a program to introduce future graduates in software development to local startup companies. The students come with their enthusiasm and eagerness to learn; the Startups arrive with innovative and exciting projects and the MIC provides the infrastructure and support. This year I had the pleasure to manage 24 students over 19 projects. I’ll explain how we did it.

In addition to the equipment necessary for project implementation (laptops, office, subscriptions, software, etc…) we organized many activities. The purpose of these activities was to increase significantly the level of our future developers’ professionalism while ensuring the proper conduct of the projects for our local businesses. These activities included among others: training, collective code reviews, coaching and each trainee had to give presentations.

Training

Controlling a claw built with Lego Mindstorms with his mind using Emotiv Headset

There was nothing very special about the training except the emphasis we gave to interactivity. One thing we noticed was that instead of covering new topics we were trying to complete the learning that students had achieved during their studies. Here are some of the topics we covered:

• Coding guidelines
• Source code controllers (We used Mercurial on BitBucket.org)
• Unit Testing
• Design Patterns
• C # in depth (inspired by the book of the same name)
• Agility in general
• Scrum in detail
• Effective Logging & debugging
• Basic concepts of project management software such as backlog management

We believe that these issues need to be fully integrated into university/college curricula. This would allow us to focus on even more advanced subjects.

Collective Code Reviews

a Collective Code review session

I regularly organized what we call a collective review of the code. This does not mean that everyone read all the code – that would be inefficient.

I read each trainee’s code and when I came across a problem, I would put a screenshot on a powerpoint slide. The next slide was a copy of the previous slide but with arrows showing the errors and a third slide was a screenshot of the code as I would have liked to have seen it. One type of error was added to the presentation once. For example, “poor management of exceptions” was examined only once even if it was a widespread problem found in most projects.

All the students would gather in the conference room to see the presentation. For each problem the first slide is shown so that the group could review it and identify potential problem with the code. Very often, one of the interns suggested the right solution straight away. The slide that highlighted the errors was then displayed and a discussion took place. Finally an example of corrected code was shown (third slide) so that everyone would get the benefit of the “lesson”.

Occasionally, good practice was suggested which always generated discussions and suggestions.

The learning method proved very effective. Students loved the performance aspect since it is very interactive and it always close to the problems they face.

Coaching

A student programming Nao

In addition to formal learning, intensive coaching has been implemented. At any time, I could intervene to help trainees to advance the project. I was fully dedicated to that during the whole period. They also had the opportunity to come and see me to ask technical questions whenever they could not find a solution online in less than 10 minutes (on Stack Overflow for example). Rather than handing out fish, the technique of coaching was to teach them how to fish. We placed an emphasis on developing the student’s capacity to learn while giving them the ideal conditions for the rapid acquisition of new knowledge. Coaching also included informal learning and covered all the things that are more difficult to cover during presentations to the group. Here are the different subjects which have been covered:

• Continuous integration
• Blogging
• The use of a project tracking tool (we used Trello see below)
• How to write an effective resume
• How to interview
• How to gain certifications (Microsoft ;))
• The attitude to adopt in the business environment

The last point was particularly important to me. Throughout the internship, I stressed the one point that I think will make the difference between them and other developers: the ability to solve problems and not create new ones.

Project Monitoring

A team using Trello with the Microsoft Surface

Managing the project was a very important part of the project. In fact, following 24 people in 19 projects is not an easy task. We naturally chose to set up Scrum and used a task management tool of the kanban type. Trello was chosen for its ease of use.

We formed four “virtual” teams based on project similarities, included in these “virtual” teams were two real teams of 2 or 3 people, Alongside our desire to maximize the output, we had a secondary objective to get the trainees to live Scrum and agility in general through real scenarios, some exactly as in a large company. So we had the daily scrum, the sprint review, the retrospective and a lighter version of the sprint planning.

Scrum has proven very effective in this type of program. We plan to integrate even more companies in the process. Although I took the role of “Product Owner” on this occasion we think it would bring more if the course tutors played this role, after training.

Trainee presentations

Students had the opportunity to prepare and make presentations to the group of students. These presentations were in addition to what was originally planned in the program and has allowed the students to practice the art of presentation but has also allowed them to share their new learning with the other trainees. Subjects covered were:

• Introduction to HTML5
• MEF (Managed Extensibility Framework)
• Work with Blend interfaces
• Introduction to Windows 8
• Introduction to XNA
• Introduction to ASP.NET MVC
• Deploy a WCF service in Azure
• Object Mocking
• Get organized with GTD
• The pattern MVVM
• Introduction to Programming Kinect
• Which company to choose?
• Introduction to Silverlight
• Debugging with Visual Studio.

We believe that a great developer must learn to communicate his knowledge and this exercise is therefore one of the things we will continue in the future. Indeed, in addition to these presentations, we encourage our trainees to develop a presentation video by making the appropriate equipment available. In business, those who are able to communicate well are often those to whom we entrust the most responsibility.

Conclusion

Programming the Kinect for Windows

How will we know if this program will lead to better performance from the students in comparison with other internship models? That’s the question we asked ourselves last year.

This year we have developed a proficiency test that measured several dimensions that we believe a developer must master. As we predicted, the score at the start of the program was pretty bad. At the end of the course this score had, on average, doubled!

Despite this result, we cannot say today that our program will have had an effect significantly superior to another approach, simply because we did not have a control group. We hope to do this in 2013.

I sincerely hope that other companies will be inspired to create a similar program within their specialism. I am also very interested in any form of feedback or to hear of your experiences – you can contact me in the comments.

You can see a video introduction to the program here.

In addition, one of the project participated in the Imagine Cup 2012 and you can watch the video here.

Programmers have to work with large amounts of bad code. Sometimes its your own code, but other times its another programmer’s code. If you have to frequently work with another programmer’s bad code, you will eventually wish to approach them about their code quality, however how to do this without causing offense or resentment is not always easy. This article is about the approach I would take when wanting to casually talk with another programmer about their code quality.

Determine the problem

First off, determine what exactly the problem is, and verify that it is worth bringing up. Ask yourself:

• Do you work with this person on a regular basis?
• Will you be working with, and maintaining their code in the future?
• Is this an actual problem that harms productivity, performance, or security, or is it simply a case that your preferences are different from theirs? For example, simply complaining that “your naming convention doesn’t match mine” is not a very good reason, however saying “your naming convention makes it hard to understand what is going on in the code” is a much better.

If you answered yes to all of those, then it sounds like you might have a good reason to approach someone about their code quality.

Gather your arguments

Once you’ve determined there is a valid reason for trying to change the way another programmer does things, get your arguments prepared. Identify why the code is harmful to the development environment, and figure out the ideal way of coding it instead. Pick some code samples illustrating the problem, and write your own way of coding the same piece. Determine what your arguments are for why your code is better than the existing code sample. Don’t use arguments such as “it’s best practice”, but instead explain why it’s a best practice (readability, maintainability, reusability, etc)

Approaching the other programmer

Now that you know your arguments for why you think your code is better than theirs, and have a clear idea of what the ideal code should look like, arrange a time to talk with the other programmer.

This could be a casual conversation, or it could be setting up an appointment to talk with them about your concerns. How you choose to approach your co-worker is based on your level of comfort with them, the organization’s environment, and both of your ranks within the organization. For example, if I wanted to talk to the programmer next to me, I might simply ask them if I could have a moment of time whenever they’re available to talk with me about a piece of code, however if it’s my boss, I might send him/her an email asking if I could setup a brief meeting with them to discuss some code I’ve been working on.

Some people might argue that approaching a boss is different than approaching a co-worker, however I feel they are both people and both deserve equal respect. The only real difference I see is that your boss’s time is usually more valuable to the company, so be aware of that when talking with him/her.

What to say

When you actually talk with the other programmer, I usually find a good way to start the conversation is to ask them to explain their code. Ask if there was a reason for their style of coding, or tell them you’ve never seen something coded that way, and ask them why they chose that method. Really listen to what they have to say during their explanation. It could be that their way is right, and you are wrong, in which case take notes and learn from it!

If you still think the code is bad and worth changing, show the other programmer how you would code the same piece of code, and tell them why you would code it that way over his/her way (better performance, fewer chances of errors, easier for other programmers to read/maintain, etc).

Focus on why your method of coding is better, and not why their method is worse. Nobody likes being accused of writing bad code, although in reality we were all new once and I’m sure we’ve all written some horrendous code at some point in our lifetime. Be sure to keep the conversation focused on the code, and avoid turning it personal by talking about the person who wrote the code. It is always best if you can show that you understand that sometimes bad code gets written, whether it was due to time constraints, inexperience, or simply a bad day.

In addition, don’t try and get them to change their old code (unless you are their boss and want them to spend time doing so). Your goal is to educate them so they stop making the same mistake in the future, not berate them over past mistakes and punish them by extra work.

Afterwards, see if he/she still supports their coding style over yours. If they are open to improvement, they will likely change their way of coding going forwards. But if they still prefer to use their coding style, you are not likely to change their opinion, so drop the subject and don’t bring it up again unless their code is actually harmful.

Conclusion

Remember, nobody can write perfect code, and good programmers are always looking for improvement. The world of programming is so big that its impossible to know everything. It’s very likely that the other programmer doesn’t know there is a problem with their code, and would appreciate the input, providing you do it in such a way that you are teaching them, and not insulting them.

So don’t be afraid to approach another programmer about their code quality. I know I would appreciate the conversation, and I think you would too.