Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming IT

On Managing Developers 146

Posted by Soulskill from the bribe-them-with-diet-coke dept.
An anonymous reader writes: A columnist at TechCrunch takes a crack at advice on how to manage developers. He has some decent starting points. For example, "Basically a manager's job is to make other people more productive. What's one really good way to do that? Do the work that is getting in their way. Which means: find out what kind of important work your developers dislike the most, and do it for them." Also: "[D]on't bull$%^& anyone, ever. ... Speak the truth as you see it. Speak it diplomatically, don't get me wrong; but be trustworthy. Only then will you be able to trust others." But some of his statements are open enough to be nearly devoid of meaning: "Any particular process artifact is probably irrelevant. The finest tech team I ever worked on began every day with a daily standup; so did one of the worst, most dysfunctional teams I ever encountered. ... [T]he systems and processes you choose for any given project should be fluid, and flexible, and depend in large part on the team and the context." If you are or have been a developer, what qualities have made your managers good or poor? If you've been in position to do the managing, does you experience jive with this guy's?
This discussion has been archived. No new comments can be posted.

On Managing Developers More

On Managing Developers

Comments Filter:

  • ... As in "I speak Jive" from the movie Airplane?

    Or maybe he means "jibe"?

  • If it were easy (Score:5, Insightful)

    by Crashmarik ( 635988 ) on Sunday June 07, 2015 @08:36AM (#49860851)

    Everyone would be great at it. Anyone that thinks you can find the secrets to being a good anything in a couple of paragraphs, just doesn't know very much about the topic.

    • Re:If it were easy (Score:5, Insightful)

      by Anonymous Coward on Sunday June 07, 2015 @08:49AM (#49860907)

      Pretty much this.

      I've been a first-line development manager for twenty years (one of the reasons I am still "first line," is because I have zero desire to lose my tech edge, which would be a requirement for moving up the food chain. I loves coding).

      In that time, I've learned a lot; much of it by screwing up.

      "Good judgment comes from experience. Experience comes from bad judgment."

      Honesty is a biggie. That's probably one thing that makes the difference. I'm dead solid honest with my team; including up front about how my first duty is to the corporation, but part of my duty to that corporation is to maintain a cohesive, productive team. That sometimes means that I'm honest to my supervisors when they make dumbass decisions or impose bad process.

      That also means courage, personal integrity and a good self-knowledge. Insecure managers are a blight.

      We need to manage ourselves first. An unpopular opinion that doesn't sell many books.

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      Do what your engineers hate is pretty much the one thing that I've found in my current job (where managers actually turn out to be good)...

      Managers here defend me from having to go to meetings by going to them for me, arguing for what I've chatted to them about, and giving me good reasoned explanations for the outcome. It lets me get on with my job, while I trust them to fight for a good solution.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Actually, I have to disagree with that position. My experience has been that being a good manager is much like being a good parent. The manager's role is to guide and mentor their reports, not coddle them and do their job for them. Treat the employees as adults and help them understand what their jobs are and how to do them effectively. That means a combination of facilitating them and educating them. Try to setup the employee for success, but ensure that they realize they have a responsibility to fulf

    • Re:If it were easy (Score:5, Informative)

      by Kjella ( 173770 ) on Sunday June 07, 2015 @12:07PM (#49861777) Homepage

      Everyone would be great at it. Anyone that thinks you can find the secrets to being a good anything in a couple of paragraphs, just doesn't know very much about the topic.

      I don't think you can learn the how in a few paragraphs, but sometimes you can learn about what developers expect from a manager. Let's face it, a lot of managers just ended up there by being put in charge and is learning by doing whatever they think a manager should be doing. And sometimes not even that because they're still techs at heart and want to dive into problems, not manage them. Others have just gone the management 101 school and don't have anything but generic theory.

      In particular, there's a massive difference between production work and creative work when it comes to estimates. If I need to get my car repaired or order catering, I expect a rather good time and cost estimate because it's standardized inputs and known quantities of work, at least for the most part. And you can fairly easily scale production with overtime, extra shifts, rush orders etc. to meet deadlines. And if a part is not in stock or you burn the cake there's a fairly standard and known fix.

      Most time I've wasted with management is discussing timelines or estimates that are as good as it gets and they're not going to get better by repeating the question. In the end you just fudge it up by a factor of x you hope is big enough and give them a number, because that's what they wanted. This is particularly true when there's bugs or problems that I really don't know where is, what the root cause is, how long it'll take to fix or even if I can fix it since it's in third party code/systems/tools.

      The best managers understand enough about computers to know this variation is natural and are pragmatic about working with it and working around issues when they arise. Those who come from a production industry seem to think you can beat a square peg into a round hole and act like I'm in the one being intentionally obtuse. "Can you do it man, yes or no?" which makes sense if you got a painter with three walls left to paint. It does fuck all when you got a developer who has no idea what to fix, but it's probably a one-liner when he finds it.

      Furthermore, those who don't understand that you want me out of that meeting and working on plan A - getting it done - while you work on a plan B, what to do if it doesn't get done on time or fixed in a reasonable time. I've had to sit through rescheduling sessions which were almost as pointless as the original scheduling sessions, the problem is that you don't have good data on how long it'll take. And rather than accept that you just double down on the developers and their poor estimating ability and demand that this time, you need correct estimates. In their eyes, we're the hopeless ones...

  • from a distance. Say "Make this do this" and stand back, let the kids do their magic (hell, being a manager doesn't require technical knowledge) and look forward to the result. Micromanaging is for kindergarten teachers. You have a team of devs because they know how to code and you probably don't, keep thy nose in thine own trough.

    • Re: (Score:3)

      by ranton ( 36917 )

      from a distance. Say "Make this do this" and stand back, let the kids do their magic (hell, being a manager doesn't require technical knowledge) and look forward to the result. Micromanaging is for kindergarten teachers. You have a team of devs because they know how to code and you probably don't, keep thy nose in thine own trough.

      While I like the overall message here of not micromanaging, I think an important distinction needs to be made between telling developers how to do their work and constantly validating that developers are doing their work. The latter is counterproductive but the former is absolutely necessary. Junior level employees often don't understand one of the major differences between managers and non-managers: in the eyes of executives your managers are ultimately responsible for the project's success or failure, reg

      • Re: (Score:2)

        by Bengie ( 1121981 )

        in the eyes of executives your managers are ultimately responsible for the project's success or failure, regardless of who actually messed up. So they absolutely cannot just sit back and wait for developers to be done with their work and hope for the best.

        Not always. Many of my projects are special requests by VPs and directors that are ASAP with no real deadline because it needs to be done yesterday or very important projects that need tight turn-arounds for nearly everything, like bug fixes and new features, live in prod.

        When the normal process can take hours, I can take minutes. It's a trade off. They know I am a single point of failure and there is good reason to have a formal process for most things, but some times customers have outrageous demands an

        • I have mod points, but there are times when what I want to say is more nuanced than a mod point can convey.

          That in this case being, thank you for sharing your experience. Primarily because I appreciate it when someone who "just loves to code" speaks up and shows how truly valuable he or she is.

    • Micromanaging is for kindergarten teachers. You have a team of devs because they know how to code and you probably don't, keep thy nose in thine own trough.

      As a manager I hate to micromanage and I've discovered that there are two types of developers: Those that can self-manage and those
      that can't. Being a small shop we are unable to efficiently micromanage the later type of employees and eventually have to let them go.
      I've stayed in contact with a few of these later type that get into a highly structured and micromanaged business and they do just fine
      even though they were incapable of completing even simple projects if left on their own.

      • Amen to that. I once had someone removed from a project I worked on, because even after a week of explaining WHAT I wanted, it wasn't getting anywhere. I later worked on another project where they brought in a new programmer - lo and behold, the person I managed to get fired walked in. As it turned out, when given explicit instructions and a template, we got passable code. It just took a bit of time to set things up at first.

        Personally, I'd not have hired that person in the first place, but when you lead a

      • I guess I'm going to be that person that raises a hand and says this isn't a binary condition.

        I'm smart and highly motivated. I'm a pretty good self-starter in an environment where things are well-structured. But I'm also a trifle scatter-brained and lose focus without decent structure in my environment (where everyone is expected to be a self-starter...yes, there are environments where this happens).

        Maybe we'll be in disagreement and you'd think that the second is simply a case in poor management. Well,

    • Re: (Score:2)

      by dbIII ( 701233 )

      hell, being a manager doesn't require technical knowledge

      Actually it does or a massive fuckup due to a newbie mistake lies in your future when you mess up a "but everyone knows that" situation that nobody thought to advise you about. Some understanding of the field saves you from that much even if you don't know the tricky stuff.
      A classic example I saw was an Non Destructive Testing manager who spectacularly fucked up a major quote and resulted in the shut down of that part of a company because his newbie

      • Re: (Score:2)

        by Ihlosi ( 895663 )
        Maybe that works with someone willing to take advice, but flying blind is a different story.

        Usually, industrial radiography equipment is fairly unforgiving to people who aren't willing to learn. Maybe leaving said manager alone with the equipment, just for a few minutes, would have resolved the issue.

  • "But some of his statements are open enough to be nearly devoid of meaning: "Any particular process artifact is probably irrelevant. The finest tech team I ever worked on began every day with a daily standup; so did one of the worst, most dysfunctional teams I ever encountered. ... [T]he systems and processes you choose for any given project should be fluid, and flexible, and depend in large part on the team and the context."

    Uh, what? Devoid of meaning? Maybe you should learn to read at a Junior High school level. What that sentence would tell you, could you read English, is that the religion of a specific process and procedure is not sufficient to guarantee success. A process which works correctly in one environment will result in doom in another. Nobody should have to spell this out for you; in the quote above, the text which precedes the ellipsis is sufficient to deliver this information. If you can't read and comprehend the above, perhaps you are not cut out to be an Editor (or story submitter?)

    • I agree completely! The advice about not treating any artifact or process as a holy cow I found much more meaningful than the "advice" that a manager should do what the developers hate for them. Sounds like a way to waste your time doing busy work instead of managine. Developers hate commenting their code. So should the manager spend all their time doing that??? Yeah, I'm sure that would help productivity.

    • Yes, that was a painfully dumb remark in the summary.

  • My approach (Score:5, Insightful)

    by CaptainJeff ( 731782 ) on Sunday June 07, 2015 @08:55AM (#49860931)
    Here is my approach to managing engineers.

    1. Get the right people.
    2. Get the right work.
    3. Get obstacles out of the people's way.
    4. Get myself our of the people's way.

    • ...and SHOW GRATITUDE! (Score:2, Insightful)

      by Anonymous Coward

      Can't stress this enough. Few developers respond well when they're treated like machines, even if they get external rewards like bonuses. Showing how valuable a part of the team they are makes a big difference in developers' morale in my experience.

      • Re:...and SHOW GRATITUDE! (Score:5, Funny)

        by jblues ( 1703158 ) on Sunday June 07, 2015 @10:37AM (#49861371)
        Reminds me of the time years ago, I wound up in a bank. We got this company-wide email from someone in senior management, I don't remember who. Maybe the CEO or CTO. I read something like: "We've had a management consultancy in this week, and and their advice was that productivity could improve if staff were recognized and shown gratitude for their contributions. So thankyou!". . . . And that was the end of that.

    • Here is my approach to managing engineers. 1. Get the right people. 2. Get the right work. 3. Get obstacles out of the people's way. 4. Get myself our of the people's way.

      I think you forgot the "0. Get a watch and a gun." item of your zero-based numbering list - love them or hate them, NaZi managers know how to manage (watch a sort online management video tutorial called Arbeit Macht Frei [youtube.com]).

    • So basically no different than managing any group of people?

    • Re: (Score:1)

      by Anonymous Coward

      5. Regularly evaluate the work being produced. Not everyone lives up to expectations, does a good job, or fits into a team; add/remove people based on results.

    • The problem with your method is you have to know, find and get the right people. What is right and what isn't? Just this simple thing is not that simple for any manager to tackle with. The right people mixed with some other right people may lead to a wrong as well. Then, the same reasoning apply to your point number 2. This is always easy to come with such a list: Do the right thing, that's it! You see, mine is even better than yours, but it is totally helpless and pointless.

  • Fast, cheap, flexible - choose one (Score:2, Interesting)

    by Anonymous Coward

    This reminds me of the "Fast, cheap, flexible - choose one"-idiom.

    You can be a great developer, a shitty manager and a good spouse.
    You can be a good developer, good manager and a shitty spouse.
    Or you can be a shitty developer, great manager and a good spouse.
    (Forget about being a great spouse if your mission in life is to please a company!)

    One of the best managers I've had have been technical, and got the boring parts done.
    One of the best managers I''ve had have not been technical at all, but championed our

    • Often, new hyped-up processes and tools become yet another excuse for people to NOT work together!

      Mythical Man Month had this one covered decades ago......it says when you have a small team of competent programmers, any development methodology can work. Remember that next time someone tells you, "you're doing Agile wrong!" because it's BS.

      • Mythical Man Month had this one covered decades ago......it says when you have a small team of competent programmers, any development methodology can work.

        Not sure if it actually says that, but there's a huge difference between "can" and "will".

        • Re: (Score:2)

          by Ihlosi ( 895663 )
          Not sure if it actually says that, but there's a huge difference between "can" and "will".

          Any development methodology that's guaranteed to work should be viewed with a healthy dose of suspicion.

        • Not sure if it actually says that, but there's a huge difference between "can" and "will".

          It really does say that, but your statement seems to be saying, "I don't want that to be true, but I can't see how it's wrong...."

          Maybe you are a true-believer in Agile? Maybe it bothers you that something called 'waterfall' could actually work? Agile works when it teaches programmers the necessary competencies......things like taking responsibility for their work, how to adhere to a schedule, how to accurately estimate their tasks, how to handle it when things take longer than expected.

          Competent develo

    • This reminds me of the "Fast, cheap, flexible - choose one"-idiom.

      Normally you would be expected to achieve two. Your product must be snake oil!

  • BS from managers (Score:2, Informative)

    by Anonymous Coward

    Well, if I'm left alone (no bullshit), it doesn't bother me to work extra time to get something done well. As soon as I have to deal with bullshit from a manager, I move into my 8 hour mode. That means I come in and do 8 hours a day as per my contract and don't give a shit.

    • If you're only getting paid 8 hours per day, you shouldn't do more than 8 hours per day.

      Unless you work for a non-profit or something and you want to give them your time.

  • ...He has some decent starting points. For example, Basically a manager's job is to make other people more productive...

    Well, if the summary starts off on such a wrong assumption, it can only get worse from there.

    .
    A manager's job is not to make anyone do anything, whether it is being more productive or coming to work earlier. Indeed, TFA says just the opposite, i.e., "Just Because You’re In Charge Doesn’t Mean You’re In Control".

    imo, one of a software development manager's jobs is to create an environment that allows the software developers to do their jobs. If the manager has to "make" them do thei

    • Re: (Score:2)

      by tomhath ( 637240 )

      A manager's job is not to make anyone do anything

      That's true, but it's also not what he said. The work "make" goes with "productive", not "people".

      His point is that the manager's job is to improve the productivity of the team. That's also a true statement, albeit pretty obvious.

    • Re: (Score:3)

      by ranton ( 36917 )

      ...He has some decent starting points. For example, Basically a manager's job is to make other people more productive...

      Well, if the summary starts off on such a wrong assumption, it can only get worse from there.

      imo, one of a software development manager's jobs is to create an environment that allows the software developers to do their jobs. If the manager has to "make" them do their jobs or be more productive, then the wrong people are in the software developer jobs.

      I agree the article starts off with a very poor assertion about the most important role of a manager, but I don't necessarily agree with your either. I like your change to what the article says, but I still don't think it is the most important part of a manager's job.

      IMHO, a manager's job is to ensure their projects are a success. Regardless of which developer or business analysts messes up, the ultimate responsibility always lies on the manager. Many employees don't realize this because they never witness

  • I'd make at least one change (Score:5, Interesting)

    by Registered Coward v2 ( 447531 ) on Sunday June 07, 2015 @09:03AM (#49860967)

    I would disagree with "Which means: find out what kind of important work your developers dislike the most, and do it for them." I would say:

    "Find out what non-essential stuff is interfering with real work and protect them from it."

    There often is work that is important that must be done but is not exactly fun, such as documenting code, helping tech writers prepare user manuals, listening to users and getting feedback on the UI, etc. Developers may dislike that work but they are the ones that need to be involved with it or do it. Sometimes it's the manager's job to point out stuff that needs to be done and find a way to get it done; even if it isn't what they want to do.

  • Mostly my list of desirable qualities is similar. I disagree about the "meaningless" part though. The one about "Any particular process artifact is probably irrelevant." is instantly clear to me. He's saying that it's the result of process that matters, not the specific bits that go into it, which is something more managers need to grasp. You need to use what works for the way your team works together, and you can't get so attached to one particular thing that you can't throw it out and replace it if it's n

  • My best manager (Score:5, Interesting)

    by Lorens ( 597774 ) on Sunday June 07, 2015 @09:15AM (#49861007) Journal

    told me that his job was only partially to tell me what to do (because I should know most of it) and mostly to shield me from the bureaucrap so that I could concentrate on doing it. I try to emulate that.

    Two other nuggets I aim for:

    - a good manager tells his people what *his* objectives are, and explains to them how that translates into the objectives he's giving them.

    - there are different kinds of management for different people, and a good manager must adapt. A newbie or an incompetent *needs* micromanaging (but beware of giving the impression of thinking either one is incompetent). As they get older/wiser/more experienced the manager can go more and more hands-off, until with a senior engineer/whatever the manager should be able to just discuss strategy and budget and priorities and such.

    • I agree. This is something good football coaches talk about. Denis Green put it succinctly and eloquently "I won't treat you all equally, but I will treat you fairly." People are not all motivated the same and are not all in the same circurmstances.

      > A newbie or an incompetent *needs* micromanaging
      I think you may want to say "mentoring" or "training" so they grow. Of course it also important to manage expectation so the individuals no what is expected and are not surprised there are consequence. Again ex

    • Re: (Score:2)

      by Gramie2 ( 411713 )

      I think it was someone at Google who described the two types of managers:

      • 1) Shit funnels take the shit that is coming down from above, and channel it onto their underlings
      • 2) Shit umbrellas protect those under them from the shit that is raining down from on high.

      Fortunately, my manager is a shit umbrella.

  • "What's ONE really good way to do that?" (Score:4, Insightful)

    by turkeydance ( 1266624 ) on Sunday June 07, 2015 @09:21AM (#49861031)
    superior compensation. period.

  • Peer reviews, client feedback, is there anything you need from us, done. As long as peers and clients are happy, the conversation takes under 30 minutes.

    Hell is a pretty cool place.

  • Judge employee performance only by meaningless metrics that can be looked up in Jira in 2 minutes, as opposed to actually looking at some the code their subordinate wrote.

    • Re: (Score:2)

      by Jeremi ( 14640 )

      All of the managers I've worked with never look at code at all. They judge performance based on whether the application works well for the customers, or not. It could be written entirely in brainf*ck for all they care, as long as it works well. (of course well-written code is more likely to work well than a badly-written mess, but that insight is left to the coders to realize, or not)

      • I assume the response is saying that looking at the code is not required to be a good manager.

        I agree that look at the code is not a key point of evaluation. I agree certainly agree with the parent post, that looking at a few metrics is not a good way to evaluate anyone or anything.

        Information I use to evaluate an employee.
        Do other employees praise or complain about them? The number one rule is making the team better.
        Do they do what is expected? Can I count on them to complete something when asked, to handl

  • Not specific to Software Devs... (Score:4, Insightful)

    by asylumx ( 881307 ) on Sunday June 07, 2015 @09:54AM (#49861201)
    Learning how to manage software developers is exactly the same as learning to be a good manager in general. I manage software developers. I'm not perfect, I wouldn't even rate myself very high, but many of my employees have told me fairly often they appreciate what I do for them. They things they seem to appreciate are: being as transparent as possible, being interested in their personal interests and development, going to bat for them when they need something (new PC, training, etc), giving them honest and quick feedback both good and bad, and not being willing to place blame but instead just looking for solutions. None of those behaviors are specific to managing software developers, but instead are some things good managers do in general.

    I was a software developer before this so while I'm not up to date on the tech they are currently using, I understand the types of struggles they face. That helps, although I'm fairly sure if I went tomorrow to manage a team of mechanical engineers that I could become effective fairly quickly in that role, too.

    Don't get me wrong, I'm don't think I'm a great manager, but I have had one or two great managers and I'm trying to borrow the things I thought they did well and my employees seem to respond to that.
  • "shit umbrella", protect the team from the crap that comes from higher management.

  • Advice (Score:5, Insightful)

    by Anonymous Coward on Sunday June 07, 2015 @10:24AM (#49861307)

    Two of the SDEs I manage told me in their last review I was the best boss they've ever had. Here is my advice:

    1) Do not judge anyone on anything except on whether they get their job done. If someone quickly does a good job, I don't give a shit whether they take the rest of the day off.
    2) Lead by example. Do the things you want your guys to do. That means the hard things.
    3) Imagine your team as a machine. You're the oil. Be where there is the most friction and smooth it out.
    4) Sacrifice yourself for your team. If you can't get a reward from the company for someone who deserves it, buy it yourself.
    5) Understand the perspective of your boss's boss, and explain it often to the team.
    6) Say you don't know when you don't know.
    7) Fight for raises and bonuses.
    8) Don't talk as a boss most of the time, but when you do, have a good reason to.

    These guys worked on the project that won us a nomination by a government agency for Small Business of the Year. The morale earned from being a good boss repays itself in improved productivity and reduced turnover. Plus you make friends for life. It pays to be a good boss.

    • Re: (Score:2)

      by talexb ( 223672 )

      Great advice! +1

      • I agree. Great advice. If the poster is following his own advice, it is no surprising the people on his team consider him one of the best managers he/she has ever had. The advice is very specific and practical and can be adopted by anyone.

  • Until last month, I managed the 12 devs I had hired (I have 30+ years of dev experience). On my way out the door, 3 of them gave me a 'best manager I've ever had'. No one gave me a thumbs down, at least to my knowledge. My 'secret'? Honesty, kindness, and this one very important thing: I never imposed a decision unless they couldn't come to one themselves, or were going off the rails. Despite my sizable ego, I've found 'letting go' of control, and focusing on guiding the team, rather than telling them what to do, produces one very happy, productive team. And they' introduced ideas and solutions that never would have crossed my mind!

    I left after a painful year of my naive boss and certain of his colleagues on the leadership team knocking us off course with their sophomoric meddling. Note to senior leaders: When you have a competent person running your dev team, let him/her do it. Just because you can spell Agile doesn't mean you know what it looks like.

  • Give them time, Give them resources and let them tell the marketing department how it's going to work.

    • ...and console them when their employer goes broke and they're back on the street, no more competent than before

      • in 90% of projects I've ever been on, that have released late, it's the marketing teams fault that the project released late and under developed, all because they didn't think to ask the developer first, how long they need to deliver the product.

  • If you're an MBA, remember that to everyone who works for you, that stands for "Moronic, Bullshitting Asshole".

    • If you're an MBA, remember that to everyone who works for you, that stands for "Moronic, Bullshitting Asshole".

      I've seen plenty of of managers without an MBA degree fit that description. Some self-taught, some who had finished college, and some who had gone to grad school. And frankly, your post is suggesting you may be heading in that direction. You are also tossing a bit of BS.

      I have to confess my opinions were once probably very similar to yours. And I had a couple of cherry picked examples in mind that matched my biased and uninformed opinion. Eventually I attended business school and one of the things I thor

  • I disagree with the post. Don't do everyone the developers don't like. It is not your job to write documentation. Get buy from the team to understand what they are doing. That being said, you do need to make sure that things don't fall through the gap.

    From my experience as a manage here are my top best practices:
    1) Get buy in
    a) Answer questions with, "what do you think we should do?" Then let them do it. If you supply an answer the employees will never believe they have control. You will not get buy in and

    • Re: (Score:2)

      by jrumney ( 197329 )
      I've seen all too often in my career introduction of good new processes fail because noone is there to champion them. As a manager of an established embedded development team that is still working "the old way", I accept that I'm going to have to 'do everything for the developers' until I get their buy in. The alternative of forcing new processes on developers before they've seen the value themselves just causes them to grudgingly follow the letter of the process with the intention of making it fail. If

      • Supporting the team like this is great. Be careful you don't burn out by taking too much on yourself. This a warning about mistakes I have seen from myself and others more than anything indicated in your post. It sounds like you have it pretty well under control, taking it one process at a time.

        Some thoughts on unit tests in case they are interesting/helpful for you or someone else.
        - Keep a bug count or similar metric posted to show process benefit
        - Make it easy to create tests, especial for the first time

  • Censoring your own profanity is one thing (albeit kind of silly in my opinion; why is implying it worse than actually spelling it out?) But when you're quoting somebody else -- and linking to their article -- you really ought to use their own words. If you're afraid that your readers are going to be offended by profanity, then you probably ought to not be linking to those articles.

  • If your developers are any good you basically don't need to do much. Give them a direction and the tech and they'll happily hack away. That's pretty much what my best manager tried to do. He made sure I had a good machine to develop on, would get them upgraded when they got old, and tried to prevent other divisions from using us as tech support. (Which can happen surprisingly easily since the devs tend to be some of the most tech savvy people around.) So he got that if I'm waiting 20 minutes every morning f

  • Managers need to know how to code (Score:4, Interesting)

    by Karmashock ( 2415832 ) on Sunday June 07, 2015 @12:29PM (#49861867)

    Or whatever your people are doing. You need to be able to understand what your people are doing so you can know if they're doing a good job or not.

    The whole TPS report thing from office space was a consequence of someone that doesn't know how to code or understand the product trying to keep tabs on people that were creating that product or service.

    So they create artificial benchmarks and paper work and then judge the employees by how well they comply with the paperwork.

    The problem is that the paperwork is not actually anything the customer cares about. It has nothing to do with the product or service. It is an arbitrary management mechanism. And it is FINE if the manager doesn't need it. If the manager can judge your work without it, than the paperwork might make his job easier.

    However, if he can't judge your work without that paperwork than he literally can't do his job at all. He can at best APPEAR to be able to do his job. And the only people that would make that mistake would other people that also don't know how any of this shit works.

    How is a non-doctor going to judge the quality of a doctors work? You can't.

    Same thing. Managers have to have experience in CS if we're talking about developers... ideally they should be programmers themselves.

    Again, if you don't have enough programmers with management experience, then it is easier to give programmers management training than it is to give managers programming training. So do that.

  • We have covered this topic time and time again and all we have are opinion, anecdotes, and people pedaling the 'Silver Bullet of the Month'. Is there any real data or comparison case studies we can draw on? I am coming up without finding anything I trust as Scientific. Are they any out there? Tech is so central to the global economy these days wonder why people are not intensively researching it.

  • > But some of his statements are open enough to be nearly devoid of meaning: "Any particular process artifact is probably irrelevant...."

    This is extremely meaningful and important if you have some experience, because a lot of managers (and devs!) seem to think that a process is a silver bullet. Things going wrong? Let's switch to another version of agile, that'll fix it!

    You need a process, but if you have all good developers it doesn't matter what process you're using (they'll come up with some loose for

  • No assholes (Score:3)

    by sehryan ( 412731 ) on Sunday June 07, 2015 @06:02PM (#49863323)

    Don't hire assholes.

    If you have them on your team, replace them as soon as you can with people who are not assholes. Take your time during the hiring process to ensure you are not hiring them. Doesn't matter how great the talent is, don't let it tempt you in to hiring an asshole. No matter what you think, you cannot manage an asshole to not be an asshole.

    I guarantee that if you look at all of the dysfunctional teams that have ever existed in software development, there was at least one asshole on that team. So if you want to be a better software development manager, get rid of the assholes.

  • I've managed a very successful team for many years, and the one thing I don't do is their work for them. They need to do their work, in their own ways, and do it well. If they do, they don't see much of me. I attend most of the meetings (though I do occasionally have to bring one or two along for specific stuff), I do all the HR stuff, I go to the boring planning sessions, and I find out how our work is being received and chart courses for sustaining and improving on that work as needed.

    I don't ask for stat

  • Managing all teams takes honesty, an ability to connect, balancing the needs of the organisation against the needs of the team and so on.

    However, there are some specific things that developers require or value highly that other groups don't:

    1) Objective decision-making.

    Developers respond and react far better to a manager who engages with a problem objectively, applies reasoned logic to it and then explains the reasoning for the decision. Other groups respond well to "lead by example", "lead by inspiration"

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close