brikis98

12 ms·

61.
by brikis98 13y ago
Re-read my reply above. You're comparing a fraction of Gretzky's contribution to a fraction of all the professional hockey players, even if you only look at forwards. Even then, he ends up 2-3x better than this already elite group
62.
by brikis98 13y ago
250th on the list of all time NHLers? That's still a tiny percentage of all players that have every played (~1500/year, obviously with some overlap from year to year). And that's only counting those in the NHL; there are
63.
by brikis98 13y ago
Actually, in the case of Gretzky and Lemieux, I believe they did average ~10x more points (and other contributions) per season than the average player. Also, don't forget that the NHL is just the best of the best; there are many hockey
64.
by brikis98 13y ago
First of all, some star athletes are statistically far more than 10x better than the average. For example, the average NHL player scores less than 50 goals in his career [1] whereas Gretzky scored 894 [2] and Mario Lemieux scored 690 [3].
65.
The 10x developer is not a myth(brikis98.blogspot.com)
26 points by brikis98 13y ago|15 comments
66.
Turning imperative Java code into functional Scala code(brikis98.blogspot.com)
2 points by brikis98 13y ago|0 comments
67.
You've gotten into a debate with me. Awesome. Let's lay down a few ground rules.(brikis98.blogspot.com)
1 points by brikis98 14y ago|0 comments
68.
Play Framework: async I/O without the thread pool and callback hell(engineering.linkedin.com)
7 points by brikis98 14y ago|0 comments
69.
What my grandfather taught me about happiness(brikis98.blogspot.com)
4 points by brikis98 14y ago|0 comments
70.
by brikis98 14y ago
Our Play frontends are entirely reactive/non-blocking, so yes, we're using the async features very heavily. We'll have a blog post about this in the near future. Our Play backends, if they use JDBC to talk to a database, are fully blocking,
71.
by brikis98 14y ago
Play is an open source project that has been around for a few years. In fact, that's one of the big selling points for us: we're not inventing something new, but using something the community is using, and contributing back to it.
72.
by brikis98 14y ago
LinkedIn has been using Grails for ~4 years. It's a terrific framework, but we found that Groovy was one of the downsides. The language is very easy to learn and use with Java, but we found that it didn't scale nearly as well to large numbe
73.
by brikis98 14y ago
We had Java services that produced JSON, some that used JSPs, and a variety of others. TDD works in some cases, but if you ever wanted to do manual testing - for example, actually see the UI you were working on with real data - that meant
74.
by brikis98 14y ago
For simple setups, that can work. JRebel can help. For more complex servlet apps, especially those with Spring lifecycle management, this rarely works, which means a full redeploy after almost every Java change.
75.
by brikis98 14y ago
Play actually has a really nice plugin system, which we used extensively to integrate Play at LinkedIn. The plugin system offers lightweight support for DI. For example, to use a FooPlugin, you don't use it directly, but ask Play for an ins
76.
by brikis98 14y ago
LinkedIn is primarily a JVM shop. We believe that type-safe languages like Java and Scala are a good choice for building performant and reliable systems that scale to huge numbers of users as well as huge numbers of developers. We aren't co
77.
by brikis98 14y ago
On my wimpy Macbook Air, most Java changes reload in < 3 seconds. Compared to redeploying an entire Tomcat/Jetty app, this is several orders of magnitude better. Combined with the scala console in sbt for interactive coding, the ~test c
78.
by brikis98 14y ago
LinkedIn uses a service-oriented architecture; the site consists of hundreds of individual services - that is, separate codebases, deployed on separate hardware, built on a handful of different technology stacks. This lets us iterate and sc
79.
Intra-cluster Replication in Apache Kafka 0.8(engineering.linkedin.com)
6 points by brikis98 14y ago|1 comments
80.
LinkedIn Hackday, Berlin, October 19 - 20(hackday.linkedin.com)
1 points by brikis98 14y ago|0 comments
81.
What's in a name? A software engineer by any other title...(linkedin.com)
1 points by brikis98 14y ago|0 comments
82.
by brikis98 14y ago
What errors?
83.
DevelopHer Hackday: a Hackday Competition for Women(hackday.linkedin.com)
1 points by brikis98 14y ago|0 comments
84.
by brikis98 14y ago
IMO, SASS ~= LESS, but Compass > *. Damn shame that Twitter Bootstrap went with LESS.
85.
Announcing DevelopHer Hackday, a public hackday competition for women(engineering.linkedin.com)
1 points by brikis98 15y ago|0 comments
86.
Inject: CommonJS compliant JS dependency management for the browser(engineering.linkedin.com)
6 points by brikis98 15y ago|0 comments
87.
by brikis98 15y ago
Very cool. And kudos on the clean documentation.
88.
by brikis98 15y ago
Cars are not a good analogy for this situation, at all. The presence of software and computers in our life is much closer to the invention of the alphabet and writing. Written text gradually becomes so ubiquitous in life that being illitera
89.
by brikis98 15y ago
My guess is that in the next few decades, not knowing how to code will be equivalent to being illiterate. This doesn't mean everyone will get paid to write code, but I suspect there will be far more programmers in the future than now. Of
90.
by brikis98 15y ago
Golden Age of the Developer? No, not even close. This is the just the tip of the iceberg. Prediction: in ~30 years, programming will be just as important as literacy.

More ›