If you had to teach professional development to students that just graduated school, what would be the topics? [closed]

Question

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.

Answer 1

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.

IoC

Answer 2

Debugging

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

Answer 3

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.

Answer 4

• 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.

Answer 5

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.

Answer 6

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;
 a=1,b=2;
 c=a+b;
 printf(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?

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

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.

Answer 14

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.