A Fear of Foreign Investments - <AUTHOR> http://www.nytimes.com/2007/08/21/business/worldbusiness/21wealth.html?ei=5124&en=d92692f4fdb3048a&ex=1345435200&adxnnl=1&partner=permalink&exprod=permalink

<comment><AUTHOR> Personally I'm glad that these funds exist. It's much better than the alternative, foreign owned US dollars being sold. Instead, everyone just ends up owning a little part of America. $2.5 trillion doesn't seem like that much, how fast do you think sovereign wealth funds will grow over the next decade or two?</comment>


To treat some diseases, researchers are putting immune cells on a diet - <AUTHOR> http://www.sciencemag.org/news/2018/03/treat-some-diseases-researchers-are-putting-immune-cells-diet <comment><USER2> The opposite (i.e. force feeding the immune cells) would also be worth looking at for improving the checkpoint inhibitor treatments of cancer. I am off to look to see what can be used to increase oxphos activity.</comment>


2005 CDC:"Chloroquine a potent inhibitor of SARS coronavirus infection spread" - <AUTHOR> https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1232869/ <comment><USER2> In France, the use of chloroquine has become a huge debate, with a mediate- savvy professor advocating loudly for it: Professor Raoult.

From what I understood, in the end, it does not work so well, even if there are some subtelties (said professor is mixing chloroquine with another drug).</comment>


The Number One Trait of a Great Developer - <AUTHOR> http://www.engineyard.com/blog/2011/the-number-one-trait-of-a-great-developer/ <comment><USER3> This post just listed traits very prominent in hackers - deep fascination for technology, perfectionism, need for deep focus and few distractions, concern for efficiency - and wrapped this package under the label of "lack of judgment".

The problem I have with such generalization is that these scenarios are always a bit caricatural and are usually presented in a way that nicely fit the argument.

The experimental developer is required to build simple stuff, but goes to extremes just because he wants to toy with new technology, while the great one is praised for her conservative approach. It also helps that she asks exactly the right questions and receives the right answers.

"How many devices do we expect to have?" "Well, we hope to sell 500 in 12 months." "How often will they need to report in?" "Roughly once an hour." "How reliable is the network?" "It'll use WiFi, so fairly reliable."

In reality, sometimes you ask these questions, you get very accurate answers and based on that, you pick some technology that you believe will spot on address the problem. You might even make the judgment call that you have enough wiggle room to include one or two new concepts you've been curious about, that are yet still very relevant to the task at hand.

Then something happens mid-project and it turns out that what was originally _requested_ wasn't actually what was _needed_. How many times has that happened?

Two possible conclusions in these situations, for either developers:

\- the "rockstar" either looks like a god, for having foreseen some problems, or he'll be the guy who brought a tank to a knife fight.

\- whereas the "great developer" will just look incompetent, or she'll just be, well, great.

Judgment is a nice trait for a good developer, but it is subjective. There are some hits and some misses.

What I believe makes a _great_ developer is the fact that they might work to push their own boundaries, which is the reason you're interested in them in the first place, but most importantly, when they do, they stand by their work.

I can't embrace a definition of a great developer, where the primary quality is to avoid causing trouble for the company, the project, the team or their boss. That has almost nothing to do with the discipline. You're describing a "great employee" or a "great team player".

The exact description of a great developer given in this article might absolutely not work in other environments, where developers are required to push the envelope and think outside the box. In such context, your great developer might be thought of as mediocre at best.

<comment> buff-a _the "rockstar" either looks like a god, for having foreseen some problems, or he'll be the guy who brought a tank to a knife fight._

Fights over. The guy with the knife killed you while you were putting the treads on. Meanwhile, the guy with the knife discovered that his customers actually wanted something else _because they could run the first iteration of the actual product_ while you were worrying about scaling to a million customers. Maybe the customer is in the steak-house business, but you just stopped reading at "customer wants knives", got a hard-on and started building tanks.

 _Then something happens mid-project and it turns out that what was originally requested wasn't actually what was needed._

So you advocate over-engineering a just-in-case tour-de-force, instead of agile, iterative, responsive development. How are you getting up votes????

 _This post just listed traits very prominent in hackers - deep fascination for technology, perfectionism, need for deep focus and few distractions, concern for efficiency - and wrapped this package under the label of "lack of judgment"_

Not so. The post listed traits found in very prominent in hackers but also found in ineffective, inexperienced hackers. And advised that to focus on just those traits is wrong. The key trait that separates these two groups is judgement. A "prominent hacker" will use the right tool for the job, right now.

<comment><USER4> "So you advocate over-engineering a just-in-case tour-de-force, instead of agile, iterative, responsive development. How are you getting up votes????"

There's a time and a place for heavy engineering, and a time and place for agile, iterative development, and sometimes both have times and places in the same project.

One element of good judgement is realizing what the tradeoffs between older and trendier development methodologies are, and then navigating them intelligently.

For example, the direction LedgerSMB is moving is towards a heavily engineered, intelligent database with a well-engineered API, and a more agile application built on this framework. The database engineering (esp. in an accounting app) needs to be done _right_ and account for a lot of "just in case" while the actual application running on the database should be able to be customized relatively easily.

<comment> buff-a Its funny, because the only code I write that is 100% TDD is the stuff that _has to be done right_. "Heavy Engineering" without agile, iterative development is actually just "Heavy Wishful Thinking", or "Heavy Waterfall".

</comment></comment></comment></comment><comment><USER5> This article is totally true, but almost impossible to act on.

It's very very hard to differentiate people who have a passion for doing good work and people who just like to play with the latest trendy technology. Especially since the latter is often just an immature stage of the former.

<comment><USER6> You can look for someone who works with non-trendy technologies.

This is actually a big reason why non-trendy technologies persist - indeed, why they often thrive in the larger marketplace precisely at the moment that they become least sexy and fall off the geek radar. Non-trendiness is a market signal of its own. There's a lot less noise in the backwaters, and those products which survive to become boring have demonstrated staying power. People obviously aren't using them for fun, or because they're easy to promote on popular blogs, or because VCs can impress each other by dropping their names. They must have survived for another reason. Perhaps they are... pragmatic, useful, or cost-effective?

This strategy must be used in moderation, of course. The final stage of nontrendiness is obsolescence and death; You don't want to hire those who are expert only in obsolete things. (Oh, my IE6-CSS-hacking skills will soon have no market value. _Thank goodness!_ )

<comment><USER7> There is a fine line. Sometimes people work with non trendy tech because they have no interest in developing their skillset.

</comment></comment></comment><comment><USER8> This essay seems to beg the question. A "good" developer, by its definition, is the who picks the most reasonable, easy to maintain technology, because she knows anything "much more complex would be beyond her current skill." Yet, if she is lacking in skill, how can we be sure her judgment is sound on what a "reasonable" and "easy" technology is? Doesn't the basis for that judgment require superstar-like experience and curiosity?

<comment><USER9> I would say that once you reach a certain level you are able to determine which technology is reasonable based on things like language familiarity, community support, and documentation.

<comment><USER8> Sure, but I wonder if two years in Ruby, or any language, is enough?

A superstar dev might go out and try a lot of the new, cool stuff, even when it is needed. But it seems that that developer would also have a grasp of the common characteristics of bad technology.

So I think there are at a minimum _two_ good traits of a great developer. The rockstar-like quality of having the skill, curiosity, and breadth of knowledge to handle being on the edge. And the maturity and thoughtfulness to know whey he/she has failed in the past.

<comment><USER10> Two years? I think you can learn everything you ever needed to know about a language in a much shorter time period than that.

<comment><USER11> Totally agree. For example, if a web dev wants to try a new language/framework, he or she can be competent in a few weeks and well-versed in 3-6 months. No?

</comment></comment></comment></comment></comment><comment><USER12> HN has a lot of link bait titles these days, making you click just to find out what they are talking about. How about

      Judgment is the number one trait of a great developer

</comment><comment><USER13> What this article is saying is you need someone with experience to make the right judgement. This means you need to find someone that has already gone on the 5-8 year roller coaster that a developer goes through. This from the 'just get something working', to astronaut over-architecture, to practicality that might come with running many projects and being through many successes and failures.

A good developer might be at any stage in that process and it is really a timing thing. Typically after 10 years most developers have this as long as they have not become too pessimistic and have experienced many platforms, not religious to any of them.

Experience with a beginners mind that is willing to innovate still, is the perfect balance of a 'great' developer.

<comment><USER14> A very smart developer who I respect once said something like: when you are young, you have lots of energy and want to learn/use the latest technology. As you get older and gain more experience, you start to see the patterns. It's not about the technology, there are repeated themes and solutions. But when you start realizing this and have accumulated 7 years of experience, you may be transitioning out and wanting to begin starting a family. So the people who might be most qualified might be wanting to leave the intensity of coding for the relative stability of management.

So perhaps n years of experience is a cludgy filter for the relative graybeards who understand that technology is just a tool, not an end in itself.

</comment></comment><comment><USER15> I find the volume of defensive comments a little amusing, since three times a day we all vote up and universally agree ideas are cheap and execution is king. The author is drawing the same parallel to characteristics of individuals.

Unlike most of you, I read that and found myself saying "yes!" It's the tortoise and hare argument: good dev teams are disciplined, focused and stable. I suspect the backlash is because it stung a bit, since many here saw themselves in flighty Jack, versus measured Diane. I was there too, but have learned from a few failed projects and disappointed clients. I encourage you to reflect upon yourself a little more carefully; good execution is decidedly unsexy and needs more Diane than Jack.

</comment><comment><USER16> Seems a bit pigeon-holey to me. I'd think twice before applying such broad stereotypes.

</comment><comment><USER17> The article is a good example of a false dichotomy.

<http://en.wikipedia.org/wiki/False_dilemma>

<comment><USER6> What dichotomy?

Are you being misled by the fact that the article uses only two examples? That's a rhetorical shortcut, not a proposed dichotomy. The article does not actually claim that "those who use Sexy Tech X tend to have bad judgement" or anything like that. What it says is that folks with good judgement use appropriate tools for appropriate reasons, which may be situational.

<comment><USER17> I'm not making a rhetorical argument. You should take me seriously.

The article stereotypes "rock star" developers as being obsessed with using the latest tools and compares them to more "average developers" who (it is claimed) better know their limits and ship more maintainable products.

I believe that this is a false dichotomy.

There are plenty of "rock star" developers who ship maintainable products which use appropriate technology. There are far more "average developers" who ship awful, barely-functional code because they're only able to use a limited set of technologies.

<comment><USER6> So, though it isn't entirely unambiguous, when I read the article closely I see that it agrees with you.

Let me see if I can make this boring enough to understand. Let's draw a classic management-consulting two-by-two matrix:

      GENIUS-JUDGEMENT       GENIUS+JUDGEMENT

      AVG-JUDGEMENT          AVG + JUDGEMENT

The author's argument is that the column on the right trumps the column on the left: Judgement is important, even if the genius-with-poor-judgement is some kind of CS demigod. However, he doesn't actually say that lack-of-genius and lack-of-judgement are correlated, or that he'd turn down a wise genius if such a rare and precious being fell on him from the sky. You've gotten the unfortunate impression that he's saying that, but that's an artifact of trying to use two examples to describe a fuzzy multidimensional space. (I mean, really, even two dimensions is a painfully naive approximation, except of course to a management consultant. ;)

Of course, if the original blog post used my four examples it would be as dull as... management consulting. The moral of this story is that writing is hard. You have to leave some ambiguity, and trust the reader to fill in the gaps, and hope the gaps are not too large, and that your sly invocation of the trendy-yet-pragmatic NoSQL user in the penultimate paragraph helps people take the hint. But sometimes the whole thing just doesn't work. C'est la vie.

<comment><USER18> If clarity was one of the design goals, the author should have included the 2x2 matrix. Sometimes, the best opinions aren't those that corrects our wrongly-held beliefs, but those that don't create them, which is much more silent.

</comment></comment></comment></comment></comment><comment><USER19> I agree with the gist of this article, but there is an opposite side to this piece as well.

We do need those developers that pick the most wild, crazy, and bleeding edge technologies. New technologies shouldn't and certainly don't solve every problem out there, but they often tackle a couple of really interesting areas quite well. At the very least they allow us to question and rethink our current development stacks. Also, being one of the first to adapt to a technology has it's benefits, not saying that it justifies the risk, but it should be considered.

Also I think node js and cassandra are pretty easily maintainable, but thats not really what this is about :)

</comment><comment><USER20> Judgement is indeed an important part of being a great developer, but I don't think the article is doing a good job of explaining why, or what kind of judgement.

First of all, the story about Jack & Dianne doesn't illustrate much. Why Jack ended up with unmaintainable code and Dianne didn't? And what does it have to do with the tools they've chosen? You can write unmaintainable code in any language.

It sounds like Dianne did a better job of understanding requirements. Okay, fair enough, understanding requirements is important (though I wouldn't call it "judgement"). But requirements change. They always do, that's why software has to be maintained - to reflect changing requirements. Which means that whether the code is maintainable does not depend on the code per se - <USER2> depends on _how_ requirements change (unless the code is so bad that it can't be changed at all).

Say, if tomorrow the new requirement is to add a new API to the backend, Dianne's solution is probably more maintainable because it's simpler. But if the new requirement is to scale to 10K users, Dianne's solution might have to be rewritten from scratch, and thus completely unmaintainable.

So, to write maintainable code developer has to anticipate future changes in requirements and make tradeoffs based on those predictions. Now, that's a hard problem, that's where we need judgement and experience. This kind of judgement makes a great developer - mere conservatism in selecting tools and technologies does not.

</comment><comment><USER21> I would say a great developer should have the followed waxed:

1\. Accurate time estimation & communication skills

2\. Not suffer perfectionism

3\. Know where to find the right answers

4\. A good understanding of general programming concepts and when to apply

5\. Ability to write code in a way that it's easy for future dev to understand

6\. A good understanding of tasks other than programming and how they all fit together in a business environment

7\. A good dose of enthusiasm - things can get tough, how are they going to deal with it?

I'll end my comment by saying that you won't know the extend of the damage caused by a bad developer until it's too late.

</comment><comment><USER22> I agree wholeheartedly with this concept. I previously used the term "instincts", but I think "judgement" is better. A solution is more than a technical implementation: it should address the actual requirements of the product as well as the characteristics of the maintainers. A combination of familiarity + ease of development + enough scalability.

</comment><comment><USER23> I think that for any type of problem solving there is a clear workflow you must go through in order to efficiently come to a solution. 1.) Break down the problem to see what you are actually required to do. 2.) Think of ways in which you have solved previous problems and check whether you can do something similar to what you have done in the past. 3.) If you need to do something that you haven't done before do some research and find the tools that you need to solve the problem; if there are multiple paths to solution apply Occam's Razor. 4.) If step three didn't work, you haven't looked hard enough or you have found a problem that no one has solved before, it is most likely the former. 5.) Implement your solution; if it works great the problem has been solved. If it doesn't work retrace your steps and then take a break and come back to the problem when you have a clearer head. 99% of your problems can be solved in this manner

</comment><comment><USER24> I think the truth of this article depends on the size of your team.

If you're hiring only one to a few developers, it's likely that you need your employees to self manage. They need to strategize, have realistic expectations, and fulfill them to the best of their abilities. "Dianne," the good developer, demonstrates these skills. So, judgment is important from this kind of developer.

However, I think that "Dianne" would be best suited to a more managerial position, focusing on her strategy skills and ability to relay needs to other developers. Handing off the implementation details to a team of rockstars, with deep and varied proficiencies, would make for a spectacularly complementary team.

And in the latter case, your best developers are - and should be - rock stars. You need to consider not only how you want your code to scale, but how your company will.

</comment><comment><USER4> I think the fundamental problem exposed in the article is actually not the hiring criteria, but rather that resumes are usually screened by HR departments who have no clue about what a job entails. So the hiring managers have to provide hiring criteria that the HR resume screener can understand. The HR resume screener is not a programmer and has no way to judge the capabilities of programmers. The hiring manager may not be either.

As seen in a Slashdot sig some time ago, "Light travels faster than sound, which is why some people appear bright until you hear them speak." Unfortunately appearances win to those who cannot understand what is being said.

</comment><comment><USER25> _When I look around at other companies hiring Ruby on Rails developers, I see them focusing on three major traits: Super-smart; Large community following; Deep Ruby knowledge._

I definitely agree with the thrust of the article, but I run community sites and have run Ruby job ads for a few years and I can't recall seeing anyone looking for a hire with a "large community following."

In aggregate, across all the listings I've run, companies are most usually looking for experience, team working skills, familiarity with Agile practices, TDD experience and, sadly, the ability to commute to a certain location.

<comment><USER26> _I can't recall seeing anyone looking for a hire with a "large community following."_

 _companies are most usually looking for ... team working skills_

I believe there is an operating assumption here that active membership and following in a given community is a solid indicator that the individual in question has very good team interaction skills, as well as working knowledge of the community's domain focus.

<comment><USER25> Maybe, although I think that assumption would be erroneous (not that you suggested it wasn't :-)).

I can only speak for the Ruby and Rails community but I think there are many developers who have a strong "following" on blogs, Twitter, at events, and even on GitHub but who aren't necessarily good "team players" (To be fair, I include myself in this bracket ;-)).

</comment></comment></comment><comment><USER27> When I do my first interview (as the interviewer) one day, I'm going to ask "Do you read blogs by software developers?" and if they answer "Yes", I will not hire them because these blogs are a bunch of horse shit.

<comment><USER28> You'd be smart to ask "Which ones?" before you dismiss all dev blogs as 'horse shit'.

Blogs like Coding Horror and Object Mentor should gain your respect, not your disdain.

</comment></comment><comment><USER29> Remember when Sinatra and Ruby on Rails were the new, hot, trendy technologies? I'm sure EY was humming a different tune back then.

</comment><comment><USER30> Judgement:

For it to be judgment, it must be living and active in a programmer's mind. It can't be switched on some of the time, it must be switched on all of the time, for the mundane and the monumental. It must be sharper than a double-edged sword; it must discern the thoughts and attitudes of the heart.

</comment><comment><USER31> One fallacy in this article is the portrayal of the typical "regular programmer". The reality is that many regular programmers would pick something horrible but established in the enterprise like Java Struts or Oracle Web forms, not Rails, because that's "what they know".

</comment><comment><USER11> I agree with this article and have a proposal for another trait of a great dev:

A great developer is not necessarily one who writes the most elegant code, but one who knows how to walk the line between elegant code and speedy dev time.

Thoughts?

</comment><comment><USER32> How do you know/decide what a "good" solution is?

It all depends on what you already know and what your team is best at.

And although a "simple" solution may look like the best choice, it too can have the same problem of maintainability.

<comment><USER11> I agree with the first point. Development is usually a team effort. Effective teams generally play of their strengths. This is probably more important than having a rockstar on board.

Isn't simple code inherently more maintainable. I can see it having the problem of lacking scalability, but prematurely building in scalability is the root of all evil...

<comment><USER33> I agree that premature _anything_ is bad, especially in extreme form, however, your other point needs some elaboration.

 _Isn't simple code inherently more maintainable_

Verbose, over-simplified code can also be unmaintainable because you lose track of the bigger picture.

The only really simple code is small projects, and code that was just written. In the longer run, as features are added, there is always complexity being added.

In that phase it becomes important to separate concerns, prevent accidental complexity, factor out repeated code, and so on. This can mean that some parts of the code have to make use of more powerful constructs of the programming language, and thus are less trivially "simple".

Also, opinions differ greatly on what is "simple code" and what is not. After all, all code is simple once you understand it.

<comment><USER4> That's why I have come to define "elegance" as "simplicity perfected."

The best solution is the one which makes use of a number of clear, easily understood, simple solutions in combination to solve a problem. But the wrong approach to simplicity can be as bad as complexity.

</comment></comment></comment></comment><comment><USER34> This hearkens back to what one of my professors used to tell us- "Always draw a conclusion (from your data)".

Don't just routinely foist gobs of data off onto others; you were hired for your brain. Use it.

</comment><comment><USER35> Great developer is relatively easy to identified. Three things: 1. get shit done, 2. good decisions on trade-offs (cost, performance, etc), 3. maintainable work.

</comment><comment><USER36> The awesome ruby developer following all tenants of Martin Fowler vs the curious Joe who hacks with nosql and clojure.

The story ends with OMG!!! Ruby is still awesome.

</comment><comment><USER37> I like to think that I don't try to solve hard problems, instead I like to rephrase them as easy ones.

</comment><comment><USER38> I always go by the maxim: "(build) the right thing at the right time". I think John Bentley said that.

</comment><comment><USER39> The real fallacy in the article is an unstated assumption - that developers should be homogeneous. Why not have a "rockstar" Jack _and_ a "sensible" Dianne, in dynamic tension? Teams of one are the exception. In multi-person teams, focusing on the same attribute not only misses an opportunity to hire developers who complement one another but often leads to outright conflict as multiple developers lay claim to the same decisions or assignments. The author's point is _slightly_ more applicable to choosing a lead developer, where judgment is at even more of a premium and many people would make the mistake of promoting Jack over Dianne because of his higher profile, but even then I think the article does more harm than good.

</comment><comment><USER40> Straw Man is the name of the fallacy!

<comment><USER4> One might think that it ceases to be a straw man when someone rushes to defend it.</comment></comment>


Portal for the C64 - <AUTHOR> https://www.jamiefuller.com/portal/ <comment><USER2> Unfortunately I think Activision got there first. I even have my copy of the novel autographed by Rob Swigart.

[https://en.wikipedia.org/wiki/Portal_(interactive_novel)](https://en.wikipedia.org/wiki/Portal_\(interactive_novel\))

I'm still looking forward to playing this one, though. :)

<comment><USER3> It's a different game, same name. The Activision game is a hybrid text adventure following after Infocom Zork-likes. This one is the puzzler by Valve.

<comment><USER4> actually Activision's portal was an amazing experience because yes it's a novel but you're the main character. You're an astronaut that arrived on Earth 100 years after you left and no one is on Earth. You find a single working computer terminal. The "game" is your terminal for you to use to figure out what happened. it's pre websites so looks like 80s ideas of info but I loved it

</comment></comment></comment><comment><USER5> Here is a full playthrough: [https://www.youtube.com/watch?v=FdxjHjFXvwM](https://www.youtube.com/watch?v=FdxjHjFXvwM)

<comment><USER6> It even has a chiptune version of "Still Alive" at the end!

</comment></comment><comment><USER7> That's gorgeous. Graphics, music, cutscenes, everything is awesome. I would have played the hell out of it in 1987 (might still do, if I get free time to futz around with VICE...I have a real C64, but my flash drive adapter got killed in a tragic vacuum cleaner accident).

</comment><comment><USER8> That's why they called it Portal. Concept is portable to nearly any architecture / platform: iOS, Android, Apple II, NES, Atari 2600... Great work!

Portal Prelude for Texas Instruments Calculators

[https://www.ticalc.org/archives/files/fileinfo/451/45101.htm...](https://www.ticalc.org/archives/files/fileinfo/451/45101.html)

<comment><USER9> I was just about to comment about the TI Calculator version! Pretty cool and worth checking out as well.

</comment></comment><comment><USER10> C= 1351 mouse support! That's pretty rare (and awesome). Also great to see both PAL/NTSC supported at launch.

</comment><comment><USER11> Reminds me of this! [https://www.ticalc.org/archives/files/fileinfo/451/45101.htm...](https://www.ticalc.org/archives/files/fileinfo/451/45101.html)

It's always pretty amazing to see these "demakes" on heavily constrained platforms.

</comment><comment><USER12> A really neat concept/idea as well as execution. I'll be sure to mention it on my C64 related show tonight!

<comment><USER13> What's your show?

<comment><USER12> A small live-show on SlayRadio. It's primarily a test-bed for an experimental performance instrument I'm working on. Schedule and info is available here - www.planmixplay.com

It would probably behoove me to add - the show content is primarily playing c-64 remixes and me talking about various c64 related (and non-c64 related stuff). Recently I've finally gotten the visual output up and running so I broadcast a c-64 like output via YouTube.

<comment><USER14> This piqued my interest so I browsed your site a little bit and would like to highlight a couple of links to other people ITT.

[http://www.lasselaursen.com/interactive- interview](http://www.lasselaursen.com/interactive-interview) an interactive interview

[http://www.lasselaursen.com/project/planmixplay](http://www.lasselaursen.com/project/planmixplay) talks a bit more about PlanMixPlay and also mentions a source of inspiration that is worth checking out as well, namely [https://vimeo.com/25861552](https://vimeo.com/25861552)

<comment><USER12> codetrotter, I much appreciate you sharing links - I am particularly curious as to how you got to the interactive interview. I was pretty sure I currently don't list it anywhere on the site.

Organic google search perhaps?

<comment><USER14> Via your HN profile, on the submissions page, is where I found it :)

</comment></comment></comment></comment></comment></comment><comment> white-flame Is this a port of the Flash version that was around years ago, or an original take?

Some of the news-splashy C64 games being released are actually just ports that don't fully disclose their prior existence, and that kind of rubs me the wrong way.

</comment><comment><USER15> I can't wait to try it. BTW Linux users, I personally found that running Vice via Wine is easier than native Vice and worked great. I've been going through C64 games and rating them when I have time...99% of the good titles are great coffee break games.

<comment><USER16> Similarly for BeebEm. Though RetroPie (even on an ordinary PC) is not bad.

</comment></comment><comment><USER17> There is a portal for everything...

[https://scratch.mit.edu/projects/43690666/](https://scratch.mit.edu/projects/43690666/)

</comment><comment><USER18> This is mind-bogglingly awesome.

</comment><comment><USER19> great useless effort .....</comment>


Serialized Mystery: The Strange Case of the New Golden Gate - <AUTHOR> https://www.mercurynews.com/2020/06/07/serial-the-strange-case-of-the-new-golden-gate-chapter-1/ <comment><AUTHOR> Links to the whole series can be found at Robin Sloan's personal website:

[https://www.robinsloan.com/notes/newspaper- serial/](https://www.robinsloan.com/notes/newspaper-serial/)</comment>


OpenZFS Merged to FreeBSD - <AUTHOR> https://svnweb.freebsd.org/base?view=revision&revision=364746 <comment><USER2> It is amazing that two disparate OS communities can take a shared codebase and integrate it deeply into their structure.

There are many places where it would be almost impossible to achieve this kind of share. Witness the 'compatability library' work which exists to avoid ABI blackholes running one platforms code on another platform.

BTW I have been able to carry FreeBSD ZFS LUN on a NetAPP and mount them on Debian ZFS, and vice-versa, since I started using ZFS. What we got here is better code alignment but with qualifications, ZFS has always been a common platform (with fringing differences)

I never had illumos or Solaris, I cannot comment on how well it would have worked.

<comment><USER3> Well you're citing netapp, zfs, freeebsd and debian. Those are all top notch.

In all honesty I can't understand why would anyone use anything other than zfs nowadays for important data.

<comment><USER4> @znpy

Why people aren't just using ZFS (or BTRFS) ?

Well...

Maybe because XFS is well proven in certain critical environments, especially ones which might involve frequent manipulations of large quantities of small files (think mailserver or database). Indeed, some developers will tell you in the docs that they only support XFS or ext4 and that you're on your own if you choose something else.

Maybe because ZFS and BTRFS still have their bugs, small and big (hello RAID5 in BTRFS ;-) ) and can be heavily dependent on particular implementations.

Maybe because in a virtualised environment, you loose many of the benefits of ZFS or BTRFS (they like to see the raw disk, not some abstract notation).

Maybe because the combination of XFS/ext4 plus LVM is more than good enough for most people as that route still provides snapshots etc.

Maybe because BTRFS needs babysitting[1] (don't know about ZFS, I suspect it might).

Maybe because not everyone feels the need to "keep up with the Jonses".

[1] [https://www.youtube.com/watch?v=8YUC-r1aXAc](https://www.youtube.com/watch?v=8YUC-r1aXAc)

<comment><USER5> That you're equating ZFS and BTRFS, and tarring ZFS with the issues of BTRFS, clearly shows how much you don't know about it. ZFS was production-stable more than 10 years ago.

<comment><USER6> I think the biggest issues with using ZFS as a linux user come down to

A) ZFS-on-Linux was always behind BSD ZFS until recently.

B) The license issue, so you have to compile it as a separate module using DKMS, which means having a compiler, the linux headers, etc etc. No where near as low friction as just choosing ext4 or btrfs.

<comment><USER7> > ZFS-on-Linux was always behind BSD ZFS until recently.

FreeBSD was never really working on ZFS in a way ZOL was. Whole reason for the switch is because main contributor upstream used by FreeBSD stopped using ZFS.

ZOL had more features for a while now as well.

<comment><USER8> I think there is a reason the part you quoted was written in the past tense. The situation has changed. But these things have momentum and people might have adopted FreeBSD years ago because of the former status quo, where FreeBSD had it integrated in the default install and Linux distros did not.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> This is only peripherally related to this great news, and I apologize if this makes me a wet blanket to ask, but I figure someone here will know the answer:

I went back to read some ZFS roadmap documentation from the Before (Oracle) Times this winter, and was reminded why my outlook for ZFS was initially rosier.

I was super excited about ZFS because if and when it got the ability to add new hard drives to an existing volume, then we had something I've always wanted: a straightforward way to grow a filesystem without having to tear it down and rebuild it from scratch.

That was still listed in future enhancements, shortly before Sun started to fall apart. Does anyone know where we are on that? Did that functionality get painted into a corner by other design concerns?

It's in that category of things that I might not use that much, but family and customers could use the hell out of and it would simplify my life just knowing it exists. I feel we are all lesser for that never making it off of the drawing board.

<comment><USER10> I think it's happening soon! Been watching this for a while too... [https://github.com/openzfs/zfs/pull/8853](https://github.com/openzfs/zfs/pull/8853)

<comment><USER9> This PR has been sitting for a long time :(

</comment></comment></comment><comment><USER11> It looks like OpenZFS still has xattr support which is the one Illumos ZFS feature I always wanted on my FreeBSD systems. Hype! :D

<comment><USER12> Has the 'old' freebsd zfs not xattr too? I can see it in the options (but no tested)

zfs get all:

zroot/var/tmp xattr off temporary

<comment><USER11> It's listed in the manpage too, but as:

      xattr=off | on
      The xattr property is currently not supported on FreeBSD.

</comment></comment></comment><comment><USER13> This is very awesome. It makes replication (via zfs send) between FreeNAS and Linux better. Native encryption should also make zfs cloud replication much simpler.

</comment><comment><USER14> How come Linux has licensing issues with ZFS, but the BSDs don't?

<comment><USER15> The issues are caused by GPL, while BSD is, well, BSD licensed.

<comment><USER16> Since Linux came first (and was GPL licensed first), it's worth remembering that ZFS was intentionally made incompatible with the GPL via the "CDDL"

<comment><USER12> >ZFS was intentionally made incompatible with the GPL via the "CDDL"

That was said by one lousy youtube comment without any explanation, Ubuntu has no problems with it...and i bet they have lawyers, i think it was in that vid:

[https://www.youtube.com/watch?v=-zRN7XLCRhc](https://www.youtube.com/watch?v=-zRN7XLCRhc)

It's also crazy, nearly no distro has a problem shipping ultra-proprietary software (firmware), but has a big discussion about CDDL, no one wants ZFS in the Kernel tree, imagine Linus has control over it and has no clue was ZFS even is:

[https://linux.slashdot.org/story/20/01/19/0059251/what- linus...](https://linux.slashdot.org/story/20/01/19/0059251/what-linus- torvalds-gets-wrong-about-zfs)

<comment><USER17> > It's also crazy, nearly no distro has a problem shipping ultra-proprietary > software (firmware), but has a big discussion about CDDL,

It's the difference between "mere aggregation" and "derived work". The kernel+ZFS can be considered a derived work from both, so it has to obey both licenses (GPL2 and CDDL) at the same time; on the other hand, the firmware is completely independent from the kernel, so the licenses (GPL2 and the proprietary license) apply separately to each component.

> Ubuntu has no problems with it...and i bet they have lawyers

On the other hand, Fedora has problems with it as a kernel module (but they do ship it as a ZFS FUSE module, see [https://fedoraproject.org/wiki/ZFS](https://fedoraproject.org/wiki/ZFS)), and they do have lawyers (Red Hat's lawyers review all the licenses for Fedora, and they consider the CDDL to be incompatible with the GPL: [https://fedoraproject.org/wiki/Licensing:Main](https://fedoraproject.org/wiki/Licensing:Main)).

<comment><USER12> >The kernel+ZFS can be considered a derived work from both

What?? No why?...no one of those project is derived from each other, ZFS is a module (on all platforms i think).

>and they consider the CDDL to be incompatible with the GPL

[https://zonena.me/2019/01/the-cddl-is-not-incompatible- with-...](https://zonena.me/2019/01/the-cddl-is-not-incompatible-with-the- gpl/)

That's the important part:

>You may distribute the Executable form of the Covered Software under the terms of this License or under the terms of a license of Your choice, which may contain terms different from this License, provided that You are in compliance with the terms of this License and that the license for the Executable form does not attempt to limit or alter the recipients rights in the Source Code form from the rights set forth in this License.

>To reiterate, executable forms of CDDL source code can be under ANY license you want.

That means your compiled ZFS module package can even be under GPL2 or 3 or beerware ;)

<comment><USER17> > no one of those project is derived from each other, ZFS is a module (on all > platforms i think)

Once compiled, the ZFS module is a derived work from both the Linux kernel and ZFS.

> > You may distribute the Executable form of the Covered Software under the > terms of this License or under the terms of a license of Your choice [...] > does not attempt to limit or alter the recipients rights in the Source Code > form from the rights set forth in this License.

> That means your compiled ZFS module package can even be under GPL2 or 3 or > beerware

I trust the Red Hat lawyers on this matter more than someone who is not a lawyer (from that page: "While it's true that I am not a lawyer [...]"). And from what I understand (I'm also not a lawyer), that clause in the CDDL applies only to the compiled result; but the GPL requires that, if the compiled result is distributed as GPL, the corresponding source code also be available under the GPL. So you cannot distribute your compiled ZFS module package under GPL2 unless the corresponding source code can also be distributed under GPL2.

<comment><USER12> >Once compiled, the ZFS module is a derived work from both the Linux kernel and ZFS.

Really? So if i compile something with gcc it is a derived work from gcc and gcc is derived work from my bin? Or when i make a firefox extension it's a derived work of firefox? Compile the nvidia module...a derived work from linux?

>I trust the Red Hat lawyers on this matter more than someone who is not a lawyer

But he can read :) but hey whatever, really not interested if linux has something good like DTrace ZFS or Crossbow, they like the NIH-Syndrome and i am ok with that too.

<comment><USER17> > So if i compile something with gcc it is a derived work from gcc

Yes. This is why the "libgcc exception" ([https://www.gnu.org/licenses/gcc- exception-3.1.en.html](https://www.gnu.org/licenses/gcc- exception-3.1.en.html)) exists. The issue is that parts of runtime libraries which come with gcc are statically linked into the compiled executable; without that exception, the result would have to be under the GPL.

The same issue happens with Linux kernel modules. Many functions they need are only defined as macros or inline functions in the headers (since ZFS is a filesystem, just take a look at how many inline functions there are in include/linux/fs.h). And even outside of these, many functions are so closely coupled to the internal data structures of the kernel (and the data structures themselves are also exposed to modules) that any module using them could be considered a derived work of the kernel.

<comment><USER15> Are data structures copyrightable? The headers are not, and macros can be easily avoided.

And in any case, there's an easy way to prove something does not constitute a derived work: just show that it can work outside of the codebase it's allegedly a derived work of. The reason NVidia is safe is that they provide the same driver for FreeBSD.

<comment><USER18> Criteria for whether a work is copyrighted are a bit more nuanced and the word "header" doesn't figure in it. A work needs to be original and have creativity element in it. Code in header files can - and very often does - meet that requirement. _Some_ kind of code (whether in headers or elsewhere) can be unoriginal, but that really has nothing to do with "headers".

The parent actually explained it pretty well.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Awesome work by all parties involved in this :D

</comment><comment><USER20> ZFS still doesn't do direct IO or automatic defragmentation. It represents an early realization of a good idea, one since clipsed by other tree-based filesystems. You wouldn't fly in a Wright Flyer, so why would you run ZFS?

<comment> yjftsjthsd-h > You wouldn't fly in a Wright Flyer, so why would you run ZFS?

Because it has literally zero competitors that can even approach its feature set? Btrfs is a trash fire, bcachefs is years out, nilfs2 doesn't actually verify its checksums, ceph/gluster run largely in userspace (so you can't run them as your root fs). What fs would you like to propose that lets us do snapshots, data integrity, and compression?

<comment><USER20> In what way is btrfs a trash fire? Works fine for me.

</comment></comment></comment><comment><USER21> Quite the natural evolution since TrueNAS has traditionally been a BSD box and they've invested a lot of time in ZFS. Happy that this will carry over to FreeBSD.

Now, only if Windows would also have some sort of support ;)

<comment><USER22> [https://github.com/openzfsonwindows/ZFSin](https://github.com/openzfsonwindows/ZFSin)

</comment></comment><comment><USER23> What really worries me here is compatibility with older pools.I hope they have thought about that as freebsd implementation is here since 2007.

<comment> yjftsjthsd-h It's my understanding that ZFS is backwards compatible forever; old pools are on old versions or have fewer feature flags, but they can still be used without issue.

<comment><USER23> Yes in theory they are but currently syncing pools between linux and freebsd zfs is not possible so I would imagine there are some differences. I have around 12Tb of zraided disk space on freebsd and I hope I will be able to upgrade eventually.

<comment><USER24> Eh? I currently share a zpool between linux and freebsd, and it works fine without issue.

<comment><USER23> Thank you for the info, I wasn't aware of that, the last time I have tryed it didt work (1-2 years back)

<comment><USER25> ZFS is backwards compatible, not forwards compatible.

If you create the pool on pre-OpenZFS FreeBSD, you can use it on Linux, but not vice versa.

I just did this with FreeNAS (based on FreeBSD 11) and Raspbian.

<comment><USER22> If you leave "zpool create" to its defaults (enable every feature).

There's two levels to consider though if you create a pool with explicit consideration for a system with an older version of ZFS: "-o version" and "-d"/"-o feature@...", both of which can be used to fine tune exactly what the pool can and cannot do.

I've made a list to help out doing it between ZFS-on-Linux releases. It shouldn't be hard to look up FreeBSD feature lists and do the same: [https://chungy.keybase.pub/zfs-features- table.html](https://chungy.keybase.pub/zfs-features-table.html)

</comment></comment></comment></comment></comment></comment></comment><comment><USER26> Remember when Apple was going to adopt ZFS as Mac OS's file system?

Then... nothing further was heard about it.

</comment><comment><USER27> Zfs does not work well on sparse volumes, it loves new blocks. That's why you don't see it much in a VM or on storage that is sparse (go nimble, NetApp, etc)

Also it's pretty much impossible to grow a zfs pool and there are no consistency check tools or repair tools. So when you actually do get corruption, you lose it all.

Might have been a breakthrough around 2000 but it's time for something new.

<comment><USER25> > Also it's pretty much impossible to grow a zfs pool and there are no > consistency check tools or repair tools.

This is flat out wrong. First you can trivially grow a zpool by adding another vdev to it. If you can't do that, you can grow a vdev, and hence the zpool using that vdev, by swapping the disks for larger disks one at a time. Once all the physical disks in the vdev are of the new, larger size, the new space will become available automatically.

Also there's absolutely a consistency check and repair tool built in. ZFS computes and stores checksums for all blocks, even when you use a single disk!. It also verifies the checksums when reading blocks. In addition you can trigger a verification of all the blocks by running a scrub command, which simply issues a read for all the blocks.

> So when you actually do get corruption, you lose it all.

Hardly. Not only does ZFS have the above, it also stores multiple copies of important metadata blocks (three copies by default), and it even takes effort to spread those blocks out on the physical disks to reduce the chance of them getting corrupted as much as possible.

I'm not saying ZFS is the perfect filesystem. But it's definitely one of the better if you care about your data.

</comment></comment><comment><USER28> The fact that there are still 3 main BSDs being developed in parallel seems odd to me. I imagine that they could accomplish much more if all that effort was focused on a single OS.

<comment><USER29> The same could be said to the nth degree for Linux. In fact I think you could make the argument that the differences between the 3 most popular BSDs are way more significant than the differences between the 3 most popular Linuces

<comment><USER30> Aren't the kernels amongst the BSDs different enough that effort is split? With GNU/Linux, the variations is much more in the packaging than the kernels, no? Couldn't I download a vanilla kernel, compile it, and boot any Linux distro with it?

<comment><USER31> Well, yes/no. There are different ways to configure the kernel, and some distros/userlands require specific kernel features which may or may not be default. Your general point is still true, though.

They are different enough that some of the work is split, however there's significant code sharing in things like device drivers and the like.

Ultimately each being very different is usually seen as a positive. While the <n> Linux distros are spending significant hours optimizing essentially the same userland for minor differences in use cases, the different BSDs have very different goals and results. OpenBSD has an emphasis on making a lean and consistent base system with comprehensive documentation, NetBSD has excellent tooling for cross-compiling, and a comparatively more modular kernel that lends itself to experiments like rump-kernels. I'm less familiar with FreeBSD but it's tended to emphasize features like ZFS and its own robust container solution.

In some cases these features are contradictory, as OpenBSD would be (I imagine) very reluctant to merge NetBSD's in-kernel Lua module support, or NetBSD's multithreaded "high performance" implementation of the firewall pf, "npf", in favor of its own much simpler and more secure pf. OTOH NetBSD has a stronger emphasis on backwards compatibility which somewhat limits their ability to make broad changes to the userland as OpenBSD has. Then, one is much more likely to be able to run old NetBSD binaries on new kernels. :)

Each has its pros/cons, and attracts its own users and developers. The distinguishing thing about *BSDs is the base userland and kernel are deeply intertwined, giving each more freedom to deeply tie userland tools to special kernel functionality. There are pros and cons to this too, but this means that, for example, one can use "ifconfig" to connect to WPA2 WiFi networks on OpenBSD with no other tools required, as the ifconfig userland is always released alongside a matching kernel. The various net-util packages shipped for linux have suffered from having to operate as "external" tools interfacing with a range of kernel versions. (of course, now the situation is better with ip/iw, but it sure took long enough)</comment></comment></comment></comment>


Verizon takes a $4.6B charge on Yahoo and AOL - <AUTHOR> https://www.cnbc.com/2018/12/11/verizon-takes-4point6-billion-on-oath-media-business.html <comment><USER2> after reading the article, half of that is for voluntary layoffs? seems like worse than the market is Verizon's rush to cut costs instead of actually putting their acquisitions to work?

<comment><USER3> The "goodwill impairment charge" is a separate item from the lay-off charge. So it's north of $6 billion total so far.

<comment><USER2> back to 4. the voluntary layoffs are for verizon specific personel. nothing on the oath side.

<comment><USER3> Their SEC statement was unclear about that. It didn't call out which unit was doing the layoffs. Merely that they were "US based management employees", whatever that means. I'd assumed these were largely from Oath, but that could definitely be a bad assumption.

</comment></comment></comment></comment><comment><USER4> What does this typically mean for employees? Layoffs or no further investment ?</comment>


How to Pay Programmers Less (2016) - <AUTHOR> https://www.yegor256.com/2016/12/06/how-to-pay-programmers-less.html <comment><USER3> Dealing with a talentless narcissistic manager or a dipshit CEO? A talentless piece of hack who doesn't know anything about technology but is somehow calling the shots ?

0\. Boundary setting doesn't work with these losers because they don't respect them, so you will have to adopt devious tactics. Running away is a cowardly act. Learn how to spot them and their co-dependent friends. I would highly recommend the book Cracking the Psychopath Code and works by Sam Vaknin.

1\. Hack their computer! This way you can leverage their insecurities and exploit them. They probably have troubles at home. Just borrow their phone and install spy tools, best 50$ ever! Even better if you can hack their bank accounts and give them a headache.

2\. Always make them look good but bad mouth about them all across the board. Firing a narcissist takes time. About 2 years if you do this diligently. Take care not to badmouth it to the narcissist's allies.

3\. Adopt the narcissistic's official ideology whatever it may be. This is the most painful thing and your code will probably look stupid.

4\. Always work diligently so that you become a valuable asset to the firm and let other managers/startups know. You should become the army general that dethrones the king. They are plenty of female narcissists as well and it is highly improbable for a guy to take them down. This is one place where you might need at least one female ally to take them down if you are a guy. If you are a woman then ... all the best! Not all women are empathic monks are they?

5\. Always remember ... they don't really care about you or your friends. You are an extra in their drama.

6\. Develop a thick skin when they throw temper tantrums ... work on your submissive poker face.

7\. Narcissists are paranoid, to put it mildly, so you have to challenge them a few times truthfully so that they think you are being real with them.

8\. Read a book on dealing with pets because Narcissists respond to reward and punishment like infants and pets. Set boundaries by disguising them as compliments and appeal to their selfishness. Give the narcissist multiple options that you control.

9\. If you have done all these steps and won, congratulations you are now a Narcissist 2.0 in your firm!

<comment><USER4> Been though that once on my last job in Canada.

After 1.5 years on the job I was quite elated to promoted to "work directly under a C-level" in a quite sizeable company when I was just 25 years old.

That was in a sourcing company that works for BestBuy, Target, LondonDrugs, WM, Amazon, and other top tier retailers, delivering OEM stuff on demand for their captive brands.

The man... happened to be a totally textbook case of "pro-manager:" net worth of few millions, few cousins and brothers in similar corporate positions, black lambo, and a mistress secretary.

I quickly understood that I became the only "general" in the business that keep things going on the technology side, and that the business will not be able to keep going unless they can customise products beyond the paint job and silkscreens.

We came to an eventual animosity, and few months after the "promotion" we had an argument in his office where he tried his cheap pressure tactic, and he made me to slam the door. As I was going through the parking lot, I saw the guy running shouting "how much you want!?"

I returned to the building and had him talk it over with me not in his office, but in the middle of cubicles of the team, to everybody's amused looks.

In the end, it was the LMIA rules update that made me leave Canada and that company. Been working with in an engineering consulting company in China for nearly 3 years now, and I can't be more happy now with Canada kicking me out.

<comment><USER3> Damn .. it sucks dealing with these clowns. I will never allow these clowns to take away the joy of working with code and fellow programmers from me. That way they win!

I hope you are having a swell time working in your new gig. How is the coding culture with the Chinese folks?

<comment><USER4> I can not generalise at all. Chinese companies can be on both sides of the extreme.

But one thing is certain, there is much more natural selection involved with businesses. A factory producing low quality widgets will be evaluated incomparably more harshly by professional buyers than a customer facing brand selling them in the US.

There are bosses who learned to respect engineers, and there ones who didn't. The later keep loosing businesses, go from one master to another, until they hit the bottom, unless there is somebody who keeps bailing them, which is not rare.

I knew one dude who lost 3 businesses as an appointed director, but each time he failed, his well connected uncle was ready to refer him to then next "good friend."

In China, "the boss" is much more of a social/hereditary class than a job, much more than it is in USA. The majority of the economy is still kept by the people called "the first generation money," though they been slowly losing their dominance in the economy over decades. You can imagine, a lot of the first gen wealth were former party bosses themselves, or their relatives.

Out of that class of people, there are some good bosses who were taught by hard life experiences, and ones who weren't. I myself recommend people not to risk and try to find an employer whose boss is not coming from that social group.

</comment></comment></comment></comment><comment><USER5> > Brainwash them regularly by communicating how great your company is, how big > its mission is, and how important their contribution is.

A few year ago a friend was working as a consultant for Disneyland mentioned about how little Disneyland would pay its lowest rung employees who kept the place running. Instead the workers were fed corporate bullshit about how lucky they were to work at the "happiest place in the world."

Perhaps being educated or skilled does not reduce one's susceptibility to psychological manipulation.

<comment><USER6> _Brainwash them regularly by communicating how great your company is, how big its mission is, and how important their contribution is._

It works even better in the world of classified programs because, due to compartmentalization of information, the engineers don't know much about the overall project or what anybody else is doing. But they can always be sure their contributions are important...to management's bonuses.

<comment><USER7> As I'm practicing consulting cases right now for an MBB interview, my standard question to reducing company costs is: can we reduce labor costs by lowering their wage? Ah, they're unionized. Ok, let's look at another cost saving strategy that does not involve labor.

The first time I learned this I was shocked that this is a standard question in case practice for strategy/implementation consultants. Now I'm happy that I know this is how strategy/implementation consultants think. It kind of feels like learning to defend against economic exploits by coming up with them yourself (a similar thing occurs with security when one learns ethical hacking).

<comment><USER8> I remember reading about one large consulting form whose answer was always "lay off 25% of your staff" regardless of what the question was.

Of course, companies would have to pay a huge amount to get that answer - <USER2> it was always the same answer.

This was from the book "Rip-Off":

[https://www.leadershipreview.net/business-management- consult...](https://www.leadershipreview.net/business-management-consultancy- rip)

</comment></comment></comment></comment><comment><USER9> Another good trick is to pass blame diffusely upwards. If you believe that your boss is fighting as hard as he can do get you the raise he 'wants' to give you, but the powers that be above him is blocking it, then you'll be far more accepting of the fact that you didn't actually get that raise. Hell your boss might even be 100% genuine in his desire to get you that raise, that's even better.

</comment><comment><USER10> If I remember correctly, the advice to give raises randomly also appeared in a serious, non-ironic "How to become a CEO" book [1].

There, it was positioned as a way to make subordinates work harder and make them more loyal - people were assumed to react to fuzzy, random bonuses and raises better than to a linear relationship between results and pay.

[1] [https://www.amazon.com/How-Become-CEO-Rising- Organization/dp...](https://www.amazon.com/How-Become-CEO-Rising- Organization/dp/0786864370)

<comment><USER11> Ah yes, from the famous executive consultant BF Skinner ...

Other famous executive consultants: Pavlov, Milgram, Zimbardo, Mengele, Torequemada, Machiavelli, Sade ...

</comment></comment><comment><USER12> Don't forget free lunches. $10 bucks for an extra hour of productivity.

<comment><USER13> Yeah. 12 months in to a job there was a big push to move to the cloud, all devs go on 24/7 mandatory support. You would be required for a week to be on call, rotating in your team, so every 3-4 weeks depending on devs in the team.

For this you where required to always have internet access, return a phone call within 10mins to acknowledge a issue then be investigating within 20-30 mins. This means for 7 days if you wanted to drink you could not, you could not travel to a place without phone signal, you always had to have a laptop and phone on you. Essentially your personal time was not personal time, you are severely inconvenienced and for 168hrs you where essentially at work. For this you got 200AUD extra in your pay packet minus tax. It was non negotiable, this was no small company but at the time a recently IPO'd company with a shit load of cash. If you look at it as 168 hours for the week on call due to loss of personal time it's a massive pay cut. I would of come out significantly ahead working minimum wage for just the sat/sun and loose less personal time.

Discussing it with my managers how I did not want to loose personal time and was happy to do it for free on a best attempt I'll answer a call if I get it and available vs being absolutely available and accountable resulted in "but you get free lunches here, take it for the team", the perks where used as leverage. As you said the cost of lunches to the company was peanuts, worse than that I had special dietary needs so never utilised it.

Didn't stay long after that

<comment><USER14> Pretending to be naive can be useful from time to time.

"I'm sorry, I have dietary restrictions that prevents me from enjoying the free lunch. It would be a great bonus if I was able. How about this you forgo the large cost of the free lunch and instead pay me the minor amount of overtime for the rare times I'm called out." (they always present that you will rarely be required to fix something off hours, call that bluff)

The only directions they can go is "Well that will cost more than the free lunch" or "we demand it" so either you win the argument by having them make your point for you or you will have a nice casus belli to find a new job.

</comment></comment></comment><comment><USER15> "They must keep this information secret. Warn them or even sign NDAs prohibiting any talks about wages, bonuses, compensation plans, etc"

That's directly illegal, at least in Denmark, so I assume in the rest of the civilized works as well.

<comment><USER16> I think I remember my previous employment contract here in Germany stating that talking about salary was a fireable offense. Can't remember anything similar in Sweden. Just some datapoints.

<comment><USER9> Salary in Sweden is publicly available information.

</comment></comment></comment><comment><USER4> I think what is forgotten is: _make programmers work less!_

And I can't stress this enough, just how much work in both "dotcom type" companies and corporate IT goes completely to waste.

N out of 10 software features some smart "requirements manager" manager, or an artsy type "product manager" make up usually end up as ballast.

I'm saying that to highlight that the prime majority of companies spending pennies on devs are almost as a rule pathologically inefficient, and that is the root of their problems.

I think there is a wrong image of tech companies among the rentier types as a maintenance free cash cows, and that they can pick a well performing companies, fire all devs, but the "maintenance crew" and secure their retirement in a few years. My own experience with that is a complete opposite:

Companies with well selling tech products only do so for as long as they give good support, and keep money burning on marketing. The moment the rentier type buys the company, and cuts both new developments (which in reality usually are support, and bugfixes) and marketing, they really destroy the only things that were keeping the business going.

</comment><comment><USER17> My urge to put this in our slack "general discussion" group is huge.

<comment><USER18> Do it during the friday happy hour, and then blame the free drinks

</comment></comment><comment><USER19> This is very true. I've worked for several employers like this. Usually it's better to quit but sometimes it's still worth staying because some jobs can open up more opportunities. In these situations, the best you can do is build leverage by creating direct relationships with stakeholders (e.g. clients and investors).

<comment><USER20> The whole of the Scrum methodology - funnelling all access to users via the "product owner" - is explicitly designed to disempower both end users and developers and concentrate power with the project managers and other managers. That's why it's so popular.

Even better some developers have even been brainwashed into thinking Scrum is for their benefit!

<comment><USER21> It's just what businesses are familiar with and, frankly, what works. Before scrum you've had system analysts writing requirements and use cases, now you have product owner writing stories.

Engineers have so much on their plate fighting the actual code that making them talk to users (who don't know what they want half of the time or are involved in some sort political battles themselves) is just putting too much on their plate IMO. Maybe this could work in a smaller organisation with a fairly straightforward business, but in any place old and large, there's usually so many stakeholders involved (usually playing poor man's game of thrones amongst themselves) and so much random conflicting bullshit (in the requirements etc.) that any sane developer would be happy to just be oblivious to that.

<comment><USER20> I disagree, based on my experience in both small and large organisations, nothing at all beats a developer spending a half-day or a day sitting with an end user saying "show me what you are doing, or trying to do". And making copious notes then going away and programming it.

Very few organisations are willing to work like this because nearly all project- and middle-management would be out of jobs. The management class will always strive to protect itself and its members from the workers (both end- users and devs).

<comment><USER21> I agree that it can work in cases where the business is actually well organized and knows what they want. However, what I've often seen is that nobody pretty much knows anything and/or they're afraid to make a decision and hence you need a product manager to go around various business units, arrange workshops etc. and try to pound out some definitive statements out of the business guys. This is super common on large multi-million (or billion) projects which are supposed to transform the whole org in some way. On the other hand, if the project is just for one business unit and they're the one driving it, then maybe product owner is less needed.

<comment><USER20> Surprisingly often they do know what they want, even if they can't articulate it they can demonstrate it.

The spec only becomes inane gobbledygook when filtered through a PM who doesn't understand it but rewrites it in business-speak anyway, or an "architect" who also doesn't understand it but thinks it needs to be a grand, generic solution.

</comment></comment></comment></comment></comment></comment><comment><USER22> Additionally when they treat managers as other engineers - meaning that they want to discuss changes or improvements without judging others for their ideas - just decide for them and announce your decision to show who is in charge.

<comment><USER8> "just decide for them and announce your decision to show who is in charge."

That reminds me of a conversation I had with a CEO once when I was a VP Engineering:

Me: "I think we have the scope of the new version pretty well understood by everyone and things are looking good for delivering on time"

CEO "I know for a fact that you don't understand the scope"

Me: "<confused>Pretty sure I do"

CEO: "Well I've decided as things are going so well we can add a few additional features"

Me: "Arghhhh..."

NB This was a while ago - my rookie mistake was having everything under control and everyone working calmly and productively and letting the CEO know, whereas the CEO favoured the "everyone must be near to panicking at all times" school of management.

Edit: Of course the features he mentioned were daft and were never implemented - he wasn't actually interested in them, just in unsettling me <sigh>

</comment></comment><comment><USER23> Joshua Fluke just released this video:

[https://www.youtube.com/watch?v=1nyHRcI5Fto](https://www.youtube.com/watch?v=1nyHRcI5Fto)

Which I thought was pretty funny and straight down this alley.

</comment><comment><USER24> >Warn them or even sign NDAs prohibiting any talks about wages, bonuses, compensation plans, etc.

Isn't this actually illegal?

<comment><USER25> might depend on the state but for sure illegal in most. At the same time, I've never heard of it being litigated, ever. Usually the people told not to talk about their salaries are making the most.

<comment><USER26> "Usually the people told not to talk about their salaries are making the most."

Oh buddy, I hope you didn't fall for that one.

<comment><USER25> it's a battle of wits for sure :)

[https://www.youtube.com/watch?v=3EkBuKQEkio](https://www.youtube.com/watch?v=3EkBuKQEkio)

</comment></comment></comment></comment><comment><USER27> Previous discussion (2016): [https://news.ycombinator.com/item?id=13120114](https://news.ycombinator.com/item?id=13120114)

</comment><comment><USER28> This has got to be satire. There's no other way any sane person could really mean this. I took it all as comedy.

<comment><USER20> These are all real things that happen in real companies.

</comment></comment><comment><USER29> This is uncomfortably close to how those with a narcissistic personality disorder psychologically abuse and control their victims. I maybe should rethink my life. :-(</comment>


Is the IoT Just Too Expensive? - <AUTHOR> https://medium.com/@patburns/is-the-iot-just-too-expensive-a621e18654fb#.hap1fkxmp <comment><USER2> Is there any reason to trust any IoT device? There seems to be an inherent conflict between making them astoundingly cheap so they become sensor-dust versus how much authentication and authorization they can be endowed with so your washing machine doesn't order multiple cases of the most expensive laundry detergent because the microwave decided that was the right thing to do.</comment>


Browser-Side Amazon S3 Uploads, Using CORS and JavaScript - <AUTHOR> http://bencoe.tumblr.com/post/30685403088/browser-side-amazon-s3-uploads-using-cors With CORS you can now easily build web applications that use JavaScript and HTML5 to interact with resources in Amazon S3, enabling you to implement HTML5 drag and drop uploads to Amazon S3, show upload progress, or update content. <comment><USER2> Just finished building a drag and drop uploader feature for <http://commando.io>. I went back and forth between storing files in S3, on disk, or using database backed storage. Unfortunately CORS was not released yet, because if it was, I would have gone with S3.

I went MongoDB + GridFS. It has worked out well so far. Really like that I can store the meta-data right with the binary data in MongoDB, and can query and filter directly on the meta-data. Also, using a MongoDB replica set, I get automatic redundancy of files.

I made a quick demo video of the upload feature showing drag & drop, and the files interface, check it out if you please: <http://www.youtube.com/watch?v=ru7YZ2E65YU>

</comment><comment><USER3> I put together a FileAPI based uploader using signed PUTs. I hadn't gotten around to releasing it yet but here is a gist for those who might be interested: <https://gist.github.com/3593744>

</comment><comment><AUTHOR> With CORS, you can now easily build web applications that use JavaScript and HTML5 to interact with resources in Amazon S3, enabling you to implement HTML5 drag and drop uploads to Amazon S3, show upload progress, or update content

<comment><USER4> With CORS in place, is it a good idea to uploading images (or for that matter HTML) directly to S3 instead of the file system, say if you are building a CMS?

<comment><USER5> The only issue with images is where you would want the image to be processed (resized for example), before being published, as S3 quite rightly doesn't carry out that sort of function. Using a 2000x2000 image as a thumbnail is not a great idea.

<comment><USER6> I've been thinking about this as I need to implement it soon. I think I'm going to send to S3 then just send a message to a worker to grab it an resize it in the background. My workers are on different VMs so I need some sort of shared storage. That said I've also considered stuffing the image into redis but that seems gross even though my image volume is low.

The other benefit I see in going straight to S3 is that I can use the S3 URL to display the image to the user in context immediately after upload even though it hasn't been resized. The worker can just update the image URL when its done with its resizing.

</comment></comment></comment></comment><comment><USER7> Good walk through.

How safe is it against abuse [i.e. MITM, dos]? Most probably I am missing smth, but if credentials are applied in browser, can user get hold of them and upload a couple of petabytes?

<comment><AUTHOR> On an upload-by-upload basis, you create a signed manifest. This dictates what actions can be taken on an S3 bucket, e.g., the key that can be written to, the size of the files that can be uploaded. This can be used to protect against a DDoS attack.

</comment></comment><comment><USER8> Any ideas whether this applies to CloudFront as well?

<comment><USER8> (It seems it does, I've later learned)

</comment></comment><comment><USER9> How is cross-browser support? I hear IE8 and 9 still don't fully support CORS...

<comment><AUTHOR> Here's a chart of the browsers that support CORS:

<http://caniuse.com/cors>

Definitely a bit spotty. It's good for my use-case, which is Firefox, and Chrome, extension development.

</comment></comment><comment><USER10> nice write-up.

> "choose the S3 option from your EC2 Management Console."

do you mean AWS Management Console?

<comment><AUTHOR> Yes, thanks for the heads up. I've corrected the typo.</comment></comment>


Microsoft Japan's 4-day workweek experiment sees productivity jump 40% - <AUTHOR> https://www.cnbc.com/2019/11/04/microsoft-japan-4-day-work-week-experiment-sees-productivity-jump-40percent.html <comment><USER2> Heavily discussed twice at time of announcement nearly 2 months ago (note this article is from early Nov):

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

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

</comment><comment><USER3> Maybe the headline should reflect this gem:

> That boon was thanks in part, Microsoft said, to meetings capped at 30 > minutes and an increase in remote conferences.

From my past experiences in megacorps, there are so many meetings it sometimes feels like that's all you're doing.

<comment><USER4> Unless it's some sort of C level meeting with tje board on quarterly basis, I seen no reason why any internal meeting should be more than half an hour long.

<comment><USER3> I agree. Sadly not every manager got that memo.

My brief time at $megacorp taught me to recognize when a meeting turns into unproductive bullshitting, at which point I just walk away and go back to work. YMMV.

</comment></comment></comment><comment><USER5> From what I've heard from the previous reporting, they were tracking the performance by the sales revenue by employee. The sales numbers for MSFT are mostly recurring revenue, and the +40% productivity jump may be a result of seasons in their subscription renewals.

<comment><USER6> The 40% figure definitely needs more context. What was the average increase in sales the prior 6 months? And did it decrease back to normal after the experiment was over?

And a single month of sales increase might be due to timing in sales cycles. Maybe the prior month there was a lot more overtime than usual, and there were a lot more leads this month, and prospects further in the sales cycle.

I am all for a 4 day work week but this experiment is lacking a bit.

</comment></comment><comment><USER7> If I was in that experiment I would work harder during that 80% just to prove that 80% time is more productive.

</comment><comment><USER8> > Meanwhile, the firm saw a fall in costs, with 23.1% less electricity used > and 58.7% fewer pages printed over the period.

The 23.1% figure makes intuitive sense; the 58.7% figure seems astronomical. Why would employees being out 1/5 days lead to fewer than half the number of pages being printed?

<comment><USER9> They're probably being forced into using email more because people will not all have the same free day so handing printed memo's and attached documents doesn't really work.

<comment><USER10> That does make sense and the only comparison I'm aware of would be a remote worker who you are just not going to start sending printed pages or faxes etc compared to digital forms, and in those case will often see closer to 100% reduction (alas some things need physical signatures).

<comment><USER9> I'm speaking from experience in UK/Sweden vs what I see in The Netherlands.

In some of the large organizations I've worked at it was the culture to distribute anything "official" \- draft documents, meeting notes, presentations for meetings etc - in printed forms to a surprisingly large number of people.

Since I moved to mainland Europe - where a four-day working week is very much the norm for people with kids in high skill jobs - I have yet to encounter this practice.

Technology might also be playing a roll here, but large organizations have this tendency to fight any kind of change tooth and nail, it only seems to happen when it is forced.

</comment></comment></comment></comment><comment><USER11> Did they check for the Hawthorne Effect? [https://en.wikipedia.org/wiki/Hawthorne_effect](https://en.wikipedia.org/wiki/Hawthorne_effect)

Almost any change you make when combined with extra observation will increase productivity for a short time.

</comment><comment><USER12> MSFT won't adopt it even in this office alone, not talking about the worldwide offices...nuff said

</comment><comment><USER13> It certainly would be nice to see things move on from a standard established at a car manufacturer nearly a hundred years ago. However, it's a well-known result that almost every study of a change in an office finds an increase in productivity. Essentially, it's believed that any change temporarily increases motivation. (I can't find citations right now, sorry.)

</comment><comment><USER14> Medium size and big companies have workplace rules and policies directed to managing the worst 10 - 20 percent of the workforce. They apply to everyone because you must be fair.

Surprising number of people just need more rest (mental health is big issue) and start thriving when you cut their hours.

</comment><comment><USER15> some good/top places at Silicon Valley make one day, Wednesday typically, a WFH and that is pretty close to 4-day week and may be even better as it allows to experience the "collaborative" environment of modern office plan in bite- size 2-day chunks instead of tiresome 4 days in a row thus being much more easier and less stressful which almost directly translates into productivity.

<comment> Fire-Dragon-DoL Working from home is not really "close to not working", that's really bad to say for all remote workers

</comment></comment><comment><USER16> of course, because they're now working 44 hours per week, instead of 55

/obligatory joke about perceived "salaryman's" work hours in Japan

<comment><USER17> For real, is the circumstance really like this even for foreign companies in Japan?

</comment></comment><comment><USER18> Hey, Silicon Valley techno-utopian startups always trying to think different when it comes to new wacky incentives to lure in talent: why not consider adopting this?

At the very least, could it be feasible in a small organization to stagger it so that some people work M-Th, and the others T-F, so there's partial coverage for all days of the week?

<comment><USER19> It's highly dependent on the actual work and the productivity claims here are unclear. There's plenty of evidence that truly creative/productive time per day is limited and that more but shorter days might be a better trade off then fewer long days. Then again it all gets muddied when full-time hours aren't actually tracked and certain cultures like Japan where excessive overtime is normal.

<comment><USER20> We looked at both solutions, shorter days of lets say 6 hours or less days. For me personally fewer days is better, because I have a pretty long ride to work, so working a day less also removes two long travels.

Also in my opinion no solution reducing the amount of working hours should have disadvantages over the conventional 5 days / 40 hours weeks, or there will be no produtivity / motivation gain. So just saying we still work 40 hours but do this on 4 days a week is obviously bad. Also working 32 hours and being paid less is bad and so on...

Something else that had a huge impact for me, is that our working hours are much more flexible now. We have four so called "core hours" from 10 in the morning to 15 in the afternoon where everyone has to be in the office, the rest is flexible. So you are allowed to work 7 hours one day and 9 the next day. Also you can include two one hour pauses as long as the minimum amount per week is not lower than 32 hours. For me this is great because it allows me to drive to work and from work when the traffic on the streets is much lower than at peak times where all the other workers commute.</comment></comment></comment>


JsDelivr - Free CDN for javascript and jQuery plugins - <AUTHOR> http://www.jsdelivr.com/ <comment><USER2> Seems odd/good that so many CDNs are popping up for JavaScript. I stumbled across this one recently (<http://www.cdnjs.com/>) along with the ones provided by stalwarts like Google and Microsoft.</comment>


Welcome to Microsoft To-Do - <AUTHOR> https://todo.microsoft.com/en-gb <comment><USER2> I'm not sure why you linked to this, but it like most to-do apps is far too simple. If I have a to-do to load my laundry, why can't it trigger a timer to remind me in 30 minutes to switch to the dryer, and then once that's marked as done another timer to take it out of the dryer?

So many to-do apps, I don't think one has solid conditional tasks or robust scheduling (repeat on 1st Monday after 60 days has passed, etc).

<comment><USER3> Todoist is the "closest" I could get to what you are describing, but frankly it is NOT even close,

</comment></comment><comment><USER4> I've been using Microsoft To-Do since the earliest pre-release versions. It's…ok. It's by the folks behind Wunderlist, which Microsoft bought, but it's lacking some power user features that made Wunderlist stand out.

I'm actually thinking of going back to a paper planner. It's a lot easier to grab a pen and add something to a list than type it into a todo list, set a reminder time, etc.

</comment><comment><USER5> There are so many To-Do applications/services/features out there. I guess I'm not surprised by MS breaking into the scene, but I have to ask the age old question. How many engineers at MS are just standing around where they can waste time on products like these which probably won't be around in two years time.

<comment><USER6> This To-Do application started as an acquisition by Microsoft (was formerly Wunderlist), and is a part of Microsoft's ongoing work to modernize their Personal Information Management (PIM) ecosystem [read: Outlook] for "mobile first" by acquiring interesting sub-components (the modern Windows Mail and Windows Calendar were both begun as acquisitions as well).

It interoperates with Exchange's Task items and is expected to be Office 365 "blessed" soon enough.

</comment></comment><comment><USER7> The introductory video says the app will "intelligently prioritize" your tasks for you... that sounds like a very frustrating feature to have as a user.

</comment><comment><USER8> Either I am missing something hidden in plain sight or or maybe deep design knowledge is required to understand why Microsoft killed (is going to kill) an excellent Todo app and to replace it wrote another app, clearly inferior, from scratch which turned out to be "okay" at best.

I mean they could rebranded the app if they did have to call it Microsoft To- Do; and maybe changed the colours and all.

</comment><comment><USER9> This should just be a part of Windows like Reminders is for macOS... We already have Microsoft accounts; it seems a bit disconnected from users to not just include something like this.

<comment><USER6> I wouldn't be surprised if it does get a default install in Windows 10 eventually, similar to its relatives Mail and Calendar.

</comment></comment><comment><USER10> Where's the API?</comment>