6 ms·

There are many reasons for doing the things the author did, but I highly doubt saving time is a valid reason. The amount of time spent on setting this up and le

• noonespecial 8y ago
  Some yaks just look really good bald.
  • chosenbreed37 8y ago
    > Some yaks just look really good bald. Sure...but how long will they stay bald? :)
    • castis 8y ago
      Once you have the proper shaving environment set up it should be pretty easy to keep them as smooth as desired.
    • sophacles 8y ago
      There's a legend of another yak. It's called "dotfiles management". It has the wildest mane of hair and actively resists shaving. If however you manage to get this yak shaved, they say it will confer the power to keep the other yaks bald effortlessly, at the low cost of occasionally removing the stubble from your dotfiles yak. There's also many legends of people going mad trying to shave this particular yak so...
    • james_s_tayler 8y ago
      Yaks present infinite opportunities to shave them. This is the benefit of Yaks. You never run out of stuff to do. Plus you have all that delicious yak fur.
• oblio 8y ago
  > But of course you should still do all of this, because it is a lot of fun and Vim rocks. Heh, probably. You should also compile your own kernel once (maybe even go for a LFS setup), configure FVWM with bells and whistles and probably a few other things I'm forgetting now :)
  • p1esk 8y ago
    Just to clarify, by "your own kernel" you mean one you've written from scratch?
    • smhenderson 8y ago
      Having mentioned LFS I'm pretty sure he meant compile the Linux kernel for your distro or go deeper and install everything GNU/Linux from source.
    • oblio 8y ago
      That would be nice, but it seems a bit overkill. It's a ton of really hard work, from what I gather. I've never done it, maybe I should try? :)
• monsieurbanana 8y ago
  Not all time is born equal. Imagine changing jobs. At your new job, you'll be able to go faster because you have a well optimized workflow. It doesn't matter to your new bosses that you previously spent an ungodly amount of time optimizing your workflow and learning advanced tools, the only thing they're seeing is a productive employee.
  • james_s_tayler 8y ago
    That's actually a pretty interesting point. Never considered it from that perspective.
• andrewl 8y ago
  You can definitely go too far with something like this. But although he might not get his time back on this project, he'll probably be writing more books and course materials, and he'll be moving faster on them because of the setup work he did for his current project.
• erikpukinskis 8y ago
  > It is a similar pitfall that developers step into when they optimize their code before profiling where the bottlenecks are at. I heard this many times and believed it, but after some time I think this is bad advice. Here's mine: There are two kinds of performance optimizations: free optimizations and optimizations with a cost. The free ones are things that don't really take any extra complexity to implement, just a little thought. Using a hashed data structure instead of an array when you'll be accessing items randomly by id. Breaking early from a loop. If you never think about these things unless you're explicitly on a profiling task, your code base will be full of "easy wins" that you have to go back and find and fix. Which will be time consuming and error prone if you do it after all your code is written. The other group of performance fixes is ones with a complexity cost: adding a cache layer, rewriting an algorithm in a slightly more confusing way, etc. My advice is: always pause when you are designing a new feature and think about whether there are "free" performance wins. You can implement them now with no cost, and you should. It often helps with your data design anyway, getting code that more closely matches the actual processing domain. It doesn't have to take more than a minute. Anything bigger than that, yes: punt it til after you have profiled.
  • ses1984 8y ago
    You're not wrong, but I don't think anyone is saying you shouldn't use appropriate data structures. To me the advice means don't belabor the choice of data structure of its not obvious to you. If you're writing a quad nested for loop to solve a problem, don't get distracted trying to refractor all the work leading up to that wart... Just get it down first. Get a passing test first then optimize later if the code is a bottleneck.
    • TeMPOraL 8y ago
      > Get a passing test first then optimize later if the code is a bottleneck. In that case, totally get that test passing and then maybe add few more tests around that solution - so that when I come to the project half a year later, and see the application consing like crazy because you used lists instead of arrays, and this now powers half of the business logic, I can tear this up and fix the data structure with confidence I won't break things badly. (Totally not a real case I had.)
• larrik 8y ago
  He's frontloading his time and attention, using time that isn't going to produce productive writing, and investing it so that his productive time doesn't deal with any of this crap.
  • bachmeier 8y ago
    Exactly right. When you're saving time is absolutely critical, particularly for something like writing. Even tiny automations that save what appear to be small amounts of time can lead to large increases in productivity by not distracting you.
• seer 8y ago
  You’ll be surprised how much those small automations and time savings pile up. And also if it keeps you in the flow it can make a quantitive difference truly qualitive. I always like to fallback on the “is it worth my time xkcd” https://xkcd.com/1205/ https://xkcd.com/1205/
  • nickjj 8y ago
    Yes, not only do they pile up, but there's another interesting win which isn't measurable in time. It's being happy. It's knowing you're using tools that let you get things done in a way that works best for you. Something like this has infinite value because it's the difference between waking up and dreading doing something because of the upcoming million paper cuts VS waking up really excited to do your task. That's the difference between writing nothing one day vs writing 5,000 top quality words.
    • james_s_tayler 8y ago
      This. I really feel optimization across this dimension perhaps the most. I just enjoy things much more. Maybe if you really want to quantify it you could think of the happiness factor as a multiplier. So you have a task that takes X time. What's say optimizing it is a net loss time-wise because it doesn't in aggregate save you more than you spent to perform the optimization. Say after optimization it only costs 0.8X time but it took 0.2X time to do the optimization so all benefit cancels out. But the difference being now happiness is 1.5 multiplier so you feel 50% better and the same aggregate amount of time is spent but it's much more enjoyable and therefore more valuable to you. Maybe I'm not explaining it well, but I totally feel this way about plenty of stuff.
• nickjj 8y ago
  > It is a similar pitfall that developers step into when they optimize their code before profiling where the bottlenecks are at. Author here. For reference I've made 5 courses over the last 4 years and have written over a million words. I also have 200+ blog posts and have hundreds of thousands of lines of code written across a bunch of projects. In other words, I hope I know what my bottlenecks are with my environment. It's not specifically editing text, but it is managing a shit load of words across many hundreds of files and also switching between projects. With no real prior Vim knowledge (I looked at it once many years ago) it took a solid weekend, and when I say solid, I mean I spent 10 hours both days researching Vim features, watching tutorials, following along with tutorials and slowly introducing a couple of plugins I knew I wanted (based on exact problems I had). That got me to the point where I had the environment mostly working with a decent enough config file. Then I spent days floundering around like an idiot while I hardcore failed to even do simple things like "move to the 2nd to last word in a sentence and then wrap the last 2 words to a new line". Doing that without arrow keys and no mouse almost killed me initially. After about a week of immersing myself I got to the point where I didn't feel like I was completely destroyed by a foreign environment. During this week I wrote about 10,000 words and worked on a couple of freelance programming gigs. In my opinion, it was worth the 20 hours of set up + 20ish hours of not being as productive to set me up for the next 5+ years. Plus as you mentioned, a side effect is it happens to be a fun too. That's a win win!
  • asdkhadsj 8y ago
    > In other words, I hope I know what my bottlenecks are with my environment. It's not specifically editing text, but it is managing a shit load of words across many hundreds of files and also switching between projects. I think another way to look at it is that humans are terrible at perceiving reality over time. Our understanding of what problems are most pressing are often only accurate to criteria that we aren't aware of judging. Ie, psychological biases built around your world view can have material impact on what you perceive as the most pressing problems - especially when trying to boil down thousands of hours of data points. That's not to dismiss your findings - it's simply to say I distrust human perception, benchmarks are needed. Hah :)
  • ejstronge 8y ago
• deleted 8y ago
  [deleted]
• kbenson 8y ago
  I think this ignores that certain types of optimizations can have benefits that are small but almost constant. A more fluid environment for your task can result in less jarring stops that take you out of the task at hand, and keep you in a highly focused state. Maximizing the time in this state, where you might actually be some multiple more productive, is a vast improvement over just saving a little time.
• darkerside 8y ago
  As one who codes in Vim, there is a huge time savings from living in a tool that closely maps your mind. Every cognitive load you can extract from the process of getting your vision down onto paper builds a compound interest in keeping your flow and momentum going while you work. If you're searching for menu options, or browsing a file directory, or doing the hundreds of other things it takes to otherwise navigate a computer file system, you can easily lose track of what you're trying to write in the first place. Call it saving time, or call it building productive power, but either way, it adds up fast. Not to mention the aesthetic pleasure of making your tools a joy to use.
  • njarboe 8y ago
    Nicely said. Master craftsmen spend much time and money acquiring high quality tools to use while they work. Most make many custom tools themselves. Having great working tools that become extensions of your body (and the body can be looked at as just a very tightly integrated tool for your mind) is key to long, highly productive sessions of creativity. Computer programmers also search for the same type of tools.
• JTbane 8y ago
  Not true at all- optimizing the tools you use is very different than prematurely optimizing code.