Don't be afraid of code
Two scenarios of fear to discuss today.
#1. The Legacy App.
It was designed 10 years ago. It grew organically. No one wants to touch it out of fear. The code languishes as everyone searches for a way to work around the beast. Things don't get fixed. Silver bullet syndrome takes over. People would rather leave the company than fix it.#2. The Low Level Solution.
Things are slow. The most direct solution would be to just write a little C or C++. But that is not clever. It's not smart. C is dangerous. It's unsecure. Surely the Right Way would be to use a stronger typed language or a clever hack distributed across machines horizontally. We prefer it should be unused-language-X, which is Safe and Correct, not C with is Unsafe and Incorrect. It would never be to write C, which is only used by hardcore kernel and game programmers. Web programmers can't use C. That's too hardcore.These fears are bunk. These are illusions that prevent real work from getting done. It's time for managers and programmers to own up to them and get a handle on them.
* You need to fix the problem directly.
There's just no sense in indirect fixes. Indirect fixes are hacks. Or, worse, ineffective at solving the problem. If you have a legacy app that's a problem, you need to schedule the refactor. If the best fix is tackling a problem in C, then that's the best fix. Working around all of your problems is ultimately just fooling yourself.
* Be like a brain surgeon.
You know how brain surgeons know they're doing the right thing in there? They keep the patient awake and talk to them. They don't know if they're doing the right thing unless they pull on the nerve and see what it does.
Code is like that. It's an inexact science. No one can have total code awareness once it gets to a certain size. It's impossible. You need to use the tools (if your language has them) or simply be okay with breaking some eggs to make changes.
And you can't be afraid to break things. Big changes mean problems, and you have to accept them. This is where management has a large part in determining an outcome.
* Stop with the silver bullet
Beware the conversations like "OMG did you see that new open source ... THIS NEW LANGUAGE HAS... Twitter is doing it this way because..."
Stop.
Your problems are your own. Twitter is Twitter. Facebook is Facebook. Your company is different unless you're making a direct clone of those.
And adopting any solution -- internal or external -- incurs overhead. One must recognize what the tradeoff is, especially if that solution is open source and unlikely to be popular amongst other adopters (and hence fade away, like many solutions have done over the years).
* Please just use C and C++ when warranted
They're really not that hard. You can write very simple C++ using Boost and have it be a billion times better than some randomness you've twisted into a pretzel to avoid writing in C++. Again, every abstraction you add to avoid writing in these languages incurs its own overhead down the road (see the silver bullet point)
Do not be afraid*
* - Is written 365 times in the Bible? What's up with that.