The cave divers who went back for their friends - <AUTHOR> http://www.bbc.com/news/magazine-36097300 <comment><USER3> I find the sentimentality towards dead bodies difficult to relate to. I would be fine with my body being left and would not want someone else to die attempting to retrieve it. I suppose my friends and family might not feel the same.

<comment><USER4> This wasn't sentimentality, it was just adrenaline junkies justifying themselves.

I really do get why people cave dive and do dangerous things. It's a lot of fun. But really, at the end of the day, they did this because it was a rush. There's no other rational reason to do something to risk your life doing someone your friends just died doing for no other reason than it was exciting.

lol, go ahead and downvote. I do a lot of adrenaline rush type activities, but I've never tried to pretend it was anything other than just dumb, life risking adrenaline pumping distraction from life.

<comment><USER5> so what is life, if not some boring stuff around adrenaline pumping distractions? you do not hold the key to the proper way of living other people's lives.

sorry for my bad english and for feeding a troll.

<comment><USER6> I wish people think twice before calling troll. That word has so lost it's original meaning, and is now a days used to shoot down any dissenting opinions.

I say this as someone who 100% agree with the first part of your comment.

<comment><USER5> I think you are right. My troll detector was triggered by the request for downvotes.

</comment></comment></comment></comment></comment><comment><USER7> OK, before people start saying why the hell would you do such a sport. Not the same but similar - I did caving for a big part of my childhood until I was 20. I miss it. The connections you build with the people you do this are very strong, your life depends on it. The places you see are mind blowing - <USER2> running into a 60m dive after entering a small hole of maybe 30 cm of diameter, or visiting a room bigger than a stadium at -500m. And there is a certain romance around it - places with names from people that discovered them long ago, places yet to be found, old guys telling gone stories of exploration. Up in the mountains, maybe 1 hour from my old home back in Italy, there is still a search for a special entrance to a big cave system (runs 1 km deep) in order to do explorations also during the winter (a big lake inside the cave closes the "classic" entrance after summer), this search has been going on for 20+ years now, still searching.

<comment><USER8> > _visiting a room bigger than a stadium at -500m._

Surely you mean -50m, right? :) Which system was that? It sounds lovely.

<comment><USER7> -500m

Check here: [http://www.scintilena.com/speleoit/atlas/molise/pdn.gif](http://www.scintilena.com/speleoit/atlas/molise/pdn.gif)

I got until the first P80. People camp close to this place few days to explore the part after that - here (remember, at -500m): [https://images.duckduckgo.com/iu/?u=http%3A%2F%2Fwww.bancaca...](https://images.duckduckgo.com/iu/?u=http%3A%2F%2Fwww.bancacapasso.it%2Fwp- content%2Fuploads%2F2013%2F10%2FPozzo-della-neve2.jpg&f=1).

Edit. Uhm, I think the guy in the middle is my father like 15/20 years ago, I have to ask him.

<comment><USER8> Ah, I read that you did "cave diving" not "caving" \-- that explains it :) That does indeed look like a really fun system, thanks for sharing.

</comment></comment></comment></comment><comment><USER9> There is a documentary coming in 2016 about this dive, here is the english website:

[http://divingintotheunknown.com/en](http://divingintotheunknown.com/en)

There was also an excellent article about the dive (with lots of pictures and videos that they recorded during the dive and interactive map) at the biggest newspaper in Finland, unfortunately only in finnish.

[http://dynamic.hs.fi/2014/syvalla/](http://dynamic.hs.fi/2014/syvalla/)

<comment><USER10> I think i found the article in english.

[http://dynamic.hs.fi/2014/deep/](http://dynamic.hs.fi/2014/deep/)

</comment></comment><comment><USER11> It's surprising to see such an article #1 in HN ... right after a long weekend of cave diving training!

It's a sport that requires a lot of preparation, planning, risk estimation and counter-measures. My hobby cave dives are nothing like such explorations, but the principles are the same.

In the end, when you go diving, the level of risk is close to 0: one regulator may fail (risk around 1/100 if well checked), two won't fail during the same dive (risk of two failures 1/100 x 1/100 = 1/10000 which is negligible--if I got the figure right, I didn't double check! EDIT: it's rather 1/1000 x 1/1000 = 1/1.000.000). And we use two independent air tanks, and with air reserves managed with one regulator fault in mind, as well as the 'little' panic induce by the regulator fault. That's called the 1/4 rule, we use it in France in FFESSM diving organisation.

<comment><USER12> I guess that depends on how you think about risk - if it's about some probability of an unfortunate event, or maximum unavoidable damage in case of that event. A 1/10000 chance of certain death doesn't sound like something I'd like to take.

<comment><USER11> > A 1/10000 chance of certain death doesn't sound like something I'd like to > take.

(maybe I was a little bit off, it's more likely that the risk of failure is 1/1000, so sum is 1/1.000.000)

but the point is, it's more risky to drive back home after the weekend than to recreational cave dive, especially with dive fatigue!

<comment><USER13> You have more risks than just reg failure though. Losing your line, line snapping, floods, rockfall, silt bank collapse, getting physically stuck, just to name a few. Based on the number of cave divers and the number of cave diver deaths over the past few years I would say your odds of dying on a cave dive are far, far higher than driving home. I think if you believe that you are more at risk driving then you haven't assessed the risks accurately. I speak as an experienced caver with several cave diving friends.

</comment></comment></comment></comment><comment><USER14> I understand that people take pleasure in doing this sport because it's physically challenging and they find the challenge exciting.

> more than 11 hours after setting off on a dive that was supposed to take > five hours.

I mean this is just insane. I can't even imagine trying to do something in which any mistake could instantly cause my death for 11 hours straight.

> "There are lots of questions - the original questions - about where the cave > goes, and where the water comes from, and they are still there," he says. > "And I am not afraid of the cave."

I appreciate this attitude, but I'm wondering if it would diminish the sport at all to have autonomous vehicles explore the cave before a dive.

It doesn't remove the physical challenge of the sport itself, but it could help divers prepare for tough portions of the dive.

e.g. at 110m depth, narrow passage. Single file proceeding with X minutes budgeted for issues.

<comment><USER15> I'm an avid explorer, regularly setting off to do things that are not entirely "safe". (though nothing on this scale).

The story of Chris McCandless[1] (Into The Wild) spoke to me so strongly, I made the trek[2] into the wilderness where he passed away, an old bus on the side of a trail in Alaska.

Chris' is a very controversial story, with many people believing he was an idiot for wandering in there "unprepared" and many thinking he is inspirational. I wound up spending 4 years living in the North, exploring the far corners of Yukon and Alaska.

I feel strongly there are some personality types that just need to get "off the map" and I love the part of Jon Krakauer's book Into The Wild where he suggests having a piece of wilderness on the earth that literally has no map. People can choose to go in there to explore. They'll (likely) find mountains, rivers, lakes, caves, etc. but nothing will be mapped, everything is to be discovered. When they return, they can't talk specifics, or show photos.

Some of us want to go places that have been unexplored, and we accept that risk.

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

[2] [http://theroadchoseme.com/the-magic-bus](http://theroadchoseme.com/the- magic-bus)

<comment><USER16> Your story sounds amazing. I'm from the UK where every square cm of ground has been mapped, examined and sold to someone.

Some questions.

        1) What did you eat and drink?
        2) Where did you sleep?
        3) What was an average day like?
        4) How did you deal with days like christmas day, new years eve, your birthday, the solstice and any other special day to you.
        5) Did you see or find anything curious? Something that made you pause and wonder?
        6) Is that sort of adventure a man thing? Did you ever hear of a woman doing something similar by choice?

Just some questions that I have, don't answer them if they are impertinent. Just a curious :)

<comment><USER17> Every square CM of the US is mapped as well, and has been for a hundred years. The USGS is very thorough and all of their topo maps are freely available in the public domain.

<comment><USER15> Which is why, interestingly, Chris chose to not take a map when he hiked into the wilderness in Alaska.

<comment><USER18> I'm part of the "Chris McCandless was an idiot" crowd, but I guess he was intentionally not optimizing for survival. Into the Wild is still a very engaging book, but it frustrates me so much that people idolize a guy who made bad decision after bad decision.

The thing that pissed me off the most was when he burned his money instead of donating it to charity.

<comment><USER15> I understand where you are coming from.

> _he was intentionally not optimizing for survival_

That's a good way to say it. In all honesty - when I optimize for survival I actually find life too boring, easy and mundane. I want more excitement and adventure than that, so I understand why Chris did what he did.

> _who made bad decision after bad decision._

It's very easy to armchair quaterback. Have you hiked into the middle of nowhere in Alaska and tried to survive? Have you hunted your own food? Have you struggled to cross glacier-melt rivers?

I have, and a lot more. I've seen friends go underwater at -35C 100km from anywhere, had snowmobiles not start at -50C well over 200km from anywhere, had severe hypothermia where I thought I was hot, lost feeling in my fingers for hours, jumped up and down on the spot for hours in an attempt to warm up, etc. etc.) Anyone that does as well as Chris did is not an idiot.

Most people wouldn't last a week, let alone 3 months.

<comment><USER17> > Most people wouldn't last a week, let alone 3 months.

Not even the native people of the area could have done it. Hunting for sustenance isn't a solo activity. Hunting large game is high reward with high uncertainty. You probably need a group of at least five people. With multiple hunters only one of them has to land a kill to feed the group. And it means there is the manpower present to process or eat all of the meat before it spoils. Which is what happened to McCandless. He was a skilled hunter to bring down a moose with a .22 but he only got a few meals from the carcass before it rotted, wasting hundreds of pounds of meat.

I can point you to a record from 1770-ish of a native american woman who managed to survive for six months alone in far north Canada, after escaping from her slavers. The party who discovered her was shocked she could even be alive and none of them had ever heard of such a thing. (Samuel Hearne's journals)

edit: Bagging a single moose during the season isn't "sustenance". It is sport. If it ends up in a chest freezer, then it doesn't count for this discussion. Sustenance means 100% of your calories come from hunted game. And sustenance-hunters at that latitude, even with a group, can go a week without seeing any animals.

Scaling up what I've seen people do with white tailed deer, 5 people could probably process 800 pounds of moose in two days if they already had stockpiled all the wood. Groups of 100 could eat it all. And groups that large were common for moving across the land.

<comment><USER15> > _Hunting for sustenance isn 't a solo activity.... You probably need a group > of at least five people_

That's not even close to the truth. I can tell you've never hunted your own large game.

Quite a few of my friends go and get a bull moose solo every year... paddle down a river for a week, shoot it, skin, quarter, load into canoe and keep paddling.

One of them is 65, still doing it :)

I always just go with one friend, moose and bison each time.

> _eat all of the meat before it spoils_

You think 5 people will eat >800lbs of meat before it spoils? Not even close.

Sure, McCandless didn't do a good job smoking it, but he sure as hell tried, and he learned a lot that would have worked better next time. I guarantee you won't meet a single person living in Yukon/Alaska that didn't f-up some aspect of large game hunting when they started out (me included).

McCandless did what all people moving North do - he threw himself in and tried to learn as fast as possible. The main difference is he didn't give himself any margin for error, because that would have made it less interesting/exciting.

<comment><USER17> Please read Hearne's journal. It is probably the best record of what living off of the land in those conditions fully entails.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> pi-rat An article from a Norwegian newspaper about the original incident, with visualisation of their diving profile, timelines, etc: [http://www.vg.no/spesial/2014/dodsdykket/index_eng.php](http://www.vg.no/spesial/2014/dodsdykket/index_eng.php)

<comment><USER19> Great visualisation.

At first I didn't understand what happened, but this article made everything understandable.

</comment></comment><comment><USER20> I'm not a diver so what I'm about to say may sound incredibly naive but I'm surprised they don't use more advanced communication tech when diving than just relying on light signal.

They could use some kind of haptic feedback system working to communicate between each other through RF waves. If one person presses a button, the other members feel a vibration or some similar haptic feedback. This would allow people to signal danger more easily. It would also make sense to have a notification signaling when any member is outside of the RF range.

Having such a tech would have allowed Gronqvist to have directly been alerted when Huotarinen became stuck either by Huotarinen alerting him or by the notification that Huotarinen was outside of the RF range (which would probably not carry very far in that situation). If other members had been alerted faster, Huotarinen would have had less time to start panicking and would maybe not have needed that cylinder of gaz.

So, maybe I'm incredibly naive and there's a good reason but it seems stupid and dangerous to rely on a torch to signal distress (which is often not going to be visible to members in front of the group).

<comment><USER21> As a cave diver (norwegian as well) i can tell you that a good light with a tight spot IS a incredible good way to communicate under water where there is no natural light at all. Lack of seeing your teams light is the first thing you notice. The only thing that could be better than a light is voice communication, but to do that in any meaning full way you will need to have a full face mask (like commercial divers) and that bring with them a lot of other problems. (like gas sharing etc). And Patrik did in-fact notice that Jari had a problem, and stayed 20minutes trying to help him before Jari died. The problem was the "surprise restriction" after point of no return.

So the problem wasn't really a communication problem, but they didn't follow good cave diving practice and thats most likely whats killed them. Normal cave dives starts and ends in the same opening, so you will never be at a point where you cant exit the same entrance as you started. When you do a more complex dive like a traverse as the Finnish did you always make sure you have dived ALL of the cave you want to traverse before! Normally you will do a setup dive from the other side of the system, and place a "cookie" (non directional marker) on the line where you turn. If you reach the cookie from the other side you can, if you up for it, continue to the other entrance. By doing so you ensure that everybody know of hazards like small and tight restrictions and that they dont catch you by surprise when you have passed the point of no return. (when you dont have gas/scrubber time to exit the entrance you started from)

<comment><USER20> Thanks for taking the time to comment. That makes more sense. From the article, it seemed that it took a while for Patrik to notice that Jari had a problem and that this caused Jari to panic with the consequences of him dying.

That's also a good point regarding the point of no return and preparation, the comments from the English divers did hint that preparation had been lacking but the article didn't really explain what could have been done better.

I've always been fascinated by cave diving but I've got asthma and I doubt I could ever do it due to that.

</comment></comment></comment><comment><USER22> One of the pictures is captioned

> The Plurdalen Valley

Which is funny because the -en in Norwegian means 'the' and 'dal' means valley. So in a way it says 'The the Plura valley valley'

<comment><USER23> > 'dal' means valley

[https://en.wikipedia.org/wiki/Dale_(landform)](https://en.wikipedia.org/wiki/Dale_\(landform\))

It's there in English too.

</comment></comment><comment><USER24> This is a good long form article about another cave dive body recovery effort: [http://www.outsideonline.com/1922711/raising- dead](http://www.outsideonline.com/1922711/raising-dead)

<comment><USER25> There's also the very good "Snap Judgement" podcast about that here: [http://snapjudgment.org/where-no-one-should- go](http://snapjudgment.org/where-no-one-should-go)

<comment><USER26> This story also aired on ThisAmericanLife [http://www.thisamericanlife.org/radio- archives/episode/551/g...](http://www.thisamericanlife.org/radio- archives/episode/551/good-guys-2015?act=3)

<comment><USER27> Thank you. I was sure I heard this story before and it was bugging the crap out of me trying to figure out where.

</comment></comment></comment></comment><comment><USER28> Very brave men undoubtedly. I can't think of a sport that I'd enjoy less though.

<comment><USER29> I could relate to a part of it - it's like being on Mars: just you, your mates, and the planet, equally unexplored and unforgiving.

</comment></comment><comment><USER30> vaguely related: the largest successful rescue mission of a scientist who was injured in a cave in Germany [http://www.bbc.co.uk/news/world- europe-27914426](http://www.bbc.co.uk/news/world-europe-27914426)

</comment><comment><USER31> An even more impressive, and tragic, story at over 270 meters depth, in one of the worlds deepest sinkholes:

[http://www.outsideonline.com/1922711/raising- dead](http://www.outsideonline.com/1922711/raising-dead)

<comment><USER32> Thanks, I had this weird sense that I had already read this story before but I thought it had been in Africa? Turns out it was this article.

</comment></comment><comment><USER33> It seems quite egoistic to take such extreme risks for leisure if you have a wife and possibly kids who love you.

<comment><USER6> What about being a soldier? Does it seem egoistic continue being a soldier, if you have a family?

We seem to be Ok, with people, risking their life to protect the interests of the country and thus protect our interests, but not ok if they risk their lives for themselves?

<comment><USER34> Honestly, it _does_ seem sort of egoistic to continue being a soldier if you have a family, at least to me. I'm going to have a hard time explaining it in a way that doesn't seem confrontational, but the most exaggerated example of this is Pat Tillman[1], the professional football player to turned down a $3.6 million NFL contract to enlist in the Army after the Sept. 11 attacks. Two years later, he was killed by friendly fire, making a widow out of the woman he married right before enlisting. Even if you ignore all the absurd, bungled propaganda surrounding his death, he probably did a lot of good in the Army -- but was it as much good as if he'd stayed home and used a couple million dollars to help vets or something?

I very much understand the sense of duty that pulls people toward the military, and I know it's frequently a complicated situation. But I don't think I'll never understand these guys who marry a woman, have a kid or three in between deployments, then just go running back into a war zone.

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

</comment></comment></comment><comment><USER35> > "This incident happened, and then they've made a film and they all come out > as heroes," he says. "But these two people should never have died in the > first place."

What should the divers have done to avoid this? Were they just not experienced enough for a dive of this magnitude? One mentions they should have done a practice run, but what does that mean? How do you practice for a dive?

<comment><USER36> I have no experience diving in caves, I just read about it on the internet, but this stuck out at me:

> But after descending about 85m Kankanen returned. Looking upset, he explains > in the film that he slept badly and is simply not in the right frame of mind > for the operation.

This happened on the retrial mission, but it hints very softly at the culture in which this group of people went cave diving.

I interpret the comment about not having to have died in the first place, as meaning that cave diving is extremely dangerous, and so planning and execution need to be perfect and require a great deal of mental control.

The first person died after he got entangled by some cord, and then after panicking being unable to switch to a fresh air supply. Why the second diver died is unclear. So maybe they weren't in the right frame of mind to deal well enough with running into dangerous problems at depth.

</comment></comment><comment><USER37> For people interested in getting into diving as a sport I recommend reading "Diver Down: Real-World SCUBA Accidents and How to Avoid Them" by "Michael Ange" (just search on Amazon).

It contains numerous case studies of diving screwups that either ended in death or near-death and what can be learned from them to avoid those situations.

</comment><comment><USER38> Is it because of the water pressure that the guy who died couldn't stop ingesting the water?

</comment><comment><USER39> Incredibly brave people. I don't know about the rest of you lads, but I don't have the balls nor the fortitude to even attempt such a feat of humanity. My hats off to them all.

</comment><comment><USER40> The article hints at them having done something wrong and that it could have been prevented. Any divers/cavers know?

</comment><comment><USER41> 99% people do NOT donate their organs posthumously</comment>


Show HN: My redesign of Basecamp's homepage for better conversions. - <AUTHOR> http://imgur.com/I9nVooQ

<comment><AUTHOR> If you're running userscript, here's the code you can use:

        .joy figure img{
            visibility: hidden;
        }

        .joy blockquote{
            display: none;
        }

        .joy figure{
            max-width: 600px;
            height: 630px;
        }

        .joy {
            background: url('https://scontent-b-dfw.xx.fbcdn.net/hphotos-prn2/1394145_10151974119134120_973425284_n.jpg') bottom no-    repeat;
            background-size: auto 100%;
            max-width: 900px !important;
            width: 55% !important;
            left: 2% !important;
        }

</comment><comment><USER2> In an attempt to keep things constructive, I would prefer if their home page tested out other hero shots than what they've had for ages now:

> [https://basecamp.com/](https://basecamp.com/)

At one point, there was even a post about how "real" photos A/B tested better than stock photos.

</comment><comment><USER3> Oh wow, been so long since I've seen the actual homepage I didn't even know Joy was there. You may just want to bookmark [https://launchpad.37signals.com/](https://launchpad.37signals.com/) and you'll never have to see that page again.</comment>


Sticky tape gives off X-Rays - <AUTHOR> http://www.cosmosmagazine.com/news/2268/sticky-tape-gives-x-rays

<comment><USER2> Try at home: Opening some envelopes (or similar) fast produces a blue light.

<comment><USER3> Wow, is that cerenkov radiation?

<comment><USER4> Doubtful. Probably static electricity.

<comment><USER2> Probably. My flatmate was still impressed, when I showed him.

</comment></comment></comment></comment><comment><USER5> This is about a year old, so what has happened in the meantime?

<comment><USER6> The scientists have been trying to get that #¤%& tape off their hands, so they can keep working.

</comment></comment><comment><USER7> Is this dangerous for people using a lot of stick tape?

<comment><USER8> "The pulses last for a billionth of a second, with an intensity of 100 milliwatts."

And this was in a vacuum "to reduce the interference of gas particles".

So I guess not.

<comment><USER7> Thanks. Still I wonder how it was possible to xray a finger using (if I guess correctly form what's written in the article) a single sticky tape without it emitting enough radiations to be dangerous for people unrolling a lot of sticky tape for work, with similar speed of 3 cm/s (this is more or less the "natural" unrolling speed when you are packing something requiring large strips).</comment></comment></comment>


Offer HN: Free ad server - <AUTHOR>

Hi guys,
In the spirit of giving back to the community, I'll like to give away 10 premium licenses to Trafficspaces.
If you need an ad server that you can customize and integrate with your database, and you are serving 1 million ads (or less) a month, send me an email at [niyi] at [trafficspaces] dot com.
More info: http://www.trafficspaces.com <comment><AUTHOR> I think more startups should offer free goodies.

It's the least we can all do for the community :)</comment>


Build your own FPGA - <AUTHOR> http://blog.notdot.net/2012/10/Build-your-own-FPGA <comment><USER2> Superneat project. Now someone needs to synthesize a CPU and build a big enough discrete fpga to run it (very slowly) on.

A few comments for those playing at home: 1) Use less solder. When you get boards done at the pcb house, they usually put a solder mask. There is enough solder on the pads that you can solder SMD parts without adding more.

Just flux it with a fluxpen, lay the part on top, and remelt it. Much neater and much faster. You just have to check that there is actually enough solder on the pad to make a solid joint (a light and a magnifier help to verify).

2) Always clean the flux off, even if it's no-clean.

3) Autorouters produce less than ideal results. If you start with an autorouter pass, you can then go back and tear up lines and reposition parts to use fewer vias and straighter lines.

When I first started doing pcbs I wanted to use autorouters, but the results were always ugly. I met a guy who had done a 6-layer ARM board in some old DOS program manually which convinced me it probably wasn't that big of a deal to route by hand. It's calming if nothing else.

<comment><USER3> I probably overdid the solder a bit, but there's no way most of the pads had enough solder on them for SOICs without my adding any. I've soldered SOICs before, but this is by far the largest volume I've done in a sitting.

As I mentioned briefly in the post, the autorouter was something I used largely as a result of time constraints - with 200-odd wires to route and very little time to do them in if I wanted the PCBs back in time, I decided to give it a go. That said, I was surprised with the quality of the results - I'd be surprised if I can find any easy-to-remove vias left in its solution. The tool is also very good for assisted hand routing, since it lets you nudge traces around without ripping them up every time.

<comment><USER2> I understand; I'm just back-seating anyway.

Where did you get the boards done?

Also, do you have any idea how fast the counter you made can go?

<comment><USER3> I got them done at Hackvana (hackvana.com, or #hackvana on irc.freenode.net); similar prices to Seeed, and excellent customer service.

I'm not sure about the maximum speed. The flipflop, for instance, has a delay of 14ns; if we take that as average, each slice has to go through 5 parts (input mux, LUT, flipflop, async select mux, output enable) for a total delay of 70ns, so in theory one slice could do about 14MHz. Since it's a ripple counter, I guess we should divide that by the number of slices, so 4MHz seems like a reasonable upper bound.

<comment><USER2> It's a really outstanding project. Thanks for sharing it with everyone.

Regarding configuration memory, could you have the arduino read out from a serial flash? They're pretty easy to bit bang or control over SPI, and you can get a 64Mb pretty easily.

<comment><USER3> I'm guessing you're talking about the SRAM-based alternative I discussed at the end? Yes, that would be an option, as would an SD card. 64Mb would be enough for plenty of 256 kilobit slices.

I do prefer the idea of using EEPROM if I was going down that route, though, so it'd be more like a CPLD than an FPGA. I just need a good way to load the only bit of remaining discrete state - the output enables - on startup. My best idea thus far is to dedicate half the EEPROM to configuration data, store the latch states at address 0, and use two RC networks to create rising edges first on a register latch pin then on the highest address pin to latch in the config before enabling the EEPROM in 'operating mode'.

</comment></comment></comment></comment></comment></comment><comment><USER4> This is the first step to true open hardware.

I am concerned how fast IT evolves to DRM-locked devices. The PC will become obsolete by tablets so we will lose control over our computers. Currently DRM looks harmless but when you consider the long-term consequences it doesn't look good at all.

First we fought TCPA and Trusted Computing, now we have the first global players (Apple, Microsoft) put DRM into their gadgets to get maximum control and minimum competition. And the customers buy, consume, and play, without considering the consequences.

Our technology today is the foundation for the political systems of tomorrow, and when you consider the global demographic development you know what I mean. Within the next twenty years we will have a completely different global political and economical system, and I don't want to have them total control over us with their super-safe cascaded DRM chips which nobody will be able to break.

Unfortunately we can't stop Apple, Microsoft & Co. from using DRM. That's why I appreciate pioneer projects like this selfmade FPGA very much as they help to jump over the big hurdle from open source to true open hardware. Someday when all commercial chips will be DRM-locked I hope we will be able to 3D-print our own processors and RAM chips.

I am convinced that Open Hardware will become vital for the survival of our freedom of speech and liberty in general.

<comment><USER5> I agree with your entire comment except for the first sentence. When working for a ideological goal, it is important to continually and earnestly evaluate what goals the imagined solution will actually fulfill, lest one end up misplacing faith in an implementation that can never achieve the desired ends.

First, this FPGA is _still_ not implemented by things that are the lowest level - how do you know that 7404 doesn't actually contain secret logic looking for specific patterns on the 6 "independent" inputs (based on your widely-propagated design) that alter it's behavior?

Second, if one wanted to build an auditable CPU, they would not start by building auditable reconfigurable logic in order to develop a soft core CPU on top of it. This is a needless extra layer of interpretation, and the number one constraint you're trying to overcome is the constant factors that are left out of the Big-Oh notation.

We don't buy Intel processors because we're lazy and have money to burn, but because they contain a billion transistors switching a billion times a second. If you build something with 10k transistors switching at 10M Hz, something that would take 1 second on the modern CPU will take roughly 3 _months_.

So I think there's two properties to be achieved for actual Free Computing. The first is roughly getting something that can compute. These days, this can be done by buying a standard PC and installing your own software on it. This may not continue to be possible (so we would have to eg rely on integrating our own ARM chips, then FPGAs, then microcontrollers, etc), but trying to put a solution forward before it is necessary isn't going to get very far. There also is available computation that is unlikely to go away - Javascript in web browsers, available to all but sandboxed programming toy apps, etc.

Which brings us to the second quality of Free Computing, which is auditability - guaranteeing that the code running is doing what it says, rather than a subtle corruption which renders the whole sensitive algorithm broken. To get performance, we would like it if such a CPU could be made in a necessarily non-trusted fab, rather than independently assembled from discrete transistors. This seems like a harder, but yet better defined problem - meaning it might actually be possible to solve through some combination of clever proofs and bootstrapping trust up from an extremely simple auditable CPU.

<comment><USER4> > I agree with your entire comment except for the first sentence.

I meant the term "first step" historically. It is really the first step to true open hardware because it is the first project (as far as I know) that solely relies on basic electronics you can solder together on your own pcb.

There are many open hardware projects but all of them are based on complex hardware (FPGA kits etc.). There are several good open cores you can download into your fpga but what if someday your fpga stops working and you can't buy another one because these fpgas are not produced anymore?

I agree with you that selfmade processors will never be able to compete with modern processors. But even a 1 MHz 8 bit cpu can do a lot of things. Remember the huge success of Commodore 64. And if you are able to 3d-print one such a cpu you can also print many, and build a multicore system.

Who says that selfmade processors have to work with silicon and copper? If someone finds a way to produce cheap conductive plastic filaments that would be a huge leap forward for printed circuits. I believe that there are several smart hardware hackers who could achieve a solution we could live well with. 3D printing is just in the beginning. I expect amazing times to come.

<comment><USER5> 1\. Plenty of CPUs have been built from discrete logic.

2\. As soon as you start talking about complex printed items (including PCBs), you're necessitating either a trusted computational device to compile the design and drive the printer, or the ability to audit the output of the printer (eg read and understand the traces on a 2-layer PCB).

</comment></comment></comment></comment><comment><USER6> This is what I like about FPGAs and soft-cpus. Some "open-hardware" designs use ARM cpus, that are as closed and patented as they can be (I.E. Arduino, Raspberry PI, etc.)

You may argue that commercial FPGAs are also closed and while it's true, the principle of operation is so simple (lots of interconnected gates) that can be easily replicated, like this cool project shows.

<comment><USER7> > You may argue that commercial FPGAs are also closed and while it's true, the > principle of operation is so simple (lots of interconnected gates) that can > be easily replicated, like this cool project shows.

Basic CPUs are not all that complex either, there are plenty of homebrew CPU projects made of discrete components. Both those and this project share the common trait that they are almost impossible to scale up to be useful.

I would also be very surprised if FPGAs aren't also heavily patented.

</comment></comment><comment><USER8> Nothing to discourage the efforts here but close to 10 companies were closed which tried to enter in FPGA market in last 10 years alone. Here is the list : TierLogic , CSwitch, Ambric, MathStar, Agate Logic, Nusym, AboundLogic (M2000)

Only one successful acquisiton. Lattice acquired --> Silicon Blue

In the past, ST Micro tried 2 times to enter in FPGA Market, once even with the "open Source " concept - GOSPL. Intel for once for sure. Other several companies failed too.

Xilinx and Altera hold close to 90% market share in FPGA market. 90% of other efforts to enter this market have failed earlier. Mostly because, companies underestimated Software importance.

<comment><USER9> Even the lattice acquisition was a small one , the VC's made no profit on it.

<comment><USER8> Exactly !! So i would say FPGA research as an academic project is a good idea but as a viable business has many challenges.

</comment></comment></comment><comment><USER10> Kudos. Just plain awesome and so recursively witty.

</comment><comment><USER11> Hmmm. did he have any indication of cost?

<comment><USER3> Enough parts for 20 boards cost me about 100 pounds; the board fabrication cost about $60, but a lot of that was because I wanted it in a rush. All up, that works out to about 8 pounds, or 13 USD per board. It'd be somewhat cheaper - around $10-$11 - if you're not in a rush for the boards, and of course cheaper again in larger quantities.

<comment><USER11> Yea that's interesting. Would be interesting to see how this scales when you start including more complex components.

For instance a board with a 10GigE connector or putting a clock onto the board itself.</comment></comment></comment>


Ask HN: Developers who became engineering managers, how was the experience? - <AUTHOR> How was the new role challenging? What skill-sets from earlier were important in the transition? <comment><USER2> I've been in software development for more than 20 years. Here are my 2 cents:

\- Training, training, training! Without exception, all the technical managers that I've worked with had arrived where they were at based on technical merits. However, being a manager, especially being a leader have nothing to do with technical knowledge. Therefore _management and leadership training_ is a must. This doesn't necessarily need to be an organized class, but being coached and mentored would be an amazing start.

\- Management and Leadership are different skills. This goes back to my #1. One needs to develop both.

\- Ideally, you become a servant of the team. You're there to help them become highly productive. Your first job is not to solve the technical problems yourself, not to micromanage everyone, not to command and control. You're there to create a self-managing team that can, ironically, work without a manager.

\- You are there to ensure that their motivation and engagement are at a high level. One can be motivated by not engaged. You need to know the differences and the ways to increase them.

\- You need empathy to become a good leader.

\- You need to be a good communicator. And transparency is a great tool.

\- You have to ensure that your team members become good enough to be able to leave your company and find plenty of jobs anywhere else, but also ensure that they wouldn't want to leave.

<comment><USER3> I bet you read "Training, training training" and thought "yeah, but I'm pretty good. I'll skip that bit."

Do not underestimate the differences between being an effective individual contributor and an effective engineering manager.

A lot of the concepts a good manager is driven by are counter-intuitive. For example, technical "leadership" as a manager can be repellant, especially to the more senior of your team, and interpreted as evidence of lack of trust.

The political environment of the company will also dictate your success. Half your job is to be the team coach/servant. The other half is making sure the rest of the company understands that what your team is doing is high-value (and making sure that actually is true).

The OP asked "what skill-sets from earlier were important in the transition." Surprisingly little. One of the team's biggest jobs (which you should try to delegate, by the way), is breaking down a problem into smaller, doable chunks. You'll have done this on smaller scales as a coder, and finding reasonable separations of concern can make or break projects. At the same time, you shouldn't be doing all this work yourself. The more responsibility (not just tasks, but decision-making) you can delegate to your team, the more they will own their work and feel responsible for their own success.

These are very different jobs, but training and spending time in those roles can help you on both sides.

</comment></comment><comment><USER4> I'm in a role as manager/lead dev, so it's kind of mixed. The transition to the managerial part was pretty rough back then and I wished I had gotten more support, many companies don't know how to do that well.

With a developer mindset, what helped me was this (no particular order)

* Go about it as a problem solving task. This can be as complex and fun as building a new system - you are building organization and culture. The way you treat them will mirror in how they treat each other and your customers.

* Don't assume too much what a manager should do or what you have seen, but see your new job as an enabler of other people and find out what the particular needs there are. You're the user interface for other people to get things done in the company.

* The hardest thing is probably to stop solving implementation problems yourself. That's again an enabling position. All the stuff you were the expert in before you now need to transfer to other people. Don't just quickly solve their new problems because you know it better.

* One thing about micromanagement - If there's something that appears to be micromanagement, it's often a problem of too little actual management and not enough. That sounds weird, but the reason is that management interferes with people's work directly, where they actually should have given them the tools and the knowledge to do it themselves. So when you start hearing or sensing that notion, don't stop managing, but try to find out where you really need to help.

<comment><USER5> Good tips. A few more:

* Resist all tasks that you and your team can't figure out next step for. (They're not actionable.)

* Find the maximum task length you're comfortable with doing yourself; try to delegate anything that you expect will take you longer. Keep this number very low (e.g. 15 min or 5 min).

* To balance the latter, find the maximum hours you're comfortable with having someone else do work you'd do in an hour. Keep this number high (e.g. 8 hours or 20 hours), and step in to do things yourself only when delegating will make you over it.

(Edit: Also, there are good lessons learned from the past; don't forget to read books books, like PeopleWare.)

<comment><USER6> Go have a listen to this excellent podcast on delegation [1] from Manager Tools. They hit the same notes you're hitting, but provide some additional actionable tips and tricks for figuring out when things are going well, about to go wrong, or going wrong.

[1] [https://www.manager-tools.com/2005/08/the-art-of- delegation](https://www.manager-tools.com/2005/08/the-art-of-delegation)

<comment><USER7> This is a great episode about their "balls in boxes" model of delegation. If you delegate it's probably worth your while to listen to it. If you are delegated _to_ then it's probably also worth your while!

</comment></comment></comment></comment><comment><USER6> I'm a senior technical staff member on my team. This means that I occasionally get to write code, spend lots of time debugging integration problems, and (as I see it) matching up people and problems that come in to the team. I don't have direct reports, but I provide feedback to managers, am a team member, lead my own team, and lead / mentor team leaders of other teams.

Delegation and Motivation are most difficult by far. I can think of several occasions where I've said or done something the wrong way, causing friction, heartache and strife. I'be gotten better at recognizing different communication styles and matching the message to the recipient however.

Soft skills are key. Go look at Manager Tools[1], a podcast focused on improving the quality of management in the workforce. Every podcast they've ever produced is online, going back to 2005, and covers all of the unspoken stuff like how to communicate effectively, how to have good 1:1's, how to give feedback, how to handle "steel cage death match" meetings, and even how to handle personal scent issues.

They organize the podcasts into a "map of the universe" and also have a "hall of fame."

I'd say start with the map of the universe (it has a "start here" which covers a couple of foundational topics, like I mentioned above. Once you've gotten a feel for it, search around and find something relevant (eg performance reviews might be a good idea given that we're in q4).

[1] [https://www.manager-tools.com/map-of-the-universe](https://www.manager- tools.com/map-of-the-universe)

</comment><comment><USER8> Random thoughts:

* The priorities of developers are _very_ different from those of managers and the greater business. Your goal is to serve the business, but neglecting the needs of your developers has obvious long-term consequences.

* Politics, obviously. I didn't expect to spend my entire working week literally _arguing_ with people.

* Technical skills are still super important. It's not like you give up coding and just manage. You have to be able to do both.

* Buy a Bluetooth headset that you love. I have a Plantronics Voyager Edge. If you're going to spend hours on the phone each day, you might as well be able to type and walk around. (Remember to mute the mic when you flush the toilet.)

* Block out time in your calendar for 'getting work done' \-- focus time. Make yourself unavailable. One employer had single-person meeting rooms, which I loved -- I could be found if necessary, but was a lot less likely to be interrupted.

Being a manager for a while helped me to understand why my managers behaved the way that they did, and helps me now (as an individual contributor) to direct my managers to where I think I need to be.

I love the 'bigger picture' thinking, and I love designing larger systems with others. Negotiating about subsystem boundaries and "whose job is it" is challenging, but useful.

I'm happy to leave the fiddly details to others. This is possibly the hardest thing to adapt to -- if other people are coding on your project, they're going to do things the way that they want to. It won't be the way that you want it, and it'll frustrate everyone if you try to force them into doing it your way. You just have to take that massive leap of faith that everything will be alright.

You can never overcommunicate. Learn to love PowerPoint. Write a lot of emails. Document _everything_ on your company wiki.

<comment><USER9> > You just have to take that massive leap of faith that everything will be > alright.

To let your employees do their jobs is taking a massive leap of faith for you? Looks like you should learn to trust them a little bit more. If they cannot be trusted due to lack of competence, perhaps you should invest in training and a better process.

<comment> volundr- That's not really what he's saying. As a developer, it is up to you to make things go. As a manager, your job is to support engineers and believe that they will make things go.

That is indeed a leap, and a very different mindset.

</comment></comment></comment><comment><USER10> Answer from a different side of the fence:

As an executive who elected senior engineers into engineering managers three time in different companies, there are three challenging areas for even the most fit for the job engineers:

\- understanding that soft skills and understanding company politics now matter not as much, but more than detailed technical skills. focusing on eliminating weaknesses in this area is that pareto-ean 20% of effort that makes the rest 10x easier. \- it's now about eliminating weaknesses, not growing strengths: what you tolerate slows down and makes everything toxic, while what you preach is a second-order problem for a while. it evens out, and later on you can focus on growing strengths, but only after a while. \- you own consistency of engineering culture, not your piece of code and responsibility, now. which makes figuring out internal feeling of "I'm doing it right" twice as hard.

<comment><USER11> I've read first two -points about four times, but still have no idea what these are about (usual thing when talking to completely "other side of fence" minded people). Can I ask for some examples in context?

<comment><USER10> Sorry, English is not my primary language, so the grammar constructions might get odd from time to time, this might have been the cause.

Point 1. Good engineer should know how to code, and how to cooperate with fellow engineers well. This means healthy balance of "hard" (engineering) and "soft" (communication) skills. When engineer becomes tech lead or engineering manager, being able to communicate, understand other people's behavior, lead them, communicate situation up and down the chain,- soft skills start to matter way more. If there are serious skill gaps in soft skills (and all ex- engineers have ones when they start to grow in this area), addressing them is more important for engineering manager's career than addressing lack of up-to- date-ness in latest technology.

Point 1, Example: when I first got to manage a small team, me not understanding power distribution between younger and more experienced engineers (I came from latter category) led to mass extinction of juniors: the way important decisions were made (with more contribution from senior engineers) was good for the company, but the way it was presented (We The Elders Made Crucial Decision) pissed youngsters off, made them feel incapable of making valuable contributions and they quickly left. After understanding the reason (which took hours of mentoring from CTO, a very experienced manager), I had to really work hard on creating the atmosphere where, even when the decisions were made by seniors, the ownership and responsibility for actual implementation of these decisions was distributed among the teams and everybody could contribute to mutual success.

Point 2, with examples already: It kinda continues point 1, but bridges from personal scale to team scale. Process is as good as it's bottleneck. Team is as fast/writes as quality code, as it's weakest members. If you tolerate them, they constrain the process. Your goal is to spot weaker people / weaker engineering decisions and put reasonable amount of effort to either make them better or make them live. As an engineering manager (e.g. manager that comes from engineering, not from fancy MBA factory), you actually can tell the slacker from person who wasn't properly integrated into the process. As an engineering manager, you can tell that the decision to make blocking tests stop CI on the first failure is a poor decision and having a proper failure log of all tests is crucial for speed of bug fixes, not fixing them faster or with better method. Basically you are responsible for the failure (even if you're formally not), because you're the focal point of knowledge and power that can prevent them, put slower people to speed, put processes to full power.

<comment><USER11> Thanks for detailed explanation, it delivered a sense to me and is in great touch with my own leading experience. I even stumbled on point 2, and it took me a month to clearly understand that it's better to let employee go. But before that I made dead sure I'm objective and not elitist (evaluated task- times, insighted into persons thoughts and knowledge, investigated virtually everything I was aware of in situation). That was pretty stressful and happened few weeks right after my assignment, but later I got few hints from team members that it was an obvious thing to do.

</comment></comment></comment></comment><comment><USER12> I didn't like it, and after about a decade I went back to being a developer.

Management may suit you but, as mentioned elsewhere in this thread, even if you're at a 'good' company you'll probably spend a lot of your time neck deep in politics. For me this just wasn't enjoyable or fulfilling, I could do it, my soft skills are ok, but it just wasn't for me. Arguing the toss with Sales or other non-technical people for 40 hours a week was not how I wanted to spend the rest of my working life.

Going back to being a dev was the best thing I ever did, I make the same money as I made in management without the hassle. I still manage dev teams sometimes, but make sure to keep away from the board room. I'm not ruling out ever going back into management but it would have to be a team and an idea I really cared about.

</comment><comment><USER13> As a developer, I found that much of the programming I was doing was not very challenging or interesting. Hooking one API to another, optimizing some database routines, converting data efficiently... It felt more like "building" than "designing". Not sure it counts as pure management, but I've moved more into product design roll that needs to understand the business, what can be done in a given time, and set expectations. It's been far more challenging and interesting to me.

It's not exactly management roll, and it still requires a degree of tech skills, but it's another type of career move option you can make.

<comment><USER14> I think you could generally classify that sort of role as an "Architect," which is usually a senior/lead engineer who works directly with business analysts/PMs to design the product and also "manage up" to set expectations with the business.

</comment></comment><comment><USER15> Ask HN: Just made Director, now what? | [https://news.ycombinator.com/item?id=14937290](https://news.ycombinator.com/item?id=14937290) (Aug 2017, only 38 comments)

Book recommendations:

>gtf21: _Would recommend very highly: (1) Andrew Grove 's "High Output Management"_ (controversial recommendation) [https://amzn.com/dp/B015VACHOK/](https://amzn.com/dp/B015VACHOK/) $13.99 2015;4+stars;153 reviews

>killjoywashere: _I like Lazlo Bock 's book, Work Rules!_ [https://amzn.com/dp/B00MEMMVB8/](https://amzn.com/dp/B00MEMMVB8/) $16.99 2015;4+stars;295 reviews

>helper: _Maybe read "The Manager's Path" by Camille Fournier_. [https://amzn.com/dp/B06XP3GJ7F/](https://amzn.com/dp/B06XP3GJ7F/) $16.19 2017;4+stars;30 reviews

>simonhamp: _I 'd highly recommend reading Radical Candor by Kim Scott._ [https://www.amazon.com/dp/B01KTIEFEE/](https://www.amazon.com/dp/B01KTIEFEE/) $12.99 2017;4+stars;138 reviews

Podcast recomendation:

>gtf21: _Manager Tools "Basics" podcasts, especially on 1x1s and feedback_ [https://www.manager-tools.com/manager-tools-basics](https://www.manager- tools.com/manager-tools-basics)

<comment><USER16> great list of books

</comment></comment><comment><USER17> The new role itself was not challenging, per se, except getting used to approaching unrealistic demands by non-technical people who have a say in the project. (There is a near constant influx of requests that are made without appreciation for the difference between ones that take 60 minutes versus 600 hours, and explaining such things tactfully and in human terms is an important highlight.)

That said, the thing I would personally place emphasis on is not letting yourself fall behind in the development world, both because (1) it's easy to let happen as you get busy, and (2) maintaining a solid understanding of what you're doing is crucial to efficiency in this capacity.

Disclaimer: personal experience derives from contract work

<comment><USER18> I'm working as developer, now since approx 8 years. At my first job I had a boss with Engineering background but he worked a long time in Management as well. So this was quite nice and when he asked me implement things that would take a long time or would be risky to build, I'd tell him and he would prefer me doing other things. At other jobs this changed, I had to talk to more people but doing the programming mostly alone. Although I sometimes got help from other technical people. Ever since on a regular base I'm confronted with this 60 minutes vs 600 hours problem. Just that it's my problem to write these things myself. But I don't really see myself as anything close to Management.

<comment><USER19> Managers are allowed to delegate parts of their job. A good manager will allow engineers with interest and potential to get some experience in this sort of thing. Individual contributors should be able to give feedback to the manager if they aren't equipped or prepared to take care of those sorts of tasks. Similarly, if the manager is missing something (like making a mistake on a ballpark estimate), an individual contributor should feel able to bring this up and be taken seriously.

</comment></comment></comment><comment><USER20> One side note I'll offer: don't view the change as a permanent one. I've bounced back and forth over the 10+ years of my career, and that's been a surprisingly good idea.

As an engineer, I have a better understanding of team dynamics, business needs, and other "big picture" items. As a manager, I don't have to worry as much about "losing my edge" technically -- I'll be back into code 6 months or a few years from now.

Best of both worlds.

</comment><comment><USER21> I'd highly recommend reading The Manager's Path by Camille Fournier. ([http://amzn.com/1491973897](http://amzn.com/1491973897)) It covers the entire career path for a developer from developer to lead to manager to CTO. I found it incredibly insightful as a roadmap for what skills I'd need and challenges I'd face while laddering up. I also found it useful in understanding the challenges that my current manager is facing and how I could help learn to "manage up".

</comment><comment><USER22> Learning to limit scope from both engineers "wouldn't this cool new feature be great" and end users "we want this new feature we never talked about after agreeing on the MVP" has been a learning experience.

Also learning to explain how and why one feature is stupidly simple and another is exceedingly impossible has been an interesting challenge.

Otherwise nothing particularly revelatory, you will hear all of the typical "learning the people skills" stuff from me. Also people complain privately to their managers way more than you would think.

<comment><USER23> What's an MVP? Is that like an SoW?

<comment><USER24> I read MVP as: Minimum Viable Product.

Essentially, the first draft of a product that does what it needs to do to show capabilities to others. Similar to a proof of principle

EDIT: Thanks for the clarification @kweinber, an MVP is put into production whereas a PoC/PoP is not

<comment><USER23> Ah, thank you. Couldn't get past the "Most Valuable Player" association; it is called a Proof of Concept in my industry.

<comment><USER25> An MVP is actually released to production and is not a PoC It was popularized by Eric Ries in his book _The Lean Startup_.

</comment></comment></comment></comment></comment><comment><USER26> The biggest challenge of being a manager compared to a developer is this: Computers do what you tell them to, people do not.

It's definitely a different skill set. Being an engineer is more fun from a day to day perspective. You get to sit down at your desk and build something.

As a manager, you are in the middle of your boss's goals and trying to keep your direct reports happy. Those things don't always align.

You'll need to improve your soft skills. Learn to manage conflict, learn to lead others, and learn to trust your direct reports to do their work without micromanaging. More on that here: [https://www.climbuptheladder.com/how-to-be- a-great-manager/](https://www.climbuptheladder.com/how-to-be-a-great- manager/).

But life as a manager isn't all bad. You get to learn more about the business. I find the most fulfilling part to be helping my direct reports improve their software skills (particularly the new hires from college).

</comment><comment><USER27> Many years ago, one of my mentors was a senior programmer who had gone from programmer to manager back to programmer again.

At the time, I couldn't imagine why anyone would leave the management track-- wasn't that the logical career progression for a programmer? So I asked my friend.

His response: "Because in management, they nip at you from the top and they nip at you from the bottom." Meaning that you have to answer to those above you, and also deal with flak from those below you. It's a constant struggle.

His words (like many other words given to me by others) have proven true.

</comment><comment><USER6> I'm a senior technical staff member on my team. This means that I occasionally get to write code, spend lots of time debugging integration problems, and (as I see it) matching up people and problems that come in to the team. I don't have direct reports, but I provide feedback to managers, am a team member, lead my own team, and lead / mentor team leaders of other teams.

Delegation and Motivation are most difficult by far. I can think of several occasions where I've said or done something the wrong way, causing friction, heartache and strife. I'be gotten better at recognizing different communication styles and matching the message to the recipient however.

Soft skills are key. Go look at Manager Tools[1], a podcast focused on improving the quality of management in the workforce. Every podcast they've ever produced is online, going back to 2005, and covers all of the unspoken stuff like how to communicate effectively, how to have good 1:1's, how to give feedback, how to handle "steel cage death match" meetings, and even how to handle personal scent issues.

They organize the podcasts into a "map of the universe" and also have a "hall of fame."

I'd say start with the map of the universe (it has a "start here" which covers a couple of foundational topics, like I mentioned above. Once you've gotten a feel for it, search around and find something relevant (eg performance reviews might be a good idea given that we're in q4).

[1]

<comment><USER28> Missing link (I assume) [https://www.manager-tools.com/](https://www.manager- tools.com/) :)

<comment><USER6> Yep. :-) of course, I double posted which you can see with the correct link, then couldn't edit the post thanks to turning on the "anti distraction" features in HN. ;)

</comment></comment></comment><comment><USER29> I was pushed into the role due to an acquisition from the position of a technical contributor CTO.

My experience: It's brutally hard and utterly unrewarding. A good manager is evaluated by the performance of their team and the happiness of their team, but most companies do not even _collect_ metrics on team satisfaction other than the mostly discarded of "peer evaluations". This tends to create a toxic environment where abusive managers who exploit their employees rise to the top and equitable and compassionate managers are forced out or given no real opportunity.

I've also never been offered, and in fact have been refused, any engineering management training. I asked, and folks say it's "too expensive." They offer some books (the wrong ones, usually), but I think they (subconsciously or consciously, idk) recognize that performance of the team is a lot more important.

The final thing is even if you do it for awhile and start to get better at it (as has been the case for me), it begins to infect people's expectations of you in the technical world. Everyone assumes you'll start to do it. In some part because you train yourself to adopt a manager's attitude of calm and promote the idea that "yes, this is fixable we don't need to panic."

Once you do it, it will follow you around.

</comment><comment><USER30> I have seen fantastic developers promoted to horrible managers. As others have stated management isn't coding. Leadership isn't management. Understand that it is your job to guide and lead your team not write every line of code or decide that every line written isn't what you would do. You must build trust both up to your management and down to your team. This can be very difficult to juggle as the impedance miss match can tear you apart. be honest and transparent, this doesn't mean be a unfiltered asshole to everyone. Understand not every decision made is binary there are shades of grey. If you find that "politics" is everywhere and you are constantly in an episode of Days of Our Lives then find another job or move back down to development. I personally don't deal with politics or like where everyone has an agenda but I will help solve problems for both my team and for the company and I will help forward ideas I think are good and get behind the decisions made above me and do my best to execute on those decisions.

</comment><comment><USER31> Its very different, few skill sets carry over from engineering, at first it seemed like I wasn't doing anything useful at all.

The challenge is not going back and doing technical work that someone on the team can do because it feels good to 'get something done', and it isn't possible to just edit some code in an engineer reporting to you and recompile them so that they work 20% faster than they did before.

There are a lot of bad managers. You'll hear all sorts of horror stories. But there isn't a book that explains good management, there are 100's of books and they are all different because how management makes sense to a person is unique to that person. When I first started managing I would read books that people recommended. Sometimes there was something useful, sometimes it was opaque. Some assumed you had no understanding of others emotions, others assumed that what others were feeling was as clear to you as if they had an emotional status monitor hanging over their head.

Three things emerged from the mess;

1) There are always two people in a manager/employee relationship and that pair is unique, and the tools need to be appropriate for that pair.

2) People who work for you, are notoriously bad at telling you that you suck. Try to cultivate relationships outside of your group that can give you a different perspective of how things are going.

3) At the end of the day respect, responsibility, and a clear understanding of what is expected is the most effective way to keep people happy and productive.

So to summarize, yes the new role was challenging and what was more, frustrating, in part because the tools I had learned for developing new engineering skills were not applicable. It isn't a job for everyone, this is for sure.

</comment><comment><USER32> Communication. Both up the ladder and down. Up the ladder, you have to be able to sell yourself, your ideas, and your team to other leaders within the organization. Down the ladder, you need to manage the expectations of your direct reports, keep them happy, challenged, and moving forward in their own careers.

Delegation. As a project manager, I was able to spend a fair amount of time keeping up on tech skills, coding, etc. As soon as I took on personnel responsibilities (as a software development manager), I've found very little time to write code. Some, here and there, but it tends to be in short spurts between meetings or other tasks. I had to learn to trust my team to make good decisions. And also learn how to spot when they are about to make a bad one (and intervene without killing morale, efficiency, etc).

Management is much more of a balancing act. As a developer, you really have one goal - write quality software. As a manager, you have two - fulfill the needs of the executive team while also fulfilling the needs of your team.

</comment><comment><USER33> I have about 9 months of experience as an engineering manager after a little under 4 years of experience as a developer. I found it a mostly straightforward transition, but perhaps I had a background that prepared me better than a lot of people have.

Good leadership is paramount I found - it makes the difference between a team that is focused on executing and one that is mired in other issues. As a Marine, I strongly believe in the Marine Corps leadership principles [1] and applied them with great success in improving the work experience for the engineers I was managing in a dysfunctional environment - I have been told that I was the best manager some of these people had as a result, one engineer with over 20 years of experience in the industry.

Anything you are not able to accomplish to make people's lives better at work makes their lives harder, so you must use that as motivation to do the best you can to give them the tools and environment to succeed.

Trust in your engineers to make the right decision & the judgment of the team as a collective - your job is not to handle the technical stuff in general.

Keep eyes and ears open for stuff coming down the pipeline and its effect on the team (people might be interested in certain projects, or it might even affect technical design sometimes).

Keep listening for the things each team member may need/want. Actively probe, and take action wherever possible to help accomplish it.

The list of things that one may want to know is endless. An ability to learn & adapt is very important for a good manager. Seek advice from above and below constantly.

[1] [http://www.au.af.mil/au/awc/awcgate/usmc/leadership.htm](http://www.au.af.mil/au/awc/awcgate/usmc/leadership.htm)

</comment><comment><USER34> Depends on the company but here's what I have been through:

* Good dev team doesn't need "managing" but instead you become some kind of BS umbrella to protect them from arbitrary disruptions.

* Don't expect every developer to be as communicative as you expect. They may be unhappy but may not let you know directly. 1 on 1s are really important.

* Much less coding. Less than I am comfortable with.

</comment><comment><USER35> The first time I was promoted to a a manager position I had no idea what this means and nobody told me. Mistakes I made:

\- Didn't take charge of hiring. My VP pushed people on me I didn't trust. Also had to deal with an offshore team that didn't deliver. Should have said "No" both times.

\- Didn't have the final say on raises and promotions. Should have taken charge

\- Stayed involved too much in coding. Should have let go

\- Didn't get rid of people who didn't fit with the team. Should have made tough decisions

\- Had to follow a process that didn't work and caused a lot of overhead. Should have refused

Things I did right:

\- Brought things to quick decisions to reduce uncertainty for devs.

\- Let people be autonomous and make decisions for themselves

In short, when you are manager, take charge and take responsibility! You are the boss now, so lead, don't just transmit orders from higher up.

<comment><USER36> A pushed "offshore team that didn't deliver". I really don't know when to pull the plug here myself...

</comment></comment><comment><USER37> I asked a similar question some time ago: [https://news.ycombinator.com/item?id=13284742](https://news.ycombinator.com/item?id=13284742) not about the experience, but more about what to keep in mind when switching. Hope it helps.

<comment><AUTHOR> The role of project management is very different from that of engineering management. For e.g., the former doesn't have any people management, whereas the latter does.

<comment><USER38> That's not exactly true. A project manager in some ways has a more difficult people management job than an engineering manager does. They're held accountable for the coordination and performance of people over whom they hold no actual authority. That takes some major diplomatic skills.

</comment></comment></comment><comment><USER39> I made this jump from researcher to network engineering to applications and systems management to tech group management. I sucked at people and project and process management and I was very lucky to escape back to research and technical communication. Tech management required skills I lack and now, I report to a professional technical manager who is wonderful, a kind, humane and also appropriately critical man. What I sucked at most was giving negative feedback. That and time management. Good managers manage expectations upward and downward, keep blame, share recognition and do not excuse failure but reward admitting mistakes. Don't ever be tempted to lie, and don't shaft people. Don't keep dud hires unless you can find the role they don't suck at. Don't allow bullies to triumph.

Tech management should be more like an anarchist collective of mutuality but I tried, and it doesn't work well in a hierarchical reward structured environment.

Tech management can be learnt but I now understand not everyone can apply it, and you need to be open to the possibility it's not for you. On one management course I was told that if you find yourself in conflict with the goals you're being asked to deliver you may be getting a signal to move. As a wage slave with no reports it's possible to compromise on this but in a leadership role, its untenable to command outcomes you cannot adhere to. Don't do it.

</comment><comment><USER40> Honestly it is a pretty thankless role and unless you are being paid very well to do it I'd recommend avoiding. Jump to being the business owner instead.

Edit: ok, perhaps it is ok in a situation where you are "earning your chops" as part of a plan for future world domination. Also in specific circumstances and the right company it could be a fulfilling challenge.

</comment><comment><USER41> I found the daily interactions and increased participation in strategy to be great... BUT I never felt productive. As a dev, it was easy to know when I was productive. I could FEEL productive. As a manager? Not so much. There was nothing tangible. Just meetings and documents, and comments from direct reports. After 2.5 years, I just went back to development.

</comment><comment><USER42> Can't stress training enough. If your company offers training take advantage of it. If it does not you have to consider if they take your success as a manager seriously, and if you are willing to invest a lot of your own time and energy into bettering yourself while being responsible for other people. I had a bit of training but also was fortunate to have worked for great managers I considered my mentors and found that to be an invaluable resource to fall back on.

It isn't clear exactly what your role entails, but in my opinion it is pretty much impossible to be a great manager and continue in a role as a technical contributor. To me that's more a technical lead than a manager, so if you still like writing code you need to think about that long and hard. Your #1 responsibility is the success of your team and they need to know you are there for them 100%, and not busy buried in code. There are times when you may be able to get your hands dirty but you can be nowhere near the critical path of the project.

You also have to remember you are not only managing your direct reports but who you report to and whomever is relying on your team. In my case, I reported to a VP but I also had to work laterally with other development managers, and in particular project managers that weren't always technical. Just like as an individual contributor you need to maintain a healthy relationship with those you work with directly because you need to balance what they need and want from your team with what your team needs and wants.

That being said, I lasted in management for a little over a year, mostly because the role evolved and due to some changes at the top where I didn't feel I was enabled to be an effective manager. Still, I found the experience invaluable as it gave me more insight into how to better work with people of all stripes. Like any role, technical or otherwise, you have to constantly evaluate what you are getting out of it, if you enjoy it, and if you want to continue bettering yourself in the craft.

</comment><comment><USER43> I made the transition after 12 years as a developer.

One of the issues I had was mistakenly assuming all the people working with me would be easy to get along with and hard working, which was how I behaved and is a factor in my becoming a manager.

It's not that way at all. You see the 80/20 rule play out, where you have a few A+ players who do most everything, a few people who do decent work, and then a handful of duds. Attitude-wise, the harder people work, the more pleasant they tend to be. The duds can be indifferent towards you or even hostile.

Being a developer and being used to controlling my work product, I had to make a shift to trusting other people blindly and that wasn't easy for me. Over time, I realized it was the most effective way to get people to do their best work though - trust that they'll give good results until they repeatedly prove otherwise.

</comment><comment><USER44> I've made the mistake of being a "tech lead". The term usually means some who plays a sort of CTO role but is also a key programmer. It's really tempting because you get a star player salary, but also make full use of your technical skills.

A programmer needs a lot of deep, focused work to do their job, whereas a manager needs to be available.

Managers are the spine and nervous system of a company. They need to transfer information from one part to another quickly. They need to communicate a lot, make decisions quickly. They train newbies, manage project progress, deal with issues.

A manager who wants to do technical work should probably limit himself to more shallow tasks like bug triaging or maybe setting up a checklist of things for the other programmers to do.

</comment><comment><USER45> These are all the minimum requirements for an engineering manager. If I hire a new software engineer I'd excpect to see someone capable of building awesome products. Same for a manager, being good at managing a dev team is for me the minimum requirement. If I were to push the boundaries further, I'd say that you have to be likable, friendly, inspiring, extremely adaptable to different personalities and totally transparent. Be straightforward whenever you can, cut the BS when it comes to career growth. Put yourself at risk and become friends with all your direct reports. The further you stand the harder it is to maintain a healthy relationship. Get your hands dirty. That's how you seperate an awesome eng manager from the pack.

</comment><comment><USER46> F*cking awful. I'm a great engineer. I'm not a good manager. There is a big difference, and most of the other replies have done a great job laying out the differences. All I want to do is sit in my corner and build stuff.

/end cathartic outburst

</comment><comment><USER47> I always felt my only chance to stay relevant in the IT industry is to move to a more managerial position because there are so many smarter developers than me, especially the sort that codes in their free time or has a formal education in CS. Essentially I felt that almost everyone is smarter than me. After being a self-thought developer for 15 years I made a transition to Product and I boost the title of Senior Technical Product Manager. Here are some of my thoughts:

\- The variety of companies and cultures is way more heterogeneous than I ever thought. I worked as a dev for mediocre companies where I was one of the weakest in the team and I worked as a PM for NASDAQ companies where I was a probably better developer than the average.

\- As a developer I was often frustrated by the inefficiencies in the system that I could not change. AS a manager I am often frustrated by the inefficiencies in the system that I can not change.

\- You can learn social skills same as you can learn swimming or dancing. Regardless of how much of a neckbeard you are, if you commit to it, you can learn to be a people person. Use your analytical skills as an advantage to filter out bullshit and follow evidence-based advice. Giving a compliment works 99% of the time.

\- The recruitment process for managers is a sham. You must know to recite all the hippest theories but in the actual job you will often fight to fix the most obvious inefficiencies.

\- I have less stress and higher salary as a manager. This may not apply universally, but as a manager I will never cause production outage or P0 defect.

\- My technical background is a huge advantage, still, there are managers with much better people skills, negotiation skills, business intuition etc. Many others just hide behind buzzwords and fake smiles. Listen and learn.

\- Manager or not, I highly recommend this gem of condensed, practical advice: [https://www.amazon.co.uk/Mobile-MBA-Skills-Further- Faster/dp...](https://www.amazon.co.uk/Mobile-MBA-Skills-Further- Faster/dp/0273750216) (based on the success of the book Jo Owen diluted the same content in much longer book The Death of Modern Management)

</comment><comment><USER48> I'm editing the blog [http://cto.pizza](http://cto.pizza) that relates challenges of CTOs, VPs, engineering directors... you might get some insights on what it is like on the blog

</comment><comment><USER49> Agreed. I found that books were good for learning the language and theory of management, but the important stuff -- interacting with, influencing and negotiating with people -- that only comes from practice and reflection.

</comment><comment><USER50> Managing requirements vs Managing expectations need different set of skills

</comment><comment><USER51> I was a Sr. Developer. My boss refused to relocate, and I was offered the job. We have the following leadership roles on a team: Scrum Master, Technical Lead, Product Owner and HR Manager. Originally I was Technical Lead and HR Manager. Later I was TL, PO and HR.

I gave up TL to someone but retained PO. I was just too busy to do all three and decided that Power of the Pen trumped Power of the Code Review, though I still do CRs.

It's hard to let go of the technical leadership, not just for me, but also for everyone else who is used to coming to me.

The people management role is the least rewarding and the most challenging. Hiring can be rewarding, but unless you work somewhere where you're always hiring, you quickly hire some decent or great folks, and then you're done with that. Like really done -- letting people go can take a long time in a big company.

I still write code, but it tends to be emergency fixes or prototypes, not the type of code that requires days on end of focus, because it is impossible to be left alone for any length of time, and not have to do a million simple but important tasks.

Being somebody's boss typically carries a lot of weight, as long as you have their respect, and I find it challenging not to suck the technical oxygen out of our team by doing the research while writing the requirements and taking that fun phase away from developers, thereby limiting their satisfaction and growth. I mean, a good developer will still do their own research even if you hand them something on a silver platter.

Also, you have to learn how each team member works and communicates. Some people are very focused on dry facts, and others on feelings. If you don't speak their language, you'll never be on the same page with them and your relationship will be constantly frustrated.

Some people work fast, and others more slowly. When people seem to be working slowly, you need to consider why. Are they on the wrong path? Did you not give them all the info they need, and they're hesitant to admit they don't understand. Maybe they just the real thorough type? Find a way to get people into their zone quicker, and leverage their individual strengths.

Finally, there is the whole issue of what role do you play. You may have been friend/peer to people who now report to you. If you notice they are slacking off, it's a bit more challenging to get them back on track, but not that hard. Just ask for a detailed status update, take a few notes, and then do it again a few days later, and compare what they've done, or schedule a demo.

Larger or less flat organizations will have a dedicated people manager for 1-3 teams, and their full time job is to manage people, foster moral, etc. That may be rewarding for some folks, but I tend to think the majority of engineering types would hate it.</comment>


Show HN: Study, research and learn with thinking notebook – MindForger 1.50.0 - <AUTHOR> https://github.com/dvorka/mindforger/releases/tag/1.50.0 <comment><USER2> This looks very interesting. Somehow didn't know about Mindforger, even though I read a lot about this subject.

Recently published a blog post about my own knowledge management practices as a software engineer: [https://tkainrad.dev/posts/managing-my-personal- knowledge-ba...](https://tkainrad.dev/posts/managing-my-personal-knowledge- base/)

</comment><comment><USER3> This looks a lot like something I have been imagining in my head (and tinkering with building on and off for a while). Thank you, I will for sure try this.

One thing that stands out to me though is the lack of mobile support. I want my note-taking app to also handle my shopping lists, and then I need to be able to access them while in the grocery store on my mobile.

Yes, having my grocery shopping list in a note-taking app is overkill - it's just that I want all my lists and notes in one place.

<comment><USER4> Just to add-on, note taking app to track expenditure as well, certain notes can be shared and updated by other people.

</comment></comment><comment> VvR-Ox The new release looks awesome and I will give it a try. Thank you for the great work!

I am still missing one thing: A live markdown editor (real time preview) like in Mark Text[0] and Typora[1].

Of course MindForger contains much more really useful features to connect thoughts and stay organized but somehow I prefer the writing experience with real time preview (it is also less intimidating for users who don't know markdown which is very likely if they don't work in IT).

I don't say this has to be the de facto default but I would appreciate a "live-mode" you can toggle.

[0]: [https://github.com/marktext/marktext](https://github.com/marktext/marktext) [1]: [https://www.typora.io/](https://www.typora.io/)

</comment><comment><USER5> Looks very promising. What would be the advantages if switching from org mode?

<comment><USER6> I bet org mode has a more developed eco system but I could think of these advantages:

\- possibly performant "single file" workflow

\- markdown

\- no need to learn emacs

</comment></comment><comment><USER7> Nice to see an open-source alternative to ConnectedText [1], though, it looks pretty unstable for 1.50.0 release (constantly crashes on switching views, graph navigator is lagging even with 3 nodes, no control over the window's layout and sizing).

[1]: [http://www.connectedtext.com/](http://www.connectedtext.com/)

</comment><comment><USER8> Thank you, dvorka! I recall having come across your website, and MindForger a few weeks ago when I was looking for lite Markdown editors. Thank you for posting. I am going to try it soon.

</comment><comment><USER9> The idea looks interesting, but I don't feel like the examples show a strong enough improvement over just using multiple windows and some pdfs and a notebook.

</comment><comment><USER10> Is it possible to sync notes to mobile and quickly make small changes? Simple Note is the best at this. Currently I am using inkdrop which is a little slower to load due to the web view refresh of react native.

</comment><comment><USER11> Looks interessting and horrible. UI and UX seems to need much more love till it becomes friendly.

There is no navigation-history?

</comment><comment><USER12> That screenshot looks like it was designed by me, except I would have used a different color scheme, or given you a color scheme switcher dropdown somewhere.

This is unfortunately not a compliment. I suppose it's great, but something designed by me will always be borderline unusable.</comment>


SocialDevCampChicago this Saturday - <AUTHOR> http://barcamp.pbwiki.com/SocialDevCampChicago

<comment><AUTHOR> Free unconference with (supposedly) free beer afterwards. It's a bit more focused than the BarCamp Chicago that's on August 15, with a focus on social networks and communities. You can sign up just by adding your name to the wiki - it _would_ be nice if you did it in alpha order, rather than just at the end as some people did ( _cough_ ColonelTribune _cough_ ).

(Disclosure: Dawdle.com is a sponsor)</comment>


Humai – Human Resurrection Through Artificial Intelligence - <AUTHOR> http://humaitech.com/ <comment><USER2> This seems to be describing measuring "conversational styles" as part of the means to get the information to "revive" the person.

This makes about as much sense as the old idea that a video of someone speaking would be like immortality, in that it would let someone speak from after their death.

How someone speaks is an external thing, just as is how they look.

There are thoughts that I've had that I have never voiced to any other human, and which I remember. These are not recorded in any media of man's making. And I am thinking of at least one specific example as I say this. (note to hypothetical future attempted reconstruction of myself: if you don't remember, it probably didn't work, and you probably aren't me in any meaningful way (unless I deliberately forgot it I guess). here's a hint though: "how I experienced myself")

Getting information about my conversational styles does not contribute significantly to the task of getting enough information to determine exactly how I internally experience myself.

The page then goes on to say that it would get information from the deceased brain, and then like, fix it, using the other information gathered, and put it in a robot?

This is entirely implausible. The idea that getting information from how I've spoken will help to reconstruct my brain, no, that's absurd.

While not /absolutely no/ information, the information about my speech patterns gives, I would think, /basically no/ information about my being, relative to the amount needed to reconstruct a state of my brain. To suggest that this would help in reconstructing my brain seems to suggest that somehow, that was one of the few areas of information needed to reconstruct my brain to a working state. This is so bizarrely specific. I don't see this information could be missing that could not be recovered from what was there, yet which this information would be enough to recover things to working order.

Now, of course, I don't have any great understanding of how the brain works, so this is largely by intuition.

But I suspect that this company is largely an attempt to get funding, and does not have any real means to achieve the ends they propose.

And on their twitter account, they talk about death no longer being inevitable.

I've written before on how the belief that being uploaded onto a machine would somehow prevent mortality is misguided. For any bounded size of a machine, if there is an injective function from one's experiences to the states of the machine, the totality of all one's experiences must be finite, because the number of states of the machine is also finite by the bekenstein bound. One dies.

Any hope for eternal life must be from outside of ourselves.</comment>


Palm Pre is shipping GPL incompliant - <AUTHOR> http://laforge.gnumonks.org/weblog/2009/06/11/#20090611-palm_pre-gpl_incompliance

<comment><USER2> Palm is _only_ waiting two weeks, so it seems a little excessive to worry just yet (especially since finishing anything in 2 weeks seems incredibly efficient by some corporate standards). But it is okay to ask the question, and remind them in public of their obligations.

Keep in mind that the "preparation" they're doing could be as simple as scrubbing everything to make sure they don't accidentally release anything proprietary. For example, even for open-source packages, it's conceivable that they have developed some of their own internal tests that use proprietary data, and so their internal copy of the packages would contain more than they intend to release to the public.

<comment><USER3> Imagine what would happen if they said they still need a couple weeks to scrub everything before they would be applying for FCC approval. This is just another obligation that comes with the legal landscape they've settled into, and they shouldn't have shipped without already meeting it.

<comment><USER4> Bit different. The GPL doesn't require that the source code be _immediately_ available. And if they had just said "sure, we'll go ahead and send that out, it will take a month to process and then however long mail takes", well... there's absolutely no GPL violation there.

</comment></comment></comment><comment><USER4> ... No, not so much. They are abiding by at least the letter of the GPL, as long as they _do_ send the code at some point. The GPL doesn't specify that they have to ship you the source code _immediately_ , just that they have to ship you the source code.

<comment><USER5> And now someone will have to do TCP/IP over smoke. Look what you've done.

</comment></comment><comment><USER6> "This sounds suspiciously like "we didn't think about it early enough and now we need to reproduce the soruce code that was used for actually compiling the build that is installed on the devices"."

You have _no idea_ how much time and effort goes into tracking these licenses and associated code.

</comment><comment><USER7> "For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights."

straight from GPLv3. So Palm doesn't exactly follow the license does it?

<comment><USER8> That's not part of the license conditions. You are quoting the preamble which has almost zero legal importance.</comment></comment>


Nim's author on v1 launch: Personal words about version 1 - <AUTHOR> https://nim-lang.org/araq/v1.html <comment><USER2> Interesting last sentence in the context of shipping a programming language: "It's like a marriage, it doesn't stop with the wedding."

<comment><USER3> The more I view things, the more I feel marriage probably is the best metaphor for any nontrivial undertaking that is worth a lifelong investment, for a group of people.

Think about it, marriage requires:

* Love

* Dedication

* Persistence

* Endurance

* Mutual respect

Pretty much the same thing for any highly functioning team!

</comment></comment><comment><USER4> Any chance NIM will get memory safety like Rust?

<comment><USER5> Does everything have to be about Rust?

<comment><USER6> There's nothing inherently wrong with wanting a language to ape a solid aspect of another nature. For all you know (chain) OP _wants_ to write Nim but needs memory safety.

</comment></comment></comment><comment><USER7> Recent: [https://news.ycombinator.com/item?id=21053140](https://news.ycombinator.com/item?id=21053140)

</comment><comment><USER8> Blog post has no link: [https://nim-lang.org/](https://nim-lang.org/)

</comment><comment><USER9> Nim is not so simple language. A cheatsheet could be nice.

<comment><USER10> [https://learnxinyminutes.com/docs/nim/](https://learnxinyminutes.com/docs/nim/) ?

<comment><USER11> Thanks. Some of the syntax seems rather arbitrary, but maybe just to my layman eyes...

        var
          child: tuple[name: string, age: int]

but

        type
          Color = enum cRed, cBlue, cGreen

why not

        type
          Color = enum[cRed, cBlue, cGreen]

<comment><USER12> Because a type declaration is declaring multiple identifiers. Each of the enum variants is a legal name.

The tuple declaration is declaring one identifier with multiple fields. The names of the field are only legal as, well, fields of the outer object.</comment></comment></comment></comment>


U.S. math team finishes 4th behind Korea, China, Vietnam - <AUTHOR> https://www.upi.com/Top_News/US/2017/07/25/US-math-team-finishes-4th-behind-Korea-China-Vietnam-in-intl-competition/1791500960942/ <comment><USER2> If you go to see the full results: [http://www.imo- official.org/results.aspx](http://www.imo-official.org/results.aspx) , you can see that asian country have a lot of good results. Do you know what the cause is?

<comment><USER3> Probably for the complexity and irregularity of the number system their languages use.

[http://www.sf.airnet.ne.jp/ts/language/number.html](http://www.sf.airnet.ne.jp/ts/language/number.html)

Asian language tend to use almost regular base of 10 number systems.

Other languages, like English, has historical debt on the language system.

French is especially bad.

<comment><USER2> There is a study that shows that European languages can make number acquisition and arithmetic more difficult and I noticed that sometime it's easier for my daughter (5 year old) to do addition and subtraction in Khmer than in French.

But I don't see how it would cause a problem long term for the best student. I believe that STEM is still esteemed in Asia and less so in Europe.</comment></comment></comment>