Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: What are your favorite developer-efficiency tips?
566 points by kanyethegreat 11 months ago | hide | past | favorite | 522 comments
I recently started integrating tmux and vim into my workflows. Obviously, it was a huge efficiency booster. What are some other tools (custom built or off-the-shelf), hotkeys, workflows that were game-changing for you as a dev? I'm interested in hearing about anything and everything (stuff from ctrl+l to clear the terminal to little-known git commands to larger-scale strategies like CI/CD)



Obs studio. I record myself while coding anything. I pretend to be a bigshot coding streaming sensation (even if its just for me). Its fun as well as very helpful in so many ways.

1. It helps me stay focus on the task at hand. One recording for each task 2. It lets me practice how to articulate stuffs. Its like blogging but ephemeral (because i wont upload this) 3. It helps me get motivated. Cant let my "thousands" of viewers down 4. It lets me review my blunders so i know how to watch out for them in the future 5. Its fun. I can let off some steam because i can curse all i want, my audience is 18+ and fine with some "sentence enhancers". I am Filipino but i record in English so i get that extra bonus practice.


Alternatively, if you don't care about having an audience, you can just do private livestreams directly to YouTube via OBS. After your stream is concluded, it saves the livestream as a VOD. With this method, you don't have to worry about storing large video files when recording yourself.

Also, because it's YouTube, you inherit all of the benefits YouTube provides. You get the added benefit of having closed captioning for your videos after processing. You can watch through your recordings at 2x speed. And of course, you can share VODs to other people if you ever need to.

I've been treating YouTube as a personalized streaming website with free, unlimited storage.

If you do end up doing this, make sure to avoid any copyrighted content (Netflix, official music, etc.), otherwise YouTube will copyright strike your channel.


I also considered this in the past but sometimes, I slip into procrastination mode unintentionally and might check my bank account (or pornhub) once in a while. So thinking my video is uploaded to somebody else's computer gives me the shivers.


Have a user account just for streaming. Then you can block any sites that you don't want shown.


It seems the point of doing this is it stops you procrastinating, because you're pretending to be a hot shot twitch streamer. If it were a live stream, you wouldn't start watching porn, you'd stay focused.

Basically the productivity tip is to pretend you're already productive.


Fair point. But sometimes the pretending part fades away when I get to the "flow". When that happens, I usually forget OBS was even running way after the task was done. If it were Twitch stream, I imagine somebody from the chat window would remind me to put my d* away


Thank you for posting this. A couple of months ago I built out the design then all the FE code for a prototype app, and recorded the whole process as J was doing it, mainly as an experiment to see where o could improve a few aspects of my designing/developing.

It was all a huge faff as I was just recording short screen captures using QuickTime. But it's definitely the most productive I've been for a very long time, as well as ending up with designs better than anything else I've done for the last year. I did it at work in the office over a few days, so couldn't really talk my way through it (which I think would have improved things still further). I haven't repeated the technique because of the (non programming) effort involved, but Obs seems very good, and something that should push me to try to implement the technique a lot more.


One thing that helped me was screen recording my editor session and then re-watching it on the highest playback speed. You start to get a feel for the arc of laying out the code, what refactoring operations look like. Most code is selection, map, map, filter, reduce, re-join, etc. Watching your actions get played back, allows you to re-think those thoughts but in the third person. Mirrors help, video helps, we are not ourselves, once you realize that, optimization becomes much easier.


> Mirrors help, video helps, we are not ourselves, once you realize that, optimization becomes much easier.

It's funny, in two of the areas I've worked in (tailoring and illustration) I was taught techniques that are analogues to this. With illustration, if you draw from a reference, one of the ways to improve accuracy is to turn the reference image upside down, which basically stops your brain seeing it as the thing it is an image of. Instead it becomes a structure of shapes, it's easier to draw. With tailoring, when cutting on a model/dummy, I was taught to continually check the work in a mirror instead of always looking directly at it -- again, I think a way to stop the brain automatically filling in structures and shapes, to force it to see the piece as a whole from a different perspective.


How did you come across these techniques? Do you know of any body of research that covers this?

With my kid, we practice drawing and eating with the non-dominant hand or try and draw something from a different orientation.


I was trained (and worked, for a short time) in tailoring/fashion, and was also trained and worked (for a longer time) as a designer and illustrator. I was just taught to do this as a matter of course (by tutors and by technicians). It's just finding ways to trick your brain into actually thinking about things instead of relying on (habitually ingrained) automatic movements which tend to cause you to miss obvious errors.

Re illustration, this is quite common when explaining how to draw from a reference picture. Not at any detailed length as far as I can ever remember, literally just "turn the photograph upside down when you're drawing from it" (doesn't really need much explanation, that just how it works). As far as introductory books go I can remember "Drawing on the Right Side of the Brain" goes through this.

Re tailoring, the issue is that you tend to fuck up the balance of things in 3D when you're sitting staring at specific bits of it, even when you step back you only tend to see what you want if you've been at it for a while. You need to be able to see it from a. different angles at the same time, and b. not just directly through your eyes

The non-dominant hand will work for what you're doing, it's a good thing to do I think (in a way I wish I'd been taught to practise using my right more when I was a child). The reference image technique is specifically to increase accuracy though, so slightly different aim


> Most code is selection, map, map, filter, reduce, re-join, etc

In which language do you code?


I take it they're speaking generally, as that covers all languages: map something to data, take that data and do something to it, map it back out to something a human or computer wants.


I imagine by speaking out loud you also get a type of "rubber duck debugging" that makes it easier to work through problems too. Nice idea!


I loved this idea. Can you share your Obs defaults/workflow for this? By example, I work 8hs per day, how much space all this audio/video recording will take? What video/resolution/etc? Thank you!


Honestly for me it was just the act of being able to see my picture and my screen moving inside OBS, not even the fact that it was recording. I tried streaming myself live coding on Twitch a couple times and it was a blast. I felt like I was thinking so much more clearly. I didn't save the recordings—just the act of it all was worthwhile.


the idea is to make a video that you can watch yourself. 8 hours of video isn't very enticing to watch. i suggest organizing the recordings by feature or task.

the only other thing I considered setting up in OBS is to make it work with Spotify to get a great bg music.


That's a great idea. I have done this with vlogs/podcasting and even blogging (created several fake blogs over the years, even in a journal on paper), but never while coding or otherwise doing stuff on the screen. Good stuff.


I don't have anything to add but I feel like a simple upvote does not do this idea justice - that's so awesome, I have to try it!


Such a good idea.


ha, I do this too, thought I was the only one


Use procrastination against itself.

So basically, when procrastinating, we tend to justify our inactions: just 1 more minute on Twitter, just one last scroll on my newfeed, lemme just check this subreddit really quick.

With reverse procrastination, you trick your brain into doing your intended task: Ok lemme just open Visual Studio Code and edit this one file then im good, I'll just change this one line of code, I'll just do 5 pushups then i'll stop. Then when you're on your 5th pushup, you say "surprise mr lazy pants, im actually doing 10!"

Once you get to do that one task, try to trick again your brain into doing another simple, easy task and before you know it youre in "the zone".

Maybe it depends on the person, but for me personally, it works pretty good.

Perhaps OP is asking for tools, but no amount of dev tools can help if you dont have the motivation to begin.


Yeah, I tried that. Didn't work for me. I'm too clever for my own tricks.


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 internal dialogue when you're trying to do that particular thing.


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)


I agree and it's important, at the same time, not to trick yourself or push yourself. If you don't feel like doing more, don't. With time, you'll want to do more.


Right. Eventually the task gets so small, it's easier to do it than to cut it into yet smaller pieces.


What's happening is you are procrastinating doing the reverse-procrastinating. haha

You can start by doing something you actually LIKE doing - no tricks.


I usually have my current project opened in Visual Studio Code at a separate desktop, so I can just swipe right and start coding. If there is an easy task I can complete quickly(not a lot of thinking) to hook me in it is pretty efficient.


Why not use both together? I tend to browse Twitter and HN in-between builds, unit-tests, model mini-training, and simulations.

If the blocker is small enough to not be worth a context shift to another work-task, then Twitter/HN are a great mini break.


> to not be worth a context shift

who says Twitter/HN doesnt constitute a context switch? In my experience, though very boring, sitting and waiting for the tests to pass is much more productive than even the slightest diversions. I believe this is due to focus and memory.


The problem with that (for Internet addicts) is that that short break then always turns into one and a half hours.


Interesting tip. Additionally, I believe attacking the cause of procrastination can be helpful in the long term. Just asking "Why do I need to check my Twitter feed?" and "Is it more important than the task I am currently tending to?" can go a long way in reducing procrastination.

https://www.bbc.com/worklife/article/20200121-why-procrastin...


This reminds me of the "floss one tooth" strategy:

https://www.fastcompany.com/3022830/the-secret-to-changing-y...


I read this book on micro tasks by the guy that started the one pushup challenge. I have been doing pushups every day for over a year now. It takes a while to make it a habit, but it does work.


The hardest part of this trick maybe being conscious of our actions while auto-pilot is often the default behavior.


The things I've benefited from most are not tools but practices.

- Question the work

Always be questioning whether the thing you're doing really needs to be done. Is there a way to not do it? Is there a way to do something better instead?

- Park downhill

Before putting a project or incomplete task away, make notes of what the next thing was that you were going to work on. This lets you bypass that 10 minute orientation getting back into the project the next time you pick it up.

- Keep a single todo list outside of your head

You can only have one master, so keep a single todo list in order of priority. Whenever something pops up on your radar, put it on the list in the right spot and immediately forget about it. Check the todo list a few times a day to make sure you're working on the right thing, and whether you need to communicate that something low on the list won't get done in time. Aggressively try to weed out the list and remove as many items as possible, preferably by not having to do them (by reassigning, by replacing or by reprioritizing).

Benefits: (1) not forgetting to do any work, (2) free up your mind to focus on work instead of meta-work, (3) clear priorities, (4) detect early when work is going to get delayed.

To combine this with park downhill I either keep the per-task notes on what to do next right in the list (in a details field of the todo item), or I keep it somewhere else and have just a single top-level item "finish X" in the master list.


Semi-related to “park downhill” is something I do at the end of the day if I’m still working on a piece of code - I’ll write a simple next task in a non-comment so it breaks the syntax. Then the next day I can dive in and “fix” the code which, at least for me, helps get in the groove.


Another variation: leave a failing unit test that will pass when you implement the next thing you were planning on doing.


This is like the coding equivalent of Ernest Hemingway's "stop writing in the middle of a sentence" strategy for overcoming writer's block:

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


Also: don't question the work.

Sometimes it's already a compromise between too many people who questioned it, and nobody wants to discuss it any more. Sometimes the questioning is more work than actually doing it. Sometimes you get a reputation of only being in the way.

Make sure the work has been questioned thoroughly, but that doesn't necessarily mean by you.


I love that last line. I think sometimes developers can feel like they can be the hero, stopping the business from going down the wrong path simply because nobody else asked the question. They may even be right! But question your motives. Are you asking questions and throwing up roadblocks to make yourself look and feel important? Or is it purely to make the best business decision?

That's not a leading question. Honestly, both of those goals can be important and effective. But if your goal is to actually effect business change, you'll probably have better luck talking to a product person offline and having the idea come from them.


I agree with this to an extent but I feel you should always ask yourself 'why'. 'why is this feature valuable to the user?', 'why has this functionality been chosen over another?' etc.

At the end of the day the work you are doing has an impact on opportunity cost - if you at least internally question the work you are doing, you can potentially lower the opportunity cost and therefore help the business.

However, if you are part of a team of people who consider these things before the work gets to you, I agree it can be counter-productive to question it.


Re: questioning the work... I’ve found that there’s a certain threshold (that is surprisingly high, sometimes) where it’s easier and faster to just do something low value than it is to convince everyone else involved and reach alignment that it isn’t a valuable thing to do.


Regarding the todo list, I find that having a text-format todo list for the current day can provide structure and sense of accomplishment (especially at the end of the day). After completing a task I would put a checkmark emoji in front of it. Such a list can also bring me back on track after a lunch or a mentally-demanding task.

If I know that I won't be able to do a certain task today, I put it in advance for the next day's todo list. Not completed tasks will roll to the next day.

Plan for May 11:

  - Contact Person 1 regarding Thing 1
  - [checkmark] Review Pull Request 1 made by Person 2
  - Implement Thing 1 from Feature 1
  - Read Email 1 from Person 3
Plan for May 12:

  - Implement Thing 2 from Feature 1
  - Investigate Thing 3


This is similar for me, except I integrate that into a daily log via a running google doc. Lists off the tickets I did, meetings, conversations and action items to follow up on. We have two week sprints, and sometimes around retro its really easy to forget things that happened the week before that would be useful to call out.


Apple notes is surprisingly nice for this style of todo list if you use a mac.


You can access your apple notes on a windows computer too, either by visiting iCloud.com or downloading the iCloud app from the Microsoft store.


This is also perfect for a Daily Scrum, as you know exactly what you've been doing the day before.


I like taskade to manage this. I'll use the weekly Todo list template and it works well


This is the use case for why I started using org mode.


I guess this means "park facing down hill" as opposed to "park down the bottom of the hill" which is what I first thought it meant but doesn't make as much sense. lol


Learn 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 often leaves out important details that will be relevant to you. If you get stuck, quit wasting your time with them, and go read the damn spec! If you're still stuck after that, go read the implementation.

Wherever you work, there is probably a page with like hundreds of ugly graphs of it. Learn what the graphs mean.

When you do this, a day will come where someone will say "Kanye, I've been banging my head all day on why users are sometimes seeing outdated results after updating their page". A little thing will happen in your head, and you'll say "That sounds like replication lag/a weird quirk of the CSS spec/a bug I noticed in the graphics code", and suddenly you'll discovered that you are the wizard.

I'm not saying to do this instead of doing those other things, or instead of whatever you're supposed to be doing. I'm saying do it as part of your practice of making software. You're probably gonna do it for like 40 years, so might as well make the investment.

[1]: https://en.wikipedia.org/wiki/Map%E2%80%93territory_relation (Second time referencing this on HN today)


Something that helps me is drawing/writing my own summary of what I just read or what a process is. For example: OAuth2 can be pretty confusing at first, but reading about the flow and drawing your own diagram helps me a lot to learn, as opposed to just reading. It also makes a nice reference for later, tailored to what I need most.


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 be good to re-access or are part of a series of similar notes (like a TIL file or a recurring meeting with the same person).


I do the same, using the Zettelkasten method. I've found it very useful. I write many small notes as markdown files and link them together, storing them in a git repository.

I wrote a bit about Zettelkästen (and the practices I follow), in case others find it useful: https://github.com/alefore/weblog/blob/master/zettelkasten.m...


That’s amazing!

So the linkages for the visualizations are derived from the notes themselves?


Aww, thank you!

Yeah, that entire article is generated from the set of notes. There's one note for each subsection (down to the finest level of granularity) and it just extracts the article directly based on the links. I described this in a set of notes that end up here: https://github.com/alefore/weblog/blob/master/zettelkasten.m...

The images (e.g., distribution of back links per file, semilattice view, etc.) are also just generated programmatically from the repository of notes.

The code that extract it is here: https://github.com/alefore/edge/blob/master/rc/editor_comman... (function zke, which receives the output path, the path to the initial note, and a string listing space separated paths of notes to ignore).

Here's another example of an article generated from my notes (this is way longer and is very incomplete, and probably contains a bunch of mistakes, but you may find it interesting as an example): https://github.com/alefore/weblog/blob/master/software-corre...


I love this. I've been wanting something just like this. Thank you!


Seems very similar to the structure of Notational Velocity, though I don’t remember whether NV provides easy cross linking between notes.


The first thing I do for every project is set up a development blog. Hugo + a nice free theme + Gitlab Pages + Netlify CMS. Everything is contained in Gitlab and I can keep the Pages site private and only accessible by members of the repo. It is less of a daily log and more exploring "issues" - basically anything I took time to research and figure out. I'm very adamant about recording details like dates, version numbers, context, code snippets, commands, and URLs of resources used. It all comes down to asking myself, if I see this issue again in the future, what information do I need to easily solve it without opening 40 browser tabs? At first it takes some effort to circle back and write the post after you solved the issue, but after a while I found myself writing the post concurrent with writing my code. The Netlify CMS isn't the most beautiful UI but being able to just write markdown in a browser window eliminates having to keep a git repo locally. Organizing with categories and tags makes referencing published posts easy and if you want to get fancy you can integrate Algolia for search. Honestly, having a project dev blog has saved me so much time since I don't need to keep every detail in my head anymore. Being able to go back and read about why certain decisions were made or how I overcame complicated problems is absolutely invaluable. And of course having this rich documentation while on-boarding new team members or passing the project off to someone else makes everything easier. Setting up a dev blog is 100% worth the minimal effort it takes.


I've been doing this for years, and even though basically no one reads my blog, it's nice to have a place where I put "polished" thoughts about my projects.


I love this. I have a grouping of pages in Notion for tech notes. But I really like the idea of scoping it to a project. I like that you don't need a local repo. I'll have to experiment with this. Have you automated anything for it? And do you have any patterns you use (eg. organizing the information, etc). Thanks!


There's really not much to automate. The Gitlab CI/CD config file to build Hugo and publish to Pages is always the same so I just re-use it as boilerplate. Likewise the Netlify config is usually the same as well, so once you've learned that syntax and structure it's not much work to put in place. I always like to peruse the latest Hugo free themes before I start and I usually end up using a new theme for each site anyway. The only real patterns in terms of organization is making sure I categorize and tag each post in a detailed manner. Most issues are related to a certain piece of the project or tech used, so when you know for example that your issue is related to the database then you can look at all posts categorized or tagged in a similar way to see if you already addressed the issue. I do find the most helpful step I took was making sure the post had a nice meaningful title with the proper keywords - that helps keep you from reading multiple posts until you find the one you need. Hugo and Gitlab's CI/CD are really great but the open source Netlify CMS is the key to making this setup so easy and remote only.


I tried to do this for my last project but ended up spending too much time making the blog and didn't get around to properly starting the project! Maybe instead of rolling my own site from scratch I'll use Hugo.


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 system of record on how it was accomplished in case you forget.

I do this only for personal projects though. I don't think co-workers would appreciate an essay with exhibits at the top of a file, lol.


> I don't think co-workers would appreciate an essay with exhibits at the top of a file, lol.

Why? I don't really have an experience of being a co-worker, but I have always appreciated such essays in free software.


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


+1 for notes. I make really detailed notes in issue threads when I'm working on things. I recently started keeping a TILs GitHub repo and it's already proved useful. https://github.com/simonw/til


I want to take notes everyday, but I keep getting bogged down by how to organize those notes so I can "look back" efficiently. Essentially, I want to avoid taking so much notes that I'm reluctant to search for something because I haven't organized it well. Do you think the ISO date name method is working well for you?


It's mostly for sorting and context. I just do a straight up search (in my case in vscode) across all notes when I want to find notes about something particular.

Really the most important thing to do is just start taking notes. You can reorganize later if you need to.


I just have a simple header for each day:

   # 09/05/2020
   Today I mostly ate cake

   ## Discoveries
   ## Meetings
   ## Projects
   - Worked on project 1
     - Fixed issue <link>
     - TODO: Bugfix #1234
   ## Misc
So a fixed set of headers for each day "Projects", "Meetings", "Discoveries", "Misc", and free-form text. Sometimes I copy/paste commands and output.

Searching is pretty much just grep.

More detail here https://blog.steve.fi/keeping_a_simple_markdown_work_log__vi...


Seconded. I finally skipped endlessly looking for the perfect note system and just created this stupid 10ish snippet of shell:

https://github.com/lloeki/dotfiles/blob/master/shell/notes

   note foo # creates a note in vim
   note # lists notes in vim’s netrw
Since note file names are time stamped, they’re sorted and I don’t have to care about dupe names. It defaults to creating as .md but renaming the file afterwards doesn’t matter.

It’s so dead simple that I use it all the time instead of fantasising about the perfect note system.


OP mentions vim, so I want to add to this that I use vimwiki for this purpose: https://github.com/vimwiki/vimwiki


I use org-mode in emacs for this! I usually keep notes on whatever task I am working on, and more general programming notes which I file into tagged headlines for easy reference later.


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.


I use a combination of WorkFlowy and Notion for note-taking. WorkFlowy serves as my daily quick jotting medium. Notion I spend more time crafting and organizing, so that knowledge is more discoverable. Do you ever find yourself going through these ISO-dated notes? I would image re-finding something is difficult?


I do this too, and I use Sublime to generate HTML from Markdown, so at work I have hosted guides like commonly-used SQL queries for one of our projects or documentation on how I updated our OpenSUSE and built a specific version of mariaDB we needed. It's been pretty great.


This. I'm having some difficulty remembering details of systems I worked on and bugs/approaches I took at places I no longer work at. Going forward I'm going to document details about everything I do, a personal post mortem of sorts.


I have read somewhere: Code comments are like love letters to your future self :-)


Org-mode ftw


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


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

That sounds a bit exaggerated from my experience. If anyone interested in TS got discouraged reading your comment, it took between like 2 days and 2 weeks for my team to be really comfortable in TS. If you already know JavaScript and if you already have some experience with statically-typed languages, TS is literally JS with static types.


Maybe my choice of the word "comfortable" was incorrect (although I would say "grok" was a spot on word choice in this context). It took me a good while to get the point where no matter what I encounter in TS, I feel pretty confident I can arrive at understanding it. The type system is very powerful and there are some deep rabbit holes you can find yourself in.

For example, if you can follow this blog post after only two weeks then you are much smarter than me: https://medium.com/free-code-camp/typescript-curry-ramda-typ.... This is a pretty extreme example, but sometimes you hit crazy types or crazy type errors like this.

But I would agree it doesn't take all that long to feel comfortable enough with TS to be productive with it.


Interesting article. :)

And there is a useful library linked at the end: https://github.com/pirix-gh/ts-toolbelt.


To be fair, TypeScript's typing is very overloaded with stuff, and is much more complicated than Java or C#'s.


Hence my love for ReasonML / OCaml with the Bucklescript compiler.


Do you use ReasonML on the backend as well? Or just something like ReasonReact? I've been interested in Reason and still wondering the best way to work it into my NodeJS/React/Typescript stack.


I am not parent comment's author, but I use TS on the backend and I did look into ReasonML. I love most of Reason's syntax and FP in general, but unfortunately, reason/bucklescript ecosystem just isn't mature enough for a serious project. I'd recommend against using it unless you are in some megacorp and you can afford to build general-purpose tooling.


Doesn't mean it's hard to get started. It only means, if you want to type everything to the detail, you can do it.


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.


FYI: Perl has moderately strong typing, as well as forward references, an excellent debugger and probably the most powerful web framework, mojolicious.

If you're unhappy with how loose python and js are, you might find happiness with Perl.

To enable the checking:

use strict;

use diagnostics;


TL,DR: Try F# or other "impure" ML languages if you want the security of types but you don't like actually typing the types.

I also used to love js / php because because I thought types make the code unnecessarily verbose. After some pet projects with a strongly typed lang (c#) I realized the peace of mind that using types gives. But I still maintain my opinion that types make the code too verbose.

But then I saw the "light" that is F# and I'm here to preach:

F# has types BUT you don't need to type them (most of the time) because it has type inference. F# can be used in the .net ecosystem and most of the time it can replace C#. F# can be compiled to js (although the interop is a bit messy). F# is a better typed javascript than typescript. F# is predominantly functional but you can also write code in the non-functional(ha!) style of your choice. F# discourages you from coding mutable spaghetti F# has decent tooling: VSCode + Ionide + dotnet + paket F# has pipes |>

The bad parts:

F# is not a hard-core functional language like Haskell, but for me this is a positive F# is a functional language which requires a change about how you think about a program. F# doesn't have a huge community F# doesn't give you a lot of job prospects F# doesn't have a lot of 3rd party libraries (but you can use c# libraries in .net or js libraries with fable. You can also mostly port libraries from other functional languages) F# requires you to think about the order of your declaration. Cyclic dependencies are harder to accomplish although this might be a good thing.


For the good parts, I would add the effortless type declarations to overcome “Primitive Obsession”, the immensely useful pattern matching to ensure you cover all edge cases and what I really found to be the killer feature: Type Providers to enable typed data wrangling in just a few lines.


It's not exactly what you're looking for, but have you checked out mypy[1]? It is basically static typing for python.

[1] https://pypi.org/project/mypy/


That's what I meant with "unless it has type hints" but thanks for the link :)

Blue ocean python I pretty much start with hints and interface definitions, the logic follows. Helps me through writing the logic when I have autocompletion of methods.


It seems type hinting is coming to Ruby 3, which im looking forward to.


I like Ruby for prototyping and quick throwaway scrips. I can write code really fast in it. Still my favorite language. But reading unfamiliar code or cooperating with others is hard. This is a good step forward in that direction.


Not in the source code itself, it will be in separate files according to Matt. If you want it in the source code you can use Sorbet today.


Sorbet syntax is like a hack bolted on... I'm not really a fan of it.


Yeah, it's limited by being a library instead of being part of the language itself.


Yeah, TS has one of the most powerful type systems I've come across, with its distributive conditional types and type narrowing logic. Recently I've been using type predicates to "dynamically" expand 'this' in specific clauses.

It's very fun to work with and allows for really safe code.


I can understand the appeal but I sometimes have to work in old code bases where you can’t simply swap things.

What I’ve done is switch whatever I work with to Hungarian Notation.

You know what the variable can hold. You can easily add a test for it. Someone that comes after will be able to know what it is.

It won’t complain, but since you know the type, you can add a quick if to validate that it is what you expect it to be.

It‘s actually working for us.


Just curious but have you tried Hegel (https://hegel.js.org/)?

I've only just started playing with it but it already feels superior to Typescript (for my needs)


Incrementally adding Sorbet to some Ruby projects has been so. good.


Same realization here, but from JavaScript to Rust. I'm still a bit more productive in JavaScript but I now regard it as technical debt to be rewritten in TypeScript/Rust as soon as possible.


What kind of systems are you developping with rust? Especially if you also do javascript? Genuinely curious as I also want to start working with some lower level languages.


If you like rust you may love ReasonML


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 for you to try it!

https://github.com/tanin47/tip


This is really cool. I had a similar idea a couple of years ago to implement something similar to this using the three finger single tap command on the trackpad that currently brings up dictionary/siri knowledge/wikipedia etc. I see you have 4-finger tap implemented with an additional app which is really cool and probably better than the 3-finger native OS way since you can highlight/copy as well as build your own menu.

Thank you for this!


Yes, I'm still working on the mouse/trackpad configuration app, which will make Tip usage really convenient.

Please leave a comment on this issue: https://github.com/tanin47/tip/issues/28

I'll notify you when the app is released to private beta.

Current progress: I'm building the setting UI for configuring mouse button and trackpad.


Very cool idea! I can immediately thing of like 5 things I could use this for.


Thank you! Please don't hesitate to open GitHub issues if you have suggestions to make your workflows more convenient.

Just curious: what are the workflows you plan to use Tip for?


Super cool. Thanks for sharing


Thank you for your comment! Any feedback/suggestion is welcome!


This is awesome.


Thank you!


Probably an unpopular opinion but... Write your own text editor.

I've been working on my own (https://github.com/alefore/edge) as a side project and using it exclusively for about six years. I don't expect it to be very usable by other people (it's very customized for my workflows, I suppose; e.g., it's mostly useful for writing C++ and Markdown files) but, because I know it inside out (and I've invested in making it easy to customize through its extension language), it's very easy for me to adjust it to behave exactly the way I want it, which allows me to lower the friction for any operations I care about (and it abides very exactly to my principles/expectations for how an editor should behave; e.g. never block the main thread/UI while executing some operation such as opening a file). Because I don't have to use but a small set of computers directly (mostly my laptop and my workstation), this works well enough.

I don't know if overall it'll save me more time than it has taken me to implement it, but I do believe it allows me to move significantly faster than if I still used Vim or Emacs (or than most of my team mates), especially because it allows me to operate at a higher semantic level than otherwise, eliminating distractions from lower level details.

... and, I guess, it has been a lot of fun to implement it (and I've probably learned a bunch). I think it has played a role for me similar to that videogames have played for some of my friends (e.g., this weekend's challenge may be to generate visualizations for the logs I keep for every interaction I have with each file I've edited; implementing stuff like that feels similar to how in the past I felt about making progress in some videogames).


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=all src/*.cc
This loads all those files, splits the screen, showing all matching files (up to a minimum area for each, with "Additional files: 498" (not shown) at the bottom), and lets me modify all files simultaneously (e.g., "search for a given regexp, make all cursors active, advance 5 words, delete to end of line, save all files, quit).

I just recorded an example of that (where I'm just renaming "OpenBuffer" to "Buffer"; you can trivially do that with Perl, but obviously you could do much more than just a simple regexp replace): https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad

These are things that even heavy Emacs/Vim users would typically do through sed/awk/perl; I see that as a limitation in their editors (since you wouldn't use the same sed/awk/perl technique if you're just going to edit a single file).

2. I've supported multiple cursors (within one buffer) natively for a while (and I use it very often; for example, searching for a regular expression just leaves a cursor in each occurrence).

I guess I'd have been able to accomplish things like this, but I'm not sure of the quality of the results. In other words, I feel that it would have to rely on putting a lot of complexity in extensions and I'd guess that it would be too brittle and difficult to maintain. There are probably extensions for these things for Vim and Emacs, but I would be slightly worried that they may not integrate very well with other features and may brittle. But I don't really know.

3. I also got fed up that these editors would block on most operations (such as when you typed ":make" in Vim or when you opened a file from a networked file system); my editor never stops responding to user commands (rather, it simply visually indicates that it is executing something; perhaps you'll see side-effects as they occur). For example, here is how "make" works (you'll see me switching back and forth; most of the time you'll see the dots next to "make" (at the bottom line) moving, reflecting make's progress; in case it helps understand what's going on, I save the file, which causes "make" to be killed and restarted): https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N

I bet you can make Vim/Emacs operate this way (compile asynchronously, overlay errors with the files (as you can see around second 0:31); be able to nest commands with a pts within them, so that you can use them as you'd use tmux/screen). I'm not sure you make them load/save files asynchronously, never blocking?

Those are the examples.

When I started I was a heavy Vim user, but I got fed up of having to edit vim syntax, which I considered a, hmm, suboptimal programming language (yes, I'm aware that there are bindings for nearly every language under the sun, but still). I considered Lisp slightly preferable (and at the time I was still somewhat enamored with Scheme; I had been contributing some ~important modules to the Chicken Scheme implementation; these days I'll go to great lengths to avoid coding in languages that make static typing difficult, mostly because I don't think I'm smart enough to use them successfully for large/complex enough projects), but I was more into Vim than into Emacs. But I felt like it ought to be possible to do better than either. I felt that they suffered from carrying a lot of assumptions that were valid in the 90s (or earlier, perhaps 70s) but no longer applied, so I wanted to see how far one could go and experiment.

For example, as the user is typing, between each keystroke, something like ... hundreds of milliseconds pass. That's an incredibly long time for a computer! However, these editors mostly just sit idly, waiting for the next keystroke, not doing anything. My philosophy is completely different: burn as much CPU as you want, as long as you can give me something useful in return (and as long as you never stop responding). In other words, do whatever you can to maximize the value for the user.

You can see an example of the type of things I mean in the prompts in the above recordings:

- In the 1st recording (https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad), around second 0:16, where I start typing a search regexp. As I type, the editor tells me things like "this would match 394 positions; in 32 buffers; and there's 2 search patterns in the search history that this matches".

- In the 2nd recording (https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N) around second 0:12, where I start typing a path (of a file to open). The editor scans the filesystem (asynchronously, obviously) and history log and tells me something like "you've typed `buffer_` so far; this matches 17 files (in all registered search paths) and 8 entries in this prompt's history".

(The key point is that all this functionality is asynchronous so it never blocks the user. If you type the next character as it is still scanning something, it just throws away those partial results (I'm somewhat simplifying; it's a bit smarter than that).)

You can probably achieve these things with extensions for Emacs/Vim, but I'd guess you'd still be somewhat limited by assumptions they make?

At the point where I'd be basically rewriting most of their source code ... I think it'd have been a significantly longer route (because I'd probably have had to care for a lot of additional things that are irrelevant to me).

Anyhow, to wrap up (sorry for the long rant!), this has been a great experience for me. I've learned a lot (e.g., I think I have more informed opinions about things like fuzz-testing, or the use of settable futures vs continuation-passing-style vs callback spaghetti) and I'm somewhat doubtful I would have been able to achieve so much through my own custom extensions for existing editors.

Thanks for asking the question. :-)


Those are some super cool screencasts, thank you for sharing! What are you showing on the right side gutter of your editor, visible at 20 seconds on https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N?

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?


Aww, thank you for your reply, I'm very flattered. I usually get very skeptical/cynical comments when I mention to my coworkers and friends that I use my own text editor, so receiving comments like yours is very encouraging.

Yeah, what you see there corresponds to the syntax tree of the file being edited. You can see it fairly clearly in this screenshot (which has the advantage of showing how this really looks in an actual terminal, without some noise from asciinema): https://raw.githubusercontent.com/alefore/edge/master/screen...

In this screenshot, the very last column is just a scrollbar. Right next to it you see a representation of a subset of the syntax tree. It is a subset because I deliberately drop from it any subtrees that don't span more than a single line.

In the recording you also see something on the right of the scrollbar. The things shown on the left of the scrollbar correspond to the lines currently shown on the screen; the parts on the right are a representation of the tree for the entire file.

The syntax parsing is a bit dumb: just just based on things like parenthesis, comments, quotes, and brackets and such, not really aware of high semantic concepts (like classes or methods). For C++ (and other C like languages such as Java) this is implemented here: https://github.com/alefore/edge/blob/master/src/cpp_parse_tr... (if it seems too complex, part of it is because I cache previous states, as an optimization, since this runs every time you type a character into the file, refreshing the tree; I want this to work with very large source files, where most of the time you type a character the vast majority of the previous outputs can be reused).

I have two other parsers, for Markdown and diff (patches). It should be easy to add more parsers, but I want to clean up the API used by them.

Anyhow, you just have to generate a representation of the syntax tree (in this structure https://github.com/alefore/edge/blob/master/src/parse_tree.h). I've been considering integrating this with clang or vscode but haven't gotten around to it.

Once you have the ParseTree, the editor will display this information about the scopes (the logic that does that is a bit complex but lives here: https://github.com/alefore/edge/blob/master/src/buffer_metad..., function DrawTree, which returns a string with the characters for a given line).

I probably gave you more information than you wanted. :-P Thanks again for your comment.


Thanks for the (very detailed) answer.


> Write your own text editor.

This is what a lot of us Emacs users do, with the advantage that we have a huge base to start from.


This has been put to the extreme by Chuck Moore [1]

> During the 1990s, he used his own CAD software to design several custom VLSI chips, including the F21 processor with a network interface. More recently, he invented colorForth and ported his VLSI design tools to it

[1] http://www.greenarraychips.com/home/about/bios.html


I'm so glad to see this comment. I recently got to the point where I created a text-viewer. Then I realized: This is the weak-sauce version of just admitting I need to write my own editor. My toolset is kind of weird conceptually so nobody else has created "my" editor yet. Haha :-) Thanks for sharing your experience.


Thank you for your response. I think most people here would disagree, but... I'd totally encourage you to go this route. It has been very fruitful for me.


This should be more generalized to "write your own tools that suit your workflow and use them, iterating on them as usual."


Writing tools, and updating your dotfiles with helpers/shortcuts is absolutely useful.

I had a small collection of useful utilities become somewhat popular on github, even though I mostly published them so I had somewhere central to install from.

These days I've been reworking them into a single binary so that I can deploy them even more easily:

https://github.com/skx/sysbox

That, coupled with my dotfiles (mostly a literate emacs config written in markdown), makes me pretty productive when moving to new systems.


A better way to put it would be "know your editor and environment"


I agree. So many times I've blamed software for not doing a thing, then _actually_ read guides and documentation and find out it's me that's the idiot, not the software Devs. Over and over again.


I can't say enough good things about a multiple clipboard manager. Not only is it useful to copy/paste multiple items in sequence, but it's a game changer to be able to quickly retrieve a code snippet, or URL, or CLI command you used recently; and/or, to trivially stash one just in case you'll want it later. (Primary downside: using a computer without multiple clipboards feels broken. What do you mean it "forgot" the thing I copied five minutes ago?)

My weapon of choice these days is LaunchBar [0]. Despite the clipboard history feature being bolted on to otherwise unrelated functionality, I love the low-friction keyboard shortcut: Cmd-\, arrow-down to the chosen item, release Cmd to automatically paste.

[0] https://obdev.at/products/launchbar/index.html


The searchable clipboard history in alfred app set to three months has been a complete game changer for me.

Pushing things that I may or may not need at some point into the clipboard has become subconcious. The type to search is a dream and can even be used without really looking.

I have no need for any actice code snippet managment/notes since anything that matters stays in the three month buffer.


Windows 10's builtin clipboard history (Win+V) is one of the best things they've added tbh

(it's opt-in, in case anyone's wondering...)


Also try Ditto. It has features I missed with the new built-in win10 tool which made be come back to it. Open source. https://ditto-cp.sourceforge.io/


Nice! I've been looking for something like this. Do you use tmux? I wonder how it works with tmux copy mode... Semi-related to this, I wish there was a way to visualize your undo/redo tree. I hate that if I want to undo a change I made 10 changes ago, I can't (at least, I don't know how to). Something like a jump list in vim.


I used to have Glipper installed in Gnome, but it looks like that's been a dead project for the better part of a decade now. Does anyone know a modern equivalent? I did enjoy having a clipboard manager

I guess one potential downside is that I use `pass` to manage passwords and I don't terribly want my passwords all stuck in my clipboard history...


I use Clipman. Simple, but does job.


Definitely agree. I've used a clipboard manager for years now, and I can't imagine going back. I always miss it when I'm not on my machine.


Yes! And please don't choose one that's too much powerful (usually means complexity) and bloated. On Windows over the decades I've tried a lot of them, and ATM, clipdiary is the best, because it does what I need (just keep a list of clip history and let me select and paste any of them handily) and not slow.


Unclutter on macOS is simple and doesn't get in the way as clipboard manager. It also has quick memo feature which I use to keep my to-do list.

These small things are part of the reasons I stick with macOS.

Not sure why in decades, Windows never have these things.


Write meaningful git commit messages, always. Even in stupid side projects that don't matter. Because then when you're at work, it will be second nature to write good messages, and your colleagues will absolutely appreciate it.

I've been following the keywords here: https://github.com/joelparkerhenderson/git_commit_message


Nice! I totally agree with this! I've used https://www.conventionalcommits.org (initially from Angular, I think) and it has _really_ made me a better programmer. Worth pointing out that it also simplified code review a lot to make PRs less of a frictionpoint.


To add to that, rebase and generally "clean" your commits before pushing them out. A repo that has no "oops, typo" type commits in it is just so much more pleasant to navigate.


It goes into full effect when you came to witness a repo full of WIP/SAVEPOINT/fix typo commit that literally kills git blame/guy bisect.


This. But I always emphasize the reasoning for doing so. I usually don't care about the git _log_, but I'm using git _blame_ very often. I want to know why exactly someone changed a piece of code, and "oh, typo" or "fix bug" don't help at all. At least include some ticket reference.


A couple others have mentioned shell tricks. One of my favorites is using Alt-. (in Bash and Zsh) to insert the last argument of the previous command. Press it multiple times and it will cycle through the last argument of all previous commands. It's great for when you want to, say, `ls thing` and then `vim thing`.

Yesterday I went looking for a similar key that would insert a copy of the last argument on the current line, like for when you want to copy or rename a file to a similar name in the same directory, as in `cp some/long/path/to/foo.txt some/long/path/to/foo2.txt`.

I couldn't find a command for this, so I made my own Zsh "widget" and bound it to Alt-/ so now I can type `cp some/long/path/to/foo.txt` and hit Alt-/ to prefill the second arg. I put the code for it up here: https://gist.github.com/dceddia/0a45a88dd61cbdf1be023d0a8f15...


One of my favorite bash tricks is that I have this alias in my bashrc file:

   function goto {
      cd -P ~/.links/"$1";
   }

And then in the `.links` folder I have symbolic links to directories I need to go to often.

Then getting to a frequently used directory is just a `goto X` away.


Ooh, that's cool. You might be interested at z[1]. It kinda fills the same purpose as your trick, except it automatically figures out what are your most used directories by tracking your shell navigation or something.

[1] https://github.com/rupa/z/wiki


Cool. How does that compare with setting CDPATH?


I just looked up CDPATH and my understanding is that the difference between the two is that with CDPATH you are setting directories that you can quickly navigate to subdirectories of.

This is more of a quick link to directories themselves.

Maybe you could do something similar to the alias if you had my `~/.links` directory in your CDPATH, but then you'd still need to add the `-P`every time to get it to follow the symbolic link.

Not something I had ever thought of before honestly.


For `cp some/long/path/to/foo.txt some/long/path/to/foo2.txt` I always liked brace expansion, for example

`cp some/long/path/to/{foo,foo2}.txt`

(Though foo{,2}.txt is even shorter)


Gonna have to try doing this, I usually cd to the source/target directory in these situations, then copy it and use cd - to get back quickly.


I think !$ will do similar, at least in bash.

(I'm on a phone and normally rely on muscle memory so it might be the wrong symbols).


Maybe I misunderstood, or it does something different in zsh, but it seems like it's inserting the command itself:

    ls foo.txt !$

    ls: ls: No such file or directory
    foo.txt


`!$` is right, though it isn't interactive like `Alt+.` is.


Yes it is, you just need to press Alt-^ to do history expansion on it.


That doesn't cycle through the previous arguments.


Correct.


Yes, I love this one! I'll check out the widget. Sounds cool! I have the same problem (it's usually changing filenames, so I just use fzf twice, then modify the second filename).

There was one bash feature along the same lines of this. It was like bringing up the previous command in a shell script, so you could modify it freely, then run it. It was useful for long command, I think. Haven't tried learning it though. Just saw a couple wizard colleagues using it, and it seemed cool.


Thanks! I didn't know about Alt-. I'm using powershell and it works there too.


I assume you're talking about only on linux? On a mac `alt .` and `alt /` are mapped to characters ≥ and ÷


Esc-. is more portable. Works on mac too.


Yea, this is what I use.


I'm on a Mac using iTerm, but I think I've tweaked some setting about meta keys somewhere in preferences.


$_ will do the same thing in bash as in "ls thing" and then "vim $_" (but only works for arguments from the last command)


I usually comment with the same thing on these tip threads. And that is learn to rebind your keyboard. Make each key programmable modifier. Open apps, run scripts/macros instantly. My Karabiner config:

https://github.com/nikitavoloboev/dotfiles/blob/master/karab...

I go as far as binding keys to instantly type `console.log()` or `fmt.Println()` or the other language equivalent with my dot modifier key. Plus typing things like `Thank you` with dot+spacebar press.

https://github.com/nikitavoloboev/dotfiles/blob/master/karab...

The other tip that paid off in time is starting a wiki. And building an interface to access contents of the wiki instantly.

Wiki: https://github.com/nikitavoloboev/knowledge

Interface: https://github.com/nikitavoloboev/alfred-my-mind


One thing I worry about with these extremely customized keyboard configs and such is that once you get used to them, you will have a hard time using any other computer when you suddenly need to. Maybe this isn't such a big problem with physical keyboards, but can be with e.g. text editor configs, which you can't take along if you need to SSH into many servers during a workday and work with whatever is installed there.


I always find this argument nonsense. Most people will be on their computer for 99% of the time and sacrificing for the rest of 1% doesn't make sense. I had a colleague who had been using vim without customization because of that reason and he's always on his computer but I find the reasoning very odd.


I have a bind to turn off all my binds if anyone else wants to use my computer.

And I can still use other people's computers although with some pain.


as a caps-to-ctrl remapper, I can't imagine how crippling it would be to have serious remaps or Dvorak or something and try to use someone else's keyboard. Doesn't seem worth it.


A buddy of mine uses dvorak with a qwerty keyboard and an inline usb switch to engage dvorak. Pair programming and everything.


I actually got used to it pretty quickly. Adapting was not hard.

It's a little like how learning more instruments doesn't make you worse at the ones you know.


Maintaining a Wiki or any sort of extensive note taking operation requires a lot of dedication and I guess practice? Do you have any tips for someone who wants to start out? Is there a smaller step that one could take initially?


I don't use a wiki but instead use Bear (https://bear.app) which gives cross-referential tags and a slick sorted tree of tags. I tag every article ('note') with a set of tags at the top.

#d/2020/05/08 #fam/sis #fam/gifts — notes around a conversation I had with my sister today about potential gifts .

#d/2020/05/05 #recipes/dinner #recipes/c/italian — notes a ravioli recipe I made on 5/5. If I later make it for a group dinner, I'll tag it, too, so I can track when I made things for who and collect longitudinal feedback and recipe changes.

#todo/today is things that need to get done today; things that don't will get moved to other notes.


In case you want to generate a graph of your notes (via graphviz for now), I wrote a project recently (I'm working on a D3 version of the graph "at the moment" although it won't happen until at least tomorrow, today is off-programming day): https://github.com/rberenguel/bear-note-graph

edit: parse error, unbalanced parentheses


Use mind maps. Its quick (much quicker than a wiki) and makes it really easy to reorganise a mess. Freemind/freeplane is good.


Holy shit... that wiki and alfred workflow is INSANE. I am so jealous. Do you find that you're able to discover what you're looking for pretty instantaneously? Any general tips for organizing (sorry if you cover this in the wiki, haven't dived into it yet, but i'm going to!)? also, huge fan of keyboard remapping. I use karabiner, kinesis advantage, and a couple kinesis foot pedals (had some rsi issues, but all this opened my mind to the possibility of experimenting with key mappings and input movements).


I cover it here https://wiki.nikitavoloboev.xyz/other/wiki-workflow

Plan to write some more things and do videos to explain my workflow & wiki setup in more detail.


Don't push a commit with a new feature without tests and documentation. Even for your personal projects.

I started doing this a couple of years ago and it's hard to overstate the positive impact this has had on my macro productivity. I can come back to a project I haven't touched in six months and instantly start productively making improvements.

Tests and documentation really are for future you.


+1, good tests are by far the biggest long-term productivity win, in my experience worth much more than any other tooling or process improvement.

Unfortunately I've gone in the opposite direction as you. I recently moved from a company that had a good automated test culture, to one that has a culture of manually testing things, often in production. Everyone, even the senior engineers who've been around for a long time, regularly lands changes that cause prod incidents.

There's actually quite a good canary/rollback system in place to deal with this, so a lot of people think everything's fine. But they don't quite realize how much more efficient things are if you can just make a change and run a test suite, and quickly have confidence that you didn't break things.


Working for Eventbrite really helped we with this. I was there for over five years and got to see the transition from ad-hoc testing and an often broken master to every commit passing the test suite for most teams.

It got to the point where I could drop in on a project by a team in another country that I'd never encountered before, read their README, checkout their code, run the tests, make a change and submit a pull request.

The big thing for me in the past couple of years has been applying the same discipline to my own personal projects and finding that even there my overall productivity improved rather than being held back by the extra work invested in testing and documentation.


Absolutely! I've come to the same realization. Just haven't figured out my effective documentation rules. Difficult to experiment with what works when the feedback loop is on the same magnitude of how long it takes you to forget (eg. 6 months). Best proxy I can come up with is "how can I communicate this to someone who has no context? What would they want to know?"


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 really concerned with myself if I am putting out so much code that I need to be concerned with my text input speed.


Your tooling isn't just about writing code, it's also about reading, analysis, debugging, research. You think about the code, have an idea, need to look up how something works, think some more, have this constant back and forth. Optimizing your environment minimizes the friction, and allows you to immediately get answers as soon as you have a thought about something, so you don't lose your train of thought.

You also want to be able to run quick experiments, same idea, get the answer to a question you're thinking about as fast as you think of it. And then once you actually know what you want to do, don't you want to have as smooth an experience executing your fait accompli? The primary focus is minimizing friction, and speed is just the observable side effect.

And then of course you can't ignore the natural human enjoyment that comes from customizing things to exactly how you like them.


I spent quite as few years as a contractor and I quickly discovered the best way to be effective was to learn how to be effective with everything in the default settings. At every new place I went I could just jump right in. No need for any time spent fiddling with settings or tweaking and installing pluggins.

Although a slight counterpoint is that I also used to have my git settings file stored in a github gist so I could just grab my latest one and every new environment would have the same set of aliases I was used to.


I donno. I use IntelliJ and when I pair-program with someone who knows how to use its features vs someone who treats it like a basic text-editor/compiler, is night and day difference.

If I am 'riding shotgun' and say stuff like "look up that definition" or "find all the implementations of that method" or "go to ABC" and they just look at me like a deer in the headlights, or start clicking through the file tree, or do "find text in project", then they are going WAY slower than they could be going.

So if "obsessively optimized" includes learning your tools, then it returns rewards.


Lines of code are the wrong metric and turning dev environments isn't going to get you to type faster. If you're happy with VS code on OS X with zero customization, more power to you :) The "obsessively optimized setup" isn't the results of a single week-long binge, which may lessen how obsessive that seems. A setting here or there, after a few years, results in a comfortable dev environment. The comfort of this environment extends the ability to make code happen.

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.


For the most part I agree with you, but it got to the point at work where I could regularly type faster than eclipse (usually some shitty background tasks messing things up but still) this actually slowed me down as well as making me angry, which is probably the way to make me least productive and ranty. Like, how can this be the case that in 2020 I can type faster than a computer displays text in a professional IDE. Jesus christ. Oooo calm. Using sublime text now and just using eclipse for the debugger. Calm. Calm.


It isn't so much the total LOC that I write (and delete) in the process of making a change so much as it is the friction and mental overhead of the change. The more I can focus on making the semantic change that I care about, the better.

Admittedly my vim setup doesn't even have YCM because I don't care enough to do it. But there are other minor things (swapping : and ; in control mode, mapping jk as <ESC>) that I've done that I hate working without now.


IIRC, the average developer output is 10 lines of code per day.


The REST Client VSCode extension[0] let's you send HTTP request from any file open in the editor. I use it to call the Cloudflare API to purge the cache of my site after I make changes. It's also really useful to test new APIs or quickly create a bunch of file/requests for the current project.

I use PHP on my landing page[1] so I can make changes and publish them immediately without any build step. This way, whenever I see something wrong with my site or have a new idea, I just open the editor, change the file, save and push all changed files through FTP to the server using the VSCode SFTP extension[2]. This means that I can instantly publish changes from VSCode without running any command, just by using shortcuts. This way I can make the changes immediately instead of having to create reminder tickets.

Automate the tasks you do often. For example, I had to download invoices from Envato every quarter, which was annoying because they don't have a button to export the PDFs of all invoices. I created a puppeteer script (headless Chrome) to download the CSV with the list of invoices, go to the URL of each of those invoices, print the file as PDF and save it into the correct folder. The automation part can also be just creating a faster build process, unit tests or even subscribing to notifications/alerts for a social site for the content you are interested instead of checking everytime if there's anything you might like.

[0]https://marketplace.visualstudio.com/items?itemName=humao.re... [1]https://usertrack.net/ [2]https://marketplace.visualstudio.com/items?itemName=liximomo...


I've just learned about this extension today from a Twitch stream. First I thought: "Nice, another great IntelliJ IDEA feature got ported to VSCode" (I think the syntax is exactly the same). But seeing the VSCode extension was first released in 2016, it looks as if JetBrains actually copied this one. Always nice to see how IDEs/editors inspire each other.


The REST client extension is so awesome, ever since I figured out how to use it I've been trying to convince everyone I know to use it instead of Postman, cURL, etc. It's just so easy to save common requests to a file and have everything in my editor.


Same for IntelliJ-based editor! It's incredibly useful to store the .http files inside git repos, an have it tracked alongside with code. It's similar to Postman or Insomnia, but tracked (and synced), and built-in


I use this too, it's great!

My usecase is that I often have queries for debugging purposes for API's that I need to send, so in my repos I keep a requests.http file for quick-access.

I also put them in repos for projects I publish (like boilerplate/demo API's) along with a screenshot and a note + link to the extension in the README because you have a working spec for API requests, and so do if/when I ever revisit it.

Tiny extension saves a ton of time and super useful.


(hi, in reference to an old thread I think you got nbomb'd on your trip)


This is awesome. I usually just have a scratch file that uses an http library (eg. requests for python) and log the response. Do you prefer this over something like postman?


Yes, I only use this now. I used postman for a while, but I remember last time I tried it, it was way too complex, had to create projects or accounts (or something like that) to make a simple request.

I now only use this VSCode extension, I have some .http files saved in my project with requests I do often. If I am trying an API online, I just copy-paste their cURL examples and run them, it's useful because on Windows there is no cURL cmd preinstalled. It's also nice that you get code highlighting by default in VSCode for the .http files.


Another big advantage is that you don't have to open a new console or application. You just do CTRL+N to open a new file and ALT+CTR+R to send the request. So you can do CTRL+N, write google.com, ALT+CTR+R and you can see the source-code of google.com in a VSCode file.

Having the request in a file means you can easily change it, save it or version it.


Only work on one task at a time.

Do small tasks immediately - reply to that email, merge from master, do that CR, etc. Delaying small tasks tends to abandon them.

Keep your workspace clean (physical & virtual).

Update docs as you use them.

Say "No" often.


Set up a "scratchpad" repo for small experiments / learning, and phrase your learning as tests.

Not only does it get you practice writing code, you have evidence that what you think is actually true. And/or you can demonstrate it's not, when you learn otherwise. And if you push it somewhere, you can link people to it trivially (great for questions / teaching / bug reports).

It's pretty much guaranteed to be faster to hop in / build / run than your day-to-day repository (often by a few orders of magnitude), and testing some things forces you to learn some new tricks (concurrency tests / bug demonstrations are particularly complex). And personally I also recommend setting up an auto-rerun-tests loop (I prefer `entr`), which gets you very nearly repl-level feedback in any language. You can interactively explore to learn basically anything in any language.


Love this idea! I generally just have scratch files in whatever codebase I'm working on, but I like the idea of having a centralized place to keep these. Any chance yours is public? I'd love to see an example of how you organized the repo, what type of stuff your testing, any boilerplate setup/tooling you used to make it more effective (mocking library to stub out things like network calls or complex objects, test runners, etc)


No, just one internal to work (which I share pretty heavily), though I should set a public one up. I've got a few bad ideas fleshed out enough to realize why they're bad, and a few multi-million-iteration things to test the fairness of go channels / cancellation strategies / etc just because it seemed like fun. But the repo has slowly grown to include things like demonstrating issues in books[1].

Boilerplate setup for me is typically:

- a one-page Makefile for laziness. I try very hard to avoid automating what I don't fully understand, and large / complex makefiles are typically inscrutable for readers. usually I just have "build", "test", and "live tests", little else.

- a small script to use `entr` to run tests in the last directory changed (the /_ arg)

- ... that's about it. maybe a .editorconfig or .envrc? I avoid lang-specific runners because they're all different and tend to have complex relationships - if you can't run your test within a second or three, find a different way. break apart dependencies to benefit from build caches. leverage make. etc.

If I wrote experiments that used networking libs, I might have common stubs, but none currently :) I'd be sorta tempted to write fakes tho (probably multi-process), and try to integrate them into tests, in part because that's often hard for no apparent good reason. Maybe I'd find out why, or maybe I'd end up with a demonstration that there isn't a good reason.

[1]: https://www.oreilly.com/catalog/errataunconfirmed.csp?isbn=0... I'm the sync.Cond.Broadcast one


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 right but you can't be sure. Just today someone on my team was trying to create a particular build on Jenkins but was using the wrong build parameters, which were copied from wiki; the previous owner of the wiki had neglected a few changes. But the script worked!


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


+1 I've been using makefiles more and more. And the nice thing is, if you don't have hidden dependencies you can just do a make -jn and get parallelism.


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.am ../migrate.sql;
    done)
  }

  function watch {
    tail -f build/app.log build/deploy/app.log
  }
Over time they'll end up with a bunch of other random things. I've tried abstracting a lot of these to their own scripts but every project proves just different enough to make that more complicated. And most of them are personalized enough that they don't go into the project itself.

Another "super power" for shell scripts is writing completion scripts (https://iridakos.com/programming/2018/03/01/bash-programmabl...). I've had some insanely useful one's do things like look up database values to mimic a large complicated third party product, going through it's UI inputting repetitive info, copying files around, etc was reduced to fake-tool<tab><tab><tab><tab>.


You may find prm useful for this purpose, it lets you create projects with start/stop scripts that get executed when you do `prm start project` or `prm stop project`. I use it to quickly switch to the right directories, open editors, services, etc. needed by a project.

1. https://github.com/EivindArvesen/prm


`direnv` will automatically activate and deactivate a project-specific shell env for you when you change directories.

I like to put scripts for the project in a `bin/` directory then use direnv to put the project's `bin/` on PATH.

I've leaned more and more towards mirroring the *nix directory structure in my projects. `etc/` and `bin/` are two top-level folders in a lot of my projects at work.


Whenever I onboard to a new codebase, or try to learn more about an open-source project, I typically create personal notes that outline the structure and high-level “markers” that I want to remember and easily reference later.

Unfortunately those notes are disconnected from the codebase itself, and therefore, not as immersive/rich as I wanted them to be. So I created a tool that allows me to annotate codebases with my own walkthroughs/breadcrumbs/ToCs and then play them back at any time, directly within my editor. This workflow has provided a pretty nice productivity boost for me thus far, and has the benefit of enabling me to share these walkthroughs with others as well: https://github.com/vsls-contrib/codetour.


I was about to ask how you got your own aka.ms link, then I saw you are a product manager at Microsoft, so that shouldn't have been too difficult :-)


RTFM (as in Read The Fine Manual).

To me, the key for being productivity is understand throughly the "tools" we use: IDE, languages, libraries, framework cli, os, shell,... Read the implementation, the docs, the issue tracker, even the git history if you have time.

When I started to learn vim, I tried many popular distribution without understand each of the plugins they included. And I almost gave up learning vim. It's until I start to read the vim manual, learn the key strokes one by one and then building my own distribution, that's when I really know how to use vim. Even so, I still learn many great things from books like Practical Vim by Drew Neil (on Tmux, there's Tmux 2: Productive Mouse-Free Development)

I think you might already know that, but still shooting here for some quick tips. I don't have any shortcut, just that motto.


> RTFM (as in Read The Fine Manual).

Some developers use alternate F-words for RTFM.

F-words like:

Fabulous or Fantastic or Friendly


Those developers should read the manual:

https://en.wikipedia.org/wiki/RTFM


Love this! I found that the more experienced I became as a dev, the more I gravitated toward the less-removed sources of truth (eg. man pages instead of stack overflow, source code instead of blog articles, etc). Haven't started reading issue trackers, but huge fan of traversing a git history (assuming it's clean and atomic).


> I still learn many great things from books like Practical Vim by Drew Neil

You should also check out "Modern Vim: Craft Your Development Environment with Vim 8 and Neovim" from the same author.


I love continuous feedback.

I set up automation in my development to run quick tools like code formatting, linting, and unit tests together.

I'll use tmux to split my terminal into an editor window on the right, and on the left, I'll have a tool like watchman or entr watching for changes to my code, and running those tools e.g.

    find . -name "*py" | entr make continuous
I also have some conventions about my tmux windows. Window 0 is where my music client lives in pane 0, and usually I'll run things like homebrew updates in other panes there.

I have a tmux keybinding that sends the "Next song" key to window zero pane zero. No matter where else I am in that terminal session, that keybinding skips to the next song.

I have another pair of tmux keys that activate/deactivate a particular openconnect vpn connection in a new pane, with a pause so i can see it complete, then it goes away. Part of my tmux status line is a single character - a C or a D, that indicates that vpn connection status as connected or disconnected.


I love entr! It's been part of literally every development environment I setup since I discovered it.

Re tmux: I have a function in my fish config (used to be zsh) that runs when I changed directories; if there is a `.tmux` script in the new directory, the function looks for a tmux session by the name of the directory, attaching if it exists, and, if it does not, creating a new session by running `.tmux`, which creates a handful of windows with my file watchers, build runners, container managers, etc etc. So all I have to do to boot up a project environment is move into the src directory, and poof — all the scripts that build source, run containers, and restart things on various config file changes get booted up immediately.


- 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 detecting movement and optical flow. Do these two images/texts/logs/terminal outputs/etc. differ? Do they differ if you ignore the hue/time stamps/pwd? Alt-tab back and forth between them and you will notice. (Beware of fancy effects or menus covering it though - it has to be an instant switch from one to the other).

- Become fluent in regular expressions (recommendation: https://regexcrossword.com/).


Oddly enough I can't use IDE's. They simply throw way too much information on the screen, and my brain gets overloaded. So I have to sheepishly confess that I do my programming in IDLE. There, I said it.

But I think a take-home lesson is that the "right" visual environment is a function of your eyes and your brain, and might not necessarily be the most sophisticated environment.


> They simply throw way too much information on the screen

You can usually just hide them. I hide everything but the file explorer, the code itself and recently I turned on line numbers but no tool bar or task bar or that distracting mini map which I feel it serves no purpose than being cool for some people.


just wondering, why idle instead of vscode with minimal extensions, or sublime text maybe?


Excellent question. Actually my cube mate uses vscode and is happy with it, and the latest incarnations of WinPython come with vscode built in. So maybe I owe it to myself.

For now, my "IDE" is Idle on one side and Stackoverflow on the other. ;-)


> - Your eyes are the only broadband connection into the brain, and they have millenia of pattern recognition training built into them.

This is also true of your ears. If you can find a way to convert what's going on into sound, you can very accurately pick up inconsistencies by ear.

(This is why you sometimes want to bring a stethoscope into the machine room.)


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.


Programming in VR Desktop: https://github.com/SimulaVR/Simula (see the README for a link to a video of it in action).

This allows you to (i) distribute your work tasks intuitively across space; (ii) completely zap out all distractions within a VR headset; (iii) completely eliminate the mouse and work 100% on a keyboard (VR Desktop allows you to click and browse with eye gaze).

It takes a bit of practice to learn the keyboard shorcuts (spawning terminals, moving windows, etc with keyboard shortcuts), but once you learn it, it can feel very immersive/productive.


This is the reason why I want a VR headset! Currently I'm a student and can't afford, however I will be doing it soon!

Question: Have you removed your screens completely and use VR 100%, or do you still have a screens? (My idea is to replace the screens completely)


I was imagining something like this for fully immersive computer work. Especially for development and research.

It can give you infinite screens.

One better idea, would be to tie in VR with some front cameras, and then overlay your windows and documents at specific spots in your room.

Like have your calendar on the wall. It becomes literally, a wall calendar.

Then a todo list on your desk. Some encyclopedias on your bookshelf. Etc.

This way, your working documents becomes grounded in your actual physical reality. And this gives you memory, of where that document was.

It’s like how my desk may be messy, but to me it’s perfectly organized. I know exactly where that receipt was placed, in that pile of papers in the far corner of the table.

Being able to recognize hand movements is also a plus, as this will make it easier to interact and manipulate your virtual objects.


What VR hardware do you use this with?


I have to admit.. I love this. Can you really _use_ it though? For long periods of work, day after day? Or is it just a gimmick?


Learning keyboard shortcuts in my most used apps has proven very effective. I used to have a bunch of cheatsheets printed but now use CheatSheet for OSX - https://mediaatelier.com/CheatSheet/ and CheatKeys when on windows - https://cheatkeys.com


In the same vein, become a faster typer. I've been using this and I can definitely see the difference:

https://www.keybr.com/


Save all bash history into a separate file. Even with a high limit, the default bash history functionality has bugs that will destroy your history now and then. With the following .bashrc settings I have commandline history going back a decade:

export HISTTIMEFORMAT='%F-%T'

PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'echo \ bash$SHELLNO $PWD "$(history 1)" >> ~/.bash_eternal_history'


As addition to this advice one can use history autocomplete tool like for example this one: https://github.com/dvorka/hstr - very useful!


Contrarian opinion, but often doing things manually rather than automated will save you time. Writing/debugging a script is fun, but more often than not it would have been faster to do things the dumb way. If a task is risky or repetitive daily, then sure, but often developers confuse "writing a script because too lazy to manually do the work" vs "get the task done as fast as possible".


Another contrarian opinion, but as much as configuring and tweaking conf files are fun, it's still faster in the long run to be highly efficient on a new system as fast as possible. It's also convenient to use standard tools to be effective on someone's else computer. For instance, it's much better if you can be productive by changing 2-3 keys in macOS settings instead of being forced to use a fancy keyboard layout and customize shortcuts for everything.


Respectfully, I've never understood this viewpoint. If the configuration options are importable from some external repository (as the vast majority of dotfiles are), "as fast as possible" simply becomes "how quickly can I install git (or my VCS of choice) and pull down my configuration options?"

For keyboards and other physical hardware, sure, you can't remap on the fly. But I'd wager the the vast majority of productivity-customizations that people implement are software-level.


As always, it depends on what you do. On your machines, sure. On customer machines, no, quickly installing a VCS and pulling some repository is often not an option.


I truly pity the developer that has to create software (a) on customer machines and (b) without VCS and pulling repositories.


It's not just creating, but also debugging, configuring, ... I'm not even sure git runs on some of the systems I work with.

And yes, some environments take a very dim view on you pulling repositories from outside their internal systems.


People should realize that any kind of system or process comes at the cost of improvisation, which is always faster and lower overhead. Doing literally anything other than doing things as they come has a cost. The gamble you're making when you write documentation, automate a test, or even write code to begin with is that the investment in doing that thing will pay dividends sometime in the future.


I only write scripts so that I'm sure that certain repetitive tasks are done correctly - this is, for me, the value proposition of automation.


Third time you do the same thing, you should probably write some script for it.


Relevant XKCD: https://xkcd.com/1205/


1. Learn a good plain text editor really well. Learn the shortcuts. Learn how to navigate text (skipping words, end/home, etc.) 2. Start using REPLs - saves a huge amount of time when trying to figure out small quips of logic. REPLs are extremely useful whether you’re an artist expert or a beginner. 3. Learn how to setup and use debugging tools. These are often a PIA to get properly working, but you’ll thank yourself later. For example I do a lot of Ruby/Rails and rspec work. Enabling byebug and leaning how to run rspec feature tests with the browser in non-headless mode can solve some really tough bugs. 4. Learn regexes (POSIX). They’re used everywhere and have pretty much identical implementations and syntax between languages; they can help you do anything from performing complex searches to parsing logs to writing your own search engines. 5. macOS: Cmd+` (backtick) lets you cycle between windows of the same application, e.g., all of your Chrome windows. This was a game changer for me. I still see a ton of people not even using alt-tab or using that awful expose crap. 6. Keeping your system “up”: Caffeine for Windows, Insomniax for macOS. One of my biggest annoyances is systems that automatically lock, sleep, or time out, wasting my time and mental energy on logging back in or waking my computer. 7. Taking more breaks and procrastinating. Yes! Procrastinating does wonders for me. Not sure why, but some of my best work is done after goofing off for hours. It’s probably counterintuitive to most of you, but surprisingly I can get more done by spending less time forcing myself to do it.


The four line documentation might help format long posts: https://news.ycombinator.com/formatdoc


Close Hacker News. Close Reddit. Close Twitter. Close Facebook.


While I suspect anyone reading this is going to detect at least a small hint of sarcasm, its true. Minimize distractions like this and unsurprisingly, productivity goes up.

My biggest one, to add, is having set time for handling administrative tasks, like Email etc. If you can (and I realize all people have caveats), just set a block of time in the morning and in the afternoon to answer email, and otherwise ignore it unless its been flagged a certain way.

This is what I do

first 30 minutes of my day, I do email catch up before my stand up. After the stand up I take about 15 minutes to update the KanBan, and then thats it for my admin tasks at that point. I may check email again (well I almost always) about half an hour before I leave for the day. The only exception is specific flags I have set and those will always notify.


While I suspect anyone reading this is going to detect at least a small hint of sarcasm, its true.

Nope, not sarcastic. The best thing I've done for my productivity in the midst of the COVID-19 pandemic has been to not read Twitter.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: