Why I'm learning to code - Roy Bahat, President at IGN Entertainment

That is the best reason for a manager to learn to code that I have ever heard. Assuming he eventually realizes that it really is because "coding isn't like that."

Because he was the VP, and kind of jerk at that, everyone acted differently in the design meetings but everyone felt compelled to answer his questions because he was the VP. He would ask obvious questions that would derail the entire process. It was completely unproductive, but he really felt he could "add value" by attending the meetings, but it was pretty obvious that his expiration date as a technical person was long gone.

There was a funny quote a few weeks ago about how Zuckerberg wanted to go in and fix a few bugs and developers were complaining because he was way slower, etc, and basically just interfered with the process.

I'm glad that the original author is interested in learning how to program, but if it means he's going to stick his nose in and start gumming up the system, then he should stop. Programmers require a certain personality type. You can't take someone in sales and think that by understanding programming that it will somehow help him. Leave the managing to the managers, leave the sales to the sales people, and leave the programming to the programmers.

It is also important though to keep track of what you don't know. It is never good when you have a manager who has been out of the thick of things long enough that they have lost the appreciation for the subtlties, trying to direct design decisions. I find this is hardest for managers where they were the primary coder on a project before it grew too big and they ended up managing it, and now it has evolved beyond their original understanding of it but they haven't realized that yet. Awkward!

"Roy graduated from Harvard College. He was a Rhodes Scholar at Oxford University, where he was also a lecturer in undergraduate math and economics."

...learning to code also involves doing projects where you run into problems and you learn and figure out how to solve those problems.

Over time.

Sometimes by spending hours on end only to have to wake up the next day with the answer.

It's certainly not just rote memorization to be tackled like learning latin or another language. Where accuracy and efficiency is not as important. And you can make mistakes and by context humans can figure out what you are saying or writing.) Or like running a ski resort and learning how to ski etc.

I think this is the most telling thing of what he hopes to achieve:

"I sometimes feel like a newspaper publisher who has to take his editor’s word for it that the articles are good."

I don't see how he will come close to devoting enough time and learning enough to make any judgment on whether the programming is good or not.

"People who are not professional programmers often don’t realize how the difficulty of writing software increases with size. Many people who wrote 100-line programs in college imagine that they could write 1,000-line programs if they worked at it 10 times longer. Or even worse, they imagine they could write 10,000-line programs if they worked 100 times longer. It doesn’t work that way. Most people who can write a 100-line program could never finish a 10,000-line program no matter how long they worked on it. They would simply drown in complexity. One of the marks of a professional programmer is knowing how to organize software so that the complexity remains manageable as the size increases. Even among professionals there are large differences in ability. The programmers who can effectively manage 100,000-line projects are in a different league than those who can manage 10,000-line projects."[1]

I had a product owner once who had an EE & signals background. He thought since he could implement a complicated algorithm in matlab, he knew how to write software. Love the guy, one of my long-time mentors, but the project didn't go anywhere and part of the reason is some really bad early technical decisions.

[1] http://www.johndcook.com/blog/2008/09/19/writes-large-correc...

There's so much attention to detail and subtlety that a well-educated engineer with years of professional experience and a vast toolbox puts into his work every day, that the active involvement of an unqualified outsider can be absolutely devastating.

Thus, I think it's great that the CEO understands in general terms what it's like to write code, but he (or anybody else for that matter) should not attempt to participate to the process first-hand in any way. You wouldn't dare help a brain surgeon with a scalpel just because you know how to cut a steak, why is it any different for the highly brittle and sophisticated world of software?

The good side is that it will help him understand how coders working under him operate and that's great, but I'm not sure it's the most efficient way to get that knowledge. Simply listening to them (and their managers / team leads), maybe reading a couple of books on the subject would allow him to understand that in a way a bit of hobby programming simply won't.

The downside is that the lessons you learn as a beginner don't automatically scale to larger projects of the sort his development team(s) are working on. I've seen a business analysts who could code a bit, or managers with outdated skills, sell a development team down the river making assumptions based on what they think they know.

So yes it's good, but it's good with caveats.

Knowing how to develop is correlated with being a good manager of developers but it's not the only way to get some of the skills you need and, at this point in his career, it may not be the best way and certainly won't teach him everything he needs to know.

My question is, what's his end goal? I doubt he'll be able to balance his job as President AND devote the time it takes to become a great programmer.

I would rather work for a manager that understands this way of thinking over one that doesn't any day.

Great post, I digging it.