I have a confession. I use Vim. Yes, I'm one of those guys. "But why?" you ask. "Why would you use a text editor when there are so many kick-ass IDEs out there?" Like Eclipse, or Visual code, or any of the fantastic JetBrains products? What about smart completion? What about symbol search? What about refactoring tools and framework support?
Well, let's talk about smart completion. For you, non-programmers out their, smart completion is kind of like when you're typing in Microsoft Word and the program tries to complete words for you. You start to type cheese curd and word suggests cheese cake. No, Clippie, I don't mean cheesecake. I mean, cheese curd. Now get out of my effing grill. Well, with a modern IDE like say, IntelliJ. If your cursor goes to the end of a symbol that represents an object, the IDE will raise a flyout that shows you all of that object's members. If you have an instance of say Gregorian calendar, IntelliJ will helpfully suggest "setSeekday" as the operation you're looking for. No, I don't want to set a weekly date on my Gregorian calendar. Now get out of my effing grill. Here's the thing. Code completion, IntelliSense, or whatever you want to call it, only provides value if you don't really understand the API you're trying to use, which brings us to an interesting chicken before the egg problem. Does using an IDE keep you in a state of perpetual infancy? If you can't write code without being spoon-fed by your IDE, do you really know what you're doing?
Now, I know, I'm not gonna convince anyone to make the leap to Vim or Emacs for coding but here's some food for thought. For a few years, I worked in Manhattan. Public transportation in New York City is pretty good. But if you want to get someplace fast, it's usually much faster to walk, especially if you want to go across town. So I walked everywhere. It was awesome. If you really want to get to know a city walk around. When you're walking places, you really notice your surroundings, you get to know all the weird alleys and shortcuts, you find hidden gems off the beaten path. And when things change, you notice if a storefront got a facelift, or if there's an unfamiliar dumpster outside the bodega where you buy snacks. You build a mental map and continuously decorate it with new observations.
Nowadays, I live in a suburb. I drive to work on highways. I'm basically a tourist. I know how to get from point A to point B, but I don't know either place very well. Truth be told, once I get to the parking lot of my office building if I were to venture a block or two in any direction, I would be utterly lost. Yeah, I got where I wanted to go. But I learned nothing along the way. That's the risk you run when you become dependent on an IDE to get you from point A to point B as quickly as possible. Yes, you might gain a little speed, although that is certainly debatable. But for the sake of conversation, let's assume that an IDE affords you a marginal gain in productivity.
The question you need to ask yourself is what is the opportunity cost? Well, a few things jump out at me, consider this. When I worked in Manhattan, I would frequently be stopped by tourists in need of directions. How do you get from Mark Twain's house to the Bobst library at NYU? Well, you can take a shortcut through Washington Square Park. It feels good to be a helper. But if you get everywhere by Uber or by the bus or the subway, you can't actually help the lost and bewildered tourist find the shortcuts. Yeah, you know how to get from point A to point B. Unfortunately, you don't know how to get from point A to point C, you sacrifice speed for depth. And as a result, you can't help when others get lost.
Okay, so what about when you get lost, because it happens sometimes? Well, if you walk around a lot in the same neighborhood, you start to understand the underlying design of a place, the way the streets are laid out, numbered, and named. That didn't happen by accident. They are all outcomes of design. So when you get lost, all is not lost. If you understand the underlying design. You can reason your way out of a problem, you don't need a GPS map or even a compass to know that the avenues in Manhattan run north-south. If you also know that the avenue numbers get bigger as you go east to west, well, then you have a mental model that will allow you to get around pretty well. Similarly, if you understand the underlying design of a bit of code, you have a mental model that allows you to reason about problems. If you can't reason about problems, where does that leave you? Your fancy IDE with all those cool features isn't coming to save you when you get lost, you have no resort but to copy and paste top-rated answers out of Stack Overflow and hope for the best.
And that brings me to my final point about IDEs. If you ever noticed how people move around in museums, they don't sprint to and fro. People wander from gallery to gallery. They have their hands behind their backs. They gaze and absorb. When you leave a museum, you are changed. That's why art is so powerful and important. The artist influences by changing your aesthetic perspective. Well, a lot of software is beautiful, profoundly, breathtakingly beautiful, and beautiful code doesn't happen by accident. Certain people work extremely hard to make beautiful code. I'll submit to you that you could learn a lot from reading beautiful code. But you have to take the time to look. Unfortunately, you're not learning shit from the window of an Uber. How can you? You're going 50 miles an hour. Everything is just a blur.
Jack Kerouac was famous for the frenetic pace of his writing. He wrote extremely quickly and never looked back at anything he wrote. If you've ever read On the Road, this should come as no surprise. Many of Kerouac's contemporaries were unimpressed with Kerouac's work but Truman Capote once said of Jack Kerouac, "That's not writing, that's typing." Something to think about the next time your IDE completes your thought for you.
I'm hiring software engineers! Check out the jobs page to see my open positions.