Enabling choice for Agile delivery Scrum teams - <AUTHOR> http://tonymaley.com/choices/ <comment><USER3> Creating software is about making the right decisions at the right point in time. Any decision by nature restricts choice. It is precisely the job of CTOs and architects to make decisions about partners, platforms, tooling and frameworks and to refrain from making these decisions at other times.

Should you empower teams to make their stack choices? I've seen chaos breaking out for a year in a major development organization with 500 devs when most teams suddenly were allowed to make some choices that better should have been made centrally. Yes, they were faster but they were faster going nowhere. And then there are all these aspects that go beyond the development phase - <USER2> term maintenance, behavior of software in the field / training field engineers and moving people across teams.

Good technical leaders know where choice is called for and where not. Managing these trade-offs requires a perspective that goes beyond the agile team.

<comment><USER4> I would add that one way to gently enforce the stack when the system is getting built from scratch is having a solid end-to-end "POC"/"skeleton"/whatever you want to call it built by a senior architect before the rest of the team is brought in.

Sure this requires an "architect who codes" type person to be involved (which can get expensive), as opposed to some ivory tower powerpoint architect but is typically worth it.

</comment></comment><comment><USER5> Too much chaos and choice and you slow down because everyone has done the same things in slightly different ways.

There's a fine balance between allowing choice and setting standards. There's productivity gains as well from having some standards -- you can built tools which leverage standards, so long as they aren't too restrictive.

e.x. In the world of microservices, you end up needing a lot of telemetry to keep things running smoothly and figure out what goes wrong when your call is four levels deep. Doing so is hard without having a standard to which your services must adhere to. It's easiest if you have a base application which takes care of that for you. That, however, becomes hard if you have the combinatorial explosion of [languages] x [frameworks].

That doesn't mean you shouldn't entertain new choices, (hey, team X wants to use Go.) but there should be some discipline. It boggles my mind when individual engineers prefer to speed up their development for the short-term vs. the overall organization.

</comment><comment><USER6> Everyone should know about Conway's Law [0], especially in the age of microservices.

I currently work in an environment where there is virtually no central technical management. There are groups of 2-4 developers who roam around their department's problem space, making whatever choices they want.

If someone doesn't like the interface on one microservice, they fork the code and make a new one. This leads to 5 microservices that accomplish the same thing, and 5x the maintenance burden whenever something changes. I've derisively called these "nanoservices", but I need a more offensive term.

People intentionally choose techs that no one else in the company has used, trying to cement their position and hedge up potential competition or unwelcome cooperation. They also select technology for the best PR effect, being able to say "We're being like Google today". The result is a whole mess of different stuff running throughout production, each needing _its own_ backup system, etc., which, to be honest, does not always get installed.

It's a disaster.

The author's contention is that giving more choice to teams is better because it makes them feel more ownership in their product. That's fine, but do recognize that this is a psychological solution to a management problem. The job of the manager is to actively control the psychology of employees and the structure of the organization such that employees are happy to do things that lead to cooperation, not to allow employees to always get their way.

Without a central coordinating force and everyone's acknowledgement that some compromise and sacrifice is necessary, everything falls apart quickly.

[0] [https://en.wikipedia.org/wiki/Conway%27s_law](https://en.wikipedia.org/wiki/Conway%27s_law)

<comment><USER7> Conway's Law in your environment should probably be interpreted that you have a team that can't talk or work together at all. It has nothing to do with what technical choices they are making, even if you imposed a rigid technical structure you would still have divergent nanoservices because your team can't communicate.

<comment><USER6> No, it's not that they're incapable of working together. It's that they have no incentive to do so. They can do whatever they want now and improve their own positions by so doing, so why shouldn't they?

Normally, people don't do this a) because they don't want to be required to deal with the cruft or b) because they believe someone will observe their bad behavior and stop it. They don't really have to deal with the cruft, and it's clear now that no one in this organization will hold them accountable, so why should they waste time and energy trying to build a consistent platform?

re: Conway's Law, the organization's communication mechanisms are loose and ad-hoc; there is no central coordination. Consequently, the software is coordinated on a loose, ad-hoc basis between small teams. The same featureset will be implemented 4 times by 4 different teams, not because they _can 't_ talk (there is an office where most people hang out together all day, and people do generally keep an awareness of what the other group is working on), but because they'd rather just do it the way they want to do it.

It's not that no one ever ends up sharing anything. It's just that instead of having a discussion and making consistent decisions about the platform, they just do what they want, because they can.

<comment><USER7> Even if you imposed a singular stack, I could just do it my way at whatever level you started to let me make decisions. All you end up doing is adding overhead to your basic problem which is your teams are not communicating, fix that problem and your tech stack becomes irreverent. People will start to talk and start to organize into best practices simply because its easier ( why reinvent the wheel if Jim in accounting already did it and I can just use his stuff )

<comment><USER6> Yeah, but again, the people aren't necessarily mean-spirited or hostile. They'd cooperate more if the structure to affect that existed.

You're acting like they don't talk. They do talk, they just don't care. They know that guy x is making thing y, but they don't want to do it in the language/platform/framework/whatever he's using, so they make their own thing y. Structure needs to be in place to make cooperation happen.

<comment><USER7> No it doesn't. If thing Y was remotely complicated and if the teams had a good working relationship why would they choose to duplicate their work. Even if it was in a completely different tech stack you would still try to leverage someone else's work and there are plenty of ways to do that in almost any situation across most technologies. Also even if a rigid structure existed I can still not use your thing Y most likely because I don't respect your work and I would implement thing Y differently ( and in my opinion better ). Then you get thing Y and thing Y+1. The problem isn't people chose different tech stacks its they don't want to work together. If they did they would choose tech stacks and work practices that foster collaboration.

<comment><USER6> >If thing Y was remotely complicated and if the teams had a good working relationship why would they choose to duplicate their work.

So many reasons, but they usually boil down to simple self-importance.

Also, remember that it's harder to read code than to write it. Any non-trivial library or service is going to have a learning curve.

>Also even if a rigid structure existed I can still not use your thing Y most likely because I don't respect your work and I would implement thing Y differently ( and in my opinion better ).

Everyone has their own opinion.

In a rigid structure, this perspective wouldn't work because your paycheck would be imperilled by it.

>The problem isn't people chose different tech stacks its they don't want to work together.

Sure, I agree. In a correctly organized structure, their incentives would change, and their behaviors would be more cooperative.

>If they did they would choose tech stacks and work practices that foster collaboration.

No, that's like saying if people wanted unity, they'd make choices everyone would agree on. Everyone wants unity. They just everyone to unite to _their_ idea of what's important/right.

Management is all about crafting an environment and structure that causes people to work in a productive way. That _could_ happen in this company, but it hasn't.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> As a person who this article is saying should be empowered to have more choice, choice is a dog whistle for Not Invented Here. The people you employ to build your software will often make the _straight up wrong choice_ when given the opportunity, and a lot of that time the "choice" will be to homebrew a solution that already exists elsewhere, because it's perceived as simpler than taking the time to understand an existing technology.

The reasons that get hand waved away in this article are _exactly_ the reasons you can't ignore consistency across teams. There _is_ value in having just one library that multiple teams use to communicate via HTTP to various services, there _is_ value in members of different teams being able to work across projects due to the similarities in infrastructure. If each team has their own client library for communicating with a service, that's work you've paid for twice, or more.

I clicked on this article thinking it would be about choice within the prioritized stack on what to build and when, because _that_ is valuable. Letting the folks building the stuff decide which things to build first is _much_ more valuable than letting them pick between Postgres and MySQL, or memcache vs. redis, etc. (just examples, don't get too wrapped up in them).

Sure, we can sit here and come up with exceptions to choice, and yeah I do like being able to choose my IDE, the OS I develop on, etc., but those choices are totally different than which relational database I use, or which web framework I develop with. There, I don't think choice is good, at least not for everyone. Maybe this is written for my boss's boss, I dunno. But as for me, the dev writing the code, I don't really want me (or my colleagues) to have all that much choice.

<comment><USER7> Its interesting trying to figure out from your comment what kind of people you intend on working with. On one hand you conclude that given the opportunity your employees will wake the wrong choice. So if you can't trust them to make good decisions what do you trust them with? If they can't make tooling choices can they make algorithmic choices, if they can't make algorithmic choices can they really decide what kind of language constructs to use.

If I can't trust you to make a good choice on which technology to use why do I think I can trust you to make good choices in other aspects of your job. If you don't feel confident to make a technical choice then what you are telling me is you don't understand, and don't want to learn. Not really a desirable quality.

<comment><USER8> I don't have the information to make the "right" choice, because I don't attend the meetings you do, I don't generally care what happens when a new hire gets here, I don't care how the company spends money on writing 3 different client libraries, etc. Those aren't decisions that are tied to my compensation, my quarterly goals, and leadership doesn't come for my head when they find out about the bill they're paying for.

My expertise is in designing and building software, not in organizing teams for optimal productivity. The tools and tech that make the most sense for my project will get me to 100% optimization, but if I pay down a 5% optimization cost to bring all teams in my organization 80% to 90%, a _manager_ should be the one making that choice, not me.

Pretending like everyone has the visibility into the org like you do _will_ get you into trouble, and giving that visibility to everyone _will_ harm their ability to focus on their jobs. I'm not a manager for a reason, I don't want to make those choices, but I _need_ someone to.

Also, not everyone gets to work at Google. Advice like this needs to have value at Medium Sized Company, Inc., because those are the people who are most out in the cold. An Apple product manager has every tool on the planet available to him/her to figure out how best to help his/her team, but the guy/gal managing a dev shop in Carson City might not.

<comment><USER7> The choices a manager makes are very different from the choices a technologist should be making, and its not about what tools or tech stack you are working with. It is about things like how do I enable my team to deliver, because one thing people love to do is see how they can make excuses for failure to deliver. At the tech level its about how leadership and management makes poor choices, at the leadership level its about how your workers are lazy and unable to perform under such and such a condition. In reality its both parties trying to insulate themselves from failure by having a scapegoat.

Empower your tech teams to do great work, it doesn't require you to be a google or apple, or podunk startup. I have seen empowered teams at 10 man contact shops and 100,000 fortune 100 companies. If you run into a company that tries to tell you something else run away, you will find politics and infighting alongside terrible technology and an inability to deliver

<comment><USER8> If you let your teams individually choose their tech, they will be empowered to duplicate work, and they won't be able to cross pollinate or provide expertise/support to any team that's picked a tech stack different from theirs.

Doesn't this just encourage silos?

<comment><USER7> If the teams are working on similar problems, and if the teams actually work together they will stabilize on a singular stack. There will be cases where work will be duplicated, and there will be cases where tech components need to be refactored because the stack has changed, but you will end up with a very well known and understood set of tech primitives that your services are built out of.

There are lots of reasons why you may never hit that state of everyone self selecting the same or a very similar stack, but they are never technical and they always indicate a team structure problem that is going to cost you way more if you don't deal with it then the amount of duplicated work you might encounter

</comment></comment></comment></comment></comment></comment><comment><USER9> Wow the comments here certainly seem to be against allowing developers any input in the tools they use. I guess you all are part of the reason I have to use Java 7 and outdated versions of Angular in my day job no matter their applicability to the problem domain and have no input in those decisions.

I agree that total anarchy is bad in the workplace, but don't you think that the people using the tools should have some input in choosing the tools?

<comment><USER10> I, for one, want to see something beyond the shiny-toy syndrome when I talk to a team member about why we need to use the tool/technology/framework/library in question. I'm all for personal improvement, and every technology, regardless how different it is, that we learn/become familiar with makes us better professionals. But sandbox to production is a long way. Keeping things simple has its merits.

</comment></comment><comment><USER7> In my experience the team should be free to make whatever technical choice they want. The only reason you get dictation from on high about what choices should be made is because your technical leadership lacks the technical depth to advocate for a common stack that is actual useful. Every time I have seen an origination talk about standardizing on some language or framework and its hasn't grown out of the engineering community at that company its been because leadership didn't have a strong technical background and they were making choices based on marketing material, sales reps, or consultants.

The best standardization I have seen grew out of a team who was empowered to make decisions, made good decisions, showed how their decisions were good for the entire origination and helped everyone migrate to one solution which turned out to be pretty good at solving everyone's problems.

If you as a leader find yourself pushing a standard tool set to a team who is hesitant to adopt it the problem is most likely you.

<comment><USER6> You assume that everyone in the company is acting rationally, and that everyone has the same goals and values. This is usually not the case.

The truth is that for most types of applications, there are several technology stacks that would be perfectly adequate. You get into the tradeoffs, and unless the benefit posed by a specific thing is immediately obvious, these are a matter of subjective judgment. Great technical minds will have differing subjective judgment; no one's judgment is exactly same as another's.

People also usually do not understand their own motives. This is the origin of fads. Everyone suddenly agrees that THING_Y is the best, and then, the next year, everyone suddenly believes it's THING_Z now. If someone can present a dense, semi-passable argument in favor of it, the rest of the uptake comes down to marketing. This is true _no matter how smart you think you are_.

If you have a technician who prides themselves on always knowing about new technologies, and that's their reputation, it's likely their primary motivating factor will be continuing to propagate that self-image. They might not even realize it.

They will come and say "There is a new tech called TECH_X and it allows us to do these amazing new things!" As long as TECH_X has _some_ value proposition and isn't a blatant or obvious bad fit (meaning obvious and blatant to _everyone_ ), their argument is plausible enough and they'll run with that.

They think they're doing this because they learn all the new things and it gives them a competitive edge. In reality, it's because they view themselves as cutting edge, they want everyone else to view them as cutting edge, and need to feed themselves and everyone else some proof validating that desirable conception.

The difference between "political schemers" and your average employee generally comes down to their naivety around the universality and importance of these functions. Which is another danger -- the less-naive employees in the ranks will be actively working their own angles here to attempt to manipulate the psychology of the people around them. This can and does invade technical choices. You can make the best arguments in the world for your stack, but if you have a political competitor, they will work to undermine you, often in non-obvious ways. If they feel now is the time to strike and they can embarrass you, they'll do so; if not, they'll agree and subtly work to sabotage your plan.

There's another type of employee here; the type who wants to keep his day job on cruise control, and will oppose anything new because it would make his short-term daily existence more difficult (and perhaps long-term if the improvement could reduce inefficiencies so much that he becomes redundant), regardless of organizational benefit.

There are many arguments to be made in favor of keeping the status quo, so he will look OK; if your new stack is a wild success, he will be able to say "Oh, I just needed some time to come around" and if your new stack is an abject failure (which happens much more often than people wish to admit, and even more often, it's made to _appear_ an abject failure by political competitors regardless), he will be able to say "I told you so".

People are naturally self-interested and will behave that way all that time. Management must look outside of the individual goals of the employee or team and consider what is in the long-term interest of the organization.

tl;dr This is naive; a purely democratic approach doesn't work because people's goals and values don't necessarily align.

<comment><USER7> What you have just described is the political reasons for not giving your employees agency in making their own decisions. Technically, while each stack might provide similar value proposition, familiarity and experience with a given stack are an organizational value that even given two equals would cause any rational person to pick the known and understood stack. Essentially you nailed the facts with your first line. If everyone is rational and had the same goals these things sort themselves out. Problems arise when people are not acting with the same goals or values, and on occasion they are not acting rationally ( it has been my experience that differing goals and values are so frequently the cause that assuming irrationality is just noise you can ignore )

So given people with differing goals and values they come to different conclusions about how to pursue those goals. Unless you hire sociopaths most of your employees will want the firm to do well and work with functional tech stacks that accomplish the stated goal of the company. However people in tech leadership don't always share that goal. They make decisions based much more on personal utility then the average worker. They might sign that sweetheart deal with a vendor because they see it as an avenue for a career change in the near future, or they might want to make sure no one below them starts to outshine them so they keep the stack something they understand ( knowing full well that someone not in leadership has much more time to persue learning ), or they know if they force an outdated but well known stack they can hire cheap.

In general none of those conditions are good for people actually doing the work and they know it which is why they push back. It gets propagated up the stack as naivete or fad chasing, but in general its leadership insulating their position ahead of the company or their co-workers. Those leaders fail and those companies fail. When decisions like this are pushed down from on high look out, its generally a sign of bad culture and a bad company

<comment><USER6> >Technically, while each stack might provide similar value proposition, familiarity and experience with a given stack are an organizational value that even given two equals would cause any rational person to pick the known and understood stack.

This is not at all the case. There are many rational arguments to be made for abandoning an outmoded-but-already-in-place practice or stack, regardless of the knowledge base that already exists in the company. Many people could and would suggest a conversion to a new platform in good faith. Sometimes this would be the right decision, and sometimes it wouldn't; it really depends on the particulars of the organization.

> If everyone is rational and had the same goals these things sort themselves > out.

People are not always going to have the same goals. You can't limit your organization to a subset of people who are all ideologically aligned.

Also, people frequently don't understand their motives for something; that is, they ascribe some rational-sounding reason to behaviors they are biologically driven to perform. They may fully believe their goals are aligned, but come to find out, they're not.

>Unless you hire sociopaths most of your employees will want the firm to do well and work with functional tech stacks that accomplish the stated goal of the company.

Sure, and since there are many tech stacks that would do well, this doesn't mean anything. People can disagree. When they disagree, the subjective judgment on the tradeoff must be passed up to a central authority.

>However people in tech leadership don't always share that goal. They make decisions based much more on personal utility then the average worker.

You're grossly overestimating the "average worker". The average tech workers wants to keep his job simple and easy so he can browse reddit all day at work.

You also assume that these things don't factor into the decisions of average workers. They do. Some workers aspire to be leaders, and, less naive about human nature, are willing to employ some showmanship and artifice to get there.

>In general none of those conditions are good for people actually doing the work and they know it which is why they push back.

None of the conditions you listed are good, but mature technical leadership, including standardization on a reliable stack (and, of course, a willingness to make rare-but-justified exceptions) is a boon to all.

>It gets propagated up the stack as naivete or fad chasing, but in general its leadership insulating their position ahead of the company or their co-workers.

There is a great deal of naivete and fad chasing everywhere, inside and outside of leadership. The ability to recognize it is valuable.

>Those leaders fail

Quite the contrary. Leaders do these things because, as long as one maintains plausible deniability, they are rewarded richly.

>and those companies fail. When decisions like this are pushed down from on high look out, its generally a sign of bad culture and a bad company

Companies that understand human psychology, both in the public and in their employee base, are extremely successful, because ultimately power comes down to the consent and resources of others. They are also usually the companies people most want to work for.

</comment></comment></comment></comment><comment><USER11> Too many technologies is a problem so teams shouldn't be able to choose anything. My wider team is 50 people made up of ~8 smaller teams. We have some flexibility to choose technology with the result of our new product: * Core system JVM * Python wrapper for web service API * C# scraping calling the web service * JS/node webserver calling the C# layer

As a result its slow, messy and difficult to maintain. Would be nice if managers prevented small teams from choosing any technical choice they felt like.

<comment><USER10> _> Would be nice if managers prevented small teams from choosing any technical choice they felt like._

That requires knowledge, experience, and good technical & business judgement. Unfortunately not everyone has these qualities. Refusing something simply for keeping things as they are is not a sustainable strategy in technology. Decisions have to be made smart, and they have to contribute to the incremental improvements.

</comment></comment><comment><USER12> I don't have a choice: I _must_ use a broad array of tools and languages.

The gamedev stuff I've helped tackle fundamanetlaly required mostly C++... and a little C, and some x86/ARM/PPC for debugging, HLSL 3-5/GLSL ES/PSSL/<custom shader DSLs> for porting graphics, at least two shell scripting languages for CI servers (Bash, and Powershell or (ew!) Batch), Python (for various modeling tools)... Java, Objective C, and C++/CX for platform specific APIs... MSBuild, Makefiles, Gradle, Ant... and that's just the languages! The tooling front is no better.

A handful more language choices that theoretically could've been avoided (e.g. C# for tools and server stuff, ActionScript for UI) is really not that big a deal in this context. You can add pointless layers of cruft, but I've only seen it once - a Python script used to hack up the result of a C++ program. Even then they had a reason: some of the C++ didn't get checked in, so we couldn't even build the C++ program. (A happy ending: With a little reverse engineering of the resulting binary output, I was able to re-implement the missing C++ bits, implement the Python-script 'fixes' more cleanly in the original C++, and add my own necessary changes on top of that.)

</comment><comment><USER13> I work for a shop with more than 200 devs. Over the years we had multiple efforts to standardize the libraries, platforms we use only to very limited success. While things like CI software and IDE got pretty much standard without any intervention to this day there is no consensus for library x to do y. The overall sentiment resonates with me and what I've seen at my workplace

</comment><comment><USER14> He seems to be ignoring long-term maintenance costs. If you're building a $0.99 app then sure let the team pick whatever they want. But if you're building a huge SaaS web application with an expected 20 year lifecycle then that cuts the range of sensible choices way down.

</comment><comment><USER15> Choices break naturally on time and platform boundaries. New projects should review stack choices, and enforcing cross-platform stacks is usually too brittle.

</comment><comment> gm-conspiracy Creativity leads to anarchy.</comment>


Protecting People On Facebook - <AUTHOR> https://www.facebook.com/notes/facebook-security/protecting-people-on-facebook/10151249208250766

<comment><USER2> There is one specific step that everyone can take to eliminate approx 90-95%+ of drive-by-zero-day-exploits without really impacting your web browsing habits that much:

Disable Plugins on your primary browser.

Whether that be Opera/Safari/IE/Firefox - just disable the plugins. Then, all of these Java 0days, PDF 0days, Flash 0days won't impact you.

Keep a backup browser, that is _not_ your primary, and use that for your SSL VPN (frequently Java), or Crappy Enteprise Apps like timesheets and Remedy (frequently Flash).

Yes, browsers have 0days as well, but they occur much less frequently (approximately 1/10th) than plugin vulnerabilities, and get repaired much more quickly.

For the really security conscious, of course, browsing from a separated/virtualized thin-client is even better, particularly if you can live with the hassle of refreshing your cookies every so often after a reset.

<comment><USER3> This is good advice, but I'd amend it to say this:

For your __Facebook __-viewing browser, disable all plugins. For the most part, you won't be viewing anything that can't be viewed without HTML5 and Javascript anyway. The added advantage to sequestering FB activity to a browser is that you won't be tracked by sites that use FB widgets.

Another added advantage of putting FB in its own browser, and YMMV, but it's easier to prevent impulsively checking FB in the middle of your normal work- related internet browsing, as it requires opening a new browser to do so.

<comment><USER4> You start running out of browsers quickly, and seperate browser users gets tedious fast. I really wish there was easy same browser sandboxing that can save cookies and so on. Double click the gmail icon, and gmail comes up in a browser user devoted to just gmail, and shows up as a separate process and separate app. All of the 'make a webpage an app' apps that I've tried still share browser state amongst the main browser user.

<comment><USER5> This is easy to do with chrome. I have many different profiles, all of which are completely separate. Just launch with the --user-data-dir argument:

        #!/bin/bash

        exec chromium-browser --user-data-dir=/home/jewel/.profiles/facebook -app=https://facebook.com

<comment><USER6> Does that both specify the custom profile location, and also launch the FB app?

I'm looking at this, trying to think of how to do the equivalent in Windows.

<comment><USER5> It launches it in app mode (no tabs, no URL bar). I'm not sure if that's the same thing as launching the FB app.

In windows you copy the chrome shortcut and then edit the shortcut to add the command-line arguments. Then you add the shortcut to your launcher bar.

Alternatively, you could create a batch file for each site that you want to isolate somewhere in PATH and launch it from the Start -> Run menu. In other words, you'd press the start key, then type "facebook", then press enter.

(Please correct me if my instructions are incorrect, I haven't used windows regularly for a long time.)

</comment></comment></comment></comment></comment></comment><comment><USER7> This happened last month, so it was 0-day THEN, not NOW.

The hole in question was patched in the February 1st Java release, plus the way the Java plugin works now (and how most browsers handle Java now) even if there are still holes remaining in Java, the user will have to click through at least one, probably two warnings before they can run the dangerous applet.

So far the latest fixes (in browsers and in Java) seem to have been effective.

<comment><USER8> > ... even if there are still holes remaining in Java, ...

Heh

> ... the user will have to click through at least one, probably two warnings > before they can run the dangerous applet ...

Unfortunately, there are still way too many users who will happily click through those warnings (unsigned code, invalid certificates, UAC, and so on) in order to {look at stupid pictures|play retarded games|win a free iPad|...}

<comment><USER7> Not many Facebook engineers, though, I suspect.

And it's worth noting that even less technical users aren't so likely to click through all of the warnings when they're _not_ expecting some kind of interactive game to play. That also reduces the risk.

There will always be some people who click the links in their spam or open the fishy attachments, who give permission to anything and everything, and whose computers are so overloaded with malware, trojans, backdoors, etc. that they collapse under the weight.

The main trick is to be sure that savvy users can keep themselves safe, and making sure people doing important things on their computers are savvy.

I think Java is finally in a state now where it's safe for savvy users.</comment></comment></comment>


We're Drowning in Tech Debt. Why Isn't Anyone Listening? - <AUTHOR> https://hackernoon.com/were-drowning-in-tech-debt-why-isn-t-anyone-listening-f4269cb5cc40 <comment><USER2> I recommend reading The Mythical Man Month[1] to anyone interested in proper SWE project management. There are so many wannabe managers out there that will just through more people at a project which is slowing down.

To quote the book: "Adding manpower to a late software project, makes it later". There's some really good stuff in there, even for those of us that are less interested in management.

[1]: [https://www.amazon.com/Mythical-Man-Month-Software- Engineeri...](https://www.amazon.com/Mythical-Man-Month-Software-Engineering- Anniversary/dp/0201835959)

<comment><USER3> I keep recommending it to my younger colleagues but they just make polite noises and forget it.

Some of Brooks' suggestions for the make up of a development team are interesting. In particular I have always liked the idea that there should be a toolmaker. Most of us are less efficient than we could be because we lack specific tools to do the job and we don't personally have time to make them. If we had someone who's only job was to make tools I think a lot of things could go faster. Of course this only applies to moderately large teams.

<comment><USER4> I'm my team's toolmaker. There's just so much lost opportunity in custom tools doing repetitive tasks, it's strange that you would leave that on the table.

But I'm not getting paid for it, my manager doesn't order it. He's kind of happy to see us getting more efficient with less bugs. But it would be good to have some support.

</comment></comment></comment><comment><USER5> Because when you wait a little bit and work on something else for a while, original requirements will change and you don't need to refactor at all.

</comment><comment><USER6> Tech is time, time is money. There always an ajustement tech-money. You can't promoting new tech or refactoring without looking contingencies. What you need is just a circular graph. Who can be a vicious circle or a virtuous cycle, depending who is in charge.

</comment><comment><USER7> IME this is why some new companies are extremely choosy with hires for a long time. The newer/smaller the company, the less time there is available for oversight of each other's work. That is not to say zero review happens, but if you're trying to move fast, trust and confidence in what the rest of the team is doing facilitates that.

This may sound overly negative or controversial, but I think there are a lot of tech workers out there that are technical debt factories. They'll produce highly coupled code, super long functions, inefficient code, etc...and be extremely defensive during code review. The mantra you'll hear from this person is, "but it works!" \- which is exactly what the PM will hear.

So it gets shipped. After this happens enough, "simple" changes to the product that should be easy to produce, aren't so simple.

</comment><comment><USER8> Imagine you're a CEO, or VP sales, or anyone with responsibility for moving the company forward. Lets say you have a technical background and actually understand how bad things can get with a codebase.

Its year 2 and you're desperate to ramp sales. the company is in existential crisis, the end of the runway is approaching rapidly. The product ostensibly works, but there are lots of customer problems and new feature requests always seem to get bogged down.

Your technical leaders say that the product has driven into a swamp, and you need 2 months to dig it out, plus 30% overhead ongoing to finish the cleanup and try to keep on the straight and narrow.

Even though its the right thing to do in some world, how likely are you to say 'I understand, take all the time you need, we don't want these problems plaguing us'

<comment><USER9> Well that's what happens technical debt is not properly accounted for. It can kill the company. That's what's so scary about it.

</comment></comment><comment><USER10> Fractional reserve software system

</comment><comment><USER11> The solution? Get Real [https://github.com/DeBraid/tech- notes/blob/master/basecamp-g...](https://github.com/DeBraid/tech- notes/blob/master/basecamp-getting-real.md)

37signals wrote a book on this a decade ago before they changed their name to Basecamp. It is loaded with practical advice on how to build good software and avoid technical debt.

Aside: no affiliation, just a fan of the book.</comment>


WWDC 2014 - <AUTHOR> https://developer.apple.com/wwdc/sessions/

<comment><USER2> Lottery! I think this is much better... The server issues of recent years have been pretty annoying. See you there. Maybe.</comment>


Google's blanket ban of cryptocurrency ads ends next month - <AUTHOR> https://techcrunch.com/2018/09/25/googles-blanket-ban-of-cryptocurrency-ads-ends-next-month/ <comment><USER2> Google's new mantra: "Whatever it takes to make an extra buck."</comment>


The Future of Enterprise Software: I Am So Scared, I Am So Excited - <AUTHOR> http://7thursdays.wordpress.com/2008/04/25/the-future-of-enterprise-software-i-am-so-scared-i-am-so-excited/

<comment><USER2> $100 million and they couldn't develop something decent? I'm perplexed on why/how other companies didn't sue SAP for this and just swallowed the pill.

QFT: "...you really can't fool all the people all the time."

</comment><comment><USER3> I occasionally scan job postings, and when I come to the letters,

 _SAP_

...I just instantly close the page. I don't even know that much about them, but everything I've heard suggests they are IBM minus the illustrious history.

<comment><USER4> The general perception seems to be that "SAP is expensive, difficult to implement and often doesn't work".

At least, that's what a SAP sales person said in a speech he gave at an event for SAP implementation partners.

<comment><USER5> That's a heck of a sales pitch!

<comment><USER6> At least he's candid.

</comment></comment></comment></comment><comment><USER7> Willie Sutton robbed banks because "that's where the money is".

Do you suppose that if he were a hacker today, he would be writing enterprise applications?

Enterprises are like oil tankers; they take forever to turn. But, as stories like this show, they have to turn. Say tuned. I wanna be around (with software in hand) when it happens.

</comment><comment><USER6> About time! As Alex Papadimoulis explained when he (briefly) changed the name of The Daily WTF to "Worse Than Failure", the problem is not just that so many software projects fail, it's that so many are passed off as a "success" just because they are finished, even if they don't work. That's "worse than failure" because at least you learn from failures.

I think the free market could curb the "software quality problem" but only if software companies are held accountable. If there were more awareness among software customers of the low quality of most software written, and a potential that a software company gets the bejeebus sued out them for shoddy work, then there are several good things would come of it: 1. Companies producing shoddy software would go out of business instead of scamming their way along. 2. When their asses are on the line, maybe they'll start demanding some quality before quantity. 3. Maybe we'll finally see a state or national licensing requirement for programmers, like there is for nurses and doctors.

</comment><comment><USER8> Can we stop blaming Jesse Spano already? It was like over a decade ago, and it wasn't her fault!

<comment><USER9> I know, caffeine pill addiction is a sickness.

</comment></comment><comment><USER10> I think the Waste Management company is brilliant, and deserves respect. If you spend a hundred bucks for something that doesn't work, you would ask for a refund. I wonder why companies didn't do this before. Capitalism is dying because companies are no longer run by owners, but by "managers".

<comment><USER11> _I wonder why companies didn't do this before._

I can shed light on one aspect of it. In large companies, if a failure is too big, it gets rebranded as a success. There are many strategies for doing this. (In one I saw, the failed project was spun off as a separate group to leverage all the "value" that had been created.) Absurd as this may be, it works, at least internally (and most failures are never made public).

This used to puzzle me, but I think there's a simple reason for it. It's ok to discuss minor failures because these can be blamed on middle managers. Huge fiascos, on the other hand, can't be. A huge fiasco was a huge project to begin with, and huge projects are sponsored by executives. These leaders are, like Madame X from the Flintstones, "much too important to be lost". Ipso facto, they can't fail.

What this means is that if the failure took place at the hands of a vendor, they will probably get away with it. Trying hold the vendor accountable makes _you_ look bad. You can't brand the project a "success" and at the same time claim they didn't deliver.

So Waste Management is unusual among large companies, which (I believe) are frequently taken to the cleaners on these enormous software projects. What's hard to explain is why they decided to take such public action. Perhaps they have a leader of unusual courage or integrity.

<comment><USER12> They probably felt they were respected like crap by the vendor. When one party has a disagreement with another, and there's a clear and obvious disparity in some kind of standing (be it social, financial, racial, age), the party getting screwed over may feel they need to take action against this or have no trouble gaining confidence to stand up against a perceived injustice, since they're fighting two battles for the price of one. It doesn't matter if the second cause has nothing to do with anything, such as if the difference is only perceived or didn't matter in the situation.

Whereas in actuality, the other company in question is likely simply trying to rip off everybody equally (equally, in other words, meaning as much as possible.)</comment></comment></comment>


The ACLU has stopped border agents from demanding ID after domestic flights - <AUTHOR> https://www.theatlantic.com/ideas/archive/2019/07/no-more-identification-checks-domestic-arrivals/594334/ <comment><USER2> ACLU donation page: [https://action.aclu.org/give/donate-to-aclu- multistep](https://action.aclu.org/give/donate-to-aclu-multistep)</comment>


Chomski virtual machine - <AUTHOR> https://en.wikipedia.org/wiki/Chomski <comment> guard-of-terra The name is to loud for what we see. And why is it a virtual machine? It has to work with actual words (e.g. tell noun from verb) to even aim at its name.

</comment><comment><USER2> _It currently does not support unicode strings, since the current implementation uses standard C character arrays_

... err, just a tiny issue!</comment>


Crime Survey Raises Questions on Data-Driven Policies and Falsification - <AUTHOR> http://www.nytimes.com/2010/02/09/nyregion/09mayor.html?hp <comment><USER2> Hmmm, this is why you _always_ match data produced in "the system" with independent survey data from the population.</comment>


Could Web Equity Save The Aussie Tech Startup Industry? - <AUTHOR> http://www.technation.com.au/2008/08/04/could-web-equity-save-the-aussie-tech-startup-industry/ <comment><USER2> The problem is that Australia lacks a startup culture. There are few people to learn from, and few opportunities for those who want to join startups. I was lucky as with my US citizenship I was able to move to the Bay Area to get the opportunity I wanted.

Now, if we could convince some of the 100,000 ex-pats in California to move back with what they've learned...</comment>


Ry: the simplest virtual environments for Ruby - <AUTHOR> https://github.com/jayferd/ry

<comment><USER2> Some clarification on how this differs from rbenv would be in order. Personally I'm still using rvm without problems, but I've been intrigued by the simplicity of rbenv (especially since Bundler makes gemsets obsolete). If this is significantly simpler, how? And given that it's brand new, what kind of scenarios has it been developed and tested with?

<comment><AUTHOR> Good point. A major part of the simplicity is that ry doesn't need to be loaded into your shell or shim any binaries. You simply add $PREFIX/lib/ry/current/bin to your $PATH (there's a helper to do this), and vanilla ruby/rubygems take care of the rest.

Ry also punts on indexing and listing the various implemetations of Ruby out there - you give it a reference name and a source tarball url, and it runs ./configure PREFIX=...; make install. That allows it to be magic-free with respect to naming different rubies - just give it a shortcut name that you'll remember.

<comment><USER3> If I understand this correctly, I can only have a single Ruby active at a time, even if I have multiple terminals open, right?

<comment><AUTHOR> By default, yes. But you can also use your $PATH to select a particular ruby per session. The `fullpath` helper is for that:

        export PATH="$(ry fullpath mri)"

</comment></comment></comment></comment><comment><USER4> This space seems to be crowded lately. There's also the newish rbfu[1], which also aims to be a lighter tool.

It's not directly relevant to Ry, which doesn't use such files, but there's now even a proposal to standardize around a .ruby-version file for these env managers[2].

Also tangential, but Mislav Marohnić probably wins the prize for _simplest_ Ruby version manager[3].

[1] <https://github.com/hmans/rbfu>

[2] <https://gist.github.com/1912050>

[3] [https://github.com/mislav/dotfiles/blob/93c0cd3/bash_aliases...](https://github.com/mislav/dotfiles/blob/93c0cd3/bash_aliases#L58-69)</comment>


The Commentator -- Automagically sprinkle your code with snarky comments - <AUTHOR> http://www.cenqua.com/commentator/ <comment><USER2> lol - nice find</comment>


Brazilian wasp venom kills cancer cells by opening them up - <AUTHOR> http://phys.org/news/2015-09-brazilian-wasp-venom-cancer-cells.html <comment><USER2> Since we are on the subject of cancer - allow me to pen down a few thoughts for those interested in the subject.

(a) You already know that ...Cancer could be caused by hundreds of different mutations in the genome that would disrupt a cell cycle control pathway. Which means it becomes increasingly difficult to find a single bullet solution to all cancers.

(b) You already know that ... Even if you find a way to target cancer cells, how do you differentiate between good cells vs. bad cells

(c) You may kindda know that... Researchers are trying hard to find specific markers on the cancer cell membrane, to differentiate them from good cells and target them for destruction. The WASP venom thing is another idea ... but venoms have been known to target calcium/calmodulin channels. So nothing too fancy.

(d) You may not know that... The most promising research in cancer therapy is to disrupt metabolic pathways of cancer cells. You see, doesn't matter what pathway led to the cause of cancer ... but they all need food to divide. If you could terminate their food supply, disrupt a metabolic pathway .. then there is a chance of stopping them...as a generic bullet for all cancers, irrespective of what mutation caused it. Furthermore, the metabolic pathway of cancer cells and normal cells are distinguishable.

Read more: Warburg effect and a paper that was published this year: [http://www.news-medical.net/news/20150626/SLU-researchers- fi...](http://www.news-medical.net/news/20150626/SLU-researchers-find-way-to- stop-growth-of-cancer-cells-by-targeting-the-Warburg-Effect.aspx)

<comment><USER3> (e) You may not know that ... cancer prevalence depends heavily on vitamin D levels. People living around the equator have a 40-60% lesser chance of getting cancer than people living in the US, Canada or Europe. This is even true for people living in Florida. We don't get enough UV-B from the sun, not like centuries ago when we didn't have to work indoors and didn't use sunscreen. People with dark or darker skin have an even bigger risk.

The risk of getting nonmelanoma skin cancer from UV-B is relatively low, and it's easy to treat. Melanoma skin cancer is dangerous, but not related to sun exposure. Taking vitamin D using pills or getting enough sun exposure (without sunscreen) without getting burnt may be the cheapest and most easy way to reduce cancer risk.

Below some links, these about breast cancer. AFAIK these numbers are similar for other cancers like liver, lung, colon, etc.

[http://bigthink.com/devil-in-the-data/vitamin-d-sun-and- canc...](http://bigthink.com/devil-in-the-data/vitamin-d-sun-and-cancer)

[http://articles.latimes.com/2008/may/26/health/he- explain26](http://articles.latimes.com/2008/may/26/health/he-explain26)

[http://proceedings.esri.com/library/userconf/proc05/papers/p...](http://proceedings.esri.com/library/userconf/proc05/papers/pap1468.pdf)

Or Google that yourself: [https://www.google.com/webhp?q=cancer+rates+equator](https://www.google.com/webhp?q=cancer+rates+equator)

<comment><USER4> Sorry, what? Please provide some sources for these claims.

As far as I'm aware melanoma is most definitely related to sun exposure and there is no consensus opinion on vitamin-D and cancer prevention, with the most evidence being for it being protective against certain bowel cancers..

Edit: Here's a source for my view: [http://www.nhs.uk/livewell/summerhealth/documents/concensus_...](http://www.nhs.uk/livewell/summerhealth/documents/concensus_statement%20_vitd_dec_2010.pdf) [3rd and 4th bullet points for example]

<comment><USER5> There's some data to speculate that chronic non-burning levels of sun exposure is protective against melanoma while acute burning exposure is inductive. Until the data becomes more clear get some sun exposure but do not burn.

[http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2082713/](http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2082713/)

<comment><USER3> This is exactly what I mean. Burning is not good, never. It damages the skin and that can cause cancer. Getting 1 MED of sun / UVB a week is however OK it seems.

What 1 MED is for you depends on where you live, what time of the year it is, and what skintype you have. If you take a sunbath of one hour in New York in July, and the next day your skin if mildly rose but not burnt, than 1 MED = 1 hour of sun for you, under those circumstances. Then you can divide that into two or three parts spread out over the week. So for 1 hour, you can sit in the sun for 20 minutes three times a week. That will give you enough vitamin D without causing nonmelanoma skin cancer.

In Mexico the sun is brighter, so that would shorten your 1 MED period. In november in NY the sun is less bright, so that would make it longer and probably even harmless.

<comment><USER5> Yes, absolutely, also of note is that it's not just only vitamin d that is good for you but nitric oxide related effects as well: [http://www.ncbi.nlm.nih.gov/pubmed/24445737](http://www.ncbi.nlm.nih.gov/pubmed/24445737) (ted talk about this topic: [https://www.ted.com/talks/richard_weller_could_the_sun_be_go...](https://www.ted.com/talks/richard_weller_could_the_sun_be_good_for_your_heart?language=en))

</comment></comment></comment></comment></comment></comment><comment><USER6> September is Childhood Cancer Month.

I lost my sister to Brain Cancer in 1996 when she was 15

I lost my son to Bone Cancer in 2013 when he was 12

Most Cancer Charities give penny or so to Childhood Cancer research and Federal Research Grants give 4 cents to the dollar to Childhood Cancer research.

In the last 20 years only 2 new drugs have been approved till a 3rd this spring.

St Baldrick's and Childhood Cancer Research Fund give the majority of their funds to research and St Baldrick's actually help find the first new treatment in years with a 30% better results! [http://www.stbaldricks.org/blog/post/breaking-news-the- fda-a...](http://www.stbaldricks.org/blog/post/breaking-news-the-fda-approves- childhood-cancer-drug/)

<comment><USER7> First off, I am sorry for your loss, cannot begin to understand how it must feel. Secondly, that is incredible about the new drug, it is crazy it takes that long to find more possible treatments for such a widespread cause of death.

What are some more effective ways we can give or help that won't be eaten up by overhead of the charities?

<comment><USER8> Cancer is a widespread cause of death, but unfortunately "cancer" is a very broad category. Just because two illnesses are both classified as cancer doesn't mean they'll respond to the same drugs/treatment. We're finding a lot more success with tailored approaches than creating new drugs.

I think one of the most promising approaches to treatment is discussed here: [http://www.ted.com/talks/jay_bradner_open_source_cancer_rese...](http://www.ted.com/talks/jay_bradner_open_source_cancer_research)

I have a friend who works at American Cancer Society. I asked him the best place to donate to, and he said Livestrong Foundation. I don't know his reasoning, but he's brilliant and incredibly knowledgeable about cancer.

</comment></comment></comment><comment><USER9> I wish the "novel discovery/technique against cancer" news items would stop appearing on hacker news. They are a staple of mainstream media, always with super promising headlines, but with nothing but a far-fetched, vague promise behind them.

As far as I can tell, they are from press releases from research centers who need to get some media attention to secure their future funding. But they are never actually cures for cancer.

<comment><USER10> As someone who does not follow the field, I enjoy knowing about new things people are working on, even if they never pan out. It helps expand the horizon of what my mind can conceive as possible.

</comment></comment><comment><USER11> Read the primary source.

Abstract: [http://www.cell.com/biophysj/abstract/S0006-3495(15)00768-7](http://www.cell.com/biophysj/abstract/S0006-3495\(15\)00768-7)

Full text: [http://www.cell.com/biophysj/fulltext/S0006-3495(15)00768-7](http://www.cell.com/biophysj/fulltext/S0006-3495\(15\)00768-7)

Please do not go off on a tangent after reading brain dead PR releases meant for the masses. These are the scientific world's equivalent of clickbait and have little connection to the actual study.

</comment><comment><USER12> > _MP1 interacts with lipids that are abnormally distributed on the surface of > cancer cells, creating gaping holes that allow molecules crucial for cell > function to leak out._

This is fascinating. As IANAMD, I had no idea there were physical (or nanomechanical?) differences between normal and cancer cells. This sounds like a huge number of mistakes, maybe from the extremely rapid divisions.

So is _Polybia-MP1_ another game changer in the Cancer world?

<comment><USER13> We have thousands effective ways to kill cancer cells. Making sure the host survives is the tricky part.

<comment><USER14> [https://xkcd.com/1217/](https://xkcd.com/1217/)

</comment></comment></comment><comment><USER15> What I don't understand is: how did they first think of testing this venom for its anticancer properties? Do researchers test many different antimicrobial substances, Edison fashion, to see which kills cancer cells?

<comment><USER16> Yep.

<comment><USER17> Any idea how this is done at scale, on C cancer cell lines x W compounds?

<comment><USER18> one way is 3D colony formation assay, 96 or more WxC combinations at a time depending on format and replication requirements

</comment></comment></comment></comment><comment><USER19> I keep hearing about these almost miraculous cures, what would my ontology office (if I had cancer) tell me if I asked for Brazilian wasp venom treatment?

<comment><USER20> "you're looking for science -> disease -> treatment -> oncology, down the corridor"

<comment><USER21> This is a really funny comment!</comment></comment></comment>


To Dine at Kew: The Meals of George III and His Household - <AUTHOR> http://recipes.hypotheses.org/10063 <comment><USER2> > to think about how food was used to encode social relations within homes > where master and servant ate food produced in the same kitchens, and from > the same supply chains

The triumph of capitalism and democracy has been the erosion of many of these distinctions. Consider that even now in this new Gilded age:

\- Billionaires and housekeepers have the same phones, and the deliberately ostentatious Vertu failed because all it could offer was an inferior phone with a few gems glued on.

\- Drive around Palo Alto and yes, you see a couple of A8s and escalades, and quite a few Mercedes. But the bulk of the cars in my neighborhood are the same Prius, Tahoe, Camaro than you see in the Central Valley, if, it's true, typically newer.

\- migrant workers can pick up the phone and talk with their family; less than a couple of decades ago to be a migrant worker was to vanish for a time, or forever.

\- It's the same facebook site for everyone (or it's a unique FB page to everyone, depending on how you look at it).

\- Everybody can watch the same TV shows and movies; in their "private theatre"

\- Anybody in the middle class, even the lower rungs, has flown on a plane.

Not to mention the usual list of reasons always trotted out that all but an infinitesimal slice of the OECD population has a better material life than George could dream about.

Of course there remain enormous disparities in health care, nutrition, and other factors. But the trend, in particular with new technologies, is running against it.

<comment><USER3> While the substance of the tools that everybody use has mostly converged, there are still many signals of wealth that I think you overlook.

\- The iPhone X and Apple Watch with Hermes bands are a far cry from an average Android phone.

\- I see plenty of Teslas in PA/MTV. But that aside, I see even more Google/FB buses - isn't that a higher level of differentiation, where you Uber/Lyft or take the corporate shuttle to get driven around?

\- Ok, I mean there are still arbitrary borders and restrictions on immigration that make being a migrant worker a living hell in many places of the world. I'd guess they aren't experiencing a triumph of capitalism (or democracy, they can't vote in the places they work).

\- Other social networks thrive on differentiation - Tinder Gold and The League position themselves as the dating apps where you can avoid the ugly and the plebian

\- Mass media content has always been intended to be consumed by the masses. But that doesn't mean that it's the same content that the rich consume. Broadway shows and other in person performances are not replicated by TV or other mediums. I had a very interesting conversation about how the movie/theater divide plays out in Cuba but perhaps that's for another time. \- It's odd to talk about the egalitarianism of travel by saying 'everyone has flown on a plane.' The transformation of air travel into a necessity is an artifact of the accelerating pace of global commerce which has created these very distinctions. The latest trends in air travel are in fact the additional polarization of the experience for the rich and poor - the near-universal embrace of 'basic economy' at the same time as 'ultra-luxury' flights a la United Polaris, Boom, or anything from Emirates.

<comment><USER4> Tinder gold only lets you see who liked you – and it's really not that expensive

<comment><USER3> Sorry, Tinder Select [https://www.engadget.com/2017/03/08/there-s-a-secret- celebri...](https://www.engadget.com/2017/03/08/there-s-a-secret-celebrity- only-version-of-tinder/)

</comment></comment></comment></comment><comment><USER5> _Soupe Sante, 4 chickens, tendrons of lamb; mutton cotellets; Emince of Pullets; 71 /2 Veal Collops; a haunch of venison; 2 large soles; a leg of Portland mutton; 83/4 muttons; Richmond duck; Capon; 3 pigs trotters; asparagus; potted meat; Genoise; ¾ prawns; celery and pomme de terre._

If this is him [https://en.wikipedia.org/wiki/George_III_of_the_United_Kingd...](https://en.wikipedia.org/wiki/George_III_of_the_United_Kingdom), he still lived to 81 years of age.

edit: I know he didn't eat it all

</comment><comment><USER6> It would be nice to link to the source, if it's available online. In fact, the raw data would be far more interesting to me than digested nuggets.

</comment><comment><USER7> I found very interesting that the sample meal shown was very, very heavily pure meat. Today's meals tend to include substantial "bread"/starch component for each meat: whether a bun, breaded chicken, potatoes. That appears absent or much reduced on this menu.

<comment><USER6> Well, I think you can assume there was bread, alongside the pomme de terre which are on the menu; and we don't have relative quantities for everything, or know how many people were eating. Variety, though, is a large part of what makes a meal opulent - e.g. tasting menus usually have 10 to 20 courses when you include the various little nibbles in between courses. And indeed, tasting menus typically have a different meat for every dish; if you listed them in this format, they'd look very meat heavy too.</comment></comment>


Help evolve my consulting company's name - <AUTHOR> http://consultantevolution.herokuapp.com

<comment><AUTHOR> I plan to start consulting more, and I need a company name.

I'm pretty sure most consulting companies use a random wordlist. I'm supplementing the random wordlist from the Unix dictionary with an evolutionary algorithm to guarantee my company name is the best.

Play a few rounds and use the power of the crowd to help forward consultant naming science.

</comment><comment><USER2> How do you feel about Consultivate?

<comment><USER2> Or Consulvation. Try saying it aloud.

I'm having entirely too much fun with this.</comment></comment>


Why Don't We Have Rockstar Teachers? - <AUTHOR> https://www.learnboost.com/why-dont-we-have-rockstar-teachers-quora/

<comment><USER2> I think there are "Rockstar" teachers out there in terms of their impact on students if not their popularity. I had a few teachers growing up that changed the trajectory of my life for sure.

Not everyone can be a rockstar though, and it's probably a pretty poor analogy for what good teachers can do for someone. I think the teacher that is still around and trying to keep subjects interesting and fresh after 20 years is more deserving of praise.</comment>


XHTML and CSS Embarrassment - <AUTHOR> http://www.akitaonrails.com/2008/1/11/xhtml-and-css-embarrassment How I was embarrassed by 3rd party badges at my website. Am I missing something? <comment><USER2> He seem to believe that valid XHTML will render the same in all browsers. If only it were so easy!

For example the Flash-trick that he talks about is just a script that writes the embed-tag through javascript. The only advantage is that the page now validates, since the validator doesn't execute javascript. The actual HTML rendered by the browser is still contain the embed, so obviously it will not render any differently.

Its just a pointless pursuit of validation for the sake of validation.

<comment><USER3> And I thought browsers deciding on the best way to render was the key strength of HTML.</comment></comment>


The More Fires Firefighters Are Exposed to, the More Heat Resistant They Become - <AUTHOR> http://www.smithsonianmag.com/smart-news/more-fires-firefighters-are-exposed-more-heat-resistant-they-become-180949315/

<comment><AUTHOR> The human body adapts over time to repeated exposure to both low and high temperatures: the article compares results from [http://www.outsideonline.com/outdoor-adventure/As- Freezing-P...](http://www.outsideonline.com/outdoor-adventure/As-Freezing- Persons-Recollect-the-Snow--First-Chill--Then-Stupor--Then-the-Letting- Go.html) and [http://www.scienceworldreport.com/articles/12057/20140109/ol...](http://www.scienceworldreport.com/articles/12057/20140109/old- firefighters-could-be-more-heat-resilient-over-time-study.htm)</comment>


Ask HN: What are you building tonight? - <AUTHOR> <comment><USER2> I'm working on another fancy wordclock: [http://www.finewordclocks.com](http://www.finewordclocks.com)

I make them from a single block of sapele. They give the exact time every 5 minutes with "ish" appended for the 2 minutes before and after the exact time. Time is set via wifi.

I've been making various wordclocks as gifts for a few years. I also made a simplified design that I donated to my local makerspace for a workshop I used to teach there (we used all their cool tools to make the parts then students soldered and assembled their own unit. I provided the design and it's program).

This sapele version is (imho) a pretty refined design and the first one for sale. So far I've sold 4.

I also cut 3 magic marker holders for an order I got on my Etsy shop ([http://www.etsy.com/finewordclocks](http://www.etsy.com/finewordclocks)). That's my side project to my side project.

</comment><comment><USER3> Writing a program that pulls article URLs from Pocket, saves the content as PDFs, groups that up in categories based on Pocket tags (e.g. #econ, #tech, etc), and emails out composite PDF "volumes" to me as they hit 250 pages. Plan is to then send them to a cheap PDF printing service like [https://www.printme1.com/](https://www.printme1.com/) (if anyone knows of anything even lower cost, I'm all ears).

I like reading physical books and taking notes in them but I realized there's a lot of good content in the form of blog posts, articles, etc that I also want to include in my primary information diet and it would really help to have them in paper copies that I can easily write on and reference. Much of the kind of content I anticipate saving also has superior information density versus books, so I'm excited to get this working.

<comment><USER4> Other than PDF, can any such services support other file formats, and can they provide information such as METAFONT modes, colour management, resolution, printable area, separations, etc? I may want to rasterize or otherwise process the data on my own computer before being printed.

<comment><USER3> wkhtmltopdf has options to adjust some of the things you mentioned. I'm sure there are other more sophisticated programs that go further. It's really a question of what HTML/CSS can be transformed into. PDF suffices for my use case (and I also specifically wanted minimal manual overhead) but I'm sure there are other options.

<comment><USER4> No, I mean if a printing service can print files other than PDF, such as prerasterized files for their printer instead, for example.

<comment><USER3> Oh not sure about that. Haven't encountered one to date.

</comment></comment></comment></comment></comment><comment><USER5> I wouldn't say "tonight", since I'm working for 1.5+ years on it, but I'm working on an easy video editor. [https://phot-awe.com](https://phot-awe.com)

For the last 2 weeks I've been working on the lower pane - hopefully will have a new version within 1-2 weeks, one that will blow your mind :)

</comment><comment><USER6> Working on a project that allows freelancers/contractors to share their work progress with their clients to help them stay on the loop.

How it actually works:

1\. If you are a professional or a contractor, you could create a list of things you would do for your client in the form of to-do lists. You could also create this either in the form of proposals to list out tasks before agreeing to work.

2\. They could see the lists of tasks, your progress and stay in the loop and comment/share their ideas on specific tasks. Or you could keep it private to let you know how much percentage of your work has been completed

:)

</comment><comment><USER7> Working out some discovery and maybe a PoC for a CI/CD pipeline. We're trying some interesting micro-service techniques for a new internal platform, and I'm juggling a lot of technologies and stacks to get everything to operate and deploy correctly.

The post earlier from Single SPA about their import-map-deployer spurred some huge progress for coordinating frontend deployments.

</comment><comment><USER8> Been teaching myself RL from introduction to RL (E.2) [https://yashbonde.github.io/musings.html](https://yashbonde.github.io/musings.html) and working on rough ideas of what I think real AI driven computation would look like so running subset of tasks on it.

</comment><comment><USER9> A small demo page that involves collating thumbnails/previews of live streams from FB, IG, Twitch, and Zoom.

While the facebook API clearly shows how to post a livestream to FB, the reverse is obviously much less supported. What systems could I use to programmatically pull livestreams from each / any of these platforms? What ToS considerations would I have to be aware of?

</comment><comment><USER10> Some friends and I built a free and open-source website for playing board games. The site is built with React, NextJS, and TypeScript.

Tonight I'm working on adding matchmaking / lobby features :)

[https://www.freeboardgames.org/](https://www.freeboardgames.org/)

</comment><comment><USER11> Developing a Smartthings device handler to control a WS2812B strip light managed via a Particle Photon [1]. Going well, but Groovy language sucks big time.

[1] [https://store.particle.io/products/photon](https://store.particle.io/products/photon)

</comment><comment><USER12> Trying to reduce hallucination in NLG systems. The idea is straightforward enough. Whatever is a parameter of the sentence: tone, nouns, verbs, actions, adjectives need to be the input parameters.

Everything else glues together the inputs to form gramatically correct sentences.

</comment><comment><USER13> I'm back to working on my unintended consequences project ([https://unintendedconsequenc.es/](https://unintendedconsequenc.es/)).

</comment><comment><USER14> I'm working on improving search in [https://histre.com/](https://histre.com/) (Effortless Knowledge Base)</comment>


The Elusive Calculus of Insects' Altruism and Kin Selection - <AUTHOR> https://www.quantamagazine.org/the-elusive-calculus-of-insects-altruism-and-kin-selection-20180410/ <comment><USER2> _Ants, termites, and some bees and wasps live in highly organized colonies in which most individuals are sterile or forgo reproduction, instead serving the select few who do lay eggs. Yet such behavior seemed to clearly violate the concept of natural selection and survival of the fittest, if "fittest" means the individual with the greatest reproductive success._

Right, but it's your genes that are trying to propagate, and how genetically similar are a colony of ants? If collective success still alllws your genes to spread, it's a win. Given that social insects in a colony share the same "mother" we're talking about huge group incentives. When you consider how few insects even reach maturity, never mind reproduce, it starts to make a lot of sense to me.

<comment><USER3> The entire article seems to be a longer version of the discussion of the same issue in the book for non scientists, The Selfish Gene, except for the discussion about the genetic formula/hypothesis used to explain the social insects being unprovable or may be even tautological.</comment></comment>