Tag Info

Hot answers tagged

567

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


401

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


371

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


216

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.


182

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


182

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


170

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


169

First, put your ego aside. Start by assuming that he's not wrong, and that you are the one that is wrong, for two reasons: All other things being equal, he's right and you're not, simply from experience It's how you show respect So ask him to teach you why his way is better, with the honest expectation that you are wanting to learn something, because ...


125

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


125

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


124

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


124

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


118

Disclaimer: I live in Central Eastern Europe, make your own decision on whether I count as Eastern or Western :-) As such, I worked on projects outsourced to our country from Western Europe, and I experienced doubts from the more Western coworkers and management concerning our abilities, similar to what Indians must experience in such situations. OTOH I ...


107

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


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


96

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


91

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


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


87

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


83

Hmm Interesting views. I'd just like to throw in mine. I live in India (I'm Indian) and I've been programming since I was 11/12. All I have so far is an high school education and interestingly I've done two things so far, I taught at an Indian Computer Institute and right now I develop freelance (and got myself a project with a VERY high profile client) ...


80

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


77

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


76

Suppose you think your boss is wrong. You have three options do what he says and end up frustrated thinking that you do something stupid - not very good long term tell him he's an idiot - he'll either ignore it or you get communication problems - gets you nothing or hurts you. tell him that you have specific concerns about the ideas he proposes and explain ...


75

It's an awful idea. It may be quicker in the short term, but it encourages badly documented hard-to-understand code as only the coder who wrote it is responsible for maintaining it. When someone leaves the company or goes on holiday the whole plan becomes mucked up. It also makes it very hard to allocate workloads; what happens when two urgent bugs come up ...


74

Being an Indian, I can speak about India. The issue is about the culture here, the mindset of the people. Since childhood, we are trained to follow the process, trade the safe path, get into high paying professions like engineering, medicine, business administration, etc. Innovation, exploration, entreprenuership is still not so common here. Most people ...


74

It sounds like you are placing too much effort on having well rounded individuals and not enough effort on having a well rounded team. There is nothing wrong with being good at something--in fact, that is probably why he was hired! You should be thankful to have someone who is good at programming to begin with. You stated: ... it goes against my ...


72

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


69

Have you spoken to your development colleagues about this? How do you know they lack education? That's quite a sweeping statement and you'll probably find you're wrong. I don't think it'd go down too well if a new grad started meddling with processes without understanding why they're like that in the first place. Managers love processes and love tracking ...


67

A rather unorthodox approach would be just use Dropbox. Have the authors save the files in the dropbox directory and you get versioning and backup for free. Plus there is basically no learning curve for the authors. For git, sounds like in the end you gonna end up providing the authors with the correct branch versions anyway, so just put the git repo in the ...


67

So my code is late too. No, it is not your code, it is the code of you and the senior. You are working as a team, you have a shared responsibility, and when you two miss a deadline, it is the fault of both of you. So make sure the one who makes the deadlines notices that. If that person sees that as a problem, too, he will surely talk to both of you ...



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