You found yourself the reason: "I know they are capable of learning, just seems that there's a general lack of motivation."
There are people who are passionate about their work. And there are others who, being sometimes competent enough, are working just for money. They know their stuff, but they don't enjoy their work. They will not spend extra time doing additional refactoring to make code readable or solving an intriguing problem when a quick and ugly hack can do the job.
This phenomenon exists in every job. It's just that some jobs are not extremely exciting (have you seen an accountant who loves his job and dreamed about it already when he was a child?), but in programming, there are plenty of people who really love what they are doing (otherwise Programmers.SE will be pretty empty). This means that as passionate developers, who talk daily to other passionate developers, we have more chances to be surprised seeing a person who does programming just for money.
What can we do? Not too much. In all cases, it's not to you, but to the human resources to choose people who are truly motivated¹. And fire people who are not.
You can try to motivate your colleagues yourself, but it's extremely hard. If you give them books to read, they will return them unopened a few weeks later. If you give them an advice, they will not listen, because they don't care².
You can:
Convince your boss to set a number of strict rules in your company: style guidelines, etc. This will not motivate those people to do a better job, but at least they will not be able to commit source code which doesn't match the requirements.
Work on the requirements, especially non-functional requirements. What about a requirement which tells that a specific project must contain less than 5 000 lines of IL code (no, I'm not talking about the meaningless LOC)³? What about requiring to obtain specific results at cyclomatic complexity or class coupling?
Increase the number of hours you spend in your company doing code reviews. Specify what is reviewed: if you have a checklist, add the points related to refactoring, readability, clean and useful comments, etc. If you don't have a checklist, you must.
Use [more] pair programming. It may help improve the code quality and motivate the less motivated coworkers.
Use the compensation system similar to what is used at Fog Creek.
¹ That's what interviews are about: before hiring you, the human resources must asset not only your technical level, but also your motivation. Sadly, some companies forget about this second part of the interview, and hire people who don't enjoy programming too much. Happily, in most cases, the work in those companies is never enjoyable, and Joel test rarely exceeds 2.
² They really don't care, even if they gain less money. I'm pretty close to one of my customers (I'm a freelancer) who believes that his work is to develop websites for his own customers. He also have a designer. I told them many times about the ways they can increase their productivity by 2 or more. If they just hired somebody competent, they would increase their revenue by at least 3. But they have enough money, and don't care about quality or how much they cost to the ignorant customers, compared to somebody productive.
³ What I mean is the number of lines of IL code which you see in Code Metrics in Visual Studio, the metric which actually means something. The real LOC doesn't matter and you don't have to measure it; it's one of the most stupid metrics ever. Enforcing IL lines of code means that developers will be forced to actually refactor code, and not just to collapse ten lines of code in a single unreadable line.
I would break it down into sections like
- Current staff - names and titles (ideally with photos)
- Applications, logins to them, data to know and permission requests to have submitted
- Bookmarks to company sites and key external sites relevant to the business
- Applications that the company uses for comms, email, conference room booking, sharescreen
- Procedures for company related activities such as Expensing receipts, booking travel
- Developer Machine Setup. Describe the process of a setting up a new developers machine in detail. This is usually 'expected' to only take a day, but often it take 3-5 days in reality.
- The development process, how work is tracked, assigned and updated and what tools are used.
- How to test, what to test, when to test, where to test.
- Coding standards including file naming conventions and language specific standards.
- How to handle bugs, where to document them, how to go about fixing them.
- deployment process, what are the key things to know for production pushes.
- How to document, what to document, When to document.
- Where stuff 'is', e.g. location(s) for Code, Data, Standards, Documentation, Links and other assets.
Making it modular will also let you or others update pieces separately, for instance the employees names and positions will change frequently as people come and go.
For each section I'd try hard to write it from a 'newbie' point of view. Most important will be making sure it really makes sense to a newbie. Your boss obviously is not the right person to review this as he is not the intended audience. He's right to want it, just make sure the content doesn't end up being tested by him. Also a 'newbie' both only has "1 week" as being a newbie... and only has one point of view. So it's likely (and recommended) that the document will be refined with each new employee. In fact it's a pretty good task to also assign them for their first week, i.e. "Update the newbie manual".
For Agile/SCRUM:
The hardest part of doing Agile and SCRUM is 'really' doing it.
For reading I would start at http://agilemanifesto.org/ and go from there.
I would also read the well-known http://www.halfarsedagilemanifesto.org/ which adds weight to the fact that you really have to embrace all the aspects for it to work. If you have to heavily modify Agile for your organizations it's likely that people want the benefits - without using the correct processes. This fact itself should be presented to ward off any half-assyness.
Best Answer
From a practical viewpoint combinators are kind of programming constructs that allow you to put together pieces of logic in interesting and often advanced manners. Typically using them depends on the possibility of being able to pack executable code into objects, often called (for historical reasons) lambda functions or lambda expressions, but your mileage can vary.
A simple example of a (useful) combinator is one that takes two lambda functions without parameters, and creates a new one that runs them in sequence. The actual combinator looks in generic pseudocode like this:
The crucial thing that makes this a combinator is the anonymous function (lambda function) on the second line; when you call
the resulting object a is not the result of running first f() and then g(), but it is an object that you can call later to execute f() and g() in sequence:
You can similarly then have a combinator that runs two code blocks in parallel:
And then again,
The cool thing is that 'in_parallel' and 'in_sequence' are both combinators with the same type / signature, i.e. they both take two parameterless function objects and return a new one. You can actually then write things like
and it works as expected.
Basically so combinators allow you to construct your program's control flow (among other things) in a procedural and flexible fashion. For example, if you use in_parallel(..) combinator to run parallelism in your program, you can add debugging related to that to the implementation of the in_parallel combinator itself. Later, if you suspect that your program has parallelism-related bug, you can actually just reimplement in_parallel:
and with one stroke, all the parallel sections have been converted into sequential ones!
Combinators are very useful when used right.
The Y combinator, however, is not needed in real life. It is a combinator that allows you to create self-recursive functions, and you can create them easily in any modern language without the Y combinator.