Elite accountants usually get promoted into CFO positions, where they are very important and get a huge paycheck. There is a huge difference between a good and an amazing CFO.
I think 10X people exist in any area, including accounting and programming. E.g. John Carmack, Linus Torvalds, Poul-Henning Kamp. Some top accountants can be found by looking at CFO positions of huge companies.
These people are very rare tho' and most of us have probably not worked with a 10X person. Just like most of us have not played football with a "Ronaldo-level" player.
There are probably also 100X people - and they're mostly unemployable in any conventional sense. (Maybe Wolfram and Kurzweil?)
I think the bar for top talent is higher than is obvious, and it's lower than it used to be.
It's not at the level of 'smart and gets a lot of stuff done' - it's at the level of good as McCarthy and K&R and the guys (and occasionally the women) who invented coding in the 60s and 70s.
Most of them have been forgotten, but many of them had phenomenal skills - the kind of people who would work for a couple of months on a project, type in all the code on a single day, and have it work perfectly first time.
Or who would sketch out a fully functional timesharing OS for a new hardware architecture over a weekend and have it finished and working a couple of months later.
Or the small team at Xerox PARC led by Charles Thacker who decided to clone an entire DEC PDP-10 mainframe as a side project, because management wouldn't let them buy one and they wanted something nicer to code on.
The list of speakers looks fantastic! This said, I think the list lacks diversity. I think it would be great to have someone outside of SV in it (e.g. Jason Fried, Jeff Bezos etc.) One of the better Startup School talks I seen was from DHH (that presented another way of building a successful company).
This presentation is tasteless and totally takes any seriousness that should be related to making and promoting an OpenSSL replacement. I personally can't take it seriously and I would recommend hackers to think about what image their presentation and design conveys.
When it comes to security tools, one uses a different approach to selecting your tools. At least, you do if you want to be secure. The best presentation and the prettiest website are nowhere in the selection criteria. You look at the history of the people involved, primarily. What have they done in the past? Was it believed to be secure by other researchers? Is it secure today because they have actively maintained it? Have they used good practices that allow their code to easily be audited by others? Have they welcomed feedback from other competent developers?
Using Comic Sans and bitching about the quality of another project is irrelevant in this scenario. OpenBSD project brings with it an almost two-decade history of seriousness about security that I think one would be a fool to ignore.
When Stee Jobs got kicked out of Lisa development and took over Macintosh he raised a pirate flag, sticking up a finger to the suits have a long and storied history in the business. The people that take offense at such things aren't people you want on your side anyway.
To me it conveys that they are a group of grognards that can't be bought and never mince words or use euphemisms, even if it upsets people. Precisely want you want for developers of a security library.
ShareJS also supports collaboratively editing arbitrary JSON documents. Support for seeing everyone's cursors is being added at the moment - there's a sandbox kicking around here if you want to play with the prototype version: http://sharejs.org:7007/
In general, the more I look at the codebase the more messy it looks like. They could have built something much simpler that solves the same problem.
It has come out of enterprise focused development - there's no getting away from that. And we have enterprise customers that the toolkit has to support.
However, enterprise is in a state of convergence right now. Those that would not previously work at "Enterprise" orgnisations are providing great value there. Those that have been part of the web development community for some time will hopefully attest to that.
So, what we're trying to do with BRJS is follow that convergence; and be part of it. Some software engineering concepts traditionally associated with enterprise shouldn't be dropped simply because of this association. Similarly techniques and tools that wouldn't have been found in the enterprise shouldn't be dismissed because they don't conform to the expected stereotypes.
- separation of concerns
- services via an IoC/Dynamic Service Locator (see Angular)
- PubSub - hopefully Addy Osmani and a number of other solutions have done enough to clarify why this is useful
All these ring of enterprise. But they're actually just good and simple software engineering practices.
One obvious thing that will still stand out as needing improvement are the deep directory structure (from Java). This is high on our list of improvements. We also only export to a WAR right now, but flat file export is also a high priority.
It was basically create by people who didn't have much JS experience so that's why it looks like Java more then JS, in fact that's why it's Java and not node. You're right it could have been much simpler. It used to be much worse.
It was created for people without JS experience, specifically Java devs that moved from back end to front end teams to write webapps. Things have since moved on and we're bringing the coding style, among other things, more inline with new practices.
The tooling itself is Java since a lot of Caplin's customers still have't adopted Node, in fact some of their ops departments are completely opposed to it, and just because it isn't written in the same language as your front end code does't mean the tooling and principles are any less valid or useful.
Allegation that a wife of a founder can read private chats at GitHub makes me question GitHub's privacy and security... I would love if we would have a statement of GitHub on this matter since it would be a huge privacy breach (and something that would make us move all of our private repos outside of GitHub). (posted this as a comment on the article as well)
Mutexes are absolutely idiomatic Go code. In fact the Core developers on the ML will often suggest them as a simplification over goroutines for synchronizing access to a shared resource. I'm not sure where you get the idea that they aren't idiomatic.
"Do not communicate by sharing memory; instead, share memory by communicating.
This approach can be taken too far. Reference counts may be best done by putting a mutex around an integer variable, for instance. But as a high-level approach, using channels to control access makes it easier to write clear, correct programs. "
There are no implications here, it's stated pretty explicitly:
"Reference counts MAY be best done by putting a mutex around an integer variable, for instance. BUT as a high-level approach, using channels to control access makes it easier to write clear, correct programs."
There is a difference between what someone with a background from other mainstream programming languages might think would be the best approach to locking (mutexes) and the idiomatic Go approach (unbuffered channels).