Live data from Hacker News

Ask HN: What are your favorite developer-efficiency tips?

news.ycombinator.com

441–450 of 532 posts

Re: Ask HN: What are your favorite developer-efficiency tips?

#441

- Your eyes are the only broadband connection into the brain, and they have millenia of pattern recognition training built into them. When solving problems like debugging, refactoring or data preparation, consider arranging information in a way that takes advantage of this. When it's in the right shape, irregularities or patterns will often just jump at you. - Relatedly, your eyes are also extremely well-adapted to d…

I spent a short time trying to find a pretty diff tool, but couldn't really find one to my liking. So just ended up using a bash function that did some decorating on the diff output.

Which OS? For macOS, Kaleidoscope is quite pretty.

Re: Ask HN: What are your favorite developer-efficiency tips?

#442
post #63
post #23

Automate 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.

I disagree. If your automation isn't well thought out, edge cases might just screw every target and you might have hard time rolling it back.

Re: Ask HN: What are your favorite developer-efficiency tips?

#443
post #413

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…

Thanks for the (very detailed) answer.

Re: Ask HN: What are your favorite developer-efficiency tips?

#444
Align your windows near the middle ok your display.

Displays are always in wide shape and if you maximize windows size of any app, you'll be looking to the left quite a lot.

What I do is I just narrow every window, so the left edge starts from a little bit left of the center of the display, so if I'm reading a page on a web, my neck would mostly be moving around the center of my natural facing position.

You can put other small window to the blank space at the left or put some desktop files there to be always accessible.

Re: Ask HN: What are your favorite developer-efficiency tips?

#445

From my experience - multiple desktops, especially when having multiple monitors (and yes, you should probably get a second monitor). If you don't use desktop switching: the basic idea is to have one desktop per task/bug/project. Lets you context-switch in a very organized manner. If you're using them, good, but you may be surprised how many people don't!

I've been developing for 30+ years and I honestly don't see much of a productivity benefit using multiple monitors. I work differently when I have them, but not necessarily more efficiently. I find the head moving required to use multiple monitors more annoying than just alt-tabbing between windows. The only major exception is if I'm doing intense UI or visualization work and I want to see my code and the output at t…

Agree with the multiple display not really being helpful. It may look professional but your neck won't feel so.

Also on a single monitor I do this to keep my neck and eyeballs easy.

https://news.ycombinator.com/item?id=23125617

The display size is usually good with about 24 inches. Bigger and you can't put everything within your sight which requires head movement.

Re: Ask HN: What are your favorite developer-efficiency tips?

#446

I use a 4k TV as a monitor - I can easily see full size my code editor, terminal output, a page of documentation and the web app/site I'm working on all at once. It cuts down tremendously on the back and forth switching and reloading of things that don't feel like they take up much time but do materially eat into things.

Isn't it annoying to keep moving your neck around than sticking to the main app window one at a time?

Re: Ask HN: What are your favorite developer-efficiency tips?

#447

Earlier quoted context omitted.

Not just that. Add this to you inputrc: "\e[A": history-search-backward "\e[B": history-search-forward Now up and down arrows will search your history with whatever you already have typed at the prompt. Re-running a command often? Probably just have to type its first letter and hit up arrow once or twice.

I like fzf for command history search. Ctrl-r, then fuzzy search the command, arrow up and down. Nirvana

fzf is game changing. Having have to guess exactly with Ctrl-R is a thing of the past.

Re: Ask HN: What are your favorite developer-efficiency tips?

#448
post #44

Avoid being an early adopter of new technology despite everyone on HN raving about it. Instead focus on solving actual business needs that grow revenue or profit margins.

Actually jumping to TypeScript at v1.x made me fluent with it and I now do projects with it.

With that said, I don't usually invest time on new stuff unless it looks absolutely convincing.

Re: Ask HN: What are your favorite developer-efficiency tips?

#450

KEEP 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…

A similar idea I practice. After I solve a complex problem I usually leave a big comment at the top of the main file, explaining how I arrived at that solution, the caveats, how it works, and how it interacts with other files and dependencies. If I need to, I also use Monodraw to produce ASCII character graphs and add them to the comment to explain concepts. It helps to cement the solution in your brain and it's a sy…

Instead of putting it as comment in the file, put it all (including graphs etc) as commit message when you commit the feature/fix
Post reply on HN