pragmatist comments on Identification of Force Multipliers for Success - Less Wrong

17 Post author: Nick5a1 21 June 2014 05:15AM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Article Navigation

Comments (32)

Comments (32)

You are viewing a single comment's thread. Show more comments above.

Comment author: Antisuji 22 June 2014 12:27:20AM 10 points [-]

This sort of optimization is a pretty foundational concept for software engineers. These are things that have helped my career as a software engineer and made me more effective in my job (not exactly the same thing, but related!):

Basics

  • Touch typing. This should go without saying, but I've worked with people who hunt and peck and it's painful to watch. But you don't have to type really fast to get most of the benefit, since other bottlenecks will start to dominate. In my experience a pokey 50 WPM is more than sufficient.

More Advanced Mechanics

  • Gain fluency in a powerful shell, a good text editor, and an expressive "scripting" language
  • Learn a modern version control system such as git
  • Set up an environment that works for you and keep improving it – this is very much along the lines of Nick5a1's systems mindset. Keep your dotfiles in version control.
  • Don't repeat yourself. Learn to refactor code to remove unnecessary duplication.
  • Keep configuration decisions out of code
  • Understand dependencies among different pieces of code and know a few strategies for simplifying them (the pub/sub or event bus pattern, dependency injection, etc.)
  • Know how to deal with asynchronous operations using both callbacks and promises – NodeSchool has a great tutorial for server-side JavaScript.

Soft Skills

  • Keep a todo list (I keep my own, or you can get really good with your issue tracker)
  • Keep a log of things you've done (bonus if you can generate the log automatically from your todo list)
  • Keep notes on how you solved tricky problems
  • Understand your role (you're not a designer or product manager, but you need to know what they care about to work with them effectively)
  • prioritize the product, then others' goals, then your own (this is usually the most effective way of furthering your goals)
  • insist on regular one-on-one meetings with your manager
  • before answering a question find out why the question was asked
Comment author: pragmatist 26 June 2014 05:48:04AM 0 points [-]

Touch typing. This should go without saying, but I've worked with people who hunt and peck and it's painful to watch. But you don't have to type really fast to get most of the benefit, since other bottlenecks will start to dominate. In my experience a pokey 50 WPM is more than sufficient.

I don't touch type, and my typing speed is about 65 wpm. Do you think learning how to touch type will result in a significant increase in speed, enough to be worth the effort?

I'm an academic, so typing speed is probably not as important for me as it is for a software designer, but I do a lot of writing, so it is a potentially significant productivity boost.

Comment author: pushcx 26 June 2014 03:45:07PM 2 points [-]

Yes. Speeds of 100wpm are not particularly hard to reach with deliberate practice. The benefit is not the time savings of typing less, it's the cognitive savings of spending your attention on your topic rather than the mechanics of entering text and correcting errors.

Comment author: Antisuji 27 June 2014 06:37:21AM *  0 points [-]

As pushcx said it's not about speed as much as not having to pay attention to what your fingers are doing (and crucially, being able to look elsewhere while you type). The bottleneck isn't bandwidth but the size of your L1 cache.

Powered by Reddit Powered by Reddit