I used to push production code -- back in '99 when I worked at GE, my buddy Jason taught me how to code, and I was fascinated by it. I spent much of the early 2000's building dynamically driven websites with mySQL back-ends for several startups, including an e-commerce website along with its back-end administration and inventory management system (screenshot below). We had to host the e-commercie site at a colo facility. That was way before AWS, or Stripe, or any of the technologies today that make something like that much easier today.

While it's been years since I've pushed any production code, that experience has left me with a deep appreciation for what engineers do. Most business people don't have that, and it hurts them in ways they don't even realize. As Paul Graham wrote in his essay "Maker's Schedule, Manager's Schedule," it's easy for managers to completely torpedo the productivity of the "makers" -- those who are actually building the business and really creating value.

It's for this reason that I really encourage managers to learn to code. It's even in our Socialize manifesto, point #1: "Every new hire has a 'Hello World' in at least one language."

The first thing that a manager will find is that coding is a lot harder than they imagined it would be. Most managers have an attitude like "Yeah I could code if I really wanted to, but I can add much more value by being a manager." That attitude is actually a smokescreen for an insecurity: If it's so easy for you to learn how to code, then let me see you do it. Because it's not easy. It's hard. And it's even harder to do it well.

The second thing a manager will find is an appreciation for leaving the engineers alone. The only way I can really describe coding is like scuba diving: It takes you a while to reach depth. Coming up for air completely destroys the dive, and it takes a while to get back down to depth. Interruptions to developers' trains of thought render them wildly less effective. So the next time a manager has a "quick question" to ask a developer, they'll think twice about blowing a hole in the developer's day. (This point is related to a related rant of mine, which is that really, internal departments should be communicating with each other via APIs, which means if the sales support team needs something from an internal database, they'd create a structured request through a pre-defined communication channel and the result would be given to them as an API endpoint. Not only does this allow the engineering team to prioritize its work in an agile scrum-style fashion, but the result is also something that anyone in the company can use, and if it's successful internally, the API can be bulletproofed and documented for external use. This is how Amazon created AWS; a great story on that is here.)

But most importantly, a manager who codes will be much more efficient and effective in his or her daily role. Just being able to hack a script together provides a tremendous ROI. A manager who codes will be appreciated by the engineers in the organization and will be able to force multiply his or her time in ways that a manager who doesn't code wouldn't even begin to understand.

So get to it. Learn to code. Being able to build things in this digital economy is the most valuable thing you can do, no matter who you are. Here's a great video that showcases some of the advantages of learning to code: