Know Your IDE - Revision history

Kevlin at 21:52, 17 August 2009

2009-08-17T21:52:52Z

←Older revision		Revision as of 21:52, 17 August 2009
Line 9:		Line 9:
	Unfortunately modern IDEs do not require us to invest effort in order to learn how to use them. When I first programmed C on Unix, I had to spend quite a bit of time learning how the ''vi'' editor worked, due to its steep learning curve. This time spent up-front paid off handsomely over the years. I am even typing the draft of this article with ''vi''. Modern IDEs have a very gradual learning curve, which can have the effect that we never progress beyond the most basic usage of the tool.		Unfortunately modern IDEs do not require us to invest effort in order to learn how to use them. When I first programmed C on Unix, I had to spend quite a bit of time learning how the ''vi'' editor worked, due to its steep learning curve. This time spent up-front paid off handsomely over the years. I am even typing the draft of this article with ''vi''. Modern IDEs have a very gradual learning curve, which can have the effect that we never progress beyond the most basic usage of the tool.

-	My first step in learning an IDE is to memorize the keyboard shortcuts. Since my fingers are on the keyboard when I'm typing my code, ~~it will save me precious seconds to press~~ ''Ctrl+Shift+I'' to inline a variable, ~~rather than having~~ to navigate a menu with my mouse. These ~~seconds add up over time~~, making me much ~~more~~ productive ~~than when~~ I try to do everything the lazy way. The same rule also applies to keyboard skills: Learn to touch type, you won't regret the time invested up-front.	+	My first step in learning an IDE is to memorize the keyboard shortcuts. Since my fingers are on the keyboard when I'm typing my code, pressing ''Ctrl+Shift+I'' to inline a variable saves breaking the flow, whereas switching to navigate a menu with my mouse interrupts the flow. These interruptions lead to unnecessary context switches, making me much less productive if I try to do everything the lazy way. The same rule also applies to keyboard skills: Learn to touch type, you won't regret the time invested up-front.

	Lastly, as programmers we have time proven Unix streaming tools that can help us manipulate our code. For example, if during a code review, I noticed that the programmers had named lots of classes the same, I could find these very easily using the tools ''find'', ''sed'', ''sort'', ''uniq'', and ''grep'', like this:		Lastly, as programmers we have time proven Unix streaming tools that can help us manipulate our code. For example, if during a code review, I noticed that the programmers had named lots of classes the same, I could find these very easily using the tools ''find'', ''sed'', ''sort'', ''uniq'', and ''grep'', like this:

Kevlin: Know your IDE moved to Know Your IDE

2009-08-17T11:30:56Z

Know your IDE moved to Know Your IDE

←Older revision

Revision as of 11:30, 17 August 2009

Kevlin at 11:30, 17 August 2009

2009-08-17T11:30:26Z

←Older revision		Revision as of 11:30, 17 August 2009
Line 1:		Line 1:
-	In the ~~80s,~~ our programming environments were typically nothing better than glorified text editors, if we were lucky. Syntax highlighting, which we take for granted nowadays, was a luxury that certainly was not available to everyone. Pretty printers to format our code nicely were usually external tools that had to be run to correct our spacing. Debuggers were also separate programs run to step through our code, but with a lot of cryptic keystrokes.	+	In the 1980s our programming environments were typically nothing better than glorified text editors... if we were lucky. Syntax highlighting, which we take for granted nowadays, was a luxury that certainly was not available to everyone. Pretty printers to format our code nicely were usually external tools that had to be run to correct our spacing. Debuggers were also separate programs run to step through our code, but with a lot of cryptic keystrokes.

-	During the ~~90s,~~ companies began to recognize the potential income that they could derive from equipping programmers with better and more useful tools. The Integrated Development Environment (IDE) combined the previous editing features with a compiler, debugger ~~and~~ pretty printer. During that time, the mouse ~~and menus~~ also became popular, which meant that developers no longer needed to learn cryptic key combinations to use their editors~~, but~~ could simply select their command from the menu.	+	During the 1990s companies began to recognize the potential income that they could derive from equipping programmers with better and more useful tools. The Integrated Development Environment (IDE) combined the previous editing features with a compiler, debugger, pretty printer, and other tools. During that time, menus and the mouse also became popular, which meant that developers no longer needed to learn cryptic key combinations to use their editors. They could simply select their command from the menu.

-	In the 21st century, IDEs ~~became~~ so common place that they ~~were~~ given away for free by companies wishing to gain market share in other areas. The modern ~~IDEs are~~ equipped with an amazing array of features. My ~~favourite are the~~ refactoring ~~tools~~, where I can select a chunk of code ~~and convert that~~ into a method. The refactoring tool will pick up all the parameters that need to be passed into the method, which makes it extremely easy to modify code. My IDE will even detect other chunks of code that could also be replaced by this method and ask me whether I would like to replace them too.	+	In the 21st century IDEs have become so common place that they are given away for free by companies wishing to gain market share in other areas. The modern IDE is equipped with an amazing array of features. My favorite is automated refactoring, particularly ''Extract Method'', where I can select and convert a chunk of code into a method. The refactoring tool will pick up all the parameters that need to be passed into the method, which makes it extremely easy to modify code. My IDE will even detect other chunks of code that could also be replaced by this method and ask me whether I would like to replace them too.

-	Another amazing feature of modern IDEs is the ability to enforce style rules within a company. For example, in Java, some programmers have started making all parameters final, which in my opinion is a waste of time. However, since they have such a style rule, all I would need to do is set it up in my IDE ~~and every time that a parameter is non-final,~~ I would get a warning. ~~The style~~ rules can also be used to find probable bugs, such as ~~when we compare~~ autoboxed objects ~~with "~~==".	+	Another amazing feature of modern IDEs is the ability to enforce style rules within a company. For example, in Java, some programmers have started making all parameters <code>final</code> (which, in my opinion, is a waste of time). However, since they have such a style rule, all I would need to do to follow it is set it up in my IDE: I would get a warning for any non-<code>final</code> parameter. Style rules can also be used to find probable bugs, such as comparing autoboxed objects for reference equality, e.g., using <code>==</code> on primitive values that are autoboxed into reference objects.

-	Unfortunately modern IDEs do not require us to ~~put in a lot of~~ effort in order to learn how to use it. When I first programmed C on ~~unix~~, I had to spend quite a bit of time learning how the VI editor worked, due to its steep learning curve. This time spent up-front paid off ~~hansomly~~ over the years. I am even typing this article with VI. Modern IDEs have a very gradual learning curve, which can have the effect that we never progress beyond the most basic usage of the tool.	+	Unfortunately modern IDEs do not require us to invest effort in order to learn how to use them. When I first programmed C on Unix, I had to spend quite a bit of time learning how the ''vi'' editor worked, due to its steep learning curve. This time spent up-front paid off handsomely over the years. I am even typing the draft of this article with ''vi''. Modern IDEs have a very gradual learning curve, which can have the effect that we never progress beyond the most basic usage of the tool.

-	My first step in learning an IDE is to memorize the keyboard shortcuts. Since my fingers are on the keyboard when I'm typing my code, it will save me precious seconds to press Ctrl+Shift+I to inline a variable, rather than having to navigate a menu with my mouse. These seconds add up over time, making me much more productive than when I try to do everything the lazy way. The same rule also applies to keyboard skills ~~- learn~~ to touch type - you won't regret the time invested up-front.	+	My first step in learning an IDE is to memorize the keyboard shortcuts. Since my fingers are on the keyboard when I'm typing my code, it will save me precious seconds to press ''Ctrl+Shift+I'' to inline a variable, rather than having to navigate a menu with my mouse. These seconds add up over time, making me much more productive than when I try to do everything the lazy way. The same rule also applies to keyboard skills: Learn to touch type, you won't regret the time invested up-front.

-	Lastly, as programmers we have time proven ~~unix~~ streaming tools that can help us manipulate our code. For example, if during a code review, I noticed that the programmers had named lots of classes the same, I could find these very easily using the tools find, sed, sort, uniq and grep, like this: ~~<code>~~find . -name ".java" \| sed 's/.\///' \| sort \| uniq -c \| grep -v "^ *1 " \| sort -r~~</code>~~	+	Lastly, as programmers we have time proven Unix streaming tools that can help us manipulate our code. For example, if during a code review, I noticed that the programmers had named lots of classes the same, I could find these very easily using the tools ''find'', ''sed'', ''sort'', ''uniq'', and ''grep'', like this:
		+
		+	find . -name ".java" \| sed 's/.\///' \| sort \| uniq -c \| grep -v "^ *1 " \| sort -r

	We expect a plumber coming to our house to be able to use his blow torch. Let's spend a bit of time to study how to become more effective with our IDE.		We expect a plumber coming to our house to be able to use his blow torch. Let's spend a bit of time to study how to become more effective with our IDE.

Kabutz at 09:23, 10 August 2009

2009-08-10T09:23:40Z

←Older revision		Revision as of 09:23, 10 August 2009
Line 1:		Line 1:
-	In the ~~days of Unix C~~ programming, ~~my choice of editor was vi~~. ~~The power of vi was in its simplicity: by learning a few keystrokes and unix tools (grep~~, ~~sort, find, etc.)~~ we ~~could manipulate code easily. My fellow students favored the more "user friendly" editors with mouse control. Whilst having a shorter learning curve~~, ~~the power of these editors~~ was ~~also greatly reduced~~. ~~The same applies~~ to ~~10 finger touch typing~~. ~~Investing~~ a ~~couple~~ of ~~hours of your life will make you far more productive for many years to come~~.	+	In the 80s, our programming environments were typically nothing better than glorified text editors, if we were lucky. Syntax highlighting, which we take for granted nowadays, was a luxury that certainly was not available to everyone. Pretty printers to format our code nicely were usually external tools that had to be run to correct our spacing. Debuggers were also separate programs run to step through our code, but with a lot of cryptic keystrokes.

-	~~Modern IDEs offer many benefits: automatic refactoring, code layout, etc. Most of these features are available from~~ the ~~menus~~, ~~but nothing beats~~ the ~~shortcut keystrokes~~. ~~Every~~ IDE ~~is different~~, ~~which makes it useful to learn one really well~~. ~~After conference talks~~, ~~I am frequently approached by programmers who enjoyed watching me craft~~ the ~~code so quickly using the key shortcuts. It does not matter~~ which ~~IDE you use, as long as you invest a bit of your time~~ to learn ~~it well. Memorize one new~~ key ~~shortcut per week and by~~ the ~~end of the year you will look like a pro~~.	+	During the 90s, companies began to recognize the potential income that they could derive from equipping programmers with better and more useful tools. The Integrated Development Environment (IDE) combined the previous editing features with a compiler, debugger and pretty printer. During that time, the mouse and menus also became popular, which meant that developers no longer needed to learn cryptic key combinations to use their editors, but could simply select their command from the menu.

-	~~During~~ code ~~reviews~~ and ~~when I want~~ to ~~make changes~~ to ~~lots~~ of ~~files~~, some ~~basic unix tools are still invaluable~~. ~~Besides knowing our~~ IDE very ~~well~~, we ~~should~~ also ~~know grep~~, find, ~~uniq~~, sort and vi.	+	In the 21st century, IDEs became so common place that they were given away for free by companies wishing to gain market share in other areas. The modern IDEs are equipped with an amazing array of features. My favourite are the refactoring tools, where I can select a chunk of code and convert that into a method. The refactoring tool will pick up all the parameters that need to be passed into the method, which makes it extremely easy to modify code. My IDE will even detect other chunks of code that could also be replaced by this method and ask me whether I would like to replace them too.
		+
		+	Another amazing feature of modern IDEs is the ability to enforce style rules within a company. For example, in Java, some programmers have started making all parameters final, which in my opinion is a waste of time. However, since they have such a style rule, all I would need to do is set it up in my IDE and every time that a parameter is non-final, I would get a warning. The style rules can also be used to find probable bugs, such as when we compare autoboxed objects with "==".
		+
		+	Unfortunately modern IDEs do not require us to put in a lot of effort in order to learn how to use it. When I first programmed C on unix, I had to spend quite a bit of time learning how the VI editor worked, due to its steep learning curve. This time spent up-front paid off hansomly over the years. I am even typing this article with VI. Modern IDEs have a very gradual learning curve, which can have the effect that we never progress beyond the most basic usage of the tool.
		+
		+	My first step in learning an IDE is to memorize the keyboard shortcuts. Since my fingers are on the keyboard when I'm typing my code, it will save me precious seconds to press Ctrl+Shift+I to inline a variable, rather than having to navigate a menu with my mouse. These seconds add up over time, making me much more productive than when I try to do everything the lazy way. The same rule also applies to keyboard skills - learn to touch type - you won't regret the time invested up-front.
		+
		+	Lastly, as programmers we have time proven unix streaming tools that can help us manipulate our code. For example, if during a code review, I noticed that the programmers had named lots of classes the same, I could find these very easily using the tools find, sed, sort, uniq and grep, like this: <code>find . -name ".java" \| sed 's/.\///' \| sort \| uniq -c \| grep -v "^ *1 " \| sort -r</code>
		+
		+	We expect a plumber coming to our house to be able to use his blow torch. Let's spend a bit of time to study how to become more effective with our IDE.

	by [[Heinz Kabutz]]		by [[Heinz Kabutz]]

Kabutz at 07:18, 10 August 2009

2009-08-10T07:18:52Z

←Older revision		Revision as of 07:18, 10 August 2009
Line 1:		Line 1:
-	In the days of Unix C programming, my choice of editor was vi. The power of vi was in its simplicity: by learning a few keystrokes and unix tools (grep, sort, find, etc.) we could manipulate code easily. My fellow students favored the more "user friendly" editors with mouse control. Whilst having a shorter learning curve, the power of these editors was also greatly reduced.	+	In the days of Unix C programming, my choice of editor was vi. The power of vi was in its simplicity: by learning a few keystrokes and unix tools (grep, sort, find, etc.) we could manipulate code easily. My fellow students favored the more "user friendly" editors with mouse control. Whilst having a shorter learning curve, the power of these editors was also greatly reduced. The same applies to 10 finger touch typing. Investing a couple of hours of your life will make you far more productive for many years to come.

-	Modern IDEs offer many benefits: automatic refactoring, code layout, etc.	+	Modern IDEs offer many benefits: automatic refactoring, code layout, etc. Most of these features are available from the menus, but nothing beats the shortcut keystrokes. Every IDE is different, which makes it useful to learn one really well. After conference talks, I am frequently approached by programmers who enjoyed watching me craft the code so quickly using the key shortcuts. It does not matter which IDE you use, as long as you invest a bit of your time to learn it well. Memorize one new key shortcut per week and by the end of the year you will look like a pro.

-	~~Most~~ of ~~these features are available from the menus~~, ~~but nothing beats the shortcut keystrokes~~. ~~Every~~ IDE ~~is different, which makes it useful to learn one really~~ well.	+	During code reviews and when I want to make changes to lots of files, some basic unix tools are still invaluable. Besides knowing our IDE very well, we should also know grep, find, uniq, sort and vi.

-	~~You can tell a lot about a person~~ by watching them work with their favorite IDE. Having presented over a hundred Java courses to experienced programmers, it still amazes me how many fellow programmers have spent almost no time getting to know the short cuts to their particular IDE.	+	by [[Heinz Kabutz]]

		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]

-	more to follow	+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Kabutz: New page: In the days of Unix C programming, my choice of editor was vi. The power of vi was in its simplicity: by learning a few keystrokes and unix tools (grep, sort, find, etc.) we could manipul...

2008-11-12T15:08:57Z

New page: In the days of Unix C programming, my choice of editor was vi. The power of vi was in its simplicity: by learning a few keystrokes and unix tools (grep, sort, find, etc.) we could manipul...

New page

In the days of Unix C programming, my choice of editor was vi. The power of vi was in its simplicity: by learning a few keystrokes and unix tools (grep, sort, find, etc.) we could manipulate code easily. My fellow students favored the more "user friendly" editors with mouse control. Whilst having a shorter learning curve, the power of these editors was also greatly reduced.

Modern IDEs offer many benefits: automatic refactoring, code layout, etc.

Most of these features are available from the menus, but nothing beats the shortcut keystrokes. Every IDE is different, which makes it useful to learn one really well.

You can tell a lot about a person by watching them work with their favorite IDE. Having presented over a hundred Java courses to experienced programmers, it still amazes me how many fellow programmers have spent almost no time getting to know the short cuts to their particular IDE.

*more to follow*