Beating the Talent Crunch with a Distributed Team - <AUTHOR> http://hkarthik.me/blog/2011/12/12/beating-the-talent-crunch-with-a-distributed-team/ <comment><USER2> We have both in-house and remote developers at AutoRevo and while we've been successful at maintaining both, we've stumbled a bit in a few areas.

The biggest problem we have is the remote folks feel disconnected. Even with Campfire and Skype, it can still be a challenge to keep everyone connected. It's not uncommon for an in-house dev to ask a simple question to the folks around him and have that question turn into a thoughtful conversation. Sometimes, we'll think "Oh, fire up Skype and get so-and-so on the line so they can join in." But many times, we just don't even think of it.

I hadn't heard of Sococo, but it looks intriguing. Keeping an open mic with Skype was something we considered, but it seems intruding. This is an area we're still trying to get better at.

The other issue is one of team-building. Usually our in-house devs go to lunch together and grab the occasional beer after (and during!) work. There is a camaraderie there because these guys work together, eat several meals a week together and drink more than a few beers together. That just can't be replicated to a remote developer.

We've also found that some devs simply aren't disciplined enough for remote work. They love the freedom, but sometimes that freedom becomes a problem for them. We don't keep devs that have to be supervised constantly, but when they are remote it can be harder to gauge if they are just hitting a slow, unproductive period that will pass or if they are just doing as little as possible to keep a check coming in.

Distributed teams are definitely a huge bonus for a company, but there are challenges that have to be thought through up front.

<comment><USER3> We use campfire to do 90% of our conversation even with our team all in house. It helps kick off conversations, save them for later and keep everyone in the team on the same page. I think before you start hiring remote talent you need to build in that communication strategy to your core team.

Very much agree that in-person bonding, whether working side by side or having a beer, are important. If you do have a remote team- try to build in time for the whole team to be in a single office every other month at least.

<comment><USER2> We're the same. Even though the bulk of our devs are in the office, we still use campfire because it's the central hub of communication. (commit messages, CI build notices, when stories get updated in Pivotal,etc.)

And it's searching ability is very nice. Pro-Tip: Keep that searchability in mind when you discuss a candidate's interview in campfire..they might be reading it later when you hire them. Dohp!

</comment></comment></comment><comment><USER4> I've actually found being in the opposite timezone can be handy. Currently I'm in the US while most of my team is in India. Often, our workflow is the following:

9AM-5PM EST: build a view.

9AM-5PM IST: view becomes nicely styled.

Similarly, I can work on a project, hand it off to my developer across the sea, and considerable progress will be made before I wake up.

Of course, this strongly depends on having people I can trust - not just any developer will do.

<comment><AUTHOR> Can you elaborate a bit on what these projects entail? Maybe a short description and how long each project went on?

The work I do tends to require a lot of collaboration as we figure things out and experiment. Having a one day delay for every thing feels like it would slow us down A LOT.

We also use iterative development in a two week sprint, a day lost would limit our productivity tremendously.

</comment></comment><comment><USER5> The site is down so if you can't read the article, see here [1].

The author is actually pointing out two distinct problems, which are both having a real impact on tech companies. The first and most difficult problem which every company faces (startup or otherwise), is finding great talent.

Every tech company is fishing in the same water trying to find devs in competitive places like S.F. or NYC. These cities certainly have the highest concentration of great developers, but there are hundreds of thousands of equally great devs scattered across the country. If your company can find a way to get the best of the best among these isolated devs (who may be in Kansas), you're ahead of the game.

The second problem he discusses is how to get startups to work well in a distributed team. As many have pointed out, using Skype can be awkward. There is also something missing from typical remote working platforms that doesn't capture the social dynamic of working in the same office.

I'mworking to solve both of these problems. Right now, I'm looking for beta testers before I launch. If you're interested and willing to give feedback, shoot me an email.

1\. [http://webcache.googleusercontent.com/search?q=cache:http://...](http://webcache.googleusercontent.com/search?q=cache:http://hkarthik.me/blog/2011/12/12/beating- the-talent-crunch-with-a-distributed-team/)

<comment><AUTHOR> FYI the site should be up now. It's loading fine for me.

</comment></comment><comment><USER6> I'm surprised no one has mentioned a great technical solution for this: Hangouts (disclaimer: I work for Google).

Other posters are correct in that there is friction with Skype or in fact any solution that isn't always on (you could keep Skpe up of course) but I can tell you from experience that if you get in the habit of just keeping a Hangout open it gives you much of the benefit that physical proximity does.

Remote debs can keep a Hangout open on a second screen or possibly a dedicated machine. Your main dev site should just hang a monitor on the wall and hook up a Mac mini to stay always on (per room). You may need a decent mic for this.

<comment><USER7> Is there a solution whereby this common "monitor on the wall" could be logged in via some common account instead of with a particular individual's account?

Also, according to [http://support.google.com/plus/bin/static.py?hl=en&topic...](http://support.google.com/plus/bin/static.py?hl=en&topic=1651183&guide=1257349&page=guide.cs&answer=1216374) "There's a 90 minute check-in to make sure you're still there."

</comment></comment><comment><USER8> Exception: always bring the interns in house. I've heard the talent crunch is bad, but I cannot imagine a remote internship being beneficial at all.

I tried working a remote internship once and it was awful. I didn't get anything done, had no idea what was going on, really a big waste of time. The first day I got to the office I fixed a bug and got the product to actually work though. The rest of my time there I did some good work.

Interns don't know what they are doing. If they did, they would be full time employees. They need to have somebody to point out some of the basics, not all!, but enough for them to actually be productive.

<comment><USER9> Eh. My first job was a remote (cross-country, even) internship when I was 16 for a 2-man bootstrapped startup that didn't have an office anyway. Since they were already setup to do most work conversations through Campfire, it worked great.

There's nothing keeping you from "pointing out the basics" via email, chat, or Skype and being available on chat if they hit walls just as you would be in person.

Sure, if you're not communicating well, maybe your full-timers can get stuff done despite that and your interns can't. But I'd say that means that having a remote intern is one of the most important things you can do from time to time. It will be a test of whether you're actually doing the distributed team thing right, instead of your team just being competent enough to work around it.

<comment><USER8> Maybe. I think there is much to be said for being able to just walk down the hall with your laptop and debug everything in person with someone who knows what they are doing. I didn't know much before that internship about software development and I learnt a ton about the whole field just watching other people. It's why I use emacs nowadays at a more than beginner level.

Again, if the intern is competent, then they aren't really an intern anymore. Just kind of a part time worker more likely to be hired in the future.

</comment></comment></comment><comment><USER10> At my company, we like to offer great health insurance, but this can be difficult to provide if you only have a single person in another state or region.

In the US, each state (and regions within a state) have different insurance providers. All providers that I have investigated require a minimum of two people as part of their group. We are just beginning discussions with our agent on this topic, so a good solution may exist that we have not crossed.

For those of you that work distributed in the US, can you tell me a little about your health insurance (+life, dental, etc) and if it is great, average, poor or non-existent?

<comment><USER11> We had that come up. A Blue Cross PPO allowed us to offer coverage in California and Kansas.

</comment></comment><comment> brown9-2 Anyone happen to have any advice on convincing the rest of your distributed team to use a chat room?

Our team lead has an odd aversion to using IM, which extends to distrust of any electronic messaging beyond email. However I really feel a persistent chat room would be a big help for the team.

<comment><USER12> I actually prefer a chat room over email. It's logged, with group discussion and it's asynchronous. I don't have to begin a reply and then wait for a response. I just get it out in the room and keep going.

Another thing I like about using a room is the chance to use Hubot (<http://hubot.github.com/>). It makes for some fun and can also be extended to actually do useful stuff.

If your team as an aversion to IM try to entice them with a room is better because it's not one to one and everyone can see and answer questions and it facilitates group discussion easily and it's asynchronous so it gets out of your way.

<comment><USER13> We've been using skype chat almost elusively for 3 years. At first, I loved the work flow, but in our case it has devolved into an email replacement for one of our team leads. He daily sends reams of chat messages into the room with the expectation of a synchronous response. Messages routinely get lost in the shuffle. I'm working to get him to use email for these sorts of issues -- status, in progress.

If skype had threaded chat conversations, it would be much more manageable. Until then, I miss gmail... :)

Use the right tool for the job.

<comment><USER14> Skype has a pretty awful UI for chats. If you get people set up using a bouncer then it's pretty easy to get persistent conversations over IRC, and then people get to use the client of their choice. Plus it's a lot easier to automate with bots.

</comment></comment></comment></comment><comment><USER15> This is an awesome article. I've been working on a distributed team and have learned some of these things in a rather painful way. Are all these lessons learned just from experience? A Hacker News type subgroup for distributed teams would be nice to have so we can share experiences learned the hard way so others don't have to. Someone please let me know such a forum exists.

</comment><comment><USER16> I also work on a distributed team. While all my teammates are in the US I am the only one working in the Philippines. We use email, chat (yahoo messenger), skype and gotomeeting for communication. We use our internal tool to log our time every day.

This setup works for us and has been going on for almost 2 years now.

<comment><USER17> I also do some work from the Philippines when I'm there on occasion, but I'm based in the US. One problem I have is the reality of power "brownouts" in the RP interrupting bandwidth.

<comment><USER16> I guess that depends on where you're located.

</comment></comment></comment><comment><USER18> Good article Kar, I agree that the talent pool is drying up and I'm not sure what reasons are behind it. I wish more company's would adopt a work from home mentality as it also creates a competitive advantage to attract some of the brightest.

<comment><USER19> agreed. but you also need to be the change you want to see in the world. in a hiring role? ensure you allow remote/home-based team members. evaluating working for someone else? filter for that and demand it, else seek elsewhere. it's what I do (well, trying to do. mostly succesful so far.)

</comment></comment><comment><USER20> I work on a distributed team. Timezone is definitely an issue. But in a startup, folks work when they must, and get the job done.

We use Sococo Teamspace (I work for Sococo). It combines chat, audio conferencing, doc share and video conferencing. Everybody stays on all day. That means you can track what anybody is doing online, know when a meeting is starting, who's talking with whom etc.

Its not perfect, but it sure beats the isolation of working at home, checking email every 10 minutes.

</comment><comment><USER21> I have always wondered how scaling across countries affects a company but I have never thought about a distributed founding or early-stage team. I think the intensity and sensitivity between founders would be lost in the ether. Great products require tough decisions that should lead to disagreements. Web- chat might obfuscate such tension or take the passion out of the process.

</comment><comment><USER22> The article doesn't put it strongly enough.

If you run a tech company and only think about hiring people locally you're crazy.

Why hire only locally when you can draw from talent anywhere in your country, in fact, anywhere in the world. Likely at a much lower cost for the same level of talent. Plus you have the advantages of your team not needing to travel.

Working together in the same office is a 20th century model of doing business, and I'm surprised that many technology companies are not open to a more distributed model.

A more important question is: What needs to be done from an office versus a distributed team?

From an office you will probably want: Core executive team members (in a larger company, but not necessary in a small company, all team members can be distributed) Local based sales people (if you are doing one-on-one presentations selling to local businesses) Plus certain types of businesses do need an office

<comment><AUTHOR> I agree with you, but in practice I've seen that even if a company wants to go distributed, they lack the knowledge on how to make the model actually work for them.

They resort to using the exact same process with more conference calls and emails. That clearly doesn't work as you miss many subtle communication queues.

</comment></comment><comment><USER23> I agree and plan to build a company in which distributed is the norm.

</comment><comment><USER24> More drum-beating about this illusory talent shortage, eh? I'm still waiting to see any signs at all that this shortage actually exists, aside from random "I can't find a rockstar!" anecdotes.

<comment><USER25> Very hard to find experienced Ruby devs in Vancouver, Canada. Have had open positions for months at my company with only junior people applying.

<comment><USER26> so train them

<comment><USER27> As long as there's no decent form of _vocational_ education, training in-house is a huge investment. You can only properly train one junior for every three to four seniors before it becomes disruptive.

Many companies that have already made the mistake of hiring too many juniors in an attempt to deal with the shortage, and have suffered the consequences (huge drops in quality and productivity, and in the worst case, seeing the experienced seniors they did have walk away frustrated).

Where education fails, major companies like Google and Facebook should take the responsibility for training juniors. Instead they spend their fortunes strip-mining the market.

<comment><USER28> Yeah! Google should start firing their top talent every five years too so the rest of the tech industry has a chance to hire them.

Because that makes about as much business sense.</comment></comment></comment></comment></comment>


The Fate of Empires (1976) [pdf] - <AUTHOR> http://www.newworldeconomics.com/archives/2014/092814_files/TheFateofEmpiresbySirJohnGlubb.pdf

<comment><USER2> Just wanted to thank you for posting this (it seems no one noticed...), I found it very interesting.</comment>


Netflix streaming video to be available on Wii - <AUTHOR> http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2010/01/13/BUHE1BH2C8.DTL <comment><USER2> That's pretty cool, but I recently got a HDTV and the Wii is the worst-looking input into it at 480p. The $99 Roku player looks fantastic at 720p, even when the video you're playing isn't specifically in HD.

<comment><USER3> Keep in mind that much of netflix content just isnt available in HD -- because it was never made as such. For this stuff it doesnt matter as much and is very nice.

<comment><USER4> Most of Netflix's films were filmed on 35mm film, which in most cases has a similar resolution to HD.

<comment><USER3> Im not arguing that point. Im arguing that untill Warner Bros, Fox, et al get around to releasing on blu-ray the only way to get that contet is dvd. Netflix is not in the biz of scannning film, so they are stuck with what they are given. Most of that is DVDs

<comment><USER2> According to the Netflix blog entry I mentioned already, DVDs are a minority when it comes to video sources.

<comment><USER3> Yeah, I see that now. At the time I posted I was operating under incorrect assumptions and info.

</comment></comment></comment></comment></comment></comment><comment><USER5> I can't wait for this. For the most part, I don't care about the quality of it (at best 480p). As long as it's not choppy, I could care less if Burt Reynolds' mustache is pixelated.

</comment><comment><USER6> Even if this is true, I imagine the video quality will be less than spectacular. Back when I was trying to finagle the Wii into a media center, I could never get videos to playback above a certain bitrate/resolution. My guess would be 480p at best.

That said, I will be very happy if/when this happens. A macbook does not a media center make.

<comment><USER7> I'm not sure the Wii qualifies any better than a macbook. Struggling to do 480p, which you concede could possibly be the highest resolution it will output, does not make it better than a macbook IMO.

</comment></comment><comment><USER8> The real winner this generation is Netflix. They now have streaming video on all three consoles.

<comment><USER9> If you saw them at CES last week, Netflix is on pretty much any device that will take them. TV's, roku, boxee (more I'm sure).

Pandora and Skype seem to be following in the same vein.

</comment></comment><comment><USER10> And will be available in Canada about the time Avatar becomes technically possible

</comment><comment><USER11> does the xbox already have this?

<comment><USER12> Yes - and my experience is it works quite well.

Like everyone else though, I just wish the streaming catalog were larger. I'm hoping that's what the recent deal with Warner Brothers will result in.

</comment></comment><comment><USER13> Time to dust off the Wii!</comment>


Geoffrey Grosenbach on how to learn any programming language - <AUTHOR> http://rubylearning.com/blog/2010/09/20/how-to-learn-ruby-or-any-programming-language/

<comment><USER2> Interesting way of going about things. My approach which I'm trying now is pretty simple. Immersing myself in everything Ruby. Read up a bit on the history and purpose of the language, then learning all the basics, whilst using a few full app tutorials. Along with bugging people on Skype whenever I get a roadblock that Google can't solve ;-)</comment>


Show HN: DayToDay - Achieve daily goals - <AUTHOR> https://play.google.com/store/apps/details?id=com.together.michal.daytoday <comment><USER2> The app is great!

I also have been working something similar: [https://github.com/mitul45/ta- calendar](https://github.com/mitul45/ta-calendar). Let me know what you guys think.

PS: For now it's not quite responsive for smaller screen sizes.

<comment><USER3> I like your project, thanks for open sourcing it! I may use it soon, because it's something I've needed :)

<comment><USER2> Sure! Let me know when you start using it :)

</comment></comment></comment><comment><USER4> Just used it quickly, I like the idea but when adding new tasks you should inspect the last tasks finish time and add that as the new start time of the new task. I'd also provide a configurable amount for time blocks (or a picker panel of common amounts, 30mins,1 hour,2 hour etc).

Overall nice and clean, tiny download like andrewvijay mentioned and zero silly permission stuff, good work!

<comment><AUTHOR> The app should recognize the last task finish time, I implemented the functionality. Could you confirm that it doesn't work on your phone ? If it doesn't, could you tell me the android version you use ? I would test it against. If it comes to picker, I don't like it. Although, I understand that some people prefer it, so I might add option to choose between standard way of entering time and picker. Thanks for your feedback.

</comment></comment><comment><USER5> From the screenshot, you're having a bug with the notifications icon, it's a white square. The solution: [https://stackoverflow.com/questions/30795431/icon-not- displa...](https://stackoverflow.com/questions/30795431/icon-not-displaying- in-notification-white-square-shown-instead)

<comment><AUTHOR> Thanks. I've only had the problem on the emulator. It worked properly on my phone, but I will use the fix you provided. :)

</comment></comment><comment><USER6> I'm on the lookout for a product to plan only the current day. This is a nice first version, but I think for it to be really beneficial the UX needs to be on point - adding tasks as quick as possible (like Google Calendars quick add - "Clean Kitchen 1200-1215") and quick glance using a widget or permanent notification of next/current/prev task. Also, Reordering doesn't work for me.

Again, as I said I think this is a well executed first version, but the problem is I don't think I'll be able to keep using it without the mentioned features. I'll keep it on my phone in case it gets updated since it's small and requires almost no permissions.

<comment><USER7> Check out Any.do. It's a little too simple for me, I personally use ticktick which has geolocation on tasks and a lot of other features (including my preferred style of UI, the Things style), but any.do has a fantastic simple UI and has a "Moment" feature that pops up every morning where you get a list of your currently waiting tasks and get to determine whether or not you decide to complete them that day or not. There's also Clear which is a very simple daily task manager.

I'm personally not a fan of the simple UIs and greatly prefer the Things style (menubar on left with projects/lists/etc).

</comment></comment><comment><USER8> I am trying to use it right now but on the time input, I get a numbers keyboard which means I can't use ":" so I can't type a time in..

I am using an LG G4

<comment><AUTHOR> You should have it on your number keyboard. Sometimes you have to quickly tap one button multiple times to get ":". It reads "-/:" on Android 5.0.1.

<comment><USER8> The only buttons I see are 1,2,3,4,5,6,7,8,9,backspace,0 and "Next"

</comment></comment></comment><comment><USER9> Like it. Would rather use voice to plan, however. 'Remind me at 3 to program.' Android phones have pretty good voice control for reminders and are great for scheduling.

Now, if I didn't have a good way to set this stuff with voice, I would love this app.

I love how it is under 5mb and doesn't use unneeded permissions. I love how easy it is to enter things in. And I love how the notifications work and how you can have it export to google calendar.

<comment><AUTHOR> Thanks. I am glad you like it.

</comment></comment><comment><USER10> Just used it for a while. Pros: Good concept. Love that it's only 3.7mb to download. One hand usage thing is good. Would be useful while commuting. Cons: Couldn't understand or make sense about the note feature. I'm not sure where it's related or linked. To the entire day or to particular task? Wouldn't be typing the same things everyday so need a repeat feature. Calendar view would be great.

<comment><AUTHOR> Yeah, it seems that I didn't make the note functionality intuitive. They supposed to be for general use, like: "I get distracted around 12". Should I explain it better and leave them for general purpose or make a description view for every task ? I will definitely add repeat functionality as well as possibility to plan entire week in advance.

<comment><USER10> I think you can make the note functionality better. Description view for every task will be an extra for me but I dont know how many will use it.

</comment></comment></comment><comment><USER11> I have a domain 1daymatters.com was going to build a personal daily quote/task tracker. It's close to expiring, if anyone interested in it keep an eye out for it.

</comment><comment><USER12> on the web app side, complice.co serves a similar purpose with other features like a pomodoro timer. Been using it for a month now and like it so far.</comment>


Laid-off Microsofties in Seattle offered free office space, Linux servers - <AUTHOR> http://www.techflash.com/venture/Seattle_software_incubator_wants_laid_off_Microsofties_to_join_them38158639.html

<comment><USER3> This is very clever, especially given that R&D was cited in articles as being in the crosshairs.

There's a stereotypical Microsoftie that only knows MS tools and doesn't care to expand their horizons or stay educated on new trends in the larger industry. However, there's a lot of talent locked up in Redmond that could really innovate if not bound by MS corporate strategy. Getting your entrepreneur-centric product in front of these eyes is a brilliant idea.

</comment><comment><USER4> I'd love to see this happen in the Valley too. The amount of companies who have been bleeding the wrong people because of management politics is astounding. I'd love to see some of those people use their packages to bootstrap some startups.

If you par down your lifestyle a few months at corporate pay is probably at least half a year of "ramen living".

<comment><USER5> I'd argue that Silicon Valley is already doing this, on a larger scale, completely decentralized and free-form.

If you got laid off and are even remotely curious about startups, there are at least two meetings a day you can attend to brainstorm with fellow entrepreneurs.

Office space and access to computers are not the issue (it's nice because it's a way for people to meet in person, which is a great boost to the entrepreneur spirit). Connecting with the existing entrepreneurs and joining one of the many projects is the key.

</comment></comment><comment><USER6> I'm used to getting cursed for Outlook - not so much for SharePoint (in my defense, I left SharePoint after V1 - there's lots I'd change - <USER2> cross-browser support and build a real framework architecture).

When people swear at me for my other products, I bring up that I was one of the original Excel developers, and that usually absolves me of my subsequent sins ;-),

</comment><comment><USER7> Sharepoint! You f#@ker! Koss!!! _shaking fist_

(Sorry, that's lame, take my karma.. I couldn't help it.)

Good marketing though, since they presumably have a bunch of free space, and offering one "free month" is costing next to nothing.</comment>


How to Make Medieval Soap - <AUTHOR> http://www.medievalists.net/2019/09/how-to-make-medieval-soap/ <comment><USER2> Oof, nowadays recipes call for adding the lye to the fat, rather than the fat to the lye. The lye will react with the fat to produce heat, and it's much better to ramp up the ratio of lye to fat rather than introducing a small amount of fat to the lye. It doesn't mention curing the soap, either, which both hardens the soap and allows the reaction to complete. It makes the soap last a lot longer and helps avoid getting burnt by untracked lye. I wonder if the weaker ash-based lye solution is safer overall than commercially available pure lye.

<comment><USER3> The fact that the recipe mentions "beating down" the soap leads me to believe that it is describing what people nowadays call the "hot process". You keep cooking the soap until it is fully saponified and it does not require further curing.

</comment></comment><comment><USER4> This video of a centuries old soap making factory in Palestine always fascinated me:

[https://youtu.be/aWmFMDr7y0U](https://youtu.be/aWmFMDr7y0U)

<comment><USER5> That has got to be (some of) the most tedious, mind numbing work I've come across.

<comment><USER6> Clearly you've never had to attend meetings in most of corporate America

</comment></comment></comment><comment><USER7> I sometimes buy Aleppo soap. It's great stuff made according to an ancient olive/laurel oil recipe.

<comment><USER8> Yeah, I've switched over almost entirely, to Aleppo soap or olive oil soaps from Greece (which seem to not have the laurel oil present in Aleppo soap), and am very happy. Skin feels a lot less taut and dry than it used to, to give an unscientific opinion.

<comment><USER7> Out of curiosity, what do you pay for it? At the moment I can get rough cut Aleppo soap for about €1.10 here in Germany. I've heard it's dirt cheap in Syria.

<comment><USER9> I get mine from a small grocery store in my hometown in Lebanon. I pay around $3 for a kilo which contains usually some 8 cubes of soap.

<comment><USER7> Nice price! I wonder what shipping from Lebanon to Europe costs...

<comment><USER9> I'm not sure tbh, Aramex typically charges inbound shipments around $9 per 500 grams. However I must note that I'm not getting the best price. If I take a short trip to villages I can buy in bulk which is way, way cheaper. And these soap bars last very long.

</comment></comment></comment></comment></comment></comment><comment><USER10> "Tonight? We make soap." Tyler, D. 1999

<comment><USER11> I make soap and as far as the occupational hazards go, I rank the chemical burns further down the scale from the endless Fight Club references.

</comment></comment><comment><USER12> Good stuff right there, as it requires no industrial products.

Will come in handy during the coming climate apocalypse.

</comment><comment><USER13> A friend gave me some home-made soap, and she told me to let it dry a few days before storing it. This means there is some excess water from the fat-lye mixture, or is this a different recipe?

</comment><comment><USER14> That's intriguing but will be awesome to give it a tryout! Medieval have the quality in many things they do.

</comment><comment><USER15> I wonder how effective this soap is when used as a cleaning agent compared to commercial options.

<comment><USER16> If you have too much lye in it, it will be ridiculously "effective", as its caustic basic property will hurt your skin. Too much tallow, and you essentially just smear fat on yourself.

No real reason why this, blended well to a reasonable pH level, would not be as effective as what we have today.

<comment><USER17> Further, it's likely our society places a disproportionately large emphasis on "super-effective" cleaning agents.

We don't need to wipe off every drop of our skin oil every day in order to eliminate bad smells or function regularly and healthfully around others.

</comment></comment></comment><comment><USER18> Anyone else read this as 'soup'? Just me?

<comment><USER19> I mean, after eating tide pods[1], might as well... :D

[1] [https://en.wikipedia.org/wiki/Consumption_of_Tide_Pods](https://en.wikipedia.org/wiki/Consumption_of_Tide_Pods)</comment></comment>


Inspirational: From Illegal Immigrant to Brain Surgeon - <AUTHOR> http://www.nytimes.com/2008/05/13/science/13conv.html?ex=1368417600&en=6db918210717207b&ei=5124&partner=permalink&exprod=permalink

<comment><USER2> "All along, I had much luck with mentors."

Seems like this is an intangible in the successes of many.

<comment><USER3> The obvious question to ask here is: how can I find one?

<comment><AUTHOR> The same way you increase your "luck." You put yourself in situations where you just increase your odds. Go meet more people, interact more, build a network.

Compare it to rolling a die, it's only a 1/6 chance to roll a 6 but if you keep on rolling it you will increase your chances.</comment></comment></comment>


The Codeless Code: Fables and Koans for the Software Engineer - <AUTHOR> http://thecodelesscode.com/contents <comment><USER2> Posted every week</comment>


Show HN: A simple and easy MQ for devices, written in Go - <AUTHOR> https://github.com/skorokithakis/gweet

<comment><AUTHOR> I wanted an easy way to send commands from my phone to my various Raspberry Pis and Arduinos, and receive data back, so I made this lightweight MQ with a very simple API.</comment>


Marc Andreessen - Three Necessities for Start-up Success [video] - <AUTHOR> http://ecorner.stanford.edu/authorMaterialInfo.html?mid=2459

<comment><USER2> I think 10x is a very good range. It's easy to convince yourself that your product needs to be earth shattering. It really doesn't. Just being _way_ better is enough.

Was Dropbox 100x better than JungleDisk?

Was Wordpress 100x better than Movable Type?

Was Google 100x better than Yahoo?

When it launched the iPhone probably was 100x better. For everyone that isn't Steve Jobs I think 10x is a damn good place to start.

<comment><AUTHOR> I think the hard part is evaluating up front whether the opportunity to be 10x better exists.

</comment></comment><comment><USER3> I think Andreessen's words should be taken with a grain of salt. His underlying premise is that a startup's ultimate goal is to get really big. This may make sense for a guy who has his own VC fund, but I'm not sure it makes sense for every entrepeneur.

While having a market is certainly important, I don't think someone should disregard the niches that are out there. Is a large market more important than the product? While I agree with Marc on iteration and speed of execution, I can't quite convince myself that I would take a large market over a solid product and team. I'd love to see a response from DHH.

<comment><USER4> I think that Andreesen sorta assumes that anyone who's watching/reading his stuff is interested in the big hits. This talk was given at the "Entrepreneurial Thought Leaders" series, for example.

If that's not your goal, you should probably seek out other entrepreneurs who're in an area more like your own. That's sorta implied though - does it have to be spelled out?

I also wouldn't be surprised if DHH also said that the market was important. Without a market, you have nobody to buy your product, which doesn't make it much of a product after all. If you're willing to settle for a smaller market, there're more of them that you can go after and less competition for each, but that still doesn't absolve you from finding one.

</comment></comment><comment><USER5> I've been listening to the Podcast of these talks for over a year now. I highly recommended the whole series, it's called entrepreneurial thought leaders on itunes. Almost every speaker is fascinating, from the CEO of KLA Tencor to Zuckerberg in '05 saying he doesn't like using the term social network to describe facebook. Great stuff.

</comment><comment><USER6> I definitely agree with the 3 necessities. Our co-founding team is composed of a technologist and a business guy. 'guess we need 1 more technologist for iterations (which is already foreseen) down the road.

</comment><comment><USER7> I've just watched the whole thing. Thanks a lot to whoever posted it, that was really interesting.

</comment><comment><USER8> I really like this format for uploading videos of a talk. Excellent to-the- point speaker as well.</comment>


The Fundraising Bible – How to raise money for your startup - <AUTHOR> The Fundraising Bible by Emilie Maret helps founders understand the process of raising capital  https://salon.thefamily.co/dont-freak-out-the-fundraising-bible-is-here-156a059fe824
Check out other resources at Founder Stuff
https://founderstuff.xyz <comment><USER2> [https://salon.thefamily.co/dont-freak-out-the-fundraising- bi...](https://salon.thefamily.co/dont-freak-out-the-fundraising-bible-is- here-156a059fe824)</comment>


Ask HN: Where to buy real SAAS business? - <AUTHOR>

So we have Flippa, bizbuysell.com, bizquest.com etc. These are selling mostly low end, affiliate marketing types sites. If someone is interested in buying a real SAAS/software business, where can they look ? By real, I mean selling an actual product with paying customers.<p>I understand that most people do not want to list their business for sale due to fear such as competition etc. I also understand that owners do not want to sell if they are profitable but there is that small group of owners who have a profitable business but want/need to sell due to a number of reasons. May be they want to work on their next big thing? Howver, they keep quiet because they don't know where to find buyers who are genuine and real. But is there a way to find these business owners ? I am interested in exploring an opportunity to buy an existing saas/software business that has net cashflow of about 5K per month (not revenue). how to find these ? Btw, contact is in my profile if you want to talk. <comment><USER2> If you want to buy a business, if you are a investor, then I think the best place for you to begin is connect with VCs, angel investors or visit crowdsourcing or crowdfunding websites like kickstarter.com .

The next best option is visit incubators like the one being run at IIM Bangalore. [https://twitter.com/Shivanand_25](https://twitter.com/Shivanand_25)

Lastly meetup.com can help you reach some developers, those developers would know about other developers who have put their products and businesses up for sale.</comment>


No Matter What You've Heard, the Docker Container Ship Is Not Sinking - <AUTHOR> https://www.itprotoday.com/containers/no-matter-what-you-ve-heard-docker-container-ship-not-sinking <comment><USER2> This morning I installed Docker on a Raspberry Pi 4. It was... easy as pi.</comment>


Bosch to be carbon neutral worldwide by 2020 - <AUTHOR> https://www.bosch-press.be/pressportal/be/en/press-release-17984.html <comment><USER2> This is good news but sadly they don't talk about transportation as normally they are not considered as a problem of the manufacturer.

Maritime and airplane transportation emissions not being considered in Paris agreement illustrate this problem.

Other thing is planned obsolescence. I wonder what is being made in the company to design products to last a lifetime.

<comment><USER3> Well at least on the consumer side, my perception has always been that their brand revolves around solidly built products that last long. We have a bunch of power tools that must be like 20 years old and still work like new.

</comment></comment><comment><USER4> Can anyone who knows more about this than me comment on whether buying carbon offsets is more than just a PR move? Props for investment in green energy though.

<comment><USER5> All carbon offsets are not created equal (in fact, most of them are bogus). There are alternative energy companies in our "deregulated" energy market here in Illinois who will sell you "100% clean electricity" in the form of offsets. These offsets represent things like wind farms in Texas that were built years ago -- buying a "credit" for this electricity does nothing to add new renewable capacity to the grid, remove more carbon from the atmosphere, or change our emissions landscape in any way whatsoever. Credits for _new_ renewable generating capacity one could argue to be a positive thing, but this market is pretty much entirely unregulated now and most of these products are not much more than accounting tricks.

<comment><USER6> _> These offsets represent things like wind farms in Texas that were built years ago -- buying a "credit" for this electricity does nothing to add new renewable capacity to the grid, remove more carbon from the atmosphere, or change our emissions landscape in any way whatsoever_

The producer being able to sell those credits going forward is what made the plant economical to build in the first place.

How are other credits for "new renewable capacity" any different? That new plant is going to be producing renewable energy and selling renewable energy credits for long after it gets built. The projected returns from selling those credits is part of the financing they used to build it.

If more people are trying to buy RECs, the market value of those RECs goes up, and it enables more producers to invest in new renewable capacity because they'll be able to sell RECs for more money.

Of course the additional credits on the market could push prices back down if a lot gets built (woo fucking hoo, that's what we're trying to encourage!), and the market demand for more credits to purchase is also increasing as governments pass requirements for XX% renewable capacity by YYYY year.

<comment><USER6> More background on these here: [https://en.wikipedia.org/wiki/Renewable_Energy_Certificate_(...](https://en.wikipedia.org/wiki/Renewable_Energy_Certificate_\(United_States\))

A short summary:

1) A producer gets a REC for putting 1 MWh into the grid from renewable generation. This energy mixes in with all the other energy on the grid, it doesn't go anywhere in particular.

2) The producer sells this REC on the market.

3) The consumer who buys the REC is considered to have purchased renewable energy, either to meet renewable energy requirements or just for their own personal reasons because it's a good thing to do.

In 29 states, DC, and PR, they have "Renewable Portfolio Standards" which require electric suppliers to have a certain amount of renewable energy in their production portfolio. They can own this production capacity and make the RECs themselves, or they could burn natural gas and buy a bunch of RECs from a third party, or even a bunch of people with solar panels on their roofs.

Beyond those 29 states, people also buy them just to say "We run on clean energy." A friend of mine has an electric car and buys renewable energy to go with it. Did the actual electrons in his car come from a wind turbine? No, but he's helping make wind power more economically viable through the renewable energy credits.

</comment></comment></comment></comment><comment> semi-extrinsic "Bosch to buy lots of carbon offsets by 2020." Without any breakdown on how much is just buying carbon credits, and without any comparison to emissions further down in their supply chain, I'm skeptical about whether this is meaningful.

<comment><USER7> > Carbon offsets are to be gradually scaled back by 2030, and Bosch is > stepping up investments in renewable energies to this end.

They're temporary until they get their renewable energy infrastructure in place. Not ideal, but they seem to have a plan.

<comment> semi-extrinsic So in the longer term we're still left with the question, how much of the total emissions (including supply chain) of Bosch is due to Bosch's use of electricity?

If somebody makes a battery final assembly plant in Iceland, and run it on geothermal energy only, but buy battery cells manufactured in China with energy from a brown coal powerplant, it's not so interesting that the 1% of emissions from final assembly was removed.

</comment></comment></comment><comment><USER8> I kinda like Bosch and props to them for their investment, but isn't offsetting CO2 kinda like sending your trash to China and then complaining how they ruin the planet?

<comment><USER9> > I kinda like Bosch

Bosch is indeed interesting because it is over 90% owned by a charitable foundation, the rest is family property.

<comment><USER10> Damn, now I feel like I made the wrong choice when I bought into the Ryobi One+ power tools. Would be nice if we just had batteries that are compatible across different manufacturers' lines. Sigh.

<comment><USER11> As long as the voltage is the same, you can buy or make (3d printed plus a little bit of wiring—you can find files on thingiverse) adapters.

The 20V line of DeWalt, Porter Cable and Craftsman are all compatible with slight modifications to the plastic on the battery housing.

I know that's too much effort for most people, but it's nice to know that it's _possible_.

</comment></comment></comment></comment><comment><USER12> Bosch owns Dremel. I sent-in my five year old Dremel rotary tool for repair, along with payment info, fully expecting to get charged. I even noted on the repair slip "feel free to charge me for the repair".

Instead, Bosch sent back a completely refurbished Dremel in almost brand new condition for free.

I was like, damn they just earned a customer for life.

Anyhow, I know I am biased but I have a little faith this carbon initiative is legit.

</comment><comment><USER13> Let's not fall for this corporate propaganda and delude ourselves into thinking that a profit seeking entity will somehow pay "social dividends" at the expense of profits.

"Bosch has agreed to pay $327.5m to resolve allegations in the US that it played a significant role in Volkswagen's diesel emissions scandal." [https://en.wikipedia.org/wiki/Robert_Bosch_GmbH#Role_in_emis...](https://en.wikipedia.org/wiki/Robert_Bosch_GmbH#Role_in_emission_cheating_software) [https://www.ft.com/content/964a2f72-e898-11e6-967b-c88452263...](https://www.ft.com/content/964a2f72-e898-11e6-967b-c88452263daf)

<comment><USER14> Speaking of "propaganda" and then using the argument "they have admited guilt in the past, therefore any future action must be malevolent" is interesting...

<comment><USER13> Just because green energy became as cheap as fossil and they can afford to switch without sacrificing profits doesn't mean they are taking "climate action". It's the same as if I claimed credit for "climate action" because I am paying energy tax. I am not saying this is malevolent. But it's at best neutral.

</comment></comment></comment><comment><USER15> Not many know but Bosch is owned 92% by a nonprofit, so they are practically a nonprofit company.

</comment><comment><USER16> Hard to believe, these promises van Bosch. Will they fake it again?</comment>


Driver stranded after connected rental car can't call home - <AUTHOR> https://arstechnica.com/cars/2020/02/driver-stranded-after-connected-rental-car-cant-call-home/ <comment><USER2> Also posted here: [https://news.ycombinator.com/item?id=22355263](https://news.ycombinator.com/item?id=22355263)</comment>


The Greatest Scam in Tech - <AUTHOR> http://gizmodo.com/5726071/the-greatest-scam-in-tech

<comment><USER2> This actually seems like a decent piece of journalism from Gizmodo.

I didn't know they had it in them.</comment>


A former Theranos employee's account of life inside the company - <AUTHOR> https://www.reddit.com/r/tech/comments/8rmudm/i_worked_at_theranos_and_this_is_a_glimpse_of_my/ <comment><USER2> The biggest takeaway here: surround yourself with the right people.

I find it hard to believe Holmes wanted to outright commit fraud with Theranos. Instead, some combination of startup "disruption" tactics and a crew of unqualified yes men led to a toxic company culture that cultivated lying and, eventually, criminal fraud.

On the first point: There's a very real culture in Silicon Valley where it's expected that everyone lies, at least a little bit. Startups will massage their numbers in VC pitch decks, or launch "Wizard of Oz" products that aren't based on new tech. If you're on a client-facing team, you're expected to learn which white lies to tell. Most startups get away with this without a problem, and Theranos probably expected to as well when they came out of stealth mode and debuted their testing equipment. But this process doesn't work in biotech when it affects real consumer health outcomes; there is a reason behind much FDA bureaucracy, and it's to protect people's health. The tech industry could use a better ethical backbone overall.

On surrounding yourself with the right people: The anecdote about the manager who lied about results, was given promotions and accolades, and then promptly quit when it became time to become accountable, was telling to me. First, there was a lack of checks and balances in place to prevent these lies—how was Holmes supposed to know the manager was lying? The board had little technical or scientific background, and it's not clear that the company set up processes to ensure research was sound. And the most likely reason why? They probably just trusted people and didn't expect that these problems could happen. The only way to ensure you're not blindsided by issues like these is to make sure those around you are capable, experienced, and have been through this before.

Company culture is everything. As bad as Theranos is, the tech industry is rife with fraudulent practices and bad apples. I'd hope Holmes' criminal charges make executives pause and think about setting up processes to allow for honesty and accountability. Unfortunately, though, the mainstream narrative has been to paint Holmes as an unsophisticated crook instead of looking at the systematic problems of the company as a whole, and that means people will keep on keeping on with the practices that led to Theranos' downfall.

<comment><USER3> > there is a reason behind much FDA bureaucracy, and it's to protect people's > health.

This is what people don't realize when they try and say the FDA is a bureaucratic nightmare. Every process in place is designed to make sure that the drugs that hit the US market work. Look at what happened with Thalidomide. The FDA didn't allow it to hit the US market due to strict requirements about what tests and processes the drug companies were required to follow. Europe had a massive problem, while the US didn't.

What most people don't realize or know, is that the FDA will readily expedite promising drugs and/or products if results are promising and the data is valid. Companies, if they have strong data from Phase I or II trials, can be bumped to the top of the review queue or be granted interim permission to sell their drugs before Phase III trials are complete.

I personally think the FDA is a great example of a well designed bureaucracy. The value it adds to the public is insurmountable, while not being unreasonable.

<comment><USER4> Are there examples other than thalidomide? Because e.g. the FDA was just as bad with Vioxx and worse with OxyContin.

<comment><USER3> I, personally, don't consider Vioxx a failing of the FDA. I might be wrong, but reading the Wikipedia article makes it sound like more of issues surrounding the drug's promotion and marketing- not the drug itself (considering the US and Canada both voted to allow it back on the market). And OxyContin's issues (I think) fall on the DEA and not the FDA. Oxy does what it is supposed to do really well, and the side affects are known.

I just used Thalidomide as an example of where the FDA got it right. The fact that we havn't see other drugs like that pop up, tells me that the system is working.

<comment><USER4> > I, personally, don't consider Vioxx a failing of the FDA.

I was following the case in real time, and it certainly looked like a failing of the FDA and being way way too cozy with Merck about it; compared to how it looked then, the wikipedia article looks incredibly white washed.

I'm not sure we read the same Wikipedia article - the one I read said that Merck withheld information from the FDA, and makes no mention of any resulting sanctions or penalties (which is exactly how I remember it). Does this sound like a working regulatory agency to you?

> And OxyContin's issues (I think) fall on the DEA and not the FDA. Oxy does > what it is supposed to do really well, and the side affects are known.

Not at all. Perdue made false claims about how long acting OxyContin is, and as a result of the recommended prescription, many people both suffered and got hooked, see e.g. [0], which was the first result for "oxycontin perdue abuse", but by no means the only one.

> I just used Thalidomide as an example of where the FDA got it right. The > fact that we havn't see other drugs like that pop up, tells me that the > system is working.

... to me, the fact that Thalidomide is basically the only example that everyone brings up, it means that the European system is essentially equally effective, despite your implied claim ("Europe had a massive problem, while the US didn't.") that the US one is superior.

[0] [https://www.nytimes.com/2018/05/29/health/purdue-opioids- oxy...](https://www.nytimes.com/2018/05/29/health/purdue-opioids- oxycontin.html)

</comment></comment></comment></comment></comment><comment><USER5> Just wow:

Q: I heard a rumor that Elizabeth Holmes' deep voice is fake, as in a part of the performance, like not blinking, any truth to that?

A: Yep, true. Early on someone gave her advice that if she deepened her voice the male dominated business scene would take her more seriously.

<comment><USER6> That actually works in meetings or other group situations when people seem ignore my points - deeper voice works better. Not sure why doing it would be shocking. It is tiring to do it all the time through. Men chage their voices based on social situations too.

It works also with students when you are teaching.

I am pretty sure she also carefully selected cloths and hair style to project the right image and thought in advance about what she is going to say. It is the same thing. That is what all charizmatic leaders, whether good or bad, do all the time.

<comment><USER5> Yes, agreed. However, this full-time is very extreme.

</comment></comment></comment><comment><USER7> Pretty good writeup, as it sheds light on what it was like to work at and tolerate (for a few years) such a poisonous company. Even with all the shady things observed, and the fact that Holmes's ideas and goals were a big sham, the author seems to have been engaged enough in the science to think -- at the time -- that the goals were legit.

<comment><USER8> Actually it sounds like early one he decided it wasn't legit. He says he only stayed with Theranos because he literally couldn't find a position elsewhere.

<comment><USER7> His complaints are heavily focused on how the company had a shit culture and terrible scientific practices. But he doesn't describe it, from the inside, as being the total scam that it looks like from the outside:

> _If they had used some of the more sensitive methods or invented a new > method they probably could have made some, but not all assays work._

> _Part of the problem was that they surrounded themselves with people who > told them what they wanted to hear. Ultimately, even if they hired the right > people from the get go, and those people pushed for other methods they didn > 't like, they would have been marginalized, pushed out and replaced by > people who were "yes" people._</comment></comment></comment>


Coronavirus puts moral systems to the test - <AUTHOR> https://www.bloomberg.com/opinion/articles/2020-03-29/coronavirus-pandemic-puts-moral-philosophy-to-the-test <comment><USER2> Paraphrasing Nassim Taleb, eventually social risk becomes individual risk. Places like NYC are already there.

[https://medium.com/@FasinFoxtrot/stay-the-f- home-d43ffea8b4](https://medium.com/@FasinFoxtrot/stay-the-f-home-d43ffea8b4)

</comment><comment><AUTHOR> I didn't use the page title because Bloomberg's original was clickbait that didn't really reflect the article. instead I used text from the end of the article summary.</comment>


Ask HN: Why doesn't Apple finish what Google started with Fiber? - <AUTHOR> They certainly have the cash to finance such a massive undertaking. It could be step one in bypassing the cable monopolies, and maybe a precursor to their own voice network (blanket the US with WiFi calling maybe?). The impending FCC Net Neutrality ruling has got me hoping that someone will step forward and take this as a (long term) opportunity to shake up the market. <comment><USER2> The real challenge is recreating the conduits and rights of way that the telephone companies have spent the last 100 years establishing. ATT's largest, most valuable asset is not the phone switches/networking gear or the copper in the ground or even the fiber they've laid over the last 20 years. It's the rights of way they control. Google's big battle with the incumbent phone companies is for access to right's of way and telephone poles. ATT is fighting tooth and nail to deny them access. Apple/Google would be better off purchasing a large cable company so you have a large network in place immediately rather than having to build one from scratch

Joe</comment>


My Go Resolutions for 2017 - <AUTHOR> https://research.swtch.com/go2017 <comment><USER2>
        > Part of the intended contract for error reporting in Go
        > is that functions include relevant available context,
        > including the operation being attempted (such as the
        > function name and its arguments).

I know the Go folks don't like exceptions, but this is an example of them learning the hard way that about one useful thing they lost by deciding to not do exceptions.

Exceptions give you stack traces automatically. All of that context (and more) is there without library authors having to manually weave it in at every level of calls.

        > Today, there are newer attempts to learn from as well,
        > including Dart, Midori, Rust, and Swift.

For what it's worth, we are making significant changes to Dart's generics story and type system in general [1]. We added generic methods, which probably should have been there the entire time.

Generics are still always covariant, which has some plusses but also some real minuses. It's not clear if the current behavior is sufficient.

Our ahead-of-time compilation story for generics is still not fully proven either. We don't do any specialization, so we may be sacrificing more performance than we'd like, though we don't have a lot of benchmark numbers yet to measure it. This also interacts with a lot of other language features in deep ways, like nullability, whether primitive types are objects, how lists are implemented, etc.

[1]: [https://github.com/dart- lang/dev_compiler/blob/master/STRONG...](https://github.com/dart- lang/dev_compiler/blob/master/STRONG_MODE.md)

<comment><USER3> Having just spent the last two months writing Go code, exceptions are the thing I miss most (well, besides the ternary operator and map/reduce operations). Not only are errors painful to debug without stacktraces, but every single method call is followed by three lines of "if err != null {". I am amazed that folks tolerate the sheer amount of repetitive typing required by the language.

<comment><USER4> Changing the language is like changing the country residence. Some things take long time to get used to, unless you're highly mobile traveller :)

I couldn't imagine myself returning to languages with exceptions and ternary operators, for example.

<comment><USER5> > I couldn't imagine myself returning to languages with exceptions and ternary > operators, for example.

Why ? Is it because no language with those feature is good (let say you wouldn't like to return to Java for instance), or is it because you genuinely prefer this over ternary operator :

        if expr {
            n = trueVal
        } else {
            n = falseVal
        }

<comment><USER4> Well, from my 15 years experience for each nice example of ternary operator being useful there are 10 more examples where it's being used improperly and makes code hardly readable.

I know that the typical answer is "it's just bad programmer", but that's where Go chooses different view. Many design decisions in Go were taken with awareness of the social context of programming.

If the feature incentivizes using it in a wrong way - it's not a bad programmer, it's a bad feature. Programming language is a language between humans in a first place and it should be readable as much as possible, it should deincentivize using obscure and easy-to-use-improperly things.

It so much better when you go to practically any Go repository and find that code is readable and clear. I've never had this experience with any other language before.

PS. Found one of the real examples of abusing ternary operators. That was one of the coolest I've seen. And I guess it's easy to understand that the same programmer wouldn't write the same with "if .. else .." blocks in Go. He would realize that it's too verbose and hard, hence probably wrong design, so he need to find better solution within the space of language features. [http://imgur.com/a/hjKOe](http://imgur.com/a/hjKOe)

<comment><USER6> > If the feature incentivizes using it in a wrong way - it's not a bad > programmer, it's a bad feature.

So there's nothing good about alcohol (it may cause liver damage), cars (they may cause accidents), prescribed drugs (they may have unpleasant collateral effects), ...

Hey, it's also true that programming incentivizes bugs, so programming is bad. Let's stop programming!

<comment><USER7> It's weird how people miss the conditional operator but not switch case fallthrough.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Along with generics, they should probably also reconsider algebraic data types, such a enums with values. This is _the_ best feature swift adds to the table hands on, and it seems to me as it's pretty orthogonal to the rest of the language ( although it carries a lot of other features with it, such as pattern matching).

They wrote that they considered it to be redundant with interface programming, but really i don't understand why. Interface is about behavior, not data. An int doesn't "behave" like one, it _is_ one. And something that's either an int or an array of string, doesn't "behave" like anything you'd want to describe with an interface...

As an example, one should see how protobuf "one of" messages are dealt with in go : switch on arbitrary types followed by manual typecasting. That's just gross...

<comment><USER9> I see where you are coming from, but that isn't the go way.

Switch on arbitrary types, followed by typecasting? That's the go way. No surprises. Explicit instead if implicit behavior.

<comment><USER8> If you have a look at swift, it's also very explicit, and non-magical ( which is why i like it so much). The difference with go is that you can't make any type error when unwrapping the enum, because the compiler knows what are the different possibilities.

I see no reason for go not to adopt it, in all honesty. it's nothing like generics, because it doesn't seem to add complexity to the rest of the language ( imho ).

<comment><USER10> > you can't make any type error when unwrapping the enum

This is also true in Go with type switches:

        switch y := x.(type)
            case MyStruct:

And with type assertions:

        y, ok := x.(MyInterface)

In both cases, y is of the correct type. The ok is optional, if omitted and the assertion fails, you'll get a runtime panic.

<comment><USER11> y is of the type you asked for, yes, but that isn't necessarily the type that should be there if the programmer makes a mistake, or if the underlying code changes. With an enum, the types are written in one place, and the compiler connects the dots, giving compile-time errors about mistakes/mismatched expectations. This similar to how one can call `foo(x)` and the return value's type is known, no need to first cast the function to the type the programmer thinks it should be. The casting pushes type errors to execution-time rather than compile-time.

<comment><USER10> > The casting pushes type errors to execution-time rather than compile-time

Which is exactly what pattern matching does, which is what I was responding about.

<comment><USER8> Ok, i'm starting to understand what we're disagreeing on. You're talking about pattern matching with dynamic expressions ( don't know the official name for that), such as what you find in erlang, i'm talking very basic enum unwrapping based on types, which is compile time checked. Swift also adds some kind of dynamic expression to patterns, which may break exhaustiv checking, but in the case of go, just a simple type check would be a great start.

Edit ( since i can't reply) : just look at [https://developer.apple.com/library/content/documentation/Sw...](https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Enumerations.html) with something like the barcode example.

It's all compile time checked.

<comment><USER10> > very basic enum unwrapping based on types, which is compile time checked

Sooo just accessing fields on a struct? I don't understand the distinction you are trying to make.

<comment><USER11> It's like accessing fields on a struct, where you can only access the ones that are guaranteed to be valid. For instance, in existing Go, the struct method would be having two fields, * X and * Y, where (in theory) exactly one of them is non-nil, but both can still be accessed. This requires manually maintaining this invariant (and remembering to check when accessing), as well as sacrificing performance by allocating. Using an ADT would allow storing the X and Y by value, as well as guaranteeing that the invariant of "X xor Y" is always true.

<comment><USER10> Sounds like type-assertions cover that use case just fine. However, you are correct that you can't do this without allocating. ¯\\_(ツ)_/¯

<comment><USER11> As people keep saying, type assertions do not have as strong compile time assurances as ADTs.

<comment><USER10> And as I keep saying: I don't value those assurances and in fact find them to be a net loss when accounting for breaking changes changes to clients.

<comment><USER12> You pay the price of getting the bugs and edge cases out regardless of whether you have compile time assurances.

The complexity is inherent and you can either choose to make it implicit and play the losing game of ensuring it doesn't fail with tests or make it explicit from the outset.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I've always wanted to like Go, but every time I get ~1,500 lines in a project, I remember my pain points. I totally see why other people like the current version of Go, but as it stands, it's not an ideal match for my brain.

Dependency management is a big pain point for me. I'm really glad to see several of my pain points on the list for this year, including another look at generics.

Generics are genuinely tricky: They allow you to write many kinds of useful functions in a type-safe manner, but every known approach for implementing them adds complexity to the language. C#, Java and Rust all bit the bullet and accepted (some) of this complexity. Maybe Go will find a sweet spot, preserving its simplicity but adding a bit of expressiveness?

Anyway, it pleases me to see that the Go team is thinking hard about this stuff. At the bare minimum, I'm going to be contributing code to other people's open source Go projects for the foreseeable future. :-)

<comment><USER14> I think it is no surprise that one goal of Go is coding at large where large teams are involved. For single person projects that I think you are doing, many people want intellectually stimulating language where Go may fall short.

<comment><USER15> > I think it is no surprise that one goal of Go is coding at large where large > teams are involved.

I don't buy that. There is no proof Go programming at large scales better than Java programming at large.

Go didn't reach the scale of Java programs yet. And no, Kub or Docker, while fairly large, are nothing compared to 15 y.o. multi-million line Java codebases. Go certainly needs less bureaucracy due to the ease of deployment, but it doesn't mean Go projects scale better in large teams.

> For single person projects that I think you are doing, many people want > intellectually stimulating language where Go may fall short.

I really hate this kind of arguments. Features like generics aren't intellectually stimulating, they are here because people want to write type safe code. Context.Value(interface{})interface{} isn't type safe code.

Now tell me, what is more intellectually challenging? writing concurrent programs free of race conditions or generics?

<comment><USER14> > Go didn't reach the scale of Java programs yet. And no, Kub or Docker, while > fairly large, are nothing compared to 15 y.o. multi-million line Java > codebases.

I didn't claim Java projects do not scale. They do. I use Java all the time at my day job. I would use whatever makes sense. Maybe someday Rust is absolutely essential I would use it then.

> Features like generics aren't intellectually stimulating, they are here > because people want to write type safe code.

When people need generics they can use languages with generics facility then. I am not arguing otherwise.

<comment><USER16> > When people need generics they can use languages with generics facility > then. I am not arguing otherwise.

This is the point where Go's advocates disagree with its detractors. The latter tend to feel that you need generics (Just like you need to program in something higher level then assembly) far more frequently then they are told.

</comment></comment></comment></comment></comment><comment><USER17> Posts like this really return me the confidence in the future of Go the language.

I very much wish Go to succeed, it's built on a few nice ideas, but where it currently is it has a number of usability impairments that stop me from wanting to work with it.

But I see that these impairments are _seen_ as problems by key developers, and work is underway to eventually fix these problems. (And this is besides the "routine", incremental but very important improvements, such as GC or stdlib.)

<comment><USER18> > But I see that these impairments are seen as problems by key developers, and > work is underway to eventually fix these problems.

What will inevitably happen is that Pike et al will argue that such things are merely problems because "you're doing it wrong" or "there's no way to do this without any tradeoffs of any kind" (generics), and ultimately very little will change.

<comment><USER19> The other alternative is that they allow them, and Go slowly loses its magic and becomes another Algol, C++, or Java.

<comment><USER20> God forbid it become as useful and ubiquitous as C++ or Java.

</comment></comment></comment></comment><comment><USER15> > Not enough Go code adds context like os.Remove does. Too much code does only

Well, the error interface is { Error()string } and gophers were told to use errors as values, not errors as type because supposedly "exceptions are bad". By providing context you are just re-inventing your own mediocre exception system. Why use errors as value at first place if you need context? just put exceptions in Go, therefore people don't need to use a third party library to wrap errors in order to trace the execution context.

<comment><USER21> I really don't miss having invisible control flow for expected conditions blowing up my programs with long stack traces.

There's a whole lot of space between "include useful context in errors" and "exceptions".

(And FWIW, Go does have exceptions, it just calls them panics, and has a culture not using them for "known knowns" error conditions.)

<comment><USER15> > I really don't miss having invisible control flow for expected conditions > blowing up my programs with long stack traces.

As opposed to panics? Checked exceptions don't blow up in your face, you have to handle them. Nil errors and type errors might yet these also happen to Go. I see no difference with Java here. Go isn't better when it comes to error handling, in fact Go is extremely tedious when it comes to error handling.

> (And FWIW, Go does have exceptions, it just calls them panics, and has a > culture not using them for "known knowns" error conditions.)

So Go has both(unchecked exceptions and errors as "value"), how does it make things better? it doesn't. If it did, the blog wouldn't be talking about people "handling errors the wrong way".

<comment><USER21> I've found it helpful to distinguish between errors that are program bugs and errors that are conditions of the outside world (network errors, invalid data, etc).

I think it depends somewhat on the kind of software you're writing.

Being very careful with errors is quite handy for a long-running server processes; maybe (maybe!) not so worth it for a program that starts and stops within the attention span of a single user.

<comment><USER22> _errors that are program bugs and errors that are conditions of the outside world_

That also happens to be the intended distinction between Java's checked and unchecked exceptions.

</comment></comment></comment></comment></comment><comment><USER23> > Not enough Go code adds context like os.Remove does. Too much code does only

       if err != nil {
           return err
       }

Is anyone else surprised that forcing programmers to do the tedious, repetitive, and boring work of being a manual exception handler overwhelmingly results in people doing the least amount of effort to make it work?

I feel like so many of the headaches of go could have been avoided had the developers spent any time whatsoever thinking about the _programmers using it_.

<comment><USER24> I think that the Go team worked very hard to make something that programmers actually like using. Yes, it is annoying to do a lot of `check if err is nil`, but at the same time, exception handling is something that can be esoteric, whilst it's trivial to see what your example does.

I also feel like there has been a lot of emphasis put on keeping the APIs consistent, which is something that a lot of developers will tell you makes PHP a nightmare sometimes.

<comment><USER23> > Yes, it is annoying to do a lot of `check if err is nil`, but at the same > time, exception handling is something that can be esoteric

People keep saying this, but the alternative doesn't have to be exceptions.

Rust strikes a great balance here. There's no nil, you _must_ handle the Err case of a Result enum, or the None case of an Option enum (this is _much_ nicer than go; in go after `val, err := failingThing()`, it's entirely possible to accidentally use `val` as a meaningful value, which is strictly impossible in Rust), and you can use functions like `map` and `and_then` on these types which has the benefits of explicit error handling without the absurd loss of readability caused by dozens of identical error handling clauses.

> I also feel like there has been a lot of emphasis put on keeping the APIs > consistent

This isn't something special about go. This is a minimum requirement for a language nowadays. Rust, Ruby, Python, Swift, and others all do this.

</comment></comment></comment><comment><USER25> Regarding error context: I'd advocate simple error-chaining using a linked list. If a function fails, it returns an error wrapping the underlying error as the cause, and so on up the stack. The top of the stack can inspect or print the error chain ("A failed because B failed because ..."), or pinpoint the error that was the root cause.

I would love for Go to include something like this:

        type Error struct {
            Description string
            Cause       error
        }

        func NewError(cause error, descriptionFmt string, args ...interface{}) error {
            return Error{
                Description: fmt.Sprintf(descriptionFmt, args...),
                Cause:       cause,
            }
        }

        func (me Error) Error() string {
            if me.Cause == nil {
                return me.Description
            }
            return fmt.Sprintf("%v: %v", me.Description, me.Cause.Error())
        }

        func RootCause(err error) error {
            if err, ok := err.(Error); ok && err.Cause != nil {
                return RootCause(err.Cause)
            }
            return err
        }

<comment><USER26> Check out [https://github.com/pkg/errors](https://github.com/pkg/errors)

<comment><USER27> Great library.

</comment></comment></comment><comment><USER28> > In the long-term, if we could statically eliminate the possibility of races, > that would eliminate the need for most of the memory model. That may well be > an impossible dream, but again I'd like to understand the solution space > better.

Unless I'm mistaken, this is an impossible dream as long as shared memory exists. It's the core tradeoff that distinguishes the Erlang runtime from the Go runtime (there are others, but they all stem from this).

Your goals are either memory isolation for better distribution/concurrency/clustering/fault tolerance/garbage collection or shared memory for ability to work with large datasets more efficiently.

It's one of those details that changing it would essentially create a new language. You'd have code, packages and libraries that either worked that way or they wouldn't.

IMO, this is an area where Go gets into dangerous territory of trying to be all things to people. Be great at what you're good at which is the "good enough, fast enough, portable enough, concurrent enough, stable enough" solution for backend services in most standard web architecture.

If people need distributed, fault tolerant, isolated, race proof, immutable run times that aren't quite as top end fast and aren't ideal for giant in RAM data structures...there's already a well established solution there by the name of Erlang (and Elixir). They made the tradeoffs already so you don't have to reinvent them.

<comment><USER29> > Your goals are either memory isolation for better > distribution/concurrency/clustering/fault tolerance/garbage collection or > shared memory for ability to work with large datasets more efficiently.

The isolation is not physical, but logical. Implementations are free to use zero-copying and make everything just as efficient. Theoretically compiler could even optimize message passing overhead away for systems with shared memory in some cases. The opposite is also true, shared memory is also logical and there is a lot of room for a lot of clever things, like eliminating races.

<comment><USER28> How can you eliminate races with shared memory in a concurrent environment?

<comment><USER11> Rust's "sharing xor mutability" guarantee eliminates data races by (usually statically but also dynamically) ensuring that a memory location won't be mutated when multiple places/threads can access it. Of course, the machinery required for this in Rust is relatively complicated (e.g. as a side-effect, it allows one to also forgo a GC without losing safety).

<comment><USER28> How is that different from a mutex lock?

<comment><USER11> Rust lets you be precise about placing the locks exactly where they are needed, with compile time errors if a lock isn't locked when accessing data, or a lock is missing. Fixing data races with locks for arbitrary code, without more static guarantees in the language, essentially means locks have to be held for most memory accesses: it's hard/impossible to tell if that location will be accessed concurrently. (This is why CPython has a GIL: it's easier to only let one piece of code execute at a time than to handle data races in arbitrary code.)

[https://blog.rust-lang.org/2015/04/10/Fearless- Concurrency.h...](https://blog.rust-lang.org/2015/04/10/Fearless- Concurrency.html) is interesting reading.

</comment></comment></comment></comment></comment></comment><comment><USER14> Excellent read. Official package management looks more about 'when' than 'if' now. As someone in Java world who did not graduated to Maven/Gradle and stuck to ANT I hope it will be minimalistic and immediately useful to Go users.

<comment><USER30> After three years of rogue Java development, maven was an epiphany to me. At the beginning it has a very, very shallow learning curve.

</comment></comment><comment><USER31> > all the way up the call stack, discarding useful context that should be > reported (like remove /tmp/nonexist: above).

It's simple. With exceptions, we got used to "errors" that are, by default, debugable. But Go got rid of default debugable errors, and programmers are lazy.

<comment><USER32> The problem isn't the methodology. Its the library support. I (for my employee) wrote a library a few years ago (~go 1.1) with "errs.New" and "errs.Append(err, ..work like fmt..)" that generates error that look like:

      main.go:13 main.main(): highest level error;
        Details: foo.go:8 foo.ExportedMethod(): mid level error;
        Details: foo.go:42 foo.innerMethod(): low level error!

It provides handy helpers like GetRootErr and PanicToError too. I hope we can opensource it in the next month or two.

<comment><USER33> It's not that it can't be done, it's that it's not in the stdlib. Without being in the stdlib, each set of code solves the same problem in its own way harming conformity. It's gotten so bad that some libs include stack traces and some even parse panics. For example, how do I write a function that loops over the error chain if it may have come from several libs with different impls?

The problem is they shot themselves in the foot and may have to incorporate a form of "default" method to get around it like Java ended up having to. You can't have a "ContextualError" type because what does "Cause()" return? If it returns "errors.Error" then you require users to use a type assertion. If it returns "ContextualError" then it can't chain existing errors without wrapping. They also can't add anything to the "errors.Error" interface because they would invalidate all existing impls of that interface.

<comment><USER34> Python suffers immensely from this - libraries tend to reraise exceptions with a new, descriptive type, but usually don't append the stack, and essentially can't chain any custom data you may have added. Not having the complete causal chain can seriously hamper debugging, and unless it's built in it's unlikely to be adopted consistently.

Python 2 has nothing, and libraries haven't agreed on anything. Python 3 has "raise ... from ...", which largely resolves it, but I'm not sure what adoption is like. Anyone know?

</comment></comment></comment></comment><comment><USER35> I really enjoyed reading this thoughtful post. He addresses a lot of the pain points I've encountered when writing Go.

I know there probably won't be immediate fixes, but it gives me confidence in Go's future.

</comment><comment><USER36> "I don't believe the Go team has ever said "Go does not need generics." "

I think that's true, but I do think its been said by a number of Go users and advocates, which is where the perception comes from.

<comment><USER37> Meanwhile I've said "even if they don't introduce user defined generics it would be nice if they fixed the language defined ones"

The builtin generics are a mess. At this point I don't trust the go team to implement any more complicated generic system.

<comment><USER38> > The builtin generics are a mess.

Could you elaborate on this? I must not have used arrays, slices, maps, or channels enough to find that there's some common issue with all of them, other than that the user can't write her own functions generic over them.

<comment><USER37> The most obvious problem is that variance doesn't work.

You cannot pass a []string to something that expects a []interface{} for instance, even though you can put every item in the first in an instance of the second.

</comment></comment></comment></comment><comment><USER39> The go vet integration with go test looks interesting. I'm currently using github.com/surullabs/lint [1] to run vet and a few other lint tools as part of go test. It provides a nice increase in productivity for my dev cycle. Having vet + other lint tools integrated into my dev+test cycle has caught a number of bugs before they hit CI.

[1] [https://github.com/surullabs/lint](https://github.com/surullabs/lint)

Disclaimer: I'm the author of the above library.

</comment><comment><USER40> I would really like to see best practices in the documentation on how to include the right amount of error context, as mentioned in the article.

Also what to put and not put in context objects is really important to document as it could easily snowball into a catch-all construct and be totally misused after a while.

</comment><comment><USER41> _> Test results should be cached too: if none of the inputs to a test have changed, then usually there is no need to rerun the test. This will make it very cheap to run "all tests" when little or nothing has changed._

I'll be curious to see how this pans out, because it sounds like a very deep rabbit hole. Is there any precedent for this in other language toolchains? I've seen some mondo test suites in Java that could desperately use it.

<comment><USER42> [https://bazel.build/](https://bazel.build/) supports this. Bazel is Google's build system, open-sourced.

<comment><USER41> From reading [https://bazel.build/versions/master/docs/test- encyclopedia.h...](https://bazel.build/versions/master/docs/test- encyclopedia.html) , it looks like Bazel's rules are quite strict (not to mention Unix-specific), and requires writing a separate rules file to configure test behavior (e.g. an "external" tag to denote tests that cannot be cached). I anticipate that it would be difficult to retrofit such things onto Go's existing ecosystem in-place (or any language's, for that matter), especially without sacrificing Go's minimalist philosophy (i.e. "this function is a test if its identifier begins with `Test`, end of story"), especially considering Go's documented aversion to config files WRT package management.

As an optional external tool it may work quite nicely, however.

<comment><USER43> Bazel's rules are _extremely_ strict. For what it's worth when I was at Google all the Go code was built with Bazel. Most of the google engineers don't experience this pain internally I imagine.

</comment></comment></comment></comment><comment><USER44> Happy to see that being able to not use GOPATH is at last considered seriously! During years, Go people wanted to force people to work their way. We can still this state of mind in the associated bug report: [https://github.com/golang/go/issues/17271](https://github.com/golang/go/issues/17271).

</comment><comment><USER45> > it would be nice to retroactively define that string is a named type (or > type alias) for immutable []byte

Perhaps an array is better than a slice, so `immutable [...]byte` Also, the for-range loop would have to behave differently so I guess it's a version 2 change. And if semantics are changing anyway, I'd prefer a `mutable` keyword to an `immutable` one.

<comment><USER38> > Perhaps an array is better than a slice, so `immutable [...]byte`

Slice is the right choice, I think. Were they to choose array as the alias, the language would need to "bubble up" the "array length" type parameter to the string type, which would make strings of different byte lengths incompatible types. But hey, Go is already pretty clearly inspired by Pascal, so maybe we'll see that after all :-)

</comment></comment><comment><USER46> Re dependencies:

Glide takes our team 90% of the way, but is a bit glitchy (need to wipe ~/.glide sometimes) & lacks a command for `npm link` type functionality.

</comment><comment><USER47> Great !

</comment><comment><USER48> It is nice that Go is trying to learn from Pony and Midori. I wonder whether any Gophers have started to learn about object-capability theory and the _reasoning_ behind why so many values are immutable in Pony, Midori, Monte, and other capability-safe languages.

To expand on this a bit, in ocap theory there is a concept of "vat", an isolated memory space for objects which has its own concurrent actions isolated from all other vats. In a vat model, data races are nearly nonexistent; in order to race, one would have to choose a shared variable in a single vat, and then deliberately race on it. But this is not common because ocap theory enforces heavy object modularity, and so shared variables are uncommon.

Additionally, a "deliberate race" is quite tricky. Vats prepare work with a FIFO queue. In the Monte language:

      # A flag. We must start it as `false` because Monte doesn't allow uninitialized names.
      var flag :Bool := false
      def setFlag(value :Bool) :Void:
        flag := value
      # Set the flag to `true` immediately.
      setFlag(true)
      # Set the flag to `false` on the next turn.
      def first := setFlag<-(false)
      # Set the flag to `true` on the next turn.
      def second := setFlag<-(true)
      # And finally, when those two actions are done, use the flag to make a choice.
      when (first, second) ->
        if (flag) { "the flag was true" } else { "the flag was false" }

You might think that this is non-deterministic, but in fact the delayed actions will each execute in order, and so the flag will be set first to `false` and then to `true`.</comment>


Better Log Parsing with Logstash and Google Protocol Buffers - <AUTHOR> http://tech.trivago.com/2016/01/19/logstash_protobuf_codec/ <comment><USER2> Author here, in case of questions.

</comment><comment><USER3> Very Useful. Thanks!</comment>


DoppioJVM brings JVM apps to the browser - <AUTHOR> http://www.javaworld.com/article/3075031/web-development/doppiojvm-brings-jvm-apps-to-the-browser.html <comment><USER2> Related note: with all the talk about web assembly, why -not- use the JVM bytecodes, instead of reinventing the wheel for a 5th time?

Watching languages compile to JavaScript is sort of hilarious.

</comment><comment><USER3> > It can execute programs written in most JVM languages, including Java, > Clojure, Scala, JRuby, and Jython, since it can run those languages out of > their JAR files.

I'm wondering about Kotlin and Apache Groovy -- perhaps they can't be run straight out of their JAR files!

</comment><comment><USER4> Project home: [https://plasma-umass.github.io/doppio-demo/](https://plasma- umass.github.io/doppio-demo/)

</comment><comment><USER5> Welcome back?

<comment><USER6> That's the same thing that came to my mind.</comment></comment>