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, no registration required.

I'm preparing a course dedicated to fresh graduated CS students. I have to name it.

Is there an English word or sentence to define all the practices you don't learn at college/university?

Here are a (partial) list of things are not teach to most students I interview or talk with:

  • Unit Testing + mocking
  • Design Patterns
  • Agility (such as Scrum or Extreme Programming)
  • Source Control, DVCS, ...

I once heard "Software Industrialization Practices" (literally translated from French), and while it sounded great in French, I'm not sure it does in English.

share|improve this question

closed as not constructive by Mark Trapp Dec 17 '11 at 6:13

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.

I actually learnt Unit Testing + Mocking, Design Patterns and Agile practices at my university. –  Spoike Jul 14 '11 at 7:50
@Spoike: lucky you ;) –  user2567 Jul 14 '11 at 7:52
Getting out of bed before 9 am ? –  Paul R Jul 14 '11 at 8:46
I'd never heard of version control software until after I'd left university, which, looking back on it, is appalling. –  Steve Melnikoff Jul 14 '11 at 11:35
@Paul - More like 3pm –  Morgan Herlocker Jul 14 '11 at 13:03

17 Answers 17

up vote 43 down vote accepted

How about "real-world software development"? As opposed to "academic things taught at university by professors who've never worked a day in the real world".

share|improve this answer
I wish they taught that back at my school. –  Timothy Groote Jul 14 '11 at 9:15
Not sure who your professors were, but all my CS professors at college had had real careers writing real software before deciding to become professors and pass on what they knew. –  Mason Wheeler Jul 14 '11 at 12:53
@Mason Wheeler & @Bill the Lizard: I just learned from Wikipedia that meaning of the word "Professor" varies by country. I meant university professors, who almost always (AFAIK) are full-time academics (researchers), although some of them may have worked in industry for some time of their career, before returning to academia. –  Joonas Pulakka Jul 14 '11 at 13:07
Also, because the field moves so fast, a tenured CS professor will have been out of the game long enough that the whole world's changed around him while he's sequestered in academia. –  KeithS Jul 14 '11 at 14:27
Adding to the discussion - my best professors at university were the ones with only theoretical knowledge. This may have been because at least they knew what they didn't know! –  Joris Timmermans Jul 14 '11 at 15:02

I would call it "Pragmatic Development" with a big nod to the book "The Pragmatic Programmer" - it is an extremely useful introduction to software development in the real world.

After all being "pragmatic" is doing what works and not doing what doesn't work, no matter what people think of it academically.

If you want a nice one-liner for your training presentation, you could also use the following: "In theory there is no difference between theory and practice, but in practice there is.".

share|improve this answer

At university we had a compulsory course called 'Professional Software Development' it covered what you listed in design patterns, Unit Testing + mocking, Agility (such as Scrum or Extreme Programming)

But as well 50% of the course mark was for a group project where you were randomly assigned a group. The requirements were given out in the first class and then over the next 20 weeks (2 semester course) as a group we had to do the following

  • interview the client to confirm and enhance requirements
  • design a mock up and get client sign off
  • develop the system
  • pass the system off to another group for testing (and test a random groups system)
  • document the system
  • implement several random changes to the requirements
  • present system to client

best introduction to the real world possible as you didn't get to pick anything! Also excellent for learning how to work with others.

share|improve this answer
+1. I think you had an atypical course at your university. Wish mine had offered a course like that. The closest thing I got to that was being forced into groups at the beginning of the year and working on a project to be submitted at the end of the year. –  Neil Jul 14 '11 at 10:31
I've always thought a good class would be what you describe, plus requiring the students to enhance with new features the system the previous year's class built. –  GrandmasterB Jul 14 '11 at 18:01

"Applied Software Development" vs. "Theoretical Software Development"

share|improve this answer

I would call such a course "Introduction to Software Engineering". Those topics are generally considered to be either software development best practices or traditional software engineering topics.

At the university I attended, these topics were touched upon in nearly every course across the curriculum. In addition, there was a course on software testing that went more in-depth into unit testing, mocking, and other types of testing techniques, a course that exclusively focused on object-oriented design and design patterns, and several process courses including one on agile software development.

share|improve this answer

"From Apprentice to Journeyman"

You didn't ask for course texts but I've just read "The Clean Coder" by Robert Martin and cannot recommend it highly enough in this context.

share|improve this answer

One work "Source Control"

One of the most essential skills is to learn to use source control.

Having to explain branching strategies to the new colleges grads every year is a pain. especially when they are self taught and think they know what they are doing.

share|improve this answer

The idea that university teaching has nothing serious to learn from practitioners, or that learning ends with a diploma, is frighteningly common.

Some things practitioners know could well be absorbed into university teaching. I was so taken with these that I wrote a book about some of them. Here's a few:

  • Performance Tuning. The gprof-meme has found a stable home in academia, in spite of its airy foundation. There are far better ways to do it.

  • Code Generation. This is a fundamentally useful problem-solving technique. Graduates may have heard of it, but don't really have any idea of when it applies or how to use it.

  • Problem-Oriented (Domain Specific) Languages: Same comment as under Code Generation.

I think forums like Stackoverflow and Stackexchange are incredibly valuable for this extended learning.

(Aside: I'm a student pilot. Aviators call a pilot's license a "License to Learn". In other words, when you've learned to fly, you've only just begun.)

share|improve this answer

Applied? Practical? Real-world? Concrete?

All words that come to mind based on your rubric.

My favourite however would be "field" practises - those that you'd have to go out to industry in order to attain.

share|improve this answer

I guess they would be called "best practices in the industry not taught in university"? I don't think there is any definite term for these. Even if there would be it would only lead to confusion where one university actually teaches one subset of practices.

Then again, I don't think you should worry that much about it... only ask the junior candidates what agile practices they know of. I guess that's a way to filter candidates; if they are clueless then it is sufficient to expect that they're not paying attention to the industry.


As a side-note I went to a university that has a course in extreme programming. It's goal however is not to teach XP per se, but to give the students a preparatory course in software engineering and the faculty uses XP to convey the whole process. That way they have something practical for the later courses in requirements engineering, testing and verification, algorithms and datastructures, OO-practices etc.

The students are first given some lectures where they are taught the basics about agile processes, version control and unit testing. In the following semester they're scheduled each week a full day lab where they work on a project, and also have a 2 hour planning meeting together with a "customer". They also have access to senior students who are acting as coaches (they're going a leadership/coaching course so this is their practical project). It is the same project every year, and in the final release the students use the application for themselves in a competition where the teams compete both in a simple sport and which application produced the results the fastest. The course is used for research as well (here is one publication about it).

share|improve this answer
@Pierre_303: Edited, the course I went to is just called "Software Development in teams". –  Spoike Jul 14 '11 at 8:32

(Introduction to) Software Development

...as opposed to Computer/Computing Science; they're different subjects. The answers going on about "real world" vs. "academic world" miss that point. A CS degree isn't meant to teach you how to write software---it's meant to provide a framework of theoretical knowledge upon which you can build vocational knowledge through experience and additional studies.

share|improve this answer

"On-the-job training" would describe skills learnt as part of your work experience.

I think it depends where you think these other skills are learnt, rather than where they're not learnt.

Personally I learnt a great deal of my skills from working on projects in my own time (typically learning from articles on the web and books). So this would probably be best described as "self-study".

share|improve this answer
real-world training –  Carlos Campderrós Jul 14 '11 at 8:24

Some of this could be considered tacit knowledge because it's something that generally takes a bit of experience to fully comprehend.

You could also call them complementary skills because they're not totally necessary for programming but they can aid in it.

share|improve this answer
  • Exception handling, or in general thinking more about "things that could go wrong with this particular piece of code". That's something I definitely would have valued a lot.
  • Refactoring of legacy systems.
share|improve this answer

Vocational training for software development

share|improve this answer

Working Software Development. As in, getting a job making software that works.

share|improve this answer

Getting paid for writing software.

share|improve this answer

protected by Doc Brown Nov 20 '13 at 7:03

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?