The text editor is one important element of the software tools approach to software development. IDE's violate that approach. The premise of software tools is to do one thing well, in a way that can be combined with other tools. IDE's attempt to be all things to the developer. IDE's are not portable. I can use VIM to write in any language on any platform with any other toolset. Further if VIM is not available - VI is and my VIM knowledge remains useable. Alot of the work I do is with embedded systems - these often do not have GUI's. I can ssh to an embedded system write code in VIM and build it on the target. Further. I use the same tool for everything. I write code in VIM, edit Makefiles, edit error logs, edit shell scripts, edit configuration files, .....

50% of the work I do is Linux work. My primary system - my laptop runs Linux. When I am employed rather than consulting or have to work on site, I often have to work in the windows world. I run Windows VM's on my linux system, or use Windows desktops because I am required to. Most of my work is still done from Linux. It is always my responsibility to figure out how to integrate myself into the windows culture, and when anything goes wrong - fingers are always pointed at me. Each of us is different. I can change from one programming language to another in a few minutes. I can learn a new language in a day. Changing text editors takes me years. Moving from windows to Linux took me about 3 months. It was hard, but I have never looked back. Using a windows machine today leaves me feeling like I have all thumbs. I know what I can make it do. I know the capabilities of windows quite well, but finding where the network configuration applet is, or other tasks I can do easily in Linux take many times longer under windows. Some parts of that are because Linux is mostly better. But mostly it is just because I know what I am doing. I think that businesses that support a broad infrastructure are wise. I think it is a mistake to lock yourself in to one OS. I think that just like porting code to a different OS improved the code, the more diverse an infrastructure is the more robust it is.

Everybodies different. Many of the projects I work on are incredibly complex. It takes hours to download intricate understanding of the code and the problem into my brain, and then I have a few hours of very high productivity before the race to exhaustion sets in. When I restart the process the next day, I start without the deep understanding that enabled high productivity and have to be careful not to try to do too much until I once again have that full comprehension of what I am doing.

The most important thing you can do is write good clean simple easy to understand code that cleanly solves the problem. Related you need to understand the problem you are solving, and write code that reflects that understanding. Getting the last 2% out of the code is a very late in the game process, and often never happens. The primary reason that efforts are made to optimize code are that the code is bad to begin with. Further any actual need for optimization of well written code is increasingly non-existant. 40 years ago, it might be necescary to get another 5% out of something to actually be able to make it work on a 2mhz z80, If you have code that is performance constrained on a quad core 3Ghz 64 bit processor - either you are trying to manage plasma containment in a fusion reactor, or you do not know how to code.