Merge pull request braydie#112 from karinakozarova/master

braydie · web-flow · commit 3c6d1df2fdc1 · 2017-06-25T12:21:08.000+01:00
Various changes to wording. Fixed broken links
diff --git a/en/1-Beginner/Team-Skills/09-Take Breaks when Stumped.md b/en/1-Beginner/Team-Skills/09-Take Breaks when Stumped.md
@@ -2,4 +2,4 @@
 [//]: # (Version:1.0.0)
 When stumped, take a break. I sometimes meditate for 15 minutes when stumped and the problem magically unravels when I come back to it. A night's sleep sometimes does the same thing on a larger scale. It's possible that temporarily switching to any other activity may work.
 
-Next [How to Recognize When to Go Home](10-How to Recognize When to Go Home.md)
+Next [How to Recognize When to Go Home](10-How%20to%20Recognize%20When%20to%20Go%20Home.md)
diff --git a/en/2-Intermediate/Personal-Skills/01-How to Stay Motivated.md b/en/2-Intermediate/Personal-Skills/01-How to Stay Motivated.md
@@ -1,14 +1,14 @@
 # How to Stay Motivated
 [//]: # (Version:1.0.0)
-It is a wonderful and surprising fact that programmers are highly motivated by the desire to create artifacts that are beautiful, useful, or nifty. This desire is not unique to programmers nor universal but it is so strong and common among programmers that it separates them from others in other roles.
+It is a wonderful and surprising fact that programmers are highly motivated by the desire to create artifacts that are beautiful, useful or nifty. This desire is not unique to programmers nor universal but it is so strong and common among programmers that it separates them from others in other roles.
 
-This has practical and important consequences. If programmers are asked to do something that is not beautiful, useful, or nifty, they will have low morale. There's a lot of money to be made doing ugly, stupid, and boring stuff; but in the end, fun will make the most money for the company.
+This has practical and important consequences. If programmers are asked to do something that is not beautiful, useful or nifty, they will have low morale. There's a lot of money to be made doing ugly, stupid, and boring stuff; but in the end, fun will make the most money for the company.
 
-Obviously, there are entire industries organized around motivational techniques some of which apply here. The things that are specific to programming that I can identify are:
+Obviously, there are entire industries organized around motivational techniques, some of which apply here. The things that are specific to programming that I can identify are:
 
 - Use the best language for the job.
-- Look for opportunities to apply new techniques, languages, and technologies.
-- Try to either learn or teach something, however small, in each project.
+- Look for opportunities to apply new techniques, languages and technologies.
+- Try to either learn or teach something, no matter how small, in each project.
 
 Finally, if possible, measure the impact of your work in terms of something that will be personally motivating. For example, when fixing bugs, counting the number of bugs that I have fixed is not at all motivational to me, because it is independent of the number that may still exist, and it also affects the total value I'm adding to my company's customers in only the smallest possible way. Relating each bug to a happy customer, however, *is* personally motivating to me.
 
diff --git a/en/2-Intermediate/Personal-Skills/02-How to be Widely Trusted.md b/en/2-Intermediate/Personal-Skills/02-How to be Widely Trusted.md
@@ -1,6 +1,6 @@
 # How to be Widely Trusted
 [//]: # (Version:1.0.0)
-To be trusted you must be trustworthy. You must also be visible. If no one knows about you, no trust will be invested in you. With those close to you, such as your teammates, this should not be an issue. You establish trust by being responsive and informative to those outside your department or team. Occasionally someone will abuse this trust, and ask for unreasonable favours. Don't be afraid of this, just explain what you would have to give up doing to perform the favour.
+To be trusted you must be trustworthy. You must also be visible. If no one knows about you, no trust will be invested in you. With those close to you, such as your teammates, this should not be an issue. You establish trust by being responsive and informative to those outside your department or team. Occasionally, someone will abuse this trust and ask for unreasonable favours. Don't be afraid of this, just explain what you would have to give up doing to perform the favour.
 
 Don't pretend to know something that you don't. With people that are not teammates, you may have to make a clear distinction between 'not knowing right off the top of my head' and 'not being able to figure it out, ever.'
 
diff --git a/en/3-Advanced/Technical-Judgment/01-How to Tell the Hard From the Impossible.md b/en/3-Advanced/Technical-Judgment/01-How to Tell the Hard From the Impossible.md
@@ -1,9 +1,9 @@
 # How to Tell the Hard From the Impossible
 [//]: # (Version:1.0.1)
-It is our job to do the hard and discern the impossible. From the point of view of most working programmers, something is impossible if either it cannot be grown from a simple system or it cannot be estimated. By this definition what is called research is impossible. A large volume of mere work is hard, but not necessarily impossible.
+It is our job to do the hard and discern the impossible. From the point of view of most working programmers, something is impossible if either it cannot be grown from a simple system or it cannot be estimated. By this definition, what is called research is impossible. A large volume of mere work is hard, but not necessarily impossible.
 
-The distinction is not facetious because you may very well be asked to do what is practically impossible, either from a scientific point of view or a software engineering point of view. It then becomes your job to help the entrepreneur find a reasonable solution which is merely hard and gets most of what they wanted. A solution is merely hard when it can be confidently scheduled and the risks are understood.
+The distinction is not facetious, because you may very well be asked to do what is practically impossible, either from a scientific point of view or a software engineering one. It then becomes your job to help the entrepreneur find a reasonable solution, which is merely hard,  and gets most of what they wanted. A solution is merely hard when it can be confidently scheduled and the risks are understood.
 
 It is impossible to satisfy a vague requirement, such as ‘Build a system that will compute the most attractive hair style and colour for any person.’ If the requirement can be made more crisp, it will often become merely hard, such as ‘Build a system to compute an attractive hair style and colour for a person, allow them to preview it and make changes, and have the customer satisfaction based on the original styling be so great that we make a lot of money.’ If there is no crisp definition of success, you will not succeed.
 
-Next [How to Utilize Embedded Languages](02-How to Utilize Embedded Languages.md)
+Next [How to Utilize Embedded Languages](02-How%20to%20Utilize%20Embedded%20Languages.md)
diff --git a/en/3-Advanced/Technical-Judgment/02-How to Utilize Embedded Languages.md b/en/3-Advanced/Technical-Judgment/02-How to Utilize Embedded Languages.md
@@ -8,4 +8,4 @@ I and many other programmers have fallen into the trap of creating special purpo
 
 The real question to ask oneself before embedding a language is: Does this work with or against the culture of my audience? If you intended audience is exclusively non-programmers, how will it help? If your intended audience is exclusively programmers, would they prefer an applications programmers interface (API)? And what language will it be? Programmers don't want to learn a new language that is narrowly used; but if it meshes with their culture they will not have to spend much time learning it. It is a joy to create a new language. But we should not let that blind us to the needs of the user. Unless you have some truly original needs and ideas, why not use an existing language so that you can leverage the familiarity users already have with it?
 
-Next [Choosing Languages](03-Choosing Languages.md)
+Next [Choosing Languages](03-Choosing%20Languages.md)
diff --git a/en/3-Advanced/Technical-Judgment/03-Choosing Languages.md b/en/3-Advanced/Technical-Judgment/03-Choosing Languages.md
@@ -12,4 +12,4 @@ Programming languages should really be called notations in that learning one is
 
 Some of these effects may only be psychological; but psychology matters. In the end, the costs of language tyranny outweigh any advantage that it provides.
 
-Next [Compromising Wisely - How to Fight a Schedule Pressure](../Compromising-Wisely/01-How to Fight Schedule Pressure.md)
+Next [Compromising Wisely - How to Fight a Schedule Pressure](../Compromising-Wisely/01-How%20to%20Fight%20Schedule%20Pressure.md)

Original file line number	Diff line number	Diff line change
`@@ -8,4 +8,4 @@ I and many other programmers have fallen into the trap of creating special purpo`
`8`	`8`
`9`	`9`	The real question to ask oneself before embedding a language is: Does this work with or against the culture of my audience? If you intended audience is exclusively non-programmers, how will it help? If your intended audience is exclusively programmers, would they prefer an applications programmers interface (API)? And what language will it be? Programmers don't want to learn a new language that is narrowly used; but if it meshes with their culture they will not have to spend much time learning it. It is a joy to create a new language. But we should not let that blind us to the needs of the user. Unless you have some truly original needs and ideas, why not use an existing language so that you can leverage the familiarity users already have with it?
`10`	`10`
`11`		`-Next [Choosing Languages](03-Choosing Languages.md)`
	`11`	`+Next [Choosing Languages](03-Choosing%20Languages.md)`
Original file line number	Diff line number	Diff line change
`@@ -12,4 +12,4 @@ Programming languages should really be called notations in that learning one is`
`12`	`12`
`13`	`13`	`Some of these effects may only be psychological; but psychology matters. In the end, the costs of language tyranny outweigh any advantage that it provides.`
`14`	`14`
`15`		`-Next [Compromising Wisely - How to Fight a Schedule Pressure](../Compromising-Wisely/01-How to Fight Schedule Pressure.md)`
	`15`	`+Next [Compromising Wisely - How to Fight a Schedule Pressure](../Compromising-Wisely/01-How%20to%20Fight%20Schedule%20Pressure.md)`