4 ms·

I'd pursue project management. Good Project Managers, Business Analysts, or Development Managers are much rarer than good Developers IME, and overall much more

by ssmoot 13y ago

I'd pursue project management. Good Project Managers, Business Analysts, or Development Managers are much rarer than good Developers IME, and overall much more important IMO. I'm a Developer. My wife is an Senior Operations Manager (head of the Business Analysts as well as some other roles). If I had to pick between having me on a team, or her, I'd pick her in a heartbeat. And there's not developer I know or have worked with that would make me rethink that choice. Because she can make a lot of "OK" individuals and build a "Great", effective team. IME you can easily have a number of "Great" individuals and end up with a "Failing" team without the management piece. Also, this is maybe just me, but it really gets under my skin when I hear "great managers are there to run interference and give developers the room to do great things". That's absolutely false. I've been a Manager. I've tried to do that. It only ends up in failure. You do that and all you'll get are half baked projects that blow the budget nine times out of ten. Great Managers delegate. They don't try to code. They get metrics. On everything. Just like the unquestioned advice about getting metrics for every aspect of your application, it's even more important to have metrics for your development. How long does it take to add a Form to the application? Is the Database involved in this Change Request? What does the Deployment Procedure look like? These things are in fact quantifiable, estimatable and predictable given experience and data if you know how to break them up. Give people room to spike something, but when it isn't working out use the data to see that and kill it so you don't end up in a swamp. Don't try to be a Developer and a Manager at the same time. Until you've done every bit of your job you could possibly do in Management you don't get to go on recess playing Developer. My wife's RFPs deliver within 93% of the hours estimate. It takes money to get there, but you put the effort in ahead of time, while it's just paper, when Change Requests are cheap. You try to avoid iteration of code during development because it's 10X the price at that point. You're able to plan budgets, quarters, quantify contributions, get people compensated fairly, make sure no one is ever working nights or weekends. The worst slogs/most expensive projects I've ever worked on have had the least planning and most iteration during development. The best projects, where you felt you actually accomplished something every day, where you could see the light at the end of the tunnel because the whole thing was estimated and so far you're able to fairly accurately predict the accuracy of the estimates, have been far and away the most successful both in cost and client satisfaction. That's my experience anyways. All that just to say: If you're interested in the Software Development field and want the best chance at having an impact, changing people's lives for the better: Be a great Manager. And that's not necessarily the one the "cool" developers think you should be.

cwe 13y ago
I'm pretty similar to the poster, and after majoring in poly sic, spending a few years in sales, have moved in project management with a side of product management. Trying to move more in product, which can sometimes get more technical, or more creative/design depending on the company/product. Great advice.
notphilip 13y ago
I will soon be working as a PM at one of the big tech companies as my first job. I've gotten the gist of these lessons from a software engineering class, HN articles, and from my internship (at the same company), but I'm still not very confident about becoming a great PM. Can you recommend any books or resources that covers more of this kind of stuff?
- codegeek 13y ago
  If you mean PM as in Project Manager/Management, then please read this one for sure [0] [0] http://en.wikipedia.org/wiki/The_Mythical_Man-Month http://en.wikipedia.org/wiki/The_Mythical_Man-Month
  - mtrimpe 13y ago
    And Peopleware is also a must read of course.
- grumps 13y ago
  Personal thoughts - suggest you look into organizational skills. Learn to take great notes, and have a tenacious follow up and follow through.
  - ssmoot 13y ago
    Right on the money. When your boss asks a question: Be able to answer it. If you can't, figure out how to answer it. Figure out what you need to track to be able to answer it in the future without being asked. This is where Agility comes in. Not in throwing out Planning. But in being able to respond to Bad Planning by incrementally improving your process and understanding until you've got Good Planning. You're not going to walk in the door on day one and toss out a plan that lines up actual to estimated hours at 93%. But with that tenacious follow up and follow through you can get there. And it's not just for the boss. It's awesome as a Developer to know that I'm 50% done. That the requirements have been met for the 50% I've delivered so far and I won't be constantly going back and reworking code because someone didn't put in any effort ahead of time to think this damn thing through. Rework is the death of budgets, team happiness, and will bring about the zombie apocalypse. Also, meetings are an important, efficient way to dig through tough problems or keep stakeholders up to date and involved. If you feel like your meeting are wasting time, then maybe you're just not managing your meetings well enough. Or maybe it's because it's not all about you. Maybe it's a little bit about Bob the Developer transitioning off another project that just wrapped up and onto this one, or Trisha the Account Executive who has her weekly status update with the client tomorrow. Or discussing the great success or disappointing failure of spiking this new library. I think of Development Team meetings like Pool Maintenance. Sure it'd be nice not to pay the Pool Guy to come out and check the water. If you could only pay him for "real work" that'd be great. But that's not reality. And if you're not daily spending 15 to 30 minutes testing the water with a: "What did you plan to do yesterday? What did you actually end up doing? What do you plan to do today?" then you're likely blowing a lot more than the 15-30 minutes * N Developers with people floundering, getting tunnel vision, people who need a helping hand, maybe just need a break, making sure Bob is aware of the utility classes Tammy just developed so he doesn't go off duplicating effort, etc. It's about fostering communication. It doesn't happen by accident. If you find it's happening and effective without the meeting then by all means re-evaluate. But don't do that before you actually have the data to prove that. Because the risk is much greater than the cost. And managing risk is what it's all about. You do that right, and your odds of success go up ten fold. That doesn't mean don't try anything new either. It means weigh your options. Timebox. Reinvest in your product and your team, but don't get so distracted you forget why you're here.

by ssmoot 13y ago

cwe 13y ago

I'm pretty similar to the poster, and after majoring in poly sic, spending a few years in sales, have moved in project management with a side of product management. Trying to move more in product, which can sometimes get more technical, or more creative/design depending on the company/product. Great advice.

notphilip 13y ago

I will soon be working as a PM at one of the big tech companies as my first job. I've gotten the gist of these lessons from a software engineering class, HN articles, and from my internship (at the same company), but I'm still not very confident about becoming a great PM. Can you recommend any books or resources that covers more of this kind of stuff?

codegeek 13y ago
If you mean PM as in Project Manager/Management, then please read this one for sure [0] [0] http://en.wikipedia.org/wiki/The_Mythical_Man-Month http://en.wikipedia.org/wiki/The_Mythical_Man-Month
- mtrimpe 13y ago
  And Peopleware is also a must read of course.
grumps 13y ago
Personal thoughts - suggest you look into organizational skills. Learn to take great notes, and have a tenacious follow up and follow through.
- ssmoot 13y ago
  Right on the money. When your boss asks a question: Be able to answer it. If you can't, figure out how to answer it. Figure out what you need to track to be able to answer it in the future without being asked. This is where Agility comes in. Not in throwing out Planning. But in being able to respond to Bad Planning by incrementally improving your process and understanding until you've got Good Planning. You're not going to walk in the door on day one and toss out a plan that lines up actual to estimated hours at 93%. But with that tenacious follow up and follow through you can get there. And it's not just for the boss. It's awesome as a Developer to know that I'm 50% done. That the requirements have been met for the 50% I've delivered so far and I won't be constantly going back and reworking code because someone didn't put in any effort ahead of time to think this damn thing through. Rework is the death of budgets, team happiness, and will bring about the zombie apocalypse. Also, meetings are an important, efficient way to dig through tough problems or keep stakeholders up to date and involved. If you feel like your meeting are wasting time, then maybe you're just not managing your meetings well enough. Or maybe it's because it's not all about you. Maybe it's a little bit about Bob the Developer transitioning off another project that just wrapped up and onto this one, or Trisha the Account Executive who has her weekly status update with the client tomorrow. Or discussing the great success or disappointing failure of spiking this new library. I think of Development Team meetings like Pool Maintenance. Sure it'd be nice not to pay the Pool Guy to come out and check the water. If you could only pay him for "real work" that'd be great. But that's not reality. And if you're not daily spending 15 to 30 minutes testing the water with a: "What did you plan to do yesterday? What did you actually end up doing? What do you plan to do today?" then you're likely blowing a lot more than the 15-30 minutes * N Developers with people floundering, getting tunnel vision, people who need a helping hand, maybe just need a break, making sure Bob is aware of the utility classes Tammy just developed so he doesn't go off duplicating effort, etc. It's about fostering communication. It doesn't happen by accident. If you find it's happening and effective without the meeting then by all means re-evaluate. But don't do that before you actually have the data to prove that. Because the risk is much greater than the cost. And managing risk is what it's all about. You do that right, and your odds of success go up ten fold. That doesn't mean don't try anything new either. It means weigh your options. Timebox. Reinvest in your product and your team, but don't get so distracted you forget why you're here.