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."
"I’ve gone back and forth on whether managers should code and my opinion is: don’t stop coding. Each week that passes where you don’t share the joy, despair, and discovery of software development is a week when you slowly forget what it means to be a software developer. Over time it means you’ll have a harder time talking to engineers because you’ll forget how they think and how they become bored."
Fuckin awesome chap!
We used to have a TD long time ago, russian dude, that somehow forgot how to run Visual Studio, yet he was just a coder year before that. Amazing transformation!
I despise the notion of the manager without technical experience in the field and I'm desperate to avoid becoming one in the future. We're living in a software dominated world, and everyone who's going to be involved in a company's strategic decision making should be conscious of how programming works, what it can do, and what it can't do.
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.
Zuckerberg is a college drop out that started Facebook. We don't really know how his skills compares to others. It's easy to assume he his above average, but I have no idea what kind of code was behind the earlier Facebook versions.
My guess is that the Facebook that Zuckerberg started is so "simple" compared to the current version that it requires a different skill set. "Anyone" can throw together some some php+sql code to make Facebook v1.0, but that doesn't mean that they are actually an above average programmer. I'm not saying that he couldn't be an excellent programmer, but he has probably lost a lot of programming hours compared to others that were at his college at the time
A person who cannot enrich themselves by learning programming in order to better able communicate their ideas without tempering it with humility and awareness of the vast size of the subject has problems that "learning" to program only made more clear. Like violence and videogames.
Indeed I would argue that they did not learn to program for communication or enrichment purposes. Great Insecurity and megalomania come to mind. That person in a more perfect word should not be leading you.
We had been working for months on moving the site to a more modern platform (RoR) when he called us into a room and told us that we were going to move to PHP and Java. Everyone just looked at him like he had just sprouted a second head.
Sometimes its bad for executives to learn programming. :(
At the very least he'll become more efficient communicating with his dev team & management than before.
That being said, my best manager was a former coder-turned-manager. When he was coding, he wasn't the most brilliant coder in the group, but neither am I. He knew about the coding process and how long things take, etc, so that was genuinely helpful.
But what made him my best manager was because he knew how to keep us shielded from the BS from customers and upper management, and he genuinely cared about our professional and personal development. This garnered a great deal of loyalty from me and my other coworkers, so he was able to get a lot of good work from us in the years that I was with him.
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.
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."
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.
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?
Though once you've covered basic algebra, you're basically there. Coding itself is super easy. The more challenging problems come from understanding the nuances of your stack (which comes with experience) and understanding more complicated algorithms (which is rooted in higher level math). That all requires much more time and effort than an intro course in elementary school.
IMO, that sort of skill rewires your brain in a way that helps you solve the root causes of problems, and not just patch the symptoms.
It would be a brave new world of child prodigies & parentheses, of Lambda symbols drawn on the wall in crayon & kids playing jump-rope games while singing songs about side-effects & mutable state :)
This highlights an important aspect of the immaturity of software development, we lack the terms to even talk about it with very much detail. We don't put everyone who knows any amount of math in the same bucket, we don't even put people who know vector calculus and differential equations in the same bucket, we appreciate that there are many grdations of skill and differences between people who know a thing to some level of competence and people who use that knowledge intently in their occupation.
The same is true with programming. Just because someone knows the basics of programming doesn't mean they are a software engineer. It doesn't mean they are capable of building or working on large, sophisticated systems. It doesn't mean that they necessarily must take up programming as an occupation either.
Similarly, taking a wood shop class or learning basics of automotive maintenance doesn't make one a carpenter or a mechanic. But that doesn't make those skills useles either.
Don't get me wrong, it would make the jobs of those in technology a bit easier. But I think that there are better uses of resources.
Another benefit would be limiting the space a user places on the possible actions of your program. By expecting less magical behaviour and constraints based on knowledge of basic limits of software; actions will be more robust, limitations more likely to be intelligently worked around till a fix is had and feedback may even be more meaningful and suggestive.
Maybe not the ideal choice of languages, but nonetheless, I did feel much better prepared than my peers when I started taking programming courses in college.
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.
The president was a coder and always wanted to work on features that had a strict deadline for our clients. He would give us the code a few days before and we would have to break our backs to fix it.
He also refused to check anything into SVN.
You tell him!
: The details of the rules are kind of specific to the domain, which is not primarily software, but think along the lines of "All code must be written in Word, since I know it well, and no weird 'makefiles' or anything else that's hard to read. Oh, and since code-sharing is important, everything has to be printed out in triplicate." It's that kind of inefficiency.