Hot answers tagged

413

Comments alone don't make for better code, and just pushing for "more comments" is likely to give you little more than /* increment i by 1 */ style comments. So ask yourself why you want those comments. "It's best practice" does not count as an argument unless you understand why. Now, the most striking reason for using comments is so that the code is ...


289

Communicate your concerns in the most concise and non-confrontational way possible up the management ladder. Summarize the risks, but do not impose your conclusion on them. Management must always have the choice of what to do, but it is your job to assess and communicate the situation. Use email, so as to leave a paper trail when things go south. Having ...


111

I have met lots of devs who had trouble in writing self-documenting code or helpful comments. These kinds of people often lack enough self-discipline or experience to do it right. What never works is, "telling them to add more comments". This will increase neither their self-discipline or experience. IMHO the only thing that might work is to make frequent ...


95

Keep a paper trail (e.g. diary, saved emails, etc). Only include facts and objective observations. Leave all conclusions up to whomever (if anyone) reads what you've written. As a developer, if you're not viewed as an obstacle to the project you're likely to come out fine from the finger-pointing that will no doubt happen. Your manager may not be so ...


89

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." ...


79

I'm going to recommend you take a little time to read 2 books. Death March is the canonical book that describes a pathological project management style that is widespread in software development. Due to schedule compression, feature bloat, or mismanagement, many projects end up in a bad state; it helps to understand that you are not alone and your project ...


78

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 ...


66

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 ...


54

Everyone altering the application should be doing it in source control, and you should have an automated process for deploying a specific version from source control to your test server. It may require some persuasion to get your non-technical people to use source control, but their really is no alternative to keeping a non-toy system running reliably. If ...


53

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 ...


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

3 simple and cynical strategies to maintain career/sanity. See a train wreck in the making - get off the train: Failing projects are terrible for morale and unless you have ninja upward management skills will have some negative impact on your career. Jump now if you can see any soft landing. If that doesn't work keep your head down: People are going to ...


46

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 ...


45

The greater the risks, the more you need "air cover". This is what a manager is really supposed to provide. While the team does the work, the manager is supposed to ensure that there is nothing that will keep the team from achieving team goals. Whether it's tweaking the schedule, running interference between the team and the sales staff, or simply making ...


45

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. ...


38

There are only two good reasons to report something like this to management: is if you believe that the coder who did this was malicious and attempting to sneak something through, or if you believe that the coder who did this is incompetent, which can be just as harmful as a malicious coder. From the way you describe him, it sounds like you believe he's ...


37

In my 20 years of experience, it is better to have code ownership rotate responsibilities amongst designers or at least have a pair of owners. Single feature ownership has the following issues, several of which you mentioned: it tends to pigeon hole designers and limit their growth opportunities it puts all the eggs in one basket so if someone is hit by a ...


34

This is the whole point of code review. Mistake is written. Mistake is found and corrected in code review. Do you want to tattle on your senior team member? This team member according to you has never made a similar mistake before. Unless the code was intentionally written that way (and you can prove it) this is a really dumb idea to go to management ...


33

What impact will this soon-to-be failed project have on your career at the firm, and beyond? In my experience, merely being associated with successful projects is not an indicator of your own personal excellence. The qualities that you exhibit in the face of adversity and sometimes what looks to be certain failure, often gets noticed by the higher-ups, more ...


32

There are two things I think you should consider 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 you ...


30

Don't rotate. I don't think anyone gains anything from the position being rotated (apart from the ones that don't deserve to be the lead might get more money than they are currently receiving). Having a brilliant lead developer who can do the following, does wonders for the development process:. Knows how to delegate. Is in control. Is an experienced ...


30

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

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 ...


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, ...


26

I'm surprised no one has mentioned code reviews yet. Do code reviews! When he has a check in of bad quality don't just say "add comments". Constantly ask questions and get him to tell you what his code does and why. Take notes. Then, at the end of the code review give him a copy of the notes and tell him to make your questions fairly obvious. Either by more ...



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