Tag Info

Hot answers tagged

88

The leader of this project will be the person who steps up and takes charge at the beginning. This applies to most things in life - not just software development. When everybody else is running around like chickens with no heads, the person who thinks things through, steps forward and says, "This is what we're going to do and this how we're going to do it." ...


76

Things that seem to work well for me: Give meaningful work and encourage ownership - even when a problem arises, don't solve it, talk through it and give the person insights so they can solve it themselves. edit - addition - this was also meant to include - stay the heck out of details. Assume your people know enough to do the assignment without ...


64

I'm surprised that everybody thinks this is such a good thing. The authors of Peopleware (which, IMO, is still one of the precious few software project management books actually worth reading) strongly disagree. Almost the entire Part IV of the book is dedicated to this very issue. The software team is an incredibly important functional unit. Teams need to ...


52

It sounds like what you're doing is basically equivalent to a code review except that rather than providing feedback to the developer, you're making all the changes that you would suggest in a code review. You'd almost certainly be better off doing an actual code review where you (or someone else) provides feedback to the original developer about code ...


52

You can quit. Not the most constructive thing to do, but sometimes it's the only option. If you do, don't sit around and moan about how you had to give it up, take that energy and put it straight into something else - 'move on' in other words. You can fork it. There's no reason why you have to work with anyone. Fork, improve the code and let the others ...


46

Ask the dumb questions, and keep asking them. Nobody expects a new hire to know what is going on. If anything, they will respect you for it - they certainly won't mind it; most programmers love being able to show off to a newb. What everyone hates is someone that just goes blank and sits there. However, do not ask the same question twice. Keep a log book, ...


44

You've more or less already answered the question: He's on probation He's not productive enough So, he needs to be made clearly aware that: He needs to be more productive or he won't survive his probation. He is liable to be more productive with a proper IDE than with a good text editor. A good IDE is not about giving up control over the code you write ...


39

I believe that Team Ownership is much more beneficial in the long term. You just need to look at the following 2 scenarios to understand why concentrating knowledge in minimum numbers of people is less than ideal: Team member meets unfortunate accident Team member meets better employment opportunity Naturally, the person/people who write particular ...


39

Alright, so someone's enthusiastically writing great code that needs to be done, just not in order. With all due emphasis: LET THEM It's causing some complications in your scrum sprints. Does it really matter in the grand scheme of things? If he's accomplishing what he's supposed to, then let him go on and build great things for you. I know several ...


38

You've made it a little unclear exactly what your role is here. The answer depends on how you fit in. If you're leading the project and control the git repository Take back control. If this guy is making commits you don't like without consulting you, remove his direct commit access. He can fork the project and make pull requests to merge his commits. ...


35

I like working in a team. It's nice to be able to split up some tasks, bounce ideas off of each other, etc. I find that the code and the project generally benefits from that sort of collaboration. But, if the team isn't cohesive, then I'd rather work by myself to get the job done. As for the ideal team size, I think it depends on the size of the project, ...


29

If I could choose I would have 6-7 seniors on a team ( assuming the project needs that many ). The only time I can see this being a problem is if the seniors are only senior in self perception and not work ethic. There is nothing better than working with a group of people who appreciate that every piece of software development is important - the ...


29

Libraries. Frameworks. Version control. If you've got reusable code, the very last thing you want is for different team members to copy the source code into their project. If they do that, chances are that they'll change a bit here and tweak a bit there, and soon you've got dozens of functions or methods that all have the same name but which each work a ...


27

In my experience, the most productive rockstar programmers in an organisation are almost always people who are truly passionate about what they do. So the trick is to find people for whom the "work itself is the reward", not some "external" stimulus such as better pay. As for how pay rises should be done - I'm not sure. I've always essentially just been a ...


26

I have had a team of 10 people for two years without a conflict(touch wood) I could be lucky or may be doing something right. The best way to handle conflict is never to let one exist for a longer time. There are several core values that you can preach. Team Spirit Fairness in everything (compensation/rewards) Being appreciative Give recognition, ...


25

IMHO Integrating in a new environment is great, it is one of the most fun things you can do :) What I do : listen a lot try to remember names from the beginning take notes, so you don't need to ask a question twice. (Especially , servers, password little trivia the team takes for granted) don't try to change their world, in the beginning you have to learn ...


25

We've been using Mercurial for about a year. While the headache you mention exists, by far, the biggest challenge to full adoption for us was getting into the DVCS mindset of local repositories (= commit often.) The old mindset of "Commit once you have polished code" can be hard to let go. You said: In the DVCS model, each developer checks in their ...


25

Jarrod Nettles' answer pretty much summarises a lot what I was going to suggest, so I'll throw in some of what worked in my recent experiences in a similar situation. I would suggest finding some way to talk with them vocally, rather than by email. If you're not in the same area, get them all on Skype. If you're in the area, meet them at a coffee shop or ...


24

Your questions has the answer in it. Adding man-power to a project that is running late, only makes it worse because the communication overhead increases in a non-linear way. It's already been studied. Read "The Mythical Man-Month".


23

At some point you have to be in charge. Code is done a certain way or it is done over. If he can't at least correct his mistakes, he has to be let go. I'm trying not to overly simplify this. There is a difference between an inexperienced coder who makes mistakes but is willing to learn and someone who thinks they are always right and does not recognize ...


23

Please forgive my bluntness, but your post reads like a rant. You say it's the other guy who wants mindless changes, but then you contradict yourself when talking about this new shiny Java program of yours. Take a break; it's not a one-way street, please try to find compromises (if you want to continue working on the project - forking is the easiest ...


22

To force people to stay out of "the zone" (also known as "flow") is codswallop. When in the zone, is when a proprammer (or surgeon, or car mechanic) is at their most productive - time passes in the blink of an eye, brilliant solutions appear, complex code with numerous pieces that interact can be created - and it all just flows out automatically. If not in ...


22

Software development isn't a manufacturing type process where people are essentially interchangeable resources. It’s a creative process that works within the collaborate environment of a professional team that takes into account individual abilities and skills. It’s not making widgets, packing boxes or flipping burgers. In fact, these kinds of throwing more ...


22

Let me play the devil's avocate here. Maybe all of your team, with the exception of that programmer, are the ones who are inferior, and he really is a brilliant programmer. Imagine if, say, Linus Torvalds (let's pick a poster boy for accomplished programmer) for some reason fell into a situation where he is working in a team of moron programmers whose ...


22

There are two things I think you should consider here here: Don't hinder someone's creative flow. If a dev wants to do out-of-hours work, then let them. Don't create work for others. If a dev wants to do out-of-hours work, it sure as hell better not be creating more work for others. Point 2 is likely what the other developers are worried about. Like ...


21

Comments don't clutter the code. And when they do, well, every half decent IDE can hide / fold comments. Ideally the story should be told by your code, your requirements document, your commit history and your unit tests, and not by comments. However excessive commenting can only hurt when comments are concentrated on the how and not the why, however that's ...


20

Ultimately, the team owns the code. But for all of the reasons you mentioned, we have designated individual authors for specific portions of the code. Each author has primary responsibility for their portion of the code, and secondary responsibility for the code base as a whole. If a problem with a part of the code base surfaces, I try to go back to the ...



Only top voted, non community-wiki answers of a minimum length are eligible