Hot answers tagged

244

When to ask for help, and when NOT to ask for help.


212

It appears that these variable names are based on the abbreviations you'd expect to find in a physics textbook working various optics problems. This is one of the situations where short variable names are often preferable to longer variable names. If you have physicists (or people that are accustomed to working the equations out by hand) that are ...


197

"We will come back to this and fix it later. We just need it working now!"


184

How to read other people's code.


162

When used at the start of a block, as first checks made, they act like preconditions, so it's good. When used in the middle of the block, with some code around, they act like hidden traps, so it's bad.


152

Familiarity with version control systems. It doesn't have to be every one, but the basic concepts that can be applied to all of them should be known.


132

When I see a line like if (!lateForMeeting()), I read that as "If not late for meeting", which is quite straight-forward to understand, as opposed to if (lateForMeeting() == false) which I'd read as "If the fact that I'm late for meeting is false". They're identical in meaning, but the former is closer to how the equivalent English sentence would be ...


120

No, this is not bad practice. Relying on short-circuiting of conditionals is a widely accepted, useful technique--as long as you are using a language that guarantees this behavior (which includes the vast majority of modern languages). Your code example is quite clear and, indeed, that is often the best way to write it. Alternatives (such as nested if ...


116

You really can't make blanket statements about appropriate way to use all GC implementations. They vary wildly. So I'll speak to the .NET one which you originally referred to. You must know the behaviour of the GC pretty intimately to do this with any logic or reason. The only advice on collection I can give is: Never do it. If you truly know the ...


105

The deadline is soooooo far away, I have more than enough time to do it, so why not spend a little time surfing the web?


104

Maybe it's too subtle, but I think of it as "knowing which problem to solve." A lot of programmers (and normal people) waste tremendous effort solving things that simply aren't very important; or they create a solution, with a great deal of extra work, that isn't quite what is needed.


103

"This is just throw-away proof-of-concept code. Once they like it, I'll really make it good."


95

How to relax. It's the secret to productivity. Eventually, willpower and caffeine are not enough. This constant contraction we do is very damaging. This is a big deal.


92

Writing == false and == true is redundant. It can be taken to arbitrary extremes, too. If you start writing if (condition == false) { ... } Then why not if ((condition == false) == true) { ... } Or why not if ((someExp == anotherExp) == true) { ... } The moral of this story is that if condition is a boolean expression, then you don't need to add == ...


89

The Discipline of Finishing. Like many software engineers, I have a tendency to accumulate projects until I am contributing so little to each one that none of them makes meaningful progress. Couple that with a classic ENTP personality type, and you get a busy, interested and ultimately unproductive programmer. Over the years, I have learned and practiced ...


87

IPV4 only networking code. The time hasn't come for most people yet, but the idea of IPV4 only networking will become obsolete.


83

Basic data type & algorithm theory. Things like Big O notation, arrays, queues, etc.


80

Variables with short lifetimes should be named shortly. As an example, you don't write for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { .... Instead, you use for(int i .... In general rule of thumb it could be said that the shorter the variable scope the shorter the name should be. Loop counters are often only single letters, say i, j and k....


76

There is no true evil in programming. <rant> The reason so many people think that there are evil things is that it is pounded into their heads when they first take their programming classes. "Don't use goto! Always normalize your databases! Never, ever use multiple inheritance!" These are hammered in because these "evil" practices are so easily ...


76

Many localization issues fit this pattern: a generation ago, programmers assumed all characters can be represented with an 8 bit data type a generation ago, programmers assumed every kind of text should be read left-to-right, top-down a generation ago, programmers assumed the field separator in a CSV file is always the comma character , (No, it really isn'...


74

Refactoring part of the code a few day before the release. Internet: The biggest distraction of all. New technology: Can't keep my hands off new technology. Optimize: Optimize, Optimize. .. and more Optimize Perfection: Never been satisfied with the code. TODO: Lack of time todos that never will be done. Time estimation: Many PMs doesn't take this as "...


74

All programming language are concrete implementation of some of the abstract ideas in computing. As you learn a language, you start appreciating the abstract ideas better. This usually makes it easy for you to also appreciate the concrete implementation of those ideas in other languages. This makes it easy to grasp and learn newer languages. The better grasp ...


74

An objective response: While my initial response to this question was based on my empirical experience as a soon-to-graduate CS student and my projected opinion of the type of people I wanted to work with in the CS field. There is actually an objective (with respect to the subjective opinions of the ACM SIGCSE and IEEE computing societies) answer. Every 10 ...


67

Premature generalization is my big bugaboo; instead of solving the problem at hand first and waiting until there's an actual need to solve for the general case, I always go after the general case up front and wind up writing a ton of code that's more complex than it needs to be. Update: See "Sin #1 - Premature Generalization" for an in depth descripztion....


67

Make sure that you're not overreacting. You are fresh, probably haven't worked a lot of (any?) other places, and so aren't prepared for the world of "real life code." Real life code is a horrible thing. It's like your nice school code and your obsessively tweaked personal project code had sex in the basement of a nuclear reactor and the baby grew up in a ...


65

My apologies to anyone who doesn't care for lengthy answers, but I do think it's pretty important to qualify your candidates before you hire them. Anyone who's conducted a significant amount of interviews in this industry knows that most candidates won't last through the first 15-30 minutes of an interview, so most of this list won't be necessary. Just ...



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