Tag Info

Hot answers tagged

389

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


266

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


101

I have met lots of devs who had trouble of writing self-documenting code or helpful comments. Those kind of people most often just lack enough self-discipline or experience to do it right. What never works is just "telling them to add more comments" - this will increase neither their self-discipline, nor their experience. IMHO, the only thing that does ...


89

I'm afraid that I'm going to have to disagree with many of the answers to this question, as none of them have mentioned the difference between intrinsic and extrinsic motivation. From the Wikipedia page: Intrinsic motivation refers to motivation that is driven by an interest or enjoyment in the task itself, and exists within the individual rather than ...


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


86

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


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


72

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


65

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


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


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


46

Ask Them What we want is not necessarily what they want For example, I would want a high salary, considerable equity, flex time, and a cash completion bonus for hitting each milestone. I have no interest in Red Bull, pizza parties, or trinkets. ADDENDUM: most important: keep your promises


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


43

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


42

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


41

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


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


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


33

I don't need to be motivated to do my job. It is very possible to demotivate people though through poor management. What I do need is an expectation that is possible to meet. Deadlines that we are going to miss even before we start are demotivating, you know you'll get the blame (not the people who set the impossible deadline) when you don't meet them so ...


30

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


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

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


28

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


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


27

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



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