Should managers know how to code? | Hacker News Reader

Should managers know how to code?

scottberkun.com

23 pointsdan_sim11 comments

I've actually had some experience on both sides of the table.

When I did my first software startup I had no idea how to code, but since I'm pretty good at convincing people, calling bullshit, diplomacy, etc. I managed to get funded and got together a development team. I thought I had a pretty good grasp on what needed to be done, timelines, etc.

Fast forward some years. I've learned to code (Not a genius by any stretch of the imagination, but I know the basics) and I simply cannot comprehend how I could have managed a software company without knowing how to code. There are so many things that seem obvious now that I completely and utterly missed that it's amazing we ever got anything done.

A rewrite of Eric Raymond's famous quote captures it pretty well: "As a manager, coding is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better manager for the rest of your days, even if you never actually code a lot."

What exactly was it that you learned that made you a better manager? Being able to judge what's easy and what's a lot of work (especially changes)? E.g. some people think that changing all text to a different font size is a lot of work, so they ask you to only change the text size in X Y and Z, which actually is more work...

I learned exactly what you're pointing out. Also to better engage in a two-way conversation about the product, which features should be implemented, why we should or shouldn't do something based on technical merits, etc.

I've always had a lot of respect for people that know stuff I don't and if they have good reasons I'll go with their judgement in their area of expertise. But it's a lot easier to engage in a meaningful conversation when you actually know what you're talking about.

At my last job (doing .NET Web Dev), I spent the first 2 years under a manager who knew absolutely nothing about programming or really anything technical for that matter. He was, for all intents and purposes, originally hired as a henchman to weed out bad employees because the CEO hated being the bad guy. That made him the COO and as such, the head of IT as well because of how the company was strucuted (or not structured).

The last 2 years saw me working under someone who had been programming for a living for many years. While he was, by his own words, a bit out of his prime and behind the times, the difference between working for the two was night and day. Deadlines became more attainable, requirements became more realisitic and when difficult decisions arose we had someone who could go to bat for the IT department as apposed to someone who always sided with the "sales" portion of the business.

In my mind, anyone directly overseeing a developer should know how to program as well. In small organizations and start-ups, that's not always possible, but if you're somewhat established and you have an IT/IS director, manager, CIO or what have you that can't program a lick .... I think there's an issue there.

Yes, they should. Programming languages have these mysterious features called "loops", "conditionals" and "recursion". Without an intimate knowledge of these, you just can't understand why your subordinates do what they do, and you certainly won't have the ability to judge the accuracy of estimates.

Does this mean that managers should be promoted from within the ranks of programmers? Yes, that's exactly correct. Should managers be "non-technical"? Absolutely not. It just doesn't work.

"/Absolutely not. It just doesn't work./"

So you're saying then that it has never worked? That's a pretty big assumption.

I am non-technical and I think I fit pretty well with B) in that article. I always said that even if I did not /understand/ programming I certainly appreciated it. That meant I could appreciate how difficult something would be to implement, whereas those non-technical people who did not appreciate programming (my superiors) would ask for something they thought was simple then go ape when it wasn't implemented immediately.

I would spend hours locked away with my programming colleague while I explanied the business logic for what I needed, he would map out that database concepts. Eventually I got a pretty good appreciation for databases.

I'd admit it didn't work perfectly - as a first-timer and more or less accidental project manager I allowed us to over-complicate the project. Were I to do it a second time I would be much better at KISS.

Based on my experience I would have to say it is incorrect to say it "just doesn't work".

It depends on how you read "non-technical".

Your personal example is the story of someone who was extremely sensitive to what they didn't know, made very careful allowances for it, and in the end found out that picking up some technical knowledge was pretty much an unavoidable side-effect.

When I read "non-technical", I don't think of a brand new manager who hasn't yet gone through that process. I picture someone who has managed to stay non-technical by not having that acute sense of what they don't know, not making those allowances for it, and as a result, completely avoided the osmosis of technical knowledge.

"Non-technical", when said by a manager, usually means something like: "I don't know what you do, I don't want to know what you do, I don't respect what you do, and I'm scared of what you do."

Your "avoided the osmosis" part is essentially correct.

If anyone in the Western Canadian area wants to help make "Programming For Managers" a real course, let me know. I don't how much easier my life would be/have been if some of my previous superiors knew what the hell they were talking about (it would have been a lot, I suspect).

I'm afraid I'm at the center of the known universe (Toronto), but it you're actually up for a collab, ping me at stan decimal rogers at gmail. I may be a workaday hack at coding (at least by my own reckoning), but I have some teaching and course design in my pocket and an intense hatred of impossible schedules, surprise last-minute spec changes that mean re-architecting everything, et cetera, et cetera (in a Yul Brynner voice).

It has been my experience that direct managers of technical people who don't have at least a competent grasp of both technical perspective and business perspective are doomed, almost without exception. This is fairly obvious when you think about it, because these people are a bridge between two worlds, and need to command the respect of both.

The problem is that most managers with only one perspective don't seem to appreciate what they're missing, think they're a good manager anyway, and often receive positive reinforcement of this illusion when the side they do understand (and probably support too much, at the expense of the other side) praises them.

Reply on news.ycombinator.com