mightybyte

> Often the "performance critical parts" are actually 60-80% of your code.

That has not been my experience at all. But I suppose it depends on what kind of programs you're writing.

Go out right now and get the book "Crucial Conversations". It is BY FAR the best book I've ever read on this kind of thing. It is simultaneously the best relationship book I've ever read and the best business book I've ever read. It goes through the basic principles for handling these situations in an easy to understand way.

I have not found this to be the case with Spacemacs. Almost everything you need is bound to keystrokes using space as the leader key in the spirit of vim. As a long-time and fairly advanced vim user I recommend Spacemacs highly.

I think for many people who have had that level of success, the idea of "just retiring" is not very appealing. They have gotten to where they are because they have a strong drive to accomplish things that doesn't go away. If they just stopped everything and took a vacation, sooner or later they'll probably find themselves bored and want to dive back into a significant project again.

Yep, I've never done it, but I've definitely been aware of how easy it can happen. When I'm in this kind of situation on a production DB without easily restorable backups I usually try to remember to put all my delete/update queries in a transaction. Then commit after I see the appropriate number of rows have been effected.

I don't remember it being presented that way at all. If it really is a core technique, I would expect it to have been emphasized strongly and the test to have a problem with a different expansion instead of the exact same 2 -> 1/2 + 3/2 problem that he had done in class.

I couldn't agree with the last point more.

> A course taught as a bag of tricks is devoid of educational value. One year later, the students will forget the tricks, most of which are useless anyway. The bag of tricks mentality is, in my opinion, a defeatist mentality...In an elementary course in differential equations, students should learn a few basic concepts that they will remember for the rest of their lives...

I hated the DE cleass I took in college and it was largely because I felt like it was nothing but a bag of tricks. I very distinctly remember one problem that seemed unsolvable until the teacher showed that you had to substitute a "2" with "1/2 + 3/2". And then, to make matters worse, he put the exact same problem on the test. So we were being rewarded, not for really understanding the core basic concepts, but for memorizing the tricks needed to solve specific problems.

None of the hackathons that I've gone to seemed to have any of these problems. Hac Phi [1] in Philly and Hac Bos [2] in Boston are both fantastic and have been tremendously valuable to my career. Last year Hac Phi started to distance themselves from the more recent connotations of the word "hackathon" and started using the word "exchange" instead. This switch makes me a little sad because I think the portmanteau of "hack" and "marathon" is still very relevant to those events.

[1] https://wiki.haskell.org/Hac_%CF%86

[2] (http://www.meetup.com/Boston-Haskell/events/223607923/)

I don't care about fast nearly as much as I care about it not having ridiculous hoops I have to jump through to get connected. I just want to connect to the network and be on without having to first have my requests intercepted by their system until I register or click "connect". I suppose maybe this falls under "well executed implementation", but I think it deserves to be mentioned specifically.

I've noticed a similar thing about myself when I'm making plans with friends. They'll say, "Are you coming to XYZ event tomorrow?" I've noticed that I very rarely answer with "Yes" or a common equivalent even when I fully intend to go. In the back of my mind I'm thinking, "How could I possibly know whether I will be there tomorrow." I could die, be involved in an accident, or my transportation could be severely delayed. I usually respond with something like "Probably" or "I'll definitely try to make it". It doesn't have the dramatic impact that this story did, but it echoes the same way of thinking.

I used Telegram for awhile, but then suddenly started having problems with the iPhone app. I can't remember what happened, message notifications didn't appear, or maybe the app crashed, or something like that. Essentially it became unusable, so I switched to Signal.

I consider myself a little bit of an anti-mustachian. But I'm sure the majority of Americans would probably consider me quite mustachian. I spend significantly less than 10% of my gross income on housing. I almost never take a cab when I could take the subway. I save enough so that for all practical purposes I never have to worry about money. But at the same time I spend substantially more than the mustachian 24k / year. I don't particularly enjoy cooking, so MMM would consider my food expenditures to be grossly high.

My view is that people should live in a way that maximizes their happiness. MMM seems to enjoy taking frugality to the extreme. But I'm different. That lifestyle would not make me happy at all. In the past I have lived with very little left over for savings. That way of living also caused a lot of stress any time unexpected expenses pop up. It absolutely did not maximize my happiness. I'm fairly careful with my money naturally, so my current mode of living doesn't require any effort on my part. It leaves me free to make what many would consider pretty large splurges from time to time while still maintaining a nice cushion for unexpected expenses as well as a nicely increasing investment portfolio that should allow me to retire well before the standard retirement age.

So no, while you might not be able to say I have fully unabated spending habits, MMM might say that I do. And in that case I would satisfy all three of your points.

This is especially sad because the NYC Mesh project (https://nycmesh.net/) to create a mesh network in NYC uses TP-Link routers pretty heavily.

And to add to your point, you also can absolutely change the number of calories you're burning. Exercise (especially at high intensity) can make a huge difference.

Hi, I was assuming that people would do their playing around and answer checking in ghci. MCPrelude does not export putStrLn because it is an IO function, which is a monad and I specifically wanted to hide all the prelude's monad stuff. I suggest loading your file in ghci with "ghci Set1.hs". Then you can just type "fiveRands" at the ghci prompt and it will show you the values.

Hi, I'm sorry you feel that way. Maybe you just aren't my target audience. That being said, Crockford's explanation of monads in that talk was overly simplistic and misses much of the point of the benefit that you get from them in a language like Haskell. And if we're being honest here I think it's safe to say that most programmers wouldn't have even heard of monads if it wasn't for Haskell. I gave a talk at the NY Haskell meetup a few years ago that specifically addresses Crockford's talk in a little more detail [1]. That talk might be about the level you're looking for. There is some Haskell code, but most of the talk should make sense to someone not familiar with Haskell.

[1] https://vimeo.com/59215336

Hi, author here. Thanks for the feedback. I definitely get your point. I thought about it and there are a few reasons I went the way I did. 1. I decided that functors are straightforward enough to not really need significant special treatment. 2. Applicatives are much less commonly used than monads (see IO etc), so I thought it would be more desirable to hit the bigger use case first without getting side tracked on applicatives. 3. I feel this progression kind of has history on its side since Applicative wasn't a super class of Monad until very recently.

That being said, I'm very open to being convinced otherwise and pull requests carry a lot of weight with me. If someone reorganized the material in the way you suggest and it had a nice flow, there's a decent chance I would accept it.

Now we just need to get personal dirt on all of congress as well as the Supreme Court justices leaked...

I used that phrase as a more concise way of communicating pretty much what you are suggesting. I assumed that since my choice of X was Haskell it was pretty much a given that I haven't limited myself to a certain programming language and aggressively investigate promising new technologies.

Haskell absolutely allows mutable references and arrays. See IORef [1] and MVector [2]. Notice how the functions that perform mutation are monadic. That's Haskell controlling the side effects and making sure that they don't pollute pure code. The ST monad stuff [3] that wyager mentioned is even cooler because it allows you to bundle up side effecting stuff and actually use it in pure code in a completely safe way, which is something that you can't do (without the dubious usafePerformIO) with the IO monad.

[1] https://downloads.haskell.org/~ghc/latest/docs/html/librarie...

[2] http://hackage.haskell.org/package/vector-0.11.0.0/docs/Data...

[3] https://downloads.haskell.org/~ghc/latest/docs/html/librarie...

Haskell lets you do side effects. The difference is that the type system carefully controls them.

I'm not sure if I like this definition of "functional". Don't get me wrong, I'm a Haskell guy and think Haskell is fantastic for production use, but this definition of "functional" almost seems to rule out everything except Haskell. Even if I try to maximize my Haskell fanboyism I can't with a straight face choose a definition for "functional programming language" that of the today's production-viable languages only includes Haskell. A definition that narrow just isn't very useful. I don't have super strong opinions about how it should be defined, but I tend to be drawn towards a more fuzzy definition. One that seems attractive is: "functional programming languages are languages that focus on functions as the basic unit of abstraction".

7 or 8 years ago I had to take over a Java project on the order of ~10k lines. I reduced the code size by 77% by rewriting it in, wait for it...Java.

After visiting another developer friend in San Francisco last summer I concluded that it would be very difficult for me to move to the Bay Area and maintain the overall cost and quality of living that I currently have in NYC. It seems to me that these kinds of analyses invariably either use or are significantly skewed by the Manhattan cost of living. But my personal (and admittedly inexhaustive) conclusion was that NYC provides much better possibilities of having a low cost of living while remaining reasonably close to Manhattan than it appeared was possible in the Bay Area.

> Maybe it becomes a little more agreeable if you flip it around: consider as "basic" whatever level people would reach after 100 hours of quality learning.

Yeah, I know what you mean. You certainly could do that. But I think that's less useful. If you use a specific number of hours as the benchmark you lose most of your relationship to useful levels of competence. I think each domain has natural levels of competence that have meaning, and it's probably better to keep the discussion oriented around that.

For a ukelele or guitar player, knowing enough to play the majority of pop songs is probably significant. For a piano or violin player maybe the bar for basic competence is a bit higher. For partner dancing it seems like the level you need to be to safely dance on a crowded public dance floor and make most partners feel comfortable is probably a pretty important level of skill to talk about. These levels are also personal. Maybe one budding pianist is happy with pop songs, but you're not going to be happy until you can play a full piano concerto. Perhaps your goal is just to be able to write a few computer programs, but a company hiring wants people who understand more about what it takes to maintain larger projects over a longer period of time.

When it comes down to how decisions are made in the real world nobody cares about how many hours you've practiced. It's all about what you can do.

I don't think they always need to be consecutive. I've seen situations where, say you practice deliberately for one hour. You see some noticeable progress, but for maybe the last half of the time your progress slows or levels off. Then, you can go away for awhile (maybe a day or a week) and when you come back you seem to be much better.

Not all activities work like this, but some do. Good teachers, however, pretty much always help. :)

> make significant progress towards competency in a new skill by putting in a MODICUM of time, effort and attention.

But even that is not always true. There are some activities where it's hard to see meaningful progress for awhile, but then once you've built up an adequate base you start progressing more rapidly.

These kinds of articles tend to be popular because they make people think that it's easy to learn new things. This is an inspiring idea and if it results in people learning more things then it might even be a beneficial thing to say. But I think it's more beneficial to promote the value of deliberate focused effort (hard work if you will), because some things simply don't come easily.

Hi there, thanks for the response. I actually don't mind the title--I've certainly been guilty of trying to increase my audience with a catchy title. I think the main reason I posted my comment was that even after reading your whole post, I still came away with "the 100-hour rule" sticking in my head pretty prominently. I think if I had written the article and chosen that title I would have tried to make people come away with a much stronger feeling about the fallacy of thinking about it in terms of "n hours" and more in terms of just deliberate focused effort.

I had a suspicion there might be some factors I was forgetting. I think this is a really big one so thanks for mentioning it. I recently became more aware of this factor after spending some time with a couple less fortunate kids going into college for computer science. It's amazing how a small amount of well-placed guidance from an experienced mentor can have a dramatic effect. In this case it was three things:

1. Learn vim (or emacs)

2. Use Linux and the command line

3. Use git

One of the guys started this semester. He's already a bright guy and would have been near the top of his class without me, but those three simple things make him look like a magician to his classmates. In the course of getting helping him get set up with Linux I also became aware how much of an advantage my middle class upbringing gave me. Something relatively basic like having a decent laptop can actually be a big obstacle. $1000 is a lot of money to a lot of people. Now I'm sure some people will say that you don't need to spend $1000 to get started with a usable computer. That's true, but there are useful things that you can do with a $1000 computer that the much more affordable computers can't do.

Another anecdote. A few years ago I was in a climbing gym and I tried slacklining. It seemed impossible so I didn't do anything more with it. A few years later someone suggested that it does wonders for your balance so I decided I wanted to learn. Then by luck I happened to run across some people slacklining and over the course of a couple days I was able to spend some time with them practicing. Their guidance got me over an initial hump that seemed insurmountable from the outside.

So yes, "environment" should DEFINITELY be added to my list!

> If you take the article with a bit of salt and step up the generalization ladder, the point is that skill expertise vs time grows exponentially

I thought about saying something like this, but after some reflection I don't think it's true. The shape of skill vs time curves is not always exponential.

For instance, take Argentine Tango. It took me 9 months of consistent 10 hours / week practice to even reach a point where I felt comfortable going to the average public social tango event. In fact, in tango it's pretty widely recognized that the learning curve shape is very different for leaders and followers. For followers it typically looks like [1]. But for leaders it's more like [2]. (Time on the x axis, skill on the y axis.) I really think that in general it's probably more like a "multi-hump curve" [3] in the general case. I had a situation recently where I took one lesson with a tango teacher and in one hour he totally revolutionized my dancing. And this isn't me talking, people I dance with regularly said that.

So I don't think the rate of progress at a new activity is always exponential or even fastest at the beginning.

[1] https://upload.wikimedia.org/wikipedia/commons/b/ba/Exponent...

[2] https://upload.wikimedia.org/wikipedia/commons/8/88/Logistic...

[3] http://mightybyte.net/learning-curve.png