Tag Info

Hot answers tagged

69

I think most developers find themselves in this position at some point, and I hope that every developer who's felt victimized realizes how frustrating it will be when he or she becomes the senior and feels compelled to clean up code written by juniors. For me, avoiding conflict in this situation comes down to two things: Courtesy. Talking to someone about ...


69

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


67

He's probably right. If the codebase is so monstrous, so gigantically complicated, so difficult to understand... what makes you think you can write something that does the same thing correctly? Generally a big refactoring is the best place to start - start ripping bits out and combining them into reusable chunks; tidy up the code so its easier to view; ...


48

Well, recursion is actually pretty simple to grasp for kids. Don't try it with mathematics or whatever the other people here are suggesting. They are too young to understand it. It's too abstract and boring for them. Instead: Show them a picture of a painter who is painting a picture of painter who is painting a picture ... Something like this: There are ...


41

The preference you observe looks like a natural consequence of recommendation clearly stated in GNU Coding Standards. It suggests to report bugs by email, as you can see in below quote (I marked bold the part that directly addresses your observations): 4.7.2 --help The standard --help option should output brief documentation for how to invoke the ...


35

The Real Edge (tm) that mailing lists have is with less busy projects. In order for a web based forum to be successful, it needs a core of people constantly present who can respond to questions, provide suggestions, and moderate it. But if a board only has a couple posts a week or month, many people interested in the topic (be it an open source project, a ...


33

In addition to the "because they are used to it" arguments, email has a few other huge advantages: You already have an email address, no need to sign up for yet another messageboard account for every project. With a messageboard, you have to actively visit the page and refresh it to see new messages. On the other hand, most people have their email client ...


32

This may not directly answer your question, but it might lead you in an interesting direction. I think what you need to do is more related to selling them on the idea than explaining it to them. Sales is all about understanding what the customer's problem is and then showing them how your product (or development method, whatever) will benefit them. Each ...


29

Do nothing. Contacting someone purely to tell them they screwed up but we fixed it, is unprofessional and no matter how hard you try is unlikely to ever be received positively. Talking in depth enough for a conversation to be remotely useful about code to non employees is bad regardless of potential NDA issues.


28

How to Win Friends and Influence People has plenty of good ideas though some of these may seem obvious: Fundamental Techniques in Handling People Don't criticize, condemn, or complain. Give honest and sincere appreciation. Arouse in the other person an eager want. Six Ways to Make People Like You Become genuinely interested ...


25

IMHO Integrating in a new environment is great, it is one of the most fun things you can do :) What I do : listen a lot try to remember names from the beginning take notes, so you don't need to ask a question twice. (Especially , servers, password little trivia the team takes for granted) don't try to change their world, in the beginning you have to learn ...


24

Your questions has the answer in it. Adding man-power to a project that is running late, only makes it worse because the communication overhead increases in a non-linear way. It's already been studied. Read "The Mythical Man-Month".


23

Talk to them about it. Go into the conversation with the attitude of "They're not doing this to annoy me or because they have some form of obsessive-compulsive disorder; they're trying to make my code better." Because you could be wrong. That could be a subtle bug fix and you just didn't spot it. Or, it could be that there's a coding standard you don't ...


23

First question is : why does he do that? Is it because he likes to compare different answers and pick the best one? Is it because he likes to see who can do it the quickest? That's rather important to tackle the behaviour. I understood from the "racing" part it's the latter. Then a simple calculation can show him why this is not exactly the way to go. Say ...


23

With Git, in particular, there is a simple historic reason: Git was started by Linux hackers for Linux hackers, and it uses the same development model and tools as Linux itself does. Linux, however, is older than the WWW, so, when Linux was started there simply were no web-based issue trackers, because there was no web! As a consequence, the Linux community ...


23

If you haven't already done so, define the minimum system requirements of your website, e.g. supported browsers¹, minimum display size, required cookie permissions, etc. If the user did not satisfy the minimum system requirements, it's not your fault that it didn't work for him. Investigate the issue, prove that the minimum system requirements were not ...


22

read Jeff's blog post. it's a great start. Another great way to learn better communication (and as a side benefit, learn your programming better), teach someone how to program. Blog regularly. Participate in *.stackexchange sites Go to developer meetups (as a bonus, you can network as well) Write a paper, present said paper at conference. Read other blogs ...


22

Propose your changes. Be clear on the business case for each: Why will your proposed change help the system as a whole? If it doesn't, expect push back. Why spend money fixing something that ain't broke? Reasons such as making the system more extensible and separations of concern may be valid (depending on who you're talking to), but 99% of the time, just ...


21

It shouldn't be an email. It should go into your tracking system: The case entry is the fault report. Initially assigned to you and with the first response to note that it isn't a consequence of X because you've checked (with any additional information to support this conclusion). Its then assigned to you colleague with a note that you suspect it might be ...


18

They tend to be used for emphasis: No, that's *my* monkey. or No, that's _my_ monkey. Asterisks can also be used to denote an action the person is supposedly doing at the time of the comment: No, that's my monkey. *snatches monkey* Or a description to apply to the comment *firmly* No, that's my monkey. In the examples you give though think of them as ...


18

E-mail is not an instant-response medium. You are expecting your colleagues to reply within 5 minutes? You are being unreasonable, they may also be doing focused work where they do not want to be interrupted. Some people at my company make a point of only checking their e-mail twice a day: in the morning and after lunch. They do this for precisely that ...


17

You might try reordering it so that you tell them what you want at the beginning of the e-mail. I noticed a problem with System A that I would like you to look at. I have already looked at X and determined that is not the cause. It might be caused by Y, which is why I need your assistance. This issue is keeping So & So from doing their ...


17

Ideally, you'd answer her by agreeing that the change was simple and easy, you'd do it, she'd be happy and everyone would move on. I'm guessing because she's recording it as a bug, rather than asking for the change, other side-effects occur. Maybe the quality of your code or your work is being measured by the number of bugs you create. If that's the case, ...


16

I got a couple of projects at github ( http://github.com/jgauffin) which have received some users. What I do is: Examples Developers are lazy. If they can't figure out how to use your code they'll just continue to search after another library. Clear and concise examples are important Documentation When they have started to use your library they'll need ...


16

What is it about the process that makes you want to take responsibility for "your code" ? Do you have the sole responsibility to keep certain features working? Did the lead say "Michael, I want you to take responsibility for ..." ? Or is your responsibility implicit, in that the lead and the rest of the team look to you every time certain features are ...


15

I'm not so married to how my code looks for it to bother me. :) I try to learn from the changes. Did my coworker adjust variable names? Write a more efficient loop? Make the code more readable? If I can't see how the changes improved what was already there, I usually ask the coworker who made the changes what the motivation behind them was. It's possible ...


15

Bring them hard facts! For example there are performance benchmarks for ORM and JS frameworks. On top of it all framework and ORM have good selling arguments at their homepage. After reading your comment I believe in your case the problem is not the right technology It’s the people who refuse to learn new technology.


15

A tried to organize the suggestions into two parts with three points each: the first point targets people without technical background, the second one: every person, and the last one, the people with more IT knowledge. Content First and most important, the content of your website should reflect the fact that your software product is updated frequently. ...


15

I see a few options: Approach the coder with your concerns. It must be done as constructive criticism with specific points. Before taking bigger steps it's appropriate to raise concerns directly and in private to give the person the opportunity to change. Gather information and statistics and bring it to management. Management might not appear to care, ...


15

Thank them for bringing it up to your attention. Reply back with the defect number from the bug tracker. Yes, that means you need to enter the bug yourself. Verify that you have all the details you need to recreate the bug. Bonus points if you can give them an estimate of its priority and when you might be able to fix it. It's also fair to explain your ...



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