Leadership:

- Turn The Ship Around (Marquet) - make everyone a leader - The Effective Engineer (Lau) - leadership for engineers - Leadership, Strategy, and Tactics (Jocko) - leadership in military/business - Good To Great (Collins) - good companies vs great ones

How to get better at everything:

- Mindset (Dwek) - growth vs fixed mindset - Atomic Habits (Clear) - automate good decisions w/habits - Change Your Habits, Change your life (Corley) - data driven selection of which habits matter - Ultralearning (Young) - how to learn anything faster - Anything You Want (Sivers)

How to talk to humans

- Difficult Conversations (Stone) - how to talk to humans - Never Split the Difference (Voss) - every conversation is a negotiation - Death By Meeting (Lencioni) - short fable - anything else by Patrick Lencioni

Prioritization and focus:

- The One Thing (Keller) - prioritization - Deep Work (Calport) - focus - Indistractable (Li) - focus

See also anything by: Jason Friedman, Jim Collins, Patrick Lencioni, Peter Drucker and biographies in general

Thanks! Thats exactly what I was aiming for. I'm glad that came across. I was thinking the same thing although I didn't actually discover https://learnxinyminutes.com/docs/perl/ until after I had written Minimum Viable Perl.

You rock.

You have high fidelity repls for python and ruby. The Perl hi fi repl is called Reply (https://metacpan.org/pod/Reply). If you are interested check out the plugins -- especially for Term::ReadLine::Gnu. If you have questions, let me know.

Most languages probably don't have the ability to download dependencies from the internet on the fly. That might be a nice feature to have.

Great response. I'll pile on:

Many people retire at 50 or 60 and don't die until 80 or 90 these days. Thats 20 - 30 years of living often while dealing with very high medical bills and health problems which can make work impossible. Everyone (not just programmers) should realize that their retirement situation is similar to professional athletes.

Programming is a hot field now and won't be in 20 years. Everyone in every country in the world is learning to program. Thanks to the internet its going to be a global employment market. Competition is going to go up. Salaries are going to go down.

Movies and popular culture say you have to enjoy your youth. I can sympathize with that, but as much as it sucks to work hard during your twenties, it would suck a lot more to work hard during your 60s or 70s when you are less healthy. Don't procrastinate.

If you save 60% of your salary you can retire in 13 years. If you save 80% of your salary you can retire in 6 years.

I built a tool that does this math for you: http://networthify.com/calculator/earlyretirement

I struggle with this all the time. Data driven tests are awesome because you write so little code. But the code is often abstract and the data is long and hard to read.

I have never been a big fan of Cucumber either and I'm not convinced its more readable -- isn't it just more verbose? Interesting point about it being language agnostic though.

I guess I don't have a better solution to contribute. Just wanted to say yeah I have that problem too.

I also see Cucumber as a way of gluing specifications with implementation allowing you to regression test specifications.

You can end up with a very domain specific testing "language" (DSTL?) enabling developers and domain experts to start describing a lot of different behavior (specifications) to see if the current implementation supports the behavior.

If current implementation does not support the behavior, then you now have a specification to implement the behavior.

Thanks! I have never heard of these. Here is the complete list of Amazon's leadership principles: http://www.amazon.com/Values-Careers-Homepage/b?ie=UTF8&node...

If you are interested in more of this type of writing you might try Dalio's Principles: http://blog.kablamo.org/2013/12/15/dalios-principles/

Excellent app! This is the writing style my high school composition teacher drilled into my head. Everything I write now is influenced by her.

I also try to write my code using this style. In fact, code and documentation and email should be:

1. As short as possible: Less words mean less stuff to maintain and comprehend.

2. Simple: The goal in business is to communicate well. Not to impress. And if I haven't communicated clearly, maintaining that code is going to be hard for the next person who has to read it.

The slowest processor in the room is the wetware between our ears. Shorter, simpler code is easier to write, read, understand, communicate, remember. Halve the code, get a 32X improvement!

Hyperloop technical specs here (pdf): http://www.spacex.com/sites/spacex/files/hyperloop_alpha.pdf

HN navel gazing aside -- I think this is really good advice. Rather than trying to impress your coworkers -- try to impress your users.

I think the challenge in many companies is getting enough access to your users that you can tell if they are impressed or not.

I'm going to try to think this way more.