Your IDE + a linter + a test suite = level up into any language super quickly
Ask HN: What are your favorite developer-efficiency tips?
201–210 of 532 posts
Re: Ask HN: What are your favorite developer-efficiency tips?
#202KEEP NOTES. Write everything down. Write down what you were thinking about, how you felt about decisions, things you tried for bug fixes. you never know when this stuff will be useful to you again. I keep really basic markdown notes in a git repo, roughly one file per day with an ISO date name, but some things I give a separate file name (still with the iso date, but with some descriptive words) for things that might…
Yes. I wish I did this years ago. I’ve been doing it since January but there are so many things on my resume (and elsewhere!) that I’ve since forgotten and it’s annoying.
Re: Ask HN: What are your favorite developer-efficiency tips?
#203Learn your environment and learn it well (over time). Every single thing that seems like weird arcane magic invented by brilliant wizards is just code or words, and often not a lot of it. Go find that code and read it. Docs are good, but they are almost never complete enough, because truly exhaustive docs would simply be the code [1]. Similarly, with something like CSS or OAuth that have specs, blog/tutorial content…
[deleted]
Re: Ask HN: What are your favorite developer-efficiency tips?
#204I 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've found recently that Makefiles are my best friend for this kind of thing, even if it's just wrapping existing commands with the right arguments and conventions for the project.
Being able to do a simple `make build`, instead of remembering all the right command syntax, repositories etc is so much nicer that having to trawl through a README in a couple of months time for how I was using this thing
Re: Ask HN: What are your favorite developer-efficiency tips?
#205Learn to touch-type properly. I'm not a shit hot typist or anything, but it does make hours on a keyboard more pleasant. And (hate me) I do judge other devs on it. If someone can't be bothered to invest a few tens of hours on such a key productivity enhancement then what does that say?
I'd love to subthread hear from people if alternate keyboard layouts have made a difference. ?
I've used Dvorak for the past few decades. As suggested by one of the other comments, it took about 2 weeks to learn well enough to get back to my normal speed (>80wpm).
It makes a massive difference in comfort. 5 minutes typing at full speed on QWERTY and my wrists start to hurt. (I really don't know how people do it.) On Dvorak, I can type all day at full speed with no pain at all. Surprisingly, the keyboard hardware itself doesn't seem to matter.
(Details: I mostly use a Mac, with caps lock mapped to control, NSRepeatCountBinding set to ^u, and -- obviously? -- I rarely touch the arrow keys.)
Re: Ask HN: What are your favorite developer-efficiency tips?
#206The 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 dramatically harder.
The investment you have to make to really grok static typing is quite large. It took about 2 years for me to be really comfortable in TS. But you'll have to claw it out of my cold dead hands now.
Before switching to web dev, I used to work in Java, C#, C++, etc. But I've been away from static typing for about a decade now. I completely forgot how beneficial it is.
Re: Ask HN: What are your favorite developer-efficiency tips?
#207Re: Ask HN: What are your favorite developer-efficiency tips?
#208I 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…
Super cool. Thanks for sharing
Re: Ask HN: What are your favorite developer-efficiency tips?
#209The 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.
Re: Ask HN: What are your favorite developer-efficiency tips?
#210Automate repetitive tasks that can be automated. A task may take ten minutes. Automating it may take hours, and thus seems too expensive. If this task is going to be done many times, then the automation WILL pay off. Running the automated task might take less time than the manual steps. And you can be doing something else. The more of these kinds of tasks that you can automate, the bigger of a lever it becomes. One o…
Another advantage is that you are less likely to make errors while using the automated way.
It also creates documentation/repeatable processes.
Also, learning, though that can be hard to justify.