672

Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that). Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, .... ...a root cause for a defect is not always ...


462

This sounds absolutely nutty. It is expending a great deal of effort for very questionable benefit, and the practice seems based on some faulty premises: That QA won't work hard unless they know they are being tested every day (which cannot be good for morale) That there are not enough unintentionally introduced bugs in the software for QA to find That QA's ...


427

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


321

In your code, you have made multiple changes: destructuring assignment to access fields in the pages is a good change. extracting the parseFoo() functions etc. is a possibly good change. introducing a functor is … very confusing. One of the most confusing parts here is how you are mixing functional and imperative programming. With your functor you aren't ...


270

Another probable result for such a policy is that people won't report bug if they think they may be the "person to blame", so it will actually reduce the number of bug reported by the team.


225

If you are in doubt, it probably is too clever! The second example introduces accidental complexity with expressions like foo ? parseFoo(foo) : x => x, and overall the code is more complex which means it is harder to follow. The purported benefit, that you can test the chunks individually, could be achieved in a simpler way by just breaking into ...


209

Well, based on what I've learned: It's not a school nor job interview; The testers are not children; It's not a game; It wastes company's money. The QA are not there only to find bugs but also to worry about how intuitive the system is, what is the learning curve for the user, usability, and accessibility in general. For example: "Is the system ugly?", "Is ...


190

My response would be to say "I'm a little busy right now, can you email me and I'll deal with it later". Chances are some of his questions are legitimate, by forcing him to email you it doesn't interrupt your flow and he is unlikely to bother detailing the problem in an email if its trivial. You then also have a record to show to management if his questions ...


175

The truth is that probably in 2 years when you will see your current code you will agree that it was a mess. Learning programming is a never ending process and there will always be someone who is better at it than you. So if person who said that your code is a mess is not just mean and it is not another case of "I would do it better" disease common among ...


164

It sounds to me like you are putting the cart before the horse. What is the major problem your team is facing and which technologies would help fix it? For example, if there are lots of bugs, particularly regression-type bugs, then unit testing may be a starting point. If your team is lacking time, perhaps a framework may help (medium to long term). If ...


161

In such cases, it is best to use the type system of your language to help you with proper initialization. How can we prevent a FooManager from being used without being initialized? By preventing a FooManager from being created without the necessary information to properly initialize it. In particular, all initialization is the responsibility of the ...


140

The main argument I would use against it is to ask what problem he's trying to solve. There are almost certainly better ways of solving the same problem. For one thing, is there really only ever one person to blame? If there is, you're doing something else wrong. A good process takes a piece of work through an analyst, a programmer, a reviewer and a tester ...


135

Ok, here goes my take on this big and complicated topic. Pros for keeping your coding style: Things like x = x || 10 are idiomatic in JavaScript development and offer a form of consistency between your code and the code of external resources you use. Higher level of code is often more expressive, you know what you get and it's easier to read across ...


128

I'm going to throw in a slightly controversial view: You say that you are working as many hours as you can stay awake. So maybe he's not being particularly unfair to say "you're making me look bad and I'm actually working as many hours as I'm willing to." Maybe he's been there and done that and maybe he burned out. I promise you that you will if you keep ...


126

You're in a bad situation, I wouldn't want to be in your shoes. It's unlikely that you could to sort it out without getting into conflict with your colleague. This is what I would do: Don't become his partner in crime. Refuse to lie about the status of your project or his project. Implement (in your spare time if necessary) bug reporting to your ...


114

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


112

I fail to see how they currently add value and is scheduling meetings, booking offsites and other administration works enough for their role? Don't underestimate the amount of interaction your manager does with other departments. They handle budgets, training plans, HR paperwork. They protect the developers from getting sucked into meetings with other ...


105

Ask for stubs. Or write them yourself. Either way, you and your coworkers need to agree on the interfaces and how they're intended to be used. That agreement needs to be relatively solidified so you can develop against stubs -- not to mention, so you can create your own mocks for your unit testing...


104

Everybody Loves a Good Code Bash / WTF Session I am now worried that they will find bugs and blame me for the problems. Of course they will find bugs. You said it yourself: it's buggy (you already found bugs) and complex (it's very likely to have more). And yes they'll blame you for it. Because it's a large codebase and they will, over time, get ...


102

when I first introduced them to branching and merging -- they looked like I was offending them This is probably because branching and merging are advanced concepts, and infinitely less useful than to simply keep track of the changes. So why not explain just "commit" (save) and "update"? Two really simple concepts. I'm sure you can explain it in less than ...


99

Bad idea. From the tester's point of view: "So they will test hard, because they know there are bugs present and not finding them might be considered as their incompetence." Basically the devs are booby-trapping the code. Few people like doing work which is ultimately pointless (because the bugs are known in advance) but which still affect how they are ...


92

It's not a training issue, it's a human factors issue. They do not want to, and are creating road blocks. Deal with the broken group dynamics, what is the root cause of their objection - usually fear, is it just fear of change, or is it more sinister. No professional developer today, or for the last 20 years, has resisted source control. Once, about 30 or ...


89

There's a famous military saying, attributed to Helmut von Moltke: "No battle plan survives contact with the enemy". In the same vein, I do not think it's possible to make a spec that will not have to be changed - not unless you can predict the future and read minds of the stakeholders (even then they may not have yet made their minds, even if they claim ...


89

Once we were halfway the project, the PM stated we had to use third party message queue capabilities instead of threads and had to implement load balancing This isn't an appropriate thing for a PM to "state" unilaterally. Two reasons: Design decisions should be made by a technical resource and only in response to NFRs. So politely ask your PM if there is a ...


87

It depends to some extent on how your team usually works, but I would say that was fine. Keeping the build working saves everyone else time. It's polite for the the second programmer to drop the first an email to explain what he has done, just in case a specific version of the library is needed or there is some other complication. It's also a slightly ...


85

You and most of the answerers approach this as a communication issue between two colleagues, but I don't really think it is. What you describe sounds more like a horribly broken code review process than anything else. First, you mention that your colleague is second in command and it's expected that he'll review your code. That's just wrong. By definition, ...


84

If you think the code should be fixed before merging, make comments. Preferably with "why" so the dev can learn. Keep in mind code is read far more often than written. So things which seem "minor" can actually be really important (variable names for example). However, if you find yourself making comments which seem tedious, perhaps consider: Should your ...


83

The easiest way is to ask from a point of not understanding and ask their opinion. It's no good to say "your code sucks", it's quite another to say "erm, I saw this and I really can't understand what it's doing, or why it's doing it. What do you think?" or similar - you could say what your concern is and ask them to explain it to you, or ask them just if you ...


81

Most people generally agree that a Software Architect should mostly be involved in high level design, setting standards, choosing tools or frameworks, evaluating products, implementing prototypes and Proof Of Concepts, and training and mentoring developers The reality however is that the title often can be a political appointment to a developer, a special ...


81

Should junior programmers be involved as code reviewers in the projects of senior programmers? Yes they should. It is a good learning experience to read other peoples' code. (And that applies both for good code and bad. Though one would hope that a senior developer's code wouldn't be bad ...) Obviously, it is unwise to only have juniors doing the code ...


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