Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

The idea is to give them more chances to be efficient in a professional environment.

Most students are good with theory, most of them are smart, but they have to learn how to solve common technical problems.

They will be better programmers as they practice, but maybe we can help them with some introduction training.

Which topics you would select for a two weeks full time training?

It's an open question, I don't want to suggest things that will reduce the answers to a particular field.

share|improve this question

closed as not constructive by gnat, Walter, Robert Harvey, BЈовић, GlenH7 Nov 27 '12 at 16:19

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. If this question can be reworded to fit the rules in the help center, please edit the question.

The first thing I would say is: "Always stay tuned because you can never know when Microsoft decides it's time for us to move to a new technology" (and here I'd talk about COM and COM+ a little). –  Emiliano Oct 8 '10 at 10:35

14 Answers 14

up vote 23 down vote accepted

Source Control: From my experience, colleges don't teach this well if at all.

Unit Testing: Same as above (also reduces the amount of time they need to spend in a debugger)

DRY/SRP/SOLID: Good, fundamental design techniques. DRY alone will help make them a better programmer, developer, and produce better quality code.


share|improve this answer
I would love to have even heard about proper Unit Test and IoC techniques in school. –  Matt DiTrolio Oct 8 '10 at 13:19
+1 Source Control is something woefully absent from my school days. –  Jesse C. Slicer Oct 8 '10 at 13:50
I will add Test Driven Development to your answer. However, I'm not that exited about IoC. –  user2567 Oct 8 '10 at 14:04
I'd agree with Pierre. The need for explicit DI is a quirk of certain languages, so IoC definitely ought to be taught with those languages, but I don't think that it is universally relevant. –  Stuart Ellis Oct 13 '10 at 9:29
My university taught me all of these things and it's not exactly one of the top uni's. Although i was doing SE, not CS –  rmx Feb 1 '11 at 15:37

I think most students don't know how to use the debugger and they feel more confortable using the console output function to query the value of variables and obtain debugging information.

I'm not talking about advanced debugging techniques but at least they should be able to able to do the following from IDE:

  • Add a breakpoint
  • Inspect the content of variables
  • Add a watch
  • Use the callstack to see the execution path
  • Debug exceptions
share|improve this answer
Excellent answer. Since I learned how to use the debugger effectively, it was a lot easier to find solutions to blocking problem that cost a lot to the company I worked for. –  user2567 Oct 8 '10 at 7:50
If this is web you might want to throw fiddler in the too –  billy.bob Oct 8 '10 at 8:57

Well let's suppose I had a group of new hires just out of school for a couple of weeks of intro training (which I really really wish we would do, people would get up to speed so much faster).

First source control, how we use it why we use it and where the files are located for various projects and how to get it running. Emphasis on comments on check in. Emphasis on how often to check in and when to check into the trunk and when not to. Emphasis on not leaving source control out until you are finished. With new emplyees, it is better to review their code before they get too far down the wrong path, so they should be checking in frequently. I notice with some of our new employees we often have to get tough to get them to check in their first stuff at all.

Next coding standards. What are standards are and why you have to follow them and not just do the things you want to on your own.

Then an intro to the tools we use including bug tracking, timesheets, project management software as well as programming tools. This would include how to use the debugger.

Then a day going through the highlights of the code base. Let them get an understanding of how the current thing works.

Then a long day on getting familiar with the complicated database structure. People just out of school have often never encountered a truly complex system.

Then a day on testing - TDD, Unit tests, QA testing etc.

Then a day on requirements, those just out of college may have never dealt with complex requirements either. Important is a discussion of how to push back if the requirement has holes or conflicts with some other requirement. It is important for them to know they are expected to push back when necessary to get the information they need. Many young people always accept the requirements at face value.

Some time on deploying. Deploying to prod is not a familar task either. Doing it poorly will cause problems. Even if they don't deploy, they need to understand what the people who do deploy need.

Finally, and most critical, have them work as a group to create a change to the current system. Make sure they do things right in terms of standards, source control testing etc. If they get pinged from the first on things, they will understand you really mean it when you tell them to use Source Control. I would create a change requirement that had holes and make them need to do complex queries and have something that has lots of edge cases to test, etc. Doesn't have to be something you deploy, just something that you can do against a database and application code that is reserved just for learning. That way they aren't interfering with the real work and you can put the whole project back to baseline for the next group.

share|improve this answer
+1 for mentioning complex database systems. I find this to be true as well with younger new hires. –  Kenzo Nov 26 '12 at 16:52
  • Requirements Gathering - school assignments too often provide them
  • Planning
  • Source Control (setting up, developing guidelines, and using)
  • Debugging
  • Installers

Depending on the jobs they get, they may not have a chance to learn these things outside of the way the team already does them. This may help to fill in some gaps.

There are other important areas like testing, but I don't know how far you could get into that in 2 weeks.

share|improve this answer

SQL skills - can't believe how weak they generally are coming out of school. The second thing would be time managment and how to meet deadlines.

share|improve this answer
+1 on this. The success of the ORM du jour doesn't mean you don't have to know SQL. –  Josh Dec 2 '11 at 17:39
At my uni it depends which options you take. If you wanted you can study CS and take 2 SQL based DB modules or you could take, say, networking (CCNA equiv) and security modules (CEA equiv) and never touch SQL, both sets of options give you a degree with the same title. –  Inverted Llama Nov 26 '12 at 13:01

Asking questions about the requirements

For e.g In schools days, if we ask a student to write a addition program in C, immediately they will come up with

void main()
 int a,b,c;

Note: Forgive me for syntax if its wrong :)

Here they do not ask the following questions

  1. From where do they receive the input?
  2. What kind of data (int,float etc) will be the input?
  3. Where should the output go?
share|improve this answer
How to code expressively... –  user2567 Oct 8 '10 at 12:02

I'd add at least one business class.

My problem after graduation is I thought the world was a place where I could always build what I wanted. Somewhere that would strive for software quality in every build. Well, I was mistaken. People pay developers not just to write code, but to write code that makes them money! A lot of times the "best" solution to someone out of college isn't necessarily the best solution for the business. Sometimes "good enough" but also "shipped" is better than something that has flawless design.

share|improve this answer

I would teach real life design. The goal is to help them to shape the projects in the correct form, building a good (and effective) object tree, avoiding overdesign.

Also being involved in some real project (instead of some "academic sample") would be very helpful. After all, student have a lot of theory but no practice.

share|improve this answer
Do you have some references ? Articles, etc? –  user2567 Oct 8 '10 at 10:04
@Pierre 303: no sorry, my answer comes from direct experience with "fresh from school" coworkers and interns... –  Lorenzo Oct 8 '10 at 10:21

Not sure if this qualified, but having taught a C & C++ class a few years ago (98-2002) at a community college, I can say I tried to emphasize:

  • List item
  • Debugging Teach yourself/look it up (this predated "just google it!")
  • Being pragmatic

In addition, I tried to bring up relative real world "sidebars" when covering the material. I especially tried to explain why things where in addition to just how things are.

I moved away from the area after 4 years and never ran into any former students. I have no idea how I succeeded or failed.

share|improve this answer

Love the answers given (esp. Source Control). I'll add one of my own:

  • How to program in a team. In other words, how to functionally break down a project into manageable pieces and assign work items to different team members, requiring formal design to be reviewed by the team before implementation. Following a technical specification for someone else's subsystem.
share|improve this answer
Yes I think that is important. I noticed that average student tend to be individualist. –  user2567 Oct 8 '10 at 14:03

If I were setting up a general "welcome to the real world" type course, I might start with a working application and give them tasks relating to that existing code - implement a new feature, give them some bug fixes to sort out and then have groups swap around so that they tested one another's work.

If the starting code is relatively well written ( but perhaps with some quirks to potentially catch the unwary integrator ) and with a degree of unit test coverage, already in source control and with it's own build process, you give them a bunch of very useful experiences in working with those tools, troubleshooting other people's code and their own and developing against an existing codebase, all of which are things that you don't typically get so much experience of in college but you are likely to be doing for much of your working life.

share|improve this answer

Write Readable Code

This would be the very first sentence I would say to them, even before introducing myself.

Other than this, I would follow the advice on Chris Holmes' answer.

share|improve this answer

I'd be more likely to suggest going over process points including the following:

  1. An overview of the methodology used where I work. How do bugs get handled? How is source control used? How are feature requests handled? While some of these may seem broad, the idea here is to ensure that the new people understand the basics of how things tie together here.

  2. General workday flow. Are there typical meetings like a daily stand-up that they should know? Are there department meetings on a regular basis worth noting? Is there a regular lunch time when most developers step out to get a bite to eat? This isn't necessarily about work as much as it is about the environment and giving the new people a chance to be successful. If in a company no developer shows up till 8:30 in the morning and the new person wants to start their second day at 7:30, what does the new person do for that hour that may be a whole lot of thumb twiddling, paperwork or configuring their machine if they are waiting for someone else to show up to help with a problem.

  3. The "if you get stuck..." procedure. While this may fall under the previous categories, I'd be more than a little tempted to make this its own section where a few other points are noted:

    1. Expertise - Who has which area of expertise? Some developers may be known for a specialty or two that is worth disclosing to new people in the group.
    2. Time frame of getting stuck - Some places may say if a developer is stuck for 5 minutes, escalate the issue. Other places may have no set threshold. What is the procedure here for a developer to find resources to help address an issue?
    3. What are the common scripts, files and applications developers use here in their work? This could be interesting and vary a bit from place to place.

I'd probably also suggest creating a feedback mechanism for the first few weeks that may be where it is useful to know who is doing what where and when is the next time for someone to check on their progress.

share|improve this answer

I had a course like this at my uni it covered:

  • Systems analysis
  • Business spec writing
  • Technical spec writing
  • Teamwork
  • Software licences
  • Version control
  • Testing
  • Methodoligies

I think the most useful area for me was the version control however some other students definitely benefited from the more business side spec writing sections. DRY/SOLIC/Refactoring and unit testing are worth looking at but at my uni these were touched on in the upper level technical courses.

share|improve this answer