Tag Info

Hot answers tagged

523

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


388

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


184

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.


178

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


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


164

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


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


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


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


118

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


118

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


102

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


100

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


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

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


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

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


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


75

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


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

Wait: Chris is the team lead. Chris wants them to do OOP. They don't. Right? IMO there's a management problem to address in the first place. Your target should be Chris, not the other programmers. Tell him that those programmers aren't going to train themselves just by being made fun of. And then you could propose that you teach them. This could bring you ...


68

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


65

Don't take pride in how well you code. Take pride in how well you learn. Then learning that your code needs improvement provides you with an opportunity to demonstrate how good you are at learning, instead of coming across as criticism of how bad a programmer you are. Read http://www.perlmonks.org/?node_id=270083 if you have no idea what I'm talking ...


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


63

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


58

Management won't change anything if they don't feel any pain. If you allow management to be hands off (by fixing things and being successful) then you will be expected to continue fixing things and being successful. After all -- from management's view -- things are fine. Stuff is getting done. You may feel stressed, but that's not what's important. ...


58

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


58

Some people like it your way and other people don't. Either way someone is going to be annoyed. It is just your turn this time. Suck it up and get on with the job.



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