451–460 of 532 posts
I just started at Stripe last year, and I found myself perform many mechanical tasks like: * Converting seconds-from-epoch to a human readable date * Select an id and pull info about it At first, I tried to perform these mechanical tasks with some crazy shortcuts. But remembering shortcuts for every little flow is heavy. Eventually, I've built a programmable tooltip on Mac OS X for these mechanical tasks. I'd love fo…
This is awesome.
Earlier quoted context omitted.
I'm really confused. I've only run into maybe one person working as a developer that didn't touch type. Is this really not nearly universal? My version of this would be learn not to use a mouse.
A lot of people type without having to look buy without using the proper technique, essentially doing hunt and peck with two or three fingers but with good muscle memory. Proper touch typing is about using specific fingers to specific keys and remaining on the home row when not in use.
The biggest boost in productivity I've had in recent years is switching back to a statically typed language. TypeScript in my case. You can absolutely refactor and change course _so_ much quicker and with virtually no regressions at all. Just the other day we realized a feature I was building didn't handle an important case, and I had to really change the approach. Doing it in a JavaScript would have been dramaticall…
Used to love Python. Now, unless it has type hints, not so much. Used to hate static types, or at least I thought I did. Really, I just hated C++ and Java. Go is Bae, trying to learn some rust. Computers are rigid. The more rigid the lang you talk to them, the less you get bitten. Untyped python, bash, javascript, just not worth it imho.
I consider scripts to be functional documentation, so I write a lot of them, usually shell scripts but Ruby and Python, too. Any task that I might want to perform again, or tasks for someone else, gets a script if possible. All of my repos have a /scripts directory. It can take some work to write and debug but in the end when it's working you know you have correct "documentation". Text and wiki documentation may look…
I also like having a script per project that will get auto loaded when you cd in. An example from a current project: #my vimrc knows what to do with this export VIM_TAGFILES="$PWD/build/tags,$HOME/.local/var/tags/system,$HOME/.local/var/tags/glib-2.0" export CFLAGS=' -g -O0 ' function autobuild { (mkdir -p build cd build while true; do make make deploy inotifywait -qr -e close_write,delete ../cgi ../test ../Makefile.…
Earlier quoted context omitted.
One thing you can try: actually stop after those 5 push-ups. Actually stop after editing that line of the code. The idea is that I need to build tolerance for that task. If you keep at it, those 5 push-ups will become so easy that you will feel compelled to do more. If it's not working, then there's another reason behind the resistance. Maybe what you're trying to do feels pointless. Try to notice your feelings and i…
Or just make the task smaller and smaller. Can’t finish 5? Do 1! Too much? Just get on the floor and hold the position. This strategy can’t fail, as you can always reduce your goal (and next time have to reduce it less)
Earlier quoted context omitted.
Same. Learn to type ~100 words/minute, I was surprised by how much more productive it has made me. Using a touch type trainer for a minute or two can also be a little mental break from writing software for hours.
I can touch type but can't get much faster than 60-70 WPM. I've been practicing for years. Any tips for speed?
If you don't already have one get a good ergonomic keyboard. I recently switched to an ergodox ortholinear layout and it immediately exposed my bad typing habits. The split hand layout saves my neck and shoulders and my working posture has noticeably improved. Took about a month to get back to 80 wpm and don't feel like I've plateaued yet trying to get to 125 wpm.
I had a Judo coach who used to scream "Practice doesn't make perfect. Perfect practice makes perfect." In practice sessions focus on not making any mistakes & using only the correct fingers to strike keys. It can be hard to resist the temptation to start hammering as fast as you can in practice but slowing down once in a while can greatly improve muscle memory.
I use https://www.keybr.com/ to track stats, practice limited or different key sets, it also supports non qwerty layouts for stretching your comfort zone. For touch typing practice it displays a real-time keylogger map so you can auto-correct your finger positioning without looking at the keyboard, if you've got a fancy keyboard (Shout out Arts and Crafts HN) you can hook up the firmware to do the same.
This is a bit of a departure from the question you asked, but I'm always amazed how much people tend to hyper-tune their dev environments, when in reality, most of my time is spent thinking how not to write code. I get just as much work done on a completely vanilla macbook with VS code installed on it as my editor-obsessed peers with obsessively optimized setups can. How much actual code are you writing? I'd be reall…
Coding is, as you've noted, rarely about typing speed. The larger a program gets, the longer the files get, the more spread out across different files and directories it gets. (Consider yourself very lucky if the programs you work on can fit entirely inside your working memory! Others have bigger programs to work on, or differently shaped working memory) Being able to find "that thing you saw that one time" is paramount. How you find it, is an entirely personal choice, but being able to find it, quickly, and without breaking out of flow state, is the goal. Whether it's by learning VS code (which has a expansive collection of settings and extensions to "obsessively" tune), or by installing ag. (And yes, for the obsessive, the merits of ag vs ripgrep/other is a fun rabbit hole to fall into.)
Still, between from when you start coding, to when you share the diff with anybody, coding is an intensely private activity (that some choose to share with others). As such, whatever works. If trying to open a file while traversing a tree view is distracting enough that it takes couple tries, and you don't mind taking a couple times, great. If I've got my dev env setup to so I can open the file from the command line where I've already got the filename, that's cool too. If I want to learn VS code's command bar syntax so I can open it from there, that also works. And if you can open that file first try, while simultaneously navigating a stream of code, good for you.
End of the day, comparing "just as much work done" with two independent variables (the configuration, and the person using the setup) and no control, is as foolish as managers trying to quantify programmer output by counting lines of code.
Earlier quoted context omitted.
Genuine question: do you think that writing your own editor was a better investment than extensively customizing an existing editor like Vim or Emacs (even going so far as to change the keybinds and UI)?
Good question. I guess I'll never know for sure. I believe it has been worth it for me, as there are several things I can do now that I'm not sure whether I'd have been able to achieve by customizing them (unless you include "rewriting their source code extensively" as customizing them; but at that point I think I'd be roughly doing the same as what I did?). I'll give three examples: 1. Being able to run edge -view=a…
It looks like the function or loop scope? What are you using to generate/output that information? What languages does it work in? How hard is it to add support for new languages?