Slashdot Mirror
The Programmer's Path To Management
snydeq writes: The transition from command line to line-of-command requires a new mind-set — and a thick skin, writes InfoWorld's Paul Heltzel in a tips-based article aimed at programmers interested in breaking into management. "Talented engineers may see managing a team as the next step to growing their careers. So if you're moving in this direction, what tools do you need to make the transition? We'll look at some possible approaches, common pitfalls — and offer solutions."
As someone who transitioned from Jockey to ShitMover I can assure you the move isn't worth the headaches. I used to work with a great bunch of like minded people who where interested in creation. Now i work with a bunch of egotistical idiots who just want to push stuff they know is garbage over the line just so they can get ticks against their name and get out before it blows up.
The stories about jobs and careers are getting so tiresome. I realize Dice bought Slashdot to datamine the comments (free focus group!), but it seems like half the stories are a variation on the same these days.
The stories about jobs and careers are getting so tiresome. I realize Dice bought Slashdot to datamine the comments (free focus group!), but it seems like half the stories are a variation on the same these days.
It's the non-engineers.
They have this misconception that people used to dealing with the intricate semantics of programming languages are going to be unaware of the intricate semantics of English. Therefore, if they ask a question once, and do not get an answer they like, they will repeatedly ask the same question in different guises, hoping to obtain the answer they wanted to hear.
This really comes down to who is more patient than whom.
I usually attempt to buffer my answers in order to soften the blow, but you can ask the same question as many ways as you want, and the answer will likely not change, so long as it is fundamentally the same question. And I usually have the patience of Job. However, there was one incident where I was up against a deadline, and was being asked to "just cobble together something that works, and we'll (read: you'll) fix it (read: in a binary compatible way) later. Which was an impossibility (I was working on some very complex database code written in C++ which did subschema definitional enforcement on an upper level database schema, and the semantics had to be correct for the data stored in the binary backing store to be usable going forward, when we did the next update). The code had to be *right*, as opposed to *right now*, and the time difference was important.
We had a UI person who was in a management position, and they brought her over to argue their case that immediate was better than correct (correct would fit under the deadline, but only if everyone left me alone to finish the code). The UI person was constantly revising the UI in each release, and each release was practically a full rewrite. And she did not understand why I could not write my code the same way she wrote hers. Finally having had enough, I explained "It's OK if your code is crap; you are going to rewrite it in the next release anyway. My code has to work now, and it has to continue to work going forward, and therefore it needs to be correct. I understand that you are feeling the approaching deadline. So am I. However, while your code can be crap, mine can't be because I have to maintain it going forward. Now if you will get the hell out of my office, I will be able to finish the code by the deadline."
Needless to say, there were some ruffled feathers. The director of engineering sided with me. I completed the (correct, rather than expedient) code by the deadline, and the product didn't turn into unmaintainable crap vis-a-vis the update process going forward.
What's the moral to this story?
Well, with specific regard to DICE:
(1) Repeatedly asking the same question in different ways is not going to get them a different answer, if the first answer was correct. Any other answer than that answer would be incorrect, for the question asked.
With specific regard to the current topic:
(2) Engineers who actually reliably, repeatedly, and consistently deliver what they are asked to deliver, within the timeframe that was agreed upon, can, and often do, wield more authority than the managers nominally set above them in the food chain, so it's not like going into management is going to give you any more real authority than you already have by way of your relationship with the team, and their trust of your judgement.
A management path can be a good idea if:
(A) You want more perks (stock options, etc.), although in a good company, if you are a great engineer, you will get those anyway
(B) You are tired of doing engineering for a living (which probably means you didn't qualify as "great engineer" under option 'A' anyway)
(C) You feel you would be more useful and/or happier in such a position (but if your happiness is based on power, don't expect it will necessarily follow)
(D) You
I find this notion interesting.
I am a manager. I have hired people over 50. On my team right now I have 3 people within 3 years of full retirement. One of whom I hired within the last year. I also have two that are within spitting range of 50, one of who I hired less than 6 months ago.
When I'm bringing someone on board in the 40+ category with 20+ years of professional experience, I have drastically different expectations than what I'm looking for in a 24 year old kid who's on his first salary gig out of college.
I'm looking for someone who understands corporate structures, workflow analysis, generalization. I'm looking for someone who says, "When you boil this down, it's an asset management system, and I've worked with half a dozen different vendors and 4 different home grown systems that do the same thing". I want someone who can sit down with users, look at what their doing and not just imagine up a new piece of software, but understand the business process to the point where they can make truly business impacting recommendations with a realistic grasp of what it would take to accomplish. I want someone who will pull the young bucks aside and explain to them the merits of simplicity and maintainability, someone who can do code reviews without being a pretentious dick, someone who can help guide that next generation of developers into the future engineers and architects I need.
People over 50 absolutely have a place in the development arena. But if you're 50 years old and still expect to have the same responsibilities as a 24 year old kid, you will be sorely disappointed.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs