Slashdot Mirror

Everyone who agrees with parent, please read this article NOW.

You don't learn C for the syntax, you learn it for the side effects.

http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html

Because it takes longer to optimize the application than it takes for technology to overtake you and erase any commercial benefit your optimizations might have.

Hear, hear!
Spolsky occasionally writes about this and I like what he has to say as well
FieldGuidetoDevelopers
BionicOffice

Hear, hear!
Spolsky occasionally writes about this and I like what he has to say as well
FieldGuidetoDevelopers
BionicOffice

There is a happy medium: http://www.joelonsoftware.com/items/2008/12/29.html Part office, but not all the way.

I'm with Joel Spolsky on this one. Private offices. If you can't swing that, *please* do not do the round table. Programmers need to concentrate! Some here here.

Joel (whom you link too) would rather start CS folk off at the bare metal. :3

This is why my view of teaching is that first year CS students need to start at the basics, using C and building their way up from the CPU. I am actually physically disgusted that so many computer science programs think that Java is a good introductory language, because it's "easy" and you don't get confused with all that boring string/malloc stuff but you can learn cool OOP stuff which will make your big programs ever so modular. This is a pedagogical disaster waiting to happen. Generations of graduates are descending on us and creating Shlemiel The Painter algorithms right and left and they don't even realize it, since they fundamentally have no idea that strings are, at a very deep level, difficult, even if you can't quite see that in your perl script. If you want to teach somebody something well, you have to start at the very lowest level. It's like Karate Kid. Wax On, Wax Off. Wax On, Wax Off. Do that for three weeks. Then Knocking The Other Kid's Head off is easy.

Wrong code is wrong.... *any* bad code is undesirable (for a litany of reasons).

True, but also unavoidable.

Let me put it this way: You will dereference a null pointer at some point. Now, would you rather get a nice stacktrace and an instant failure, or a random segfault, or worse, a security hole?

Similarly, it's very likely you'll have something like a buffer overrun -- and the steps to avoid this are ridiculous -- so would you rather do all that extra tedium, much of it absurdly inefficient, and then if you get it wrong, you've got a security hole? Or would you rather do none of the tedium, and if you somehow get it wrong, you've got a DoS (a crash) at worst?

They used to. Recently they changed their mind and quit doing this. Joel on Software has an interesting article on exactly this: http://www.joelonsoftware.com/articles/APIWar.html

I use KDE. 3.5.10 is still unbeatable when you want fast, clean and powerful. However, it's officially dead now, and the 4.x series sucks.

KDE4 is full of tiny little features that look like what you're used to, but do something completely different. Or they removed the most important button on the Konsole window, injected Amarok with featuritis, and k3b simply does not exist. (Wanna guess my three favorite applications?)

I'm starting to think Joel was right. The KDE project wasted two years trying to produce something "better" than what they already had. They failed miserably.

I guess its better than factory factory factories:

http://discuss.joelonsoftware.com/default.asp?joel.3.219431

Diminishing returns applies to programming too... big surprise...

But you don't know how much each bug will cost. What if that little UI glitch gives remote root?

BTW Joel Spolsky said the same in 2001. Big fucking news indeed.

"The very fact that Google invented MapReduce, and Microsoft didn't, says something about why Microsoft is still playing catch up trying to get basic search features to work, while Google has moved on to the next problem: building Skynet^H^H^H^H^H^H the world's largest massively parallel supercomputer. I don't think Microsoft completely understands just how far behind they are on that wave."

Perhaps Microsoft just cannot think like that? To be clear, Microsoft saying that maybe Google and Bing can perhaps exist side-by-side is a clear admission of defeat. Microsoft never says that, so you know the situation is bad. I just can't understand why they got a bee in their bonnet and wanted to chase Google in the way that they have. It was clearly a knee-jerk thing and they hadn't clearly thought about it. The only major difference they did was change the name from the stale MSN Search name to something they thought was cooler - Bing. Nothing else changed.

To not take into account that people search for many random and obscure things put together that won't have been recorded before (language is a very broad thing and what people search for is also time-based i.e. NOW), and not to have some sort of logic to aid with that, is utterly unforgiveable. What the hell are Microsoft Research doing?

Sure - new codebase, new bugs. A given. What isn't given is why the original developers thought this was a good idea? None of the answers to that question that I can think of are complimentary to what is now core infrastructure to the Internet. Was it not modularly written? Was it horribly insecure, and so badly so that it wasn't considered worth extending?

Bind is now in its tenth revision. You'd think by now that some sort of good, workable framework or design pattern would have evolved by now?

But clearly, it hasn't, and clearly, after several rewrites, it's *still* not considered worthy of being extended or refactored rather than rewritten. This bespeaks (to me) a well of WTFs, in light of the idea that you should basically never rewrite your software .

Nothing new. Just read this:

http://lxer.com/module/newswire/view/57261/

http://www.joelonsoftware.com/articles/fog0000000339.html

And spread the news to other newbies!

The reality is somewhere between the two.

You're right that specialization is fundamental and not needing to understand, say, CPU architecture is an improvement.

On the other hand, just because you don't need to understand how computers work anymore, doesn't mean it's a bad idea to do so.

I have been interviewing a lot of Java programmers lately. Many of them have a very weak understanding of how Java actually works. For a lot of projects, this doesn't matter. However it is very typical that, for instance, candidates underestimate the memory usage of their code by half because they don't know Java characters are 16 bit. Perhaps it's not surprising that Java programs have a reputation for being slow and bloated. And it goes without saying that for many real world programming problems, you are working within a memory and CPU budget, so not knowing the basic costs of the abstractions you work with is going to cause problems sooner or later.

Joel on Software has a good article on leaky abstractions. In my humble opinion, every working programmer should have read and pondered it.

This is one of many reasons why creative professionals prefer macs over PCs --- and I'm not saying this as platform evangelism -- for one, you'd be hard pressed to disagree that Mac OS X's font-rendering, kerning, and anti-aliasing abilities are far superior to those provided by Windows when presented with side-by-side examples.

Mac OS X's font rendering is different , but calling it "far superior" is simply platform evangelism.

OS X renders text so that the on-screen representation looks more like the printed representation, which is good for tasks like designing print advertisements (where you want to approximate the finished product as closely as possible). Windows takes liberties with the shape and spacing of on-screen text in order to line it up with the pixel grid, which is good for tasks like word processing and programming (where legibility on screen is more important). When you're used to Windows, Mac text looks blurry; when you're used to the Mac, I imagine Windows text looks thin and lanky.

See Joel on Software on this.

Joel is gay. Any real man can recode any piece of software if he is a real man. Otherwise Linux wouldn't exist. See: http://www.freesoftwaremagazine.com/articles/drivers_linux

These projects invariably have lots of tiny gotchas that you're going to steamroll in your effort to rewrite it. See Joel on Software on this.

That sounds almost exactly like what Joel Spolsky talked about ("Evidence Based Scheduling") in his article at http://www.joelonsoftware.com/items/2007/10/26.html

Joel Spolsky has written about making useful estimates at http://www.joelonsoftware.com/items/2007/10/26.html

The short version: for each developer, gather their estimated times and actual times for each of their projects.

If the ratio between the two is always 1, that person is the perfect estimator. If it's systematically close to some x != 1, you just divide all their estimates by x to compensate for their optimism (or pessimism, as the case may be). If the estimate factors are all over the board, you teach them how to estimate times better.

Engineers tend to speak plainly and to the point. Most straight thinking technical people wouldn't want to work in a place where people utter phrases like "the very best of the collective ecosystem knowledge." This is bullshit. If you don't know something, say "I don't know," not "to the best of the universal flux's knowledge."

More on that here: http://joelonsoftware.com/items/2009/12/30.html

Joel Spolsky has a method which ostensibly accommodates for consistent over- or under-estimating by any individual developer. It takes a couple release cycles to collect the necessary information, then tries to use that data to provide a likelihood that a product will ship by a given date.

I just make a wild guess and multiply by 2. Joel Sposky had a different take on time management:

http://www.joelonsoftware.com/items/2007/10/26.html

Your point is well taken, though. If you want to give away free samples, giving them to notorious critics of mostly everything is probably not a good idea.

An entertaining case in point.

http://www.joelonsoftware.com/articles/fog0000000072.html
http://www.joelonsoftware.com/articles/TwoStories.html
http://www.inc.com/magazine/20080901/how-hard-could-it-be-how-i-learned-to-love-middle-managers.html?partner=fogcreek

http://www.joelonsoftware.com/articles/fog0000000072.html
http://www.joelonsoftware.com/articles/TwoStories.html
http://www.inc.com/magazine/20080901/how-hard-could-it-be-how-i-learned-to-love-middle-managers.html?partner=fogcreek

It's a valid use case, but as you describe it, it means that every time you actually want to check the return value of fopen(), you use @ anyway. So whenever you use fopen() without @, you're effectively asserting that the file exists, and the following code will not have any checks (otherwise you'd use @ to avoid the warning message). If so, why isn't the use of fopen() without @ not a critical error that will prevent the following code from running, terminating the application - for example, by throwing an exception (as it happens in e.g. Java, C#, Python...)?

No, no, no. I check the return value every time, whether I use "@" or not. The return value check is for displaying a sensible message to the end user. In deployment, the PHP-generated message is *always* suppressed, "@" or no "@", so the return value check must always be there for every call.

I use "@" to suppress the PHP-generated debug message during development for specific calls where the failure is expected/harmless so that my HTML layout isn't hopelessly broken by those bogus warnings. They're suppressed because of the high false positive rate on that particular call. I omit the "@" on most calls because they should not fail even during development. That way, I get the detailed debug info during testing.

Either way, in the deployment phase, the "@" effectively occurs for every call, and the only error output comes as a result of checking the return value and generating a user-centric message.

If so, why isn't the use of fopen() without @ not a critical error that will prevent the following code from running, terminating the application - for example, by throwing an exception (as it happens in e.g. Java, C#, Python...)?

Because in deployment, that's the last thing you'd want. You want to trap the bad return value and display a user-friendly "Your changes could not be saved" formatted to match the site rather than "Java.lang exception blah blah blah" in black text on white or whatever.

Also, I generally need to identify that something went wrong as close as possible to the call because that's the only part of the code that knows precisely what was happening at the time, and thus that's the only place where a precise error message can be generated. It is also often necessary to roll back earlier operations when one part of a complex operation fails. That's not possible except right at that point in the code. If I can't just let the exception bubble up very far in my call stack, then there is no real advantage to using an exception over a return value.

Finally, I usually don't care why a call failed outside of the debug environment. I only care that it failed. With return values, I can typically handle every possible failed exit status with a single if statement. With exceptions, depending on how the particular function was designed, it can require multiply-nested try/catch blocks, one for each class of exceptions, all of which then have to set some flag so that later in the function you can treat each of them as being the same fundamental failure (or add an unnecessary function call whose sole purpose is to call the exception-throwing function, catch the exception, and return an exit status).

Also, exceptions are, in my opinion, simply a bad programming practice that leads to sloppy, buggy, insecure programming.

http://www.joelonsoftware.com/items/2003/10/13.html
http://silkandspinach.net/2005/06/14/exceptions-considered-harmful/
http://blogs.msdn.com/larryosterman/archive/2004/09/10/228068.aspx

That's what we learned when we asked a similar question with another FOSS project called KATO. Those who responded said that they couldn't figure out what KATO could do for them. You need to be very specific and concrete. Say it in five words or less and surface it very prominently.

I really don't get this. I sit in front of an LCD monitor all day, every day, and read and/or type away. I touch-type, so even if I'm typing, I'm looking at the screen. I don't get tired eyes, I don't have a problem reading for hours on end.

I went into the local bookstore and saw one of these e-ink readers (made by Sony, I think), and I thought the display was truly awful - blurry, low-contrast, and far-and-away more difficult to read.

Perhaps it has to do with the different ways that OSX and Windows (which most people are used to) put type on the screen. OSX tries to mimic print layout as much as possible. Windows attempts to line up to the pixel matrix on the screen. I'm not saying Windows is wrong in this - it's a matter of preference - but I far prefer the smooth characters on an OSX display.

I guess it's "common knowledge" that eInk is "better", but I'm not seeing it. I wonder if it's just common knowledge that eInk is better than Windows LCD displays ?

Simon

He's probably thinking of articles like this:
http://www.itwriting.com/blog/541-mshtml-layout-engine-completely-rewritten-for-internet-explorer-8.html

Interesting article here: http://www.joelonsoftware.com/articles/fog0000000069.html

"[netscape killed themselves by rewriting]
Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make:
They decided to rewrite the code from scratch."

Joel's argument is "code doesn't go bad. it is better to sand it and polish it because a given code base has already had a lot of bugs found and removed. writing a new codebase brings you back to bug rich code".

And a qualified expert to use it!

With this functionality removed I would have no reason left to stick with Firefox.

You are so right. If they really did do this then they would lose so many of their users. This is so perfectly Netscape of them and as such I'd like to link to a suitable story from Netscape's past in the hope to god that the Mozilla people can learn from the past.

Dear Mozilla people:

• if you are defining a new plugin interface only use it if it's better
• if it is better; then implement the old interface using the new one. If you can't then it isn't better.
• prove that you can refactor the plugins so that 95% or more of old plugins (and 100% of popular ones) work in the new system
• Until you get 90% of old plugins working, don't let the new system anywhere near production.
• Make it the responsibility of the people with the new interface to get the refactoring working for those 90% of plugins.

It's so simple. The new should not be allowed to break the old. If the new has to do that, then it's design is bad.

Well, I think this would be the article Zed needs to read:

http://www.joelonsoftware.com/articles/fog0000000332.html

Basically, many programmers feel that everybody else around him(or her) is a stupid asshole. However, if you want succeed, (e.g. have everybody around you learn statistics) you should never, ever, ever make enemies.

Be productive, work hard, listen to others, and try to do the work in the *right way*. Gain respect from yor collegues, and then they will get interested.

This wouldn't be Microsoft's first date related blunder. Did anyone ever experience the excel date quirk? Apparently MS didn't realise 1900 wasn't a leap year. A by product of this is that your dates gain 4 years if you open them on Mac Office. What about the Zune's effort with the 366th day of 2008?
Although I think this just requires a different marketing strategy, a mobile email device that can help me travel into the future? I'll take two please.

All joking aside, that's not a bug, that's a feature.

Reading about the details behind such things can reduce a grown programmer to tears. (the bit about 1900 issue is towards the middle)

You may benefit by taking a look at Joel Spolsky's opinion of that particular hammer.

That article does not argue against refactoring, it argues against rewriting your code from scratch. In fact, the author mentions refactoring as a good alternative to rewriting the code.

Since you have never seen his code and know nothing about its application, it would seem you carry around the "refactor it!" hammer.

You may benefit by taking a look at Joel Spolsky's opinion of that particular hammer.

And he tells there that they done that precisely to create more revenue.

There's another name for what killed DNF: "feature creep". Classic mistake. So is hiring extra people to work on a project that's already late.

After reading the article, it's blindingly obvious that what really killed the project was nothing but bad project management.

"Shipping is a feature. A really important feature. Your product must have it."

Apology accepted.

Actually, I don't necessarily take "unprofessional" as an insult. Some of the greatest accomplishments in software have been from amateurs.

Perhaps you're one of that rare breed that actually brings "process" to the table from day 1, and doesn't do it in a way that merely produces rheems of design documents without code to show for it. I've heard of this happening, but I haven't seen it in action.

I wager such programmers are rare, to the point where you're better off looking for those who will simply put forth effort, simply because you're far more likely to find them and get the job done.

For a far more eloquent and respected essay along these lines, please read The Duct Tape Programmer by Joel Spolsky, and let me know what you think.

People are accusing you of trolling, but I did recently see an advert for a .NET developer job where it actually did say "Please note we are not interested in individuals who work in C#". Now, I'm only a hobbyist programmer at the moment, but as far as I can see you should have no problem adapting to VB.NET if you're already familiar with C#. Is there any rational basis for this, or are the people advertising these jobs the sort of recruiters-who-use-grep described in Joel Spolsky's post at http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html ?

http://www.joelonsoftware.com/articles/fog0000000043.html

8. Do programmers have quiet working conditions?
There are extensively documented productivity gains provided by giving knowledge workers space, quiet, and privacy. The classic software management book Peopleware documents these productivity benefits extensively.

Here's the trouble. We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

The trouble is, getting into "the zone" is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Sometimes, if you're tired or have already done a lot of creative work that day, you just can't get into the zone and you spend the rest of your work day fiddling around, reading the web, playing Tetris.

The other trouble is that it's so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers -- especially interruptions by coworkers -- all knock you out of the zone. If a coworker asks you a question, causing a 1 minute interruption, but this knocks you out of the zone badly enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble. If you're in a noisy bullpen environment like the type that caffeinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.

With programmers, it's especially hard. Productivity depends on being able to juggle a lot of little details in short term memory all at once. Any kind of interruption can cause these details to come crashing down. When you resume work, you can't remember any of the details (like local variable names you were using, or where you were up to in implementing that search algorithm) and you have to keep looking these things up, which slows you down a lot until you get back up to speed.

Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).

Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff. Ahhh!

I've found the second half of this to be persuasive in the past:
  * http://www.joelonsoftware.com/articles/fog0000000068.html

--
Here's the trouble. We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.

The trouble is, getting into "the zone" is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Sometimes, if you're tired or have already done a lot of creative work that day, you just can't get into the zone and you spend the rest of your work day fiddling around, reading the web, playing Tetris.

The other trouble is that it's so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers -- ESPECIALLY interruptions by coworkers -- all knock you out of the zone. If you take a 1 minute interruption by a coworker asking you a question, and this knocks out your concentration enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble. If you're in a noisy bullpen environment like the type that caffinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.

With programmers, it's especially hard. Productivity depends on being able to juggle a lot of little details in short term memory all at once. Any kind of interruption can cause these details to come crashing down. When you resume work, you can't remember any of the details (like local variable names you were using, or where you were up to in implementing that search algorithm) and you have to keep looking these things up, which slows you down a lot until you get back up to speed.

Here's the simple algebra. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity. For this example, lets put two programmers, Jeff and Mutt, in open cubicles next to each other in a standard Dilbert veal-fattening farm. Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).

Now let's move them into separate offices with walls and doors. Now when Mutt can't remember the name of that function, he could look it up, which still takes 30 seconds, or he could ask Jeff, which now takes 45 seconds and involves standing up (not an easy task given the average physical fitness of programmers!). So he looks it up. So now Mutt loses 30 seconds of productivity, but we save 15 minutes for Jeff.

Anyway, I fully expect that most of you, reading this, will write to say, "what the heck are you doing reading Upside anyway? You get what you deserve". How true. Serves me right.
--

No innovation here. As long as the ETF represents the losses that the provider would have had because of an early termination, I see no issue with it. If the cost of the phone is subsidized by the service contract, then an ETF should be the remaining subsidized cost of the phone. That should be specific to the type of phone, and spelled out in the contract.

Now the real question is: should the providers be allowed to even subsidize the phones via a combination service contract? I say sure because many people need this as a way to bankroll the cost of a new phone (a real bank is less likely to grant credit because they don't have a particular interest in generating demand for phone services). For this to be a valid offering, it needs to also offer paid-up-front pricing for the phone, and service at the basic service rate. The basic service rate must not be more than the total term cost minus the ETF (no jacking the service rates to embed the cost of phones). Basic service must be available to anyone owning a compatible phone, too.

The phone and the phone service are complements in microeconomics, just like Joel described. In this case the phone company is assisting in lowering the cost of one to drive demand for the other which they make their real revenue on (supposedly). That's fine as long as the basic costs balance out (not considering the extra service someone might later choose to add on) for the consumer. The problem exists when these numbers manipulate the consumer to bring in un-earned revenues (much like banks do for all those service fees they charge which are way much more then the supposed costs they claim those are to cover).

Again, there is no innovation here by Verizon, regardless of whether you look at this as a means to subsidize phones for people that cannot afford to buy them up front (and don't have the will power to save up to buy them later on), or look at this as a way to boost revenues by ripping off less savvy consumers ... because both of these things have been going on for decades.

A lot of the comments are pointing out the problems in Javascript, and ignoring the problems in the big heavyweight languages like Java and C#.

It's not really in praise of Javascript, but a very good read is Joel's article 'Can Your Programming Language Do This?' It accurately points out a number of ways in which Java development very quickly takes up a lot of lines of code compared to more lightweight approaches. I personally prefer the light weight approach for many applications.

http://www.joelonsoftware.com/items/2006/08/01.html

MS Word had great import and export capabilities when WordPerfect was the market leader, and so did Excel when Lotus 1-2-3 was the market leader.

Yep, read this article from Joel on Software:
http://www.joelonsoftware.com/articles/fog0000000052.html

Copilot (from Joel of Joel on Software fame) just works. I give my family a code, they type it into the website and download and run the .exe.

If you like, they can hang on to that .exe file and reuse it next time (so long as you also keep your corresponding helper .exe).

It's free at weekends; the rest of the time it's very cheap (and pay-as-you-go, so no monthly subscription - you just pay for the minutes you use).

I refer to this article.

I would assume that the Microsoft Excel team did it this way as well, since Joel mentions it in his article. But they also wrote their own compiler because everyone else's was crap, and still managed to ship on time.

I refer to this article.

I would assume that the Microsoft Excel team did it this way as well, since Joel mentions it in his article. But they also wrote their own compiler because everyone else's was crap, and still managed to ship on time.