Programmers At Work: Bill Gates (1986) - <AUTHOR> http://programmersatwork.wordpress.com/bill-gates-1986/ <comment> Jackson-Solway Side note: The illustrated portrait of Gates that accompanies this article was done by, drumroll...my dad!

In fact, my pops did the illustrations for the entire series. Microsoft Press was one of his favorite clients back in the day. Growing up, he'd tell me stories of disorganized secretaries at Microsoft sending him awful reference photos, so he'd look up the execs in the phonebook and call them at home. Sometimes he'd get their wives/husbands on the phone, and he'd nicely explain that he was an artist, and would they mind if he borrowed the family photo album? Many fine stories from those cases, too.

Somewhat ironically, my dad never learned how to do art on a computer. Now he's a commercial construction inspector in Seattle.

<comment><USER3> Wow, thanks for sharing this! That's an awesome anecdote, and I really like his work.

<comment> Jackson-Solway You're welcome! I talked with my dad last night and he's flabbergasted the book is now online (in blog form, at least). He still has all the original illustrations sitting in a flat file in our garage. We discussed what to do with them, if anything, and I suggested the Computer History Museum might be interested. He liked the idea, so we're going to reach out soon. If anyone knows someone there, please drop a line to jackson.solway at gmail. Thanks!

</comment></comment></comment><comment><USER4> I really liked this quote - "Programmers just starting out today never had to squeeze, so it's a little harder for them to get the right religion because they always think of resources as being immediately available. Ten years ago every programmer ran into resource limitations, so the older programmers are always thinking about those things."

And --

"I still think that one of the finest tests of programming ability is to hand the programmer about 30 pages of code and see how quickly he can read through and understand it."

Does any company run "code comprehension" tests for hiring? Any thoughts?

<comment><USER5> IMO, that quote's garbage and really "back in my day". Our resources are just more powerful today. We still run into performance issues with things like bulk updates and computation times (MapReduce / distributed computing) quite frequently.

<comment><USER6> Ironic language given that most "engineers" today can't write code without dependency on built in garbage collectors.

Do you really think developers these days are just as good at optimizing for limited system resources as they were in 1986?

"We still run into..." Who? Maybe you - but most developers aren't running into map/reduce problems every day. And when they do, they certainly aren't coding a solution from scratch.

<comment><USER7> Maybe these days other metrics are more important to optimize for? Ultimately it is about transforming money (resources) into output (more resources) and depending on times different things bottle-neck you there.

<comment><USER8> optimise for maintainability, reusability, composibility

<comment><USER7> and talent pool availability

</comment></comment></comment></comment></comment></comment><comment><USER9> He answers:

"The hardest part is deciding what the algorithms are, and then simplifying them as much as you can. It's difficult to get things down to their simplest forms. You have to simulate in your mind how the program's going to work, and you have to have a complete grasp of how the various pieces of the program work together. The finest pieces of software are those where one individual has a complete sense of exactly how the program works. To have that, you have to really love the program and concentrate on keeping it simple, to an incredible degree."

This line alone demonstrates he was a good coder.

<comment><USER10> Paul Allen has said that Bill's particular gift when it came to programming was the ability to find the way to get to the needed outcome in the absolute fewest lines of code necessary.

<comment><USER11> Sometimes that approach is good. And then sometimes, after a decade of misuse, it just leads to a nightmare of a codebase.

<comment><USER12> Yet, being first to the market has ensured he made billions.

The definition of 'useful' and 'beautiful' varies based on circumstances.

</comment></comment></comment></comment><comment><USER13> OK, so Bill had really modern thinking. I mean if you apply what he said to modern software design, it still stands mostly true.

So here's a question - given his understanding of team management, product design etc, how the hell did Microsoft go so wrong and end up today with constantly-rebranded products that does not appear to have one unified direction, but rather feel like it's been split to a billion different directions?

Did teams in MS get bigger? He did mention that it was important that in a team there were a few people that truly and fully understand the codebase. I wonder if that is even possible in any of MS products nowadays

Edit:

Some really great choice quotes:

>I like to think the whole program through at a design level before I sit down and write any of the code. And once I write the code, I like to go back and rewrite it entirely one time.The most important part of writing a program is designing the data structures. The second most important part is breaking the various code pieces down. Until you really get in there and write it out, you don't have the keenest sense of what the common subroutines should be. The really great programs I've written have all been ones that I have thought about for a huge amount of time before I ever wrote them

Bill is One of Us! I don't think I've ever read about him hacking before

> That refers to a program that molds itself to the user's needs and the > user's interests over time. There are going to be more great word processors > and spreadsheets, and we'll use networking and graphics and new > architectures

> Programmers just starting out today never had to squeeze, so it's a little > harder for them to get the right religion because they always think of > resources as being immediately available. Ten years ago every programmer ran > into resource limitations, so the older programmers are always thinking > about those things.

I think we're still saying that today.

The interview was done in 1986, and he was talking about CDROMs which took off roughly 8 to 10 years after this interview (end of 3.1 and beginning of win95). They really did pursue the multimedia strategy well

<comment><USER14> _I don 't think I've ever read about him hacking before_

Oh, you didn't hear about that time he implemented BASIC in 4k? [http://www.theregister.co.uk/2001/05/15/could_bill_gates_wri...](http://www.theregister.co.uk/2001/05/15/could_bill_gates_write_code/)

<comment><USER13> Oh, I'm familiar with that. I'm also familiar with the pancake flip algos.

What I've never read about before was his attitude to hacking

</comment></comment></comment><comment><USER15> This would be six years after he attempted to negotiate a three-way split of the computer marketplace with IBM and Intel (who refused his proposal):

 _In the autumn of 1980, Bill 's unfamiliarity with his new purchase [of QDOS] didn't stop him proposing, in a story told by Stanford's John Wharton who was Intel's second point man for negotiations, a three way carve up of the market between IBM, Intel and Microsoft - then a company with 30 employees. If historians are to conclude that Bill "thought big", they'll be correct - <USER2> they may also conclude that he didn't always "think legally". Market carve ups are a violation of antitrust laws._

[http://www.theregister.co.uk/2006/06/17/saint_bill/](http://www.theregister.co.uk/2006/06/17/saint_bill/)

That said: Gates's comment that core programming teams are generally 4-5 devs suggests a pretty strong constant through the industry. It's rare for any specific module to grow much beyond that -- where you _do_ see more people working on a particular piece of code, it's typically either highly modularized (and module contributors are working on sub-pieces), or the architecture is already highly refined, and the process is largely one of providing bugfixes or additional features to an established base.

<comment><USER10> Market carve-ups are not an inherent violation of anti-trust laws. Neither are possessing monopolies. Two extremely commonly held and mistaken beliefs.

Allow me to properly word it: market carve-ups, that cause consumer harm, and that the government chooses to prosecute and in which the government manages to prove consumer harm - are a violation of anti-trust laws.

If three companies carve up a market, benefit consumers, and the government chooses not to pursue - that is not a violation of anti-trust laws in any way shape or form. To make this point clearly, if the DOJ chose not to pursue Apple with anti-trust law regarding the ebook situation, what Apple did would not be considered a violation of anti-trust laws. Anti-trust laws are inherently very subjective, they're up to heavy interpretation on the government's side (and then further, what the government can demonstrate when it comes to harm).

<comment><USER16> This wasn't even a market carve-up. It was a proposal for IBM to single-source from Intel and Microsoft. That's perfectly legal for a new product that's starting out with 0% market share.

It was legal for Microsoft to single-source the CPU for the Surface from Nvidia. And it would have been similarly legal for IBM to single-source the OS for the PC from Microsoft.

What's more, Microsoft had 0% share of the OS market -- thus, no market power. And it had already agreed to produce BASIC for the IBM PC -- thus, no tying. _Ipso facto_ , Microsoft could not possibly have been guilty of an antitrust violation in 1980 for offering to single-source DOS to IBM.

Only the Register could come up with such an illogical conclusion like that. But then, the Register is so virulently anti-Microsoft that they could probably criticize Altair BASIC on antitrust grounds.

<comment><USER15> _This wasn 't even a market carve-up._

Having heard Wharton's story directly from him, I can assure you that was being proposed as told by Wharton was in fact a three-way market carve-up.

• IBM would get business.

• Intel would get embedded devices (Wharton's own work was largely on an embedded controller that's used in automobiles, more units of it have been created than there are humans on Earth).

• Microsoft would get the hobbyist market ("home computing").

Your ad hominem on The Register (El Rag as I like to call it) doesn't address the fact that the source of the story is in fact John Wharton, and he has IIRC publicly discussed it elsewhere. I've got my own beefs with the Register (its irrational opposition to anthropogenic global warming comes to mind). And while long critical of Microsoft, that stance seems to have softened markedly in recent years. The stance of the site is pretty aggressively confrontational -- it's not "biting the hand that feeds IT" for nothing.

<comment><USER16> That's an interesting anecdote. But that still isn't an antitrust violation.

You need market power in order to restrain trade. Otherwise, you're just fantasizing about seizing control of a market without actually having the power to do so. For example, if you and I get together and divided the smartphone market 50/50 between the two of us, that would simply be laughable, not anti-competitive.

But if you do have market power, then your actions could actually be anti- competitive. If IBM had reached an agreement with, say, DEC to split the mainframe and minicomputer market between them, then that would have been an "unreasonable restraint of trade."

But Microsoft held 0% of the operating system market in 1980. In fact, in 1980, Microsoft had market power only in BASIC interpreters. As long as Microsoft didn't try to tie BASIC interpreters to some other product, it would've been very hard for Microsoft to violate antitrust law, even if it tried.

> _Your ad hominem on The Register (El Rag as I like to call it) doesn 't > address the fact that the source of the story is in fact John Wharton, and > he has IIRC publicly discussed it elsewhere._

An _ad hominem_ is when someone claims that an argument is false simply because it originated from a certain source. That's not what I did. I attacked the Register _after_ addressing the argument directly. That's not an _ad hominem_ , that's just an attack on the Register.

P.S. Since the information came from John Wharton, it would be best if we could see what he actually said. Right now, Googling for "John Wharton IBM Microsoft Intel" gives only three relevant hits: two articles in the Register, and your original comment.

<comment><USER15> _You need market power in order to restrain trade._

First off: that's _not_ what the statute says. And again you've failed to provide any documentation for your claims (as adventured has also failed to do).

So I'll leave it there.

As for Wharton's making statements elsewhere: it's my recollection that he had. I haven't looked for them ... and no, don't see anything that's a specific match, though you can certainly place Wharton at Intel and having met with Gates while there.

<comment><USER16> > _First off: that 's not what the statute says. And again you've failed to > provide any documentation for your claims (as adventured has also failed to > do)._

As I've already stated, it doesn't matter what the statute says. It matters what the courts have interpreted. See other thread: [https://news.ycombinator.com/item?id=7188995](https://news.ycombinator.com/item?id=7188995)

As for sources, see any textbook in antitrust law. Or just Google for the words "market power" and "restraint of trade. " These are not controversial concepts in antitrust law. You don't need a citation to say that the sky is blue.

There are such things are _per se_ violations, but the courts have chipped away at this concept. For example, vertical segmentation used to be a _per se_ violation, but today it is subject to the rule of reason.

> _As for Wharton 's making statements elsewhere: it's my recollection that he > had. I haven't looked for them ... and no, don't see anything that's a > specific match, though you can certainly place Wharton at Intel and having > met with Gates while there._

It's certainly ironic that you don't provide a citation for this, when you're so aggressive about demanding citations from other people.

</comment></comment></comment></comment></comment></comment></comment><comment><USER17> > You have to simulate in your mind how the program's going to work, and you > have to have a complete grasp of how the various pieces of the program work > together.

> You've got to have somebody who's super smart. A great programmer thinks > about the program on a constant basis, whether driving or eating. That > method takes an incredible amount of mental energy.

> Before I sit down to code something, most of the instructions have already > run through my head.

> Programming takes an incredible amount of energy, so most programmers are > fairly young.

It may be a bit anachronistic to look at statements like these in the light of subsequent revolutions in software development such as XP and Agile. But I can't help thinking as I read this that he's doing it wrong. All the talk about using lots of mental energy to "have a complete grasp" of the program is fairly useless when faced with ever increasing complexity and code base size. Test Driven Development and clean code organization goes a long way towards breaking large problems down into easier to manager parts.

<comment><USER18> > Programs today get very fat; the enhancements tend to slow the program down > because people put in special checks. When they want to add some feature, > they'll just stick in these checks without thinking about how they might > slow the thing down. You have to have a programmer who knows the program > inside out to guard against that.

This one struck me. Today the public methods of a class would check to make sure the inputs are valid. Back then the programmer would just know the location of every single caller and make sure the calls are always valid in the first place.

It's clear that the modern approach is a winner, especially with enterprise- size codebases, and _really_ especially when developers churn every few years and nobody is around from when the code was originally written.

And of course Amazon is the ultimate success story of taking this idea to the extreme with a completely service-oriented architecture. Coding super defensively to minimal interfaces has been proven to work.

<comment><USER19> Keep in mind that Bill was talking about programming in assembly language for extremely resource-constrained systems there. Even today, if you're trying to write an extremely small/fast program/inner loop in assembly, you had better be relying on "dangerous assumptions" like that, or else the result is going to be worse than what a compiler could do.

<comment><USER20> Ideally you want your type system to enforce as many of these assumptions as possible since when it can you both speed and safety.

</comment></comment></comment></comment><comment><USER21> "INTERVIEWER:: Where do you see Microsoft in ten years?

GATES: Our goals are very simple. We're going to create the software that puts a computer on every desk and in every home. I don't know if that'll take ten years–that's not my expertise, guessing those exact time frames. Microsoft also wants to participate in helping to make sure those machines are good machines, building the system software into them, and then doing a lot of the important applications they'll use."

<comment><USER22> This leads into a section that I find interesting, where he envisions every useful application on computers having to do with CD-ROMs and their vast storage space.

He doesn't mention anything at all about networking, which is a very true to the story of how the last 10 years of his tenure as a chief at Microsoft turned out.

Microsoft succeeded in what he stated, creating software for computers that almost every home used, indeed with software on CD-ROM. However, the applications he envisioned - catalogs, phone books, maps - actually turned out run on the Internet, not local storage. The attempts to distribute things like catalogs on CD-ROM turned out to be cumbersome and expensive, and too difficult to keep updated. He mentions the vast storage space of CDs, but the effective storage space of a computer connected to the Internet dwarfs the capabilities of any local storage.

<comment><USER23> > He doesn't mention anything at all about networking ...

It was a blind spot for Gates and Microsoft in the 1980s. He wasn't alone, of course. People like Marshall McCluhan had laid out a vision for it years before but Gates was really focused on software for devices and not the network. It wasn't until the late 1980s that Microsoft turned its attention to Novell which was making a killing in PC networking. (Gates recruited Jim Allchin from network company Banyan in 1990.) By the mid-1990s there wasn't much left of Novell, but Microsoft's interest and strategy there was purely driven by business and not vision. That was clear when they were clobbered again by the Internet.

</comment></comment></comment><comment><USER24> "INTERVIEWER: Does accumulating experience through the years necessarily make programming easier?

GATES: No. I think after the first three or four years, it's pretty cast in concrete whether you're a good programmer or not. After a few years, you may know more about managing large projects and personalities, but after three or four years, it's clear what you're going to be."

Out of curiosity, is there any experienced programmer that would dispute or agree with this statement?

<comment><USER25> He appears to answer a slightly different question to the one that was asked, but I agree with what he said in his answer. To be a really good programmer, you need to have a particular kind of brain, and if you do, you will pick everything up very quickly. If you don't, you will always have a weak grasp of some concepts no matter how much you are taught.

There are university lecturers who agree that it's clear within the first couple of weeks whether someone has the aptitude to study CS. I remember a paper that was talked about a few years ago that described a "double hump" in aptitude, clearly separating the two groups. They wrote a very short test that was a good predictor of success. There's an article on Coding Horror about it: [http://www.codinghorror.com/blog/2006/07/separating- programm...](http://www.codinghorror.com/blog/2006/07/separating-programming- sheep-from-non-programming-goats.html)

<comment><USER26> That is a fascinating paper referred to in the blog post.

I teach introductory chemistry, and for a long time, I've felt that there are students who are just incapable of making relatively simple mental models of the concepts that we discuss. To give an example, there are students who don't have a mental model of what _density_ is.

I imagine that most people here have a good grasp of density and each of us has some mental model where the 'matter' in _dense_ materials is "tightly packed" when compared to less dense materials. This isn't a perfect mental model, but it's reasonably accurate.

The students who don't/can't make these models view the entire course as a collection of arbitrary formulas that make absolutely no sense and require painstaking memorization. As a rule, they do poorly, unless they are exceptionally good at memorizing.

<comment><USER27> _I 've felt that there are students who are just incapable of making relatively simple mental models of the concepts that we discuss._

Just because this _seems_ to be the case, I would only ask that you don't let this become a limiting belief that you project on your "incapable" students.

I only say so because I know I've taken various courses over the years (HS or college) where that sort of analogous big-picture communication you're talking about didn't really click for a few months or even years. When one is overwhelmed - or at least feeling overwhelmed - with the volume of new fundamental concepts to be grasped, it's akin to having 1,000 jigsaw pieces dumped on your coffee table. Oh and by the way, we're going to apply time pressure and grade you on your ability to figure out the big picture.

In that case, learning can turn into a fear-based "tread water because I'm drowning" activity where rote memorization is the fallback tool to get the learner to shore alive. The outcome is no longer the joy of understanding and meditating on those analogies/models to get the fundamentals to click, but trying to avoid death (err, a failing grade).

It wasn't until I revisited those certain topics later without the time- sensitive pressure of exams/grades that the broader models for understanding would "click" and all those rotely memorized fundamentals would fall into place - which is an indescribable joy.

So while your incapable students may not seem to grasp the big picture now, it's likely you are still making a difference by implanting those fundamentals which will snap together later on in life.

<comment><USER26> You make a fair point and my generalization was certainly too sweeping.

One of the things that I tell my students is that sometimes, if they stick around long enough, things will make sense.

That being said, I'm still at a loss on how to _help_ the students who aren't making mental models that (to me) seem relatively fundamental. I try to use visuals and videos when applicable and when possible, but I would use other approaches if I could think of something that would be helpful.

Finally, I think/speculate there is a continuum of skill with mental model building. When I was a postdoc, I worked with people who had deep mental models of statistical mechanics that I just didn't have. So...I know what it feels like, but I don't know how to fix it.

</comment></comment></comment></comment></comment><comment><USER28> "There's a lot of talk about how large software companies find it difficult to attract talented people who can produce great software, because these mavericks are so independent that they want to work on their own. "

Still appropriate today!

</comment><comment><USER29> "We're no longer in the days where every program is super well crafted. But at the heart of the programs that make it to the top, you'll find that the key internal code was done by a few people who really knew what they were doing."

</comment><comment><USER30> "You're seeing a lot more cases where people can afford to use C, instead of using assembly language"

God bless Intel Core i7 CPUs that allow me to use JIT'd, GC'd languages without a second thought.

</comment><comment><USER31> My favorite quote: "the best way to prepare is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."

</comment><comment><USER32> > The old rule used to be that a manager of a programmer was always a better > programmer, and there were no what we called "technical inversions," where a > programmer works for somebody who doesn't know how to program. We still > follow that philosophy: At certain levels we've got business managers, but > we don't have non-programmers really managing programming projects.

Holy shit this is amazing

</comment><comment><USER33> Really wonder what others think about this line: "INTERVIEWER: What do you consider the most difficult part of computer programming? GATES: The hardest part is deciding what the algorithms are, and then simplifying them as much as you can."

<comment><USER25> Everyone knows the two hardest things are cache invalidation, naming things and off-by-one errors.

</comment></comment><comment><USER34> Does anyone know of any other Bill Gates interviews of this quality from, say, 1996? I suspect that one doesn't exist, but I'd love to hear what sort of lessons he learned from ten more years of running Microsoft as the company got larger and he moved "up the stack".

It's clear, though, he still paid attention to details:

1991: Product review for Excel Visual Basic - [http://www.joelonsoftware.com/items/2006/06/16.html](http://www.joelonsoftware.com/items/2006/06/16.html)

2003: Critique of Windows usability - [http://blog.seattlepi.com/microsoft/2008/06/24/full-text- an-...](http://blog.seattlepi.com/microsoft/2008/06/24/full-text-an-epic-bill- gates-e-mail-rant/) (the article emphasises the drama, calling it an "epic rant" and shows how Gates "isn't immune to the frustrations of everyday computer users", but that's just some journalism bullshit. What's more interesting is that he still has a wicked attention to detail, and you still see that he's the same person that gave the interview in the original post.)

<comment><USER16> > _What 's more interesting is that he still has a wicked attention to detail, > and you still see that he's the same person that gave the interview in the > original post.)_

I remember seeing this memo back when it originally came out. If I recall correctly, the problem was not actually fixed after Bill Gates complained about it. The replies to his email just pointed fingers at each other.

Thus, all the talk of Microsoft needing a Steve Jobs are off the mark. Microsoft already had a Steve Jobs -- he was named Bill Gates. For whatever reason, even he couldn't polish out the flaws. There's something in the culture of the organization that prevents attention to fit-and-finish.

For example: Bill Gates complains about the C:\Documents and Settings\billg\My Documents\My Pictures folder. This was in 2003. OK, so it got fixed in Vista. But why couldn't he get this fixed for XP? I doubt he was happy with it when he ran the XP betas.

My pet peeve: Explorer gives an uninformative "Try Again" dialog when I try to delete an open file. Why doesn't it tell me which program is holding the lock? Microsoft bought Sysinternals eight years ago! They just need to integrate the code from the _handles_ utility, and add a "Switch to" or "End task" button to make it easier to close the program.

<comment><USER34> Agreed, but to become as good a consumer company as Apple, Microsoft would have needed a Steve Jobs (someone more dedicated to focus and aesthetics of form and function). It's not clear Gates wanted to be the same sort of consumer company. I'm sure he'd have taken it if he could've gotten it, but probably not at the expense of sales of site licenses to businesses.

Thanks for the pointer to _handle_! I've got the sysinternals suite but never bothered to explore much beyond Process Monitor.

<comment><USER16> > _Thanks for the pointer to handle!_

You're welcome, it's a useful tool when you just can't seem to delete a file. Although you're right -- it's called _handle_ (singular), not _handles_ (plural).

Actually, I think I do this all the time. I type _handles_ , get an error message, and then think, "Maybe it's just _handle_." After all, multiple programs can have a file open at the same time, and the _handle_ utility can actually list more than one program. So why isn't the name of the utility plural?!

Yet another fit-and-finish issue in a Microsoft product ...

<comment><USER34> Oh, for what it's worth, I italicised the name because it's a work, and I guess I do that for programs in addition to books, not to point out a correct spelling. Pointing out spelling mistakes and grammar errors on the internet seems needlessly rude. :)

</comment></comment></comment></comment></comment><comment><USER35> "In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."

</comment><comment><USER36> "one of those people has to have the proven ability to really absorb a program. And when that lead person is uncertain about something, he or she should be able discuss it with even more experienced programmers."

I've always thought as the lead, you're supposed to be the most experienced programmer.

<comment> UK-AL If experience was correlated with skills, maybe.

</comment></comment><comment><USER37> Interesting.

"...our present thinking is that we won't have to increase the size of our development groups, because we'll simply be making programs that sell in larger quantities. We can get a very large amount of software revenue and still keep the company not dramatically larger than what we have today."

<comment><USER38> And to think what Microsoft does today, with only 160 programmers and 100,722 salesmen.

Of course, 640k... I kid BillG.

<comment><USER38> This crowd either lacks a sense of humor or any tolerance of bad jokes. Or both.

</comment></comment></comment><comment><USER39> Very interesting historical anecdotes.

The following shows his move to management: _No, I don't. I still help design algorithms and basic approaches, and sometimes I look at code. But since I worked on the IBM PC BASIC and the Model 100, I haven't had a chance to actually create a program myself._

The following shows pre-agile thinking on development: _I like to think the whole program through at a design level before I sit down and write any of the code. And once I write the code, I like to go back and rewrite it entirely one time.The most important part of writing a program is designing the data structures. The second most important part is breaking the various code pieces down. Until you really get in there and write it out, you don't have the keenest sense of what the common subroutines should be. The really great programs I've written have all been ones that I have thought about for a huge amount of time before I ever wrote them. I wrote a BASIC interpreter for a minicomputer in high school. I made massive mistakes in that program, and then I got to look at some other BASIC interpreters. So by the time I sat down to do Microsoft BASIC in 1975, it wasn't a question of whether I could write the program, but rather a question of whether I could squeeze it into 4K and make it super fast. I was on edge the whole time thinking, "Will this thing be fast enough? Will somebody come along and do it faster?"_

It was a very different time!

<comment><USER40> > The following shows pre-agile thinking on development

Oh come on! When he says that "until you really get there and write it out..." shows a lot of agile thinking. Agile does not in any way exclude design before writing code! He also talks about rewriting (refactoring).

It wasn't that different of a time!

</comment></comment><comment><USER41> What struck me was the way in which Microsoft's coding hammer was so sophisticated that it viewed the design issue of accessing vast amounts of information by ordinary people as primarily a software problem (the interactive CD Rom) rather than a bandwidth problem. Though in fairness nobody was betting on the creation of the commercial internet at the time of the interview.

Gates and Microsoft saw the future and placed an early bet- much as they did with embedded and mobile Windows in the 1990's. In both cases, their timely early solution was made obsolescent when communication infrastructure scaled and bandwidth further commodified first over wire then over wireless.

In the first case, Microsoft underestimated their success. Computers in every home made providing cheap bandwidth profitable. With wireless, they simply had more than a decade of designs intended to minimize bandwidth consumption rather than actively encourage it. The idea of selling information about their customers [and Microsoft has always viewed users as customers rather than consumers though that could change] just wasn't consistent with their pre- goolified internet age ethics.

</comment><comment><USER42> Since we are all adding quotes I'd like to add this one...

"No great programmer is sitting there saying, "I'm going to make a bunch of money," or, "I'm going to sell a hundred thousand copies." Because that kind of thought gives you no guidance about the problems."

Amen brother.

Too many times, especially here on HN, developers create something to make the big bucks. Usually they find little shortcuts for the things they want. The final product ends up sacrificing the mission as well as the quality.

I like the adage wise people give to enthusiastic people who want to "start something".

When starting something, be it a business, learning a skill, etc, make sure you're doing it for you.

Bill, I feel hit that on the head about BASIC. He saw a problem, and worked on it for himself. Others liked it and started using it. Reminds me on David Heinemeier Hansson's talk on why he built Ruby on Rails. It was a means to an end that ended up helping him and others in the process. [http://bigthink.com/users/davidheinemeierhansson](http://bigthink.com/users/davidheinemeierhansson)

</comment><comment><USER43> I've been playing with CP/M recently (on an emulator). It strikes me that Microsoft had a very clear vision at this early stage: it was to port all of the popular (to businesses) large computer languages to micros. Hence we have not only BASIC, but very complete implementations of Fortran and COBOL for 8080/Z-80. I wonder if there is a quote from Bill Gates about this?

</comment><comment><USER44> This is a great, great article. It gives you insight and makes you realize how intelligent he really is. Compared to Steve Jobs, I would bet Gates' IQ is a full 10-15 points higher. However, what Jobs lacked in intelligence he more than made up for with charisma and ability to relate to people. Highly enjoyable read.

</comment><comment><USER45> Nice picture of a young and sprightly looking Bill at the top of the page... looks like it was created on MacPaint.

<comment><USER46> Nice, you just dissed the father of someone in this thread!

[https://news.ycombinator.com/item?id=7187951](https://news.ycombinator.com/item?id=7187951)

<comment><USER45> Wow, much coincidence...

I'll go and hide in the corner while all onlooking HN readers facepalm.

<comment><USER47> I thought the same thing - I think its a limitation of the digitization of the original image.

</comment></comment></comment></comment><comment><USER48> This once again makes it clear that Bill Gates, although incredibly smart and successful, was never a visionary. Notice how he expects an immediate trend towards learning computers, that adapt to the user by learning from their behavior and a set of rules. Although an enticing idea this resulted in Microsoft Bob and probably not much else.

Also remarkable is the absence of any mention of the internet, although it was quite developed and capable already in 1986 - Microsoft famously missed the boat on this until the 'Cornell is wired' memo.

Finally, in every question about how Microsoft decides _what_ to build, he is very vague and hardly ever talks about actual users. We now know that the main methodology employed by Microsoft was to simply rip off existing successful products and bundle them with Windows.

<comment><USER49> > This once again makes it clear that Bill Gates, although incredibly smart > and successful, was never a visionary.

He became successful because he was a visionary.

He saw in 1978 that the future was in software, not in hardware (Apple went the other way and ended up in a hole for two decades because of that mistake). Then he saw the future of licensing software and bootstrapped Microsoft based on it.

Then he saw the importance of operating systems and built the company around it.

Then he saw the importance personal computing with Word and Excel.

You can say a lot of things about Bill Gates but saying he was not a visionary is absurd.

</comment></comment><comment><USER50> Another great interview, from the same time by the guy who created Pac Man: [http://programmersatwork.wordpress.com/toru- iwatani-1986-pac...](http://programmersatwork.wordpress.com/toru- iwatani-1986-pacman-designer/)

</comment><comment><USER51> _INTERVIEWER: What do you consider your greatest achievement ever in programming?_

I thought for sure it was going to be DONKEY.BAS:

[http://www.youtube.com/watch?v=kymzTlqi1SY](http://www.youtube.com/watch?v=kymzTlqi1SY)

</comment><comment><USER52> None of the web developers I've interviewed in the States was able to implement a sorting algorithm of their choice. The one developer who got close to accomplishing this used min() on array_slice() in PHP.

<comment><USER42> That's not to say that all web developers can't do that. I can. Its not that tough.

I do honestly wonder what it is they teach in college. I've took 2 years (on and off) at a Community College and was able to do very well for myself. But, I have seen many "developers" that had impressive 4 year degrees on the resume and couldn't create an algorithm that removed duplicate records from a record set. Lol, some couldn't even tell me what their favorite text editor was ("All of them" ~Palin).

I'm not sure what to tell you, kolev.

For me, it has come to the point where asking trivial questions during interviews just doesn't work. You truly know what a dev can do when a dev develops.

In my shop, we work on classic asp, and asp.net web applications. I'm currently creating a package that will address the common building and troubleshooting scenarios pertaining to those frameworks. If the applicant cannot complete the task to satisfactory, then they don't belong here.

Good developers are out there. But you have to make a decision "Am I willing to pay a premium for them, or see if I can get just get lucky?"

<comment><USER52> When did I say "all"? I shared my personal experience interviewing web developers in Southern California. And, trust me, it's a good sample size as I've interviewed tens over the years! Also, the HN crowd consists of probably the best software engineers in the industry and that's why HN replaced a lot of aggregated blog feeds and the comments are especially valuable! Maybe I should've clarified that my observation certainly does not apply to the members of this community! :)

</comment></comment></comment><comment><USER53> "We're no longer in the days where every program is super well crafted. "

Wow. This statement is epic in the context of Microsoft today. Seems like everything they put out is feature rich but overly complicated.

</comment><comment><USER54> I didn't realize that he had stopped personally programming so early.

<comment><USER55> I think that is part of the price you pay when company you launched turns so successful. I doubt Zuckerberg codes either.

<comment><USER56> Yes, imagine if you code part of a product, your company makes three branches and in the middle of the deadline to release a new version they call you to fix some bugs and merge the code into the branches.

</comment></comment></comment><comment><USER57> INTERVIEWER: Where do the ideas for programs come from?

GATES: Well, there's no formal process, that's for sure. At Microsoft, there's usually a brainstorming session at night or on the weekends. Everybody has a general idea, like, we want to do the world's best word processor. ....

=> Well now, we have found a better way and companies are internally finding great ideas by doing hackathons!

</comment><comment><USER58> For my money the more interesting 1986 PAW interview is linked on the sidebar, the one with Jaron Lanier, who I remember interviewing around then. Not a lot about the real work of programming, which Gates talks about like the automaton we know he was at that time, but many many insightful ideas about what programming means.

</comment><comment><USER59> "I thought we could save a few bytes and tighten things up. We just tuned the program very, very carefully, and ended up with a 4K BASIC interpreter. When you know a program that well, you feel that nobody can look at the code and say, "There's a better way to do this." That feeling's really nice"

so sad: from that to... Windows

</comment><comment><USER60> Somewhat related - I highly recommend checking out the books Coders at Work and Founders at Work.

</comment><comment><USER61> "One way is to have small project teams, typically four or five people, and one of those people has to have the proven ability to really absorb a program.."

Genesis of the Program Manager @MS? I didn't think it was that old!

</comment><comment><USER62> Wonder if anyone has access to those texts from John Norton he refers to?

</comment><comment><USER63> I love this quote: "You're seeing a lot more cases where people can afford to use C, instead of using assembly language.". Yes. Definitely 1986.

</comment><comment><USER64> I stoppped reading when I got to this:

"If you're a great programmer, you make all the routines depend on each other, so little mistakes can really hurt you."

I know things were different back then, and Bill did not have the luxury of building on the wisdom learned over decades of experience, but 'separation of concerns' and 'loose coupling' have been central to every design decision I've made. It's hard to conceive of how one would believe that a tightly coupled, brittle design was a good one.

<comment><USER65> In assembly language, a sub-procedure can save the state of all the registers it will use before using them and then set the state back when it is done (push register values on the stack, do work using those registers, and then pop the state back). This is the safe thing to do, but it wasn't the best way to write code back then. People would use unsafe procedures instead to reduce code size. With that said, I think Bill was talking about the fact that if the program doesn't repeat itself (by using procedures to abstract common idioms), then a mistake would be amplified since it would cause problems for all call sites.

<comment><USER64> Yeah, I could see interpreting this quote that way. However, if taken literally it implies a very intertwined world. It's probably not fair to to dissect this so much, however.

<comment><USER66> It was a different time. Intertwining your world made sense if it could squeeze a BASIC interpreter into 4k. Now my laptop has 8000000k of memory.

</comment></comment></comment></comment><comment><USER67> "You're seeing a lot more cases where people can afford to use C, instead of using assembly language."

</comment><comment><USER68> GATES: "... We knew what programmers wanted, because we're programmers. So we wrote BASIC."

Nuff said.

</comment><comment><USER69> So quaint, talking about "programs" instead of "applications".

</comment><comment><USER70> "The PDP operating system."

Unix?

<comment><USER71> I'm pretty sure he's talking RSX11, VMS, and VAXELN. I believe when Gates says "Everybody who wrote the PDP operating system influenced me" the everybody he's talking about is Dave Cutler and friends.

You know, the people he hired to write Windows NT.

</comment></comment><comment><USER72> Thanks Bill Gates for saying what I always thought...

"choose features to put into programs. To do that, you have to have a reasonable understanding of what's easy and what's not easy to do."

For those Product/UX/Tone Goons who can't actually build....

Also this gem

"and there were no what we called "technical inversions," where a programmer works for somebody who doesn't know how to program. "

"We still follow that philosophy: At certain levels we've got business managers, but we don't have non-programmers really managing programming projects."

Bill knew it back in 86... we still do shit like that.

<comment><USER73> Today at Microsoft, not many managers actively write code. They had been doing it "back in the days" but not any more. Many don't even have Visual Studio installed in their primary work machine. I've seen tons working off of Surface with their only actively used apps being browser and Outlook. In fact, as higher up you go you are less likely to find anyone who has written any code in any reasonable period like past 2 years. It is not uncommon for a developer who is starting to feel that it's hard to keep up with coding asking for a management position aggressively. I would wager that more than 70% of the managers are ex-developers who no longer wants to deal with complexity or responsibility of writing code.

<comment><USER74> I don't think by "non-programmers" he meant "people who don't actively program".

I think he meant "people that don't even know how to program".

In this article bill gates says in the first line that he no longer writes code. But clearly he would not classify as a "non-programmer".

Today's managers can still provide valuable input (e.g. algorithm design - like Gates did when this article was written) even if they don't code day to day.

I'm a program manager at Microsoft so I don't actually write code. That said, I majored in CS and know my stuff pretty well. I don't consider myself a "non- programmer". That said, I try and increase my credibility among "my" devs by doing projects outside of work. This also helps me keep up with the times.

</comment></comment></comment><comment><USER75> Great post! It's lengthy but I had a great time reading! Thanks for sharing!

<comment><USER35> This interview is part of a really great book. The site probably has all the interviews.

[https://www.goodreads.com/book/show/2092682.Programmers_at_W...](https://www.goodreads.com/book/show/2092682.Programmers_at_Work)

<comment><USER76> Would you know/recommend any books from the early Microsoft era? I enjoyed Masters of Doom and would love to know if there is anything which goes into that much detail of the early days of Microsoft, actually any company would be interesting.

<comment><USER77> Three I'm familiar with, all recommended:

'Gates', Stephen Manes [1]

'Show Stopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft', G.P. Zachary [2]

'Microsoft in the Mirror', Karin Carter [3]

But I agree with the parent that 'Programmers At Work' is a great book.

[1] [http://www.amazon.com/Gates-Microsofts-Reinvented- Industry-H...](http://www.amazon.com/Gates-Microsofts-Reinvented-Industry- Himself/dp/0671880748)

[2] [http://www.amazon.com/Show-Stopper-Breakneck-Generation- Micr...](http://www.amazon.com/Show-Stopper-Breakneck-Generation- Microsoft/dp/0029356717)

[3] [http://www.amazon.com/Microsoft-Mirror-Nineteen-Insiders- Exp...](http://www.amazon.com/Microsoft-Mirror-Nineteen-Insiders- Experience/dp/097252990X)

<comment><USER76> Thank you very much, I'll have a look at those 3. Completely agree about the parent book, it does seem very interesting. Although potentially only available in the UK as an import.</comment></comment></comment></comment></comment>


Ask HN: Can you approximate the ratio of content that was posted by paid users? - <AUTHOR> On reddit, for example. <comment><USER2> This probably isn't what you're after but the idea is out there for this sort of thing:

[https://www.fakespot.com/](https://www.fakespot.com/)</comment>


Help me become a web developer, 10,000 ft. in the air - <AUTHOR>

I graduated with an electrical engineering degree and am familiar with programming (C/C++, VHDL, Assembly, etc). But now, I want to start developing web apps.
I am a Management Consultant and spend 15 to 20 hours a week on a plane. So as a personal challenge, if I spend 60 hours a month for 6 months learning and implementing, I should be able to have my ideas turn into funcitoning apps.
Since I don't have an internet connetion, online resources and communities to help me learn are impossible to leverage until I make it to a hotel. At this point, I don't know where to begin in terms of both language and resources.
I've come here to Hacker News to request your advice in helping me complete my personal challenge. I'd love to have a web app up and running this year. <comment><USER2> The key thing that I've found drives me and makes me finish coding projects is if I'm building something that I use a lot, preferably everyday.

Don't waste another minute on choosing the tools - just pick one of Ruby on Rails or Python+Django based on whatever you've heard about them already. The docs are downloadable so you can use them offline.

Could you build something that you would use for your work? You probably use Excel a lot. Is there some manual copy-pasting you spend a lot of time doing in Excel? You could probably automate that.

Edit: As soon as you start working on it, put it on here - <http://swym.me>. I will make sure you get it done.

<comment><AUTHOR> Thanks for the suggestion! I'm not entirely sure about the learning curve of either but I will definitely look into both sometime this week and pick a language to stick with.

Great advice on picking a project. I had a few in mind but you reminded me of some Excel macros I'd like to make.

"I will make sure you get it done" - And this is why I love this community.I'll make a list and definitely check out swym.me when I've made a decision on what I want to start with.

<comment><USER3> Doing is the best learning - why not join a project like mine that needs a web developer? You learn and get to share in our project, and in 6 months if you want to go off to do your own thing you will have gotten real world experience out of the deal. I spend a lot of time on planes as well, and actually the lack of distractions makes it a fantastic place to work. Ping me if you are interested - jeff -at- notifika.com.

<comment><AUTHOR> Thank you for the offer. I completely agree that "doing is the best learning". At this point I can't commit or take on responsibility on someone else's project. If you have a web developer already and that has the patience to work with me, I might just change my mind. But at this point, I'm looking for more flexibility to work on my own ideas.</comment></comment></comment></comment>


TheThings.biz - the anti-LinkedIn for disconnected job seekers - <AUTHOR> http://www.theThings.biz

<comment><AUTHOR> If anyone is tired of "prior experience required" for entry-level jobs and is finding no love on LinkedIn or traditional job boards, we want to help. We'll help you discover, attest to and market the transferable skills you've proven in jobs, education, and volunteering to help you start a more fulfilling career.</comment>


Are statecharts the next big UI paradigm? - <AUTHOR> https://www.slideshare.net/lmatteis/are-statecharts-the-next-big-ui-paradigm <comment><USER3> My experience suggests no, because of two things:

1) Your user interface probably has more edge cases than you or your designer anticipated, and IME the most efficient, understandable way to deal with these is in as-simple-as-possible plain-old-code if/else business logic. The further away you keep code like that from anything "frameworky" the less likely you are to regret it as tech debt.

2) Many of your state transitions probably share similar helper logic. So you want to break that stuff out into its own non-state-based organization anyway to avoid copypasta, and at that point, similar to the above, representing different use cases as linear code as much as possible is a low-cognitive- overhead way to organize your biz logic. That is to say: I think your "states" should be big and chunky - occasionally one feature's flow will transition you into a different feature, but whenever I've tried to push that model down to the individual screens and buttons level, it's caused self-induced pain.

If I had to reduce it to a soundbite, I'd say: your business logic is likely to be inherently complex. Don't intermix that complexity with the technical complexity of your application framework if you can at all avoid it.

(Where this KISS approach goes wrong in practice is you don't have enough team discipline about organizing your biz logic code, or you try to share the wrong things/too early, and some biz logic ends up in every layer of the UI, and you get lots of big pull requests touching lots of files with hot spot files frequently having merge conflicts.)

<comment><AUTHOR> I'm confused because statecharts don't describe business logic - you might be confusing them with flowcharts which are inherently very different: there's no concept of state in flowcharts.

> the most efficient, understandable way to deal with these is in as-simple- > as-possible plain-old-code if/else business logic. The further away you keep > code like that from anything "frameworky" the less likely you are to regret > it as tech debt.

A statechart is simply a JSON structure. You still have to write the code for the figuring out what to do given the current state, and also code for triggering events. So it's still up to you to keep them away from anything frameworky.

> representing different use cases as linear code as much as possible is a > low-cognitive-overhead way to organize your biz logic.

Again, you'd still write linear code with statechart.

> your business logic is likely to be inherently complex. Don't intermix that > complexity with the technical complexity of your application framework if > you can at all avoid it.

With statecharts your business logic is anywhere you want it to be. Statecharts add the idea of limiting you of calling _only_ procedures that are allowed by the current state; meaning that if you are in state "Submitting form" and you call a `goToHomePage()` transition, nothing will happen if there's no such outgoing arrow.

This concept of "changing state only if the current state allows it" is quite powerful especially in the construction of UIs.

<comment><USER4> Good catch. You're right. The author confused flow charts with state charts.

</comment></comment></comment><comment><USER5> Visualization is a powerful mental technique, but visual aids can only really represent a few dozen things before they become as complicated as the thing you were trying to understand in the first place.

And when analyzing messy state diagrams, it's not just the states we're trying to visualize, but the lines connecting the states (the "edges" connecting the "nodes," in graph-theory terms). We can only visualize a few dozen of those, and that typically means we can visualize only a handful of states at a time.

It looks great in a slide deck, but it only works in trivial examples where you don't need it; it fails in complex environments where you need it the most.

<comment><AUTHOR> I disagree especially because statecharts solve this with hierarchical states. You draw and think about a substate on its own, without all the higher-level complexity. Then once ready you can include it in any subsequent layer - <USER2> it's composable and reusable.

Take a look at the "unclustering" section of the statecharts paper.

<comment><USER6> Once you get into the realm of drawing lines, grouping things, and imagining flows you're programming. That it's graphical makes no difference.

I've tried this approach before: the charts get complex fast, then your designers give up.

<comment><USER7> Probably would work better if the visualization is automatically derived from the code, so that it's a guide but it doesn't get in the way.

<comment><USER8> Yes. I can this a self describing system. When the code or config can be used to generate reference materials, at run time or build time, to make understanding the system easier.

Typically you don't need to refere to these diagrams and outputs very often, but they are useful for: \- on boarding new people to the team \- deep reasoning when debugging or analysing a problem \- putting on the board during a design session

</comment></comment></comment></comment></comment><comment><USER9> State is typically multidimensional, so being "in" some state implies a whole lot of context (a whole lot of variables), and most real-world situations are so loaded with context that the only unambiguous way of determining which real-world variables are represented within your program is reading the code (or inversely, any unambiguous definition of which real-world variables are relevant to your program may as well be code). This limits the value of statecharts IMO. I think a more useful solution is something that describes how each level of state is derived from the previous level.

<comment><AUTHOR> Of course to understand how things are implemented you'll have to read the code. With statecharts at least you have a visual bird's-eye view of the behavior of your UI. This is important because otherwise you'll be lost with just code to figure out how things behave.

More importantly, statecharts limit your behavior - a specific state can only go into another state if there's an outgoing arrow. This limitation is quite awesome because, given any state, you know that the only thing effecting change are the transitions - nothing else!

Also I want to stress the importance of the unclustering property described in the paper. Your high-level statechart can be a simple diagram. Then you can "zoom in" and see the behavior of other portions of the diagram. This is quite powerful abstraction and I don't see how "just code" can solve this - especially because we're inherently visual creatures.

<comment><USER9> I'm definitely not arguing against the statechart being higher-level than a pile of state mutations. I think they're very low-resolution however, and I believe there can exist code that can serve the same high-level purpose as statecharts without discarding as much information.

I also think zoom is a very powerful visual metaphor for context, and I don't mean to discount the value of that. I just think the contents of each node in the zoom-context graph could be higher-fidelity.

> More importantly, statecharts limit your behavior - a specific state can > only go into another state if there's an outgoing arrow. This limitation is > quite awesome because, given any state, you know that the only thing > effecting change are the transitions - nothing else!

This touches on a point that I think is important and would like to expound upon.

One thing that makes code easier to reason about is "locality", being able to see everything that affects what you're looking at.

One way of dealing with poor locality in code is to zoom out until you're only looking at a web of state transitions, and then you can find the state you're in and see where you could have come from (which offers _hints_ as to how you got there) and where you could go (which offers _hints_ as to what might happen next).

Another approach is to write high-locality code, code which describes the incoming arrows so that by design, whatever you're looking at is already revealing its composition, and fractally-organized at that. That can be hard to do in application code with existing tools, although (shameless plug) I wrote libraries to help make it easier in Clojure and Javascript: [https://github.com/notduncansmith/factfold](https://github.com/notduncansmith/factfold)

</comment></comment></comment><comment><USER10> The Qt makers seem on the same page. Qt has support for SCXML [1][2], which is an XML format to represent statecharts FSM. You can edit SCXML files from Qt Creator [3], load them in your app and use them to drive your Qt GUI, or any dynamic behavior in your app.

[1] [https://en.wikipedia.org/wiki/SCXML](https://en.wikipedia.org/wiki/SCXML) [2] [https://doc.qt.io/qt-5/qtscxml- overview.html](https://doc.qt.io/qt-5/qtscxml-overview.html) [3] [https://doc.qt.io/qtcreator/creator- scxml.html](https://doc.qt.io/qtcreator/creator-scxml.html)

</comment><comment><USER11> From prior experience working with non-UI statecharts:

1) State transitions are essentially "goto". Structured programming offers abstractions that are easier to think about and less fragile to requirement change. But in some situations small state machines can be a win.

2) Statecharts offer "structure" in the form of substates and superstates which are much like inheritance in OOP. In my experience these are fragile to requirement change.

3) Statecharts are advertised as being explicit and therefore easier to check for correctness. They can be, although if there are multiple state machines operating concurrently or even an "outside world" acting on them, the set of possible states is no longer explicit.

</comment><comment><USER12> It is a neat idea to separate the semantics and the syntax. However, for some reason, it didn't get enough popularity.

Apache Commons has an SCXML package which parses scxml statechart format (standard) and produces dynamic java objects but this couldn't see the daylight and suspended at version 0.9 in 2015.

I had nice experiences with this separation logic though. It is more flexible and extendable than regular finite state machines. There is parallelism and timeouts built-in the standard and as mentioned in the presentation, it solves a lot of if-else kinda structure without a hassle.

</comment><comment><USER13> The syntax reminds me of Adobe's Adam GUI specification language. Jaakko Järvi has continued this work: [https://github.com/HotDrink/hotdrink/blob/master/README.md](https://github.com/HotDrink/hotdrink/blob/master/README.md)

It's honestly a better way to implement GUIs.

</comment><comment><USER14> When EmberJS was young, one of the early contributors tried to make statecharts first class in the framework.

</comment><comment><USER15> Makes me think of a tweet from Adam Saltsman yesterday: [https://twitter.com/ADAMATOMIC/status/936638936042082307](https://twitter.com/ADAMATOMIC/status/936638936042082307)

<comment><AUTHOR> The statecharts paper provide a solution to this "state explosion", in the form of hierarchical (nested) states which I also talk about in the slides.

</comment></comment><comment><USER16> Not the next big paradigm because it already exists for critical software and UI [1]. For verification purposes, thinking in state charts at design level is essential. The fact that code does not reflect easily this model is not an issue provided you do not write this code manually, but off-load this to a compiler front-end. It is actually the only sane way to keep state space and performances under control.

[1] [http://www.esterel-technologies.com/products/scade- display/](http://www.esterel-technologies.com/products/scade-display/)

<comment><USER17> It has to exist before it can become the next big thing. It's more the transition from early adopters to mainstream.

</comment></comment><comment> d--b Funny to hear about state charts as the "future" while we can celebrate Grafcet's 40y anniversary.

</comment><comment><USER18> Using state machines in the UI layer is good idea, but problem with trying to present everything with pure state machines is that the state space easily explodes when you have a lot of different potential events and interdependent systems affecting the UI.

</comment><comment><USER19> Feels like FRP. But is it isomorphic to it? I once started with a 'back of the envelope' experiment with a frp gui system and ended up with the conclusion that I could not do without hierarchical state charts.

So, a statechart formulation could be an 'emergent' , most simple way to formalize a Xerox Alto-descendant GUI system.

The fact that they start from an existing deep GUI stack is a bit distracting to the disucssion, though...

</comment><comment><USER20> Interesting take. I do think state-charts (and state machines) can potentially be a huge benefit to both design and development. However, your login/auth examples are really poor fits for this kind of solution. While you could use statecharts, you could also just use generalizable global form validation. There's not a lot of benefit in defining statecharts for common UI paradigms.

That said, here's an example from my own recent experience where formal statecharts/state machines became a necessity to even move forward.

My colleague published a finite state machine for swift ([https://github.com/softwarenerd/Stately](https://github.com/softwarenerd/Stately)) that grew out of necessity from a project we worked on together.

The project ([https://news.microsoft.com/videos/cities-unlocked-a- voyage-o...](https://news.microsoft.com/videos/cities-unlocked-a-voyage-of- discovery/)) was creating a turn by turn navigation system for the blind.

From a workflow perspective (and UI/UX) it was never terribly complex. There are a handful of primary actions, with a handful of intents and a single common workflow with branching outcomes. Over time and iterations, we reduced the workflow complexity quite a bit further as well.

But we kept having more and more functional regressions and exploding bug counts as more and more subsystems and capabilities were integrated into the experience. The issue was that, while workflow and UI were both simple, the number of potential application states exploded.

For a long period we used simple if/then logic, followed by tracking increasingly global variables to detect state conflicts/dependencies during flows. This was messy at best and became an unmanageable nightmare.

Enter the state-chart. We followed nearly the same process as you've outlined, with visual charts first. It gave us the initial frame to build a state machine from, followed soon after by sub-hierarchies. It worked well for us because the majority of our states were not many:many interdependent. Most states had a 1:1 or 1:few correlation with others.

Statecharts likely aren't the next big UI paradigm because most applications are driven by workflow (Line of Business apps) or by state machines that are already well-known (form validation, auth, network graph navigation, CRUD, etc) where those charts are already implicitly well handled by browsers, services or existing frameworks.

I think the magic area for statecharts is in applications with many independents or semi-linear state workflows that don't match up to visual or experiential interaction workflows.

</comment><comment><USER21> Like this idea. Probably work well as a recommended spec/pattern for developers and designers to follow.

</comment><comment><USER22> Are we really rediscovering flowcharts? Because, this sounds like we are rediscovering flowcharts...

<comment><AUTHOR> No. A flowchart does not have any concept of state. Here's a good reading about the difference: [http://www.stateworks.com/active/download/TN9-Flowchart- is-n...](http://www.stateworks.com/active/download/TN9-Flowchart-is-not-State- Machine.pdf)

In essence: Flowcharts do not inherently have a concept of waiting for something to happen.

<comment><USER22> Flowcharts don't have state? Certainly some simple ones don't, but diagramming programs in flowcharts was not an uncommon method of presenting programs... well, ever. Some of the introductory algorithms in Knuth's works use basic flowcharts. In some of his notes on computer languages, diagrams akin to what you are discussing were used by some smart people. So, don't take this as a criticism saying it is a bad idea.

More, this isn't to say these aren't worth looking at again. New and old things are always worth revisiting to see if something is different in the idea or the environment that we are in now.

That said, the UML world had several runs at diagrams that could do this. Activity diagrams being the more complicated ones, but what this is proposing seems to be the standard state machine diagrams.

It was not an unfounded (well, in my opinion) view that UML over complicated things. The problem appears to be that they were too complete in their modeling of the problems. And, these diagrams only really work in a "simple" sense if the viewers and the authors have a lot of shared context between them. The more of that context you put in the diagram, the more you will eventually remake UML's efforts. (Again, you will be in really smart company.)

</comment></comment></comment><comment><USER23> This reminds me of Mealy machines.

</comment><comment><USER24> no

</comment><comment><USER25> Next big ui paradigm would be ditching all these messy JavaScript ui frameworks and going back to real tools we had for implementing desktop applications. At the moment we're switching the tools every 6 months and the next shiny ones are of course no better, just broken or incomplete in different places. Web apps are crappy replacement for professional desktop ui

<comment><USER8> How do I get a user to install a desktop app to complete a survey. Will they do it to take out insurance? Is it feasible to build and test and deploy and patch and support native apps, on multiple platforms, to rent a cement mixer or a snow blower?

The low barrier to entry of web apps is so great we can easily put up with the many downsides.

</comment></comment><comment><USER26> God please no.</comment>


A digital dollar – why, how, and why now - <AUTHOR> https://venturebeat.com/2020/04/18/a-digital-dollar-why-how-and-why-now/ <comment><AUTHOR> I think this is especially relevant given China's rollout of the digital yuan: [https://www.theguardian.com/world/2020/apr/28/china- starts-m...](https://www.theguardian.com/world/2020/apr/28/china-starts-major- trial-of-state-run-digital-currency)</comment>


Show HN: Easily accept Stripe payments for your Laravel 5 SaaS application - <AUTHOR> https://github.com/tylercubell/billing <comment><USER2> What are the differences with laravel/cashier?

<comment><USER3> For those who aren't aware, Laravel Cashier is the official billing package integrating Stripe, Braintree, and more. [https://laravel.com/docs/5.4/billing](https://laravel.com/docs/5.4/billing)</comment></comment>


Ask HN: Please review my Business Briefing - <AUTHOR>

Hey HNers,
One of the things I've just launched is a dead-simple Daily Business Briefing. We send out 12 stories a day after scanning 2-3,000.
Some questions: (a) Is it too simple? (b) Will people want/need to personalised it? (c) How should we get them to personalise it? (Explicitly or is there some better way?)
The link is here: http://bit.ly/Viewsflowdaily <comment><AUTHOR> Oh. The link is <http://bit.ly/Viewsflowdaily>

<comment><USER2> (pssst. I'd edit the story and include the URL there as well, even if it doesn't become clickable)

</comment></comment><comment><USER2> a) No. I don't think it's too simple. I mean, look at Twitter? :)

b) I imagine people may want to personalize it, but I don't think that is something you need to worry about just yet. Keep it lean and mean. But that's my personal opinion.

c) Get them to flag individual items in the mail they get (I want more of this, I want less of this)

One thing I missed when going to the site was the ability to see what the last 2-3 days mails looked like. Before I sign up I'd like to see what I'm getting in to. :)

<comment><AUTHOR> Oh hey thanks. (D) is a good point. I will add that on the sign up page. Cheers

<comment><USER2> When thinking more about personalizing (might be obvious, I don't know):

Bear in mind, though, I am the kinda person that likes clean and minimal and don't really like having to manage online profiles on a gazillion sites.

But say, next to the articles you send out, perhaps have a few tags that categorizes the article. For instance, if it's related to Europe, US, Global, automobile, IT, woodcrafting. Make the tags clickable (unique ID per user in the mail) -- a click on it means "yay, gimme more". How to undo a click, well, I dunno... Some down-arrow like at HN?

<comment><AUTHOR> Yeah. That's a great idea too. Much appreciated</comment></comment></comment></comment>


Paper that claimed the Sun caused global warming gets retracted - <AUTHOR> https://arstechnica.com/science/2020/03/paper-that-claimed-the-sun-caused-global-warming-gets-retracted/ <comment><USER2> The discussion linked to in the arstechnia.com article is fascinating. The paper's author has blinders on. [https://pubpeer.com/publications/3418816F1BA55AFB7A2E6A44847...](https://pubpeer.com/publications/3418816F1BA55AFB7A2E6A44847C24)

<comment><USER3> If this is about the sun moving because of not being centered, that doesn't make any sense at all to me.

Most of the wobble would be Jupiter, so shouldn't Jupiter's orbit be the approximate period of the wobble? Which is 11 years, which is obviously way too short to be in a discussion about global warming.

I found a picture on Wikipedia that seems to confirm that the barycenter takes about a decade to go from near the center of the sun to roughly the furthest away that it gets.

[https://upload.wikimedia.org/wikipedia/commons/0/0c/Solar_sy...](https://upload.wikimedia.org/wikipedia/commons/0/0c/Solar_system_barycenter.svg)

<comment><USER4> 11 - 15 years is exactly the period of the "standard business cycle", which was established by the boom/bust nature of economies that depended primarily on agriculture. Farmers considered it common knowledge that the "business cycle" depended on the Sun's variability.

So, there is a definite, well-known, historically traced effect that occurs on around that time scale. It would take serious study to move past the coincidence level, but it's not something that can be dismissed out of hand, either.

<comment><USER3> Uh, it's also the length of the sunspot cycle.

</comment></comment></comment></comment><comment><USER5> Reminds me to the Milankovitch cycles that are an accepted phenomenon but still not fully explained

[https://en.wikipedia.org/wiki/Milankovitch_cycles](https://en.wikipedia.org/wiki/Milankovitch_cycles)

[https://climate.nasa.gov/news/2948/milankovitch-orbital- cycl...](https://climate.nasa.gov/news/2948/milankovitch-orbital-cycles-and- their-role-in-earths-climate/)

</comment><comment><USER6> No retraction notices here: [https://www.thesun.co.uk/news/5219383/britain- mini-ice-age-2...](https://www.thesun.co.uk/news/5219383/britain-mini-ice- age-2030-uk-rivers-cold/) [https://www.thesun.co.uk/news/4503006/global- warming-sums-ex...](https://www.thesun.co.uk/news/4503006/global-warming-sums- experts-bullies-james-delingpole-opinion/)

tl;dr The Sun _is_ causing global warming, by spreading misinformation. :-)

</comment><comment><USER7> I have a friend who does atmospheric physics research (nothing surface level) and who looks into solar intensity from time to time as a side thing. IIRC, she told me there are intensity cycles that definitely do affect the earths temperature and that they vary over a course of only a few years. I _think_ she said we are at a solar minimum right now, which is making it look like global warming has been less than it is. Apologies if I am mis-remembering.

<comment><USER8> Correct, the temperature difference is small but affects weather:

[https://www.exploratorium.edu/solarmax/whatis.html](https://www.exploratorium.edu/solarmax/whatis.html)

[https://www.giss.nasa.gov/research/briefs/rind_03/](https://www.giss.nasa.gov/research/briefs/rind_03/)</comment></comment>


Ask HN: Can I review your startup / product? - <AUTHOR> I've had a few startups and done product for a long time. Over the years I've gotten a lot of feedback, as well as reviewed a lot of products and startups. I'm looking to start creating video content focused on reviewing startups, so that everyone can benefit.<p>If you're interested in having me review your product, comment with your product and the best way to get in contact with you. I'll review it and reach back out when I'm finished, with a link to the results. Thanks! <comment><USER2> Hi,

I'm working on building a banking related startup. We're mostly working on UI design and regulatory compliance right now and will start on actually building the prototype very soon, but I'd love to talk more about it. Probably not video material yet but we can at least open a channel of communication. You can reach me at ashutoshraiofficial[at]gmail[dot]com

<comment><AUTHOR> When I wrote the post, I was thinking more functional MVP or better. But, I'll look at whatever you got. I'm happy to provide feedback, even if it's not video material.

I'll follow-up via email.</comment></comment>


Ask HN: Adopting Teams or Slack Quickly - <AUTHOR> Hello HN Hivemind! Like many others, I find myself leading a team located in two physical locations that is now scattered by mandatory work remote.
We have in the past embraced remote work on an incidental or scheduled basis, but never en masse for a long period. (At least a month)
We are Office 365 based, and will be looking at maximizing the toolset to adapt to our new reality. Specifically, we want to use Teams to collaborate and build the type of daily interaction that we get in person today. What do you do formally at the Team level? What do you encourage your team to do on their own? <comment><USER2> Slack has a far superior UX from the last time I checked.

If UX and productivity does not matter then Teams is fine.

There are also open source ones like Rocketchat.</comment>


Learn Data Breach Detection and Response at BlackHat USA - <AUTHOR> https://www.blackhat.com/us-18/training/schedule/#data-breaches-detection-investigation-and-response-9790 <comment><USER2> Blatant advertisement for overly expensive training course?

<comment><USER3> Pretty much. Unless highly technical (like hardware hacking, Windows internal, reverse engineeeing and such), most courses at Blackhat are way overpriced for the content. Moreover, I discussed with a few guys from FireEye at last year's conference and they mentioned that they were not getting paid for teaching those course. If true (I'm skeptical) I wonder there that money goes.

</comment></comment><comment><USER4> garbage post for overpriced training you can learn on Youtube.</comment>


Don't Dequeue WordPress' jQuery - <AUTHOR> http://eamann.com/tech/dont-dequeue-wordpress-jquery/

<comment><USER2> You're missing one very important detail: if a user already has jQuery loaded from Google's CDN (which is pretty likely, way more likely than having loaded your local copy) the browser won't make any requests.</comment>


Science Behind Nintendo Switch's Pleasant Sounds and Audio Branding - <AUTHOR> https://www.reddit.com/r/NintendoSwitch/comments/d1d34d/the_science_between_the_nintendo_switch_click/ <comment><USER2> I always found it interesting how much more memorable nintendo's gaming console (aka wii, nintendo switch, gamecube) were compared to other systems</comment>


Fail Slower: The Dangers of Punting Too Early - <AUTHOR> http://codercofounder.wordpress.com/2010/06/29/fail-slower/

<comment><USER2> Summarising:

In the USA it means to postpone, give up on (possibly temporarily) or to make someone else's problem or responsibility.

In other parts of the world it can mean to press on with, perhaps against the odds, or to take an aggressive/assertive course of action.

Might I suggest that people should be aware when using the term that it might be taken to mean the opposite of what you think?

<comment><AUTHOR> Sorry for all the confusion, and thanks for setting the record straight.

</comment></comment><comment><USER2> Would someone care to explain what "punt" means in this context? It's a word that turns up reasonably often ...

<http://searchyc.com/punt>

... but I really don't have a clue what it means. Is it some kind of sporting metaphor?

Thanks.

<comment><AUTHOR> It means to give up. To punt on something is to set it aside or to give up on it. At least that the definition I was going for. :)

<comment><USER2> Interesting.

In Australian Rules Football, and to a lesser extent in Rubgy and Gaelic football, a "punt" is a kick which is most commonly used in an attacking manner.

As a verb, "Punt" can also mean:

\+ A kick of a football

\+ A method of propelling a boat with a pole

\+ To place a bet, usually at long odds, or a risky one

As a noun it can be:

\+ The former unit of money in Ireland

\+ An open flat-bottomed boat (usually propelled with a pole)

\+ The dent in the bottom of a wine bottle

Your usage matches that I've seen here before, but is not one with which I'm familiar. I wonder if it's preculiarly and specifically North American. In particular, though, it's the exact opposite of other meanings in other parts of the world.

<comment><USER3> _\+ To place a bet, usually at long odds, or a risky one_

So that's what they mean on "Dragon's Den" when they say "It's a punt for me.". I guess I assumed something similar, but was never really sure.</comment></comment></comment></comment>


5 Habits I Keep Reminding Myself to Be a Better Developer - <AUTHOR> https://medium.com/livecodestream/5-habits-i-keep-reminding-myself-to-be-a-better-developer-cf32a9dfdf24 <comment><AUTHOR> I've posted this article which is based on my personal experience, and I'd love to hear from all of you, what makes you better at coding? maybe even a better hacker?</comment>