Tag Info

Hot answers tagged

115

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


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

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


73

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


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


64

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


61

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


55

One of the developers I regularly collaborate with is colorblind. The issue isn't just that he can't tell colors apart, but also that he doesn't tend to think much about color. He, and other colorblind people, learn to make it a nonissue to the point where color, even that they can tell apart, becomes a bad tool for distinguishing things. We were talking a ...


54

This seems to be a pretty common prevailing attitude among some developers. Everyone seems to feel that a code review is some challenge to their work, and that makes no sense to me. A code review is a quality assurance mechanism that has the added bonus of education to go along with it. We implement code reviews extensively where I work, and I've fostered ...


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


51

The primary purpose of a code review is to find defects or potential problems. The required participants in the review should be the people who are best suited to identify these problems, regardless of their title or seniority. As an example, if an application is being developed in Python and the junior engineer has more experience with the Python language ...


49

To start with, this comment: ... having a branch implies an extra complexity and thus extra work ... is wholly false. I often hear it from people who aren't accustomed to branching, but it's still wrong. If you have many developers accumulating changes locally, their local changes constitute a de-facto branch of the main repository. When they finally ...


49

There are two main factors in my experience: Deadlines Most companies are so date driven that QA, tech debt, and actual design are cut just so the project manager doesn't look bad or to hit some absurd over-promised client deadline. In this environment where even functional quality is cut, then a long-term investment like documentation has little chance. ...


46

The best team leaders I've seen have all been dynamite programmers. But they've all had several other qualities, which are harder to define: wisdom, good judgment, good people skills (friendly and pleasant but not a pushover), dedication, commitment, and — most important of all — knowing how to give credit to others. Such people are natural leaders. The ...


45

He is 100% right that you must provide enough information to make the bug reproducible - otherwise there is no chance to find out if any fix he provides will really work. But - he is IMHO 100% wrong that this must be in form of a unit test. If you can describe a test scenario in a way so he can reproduce the failure (at least with a high probability in a ...


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

Please take a day to install version control and teach everybody on the project to use it. It's not that hard. Personally I've not used Git, but I have set up and used other version control systems and they are not that hard to get working. Make sure you choose one that integrates with your development environment. This will make using it virtually seamless. ...


42

My question is: am I too harsh on this matter? You can lead a horse to water, but you can't make him drink. It's hard to say whether you're "too harsh," but it may be unrealistic to expect your teammates to adopt all the infrastructure that you're hoping for. And truly, if the team is working well together, using a wiki to communicate between three ...


40

Say "I'm a bit busy right now, you can ask on stackoverflow.com if you're really stuck." Eventually he will hopefully get the clue. Also, next time he comes to your desk say "Hmm I don't know, let's Google that and see..." or "Let's check the API docs." The combination of these two has worked for me with co-op students in the past - ...


40

Comment Well Should you lower the skill of your code? Not necessarily, but you should definitely raise the skill of your comments. Be sure to include good comments in your code, especially around the sections you think might be more complicated. Don't use so many comments that the code becomes hard to follow, but be sure to make the purpose of each section ...


39

Some problems are naturally recursive. Coming up with an iterative solution in these cases can actually be more clunky and complex than recursive ones. A good example is any algorithm which needs to traverse a hierarchical tree structure, which is a not-uncommon task in programming. TL;DR version: No.


39

Mentor them. I've come across this same situation when consulting and having been put on teams with less than optimal team members (nobody needs a consultant if everything is going great :-/). My manager one time became so frustrated with the other developers, he resorted to getting frustrated and just telling them all the time how they were doing things ...


38

You need to get the situation formalised as it shouldn't really have got to this point. However, these things happen so you need to explain to your boss that you created these scripts for personal use, but they've "escaped" into wider circulation. Admit (if necessary) that you were at fault for not bringing this to his attention sooner. At the very least ...


38

Change takes time. Udi Dahan has an excellent article that touches on what you are asking, and I think he does a better job with the answer than I would. Be enthusiastic, not bitter. Be prepared to carefully, cheerfully explain your position far more often than you'd like. Count your wins, and be prepared for others resisting your ideas. Always keep in ...


37

Ask. That is, ask the folks you work with. Do your best to stick to the established style of the existing code. Ask especially if there's a document list of coding standards, and follow it. If there isn't one, write up a first draft based on what you observe in the code and then ask the other team members to critique it. You'll do the company (and new ...


34

Like so many of these questions, I think the answer is: It Depends There is reason to believe that taking the position that every programmer should know every line of code is misguided. If we assume for a moment that someone with a deep understanding of a piece of code will make changes 5 times faster than someone who doesn't know it at all (not a giant ...



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