"Every time I open my editor, I’m reminded that I can’t just “jump in for a few minutes” the way I can with my usual work – either because coding isn’t like that, or because I’m not good enough yet."
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."
I love it that our CTO still codes, debugs and shares the pain as everyone else. He would even apologize, as anyone else for making mistakes here and there.
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 run a small interactive agency, half my time is doing business and half coding. The single most difficult thing I have to deal with is the context switching. When I'm "taking care of business" its a crap load of little things which need to be done, as opposed to code which I need to do in a large multi-hour block. I can never intermingle the two or the coding just doesn't get done. My business partner (creative director/designer and runs our NY operation - I'm in SF.) can now tell on the phone if I'm in "coding" mode and has learned to leave me alone.
Yes, this is a stellar pg classic. But , oddly , folks who get the aha behind it are the makers. Paul probably needs to do a new essay for " powerful people " that somehow with his usual, subtle cunning helps them feel even more powerful + leave the makers alone.
And this is exactly why I love the fact that my two bosses (direct manager and department VP) write code on a daily basis (well, in the case of the VP, it's probably weekly at this point, but he's been in the trenches long enough).
This is _the_ reason I'm picking up coding again after a 7 year hiatus. I know instinctively that without it, I will never be able to understand the mindset and workflow and needs of coders, which is essential when working with a team of hackers.
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.
I was in a medium-sized company where the VP of Engineering started attending design meetings. Talk about a huge waste of time and a huge distraction.
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.
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.
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
What you say makes sense. But if someone were to learn a little math and then proceed to tell mathematicians how to solve theorems they would be labelled a crackpot.
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.
I have a similar story except that the executive is the founder and created the original web site over a decade ago. Now, he's not a bad programmer but he's not really a good one either, where he excels are ideas and architecture.
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. :(
I hope he gets to see your comment b/c its not something that would get mentioned by his coders. So do you feel like its a good idea on paper for managers to know the nature of the programmers work that well?
A good manager should be technical so that you can engage him in a very technical conversation and he should be able to follow along. But I don't think you specifically need to be a coder to do that, I've seen other good managers come from non-programming backgrounds.
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.
Its always a good thing to know the work that your employees do, it helps evaluate their strengths and it helps in understanding the priorities of their requirements. I remember a manager at one company saying that programmers liked to have two monitors because it made them 'look impressive.' I asked if they really thought that reason really entered into the top 10 for the request and they were convinced that since they could do their entire job with just a lap top screen than more than a single big screen was a waste. Sad, so very sad.
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!
Even though Roy has stellar academic credentials...
"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.
He also follows that sentence with a really good point "You trust your people, you know you could never write the way they do, but it would still be good to be able to read."
lately i wonder if these "biz guy learning to code" posts are harmful. I'm not sure which is worse: a product owner who can't code, or a product owner who thinks he knows how to code.
"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.
As long as you understand where your team's talents are best deployed, a wider knowledge base of your product is only an advantage as a manager. To your point edw, yes when someone attempts to add value where they have no skill, frustration ensues. But, when you can better communicate with your team and understand their plights (via a knowledge of your tech), then expectations align and make for a better team workflow (emphasizing wccrawford's point).
There are few things out there as infuriating as as non-technical co-founder (or say, someone higher up the chain if you're reporting to someone) who's written some crappy code once or twice in his life and then believes he's ready to tell professional software developers how to write code.
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?
I remember being taught BASIC in elementary school as part of the standard curriculum, which was now a long, long time ago. And this was just a small rural school, literally surrounded by farms. My parents both talk of learning how to program on punchcards in high school. They struggle to use a computer, let alone program one, so I'm not sure it was of any real benefit to them.
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.
I might add that the real value and challenge of learning to code, beyond stacks and algorithms, which are domain specific, is the ability to abstract problems and find generic solutions.
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 :)
What would be the utility in doing this other than increasing the number of "coders"? I would make the argument that there are other, more practically applicable areas of study that would benefit the general population. Basic physics or even basic anatomy and physiology comes to mind.
What is the utility of teaching people arithmetic other than increasing the number of "mathematicians"?
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.
One utility would be that software would be a lot less brittle and a lot more flexible since you would know that a significantly greater than 0% of your audience could use the sandboxed non turing complete language that allows intelligent communication of triggers to the application.
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.
let's say an end user of your app is having a problem getting it to work. would you rather that end user be a developer, or someone that doesn't know anything about development?
Computer programming should be offered as an AP similar to how AP Statistics is in high school. I ran out of math to take in High School - the logic of calc-based psychics and advanced calculus trend well with object-oriented programming.
AP Computer Science exists, they provided it at my high school. At the time, it was taught using C++. I believe they use Java now.
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.
Besides that AP CS exists, if you are running out of APs then you should be taking classes at a local community college or even actual university. AP is already putting intro level college classes into highschool, it doesn't really make sense to just offer all college classes in a highschool.
It's great that he came to the realization that coding isn't something you can do for 15 minutes, in between meetings. Most of the managers at big corporations don't seem to understand how meetings can just kill off a day's productivity for a programmer.
While this is a good thing my immediate concern is that a little knowledge can be a dangerous thing.
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.
I'm assuming as President of IGN, Roy Bahat already has his hands full managing day-to-day operations. I'm sure he's intelligent enough to take up a task like "learning to code", but can he really put in the time to be a proficient programmer? It takes a full time CS student about a year before they really understand the logic of writing program...and then an additional 5-10 years (at least) to become the excellent programmer that a place like IGN would employ to engineer video games...
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.
He taught a class at UC Berkeley this past spring. The course was excellent, and he brought in some amazing industry speakers. I wondered the same thing about how he balances.
What I really like about Roy's post is that he understands that programming is a way of thinking and he acknowledges that it's different than what he's used to. Programming teaches me how to think about abstract problems and to come up with solutions, and a series of steps to implement the solutions. The coding part is mostly boring and mindless typing if you have done the first part well.
I would rather work for a manager that understands this way of thinking over one that doesn't any day.
As I see it, everyone in a software company should know how to 'code' at a rudimentary level - and appreciate the process and skill required by the company. Analogies anyone?
I really like that he wants to learn something new.
And I think it's also quite important that we, coders, try to learn something from the other camp too!
I've always found that hackers should hack and business people should just conduct business, but each with as deep an understanding of the other as possible. One of our co-founders both programs and helps on the business side, because he insists on it, and it just doesn't work. However, his understanding of what we do from a business perspective and our non-tech cofounders basic understanding of programming has proven crucial to proper planning and communication.
The danger in the president learning to code is that no one wants to tell him his code sucks, then he releases/deploys it and fucks shit up. All I can say is "good luck".
This is a pretty unfair. He seems self-aware enough to know he probably shouldn't be releasing stuff to production. But there is a long way from "learning to code" to "releasing production code."
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.
Yeah! He really shouldn't learn to think more logically, or understand what his employees are going though, or even just enhance his personal growth by learning a new skill. He should be all about the ideas and stay out of programming so that us coders can take our time and bullshit our way out of everything.
I don't think you're being fair. If you've never had a boss who personified the saying "A little knowledge is a dangerous thing," you've been very lucky in your career. I had one who would literally tell us to stop what we were doing, institute a whole spate of inefficient methods that we had to follow[1], shout down any objections because "I know a little bit about this stuff," and then leave so he didn't have to witness the fallout. It literally turned a one-hour task into a two-day project.
[1]: 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.
I'm sorry, but he's a fucking moron and an asshole. Even if he'd never learned to code he'd still be screwing up your day. You're confounding his personality with the fact that he learned some programming.
As I see it: If your boss is an enormous idiot you have a problem anyways. I can't imagine someone, a manager no less, to act that stupid. How did he manage to keep his job?
In this particular instance, it was a small company and the top people were the owner and his relatives. But it happens at all levels. Usually it's not quite that blatant, but assuming you know what's involved in other people's jobs is a common failing for humans in general. It just happens to be particularly damaging when it's a manager because they have the ability to act on their misconceptions.
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."