Slashdot Mirror

> That's a pretty priceless strawman, given that while Bill Gates may have a lot of micromanagement tendencies, he wasn't chiefly responsible for a lot of what made Windows, Excel, Word, etc.

*Facepalm*

1. Joel says otherwise

"I don't know, you guys," Bill said, "Is anyone really looking into all the details of how to do this? Like, all those date and time functions. Excel has so many date and time functions. Is Basic going to have the same functions? Will they all work the same way?"

"Yes," I said, "except for January and February, 1900."

"OK. Well, good work," said Bill. He took his marked up copy of the specand left.

:

  Bill Gates was amazingly technical. He understood Variants, and COM objects, and IDispatch and why Automation is different than vtables and why this might lead to dual interfaces. He worried about date functions. He didnâ(TM)t meddle in software if he trusted the people who were working on it, but you couldnâ(TM)t bullshit him for a minute because he was a programmer. A real, actual, programmer.

2. Bill Gates personally reviewed every line of code for the first 5 years

During Microsoft's early years, all employees had broad responsibility for the company's business. Gates oversaw the business details, but continued to write code as well. In the first five years, he personally reviewed every line of code the company shipped, and often rewrote parts of it as he saw fit.

:

He finally retired as chief software architect in June 2008,

Do you actually have ANY clue what a Chief Software Architect (also called CTO Chief Technical Officer) means?

3. Who co-founded and RAN MS again??? The buck started and stopped with him. He would make announcements of what MS was working on next and would announce when they were ready. While he may have only written a small percentage of the code in the later years he was either directly or indirectly responsible for everything MS did, especially buying software companies and slapping their own MS label on it. Gee, go figure. From the same article previously linked:

He met regularly with Microsoft's senior managers and program managers, and was reportedly verbally pugnacious, berating managers for perceived holes in their business strategies that placed the company's long-term interests at risk.

The point is Bill wasn't some clueless company president. He was VERY much hands on. Especially in the early years.

This has got to be a new low on /. I'm defending the guy and I hate his business practices! LOL.

One issue you’re ignoring is that a lot of us open source developers would love to spend more time on open source, but have signed "inventions" contracts which force us to turn over any "inventions" we make, in our spare time or not, over to our employer (California has a "on your own time, with your own computer, as long as it is not related to what your employer makes" exception, but some companies argue they make everything, so the third clause means they own everything a developer can possibly do in their free time).

I know a lot of companies use Redis, so hopefully there are enough with managers with some clue who are willing to allow some of their developers to take the time to maintain an open source fork of it. Or, maybe the US can be like Germany and mandate the employees must have six weeks of paid time off every year; that would allow developers to contribute to open source during those six weeks.

It's a question of money, and whether we want to benefit the 1% (more proprietary software) or the 99% (more open source software libre) when all is said and done.

Joel Spolsky has provided some background on this.

Back in the late 1990's Microsoft won the browser war against Netscape

Microsoft didnt win. Netscape lost. It was a do-it-yourself mugging.

Netscape committed suicide.

Lots of people are paid to work on open source projects

When people are paid to work on open source, they are usually given a specific checklist of things to work on, and are paid by people that have already figured out the UI.

Also, plenty of "UI designers" aren't actually very good at designing UIs. You aren't going to get a world class designer from a Craigslist ad.

Here's a better suggestion: Read some books on UI design. A very good one is Don't Make Me Think.

The Design of Everyday Things is not about software, but is still a good book that every engineer should read.

You should always do "Hallway Usability Tests", as well as the other 12 things on this list.

Surely the OS is providing standard access to every FS

They are trying, and largely succeeding. Nevertheless, all non-trivial (and filesystems are highly nontrivial) abstractions are leaky

fopen() will still work, regardless, surely... no?

A service that offers background sync (i.e. changes are pushed to the cloud in the background) which doesn't just poll (polling is evil) needs an API much more complicated that fopen. Specifically, it needs a notification stream where it can create a 'watched' folder and be notified when:

• A file in the watch was opened for writing was closed
• A new file or directory entry was created
• A file or directory was deleted
• A file or directory was moved, either from outside the watch to inside, inside to outside or inside to inside. Note that this is essential to allow users to rename or reorganize their folders without retransmitting the entire file each time
• Probably more I'm not thinking of . . .

This is a (somewhat) solved problem, in the sense that inotify exists within some limitations described on the wikipedia page (and further in the man page). One really obvious limitation is that the kernel will not do this recursively for you, meaning that the client has to manually add/remove folder watches. The other is that rename events are clunky, coming in two halves with a linking identify. Anyway, if you read the history, you'll note this is the third or so attempt at getting this right, which at least suggests that it's non-trivial enough that we had to can the original (dnotify) interface and start over once.

What was the point of this side-track into filesystem watching? Well, for one, we started with "how hard is fopen/fread" and now ended up with "holy crap, that's highly non-trivial to be async notified of changes within a directory tree (recursively!)". It also raises the question of whether the interface really is an airtight abstraction, or whether filesystem implementation details leak into the caller to be dealt with. Even answering that question for all supported Linux filesystems is non-trivial.

If you take nothing else away, just remember that this is a far more complicated problem than rsync ;-)

Postscript: rsync is 50K LOC

Joel on Software did an interesting profile of the problems with strcat() et al:

https://www.joelonsoftware.com/2001/12/11/back-to-basics/

However, despite the inefficiencies and security concerns, concatenating strings in C is a solved problem. No reinventing of wheels is necessary.

https://www.joelonsoftware.com...

That's software, these are laws. Turns out we use ridiculously old laws in an ongoing fashion - pretty much for the same reason that Joel specifies in that article.

I'm going to assume that pressing you for specifics is just going to result in more evasion. If you would like to identify a particular piece of the constitution that you feel is outdated so that we can discuss it, I'll be happy to pick this back up.

This is an office I'd like to work in, from a company owner who gets it. I'm sure the amount he put into getting this office has more than paid out in increased productivity.

Too bad other companies won't read anything other than the 4-color glossies from the Gartner Report, peddling the "synergy" produced from a open office.

Not necessarily.

As a general rule, software developers aren't that interested in being paid a lot. Sure, we'd all like more money, but it turns out not to be a real motivator. Its main effect on morale is as demotivation: if a developer thinks he or she is underpaid, he or she will think he or she is disrespected, and morale drops.

If the employer has compensation based on transparently reasonable criteria, the employee will not feel personally underpaid. It's a good method to avoid the bigger problem while losing the much less important benefits.

Joel on Software has much more detail on this.

Does not fulfill all of your requirements, but it is simple, and has web and mobile apps:
https://trello.com/

Made by https://www.joelonsoftware.com... , who has a style that most, but not all, developers like.

I suspect there's been 15-20 years of programmers telling the higher ups that they need to rewrite this stuff

When programmers are faced with maintaining someone else's code, they ALWAYS recommend throwing it all away and starting over. This is rarely the correct thing to do.

Things you should never do

I'm sure he didn't mean that exchanging files was impossible prior to the Internet but you can't seriously compare the concept of mailing floppy disks or dialing up with AOL to the era where suddenly everyone was online all the time.

The author, Joel Spolsky, was a Program Manager on Excel back in the day, so this article is based in part on his experiences working on Excel, it's not just some blogger spitballing.

Maybe there are deliberate file irregularities that Microsoft uses to try to force people to buy new versions of Microsoft Office.

No, the reason Office document interoperability is so difficult is because Microsoft designed these formats for themselves, for their own programs, with no thought to interoperability in either direction, and with other concessions in mind like how the early versions of Word and Excel needed to run on really old computers.

Pretty much exactly ten years ago Microsoft released documents to satisfy the EU that detailed exactly how the Word and Excel file formats worked, and they were PDF files that were 400 and 450 pages long. People like yourself speculated that perhaps they had been purposely obfuscated to thwart developers but the truth of the matter is that these things were designed over the course of decades and had a whole lot of stuff in them as a result of the increased complexity of the requirements.

To some extent, Office applications have the contents of the document loaded into memory and the document file itself is basically a memory dump of the contents of the memory serialized to disk. Loading the document deserializes it into memory. People complain about this but again, when your perspective is you need to have this application you're programming write out files and then read them in later, it makes perfect sense as a plan of action. It also explains why occasionally Office breaks compatibility with itself on upgrades which is unacceptable but it happens.

In that vein, LibreOffice has had the specs for the Office documents for a decade now, so I think the "what is the excuse?" question is still pretty valid. But the issue is not that Microsoft deliberately sabotages efforts. They're not that smart and they're not that dumb.

If you read Raymond Chen's Old New Thing blog he explains how the compatibility stuff is mostly in shims that get loaded only when an application needs them. So the notion that worrying about compatibility held back Microsoft is dubious.

Despite that Microsoft did abandon back compatibility around XP SP3 and Vista which both broke insecure code. And then they tried to convince people to stop writing Win32 code and start writing code for their newest API which changed every year. Joel ranted about this memorably

https://www.joelonsoftware.com...

Unfortunately the effect was that people stopped writing Win32 code and started writing code for IOS and Android. And people started doing everything they could to avoid OS versions because they broke all their third party apps and pushed them obnoxiously to use Metro ones. Which no one was writing.

Ie abandoning back compatibility gained them nothing and will probably kill the Windows as a platform in the long run.

Net Neutrality is a slogan they use to promote Title II regulation of ISPs, i.e. they want to regulate their complements. It reminds me of Joel On Software's memorable line that 'smart companies try to commoditize their complements'. E.g. Microsoft encouraging clone PCs. That drove down hardware prices which meant a consumer buying hardware and software would have more free cash to spend on software.

https://www.joelonsoftware.com...

Once again: demand for a product increases when the price of its complements decreases. In general, a company's strategic interest is going to be to get the price of their complements as low as possible. The lowest theoretically sustainable price would be the "commodity price" - the price that arises when you have a bunch of competitors offering indistinguishable goods. So:

Smart companies try to commoditize their products' complements.

If you can do this, demand for your product will increase and you will be able to charge more and make more.

Similarly Title II regulation of ISPs theoretically means that ISPs will be less able to charge Google a premium to be on a fast lane and/or less able to charge consumers a premium to access that fast lane. Meanwhile Google would be unregulated and free to do non Net Neutral stuff.

Sounds good in theory? Well even under Wheeler the FCC allowed for zero rating, e.g. T Mobile's Binge On, though he muttered he might rule differently about future offerings.

http://www.multichannel.com/ne...

"Tom Wheeler's comments regarding T-Mobile's new BingeOn zero-rating plan calls to mind the good familiar cop/bad cop routine," said Randolph May, president of free market think tank, the Free State Foundation. "On the one hand, Wheeler's statement that the plan is pro-competitive and innovative is commendable. On the other hand, his further elaboration that the FCC will monitor the T-Mobile plan for compliance with the Open Internet Order's 'good conduct' rule is disturbing. This is because the vague 'good conduct' standard means anything that Wheeler's Enforcement Bureau says it means on any given day."

Tech companies need a strong leader who is detail obsessed. E.g. consider Microsoft back in the Bill Gates days

https://www.joelonsoftware.com...

In those days we used to have these things called BillG reviews. Basically every major important feature got reviewed by Bill Gates. I was told to send a copy of my spec to his office in preparation for the review. It was basically one ream of laser-printed paper.

I rushed to get the spec printed and sent it over to his office.

Later that day, I had some time, so I started working on figuring out if Basic had enough date and time functions to do all the things you could do in Excel.

In most modern programming environments, dates are stored as real numbers. The integer part of the number is the number of days since some agreed-upon date in the past, called the epoch. In Excel, today's date, June 16, 2006, is stored as 38884, counting days where January 1st, 1900 is 1.

I started working through the various date and time functions in Basic and the date and time functions in Excel, trying things out, when I noticed something strange in the Visual Basic documentation: Basic uses December 31, 1899 as the epoch instead of January 1, 1900, but for some reason, today's date was the same in Excel as it was in Basic.

Huh?

I went to find an Excel developer who was old enough to remember why. Ed Fries seemed to know the answer.

"Oh," he told me. "Check out February 28th, 1900."

"It's 59," I said.

"Now try March 1st."

"It's 61!"

"What happened to 60?" Ed asked.

"February 29th. 1900 was a leap year! It's divisible by 4!"

"Good guess, but no cigar," Ed said, and left me wondering for a while.

Oops. I did some research. Years that are divisible by 100 are not leap years, unless they're also divisible by 400.

1900 wasn't a leap year.

"It's a bug in Excel!" I exclaimed.

"Well, not really," said Ed. "We had to do it that way because we need to be able to import Lotus 123 worksheets."

"So, it's a bug in Lotus 123?"

"Yeah, but probably an intentional one. Lotus had to fit in 640K. That's not a lot of memory. If you ignore 1900, you can figure out if a given year is a leap year just by looking to see if the rightmost two bits are zero. That's really fast and easy. The Lotus guys probably figured it didn't matter to be wrong for those two months way in the past. It looks like the Basic guys wanted to be anal about those two months, so they moved the epoch one day back."

"Aargh!" I said, and went off to study why there was a checkbox in the options dialog called 1904 Date System.

The next day was the big BillG review.

June 30, 1992.

In those days, Microsoft was a lot less bureaucratic. Instead of the 11 or 12 layers of management they have today, I reported to Mike Conte who reported to Chris Graham who reported to Pete Higgins, who reported to Mike Maples, who reported to Bill. About 6 layers from top to bottom. We made fun of companies like General Motors with their eight layers of management or whatever it was.

In my BillG review meeting, the whole reporting hierarchy was there, along with their cousins, sisters, and aunts, and a person who came along from my team whose whole job during the meeting was to keep an accurate count of how many times Bill said the F word. The lower the f***-count, the better.

Bill came in.

I thought about how strange it was that he had two legs, two arms, one head, etc., almost exactly like a regular human being.

He had my spec in his hand.

He had my spec in his hand!

He sat down and exchanged witty banter with an executive I did not know that made no sense to me. A few people laughed.

Bill turned to me.

I noticed that there were comments in the margins of my spec. He had read the first page!

He had read the first page of my spec and written little notes in the margin

I somewhat disagree. Most systems exist for many years or even decades after they should have been replaced. Here's an old but good article from Joel on Software:

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

It talks about how code rewrites almost always fail. I could easily come up with another hundred examples. We've started rewriting our inventory system three times and failed three times. I heard the last failure cost over 20 times what the software originally cost to write. If you're the go to guy for a legacy system and are willing to slog away at maintenance and work on the uninteresting problems that others don't want to, then you are a great asset.

The odd thing is that Microsoft have being doing this since Win32

Post Win32 you had MFC which I spent a lot of time learning, only to eventually go back to Win32.

Then there was .Net, WinForms, Windows Presentation Framework/Avalon, Metro, Windows RT. Anyone who adopted one found it deprecated in a year or two. As Joel On Software put it

https://www.joelonsoftware.com...

Now Microsoft has so many developers cranking away that it's not enough to reinvent the entire Windows API: they have to reinvent it twice. At last year's PDC they preannounced the next major version of their operating system, codenamed Longhorn, which will contain, among other things, a completely new user interface API, codenamed Avalon, rebuilt from the ground up to take advantage of modern computers' fast display adapters and realtime 3D rendering. And if you're developing a Windows GUI app today using Microsoft's "official" latest-and-greatest Windows programming environment, WinForms, you're going to have to start over again in two years to support Longhorn and Avalon. Which explains why WinForms is completely stillborn. Hope you haven't invested too much in it. Jon Udell found a slide from Microsoft labelled "How Do I Pick Between Windows Forms and Avalon?" and asks, "Why do I have to pick between Windows Forms and Avalon?" A good question, and one to which he finds no great answer.

So you've got the Windows API, you've got VB, and now you've got .NET, in several language flavors, and don't get too attached to any of that, because we're making Avalon, you see, which will only run on the newest Microsoft operating system, which nobody will have for a loooong time. And personally I still haven't had time to learn .NET very deeply, and we haven't ported Fog Creek's two applications from classic ASP and Visual Basic 6.0 to .NET because there's no return on investment for us. None. It's just Fire and Motion as far as I'm concerned: Microsoft would love for me to stop adding new features to our bug tracking software and content management software and instead waste a few months porting it to another programming environment, something which will not benefit a single customer and therefore will not gain us one additional sale, and therefore which is a complete waste of several months, which is great for Microsoft, because they have content management software and bug tracking software, too, so they'd like nothing better than for me to waste time spinning cycles catching up with the flavor du jour, and then waste another year or two doing an Avalon version, too, while they add features to their own competitive software. Riiiight.

No developer with a day job has time to keep up with all the new development tools coming out of Redmond, if only because there are too many dang employees at Microsoft making development tools!

On top of this I have been using this list for interview questions. https://www.joelonsoftware.com...

It is amazing how it weeds out environments where the devs have 0 clue what they are doing.

In this case step 10 is missing. You can have a few missing. But in my book missing #10 would be a big red flag of a dysfunctional environment and my follow up question would be how do you mitigate new bugs and ongoing bugs. Because they would not be managed. With #10 missing #4 and #5 would quickly go out the window.

QA takes a particular mindset and ability. Not all developers have that in addition to their primary skillset. Some of the best testers I have worked with could never write any code. They just had a knack for finding bugs though.

"Sometimes, it's better to start from scratch, which is especially true for software development," Odvarko said.

https://www.joelonsoftware.com...

I am working on a case where I'm heavily modifying a charting library to fit my particular use case. In hindsight, I should have just started from scratch. Here is why that would have been the correct decision. The charting library I started with had a crap ton of features. Everything was written to an interface, with most classes having four or five levels of inheritance and this massive ipc mess kicking around a custom property handler to update threads in the system.

The thing is, I needed a fairly narrow subset of that, with a bunch of interface breaking changes left and right. I ended up deleting like half of it to get it out of my way, and there are now fewer levels of inheritance, since I needed the different parts to work together more closely to get decent performance. The biggest thing I could have reused would be the idea of using a force based layout algorithm, but even then I could have recreated it fairly fast and had something more maintainable in the end if I started from scratch.

Of course I originally thought I'd just do small changes and move on with life. Sadly that didn't work out. I even half planned to try to get my company to let me export the changes to the parent project. That didn't work out either, as my changes are too invasive for the parent project to want them.

Basically it seems you can get by with writing it from scratch if the work to do so is on the same order as making anything else do the task, particularly if you can't ship those improvements off to that project for someone else to help maintain. Of course, I still think we perhaps start over too quickly, but I gave this a fair shot and I'm still not starting over since it is too late for that solution not to take longer.

Ironically, had I started from scratch I wouldn't have learned some architectural ideas I might have needed to do a clean rewrite of the small bit I needed. I could have still done it, since I could have figured them out.

Maybe in the end the biggest warning about starting over is to ask yourself if you understand why things are how they are. The reasons may be good or bad, but if you don't understand the current design to some extent you risk making a worse design.

"Sometimes, it's better to start from scratch, which is especially true for software development," Odvarko said.

https://www.joelonsoftware.com...

Is there evidence he has deep knowledge about technology? Is there evidence he has deep knowledge about programming, for example?

You can look at his code and judge for yourself. He aced the SAT so it's reasonable to assume he could acquire deep knowledge about programming, whether he did or not. Reports are that he was technical at Microsoft. Other reports suggest he mentored other programmers.

All in all, there's plenty of evidence that Bill Gates understands programming as well as many working programmers.

Maybe you don't know him that well. I suggest to read this story from joelonsoftware:

Then I sat down to write the Excel Basic spec, a huge document that grew to hundreds of pages. I think it was 500 pages by the time it was done.
[...]
In those days we used to have these things called BillG reviews. Basically every major important feature got reviewed by Bill Gates. I was told to send a copy of my spec to his office in preparation for the review. It was basically one ream of laser-printed paper. I rushed to get the spec printed and sent it over to his office.
[...]
I noticed that there were comments in the margins of my spec. He had read the first page!

He had read the first page of my spec and written little notes in the margin!

Considering that we only got him the spec about 24 hours earlier, he must have read it the night before.

He was asking questions. I was answering them. They were pretty easy, but I can’t for the life of me remember what they were, because I couldn’t stop noticing that he was flipping through the spec

He was flipping through the spec! [Calm down, what are you a little girl?]

  and THERE WERE NOTES IN ALL THE MARGINS. ON EVERY PAGE OF THE SPEC. HE HAD READ THE WHOLE GODDAMNED THING AND WRITTEN NOTES IN THE MARGINS.

He Read The Whole Thing!

https://www.joelonsoftware.com...

Bill Gates was the real thing.

Because really good programmers are hard to find.

If something is clickable, make it look clickable. If some items are clickable and some are not, they should look different.

But hey, we've only known this for 17 years. Maybe not everyone has caught up yet.
https://www.joelonsoftware.com...
(Scroll down to the "etrade" example.)

This is what happens when developers make business decisions. Seriously, why is Mozilla focused on promoting/using/developing Rust, when they could be focused on making their browser suck less? Probably because they have no business concerns, at all, about making a viable product (or company.) I spent two weeks exclusively using Firefox, right when Google was found to be recording everything I said, in the event I happened to say "OK Google" without a way to turn this off. After two weeks, I realized I'd rather be bugged than use Firefox any longer.

This is exactly what Joel Spolsky wrote about, when Netscape did a complete rewrite here, or in his awesome book Joel on Software . Netscape focused on a rewrite, instead of making their browser suck less.

It sounds like Netscape made this mistake and then became Firefox. Now, it seems like Firefox is making the exact same mistake. This has to be the funniest business case study ever.

https://www.joelonsoftware.com...

This is one of his blog posts that is almost an infomercial for his product, but he does describe the concept well enough that you could roll your own if you wanted to.

This has been answered many times over the years. Joel Spolsky did a good job in his book Joel on Software , which I highly recommend you read if you're asking these kind of questions. His blog is good too.

As Joel Spolsky keept trying to remind us

Last year I went to a Computer Science conference at Yale. One of the speakers, a Silicon Valley veteran who had founded or led quite an honor roll of venture-capital funded startups, held up the book Peopleware.

“You have to read this book,” he said. “This is the bible of how to run a software company. This is the most important book out there for how to run software companies.”

I had to agree with him: Peopleware is a great book. One of the most important, and most controversial, topics in that book is that you have to give programmers lots of quiet space, probably private offices, if you want them to be productive. The authors, DeMarco and Lister, go on and on about that subject.

After the speech I went up to the speaker. “I agree with you about Peopleware,” I said. “Tell me: did you have private offices for your developers at all your startups?”

“Of course not,” he said. “The VCs would never go for that.”

Hmm.

“But that might be the number one most important thing in that book,” I said.

“Yeah, but you gotta pick your battles. To VCs, private offices look like you’re wasting their money.”

You just demonstrated my point. There's no such thing as "the fastest possible way". Is your data uniformly distributed over a fixed range? If so, you can use a bucket sort to process it in O(n) time. But if the distribution is non-uniform, a bucket sort can be very slow. Maybe your input data is partially sorted. If so, some algorithms will take advantage of that to sort it faster and others won't. Did you ever think to wonder whether the sort function is multithreaded? Probably not, because if you're already using multiple threads at a higher level, that would just slow things down. But if you aren't, that could speed things up a lot.

This is a great example of the law of leaky abstractions. In most cases, just calling the framework's sort function is the best thing to do. Except that every now and then, it isn't. A good software engineer understands that. They know the framework provides an abstraction, and that abstraction sometimes breaks down, and they can deal with it when it does. Even if they don't know all the low level details, they know enough to know what questions to ask.

"(Joel on Software has a good article about the costs of hiring a bad employee vs the costs of hiring no one)."

Are you referring to this article? The Guerrilla Guide to Interviewing (version 3.0)

Old but excellent article about the choice between organic growth vs get big fast, and how to implement the decision: https://www.joelonsoftware.com/2000/05/12/strategy-letter-i-ben-and-jerrys-vs-amazon/

So, if you look at the foreign language requirement for what it is (an "expand your mind" requirement), then it is plainly obvious that coding achieves the same objective.

Joel Spolsky,in his rant on Java Schools, sort of touches on this:

Heck, in 1900, Latin and Greek were required subjects in college, not because they served any purpose, but because they were sort of considered an obvious requirement for educated people. In some sense my argument is no different that the argument made by the pro-Latin people (all four of them). âoe[Latin] trains your mind. Trains your memory. Unraveling a Latin sentence is an excellent exercise in thought, a real intellectual puzzle, and a good introduction to logical thinking,â writes Scott Barker. But I canâ(TM)t find a single university that requires Latin any more. Are pointers and recursion the Latin and Greek of Computer Science?

Granted, he is arguing for CS students always having to learn fundamental CS concepts like pointers and recursion, but I think that it is not too much of a stretch to think that coding will eventually become the Latin and Greek of our culture. Everybody should have to learn a bit of it if they want to consider themselves well educated and well rounded, and a small number will choose to specialize in it as a field of endeavor.

And if you are thinking to yourself, "Well, what's the point, they won't remember any of it?" Please go find any random middle aged person whose only exposure to foreign language was their 2 year requirement in high school and ask them how much Spanish, French, German, etc. they remember? Hint: their high school foreign language class didn't make them an expert in the foreign language, so would two years of programming in high school be seen as any less valuable from a macro-pedagogic perspective?

Learning C/C++ is hard as a first language, though it makes for better programmers.

Yah, sure. I don't know of many that actually believe this, and you're gonna have to back up that statement a little...

The Perils of JavaSchools

If you show a nonprogrammer a screen which has a user interface which is 100% beautiful, they will think the program is almost done.

People who aren't programmers are just looking at the screen and seeing some pixels. And if the pixels look like they make up a program which does something, they think "oh, gosh, how much harder could it be to make it actually work?"

I still don't understand all the hate toward systemd.

I think I can break some of this down for you...

Linux has had a number of de-facto standard implementations for things through the years: (working from memory) - For sound we had some various odds and ends, then focus started to go toward ALSA, then later we had JACK, and PulseAudio. Now it seems most major distros use PulseAudio.

And who 'spearheaded' PolypAudio - err, PulseAudio? Lennart Poettering. I was really excited about PA, until it utterly destroyed my sound for a couple of years. I couldn't make it work in Gentoo, and after about 8 months of pain, I switched to Ubuntu. That was also painful, but at least there were users there to help me transition from Gentoo and fix my audio issues. Audio was so bad, I had to switch back to Windows for anything audio related, whether it was games, audio, or video. The quality was especially bad for video capture. The kicker is I still today need to use the alsamixer to unmute channels from time to time. PA doesn't seem to have any way to do this.

- For our displays we've had the X window system for ages. Now we're starting to move toward Wayland and there's still some of the old grey/neckbeards that are simply afraid of change and digging their heels in on X.

I can understand this, too. The Wayland folks say, "The code is old and broken, we need to rewrite it." Wiser folks than I have blogged about this. Let me give you some examples of projects that foundered or died because of rewriting:

• Netscape 6.0 - released extremely late, ended up destroying the company
• MacOS 8 (Copland rewrite) - was slated as an update for System 7 - then MacOS 8 - then tossed (Apple bought NeXT instead). The MacOS 8 & 9 that were released were incremental updates to System 7
• Gnome 3
• KDE 4
• I'm sure others can think of more

In addition to that, they've deprecated useful features like X11 forwarding, and they just dusted off their hands and said, "Not my problem. That functionality should be handled by an application." It seems short-sighted to remove a working feature that a portion of people use, just because they don't believe it has value. From what I've read, adding it back in will be a non-trivial task.

Your big complaint is that it was once free-as-in-speech *and* free-as-in-beer. Tell me, how is software that you pay no money for and have access to all source code somehow not both definitions of free? Are you not still free to pick a distribution that uses sysvinit? upstart? openrc? Assuming you have the knowledge, ability, and time, couldn't you roll your own distro with all those features you want *and* pick which init system you wanted? Couldn't you get the source of systemd and rip out those things you don't like?

Sure, just like you could assemble your own car or build your own house. By yourself. Oh, and could you pay inspectors $MEGA_CURRENCY to go over it with a fine toothed comb to make sure it won't come down on your head in the middle of the night, or when explode when you flush all toilets simultaneously, or fall apart at 88 mph?

Looking at it another way, one of the biggest complaints about Linux adoption was the fragmentation across different distributions. Now Linux is starting to approach a standard for user space, which would make cross-distro development easier. Isn't that a good thing?

I agree that some standardization is a good thing. But we need not remove *all* choice. That puts us in the same boat as MS.

Also, one last note on L. P. He favors breaking compatibility with POSIX and BSD to speed development. So, if he feels that way about POSIX, the standard that makes Linux, well, Linux, who's to say he won't radically change direction again?

The article's links seem to have better real experimental data backing them up, but I still think I prefer reading http://www.joelonsoftware.com/'s 15 year old article "Human Task Switches Considered Harmful". The second half of "Where do These People Get Their (Unoriginal) Ideas?" is also relevant.

In the last few years he has posted much less often, and when he posts, it is usually only announcing the latest product his company has made, but most of his older "reading list" articles (from the front page) are still excellent.

The article's links seem to have better real experimental data backing them up, but I still think I prefer reading http://www.joelonsoftware.com/'s 15 year old article "Human Task Switches Considered Harmful". The second half of "Where do These People Get Their (Unoriginal) Ideas?" is also relevant.

In the last few years he has posted much less often, and when he posts, it is usually only announcing the latest product his company has made, but most of his older "reading list" articles (from the front page) are still excellent.

The article's links seem to have better real experimental data backing them up, but I still think I prefer reading http://www.joelonsoftware.com/'s 15 year old article "Human Task Switches Considered Harmful". The second half of "Where do These People Get Their (Unoriginal) Ideas?" is also relevant.

In the last few years he has posted much less often, and when he posts, it is usually only announcing the latest product his company has made, but most of his older "reading list" articles (from the front page) are still excellent.

Dunno about exception-based code. Joel Spolsky seems pretty much against it.

The problem was that the database was hidden behind ActiveRecord, so it was easy to forget we were using a database at all. Writing a for loop to search for a record that matched some criteria felt natural, because our interface was with objects, not the underlying tables.

Object-Relational Impendance Mismatch

Law of Leaky Abstractions

This problem is not unique to Ruby on Rails usage of the ActiveRecord pattern. People blindly using Hibernate and other ORMs run into the same thing, and it is, in general, what happens when people fall for one or more of the fallacies of distributed computing ("latency is zero" and "bandwidth is infinite".)

ActiveRecord pattern provides a theoretically pleasing abstraction, that is OK when accessing one row out of a relation. Trying to operate on a set of relations, as if they were a locally maintained collection however, that's where you hit the problems you mentioned.

Without some clever caching planned up front, your resources are always remote and not everything is supposed to fit an object-oriented model. Projects turn to shit when they forget these general rules.

Firefox has spent too much time adding useless crap like Hello. There are far more pressing issues. If I leave Firefox, it will be because of the abysmal performance problems which have been plaguing it for years. Background it, and you'll hear your CPU howling like a banshee while it displays a few otherwise static pages. People have been reporting these kinds of problems for years, but Mozilla closes problem reports with the meh button.

> , "since Mozilla is focused on rebuilding Firefox's code from scratch to keep up with speedier competitors like Chrome, Opera, and Vivaldi."

haha! that's exactly what Mozilla did and look what happened to them: http://www.joelonsoftware.com/...

He didn't echo anything back and you wouldn't recognise a literary device if it was carved on a flagstone and shoved it up your arse, sideways.
http://www.joelonsoftware.com/...

He just asked a dumb question because he's either an over-literal aspie or a troll pretending to be one.

According to this classic, you just need to make estimates, and measure results, and then you can normalize the values and make good predictions of actual time.

http://www.joelonsoftware.com/...

Hmmmm, what Joel says here definitely supports your point.

I"m reminded of Win9x days. You had much simpler software running much faster. Today we use much higher level languages which may improve stability, but we have lost a lot of the potential performance per watt. Adding more layers of abstraction seems the new thing at work, ignoring the fact that the targets are extremely resource constrained devices that run on battery power for long periods of time.

Some of the changes are necessary, yet some seems to go too far. All those layers of abstraction can really make it hard to debug subtle issues, since you have to step through each one and figure out what went wrong in what should just work. At any rate, I thought this site fit well. joelonsoftware

That's a *HORRIBLE* idea. You start thinking you can write that program, then generalization takes you down the internationalization/localization route, then you learn about character sets, font design considerations for new scripts, the political/international/interplanetary aspects of character encodings, and ... down that way lies madness. I think I need to lie down now.

sounds familiar
http://www.joelonsoftware.com/...

who needs another browser anyway?

Just to be clear... this is not Pale Moon writing their own web browser. This is Pale Moon reforking from a newer Firefox branch and reimplementing the features that distinguishes them from Firefox. So, the article and summary says "from scratch", which is misleading because it's not "from scratch" as most people understand the term (writing a new browser yourself from the ground up), it's modifying the newly branched Firefox code, adding their own new features or stripping out crap from Firefox. It's the Pale Moon features only that would have to be rewritten "from scratch".

Joel's advice doesn't account for this scenario, in which you're building new code on top of an existing forked codebase that is lagging behind modern web standards. There are only two choices: Moon Child can try to integrate massive amounts of Mozilla developer changes back into an older fork (impossible, really), or he can refork and redo his own changes. Given that undoubtedly Firefox's changes have been far more numerous and substantial, it probably makes sense to re-fork and rewrite the Pale Moon code.

Honestly, I'm not sure how this is really sustainable, as the same thing is bound to happen again in the future. And I've never figured out how anyone can be assured that Pale Moon is at all secure, either. I have a sneaking suspicion it's "secure" in the same way Macs (and Linux, actually) used to be secure - too small a target for anyone to bother with. I mean, I love the guts of these guys trying this, but... well, I wish them the best.

I also really hate whenever someone trots out this article of Joel's and presents it as gospel, because while it's a good rule of thumb, it's foolish to view any particular development rule as 100% inviolable. I've personally been involved in several highly successful near or partial complete rewrites of very large codebases. I'd say it's certainly a good default position to take - you'd need to convince me before tossing code and starting over. But there are times when doing so would actually be more damaging and end up compromising your new design too much in order to maintain compatibility. Often, it's far better to simply put in a compatibility shim, leave the old code behind, and build a new module next to it, switching over when backward compatibility is needed and slowly depreciating required dependencies.

Netscape 4 sucks, so lets throw it out and start again. Back when Spolsky could write he bitched about this.

Mozilla seamonkey sucks, so lets gut most of it and make Phoenix (now known as Firefox)

And now this again?

Seamonkey's actually pretty decent. It's lighterweight than Firefox (!!!) and comes with tons more features and custimizability. The only thing you lose is the newer stuff like Pocket or the chatting service, and you have an older interface pre-Auralis (though I daresay many consider these features). The real loss is fewer extensions are compatible, but a decent selection of Firefox ones still are, and there's even a converter that can get solid results. I don't know if you'll like it, but I'd reccommend to give it a try, if you want a good open source browser.