
Should managers know how to code? - dan_sim
http://www.scottberkun.com/blog/2010/should-managers-know-how-to-code/
======
mixmax
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."_

~~~
jules
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...

~~~
mixmax
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.

------
WesleyJohnson
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.

------
bediger
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.

~~~
Major_Grooves
"/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".

~~~
Legion
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.

~~~
bediger
"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.

------
Rust
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).

~~~
stan_rogers
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).

------
Silhouette
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.

