|
Err, yes. Sadly we don't always get the time.
|
|
|
|
|
While I think it's a good idea that the manager understand the code I don't necessarily thin it critical.
As long as there's more than one person that understands the code he should be in good shape.
|
|
|
|
|
Developers should develop and managers should manage.
However, a manager of developers should have been a developer.
People who have managed bakeries or banks are plainly not suitable to manage software developers.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
Quote: People who have managed bakeries or banks are plainly not suitable to manage software developers.
Are you sure? Donuts and money are pretty good motivators. 
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
 
Getting information off the Internet is like taking a drink from a fire hydrant.
- Mitchell Kapor
|
|
|
|
|
I agree and it's not just something that applies in the coding world.
Any manager needs to be able to understand what it is his/her minions do, how they do it, what they do it with, pitfalls, etc. etc. which by and large means experience in that role.
As a mainframe engineer back in the day, the best managers I had were the ones who moved up from the ranks. There were a couple who moved in sideways and were bean counters by trade. Worthless tossers the pair of them. Really good at adding up numbers but clueless as to how an engineering service actually operated on the ground.
If your neighbours don't listen to The Ramones, turn it up real loud so they can.
“We didn't have a positive song until we wrote 'Now I Wanna Sniff Some Glue!'” ― Dee Dee Ramone
"The Democrats want my guns and the Republicans want my porno mags and I ain't giving up either" - Joey Ramone
|
|
|
|
|
If they can, they should, even if just to keep up to date with the tools their teams are using. Managers who cannot code at all, are a hazard to everyone around them.
Christian Graus
My new article series is all about SQL !!!
|
|
|
|
|
I wouldn't take it that far, but I believe that managers that lacks the knowledge, aren't able to take the right decisions.
|
|
|
|
|
Yes, agreed.
Christian Graus
My new article series is all about SQL !!!
|
|
|
|
|
If there are differences in opinion about architectural decisions and those differences are between his senior architects or developers it would be really nice if he had a notion about what is going on.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
One of the best bosses I worked for was a developer who got promoted to VP of Engineering and no longer had time to do what needed doing.
Another good boss I had had become Director of IT and only had time to work on the UI. I worked on everything else.
But it seems that to a great extent, that article applies mainly to small teams, where the loss of one developer is a high percentage of the force.
For larger teams, it seems less critical that the manager be able to code, but ease of bringing new members in is still important.
This space intentionally left blank.
|
|
|
|
|
I'm just changing my job role from developer to a more management-y position atm; one of things I'm really happy about with my new employer is that it's mandatory for me to maintain my development skills. For me, I don't think that management need to be writing 'production' code as a matter of course - but they need to be capable of doing it [competently], and able to function at that level. Learning a new skillset doesn't mean abandoning old ones!
--
What's a signature?
|
|
|
|
|
Good luck to you.
I made the transition years ago, and I still code and manage.
I cannot imagine managing developers without understanding the process, the people, the style.
Although I have to recommend learning about management, like you do a language.
You need to determine your management style, and approach to handle your team.
I still like the "One Minute Manager" book. It shaped me when I was young, and just after
having had a terrible Software Development Manager. You know, the one that teaches you
what you WILL NEVER Do if you ever manage people!
|
|
|
|
|
Thanks for the advice, that's very useful
--
What's a signature?
|
|
|
|
|
Define IT. IT in inside parlance, is typically not engineering, but handling the company infrastructure, in which case, the best I've worked with can code scripts and that's about it. They could, however, make VMWare and routers proverbially dance and sing.
I believe Engineering managers should have done some engineering, though simply respecting engineering may be good enough for a rare individual. The best manager I've ever had by magnitudes was a former hardware engineer. The second best I had couldn't write code if his life depended on it, but could close sales like no tomorrow and the customers loved him. The third best was a working software engineer who spent most of his time coding, but he was a rare creature. ALL respected engineering and the time it takes, could quickly grasp the core of issues and, most importantly, enabled us engineers to do our jobs and shielded us from the bullshit of upper management.
(Thinking more about this, I believe the qualities that make a good manager and a good developer are different. Great managers not only need to see the big picture, but need to know how to handle people. They need to know how to digest information given them and be able to distinguish priorities. Most importantly, they need to have a really good BS meter. I've worked with few engineers, and even fewer brilliant engineers, who show these qualities.
On the flip side, the one common trait amongst the terrible management I've had is that they didn't respect the engineering process. In general, they thought that simply demanding results was sufficient.)
|
|
|
|
|
I think the size of the group is the determining factor. I manage a software development group that has 25 members. I started as a hardware guy, became a programmer and eventually moved to management. Being a good programmer will no longer advance my career. But being a better programmer and having new programming opportunities are essential to the careers of the other members of the group. Every time I code, make architectural or design decisions I am taking opportunities away from my staff. I have to trust that they will make the correct decision and will not be afraid to say they made a mistake and correct it. If experience shows me that I cannot trust their decisions then I need to remove them from the group. Sometimes it is like teaching your teenage child to drive. Very scary. But when you get good programmers who are not afraid to make decisions and implement them when and where they need to be made the results can be magical.
|
|
|
|
|
My Former Bitch Supervisor From Helltm was a prime example of promotion to get her out of the way. However her lack of understanding practices and principles was a continual drag on our productivity. When I temporarily took over her position during her leave of absence we kicked ass and took names. I viewed myself as a facilitator to give everyone what they needed and as a load leveler. We set up a weekly cycle of Monday thru Thursday to do bug fixes with Friday spent preparing documentation while the dedicated compiling machine produced the next image. Monday morning we'd present the package to QA and continue work. Towards the end, the QA department was begging us to slow down, they couldn't keep up with testing of the scripts we gave them and their regression testing. Unfortunately I didn't have any time to program.
My current position as manager has me programming and until some of my new hires I found myself teaching the staff as well. We had one guy who used to snow his previous manager by defending his poor code with the phrase, "...unless you know a better way..." Unfortunately for him, I did. He eventually came around and still used the same phrase, but this time he was looking for help.
I don't limit my staff to what I know like my Former Bitch Supervisor From Helltm did, but I at least try to get rational explanations of how the code works from them. One former worker used to give status reports that had me sniffing the air and wondering if it was bullshit I was smelling. I think I succeeded in not smiling when he gave me his resignation. He had worked on a project for over a year without producing anything under the previous manager because the manager couldn't smell what I did.
Psychosis at 10
Film at 11
Those who do not remember the past, are doomed to repeat it.
Those who do not remember the past, cannot build upon it.
|
|
|
|
|
IMHO, managers got promoted because they could NOT code, did NOT want to code, or for some other similar reason -- why is it necessary? If you follow some kind of Agile/Scrum development model, why not make the manager the "product owner" if they need to feel more involved and part of the team? There is a reason for "division of labor" even in software development. 
David
|
|
|
|
|
|
or the Peter Principle -
[^]
David
|
|
|
|
|
My best manager did not know how to code at all. He discussed target dates and requirements with me before committing to anything, then let me manage my own development process. My worst managers knew how to code once to some degree, but did not keep up with current development processes or capabilities with our systems, so often made unreasonable demands and "standards" that they would not budge on, because they thought that they understood things that they really didn't understand. In spite of my experience though, I would like a manager who understood what I was talking about, but flexible enough to see that things change and that it would be best to adapt.
|
|
|
|
|
Whenever possible why not code, but the manager side of the role has to come first. By this I mean that if someone in the team has a problem or a question, you have to deal with that first, because by resolving that problem you are freeing them up to do their work.
And that is where the difficulty lies, because if as a manager you are working on a critical coding task, you have to leave that to deal with the problem or questions or help that is needed by team members.
I therefore find it best when I am working on non critical coding tasks that are of lower priority of that than team members are working on. This way I keep my coding skills up to date and am able to put the coding task on hold when a team member needs help.
|
|
|
|
|
Spiral Galaxies in Collision [^].
From over the weekend. Enjoy.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
Has the presence of some evil dude looking at us from space as if he were menacingly contemplating colliding with us!
And, if the galaxies are bazillions of light years away, the collision could've already occurred!
|
|
|
|
|
They are 80 million LY away: http://en.wikipedia.org/wiki/NGC_2207_and_IC_2163[^] so there is a while to wait for the final dénuement. 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
