Tag Info

Hot answers tagged

43

Correlation doesn't imply causation. Developers copy/paste code they don't understand because they're bad developers. The availability of such code doesn't turn good developers bad. If there were no open source projects, there would still be forum posts with code snippets or programming books with examples. So we're back to my first paragraph: bad ...


37

Professionals in every profession have a way of thinking that differs from the others. After all, 'tis natural - you went to school and studied exactly for that reason; so you could develop that way of thinking. So yes, to that first questions. What one should never do, however, is think he is better than others in any way. And that is something IT people ...


36

Compared to languages like Perl, Python has a limited number of control constructs: only if and no unless, only for that iterates over sequences and no foreach or C-style for, only while that checks a condition every loop and no do-while, only if-elif and no switch, there's only one comment construct, the #, and for every line you can tell if it is ...


35

First, I'll note that although I only mention "C" here, the same really applies about equally to C++ as well. The comment mentioning Godel was partly (but only partly) on point. When you get down to it, undefined behavior in the C standards is largely just pointing out the boundary between what the standard attempts to define, and what it doesn't. ...


34

Interesting question. We produce a product - code - but we're not like typical unionized laborers. We're also not professionals like doctors and lawyers and accountants. (Can you imagine some hospital administrator demanding that a surgeon work overtime on Saturday - with no extra pay - to push a few more patients through?) Really, we're highly skilled ...


33

Unions are useful when one person can pretty much do the same job as anybody else with little or no training. By allowing employees to negotiate as a whole, you don't run the risk of employers simply finding the person who'll work the cheapest and driving wages down. (At least, that's the theory.) For professional fields, when employees require particular ...


30

Yes, programming languages heavily influence the way we think about programming - everyone who has learned a new programming language that uses a different paradigm than the previous one can testify to this. The more languages you know, the broader your horizon, and that's always a good thing - you want to be able to look at problems from many different ...


28

There are two distinct IT disciplines: Computer Science - is the discipline study of computers and computation using the scientific method. Software Engineering - is the discipline of designing and implementing software following proper engineering principles. The two overlap somewhat, but the distinction is really about desired outcomes of science ...


24

I try to think far ahead too, but usually not in code. I brainstorm and take notes, hopefully organizing things well enough so that I can refer back to them. I lean more towards "you ain't gonna need it" with respect to code, but "now is better than never" with design. When starting off building a new system it is tempting to want to build everything now, ...


23

Here's a motto for you: Anything worth doing is worth doing badly. You speak of painting beautiful paintings and coding beautiful programs. I suspect you also want to write good novels and compose good songs. You don't get to do those things, by and large, without working for a long time first and making bad things. So, go out there and do cruddy work. ...


23

It's always difficult to judge an approach based on a screencast, since the problems picked for demos are typically so small that applying principles like SOLID quickly makes it look like the solution is completely overengineered. I'd say SOLID principles are almost always useful. Once you become proficient with them, using them doesn't seem like something ...


18

The two extremes are about equally bad: On one side the architecture astronauts/academics who can't even look at a class without defining two factories and a strategy pattern. On the other the self-aclaimed "duct tape programmers", often powered by at least some part ignorance, who subscribe to YAGNI ("You ain't gonna need it") to the extreme. Good ...


17

I think you've got a point there, but cp, rm, cd and a lot of others change state, so they aren't really functions. The UNIX philosophy is more about doing only one thing but doing it well; often doing it well means allowing functional usage, but not always.


16

Software Engineers do have a union... The "Communications and Computer Workers Industrial Union 560" is a department of the Industrial Workers of the World (IWW or "Wobblies") who work in the electronic communications industry. Their organization is open to workers engaged in computer operation, including programming and networking. See ...


14

The C rationale explains The terms unspecified behavior, undefined behavior, and implementation-defined behavior are used to categorize the result of writing programs whose properties the Standard does not, or cannot, completely describe. The goal of adopting this categorization is to allow a certain variety among implementations which permits quality of ...


13

Somewhat akin to the other answers, but the classic "professional" roles in society (doctor, lawyer, engineer, etc.) have not been unionized. The working class banded together into unions to oppose heavy-handed treatment by management and owners. By collectively demanding a change in their working conditions they were effective where a single person could ...


12

I've been using emacs for the last 10 years (from and to), and I can only say that you are absolutely right. Back in the days, I used gnus and the w3 browser, but clearly they are no longer up to it when compared to dedicated programs. But, obviously, you cannot run Chrome in text mode so this is where emacs wins. And even there, I'd rather use lynx/elinks ...


12

I don't know that any particular natural language lends itself to better programming (except maybe Latin?). I do know that knowing more than one language is pretty powerful. Dijkstra said in one of his last interviews (as reprinted in CACM Vol. 53 No. 8, p. 44): There is an enormous difference between one who is monolingual and someone who at least ...


12

Think about the problem at hand first and foremost. If you blindly apply the principles of YAGNI or SOLID, you can hurt yourself later on. Something that I hope we can all understand is that there is no "one" design approach that fits all problems. You can see evidence of that when a store sells a hat advertised as "one size fits all", but it doesn't fit ...


12

matz himself is a nice resource for understanding the principles behind Ruby. Ruby is the definition of beautiful code (pdf): "[Code] is meant [...] to be read and understood by human beings" "Beautiful code is really meant to help the programmer be happy and productive" "[Ruby] is an extremely conservative programming language [because it sticks to if, ...


11

The software industry lacks unions simply because neither the workers nor management see the need for collective representation. There are obvious reasons why management would rather not see software professionals collectively bargain on work issues such as compensation, working conditions, etc. But software professionals haven't felt enough discomfort in ...


11

Programmers rarely "do computer science". They mostly use results of "software engineering", which is an engineering discipline, obviously. Other than that, Computer Science is Applied Mathematics. If you compare CS with something indubitably belonging to applied maths, you'll notice a lot of resemblance. Computer scientists design and study ways of ...


11

It's been demonstrated that there are two kinds of thinking (logical and intuitive) and most people have a predisposition toward one or the other. I personally think that many programmers are balanced between the two (whole-brained is the term mentioned in the article), based on the fact that we understand things like elegance and "good-looking" code (as ...


10

Personally I always estimate for correct, I would rather delay then release rushed code. My standard backup for that claim is that I cannot assure for the overall quality or performance if we kludge it in and it will cost the PM more headaches in the long run. From a development perspective if you can't grab my code and immediately know what its doing ...


10

The speed thing is especially a problem when compared to C. If C++ did some things that might be sensible, like initializing large arrays of primitive types, it would lose a ton of benchmarks to C code. So C++ initializes its own data types, but leaves the C types the way they were. Other undefined behavior just reflects reality. One example is bit-shifting ...


10

Fail fast is a great design approach, and perhaps it can be counted as a pattern: http://en.wikipedia.org/wiki/Fail-fast I've also found a number of principles to be useful: Consider exceptions as part of the interface to each function / modules - i.e. document them and where appropriate / if your language supports it then use checked exceptions. Never ...


10

As a general rule, problems are worth fixing when the expected benefit exceeds the expected cost. Thread safety is no exception from this rule, it's just that the way of calculating the risk that determines the expected cost is particularly complex and ill-understood by many. To begin with, threading safety is not on many people's radar. They will simply ...


9

I think there are several reasons why we still aren't good at this. People for a long time though software was like houses, and were using processes and ideas from construction. "Software architect" was a title all programmers wanted. During the last ten years the software architect has almost died out. The idea of waterfall processes where you first have ...



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