Show HN: ML data annotations and tagging made easy - <AUTHOR> https://dataturks.com/datalicious.php <comment><USER2> What's your policy on data ownership once the data (and annotations) have been sent to you? Do you reserve the right to keep and use the data that's sent to you? Your privacy policy page only talks about personally identifying information, not usage rights.

<comment><AUTHOR> Hi thanks for the comment and thanks for SpaCy, have used it a few times and found it really powerful.

Also what you are doing with prodi.gy is also pretty interesting with active learning and stuff.

W.r.t privacy policy the data is owned by the users and he can delete it as he sees fit. We will never access it.

<comment><USER2> Thanks!

Yeah the active learning is one reason we made it a downloadable tool. We couldn't figure out how to make that work well as a SaaS.

That said, there's definitely advantages to the SaaS design too, so I think the products take different shapes. It's good to see more tools in this space, and your free usage for open data plan should be really useful for researchers.

<comment><USER3> Could you elaborate on the reasons you didn't go SaaS? Were there other reasons besides technical configurability and sheer scale of data?

To provide a little context, we're currently building an annotation tool that will be accessible by clients and seriously considered prodigy. I'm curious to know what pitfalls we may not be anticipating with that model.

P.S. Your work on SpaCy is nothing short of awesome. Thanks you.

<comment><USER2> Well, a major consideration is that uploading data to a third party is a huge barrier. Imagine you want to work on internal messages between your users, or support tickets, or emails within your company. Because spaCy is open-source, we already had a lot of users where data privacy was a 100% non-negotiable requirement. There are already a lot of people doing cloud stuff, so it made a lot of sense for us to think about self-hosted tools.

We also had a slightly different idea about what makes annotation or data collection "hard" or painful.

If you start back at a business or product need, you first have to sketch out how you're going to structure your solution before you can start annotating the data. For instance, you might need to decide whether to do sentence classification, or tag spans of text, or recognize structured relations. You need to figure out how to select which texts to annotate, or which parts. Maybe your documents are long, and it's efficient to annotate only the start of the document. Maybe the information is rare, and a lot of effort should go into getting the right filtering process before you annotate your text.

These types of considerations are really basic -- they arise on every new thing you do. You can develop better or worse intuitions, but in the end you have to make a bunch of decisions, and making them blindly is really inefficient.

Prodigy addresses this by letting a single developer quickly iterate on trying out different ideas. You can filter the stream of examples however you like, plug together the components in different ways, and build complicated pipelines. You might start by selecting examples for entity annotation by keyword, but then decide your keywords suck, so you build a text classifier to select the examples. Then you might apply a sentence-based classifier to all examples of a given entity type, to identify the presence of some relation. This pipeline of three models is very quick to build once you know you need to build it --- and Prodigy helps you figure out whether an approach is working within a couple of hours.

We could have given developers all of these pieces as REST endpoints...But that would give you a really miserable workflow. If what we're trying to give you is a bunch of functions you can compose in different ways, we should just let you program.

In short, we think the big problems with ML/data science/AI are that the technologies are so unpredictable. If you're at a point where you know exactly the inputs and outputs of all your models, and you just need to 10x your data set, you've really almost won already --- you're at the happy state of knowing you can turn $ into %. That's a great problem to have, because it's not the _big_ problem. The big problem is the unpredictability.

The best solution to unpredictability is rapid iteration, and to do that we need to give data scientists the tools to figure out which supervised approaches seem most promising. And if developers are working with a bunch of composable pieces themselves, it may as well be a library. Making it a SaaS just makes the product worse.

</comment></comment></comment></comment></comment><comment><USER4> This appears to be inspired by Amazon's MTurk, which data people typically use for manual data labelling; as a result, you may want to change the name.

CrowdFlower ([https://www.crowdflower.com](https://www.crowdflower.com)) is also a very large company in this space already.

<comment><AUTHOR> Yeah even we think of it as your personal MTurk. You can do the annotation with your team/network and not have to depend on crowdsourcing it.

Don't you think in that context the name is kinda appropriate?

<comment><USER4> Amazon's trademark lawyers may see that differently.

<comment><USER5> "Mechanical Turk" is an 18th century fake chess machine.

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

<comment><USER6> Trademarks are scoped within vertical/business sector/industry.

</comment></comment></comment></comment></comment><comment><USER7> There's also a recent Prodigy by the same folks who make SpaCy - [https://prodi.gy](https://prodi.gy) (disclaimer: I'm not affiliated, but participated in their beta).

<comment><AUTHOR> Yeah that's true, the above commenter _syllogism_ is the founder of Spacy I guess. Similar tool but for a different purpose.

</comment></comment><comment><USER8> This seems like a copycat product [https://prodi.gy/](https://prodi.gy/) I would use this product because they are actual AI people who will help you customize your product for your use case.

</comment><comment><USER9> Biggest usecase for me will be to create golden data set to create some hold- out set to iterate algorithm on.

<comment><AUTHOR> That certainly is one use case. Even for an auto-generated training data it is almost always the case to have some noise in the data and taking out the golden set from that is rarely an option, we always need to do some manual tagging and cleaning. Thanks for the feedback.</comment></comment>


Show HN: Aggregate Functions in FaunaDB - <AUTHOR> https://fauna.com/blog/advanced-string-aggregate-functions-in-fql <comment><USER2> Hi there! I'm Lewis, a PM at Fauna.

We built new Fauna Query Language capabilities which allow users to write more concise and powerful FQL statements. Specifically we've released aggregate functions for sets (Count, Mean, Sum); string predicate functions (StartsWith, EndsWith, ContainsStr, ContainsStrRegex, RegexEscape); a MoveDatabase function; and a Now function.

In short: our users now have access to powerful regex and aggregate functionality. These functions are in Preview! Please let me know what you think so that we can incorporate feedback into the formal release, and visit our documentation to learn more :)</comment>


From Oxford to Wall Street - <AUTHOR> http://www.washingtonpost.com/wp-dyn/content/article/2009/11/20/AR2009112003374.html

<comment><USER2> This is disastrous for any civilization...

And an unfortunate consequence of neglecting excessive power concentration.

Some value may be seen also in taking an anthropological approach!

In my recent brief post on this issue, "Compensation & the Social Network" [http://culturalengineer.blogspot.com/2009/10/compensation- so...](http://culturalengineer.blogspot.com/2009/10/compensation-social- network.html) , I point out that the competition for status and wealth takes place WITHIN the individual's social network and NOT WITHIN the social organism as a whole. (plumbers compare themselves to other tradesmen while CEO's compare themselves to other CEO's).

The import of this for the social contract resides in the stresses created where social networks become isolated over time (oligarchy) creating an "Ultimatum Game" situation for those individuals and especially social networks that perceive themselves as no longer a party to that social contract (with consequences ranging from regime changes to revolutions and/or civil decay).

This is why there is a point at which wealth division becomes a direct threat to the social contract. This "point" will vary depending on many factors... but at our current stage in cultural evolution there is nothing more important here than the role of ICT (Information and Communication Technology) and what David Brin calls a "Moore's Law of Cultural Change".

This tension between the social network and the social organism extends back to the birth of agriculture... but things are moving quite rapidly now.

For a few thoughts on this (and at least what may be a framework for an approach to solutions) I hope you'll see my post "How would hunter-gatherers rule the world? (Pssst... They do!)" [http://culturalengineer.blogspot.com/2009/11/how-would- hunte...](http://culturalengineer.blogspot.com/2009/11/how-would-hunter- gatherers-run-world.html)</comment>


Deflation is coming to the UK  (2015) - <AUTHOR> http://www.telegraph.co.uk/finance/economics/11340538/Deflation-is-coming-to-the-UK-and-it-will-have-a-huge-impact-on-business.html <comment><USER2> What has this got to do with anything?</comment>


How to Make Remote a Success - <AUTHOR> https://www.bearer.sh/blog/how-to-make-remote-a-success <comment><USER3> I'm totally convinced that video & voice communication –not only chat/text personas– is what will allow any remote organization to be successful, by bringing their teams together, improving culture, team spirit, their sense of belonging and ultimately having more productive and happier teams.

Sync/real-time communication is not needed for all the processes in a remote team, and you should go async by default and only use sync for cases where you _really_ have to get together. This is how companies Gitlab [1] have really become successful in doing remote work.

A remote team can be successful by using async/non-real-time communication, especially when you're pairing it with an async platform like Standups which is built from the ground up to support the async comm style. I wrote a blog article about how async is determinant to make remote work "work" within your team/org [2].

[1] [https://about.gitlab.com/handbook/communication/](https://about.gitlab.com/handbook/communication/)

[2] [https://standups.io/blog/how-async-communication-can-help- yo...](https://standups.io/blog/how-async-communication-can-help-your-team/)

<comment><USER4> And a lot of people probably undervalue video specifically. I was probably one of them but I've had a manager who insisted on camera-on for both group and 1:1 calls unless you were in some environment where you couldn't for bandwidth or other reasons. It really does make people more engaged.

<comment><USER5> I'm a remote dev for 5 years now and I have to say, most of the time synchronous communication didn't help much in terms of engagement. Good projects helped, a reason to do stuff (besides getting paid) helped, nice co- workers and managers helped.

Often synchronous communication is applied by managers because they lost control of their team and now try to monitor them closer so they don't step out of line.

It's like working overtime to compensate for bad planning or dropping home- office work all together because the company does bad.

I'm not saying 1:1 video isn't needed for some situations, but every day and even every week is often overkill. The best projects I had only required 1:1 videos every few months, most of them even only at the beginning.

<comment><USER6> This seems like a personality thing and reflects the type of culture company leaders want to create. Every other comment in this thread is "I don't like video, not conducive to how I think/work" or "I like video, makes me feel engaged and part of a team". My bet is this is not a better/worse thing but more of a mars/venus thing (I'm definitely, as someone on a remote team myself, in the video camp).

The other strange thing you hear a lot is that any attempt to get people to be on-site or on-video (basically anything other than fully async, text only) is attributed to control-freak tendencies by terrible managers. Again going back to my above point and the fact that so many people here agree that video is better for them, I wish we could dispense with speculatively attributing motives so negatively and give people the benefit of the doubt that, right or wrong, they hold their POV because it is what they actually believe is best.

<comment><USER5> Yes, probably.

Guess, I'm seeing it like that, because I worked with control freaks.

</comment></comment></comment></comment></comment><comment><USER7> Good points but I think you missed one of the biggest ones. Hire people who want and can work remotely.

Some folks aren't wired for the self-discipline or don't enjoy the isolation of remote work. They thrive in an office where they can interact face to face with their co-workers and have their manager looking over their shoulder. And that's fine. There's nothing wrong with that. But don't hire them for your remote-only business and expect them to be happy and productive.

<comment><USER8> At GitLab we translated this this requirement to 'manager of one'. It is a term introduced by Basecamp that means every person has to be able to manage themselves.

<comment><USER9> I can identify with that. The more autonomy I have the more I get done. I am happy to collaborate with others but I don't need nor want a manager to tell me what to do.

At my current job there is a trend to more and more planning, prioritizing and scheduling. I understand there is a need for that but personally I perform best if I get a big goal and can figure it out for myself.

</comment></comment></comment><comment><USER10> Most of these bullet points are just as important for in-office teams. Enforcing good meeting discipline, sending out weekly updates, defining process for RFCs, and documenting process and culture in a shared location are all very important regardless of where employees are located. Remote work only works if the team's foundation is solid in the first place.

The point about forcing everyone to be remote is great if you can make it work, but it will eliminate a lot of employees who can't work remotely. I know remote work is a hot topic, but in my experience only a small fraction of employees can be very effective in remote-only roles.

If your company can't be all-remote, it's critical to invest in proper processes and culture to keep everyone included. Quashing in-office politics, breaking knowledge silos, and mandating centralized documentation of decisions is key.

<comment><USER4> >The point about forcing everyone to be remote is great if you can make it work, but it will eliminate a lot of employees who can't work remotely. I know remote work is a hot topic, but in my experience only a small fraction of employees can be very effective in remote-only roles.

It's both effectiveness and preferences. I was just having this conversation a couple of days ago with someone whose company location is basically out of space. I asked why more people don't just work remotely. (Many already do; the company is generally remote friendly.)

His response was basically that there are a lot of employees, especially younger ones, who would probably up and quit if they were told they had to work out of their homes. Most of the people who haven't already gone remote either have to be in the same office or want to for whatever reason; this is in an area where housing is fairly reasonable and commutes are fairly modest.

Leaving aside that I started work at a time when communication tools were much more limiting than today, I still can't really imagine working from my apartment during the early years of my career.

<comment><USER11> It's been my experience that mixed remote/onsite doesn't work. Either go all- remote or all-onsite. I've even been in an org once that was mixed remote/onsite and very friendly towards remote and decided to end that policy, which resulted in all remote staff walking away from the company. That's a very tough and painful thing to have happen.

Among the remote-only companies that I've been in, I've never seen the remote- culture as being in any way problematic. (Quite the contrary. They were usually better at communicating).

<comment><USER4> >Either go all-remote or all-onsite.

The thing is that, in many cases, there is no "all-onsite" especially for larger organizations.

Your field people (sales, system engineers, etc.) are going to be wherever your customers are.

Acquire a company in a different city? If you force everyone to move, you're probably going to lose a lot of the value of that company?

Work with open source software? Many of the upstream developers are going to be scattered all over the world in any case.

And as soon as you're in multiple locations even within a given city, you're really not much different from being in two separate cities at that point.

Certainly, there are challenges. But I'm in a very mixed environment, which I think generally works pretty well.

<comment><USER11> ...well the scope of each team for which this "all-on-site or all-remote" principle holds is debatable (i.e. if we're speaking of a project team, department, set of people working on a given product or module within a system, etc). But the principle, I think, is still a valid one.

<comment><USER4> The real problem tends to be when you have a few outliers. Say, a 10+ person team where everyone is next to each other and are all in the office most days except for one or two who are fully remote. That can be a problem. It can also be made to work. But everyone needs to work at it and be committed to it.

To be honest, the situations where I have personal experience are mostly more senior teams where everyone is doing a lot of travel anyway, a decent percentage are fully remote and the rest are often only in the office a few days a week. And everyone is doing as much communication (if not more) with other teams and people outside the organization as they are internally anyway.

</comment></comment></comment></comment></comment></comment><comment><USER12> Just a personal story; but I think remote work can only work if the entire team (or at least the majority of the team) is remote. I'm currently the only remote person in the team, and it's so frustrating. For them, getting me involved in anything is an extra step, as to them I'm the only remote person. But for me, everyone is remote, and I have a lot more expectations about communication and meetings.

Just to name one thing; meetings that start 5-10 minutes late. For them it's normal, because they're in the room, or walking to the room, or at least aware as to why a meeting is starting late. To me, it's 15 minutes wasted, and there's no communication what's going on.

We're getting better at it tho; or at least, I've lowered my expectations of them. I know that I will be left out of meetings frequently, I know that every meeting will start 5-10 minutes late.

That said, I love working remotely, although I would prefer to find a team that's used to it.

<comment><USER13> I'm not getting the problem with the meetings...

Why you don't just... log on Zoom on the correct time and leave it running while you do actual work on another screen/monitor/window?

Eventually they will get to their senses and stop being late.

<comment><USER12> Most of it is just being in the unknown, it's incredibly frustrating to just having to sit there and wait not knowing what's going on. Obviously I can continue to do work, but the frustration is still there.

Like I said, for them it's natural, they know what's going on, if they don't communicate that, I don't know.

</comment></comment></comment><comment><USER14> We rely mostly on email. Probably 90%. The best part about remote, I believe, is asynchronous communication. Email forces people think harder about what to say, vs trying to fill gaps of silence with nonsense during video calls. This makes for a more effective and efficient exchange of ideas.

<comment><USER3> Completely on point. I've heard this from our users at Standups, that async lets them have the time to think and note down what to say, and don't come unprepared to a live/sync daily update meeting, for example.

</comment></comment><comment><USER15> Another thing I will add to this is to use creation tools that show your presence to others. Figma has been huge for our design team because you can see the other person's mouse cursor moving around and making changes - <USER2> makes it feel like the person has a presence in the same room with you. Likewise with google docs or confluence, just the presence of a line cursor with a name next to it goes a huge ways. Mural is another one that does this well. It really helps make the remoteness feel less isolating.

</comment><comment><USER16> He mentions keeping a knowledge base up to date. That's a great idea, but I've never found good low-friction methods/tools for getting knowledge from peoples' heads into a knowledge base. Any suggestions?

<comment><USER17> One suggestion I've heard is to encourage your team to write blog posts. The blog posts serve as an open source knowledge base for the organization. This also provides the individual a way to become more well known in and out of the organization (personal branding) and provides the organization a bit of content marketing.

<comment><USER3> Totally agreed! I've seen this at other startups, and it works great.

</comment></comment></comment><comment><USER18> I'm convinced that some of the downsides to remote work will be solved through technological means; probably some kind of VR or AR solution, where you can be inside a shared virtual space and glance over to see what your coworkers are up to, and perhaps give them a virtual tap on the shoulder.

This kind of virtual office would not help as much, of course, in cases of highly distributed teams split across continents. Even then though, it would be cool to drop into someone's virtual office and leave a note on virtual post it or whiteboard.

<comment><USER8> In general I'm sceptical of skeuomorphism tools that try to simulate offices in applications. But I do believe VR can help creating the feeling of presence that is still lacking with traditional tools.

<comment><USER19> Sense of presence is a real added value of VR, I've been experimenting with virtual presence since 1995 making Unreal level with Wicked3D glasses and a huge monitor, later a z800 and OpenSim. Nowadays I watch Star Trek with a friend in Bigscreen, sitting next to each other, catching up - Bigscreen also works for pair programming.

A friend of mine lived in Boulder for a long time so I asked her to take me on a tour through the area's where she lived (Wander), basically you morph through a series of 360 photos like in streetview and you don't have full body tracking, but "you are there with someone, 'cycling' around". It beats narrating pictures.

I made a VR app so I can practice my vajra dance, a spiritual practice, on a huge mandala and meditate and doing tai-chi on a mountain top. I work solo or together with a cooperative game contained in Tabletop Simulator (Robinson Crusoe, Spirit Island, Codenames Duet), manipulating the various tiles with my Oculus Touch controllers. Experimenting with memory palaces in relation to internal psychological concepts and states as well as tuning into a virtual dance floor while DJ-ing are next on my 'play' list.

</comment></comment></comment><comment><USER20> As a PM, I don't think remote can work for me. Any PMs who work remotely? Curious to your thoughts.

<comment><USER10> Yes, I've held this role at an internationally distributed company. It's even harder across time zones, but it's doable.

As a first step, work on weaning yourself off of synchronous communication wherever possible. Limit your synchronous communication to only the minimum necessary to operate efficiently.

Create a routine of sending of ultra-concise weekly updates to the team. Your goal should be to produce reports that the teams actually enjoy reading. People should walk away from the reports feeling like they know what they need to know, what's expected of them for the week, when it's expected, and who to contact if any exceptions come up. The goal is no surprises, no hidden expectations, and visibility into the team goals. If people have to synchronously talk to you or wait for a specific meeting, work on improving the weekly update.

Fill in the gaps with daily updates for any relevant changes. Work on collecting updates, summarizing, and sharing them at the same time every day for predictability. Don't get in the habit of pinging everyone every time you have a question. People will hate the constant distractions.

Finally, carve out time for predictable, synchronous weekly meetings. Make it predictable, at the same time every week. Resist the urge to schedule spontaneous phone calls every time something comes up. Practice excellent meeting discipline, with an agenda shared ahead of time, careful attention on managing off-topic discussions, and so on.

</comment></comment><comment><USER21> Couldn't find a better time to post this article than in the middle of France biggest strike!

<comment><USER22> Good point. This will probably force more companies to experiment remote work.</comment></comment>


Deep learning with coherent nanophotonic circuits [pdf] - <AUTHOR> https://arxiv.org/abs/1610.02365 <comment><USER2> Very interesting paper, optical circuits have always been interesting option for computing whether it is in the form of plasmonics (surface plasmon + electronics) or linear quantum computing (with similar circuits reported in the manuscript). However, the challenge to translate this into any practical application involves solving a lot of engineering challenges....

</comment><comment><USER3> Unfortunately they didn't implement the non-linear part in optical form as of yet, though they do at least model a fairly realistic saturable absorber.

</comment><comment><USER4> Is this addressing the learning phase of the neural network, or just the feed- forward phase?

<comment><USER5> They trained on a computer model of the optical circuit, and only did the feed-forward step on the real thing. The rationale for that is that real-life models spend much more time (and energy) in inference mode, so that is the step you'd most want to optimize.

I can't help but think it would be really cool to automatically produce a circuit that would output the gradient of the error of the actual NN, so you could optimize that directly.

</comment></comment><comment><USER6> I wonder if this is what Intel is playing at with their comments about beating NVidia in the ML space within a few years without using GPUs?

<comment><USER7> No it wasn't, they were talking about ASICs.

</comment></comment><comment><USER8> It would be cool if they implemented a way of generating true random numbers by measuring a quantum events as part of the system

</comment><comment><USER9> Bingo!

<comment><USER10> What do you mean?

I've had a short discussion with a professor at my university about the practical efficiency of circuits. It seems like some tasks are better solved with algorithms and others with circuits.

I think that a proper mix between turing machines and circuits will be important in the future of AI.</comment></comment>


Gyrocopter lands in front of U.S. Capitol: political engagement hacker? - <AUTHOR> http://www.bbc.com/news/world-us-canada-32322775

<comment><AUTHOR> Could we also just land a bunch of drones there with our complaints? Clearly it's not that hard. Kudos to the first person to build a drone delivery service for sending complaints to congress.

</comment><comment><AUTHOR> "Delivering concerns to congress? There's no app for that. Better fly by gyrocopter."

</comment><comment><USER2> Violating no-fly zones and landing something with spinning blades, unannounced, in a public area is hardly the best way to deliver your grievances to members of Congress.

But let's not fool ourselves: if Mr. Hughes had instead taken the Metro and walked up to the Capitol Building, his letters would _still_ be ignored by his representatives.

<comment><AUTHOR> This was on his website. "Let them know you demand an honest government that works for the people - and you oppose shooting me down. (If you are in favor shooting me down, call that number, but wait until tomorrow.)"

<comment><USER2> Well, then he is a loon...because the people running the local air defense system weren't going to take a survey prior to engaging a possible hostile target when they have only moments to make a decision.

<comment><AUTHOR> Yeah I just thought it was kind of funny that he included a scenario where someone would desire to shoot him down.</comment></comment></comment></comment>


HuffPo: Trump Finally "Admits" His Campaign Is Racist - <AUTHOR> http://www.huffingtonpost.com/entry/donald-trump-racist_us_575588d2e4b0c3752dce1ec6 <comment><USER2> Please don't post garden-variety politics to HN.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

[https://news.ycombinator.com/newswelcome.html](https://news.ycombinator.com/newswelcome.html)

<comment><AUTHOR> Okay.

</comment></comment><comment><USER3> This might be the definition of "trying too hard".

I loathe Trump, but does huffpo honestly think this article is convincing to anyone who isn't already drunk on their koolaid?

<comment><USER4> > but does huffpo honestly think this article is convincing

Does Verizon/AOL care? Controversy brings eyeballs, whether its convincing or not.

</comment></comment><comment> Inspired-Mobile Hey guys, we're conducting a short survey about Trump and his values and we'd really love to see what you have to say about it. Just go to [http://bit.ly/1WDv4om](http://bit.ly/1WDv4om) and we'll be sure to share the results with you.

As a short introduction, we're a marketing company that provides an innovative self-service marketing platform for small and medium businesses. If you want to learn more about this, just send me a message and we can talk!

Thanks!</comment>


Programming's Dirtiest Little Secret - <AUTHOR> http://steve-yegge.blogspot.in/2008/09/programmings-dirtiest-little-secret.html <comment><USER2> Is that why Steves posts are so long. If he is going to type that fast, I need to learn how to speed read as well.

</comment><comment><USER3> Interesting rant, but off target. My dad, former journalist and author of about 50 books and hundreds of articles, is a hunt-and-peck typist. He just works really hard and doesn't get distracted.

</comment><comment><USER4> Reminds me of just how entertaining this guy was when he was blogging regularly. I miss this stuff.</comment>


Why Work Marriages Make Sense - <AUTHOR> http://www.blog.joelx.com/why-work-marriages-make-sense/9511/ <comment><USER2> The view of romantic relationships underlying this piece is not one shared by most of my friends who are in stable relationships, and is IMHO rather unhealthy.

People do not stay in romantic relationships to avoid "the trauma of getting dumped". They stay because their partner is who they are looking for, someone who enriches their life. Healthy people sting for a bit when dumped, but they get over it and find someone new.

Also, the boyfriend/girlfriend stage doesn't match up with what I've seen: people who dump their boyfriend/girlfriend "because someone better comes along" usually find that the new person isn't better at all, and in the meantime they've labeled themselves as fickle and capricious in the minds of friends and prospective dates. Rather, it's time to end a relationship when your continued partnership is making you unhappy, regardless of whether there is someone better out there. And as long as you are happy, you are unlikely to be _more_ happy with someone else.

I'd argue that even with these corrections, viewing work like a romantic relationship still makes no sense. The cornerstone of romantic relationships is equal emotional investment, and the idea that beneath all the trappings, we're fundamentally all just people. Business is different because:

1\. There is an inherent power imbalance between employer and employee. A company is never going to love you back, nor will you ever fulfill as important a role for it as it does for you.

2\. Companies will and should respond to changing market conditions. Those changes sometimes mean that whole roles disappear, and employees who want to perform those roles can and should go elsewhere. A romantic relationship is hopefully based on qualities more fundamental than "what professional role do I want to occupy?"

3\. If a company refuses to make hard choices about employment and market positioning, the market makes it for them, with the result that _everybody_ is hunting for a new job.

<comment><USER3> Company/employee relations are well-modeled by marriage between a mortal human and an immortal sociopath.

The Ancient Greeks had a fairly extensive literature on such relationships, which tended not to end well for the human, even when the human is exceptional. The gods... err... corporations can always behave irrationally, so even "irreplaceable" people can get dumped.

</comment></comment><comment><USER4> This model of employment exists. In Japan we call them "salarymen", in America "tenured professors" or "civil servants" or (in much of the country) "tenured schoolteachers." The model heavily distorts expectations about work (for those in the model and out of it), life, culture, etc. It _is not an accident_ that your workplace will frequently be involved in the decision of who you _actually_ , not metaphorically, marry.

If your life experience does not include enough warning flags for the potential negative consequences of this model on the firm, on its non-"married" workers, on its "married" workers, on its workers' families, on its customers, and on the wider society, flag me down two weeks from now and I will go into them at substantial length.

</comment><comment><USER5> This article is terrible.

>Some companies today and many companies of yesteryear had a different relationship with their team members: that of the husband / wife level of commitment.

The relationship was more like _parent & child_ than that of husband & wife. That's what it was with the 1950s automotive companies and Japanese corporations decades ago. The common adjective when discussing those companies was "paternalistic" and not "spousal".

The author should research the rigid labor situation in France and see how it's handicapping their economic growth. They don't have the political will to push through labor reforms and their young workers face 25% unemployment rates.

A husband+wife employment model in America would weaken instead of strengthen its economic power.

<comment><AUTHOR> Very good point about the parent-child relationship vs the spousal relationship... I thought of the husband-wife metaphor today and liked it so I wrote an article on it. I will consider your idea further to see if my idea needs updating.

</comment></comment><comment><USER6> This is the "Loser" deal according to the Gervais Principle[1]:

"[The Losers have] given up some potential for long-term economic liberty (as capitalists) for short-term economic stability."

It makes a certain amount of sense, but so do the other positions of the "Clueless" or "Sociopaths". If you are ambitious, then the "Loser" deal is clearly a bad one.

[1] - [http://www.ribbonfarm.com/2009/10/07/the-gervais- principle-o...](http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-or- the-office-according-to-the-office/)

<comment><USER2> I'd argue this is the "Clueless" deal in the Gervais model. Losers are fully aware that they have struck a bad and unequal economic bargain with their employer, they just don't care. They will happily go elsewhere if a better bargain comes along.

It's the Clueless who believe that their loyalty to their employer is matched by their employer's loyalty to them (hence, "clueless"). They're the ones who stick with the firm, rise into middle management, diligently play the company line, and then get abruptly disillusioned when the firm institutes mass layoffs.

<comment><USER7> Yeah no shit, if you get fired and get to keep 50% of the stock, it might be a marriage.

Otherwise it's just delusional. My labour goes to the highest bidder.

</comment></comment></comment><comment><USER8> I'll admit I haven't read the full article. However, this did stand out to me:

> So why would they want to be exclusive? Mostly because they want their > significant other to be committed and not leave them whenever the > significant other has a better option.

Realistically, I think it probably is true, sadly, that many people might see committed relationships this way. And if it is true, I would take that as at least a partial explanation for why the divorce rate is so high.

This is totally anecdotal, but from my observations, the marriages I've seen and known that have succeeded the best were not based on a trading of commitments, at least not in this very game theoretic sense. They were based on actual, legitimate love, and that's all there is to it. Love doesn't mean you can't be attracted (even very attracted) to someone else, but it means that any such attraction pales in comparison to the companionship you share with the one you love.

</comment><comment><USER9> _So why would they want to be exclusive? Mostly because they want their significant other to be committed and not leave them whenever the significant other has a better option._

Uh, no. Monogamy is rooted in, basically, the following issues:

1) Germ control. You can get deadly diseases by sleeping around casually.

2) Sex leads to babies and human babies do best with two parents. It is a big burden and our species is designed to do the two parent thing.

3) It takes 15-20 hours a week to build and maintain real intimacy. There simply isn't enough time in the week to have lots of different genuinely intimate lovers. The math suggests that most people can sustain no more than two genuinely intimate sexual relationships.

<comment><USER7> You're trying to justify the dominant social mode rather than trying to discover arrangements that make people fulfilled.

Marriage stats suggest that humans aren't at all monogamous, most marriages end in divorce, and most people cheat.

</comment></comment><comment><USER10> This article is terrible. Companies are not loyal to their employees and pretending otherwise is truly deluding yourselves.

People in a marriage, in theory, should remain loyal for life.

<comment><AUTHOR> I agree most companies are not loyal. It would need to be a 2 way relationship led by ownership (not really possible for publicly held companies, but can work for small wholly owned companies like mine). Perhaps it should even include some sort of legal contract...

Good point though for most large companies.

<comment><USER10> Joel,

I think that sort of relationship should really only existing for a few types of government jobs to block regulatory capture [if you have a job for life with good pay and retirement...the only way to lose it is to be caught being bribed] and teaching [which politics might meddle with].

Please don't take my comment personally. I watched people who were loyal for 10+ years get laid off recently and it kind of has made me angry about the idea of that kind of loyalty to a legal fiction.

</comment></comment></comment><comment><USER11> Even if it were better for the employee to be married to their job (which is doubtful - see: the many articles telling us that the best way to get a raise is to negotiate your new starting salary), I worry that this post could be taken to mean that you should be loyal to your company in the current real world. Your employer does not want to marry you, and will in fact drop you as soon as something better comes along. If you're the only one acting as if it's a long-term thing, you're the sucker.

<comment><AUTHOR> Agreed... you would need to strike some sort of a deal directly with ownership, which is impossible for most public companies. Good point!

</comment></comment><comment><USER12> That's really a confusing thing in many ways.

"The company can be sure that that person will show up each day and do their best to do good work." <\- no, the company managers can feel they're getting the best they can get. Not the same thing at all (it's all about perception).

Sorry I'm too tired to refute the rest of the confusion but to leave something of value to think about: the way our brains operate have optimised us to think about people. Disney make some objects like creatures because is easy for kids to pick up on anthropomorphised objects.

There might be something of value to research in the antropomorphisation of the company-employee relationship but my radar says it's easily going to end up hacking unaware or unpowered humans into company drones.

Watch this: [http://topdocumentaryfilms.com/the- corporation/](http://topdocumentaryfilms.com/the-corporation/)

<comment><AUTHOR> I agree; this concept if applied to a company that did not (or legally could not) operate this way would lead to the detriment of the employee. By the same token, the concept if misapplied by a company to employees would lead the company to fail. It needs a bit of an enlightened team to work properly.

</comment></comment><comment><USER13> _Basically it's a trading of commitments: Each person says to the other, "I want to avoid the awful risk of being painfully dumped for someone else, so I will make a commitment to you to not leave as long as you do your part even if someone else that might be better comes along."_

From Dante to this.

"Progress"

</comment><comment><USER14> This makes no sense to me. A marriage is premised on a lifetime commitment. Even with a 50% divorce rate, you are talking about 2 marriages in a lifetime, outliers are 3.

Most people stay in jobs for an average of a few years. It is dating as best.

Seems like a very contrived argument with no particular value derived from this analogy, apart from in fact, not making sense.

</comment><comment><USER15> Almost all the comments here are saying that this article is terrible, yet it's at the top of the front page. Huh.

<comment><USER16> It got under people's skin - good troll! Bad argument though.

</comment></comment><comment><USER17> One of the most stupid things I have ever read on this side of the screen

<comment><USER3> While I don't disagree, I'm deeply interested in knowing how often you read things from the _other_ side of the screen...

</comment></comment><comment><USER18> So vesting periods for options are a prenuptial agreement? Stay for a few years if you want to leave with anything.

<comment><AUTHOR> Haha... and golden parachutes are alimony!</comment></comment>


Tips for Screencasting - <AUTHOR> http://brettterpstra.com/2015/12/10/tips-for-screencasting/ <comment><USER3> One thing I've found that is handy is to record the video while narrating the process (this will slow your actions to a comfortable pace) but only record the video. Go back after that and focus on the narration/explanation. You'll cut down on the "uh..." "um...". When you piece them together, the viewer won't know and your delivery will be much smoother.

</comment><comment><USER4> A few other tips:

* If it's on YouTube, you can get an automatic transcription. That's not the best; you can use something like [https://speechtotextservice.com/](https://speechtotextservice.com/) (no relationship with them). Or hire someone on fiverr. Having searchable text is good for SEO but, more important, for visually impaired users.

* Though OP sort of poo-poos cool intros, brief ones (the best kind) can be done very cheaply on fiverr (again, no relationship) and help keep viewers awake and are simple to reuse.

* Watermarks are good if it has genuine editorial use, as should be the case, because it makes theft harder.

</comment><comment><USER5> [http://www.hanselman.com/blog/TheGuideToCreatingQualityTechn...](http://www.hanselman.com/blog/TheGuideToCreatingQualityTechnicalScreencasts.aspx) (2011)

</comment><comment><USER6> Another tip that can save viewers (or readers) a lot of frustration - if your screencast (or blog) is specific to a particular technology, mention (or write) that at the outset.

Interestingly the page doesn't contain the string 'apple' or 'osx'. Some of the generic suggestions, early on, are almost platform agnostic, but by mid- way through we're clearly in the realm of OS and application features, and keyboard shortcuts, specific to one particular vendor.

<comment><USER7> For the record (from the author), 98% of my traffic is from Mac users, so I don't usually specify. I do, however, state in the second paragraph that it's very specific to ScreenFlow.

<comment><USER6> Thanks. I was not intending to sound overly snarky. I think perhaps only people outside a circle notice the assumptions made by people within it.

For example, it's usually easy to identify material written by people in the USA - they're more likely to assume their readers are within the USA. People in South America, Europe, and Asia seem to assume their readers could be anywhere.

Similarly with tech, though I think we all assume everyone knows what we're talking about, no matter where they are. : )

I had no idea what ScreenFlow is, other than a camelcased bonding of two common words. Yes, you may say, I could have looked at that link, find that it takes me to iTunes, and then intuit we're talking OSX ... but a) I was on mobile so it wasn't a simple hover, b) as you note it's an en passant reference in the second paragraph.

EDIT: Oh, and c) the page title is 'Tips for Screencasting'

<comment><USER7> Fair enough :).

</comment></comment></comment></comment><comment><USER8> Along the same lines, does anyone know of any guides/tips for recording interviews over Skype or something like that? Telling your guest to turn off downloads/torrents, quit other apps, use a good mic, and so on seems common sense but I still notice these issues in screencasts on YT.

<comment><USER9> This requires buy-in from both the interviewer/interviewee, as well as any other participants.

In general, you just need to take a few extra precautions.

\- Situate each member in an room with minimal distractions and isolated from noises. If possible, go somewhere without pets - everyone loves pets, but everyone also knows that they have no sense of privacy, will make noise when they verily well feel, and in the case of dogs, their bladders know not the meaning of "Do not disturb". They're just doing what they do, but it's just an interruption that can maybe be avoided

\- Likewise, avoid being too close to a window especially during the day - <USER2> sunlight may provide some really pretty back-lighting, but auto-color correction on a lot of web cameras will be constantly fighting with the sunlight should a cloud pass, shadows rise/fall, and so on

\- A wired connection is strongly recommended just to remove the variable of WiFi interference kicking up unexpectedly

\- Headsets are strongly recommended, or at least a quality microphone with the speaker having an earbud to isolate any possible feedback. Wired strongly preferred

\- In a similar vein, fixed apparatuses are preferred (i.e., no in-line microphones like what you get with cell-phones). They tend to brush against fabric and make awful noises, or twist or turn

\- Take some time prior to the actual recording to just sound-check and also get used to the tiny delays that often occur with interviews. 10-20 minutes is often good enough just as a warm up

\- Make sure that all participants are used to speaking on video and through mics. There is a bit of an art to doing it right with video chat, avoiding either being too loud/blaring or too soft

\- Finally, test whatever screen recording software you're using multiple times before the call and test it in a real call situation to ensure that there are no audio goofs. This can be part of the 10-20 minute test. It goes without saying, but you'll probably want to use a moderately modern machine that won't chug when recording, and also have enough space to store the recording

These are what we used for my workplace when we did Skype interviews and needed to record them for review later on.

</comment></comment><comment><USER10> Pet peeve as a viewer - avoid disguisting body nioses - lip smacking and sighing between sentences, sniffing and saliva sliding around the mouth. I guess that last one is a microphone thing.</comment>


The State of the Smartphone: iPhone is Way, Way Ahead - <AUTHOR> http://www.readwriteweb.com/archives/the_state_of_the_smartphone_iphone_is_way_way_ahea.php <comment><USER2> Those numbers look a little skewed to me

<comment><USER3> It looks like a plug for Flurry who is marketing itself as (and I looked in the title of the Flurry page for this) iPhone and Android analytics. See whats missing? Right, no Blackberry. Just because they support it doesn't mean they push marketing in that direction. Its a skewed result from a opt-in service.

The article isn't so much about the iPhone as it is the Flurry service giving us biased facts and Fluffy information.</comment></comment>


Cost Effective Web Development Techniques - <AUTHOR> http://allinthehead.com/retro/340/10-cost-effective-web-development-techniques

<comment><USER2> To me, this was worth the 5 minutes it took to go through. Each point was supported by good observations. As a supported of agile techniques he nearly lost me after slide 9, but made up for it.

OK, the highlights. The numbers are the slides. If you disagree with one then I suggest you look at its supporting slides before criticising in detail.

       9 Write a comprehensive specification
      16 Evaluate possible existing solutions
      21 Consider the cost of your design choices
      32 Make sure your design covers all states
      39 Design for reusability
      45 Broadband is not a silver bullet
      50 Prepare your design files read to send
      58 Build your site for cheap maintenance
      65 Build your site for low cost quality assurance
      73 Use existing APIs

His final point was

 _"The best way to save money is to let someone spend theirs."_

There are many faults to be exposed here, but I think there are many good points to take away from it.

Thank you for submitting this.

<comment><USER3> I'll second the thanks - I've book marked this to add to our training regimes, some great tips.

Some thoughts to add though (based on ROG's condesing). Whilst I agree with "9 Write a comprehensive specification" in slide 14 he says "Development can be planned up front". By that I assume he means planning the process by which the specification is executed: or mapping how to build the spac. That's always a point I _specifically_ avoid doing, at least till things are underway. One of the best things (possibly the only useful thing...) I was taught at school was that a specification is about _what you want to achieve_ NOT how you plan to do it. Purely because if you plan out in too much detail how to execute a problem then you risk locking into an inelegant solution.

2 things I particularly like are the comments about "logged in logged out" (slide 32 onwards). One of the issues I often run into (and MUST learn to avoid) is beginning a design and framework in a logged out state and never consider the logged in state till I come to add it later. I often find this is much more of a problem with _code_ than it is with visible design. Secondly "DONT reinvent the wheel" is the #1 bit of advice ever. Literally.

:)

<comment><USER4> By "development can be planned up front" I mean on a really simple level. I think the example I gave in the presentation was that if you were implementing a user comments feature, you could reference the spec to find the other parts of the site/app that also need user comments and implement a single solution that will cover all cases.

One of the downsides to agile is that you don't always know what's coming further down the road, so you either have to build extremely generic solutions (usually a waste) or very specific solutions that get adapted over time (refactoring is also wasteful).

In situations where budget is tight - which is the position I was coming from - it is optimal to have solutions that are Just Generic Enough to cover needs.

Thanks for your comments :)

</comment></comment></comment><comment><USER5> Good list.

Not sure about the comprehensive spec at page 9 though: BDUF - Big Design Up Front is often a naive approach. Requirements and constraints tend to change as you go along. Too much up front specification can be a waste if 30 percent of those features never see any use. I'm all for thinking each specific task, function and web page properly right through before coding it, though. :)

I also have trouble with "design for reusability" at page 39. Building one-off components is a waste IF you are going to build similar stuff in the future. However designing things for reuse also incurs overhead in itself that first time around. The specific project context should determine if building for reuse is cost-effective. Also, designing for reuse can be taken too far. We sometimes burn ourselves by thinking too generally - see some of the more complex J2EE frameworks out there...

<comment><USER6> Drew may correct me on this, but I dont think he is necessarily talking about the BDUF approach from a traditional software development viewpoint. ie. not documenting every detail of the system from a developer-standpoint (eg. this function must be AJAX-driven, user details will consist of x and be stored in a mysql innodb database table etc), but more as complete-as-possible account of the user stories the website / application needs to satisfy.

I've managed development teams that have very successfully implemented agile development work within a larger organisation that follows waterfall within its general IT teams. The trick is two-fold. One: remove low-level system dependencies (do you really care if i use Apache 2.2 or IIS to host the website??), and two: internally tier the requirements to allow iterative progression and evaluation.</comment></comment>


Can Open Data Keep Politicians in Africa Accountable? - tefo-mohapi Serious question, given rulers like Uganda's Museveni who have been president for decades and yet living conditions haven't improved for citizens. <comment><AUTHOR> Really doesn't make any sense here, I live in Algeria and the president here has edited the constitution to allow himself for more terms and he is literally unable to move a keyboard, and beside everyone knowing that in the country, nobody moves a finger and if he does, he will end up badly, so most of the times people know what is going on, yet they choose to do nothing because of fear, so open data, open government, open<insert government related thing> won't help really, the only choice i see in my country is to educate people, because compared to USA, people here are uneducated (not talking about college) people don't care, they can give up everything they have, which is really bad if you ask me, and i think that's the main cause of this, is the government as it made sure to insert ignorance and keep the people busy with shallow topics, now i know i have gone off-topic (I just hate to see my county going down), but just to say that as long as people don't care, nothing will help the corrupted government officials.

<comment> tefo-mohapi Don't you think fear plays more a part than just "not caring" and "ignorance"?

<comment><AUTHOR> I certainly agree with you, but in that specific case I am seeing, those are the major players, there is other factors like being assassinated and kidnapped to nowhere, but that have decreased in my country in the last few years, in 2011, essential food prices has gone too high, and when the people went out and protested (it was a real mess), the government took actions immediately, but since the, they kept people busy with other factors, that prices have gone high again (higher than last time) yet no one is caring.

<comment><USER2> Machiavelli said of people that they were easily afraid, that between their little comfort and the insecurity of change they will chose their comfort and that money is the main thing that makes people go around.

This is why people in the arab world protested because of food prices, corruption had been known for years, and it's still there, but it's not enough to make people revolt, they had to get really hungry to get pissed off. It's also why the saudis gave 40 grands to each and every one of their citizen, it was a ''don't revolt'' bribe. It worked.

So if you're an authoritarian government who wants to keep power, all you have to do is use fear and money and you'll be mostly alright, problems arise once your military stops working in your favor and money dries up.

<comment> tefo-mohapi Applies to most of Africa

</comment></comment></comment></comment></comment><comment><USER3> You're asking people in America where politicians aren't held accountable even if they poison thousands of children and take hundreds of thousands of dollars in lobbyist money? will you get an answer from the country where Generals are assured a job in the private sector after they've done their best to allocate juicy contracts to their corporate handlers and made plan to start wars where the flow of money is more important than strategic wins? Personally I don't think you will get any good answer from the land of the greed and home of the hate/jailed.

</comment><comment><USER4> "Open Data" is only as good as the quality and truthfulness of the data. I suppose the most likely outcome is that these politicians will get more sophisticated about data... so that they can fake it reliably.

<comment> tefo-mohapi That's always the risk --> "what if the data is rigged?"

</comment></comment><comment><USER5> I don't think it can. If witch hunts are still common and private armies are a thing as well as foreign powers intentionally destabilizing the region there is little open data can do.

<comment> tefo-mohapi I agree but have a glimmer of hope.</comment></comment>


Swift: How to make single-character Strings work in a UInt8 raw value enum - <AUTHOR> https://gist.github.com/danhd123/c1dc8242f48ace176cf8

<comment><AUTHOR> The motivation for this was trying to parse a binary file with a discriminated union, with the tag being a single byte representing one of several ASCII characters. Since Swift doesn't have single byte character literals like single-quoted characters in C, UInt8 raw value enums required decimal or hexadecimal integer literals, which really hurts readability; 0x42 is strictly worse than 'B'. As a StringLiteralConvertible, "B" is an acceptable value for a UInt8 case.</comment>


Notes on "A Philosophy of Software Design" - <AUTHOR> https://lethain.com//notes-philosophy-software-design/ <comment><USER2> John Ousterhout: "It's more important for a module to have a simple interface than a simple implementation."

Richard P. Gabriel in [http://dreamsongs.com/WIB.html](http://dreamsongs.com/WIB.html) : "Simplicity -- the design must be simple, both in implementation and interface. It is more important for the interface to be simple than the implementation."

Ousterhout here is advocating The Right Thing, as opposed to Worse is Better. Unfortunately Worse is Better has become the dominant approach and it will be difficult to change that.

<comment><USER3> > Unfortunately Worse is Better has become the dominant approach and it will > be difficult to change that.

That's because "Worse is Better" provides revenue out of the gate. Design and performance doesn't sell, it just raises costs and causes churn. And so long as your features are bringing in more customers and revenue than you churn, nobody cares.

Yes, it will cause blowback later, when you have a feature-rich product that is unacceptably slow, or new features cost too much to be released on time, but that future may be _years_ away, a timeframe you can't (or aren't allowed to) think about when investors are pushing hard for user and/or revenue growth.

Of course, those years later, it will probably be faster to pivot to a new bit of software written with a "Worse is Better" mindset and start the cycle again.

</comment></comment><comment><USER4> I want to politely disagree with the comments here telling that this book should be categorized as a "undergrads book". This is a way to neutralize the content of the book for a broader audience, that is, we are doing everything wrong in most software development environments.

Moreover the author commits a big mistake in saying that Google is a good example of clean software design. Talk with people inside the company to get a real picture, it's full of monsters that you have to maintain just with "tactical programming". This book is very well applicable inside Google as well.

<comment><USER5> I totally agree with your point. Categorizing the book as undergrads book is really trying to minimize the importance of the message. Those recommendations does apply to everyone, thinking that it could be only useful for junior or undergrads is almost admitting that you don't really have to care, hence you are probably not trying to follow this philosophy. As a senior, I've been trying to apply and you have to be humble and question your choices all the time. One of the problem is the culture of complexity among developers, seniors not being an exception.

</comment></comment><comment><USER6> I saw some reviews that claim the books just presents common knowledge. Keep in mind it is aimed at undergrads.

I personally think the author is to harsh on "tactical programming" (solving problems locally without the big picture in mind). I agree with someones note on HN that tactical programming is fine till you get a product market fit. Technical debt has not to be paid back if the product fails.

I try to design strategically for overall architecture and don't care for most of the rest (in worst case you can refactor later).

If 9 out of 10 startups fail you can have huge savings. If you have enough success that it matters then you have the resources to improve.

<comment><USER7> I think your comment reflects well the mindset difference between programmers working for startups and the rest of the world. When you're working on a system that's supposed to last for decades, you think in a completely different way.

<comment><USER8> Do general purpose line of business programs last for decades though? I suspect that the ones that have lasted have gone through enough iterations to the point of being unrecognizable to original authors...

<comment><USER9> Someone on HN said recently that business software is like another employee. You wouldn't fire a senior with lots of domain experience, on whom critical processes are dependent, just because it's time to freshen things up.

</comment></comment></comment></comment><comment><USER10> This was a fantastic book. It is definitely not for undergrads, or just undergrads. I think it even more important for people actually working on production systems. Even better, it provides some language for people to share when doing code review about how to design their APIs better.

</comment><comment><USER11> I've found this book to be a nice antidote to the damage done by excessive Uncle Bobbing. I.e. if you give your undergrads "Clean code", also give them this book to prevent them from becoming mechanical DRYers who think good code equals avoiding duplication.

<comment><USER12> If the only thing you got from "Clean code" is Don't Repeat Yourself then I highly suggest reading it again.

(IIRC the DRY principle comes from "The Pragmatic Programmer" and not "Clean code", but it is referenced and is one of dozens of "clean" concepts.)

</comment></comment><comment><USER13> Side note: I find it really weird that a book about software design released in this day and age has no plans for an ebook edition[1].

I've had this book on my radar since it came out, but no library near me is going to stock it, and I just don't have the space in my tiny apartment for books unless they are very important to me.

[1] [https://twitter.com/JohnOusterhout/status/989581205799452672](https://twitter.com/JohnOusterhout/status/989581205799452672)

<comment><USER14> I don't know why Ousterhout doesn't want to release an ebook version, but I do know that some authors refuse because of typography limitations in the mobi and epub formats and popular ebook readers.

On one hand it's annoying to not be able to buy something in the format you want, but on the other, it's nice to see people refuse to compromise on aspects they consider important.

<comment><USER9> I'd settle for a PDF then. No limitations whatsoever, and trivial to generate from whatever the author's toolchain is.

I suspect the reasons have nothing to do with typography or technology limitations, and are more related to a contract with the publisher.

</comment></comment></comment><comment><USER15> I've yet to finish this book yet, but it's definitely not just for undergrads. There is a lot of things in it that seem obvious when stated, but are either good reminders, or genuinely well stated language for a domain.

One example that stands out to me is deep vs shallow classes.

</comment><comment><USER16> This [1]post on Reddit says something similar and really is true. Most of us engineers tend to neglect design. The fusion of good code and good design can set you up for success (after product market dit obviously)

[https://www.reddit.com/r/Entrepreneur/comments/9ay8fq/design...](https://www.reddit.com/r/Entrepreneur/comments/9ay8fq/design_helps_software_companies_grow/)

<comment><USER17> To a certain extent design is the antithesis to agile. How can you create a good design when you make up new features on the go?

Following the above summary of the book Ousterhout argues for increments implementing abstractions instead of features.

Ordered the book now :)

<comment><USER18> I don't think design is the antithesis to agile just that design needs to be an iterative process not just in terms of product features but software architecture.

Jamming new features into an existing architecture whether it fits of not is amazingly common though. In that vein I'd maybe even think about separating product and software increments just to highlight technical debt.

<comment><USER19> 'Agile' has become such an overloaded and qualified term that it is almost meaningless, or even a source of confusion between people for whom it has different implications. If you are asking whether something is or is not agile, you are probably asking the wrong question.

You are right about the frequency of jamming new features into an existing architecture whether it fits of not, but, if the feature makes sense (which is not a given), then a bad fit shows that there is something inadequate about the current architecture. This does not necessarily mean that it is wrong for its current purpose, but regardless of how you got into the situation, you now have a choice: you can redesign the architecture and re-implement the affected parts (aka refactor), or you can create technical debt, and the former has a much greater chance of success if you separate it from anything that changes features.

</comment></comment></comment></comment><comment><USER20> I use 'A Philosophy of Software Design' as my goto-list for reviewing pull requests. It has a great set of points that apply across a wide variety of applications.

</comment><comment><USER21> The author gave a talk on this book at Google recently: [https://www.youtube.com/watch?v=bmSAYlu0NcY](https://www.youtube.com/watch?v=bmSAYlu0NcY)</comment>


Code Reduction or Spartan Programming - <AUTHOR> http://willcode4beer.com/design.jsp?set=codeReduction

<comment><USER2> I thought it was cool that the author mentioned Hemingway. He linked through to an article, "Ernest Hemingway's Top 5 Tips for Writing Well" ([http://www.copyblogger.com/ernest-hemingway-top-5-tips- for-w...](http://www.copyblogger.com/ernest-hemingway-top-5-tips-for-writing- well/)), which contained this little gem:

"Hemingway was famous for a terse minimalist style of writing that dispensed with flowery adjectives and got straight to the point. In short, Hemingway wrote with simple genius.

"Perhaps his finest demonstration of short sentence prowess was when he was challenged to tell an entire story in only 6 words:

"For sale: baby shoes, never used."

Every now and then you come across code that's as good as that, and when you do it's a wonder to behold.

<comment><USER3> I think it was "For sale: baby shoes, never worn."

<comment><USER4> Shamelessly plugging a little site I put together a couple months ago in hopes of inspiring more stories of this form (inspired by a Wired article): <http://sixisenough.com>

</comment></comment></comment><comment><USER5> Another programmer blog by someone who hasn't heard of Don't Repeat Yourself yet.

A lot of this stuff just boils down to Don't Repeat Yourself. If all substantial ideas in your codebase are only expressed once, then changing your mind about any idea in your system is easy.

<http://en.wikipedia.org/wiki/Don't_repeat_yourself>

<comment><USER6> It really is common sense stuff, but the longer I live the more I learn how uncommon 'common sense' really is.

<comment><USER5> It's common sense applied a few steps farther. In the short term, cut & paste can get your job done fast. But after the 12th cut & paste followed by another change in requirements, it starts to look not so good.

</comment></comment></comment><comment><USER7> Even there is a hacker comunity based in these principles: <http://www.suckless.org/common/index.html> (KISS with steroids)

<comment><USER8> i'm the happy user of suckless' dwm and dmenu :D</comment></comment>


Amazon's Alexa is triggered by the word "Elections" - <AUTHOR> http://nymag.com/intelligencer/2018/11/dont-murder-anyone-around-an-echo-during-election-season.html <comment><USER2> Does anyone know if mint-condition Alexa devices that have never been connected to the Internet are triggered? That'd give us some idea of the remote update capabilities of the device.

</comment><comment><USER3> Just tried it. Yup, it does get triggered.</comment>


Toshiba's new glasses-free 3D display tilts images and viewing angles your way - <AUTHOR> http://www.engadget.com/2010/12/12/toshibas-new-glasses-free-3d-display-tilts-images-and-viewing/ <comment><USER2> This is not strictly auto-stereoscopy (glasses-free 3D), it's just a movable 2D window in a 3D space; like walking through a 3D scenery with one eye closed.

Possibly useful for "augmented reality" scenarios.</comment>


CompuServe Forums, RIP - <AUTHOR> https://arstechnica.com/information-technology/2017/11/compuserve-forums-rip/ <comment><USER2> Wow, I'm amazed they were even still around.</comment>


Ask HN: How do you percieve colors - <AUTHOR>

http://i.imgur.com/fN2MveM.jpg
The discussion of perceiving a dress as gold/white and blue/ black (http://www.wired.com/2015/02/science-one-agrees-color-dress/) has fascinated me. I realize the following post raises more questions than answers, but... How many times have we gotten into arguments as developers, or with clients on a particular design choice, because of a difference in perception?
This brings up an interesting topic in how to chose colors for the design of your project - none of us have any idea, if we all perceive colors so radically different.
The above image is one of my favorite "visual thought experiments". The green column is actually the same on both the left and right (#15b400)
To start framing a discussion on how to actually try and learn other people's schemas for seeing, Im using a basic image like this, and these questions are how I'd propose we start.
(my apologies that I don't have enough karma to create a poll)
What do you see in the image:

   1) Brown Stripe, left dark green
   2) Brown stripe, left bright green
   3) Purple stripe, left dark green
   4) Purple stripe, left bright green
 I'd suggest we begin with answering on our own perception (I'm number 3) and going from there. <comment><USER2> For the wired article it seems that the images are just altered to the point where they are clearly not black and blue.

I wrote about it here: [http://austingwalters.com/that-dress-is-gold-and- white/](http://austingwalters.com/that-dress-is-gold-and-white/)

As for the perception of the image you sent:

The greens look the same to me, and I see purple stripes</comment>


Nginx + LibreSSL – a first test - <AUTHOR> https://www.mare-system.de/blog/page/1405201517/

<comment><USER2> The small performance degradation could be a good thing - it may be a result of the use of explicit_bzero to clear sensitive data structures (instead of memset which was used previously) before freeing.

It could mean that a fair bit of that important cleaning was being optimised out before with OpenSSL.

<comment><USER3> Possibly, but it could also be much faster with all the cruft gone. Dynamic linking has a small overhead, so would love to see an apples to apples comparison.

<comment><USER2> Definitely to some extent, but I think the cruft would have a much smaller effect. Much of it was dead code - commented out, whole files not actually compiled, code ifdefed out, or bits of code only compiled on platforms that nobody has used this decade etc. It was making maintainability a nightmare and making it a lot harder to find bugs, but I don't think it would have had a huge performance impact.

</comment></comment></comment><comment><USER4> Cool, it builds!

Reminder: You still have RC4 enabled. It's time to take that out.

<comment><USER5> yes, i know, but accoring to the blogpost below it should be no problem for newser browsers when using tls 1.2, but might e usefull to keep compatibility with very legacy clients, no? disclaimer: i'm not a crypto-guru, the ciphers used are copypasta'd from [https://www.ssllabs.com/projects/best- practices/](https://www.ssllabs.com/projects/best-practices/).

[https://community.qualys.com/blogs/securitylabs/2013/03/19/r...](https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in- tls-is-broken-now-what)

</comment></comment><comment><USER5> an updated version is available, now with nginx+libressl statically linked</comment>


College Debt - <AUTHOR> http://collegedebt.com/

<comment><USER2> Oh come on. Just showing long numbers, without even providing a graph to allow people to compare the relative size of the values?

I can learn about the 15th decimal place (which is totally bogus, of course -- it's not that accurate), but I can't easily tell whether student loans are bigger than or smaller than credit card debt.

Build a better way of displaying this.</comment>


Hellо, I Am a Compiler - <AUTHOR> https://stackoverflow.com/questions/2684364/why-arent-programs-written-in-assembly-more-often/2685541#2685541 <comment><USER2> While the question seems a bit arrogant/ignorant, I really dislike the snarky quora-styled response.

I go to stackoverflow for answers, not stories or opinion pieces.</comment>


NFL Has a GitHub Page - <AUTHOR> https://github.com/nfl <comment><USER2> Hi there! I used to work at the NFL. We were VERY early adopters of React, and I was lucky enough to work with some of the best frontend engineers I've ever worked with in my entire career. We built our own version of NextJs and Create React App 2+ YEARS before those projects became popular in the community ([https://github.com/nfl/react-wildcat](https://github.com/nfl/react- wildcat)). This is what I primarily worked on, along with being responsible for making sure NFL.com was accessible, and working on the build/test/deploy pipeline for NFL.com and the NFL.com App (which is react-native). 1.5 years ago my boss and I left and joined System1.

Unfortunately, the vast majority of the website was farmed out to contractors, so we weren't given too much business support to really push some of these open source projects forward and give them the same level of "marketing sparkle" that a company like Facebook would encourage. For example, part of me was STOKED to see NextJs come out, because it was a better version of react- wildcat. But to be honest part of me felt like with that extra level of marketing sparkle react-wildcat could have been what NextJs was built on to begin with.

I don't really fault NFL for this because these projects didn't drive any revenue. Also the way NFL.com's business model worked didn't really give engineering a "wedge" to increase profits, so engineers were all considered a cost center. E.g. at most adtech or publishing companies you can write a few lines of ad related code and prove revenue increased in an A/B test 24 hours later. NFL had no problem selling ads directly because of how amazing their brand is, so fancier code wouldn't really make a difference.

Also career-wise I learned even though I got to touch decently high profile open source projects like React Helmet, React GPT, and React Metrics, it didn't really transition to any benefit in job interviews. Before leaving NFL I interviewed at top FANG level companies and got rejected at the phone screen. Even non-FANG companies didn't really seem to care. Keep doing those leetcode problems kids!

Most of the original team members from that era of the NFL have moved on to different companies after it became pretty clear that more and more work was going to become outsourced. I got lucky and really clicked with my boss at the NFL, so when he left I tagged along and fumbled (no pun intended) into an absolutely excellent opportunity at System1. All in all, working there was a great experience!

<comment><USER3> Thanks for sharing your story and for all your great work. Comments like this make HN the special place it is.

<comment><USER2> Thanks for the response! I always like seeing people chime in from companies at Hacker News too so I'm glad you enjoyed my story.

</comment></comment></comment><comment><USER4> They've nailed the repo naming (sample of size 1): [https://github.com/nfl/react-helmet](https://github.com/nfl/react-helmet)

<comment><USER5> It's a great library too. the defacto standard to use with Gatsby

</comment></comment><comment><USER6> Of course they do. React-helmet is great!

</comment><comment><USER7> I'm sure a lot of "non-tech" companies have little things that can fill their corporate presence on GitHub.

<comment><USER4> What is the difference between a tech and non-tech company?

Btw, their top-3 repos respectively have 12k, 573, 432 stars. I'm not sure little is the apt description.

<comment><USER7> > What is the difference between a tech and non-tech company?

The number of software engineers in the NFL is probably a rounding error compared to their entire workforce.

> Btw, their top-3 repos respectively have 12k, 573, 432 stars. I'm not sure > little is the apt description.

I'm not saying that they don't have _useful_ software. I'm just saying that many companies probably have some projects they can open source; it's not surprising to see that NFL has a GitHub page.

</comment></comment></comment><comment><USER8> [https://github.com/nfl/react- helmet/blob/master/CODE_OF_COND...](https://github.com/nfl/react- helmet/blob/master/CODE_OF_CONDUCT.md)

And a properly filled out code of conduct. Not bad.</comment>


A Week in Hacker News - <AUTHOR> http://mjtokelly.blogspot.com/2009/03/week-in-hacker-news.html

<comment><USER2> That is fascinating. Admittedly probably more to me than anyone else. What do the red titles mean? Could you make a version that plays at half the speed? It would be interesting if the background changed color to show day and night PST.

<comment><USER3> It says in his explanation -- green stories made the front page; red did not.

<comment><USER4> Actually, he says green are on the front page and red _are_ not. They could have been on front page at some time.</comment></comment></comment>


Watch 3 concurrent streams of the Curiosity landing with HN/Reddit Chat - <AUTHOR> http://teevox.com/space

<comment><AUTHOR> Spent the last 4 hours hacking out a way to integrate UStream!

        1,2,3 - Cycle through PiP screens

        TAB - Show/Hide PiP screens

        LEFT, RIGHT - Volume Change

        C - Show/Hide Chat

For everyone who's coming to Teevox for the first time, Teevox is an integrated stream viewer that has focused on gaming streams (think Starcraft and League of Legends tournaments) gathered from our very own Twitch.tv and Own3d.tv.

Let me know if you come across any bugs / new features you might want! I can be reached at jiggity - at - gmail.com

<comment><USER2> I thought it worked great -- thank you!

</comment></comment><comment><USER3> I'm getting a blank screen. I get redirected to [http://teevox.com/#!/c=streams&ch=24&s0=999999&s...](http://teevox.com/#!/c=streams&ch=24&s0=999999&s1=999997&p=3) and receive a 200 OK response but no response data. Using Chrome Version 21.0.1180.57 on Mac OS X 10.7.4

<comment><USER4> Ditto Ubuntu 11.10 + Chrome 16.0.912.77

<comment> X-Cubed Ditto Windows 7 + Chrome 22.0.1221.0

</comment></comment></comment><comment><USER5> Thanks for this! I used it ~twenty minutes before landing, and it was nice to see it from different angles (though it was all the same room). But together with this and the [Eyes on the Solar System][1] simulation, it was really cool to watch! I can see how this would be useful for video game streams.

[1]: [http://eyes.nasa.gov/launch2.html?document=$SERVERURL/conten...](http://eyes.nasa.gov/launch2.html?document=$SERVERURL/content/documents/msl/edl.xml)</comment>


30 years of being the only woman in the room — and how that's changing - <AUTHOR> http://venturebeat.com/2013/12/15/30-years-of-being-the-only-woman-in-the-room-and-how-thats-changing/

<comment><USER2> > "Girl" was one of those boxes, and he lost a killer co-founder because he > couldn't let her win.

in all fairness, these same alpha male-types do the same thing to men they perceive as non-threats. most of them have no problem pigeonholing men they deem weakly inferior into the same category as "useless slut." the best way to deal with them? emasculate them in every which way right from the beginning.

</comment><comment><USER3> > Women represent less than ten percent of venture capitalists, according to > the Kauffman Foundation. Per Pitchbook, only 13 percent of first-half 2013 > venture investments went to women.

When I do those numbers, it seems being a woman is a very significant advantage in this case? 30% above average success rate?

<comment><USER4> Venture investments are made _by_ venture capitalists, not _to_ venture capitalists. You're comparing apples and oranges.</comment></comment>


Notes from Tehran: Art in the Time of Sanctions - <AUTHOR> http://creativetimereports.org/2015/07/08/sohrab-kashani-notes-from-iran-art-in-the-time-of-sanctions/

<comment><USER2> Nice piece, thank you.

I very much admire Obama administration to take a diplomatic approach on this issue, and I believe when hopefully these negotiations are succeeded, this can be an evidence that how a conflict can be resolved in peace without the need to start a new war.</comment>


Turkey asks Twitter to open local office - <AUTHOR> http://www.reuters.com/article/2013/06/26/net-us-turkey-protests-twitter-idUSBRE95P0XC20130626

<comment><USER2> I would assume that opening an office there would mean they need a company there which means they will have to adhere to the law there.</comment>


WordsEye – Type words and tech creates a picture - <AUTHOR> https://www.wordseye.com/ <comment><USER2> You might also like the Scribblenauts series[0].

It's 2D and it doesn't include text-based positioning (or, indeed, any kind of freetext scene description -- you just 'summon' objects by typing their attributes+name), but its database of nouns and adjectives is notably vast, and it also includes a fairly sophisticated trait-based interaction system.

E.g. a 'hungry boy' will always seek food (that is, any object in the scene which has 'edible' trait). Combine that with the game's physics engine and recreating the classic 'carrot-on-a-stick' setup is few clicks' work.

To more directly compare the two:

Taking a random featured scene ([https://www.wordseye.com/view- picture/23507](https://www.wordseye.com/view-picture/23507)), here is my quick attempt at recreating it in Scribblenauts Remix (Android): [http://i.imgur.com/vkq3ha8h.jpg](http://i.imgur.com/vkq3ha8h.jpg)

Parts list: bike (x2), colossal white spotty sphere, cherry, immobile beagle, immobile strawberry, huge red sphere, huge red puddle.

The 'immobile' adjectives are used because the beagle would destroy everything by happily running around, and the almost-round strawberry would inevitably fall off the round top of the sphere.

[0] [http://www.scribblenauts.com/](http://www.scribblenauts.com/)

</comment><comment><USER3> I clicked the front page for a while thinking the demo would be editable.

</comment><comment><USER4> New epoch in UGC. Imagine how easily movies can be generated from user scenarios.

<comment><USER5> This future is already there !

[https://plotagon.com/](https://plotagon.com/)

<comment><USER6> I've used it, it rocks!

</comment></comment></comment><comment><USER7> Exciting to see the response to this post! People who would like to get access can use this link:

[https://static.wordseye.com/html/signup.html](https://static.wordseye.com/html/signup.html)

You will then be sent a personal e-mail invitation link as we work through the queue.

<comment><USER8> The link in the email is giving me 502 Bad Gateway

<comment><USER7> Hi Finnn,

Please try this link again:

[https://static.wordseye.com/html/signup](https://static.wordseye.com/html/signup)

You will then be sent an invite as we go through the queue.

There's been a lot of volume coming in today so we've made some changes to accommodate that.

Please let me know if you have any more issues.

<comment><USER8> Yes, i did that, it sent me an email with a link to

[http://www.wordseye.com/signup?action=confirm&auth_key=[reda...](http://www.wordseye.com/signup?action=confirm&auth_key=\[redacted\]&email=\[my) email]

which displays an error page that says 502 Bad Gateway

EDIT: Tried again without a + in the email and it worked fine.

<comment><USER7> Ah, great! Glad it worked. We'll look at the issue with "+" signs. Thanks for reporting it!

</comment></comment></comment></comment></comment><comment><USER9> Impressive, though the results aren't quite as good as [http://jimllpaintit.tumblr.com/](http://jimllpaintit.tumblr.com/)

</comment><comment><USER10> Only 2/3 of the "peacock" image is visible when viewing site on reasonably modern laptop, so "the ground is shiny" part makes no sense.

</comment><comment><USER7> There's been a lot of volume coming in today so we've made some changes to accommodate that.

Please click on this link:

[https://static.wordseye.com/html/signup](https://static.wordseye.com/html/signup) You will then be sent an invite as we go through the queue.

Look forward to seeing what you conjure up in the WordsEye Gallery!

</comment><comment><USER11> Wow, this is so ugly. It's eye-burningly ugly.

It fails at even the simplest request "The man is sitting in the chair" and oh, did I say how ugly it was?

</comment><comment><USER12> Why do I need to sign up for this? No, thank you.

</comment><comment><USER13> You can use PH_Nov2015 as an access code

</comment><comment><USER4> Access code: fb-arts-nov15

<comment><USER14> Doesn't work.

<comment><USER15> Works for me

<comment><USER14> Huh. Now it works for me too. Odd.

</comment></comment></comment></comment><comment><USER8> "Please provide your full real name."

Why could you _possibly_ need that?</comment>


Ruby on NetBeans lives - <AUTHOR> http://blog.enebo.com/2011/02/ruby-on-netbeans-lives.html

<comment><USER2> I'm still using the now moribund Python on Netbeans as my day to day IDE.

I'd love someone to pick that project up too. I recall someone looked into it and decided it was too big a job.

Shame because it's 90% there and definitely usable in it's current state.

<comment><USER3> The problem with niche open-source products is that you won't find enough developers to pick up development for free after they are abandoned by the original authors.

So, unless some company steps in to sponsor this and/or users start financing this somehow, there is a high chance that the module becomes less functional with every major release if API changes are introduced.

I work fulltime on a NetBeans Platform application (for a 3rd party, not Oracle) and I know the internals of the NetBeans community but I am still waiting to see a nice community hand-over of an open-source project/module.

The way I see it the limitation seems to be mostly economical -- developers need to eat too but developers are also the least likely to pay for tools.

<comment><USER4> Also, there are many "competing" open source IDEs. Potential contributors will likely join one of the live projects instead of trying to ressurect a dead one.</comment></comment></comment>