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.
the only other thing I considered setting up in OBS is to make it work with Spotify to get a great bg music.
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.
In which language do you code?
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.
With my kid, we practice drawing and eating with the non-dominant hand or try and draw something from a different orientation.
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
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.
Basically the productivity tip is to pretend you're already productive.
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.
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.
You can start by doing something you actually LIKE doing - no tricks.
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.
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.
https://www.bbc.com/worklife/article/20200121-why-procrastin...
https://www.fastcompany.com/3022830/the-secret-to-changing-y...
- 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.
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
- Implement Thing 2 from Feature 1
- Investigate Thing 3Sometimes 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.
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.
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.
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)
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).
Really the most important thing to do is just start taking notes. You can reorganize later if you need to.
# 09/05/2020
Today I mostly ate cake
## Discoveries
## Meetings
## Projects
- Worked on project 1
- Fixed issue <link>
- TODO: Bugfix #1234
## Misc
Searching is pretty much just grep.
More detail here https://blog.steve.fi/keeping_a_simple_markdown_work_log__vi...
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.
Why? I don't really have an experience of being a co-worker, but I have always appreciated such essays in free software.
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...
So the linkages for the visualizations are derived from the notes themselves?
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...
https://github.com/lloeki/dotfiles/blob/master/shell/notes
note foo # creates a note in vim
note # lists notes in vim’s netrw
It’s so dead simple that I use it all the time instead of fantasising about the perfect note system.
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.
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.
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;
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.
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.
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.
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.
And there is a useful library linked at the end: https://github.com/pirix-gh/ts-toolbelt.
It's very fun to work with and allows for really safe code.
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.
I've only just started playing with it but it already feels superior to Typescript (for my needs)
* 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!
Just curious: what are the workflows you plan to use Tip for?
Thank you for this!
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.
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).
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
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. :-)
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?
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.
This is what a lot of us Emacs users do, with the advantage that we have a huge base to start from.
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:
That, coupled with my dotfiles (mostly a literate emacs config written in markdown), makes me pretty productive when moving to new systems.
> 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
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.
(it's opt-in, in case anyone's wondering...)
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.
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...
These small things are part of the reasons I stick with macOS.
Not sure why in decades, Windows never have these things.
I've been following the keywords here: https://github.com/joelparkerhenderson/git_commit_message
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...
(I'm on a phone and normally rely on muscle memory so it might be the wrong symbols).
ls foo.txt !$
ls: ls: No such file or directory
foo.txt`cp some/long/path/to/{foo,foo2}.txt`
(Though foo{,2}.txt is even shorter)
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.
function goto {
cd -P ~/.links/"$1";
}
Then getting to a frequently used directory is just a `goto X` away.
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.
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.
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.
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.
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.
And I can still use other people's computers although with some pain.
It's a little like how learning more instruments doesn't make you worse at the ones you know.
#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.
edit: parse error, unbalanced parentheses
Plan to write some more things and do videos to explain my workflow & wiki setup in more detail.
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.
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.
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.
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.
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.
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.
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 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.
Having the request in a file means you can easily change it, save it or version it.
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.
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.
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.
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
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!
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
#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
}
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>.
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.
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.
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.
Some developers use alternate F-words for RTFM.
F-words like:
Fabulous or Fantastic or Friendly
You should also check out "Modern Vim: Craft Your Development Environment with Vim 8 and Neovim" from the same author.
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 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.
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.
- 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/).
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.
For now, my "IDE" is Idle on one side and Stackoverflow on the other. ;-)
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.
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.)
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.
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)
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.
export HISTTIMEFORMAT='%F-%T'
PROMPT_COMMAND="${PROMPT_COMMAND:+$PROMPT_COMMAND ; }"'echo \ bash$SHELLNO $PWD "$(history 1)" >> ~/.bash_eternal_history'
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.
And yes, some environments take a very dim view on you pulling repositories from outside their internal systems.
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.
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.
When I am in the zone I have an intense desire to create a beautiful masterpiece in my chosen art and revel in its elegance and beauty. When I am in the zone outside distractions are eliminated and my mind is fully focused on the task at hand. When I am truly in the zone matters such as health, family, children, work and (when I was younger) even hunger or the need to sleep disappear; all that remains is the task. My brain has maximum cycles to iterate again and again until I achieve greater understanding and/or arrive at a solution.
I do not have very good general tips on how to get in the zone. I have some things that work for me, although not always. They include:
- Real-world isolation: These days where everyone is at home, I go to a corner in my garden where my family knows not to bother me.
- Virtual-world isolation: No emails. No browsing. No notifications of any kind. Phone on silent. Absolutely no Slack, Teams, etc!
- Friction-free programming environment: If the build takes 20 minutes, then it will be hard to remain in the zone. If the Mac has stuck keys get them fixed or buy a laptop from a different brand.
- Headphones with some favorite music: For programming I like trance, the more repetitive the better. I often use this youtube channel: https://www.youtube.com/user/MrLemilica2
- Review previous work on the subject: This acts as a brain warm up for me and usually puts me in the right mood.
- Some times work better than others: When I was younger it was far easier to get in the zone at night. These days I do not have that luxury because of family.
- Work on a problem that excites you: It is much easier to get in the zone when the subject matter interests you. It is harder (although still possible) when the subject is less interesting.
- No context switching: Choose a task and stick to it for at least a few hours.
- Get the non-enjoyable tasks out of the way: (This may not work for everyone.) I like to complete tasks that I do not enjoy (e.g. administrative or legal) first. I can then continue my work care-free instead of having this niggling thought in the back of my mind: "do not forget to respond to the lawyer".
It'll provide similar benefits as writing your own text editor (which was suggested here).
It can also provide type hints and type checks for dynamically typed languages, thereby making them more like statically typed languages (also suggested in here).
Plus a good IDE will speed up searching as well as index the source code to make things click-able, thereby making large code bases or dependencies easier to navigate (also suggested in here).
So basically you can get a large chunk of the improvements that others have suggested in this thread simply by purchasing a good IDE :)
I have to say that while it was hard to get used to in the beginning, it is surprising how good VS code is. I get 80% of the featureset of jetbrains' products, for free. Specifically, all of the features you mentioned VS code does just as well when doing web dev.
The only thing I'm missing is the framework-specific automation helping you easily set up projects, builds, unit tests, and so on. VS code can automate those things, but there is more googling involved.
If this task is going to be done many times, then the automation WILL pay off. Running the automated task might take less time than the manual steps. And you can be doing something else.
The more of these kinds of tasks that you can automate, the bigger of a lever it becomes.
One of the oldest examples would be 'make'.
Also, learning, though that can be hard to justify.
Further, when that would happen, it is typically obvious that some bigger change has occurred which required the automated procedure to be updated and tested.
Some downtime is important and healthy, but it is too easy to waste hours and stay up late staring at a television.
Not a developer tip specifically, but not wasting time and sleeping well is the best way to improve your efficiency at everything.
Why MS Word, you ask?
I am ordinarily an avowed plaintext person, and I have tried everything from various wiki formats, org-mode, markdown of every shape and stripe (even bought a few markdown editors), but they haven't worked for me. The reason is lack of WYSIWIG
WYSIWIG is a huge efficiency booster. Inline images, doodles of my own, colors, fonts, tables, inline math, greek and other symbols, all of it is right there in the original (not in a separate render), and is searchable.
Having all of it in one file is not really a problem performance-wise; I have had one file for the last 8 years. It is easy to back up and the chronology is clear, and it is easy to generate a table of contents.
Finally, having it on a google drive means that it is available/convertible to google doc if I need to access it from elsewhere. I do not rely on google docs to be the primary copy, because i don't want to rely on a working internet connection all the time. Offline works better for me.
I did a quick trial run, and I love it. I'd pay for it. I tried drawing quick sketches on an iPad and pasting it, I tried latex math formulae inside tables; they worked flawlessly. The UI is gorgeous. Lists don't seem to work inside tables though, and most of the keyboard shortcuts don't work for me.
In any case, for the theme at hand, I'd still go for a word processor and a single file combo. It turns out I need more primitives to organise my writing than even typora's markdown gives me, such as colors, formatted paras or lists within tables, tab stops etc. And most importantly, Word has evolved to support really large files, since I have had basically a single diary for many many years.
That said, I will try out typora in earnest for documentation and other things.
Of the word processors, I like Apple Pages a lot, and its inline math typesetting supports LaTeX. But it didn't at one time, and I already had a ton of stuff in my Word diary.
I've worked with many programmers who don't know how to touch type. Anyone who uses a keyboard for more than an hour a day should learn to. It only takes about 2 weeks to learn all the keys, but it's a skill that'll save you thousands of hours throughout your entire career.
It completely baffles me that some developers haven't learned this basic skill. I've heard the argument that thinking is more important than typing. I counter that by saying if you learn to touch type, then it's easier to get into "flow" and your resistance to writing code drops pretty quickly.
> I've heard the argument that thinking is more important than typing
People who do not touch type are putting some of their mental energy in typing.
I believe longer contiguous periods of time developing are very helpful.
Edit: upon further reflection, I think the big difference is it's a few-hour boost in self confidence. So it's much easier to follow conversations and ask probing questions, rather than being afraid to ask things for fear of looking foolish.
https://techcommunity.microsoft.com/t5/windows-kernel-intern...
Using Zoom from Firefox.
Only bad thing is that MS doesn’t seem to realize what an incredibly useful tool they’ve built and don’t seem to be actively developing for it.
In general I find that logN is faster than solving the problem from first principles again (N!).
Here's a video by myself showing the JavaScript tools: https://youtu.be/MpFImvZrbDY
For me, the transition from Bash to Zsh has been a huge efficiency boost. Mainly because of some great plugins for Zsh, such as z, zsh-peco-history (better history search), zsh-autosuggestions, and zsh-syntax-highlighting.
My blog post about setting up a Linux workstation describes this in detail: https://tkainrad.dev/posts/setting-up-linux-workstation/#swi...
The best thing is, there is no initial productivity hit. You don't miss out on any shell features that you are accustomed to.
If you work a lot with ssh, it is also worth the effort to create a proper .ssh/config that contains the most used hosts.
scp ~/.ssh/id_rsa.pub me@[IP address]:/home/me/.ssh/authorized_keys
Make aliases for your most common commands. Someone in a similar thread posted a script for parsing your history to find them out. For me they were all git subcommands.
Write a script the second time you have to do something.
On a macro level: Don't work on doomed projects. Don't update tools in the middle of a project unless the current version is a roadblock.
scp ~/.ssh/id_rsa.pub me@[IP address]:/home/me/.ssh/authorized_keys
you can use this:
ssh-copy-id me@[IP address]
1) VIM with almost no special .vimrc
2) gnu screen (10 screens initialized via .screenrc)
- hotkeys Ctrl-Left (prev), Ctrl-Right (next)
- I tweak my $PS1 prompt so it will display which $WINDOW I'm on.
3) Not a tool, but a tip. Maintain a TODO list. I just open a text file and put some simple separators between projects I'm working simultaneously. But I go out of my way to ensure it's got everything I'm going to "DO". If I think of something, even if I'm not sure if I'll actually want to do it, I don't rely on my memory for ANY of it. If I'm not going to do it immediately I put it on my TODO list.
Unless you have 5+ years of muscle memory (learnt with pain), all the shortcuts are too confusing.
Laughing in urxvt
> Unless you have 5+ years of muscle memory (learnt with pain), all the shortcuts are too confusing.
Don't know which level of mastery of the default shortcuts you're talking about but speaking from my experience, going through vimtutor and oni[0] integrated tutorial everyday made me productive in less than one week, without modifying any .vimrc, granted I used neovim, but still...
You. Yes, you. Sit up straight. I know you aren't. Take a deep breath, belly breath. Try to let some of the tension out. There, much better :)
Also, TabNine, with a strong IDE and a good type system. The code practically writes itself. You can focus on higher level things.
Testing. Driven. Development. Once you define your goals, it's so much easier to hit them, both cybernetically and psychologically.
tabnine.com/faq
I.e. do a little writing to help avoid coding the wrong thing.
Also get comfortable with rebasing. The most foolproof formula I've found is
git rebase -i <commit hash immediately before what you want to move> [--onto <branch you want to be the new base>]
Makes reviews more pleasant and looking back through history more useful.
Also learn to use `git log -p` to look through the change history of files. Immensely more useful than `git blame`.
The only protip I have is to think through a task on paper before you start writing code. Scope it if unclear, sequence it into small chunks, do more technical design if its a complex change etc. See if you can reuse existing code/libraries to do what you need.
2. Learn emacs.
3. Learn how to use emacs in a tight code and test loop.
Now you are invincible.
Came here to say this. Having a build delay for an average incremental change (edit a single file / compilation unit) be less than 2 seconds is extremely important for my productivity. Whenever I happen to do mobile development (this goes for both Xcode and Android Studio), having to wait 5+ seconds for the app to launch makes me lose focus.
You know those tiny useful functions to "parse any date into mysql friendly format", "check if string is a email or url", etc.
I have now hundreds of such functions in two huge files for the languages I work in most and it saves me a ton of time not having to reinvent the wheel or searching stackoverflow everytime.
I see many people suggest tmux, but I have not seen suggestions for my favorite terminal emulator.
Ctrl+Shift+E for vErtical split Ctrl+Shift+O for horizontal
This is a killer feature. It is also much better than tmux because scrolling up is naturally supported.
I always keep an instance of Teminator running full screen on one monitor and whenever I need another terminal, I just split the screen, or go to the relevant already open post of the screen.
Having a visual overview of all instances of very helpful and much better than using tabs.
The other killer feature in bash is Ctrl+r.
I think Terminator gave me a real boost on productivity. The split feature is great. And it has a lot more good things, like increase/decrease/reset text size, resize/rotate/expand or even drag-and-drop splits, grouping (to write in multiple splits at once), and the scrolling is done very well: scroll up a bit to stop following the output, scroll to bottom to follow again.
While sometimes it makes sense to ask around for help on something, you should always spend 20 minutes checking the source of your favorite framework/company's library, and try to debug it yourself.
Here is why I think it makes me extremely efficient
1. I can group and nest together Emails, to-do’s, files and links that are related to the same goal, my lists are now much shorter and manageable and I can focus on my goals instead switching between gmail, todo’s etc..
2. Since my gmail Inbox is fully integrated with my to-do list, I don't need to manually and tediously maintain and synchronize them.
3. Scheduling a goal with sub-emails and tasks hide them and bring them back when I need them.This further reduces my clutter and makes sure I will not forget anything.
4. I can organize my plans and thoughts as I organize and drag inbox Emails, To-Do’s and Ideas into their related tasks.
5. Since every email has a natural place in my task hierarchy, I can quickly empty my Gmail Inbox and deal with email when dealing with their related tasks.
What made it stick for me was processing my gmail inbox (which I must do), inside my todo list, which quickly created a habit.
BTW I tried to market the solution and gave up, either most people think different or I am just a bad marketer.
If you don't use desktop switching: the basic idea is to have one desktop per task/bug/project. Lets you context-switch in a very organized manner.
If you're using them, good, but you may be surprised how many people don't!
Different strokes for different folks and all that, but, anecdotally, having been tech lead for various sized groups as well, I never saw a performance boost when people got the multiple monitors they always wanted, either.
I think part of it is that I find building a mental space of what I'm working on is the most important thing, and having tons of screen real estate acts as a replacement for that and thus goes against it, ultimately causing me to perform worse.
Also on a single monitor I do this to keep my neck and eyeballs easy.
https://news.ycombinator.com/item?id=23125617
The display size is usually good with about 24 inches. Bigger and you can't put everything within your sight which requires head movement.
My tip is to change the requirements. Requirements are often poorly written and often contain a suggested implementation. Try to find the real problem, talk to your stakeholders and alter the requirements to find the easiest implementation.
I've saved months of work several times by doing this.
My native language is Hungarian. We have 9 extra letters on the keyboard. Occupying the keys on the right side on the keyboard that used for brackets, semicolons, etc. on the US keyboard. These characters are moved to weird positions[1].
I use the English keyboard most of the time but modified it, so when I hit Caps Lock I can type Hungarian letters.
[1]: https://www.apple.com/uk/shop/product/MLA22Z/A/magic-keyboar...
It was the fasted way to use a computer I've ever experienced
yasnippets is the best for emacs.
The only other situation single-letter variable names make any sense is if you have a short function that implements a mathematical formula, like distance or something.
Alt-tab drove me nuts so I bind F2/F3/F4 to a script that will cycle through instances of these 3 programs.
F2 is terminal, F2 again is next terminal, etc.
Anywhere you want to find something, but particularly find something and do something with or to it, aliases or small scripts or plugins using fzf are great.
No specifics because I think it's a great Unix-spirited 'one thing well' and it's better to implement what works for you around it yourself, but I use it in: vim (filenames, file by contents, buffer names), password management, several git aliases for running commands with either a fuzzy found SHA or file, and more.
I was going to leave it at fzf, but as a bonus - bat. Use it in fzf previews, to see, with syntax highlighting, what you're selecting before you select it.
For any self improvement where it's equally difficult, and it's only the changing cost, do your best to change immediately.
For example it's basically identical to write, but the latter is much much more valuable code. Identical effort, more value.
log.Printf("thang blew up: %v", err)
// vs
logrus.WithError(err).Error("thang blew up")
Thus you feel deflated, the energy is gone, and finally you move to something else.
Instead, fix that stupid thing, once and for all. Get to the bottom of it, automate all the future times it would happen again, don't just hit it but hit it out of the park.
Not always, because you won't do anything else, but often.
If it’s about tools, I would suggest trying out i3 and emacs. I’ve used vim+tmux for a couple of years. Slowly I’ve migrated to Emacs. Somehow, I like it a little more than vim. I still heavily use tmux.
For tmux, having a startup script with pre configured windows and panes can be helpful as well.
Having a dual monitor setup can also be very productive.
I personally try to avoid using mouse. Most of my hacks are targeted to achieve this.
Using vimium on Chromium and vim-vixen on Firefox I always found those extensions quite limited and buggy. As I already posted here https://news.ycombinator.com/item?id=22642386
> There are a couple of annoying things with vimium which, I think, are general limitations for Firefox extensions, or browser addons in general: - it loads after the page, so if you mistakenly open a link, you have to wait until the page is fully loaded to close it with the extension, but you can always use the browser's integrated shortcut Ctrl+W. So far so good - Letters positions are not as accurate as let's say, qutebrowser, and sometimes when you open a link it's not the right one, even if the letter was indicating it. For a clear illustration of what I'm trying to say, try to browse stackoverflow and use the reviews queue. - When the page is saturated, letters start overlapping, you find yourself with one link hovered by 'A' and another 'AA' maybe a couple of links labelled: 'AB', 'AC', ... and in this situation it's impossible to select the link 'A', you have to do it with the mouse.
You'll be better off using qutebrowser instead.
I use a simple TODO file for side projects https://blog.frantic.im/all/todo-file-for-personal-projects/
That is/was a big problem with MacOS for me - I tried using alternative application switchers that displayed an icon for each window instead...
Then kinda settled in just using spaces and putting VsCode, Chrome and Iterm on the same places every time.
`rspecs alexa_api` translates to `rspec spec/services/alexa_api_service_spec.rb`
`rspecm startup` translates to `rspec spec/models/startup_spec.rb`
I also have a bunch of other shortcuts for repeating tasks like expiring Redis, dumping a test database for local testing, etc.
[Edit] - reading a bit about Double Commander I guess it's what I am actually using on Linux. Both are written in Pascal and they look the same (well, as much as they can due to inherent OS differences). Didn't paid attention when I "apt"-it to its actual name :).
``` #!/bin/sh
# Disable capslock setxkbmap -option caps:none
# Better repeat rates # Previously set in lxdm.conf (arg=/usr/bin/X -ardelay 175 -arinterval 20 xset r rate 150 75 ```
I've added another hack in there that I absolutely love for free (:
Tell us more!
Unit testing was traditionally considered impractical for embedded systems, because the code is so closely tied to the hardware. However, with proper architecture and unit test frameworks that simplify your life, it's quite feasible, and indeed enjoyable.
You write unit tests that exercise your embedded code, compiled for the PC, not the target. This ensures your code is portable.
I use the Unity/CMock/Ceedling framework when I'm writing in C, and CppUTest when I'm writing in C++.
I HIGHLY recommend the video courses taught by the guys at ThrowTheSwitch.org (the authors of Unity/CMock/Ceedling). See https://www.throwtheswitch.org/dr-surlys-school
I read and enjoyed James Grenning's book, Test Driven Development for Embedded C, but it didn't really click for me until I took the video courses mentioned above. In the second course, you code an entire simple but realistic embedded project in TDD fashion.
regex is game-changing and regex101 is a great tool for it.
take notes and save snippets so you can refer back to them.
most underrated stack for productivity is proper diet + exercise + sleep.
I use this method: https://breakpo.blogspot.com/2020/05/simple-system-to-track-...
YYYYMMDD.XXXHHII
This give a full uniqueness for the Error Code number among the team. XXX is a unique number each one of the developers in the team have.
So an error code could be: 20190412.1001643 For programmer number 100, on the 12th of April 2019 at 4:43PM
This allows me to know how old is the code, and who to blame in no time :-)
The biggest efficiency tip I've found it blocking all distracting websites via /etc/hosts when my computer wakes. Website blockers never worked perfectly for me because of edge cases. Ex: YouTube is distracting, but sometimes I want to watch a YT video, so I would disable the blocker and then forget to enable it again.
The /etc/hosts based approach with a wake script to re-add all distracting websites has worked amazingly well:
http://mikebian.co/how-to-block-distracting-websites-on-your...
It doesn't really block websites, it just pops up in the middle of the screen warning you about how much time you've spent on that particular distracting page today. But you can mark a checkbox telling it that you will be using the site productively (watching a lecture at YouTube, for instance) and assign a period of time for it.
I've tried a lot of websites blockers that didn't stick but I'm really digging the approach of this one.
Depending on time of year / weather I will either lie on a couch, pace in circles inside, or go for a walk, preferably with plants nearby, outside.
For projects I'll be working on for a while, rather than CD into a nested directory, activate a virtual envirnoment etc. I have simple bash shortcuts that perform all the steps. Also for SSHing and many other common task.
On this note, (probably doesn't apply to many here) but if you aren't lighting fast with a terminal and are dragging files around etc. you are usually doing work in a sub-optimal way. Learning bash (or some shell, I don't consider I'm an expert) a little more all the time really pays off. Likewise VIM.
Things I like to use:
- org-mode for structured note taking (debug sessions, wip tasks, architecture, rubber ducking, other team details, scratch buffer is like a giant clipboard manager, used to use notes for tracking time on tasks and starting + ending the day too but now only do if there's a crunch)
- isolated testing envs where I can test apps
- automated e2e tests via Sauce Labs + WebDriver with emails for catching regressions
- adding APM tools like email alerts when prod goes funky
- quokka + wallaby.js + personal development setup for interactive programming (yes proprietary but super helpful)
- personal scripts for automating work (little stuff like: run triage steps while debugging, control tools that have bad UIs, add git hooks so I don't do as much dumb stuff, etc.)
- using code formatting like prettier, stylelint, eslint (other teams contribute code to us so breaking their work locally saves us time in the PR later)
- pay attention to where you get stuck, optimize
- pay attention to what you burn large amounts of time on, optimize
- lots of little debugging things like look for adjacent problems after finding a new issue (9 debugging rules book is a good starter)
- thinking about Rich Hickey talks (lol)
- get unstructured time everyday to just hang out with other developers on your team and talk about issues or new tools to try out (favorite part of my work). Other people are really smart and come up with good ideas!
Things I want to get:
- source maps for all frontend scripts pulled in only for my browser, works for all envs at work
- full source code search across the company at work (large group, thousands of projects)
- automated a11y and performance tests to catch regressions early
- automating small code changes across hundreds of projects
- somehow get rid of webpack's complexity (pipe dream, yeah right)
Edit: list formatting whitespace
Reading non-fictional books can be a waste of time. IE: I've read over 40 non-fiction books in 365 because I enjoy them. This approach is not time effective because you can usually put the wisdom and knowledge of one book in 1 paragraph
Know your context and know if those advice apply to you
Displays are always in wide shape and if you maximize windows size of any app, you'll be looking to the left quite a lot.
What I do is I just narrow every window, so the left edge starts from a little bit left of the center of the display, so if I'm reading a page on a web, my neck would mostly be moving around the center of my natural facing position.
You can put other small window to the blank space at the left or put some desktop files there to be always accessible.
- learning more then a few basic hot keys for zsh (things like ctrl-k, ctrl-r and beyond)
- mastering tiling window manager, today I can switch, compose, mix and match windows in a blink of any eye - it used to take seconds
- switch to minimal OS setup, tile WM, your basic terminal tool suit, browser + the few apps you actually need (saves you trouble configuring all of that extra crap + updating it daily)
- find time to read MAN on every program you use daily, you will find lots of hidden gems in there
Note this can be painful to leave an old favorite behind.
I am not good at remembering commands particularly when you have to deal 10 different technologies (Kubernetes, Docker, Framework specific stuff) so create some standard wrapper functions as make shortcuts and document them in Readme.
Just in time compiling means, you can modifiy your programm at runtime. I had wasted so much time in the implement-compile-run-debug-repeat cicle. Just the naviagtion to the part i want to debug had me cost a lot of time. With JIT you can implement and debug at the same time. Debugging every single change and seeing the effects helped me to avoid a lot of bugs.
You are aiming for something that supports both 4K (3840x2160) [or greater I suppose] and a 60Hz refresh rate in that mode. On cheaper models this can be found on a HDMI2.0 input. More expensive ones might have DisplayPort as an option.
Shop around during TV season and you can find a quality model for $200/ea.
Like tmux in terminal, i3 for every GUI app. On a dedicated screen / workspace I run apps like browser, slack etc - and having them split the space automatically is super convenient.
10x multiplier if you're working with a team.
Now I use Spotlight/Alfred/Dash/aText instead.
https://www.youtube.com/watch?v=_o7qjN3KF8U
Please watch it. You can choose to be part of the wheat or the chaff, and if you're not hustling, what's the point?
Add this to you inputrc:
"\e[A": history-search-backward
"\e[B": history-search-forward
Now up and down arrows will search your history with whatever you already have typed at the prompt. Re-running a command often? Probably just have to type its first letter and hit up arrow once or twice.
(fyi, for others: you need not use ctrl-r, just type and press up and down)
Alt + space (terminal)
On Firefox:
Spacebar (pagedown) | Shift + spacebar (pageup) | Ctrl + tab (cycle between last recent opened tabs) | Cmd + number (go to tab of number) | Cmd + K (go to search box) | Cmd + L (go to address bar)
Use Vim and forget the mouse
(Really, use any fully extensible editor and take the time to learn it well. I'm told Vim fits the bill too; my personal experience just happens to be with Emacs.)
Yank works 90% the same, which is close enough to be useful but different enough to be annoying, daily. Repeat count is disabled by default. Transpose is broken in Xcode 10, and I heard Xcode 11 fixed it but one of my Macs can't run (the macOS required for) Xcode 11 so I'm hesitant to upgrade.
And of course if you use Firefox, they've implemented the whole GUI from scratch, and didn't bother with half of those, despite bug reports having been filed literally decades ago.
I get the feeling that Emacs keybindings on the Mac are like map/reduce in Python: it got snuck in version 1 by a fan, and the maintainers since then haven't really understood why it's there or what to do with it. I fully expect it to simply disappear one of these days.
My main one's 5k2k and I could still use more space.
Shame on you HN!
much faster than I Can type.
2. I have enabled linter autofix on safe. It fixes a lots of stuff very good fast.
3. I wrote several own extensions. One for example shows error in the code when i do some mistakes i normally do. It also boosts my speed because i dont go through the whole process of finding these errors.
4. Since i code using TypeScript and Angular i use a lots of OOP and composition to reuse easily and modify code fast. And have less errors. OOP gives great propert and method suggestions in VSC so there is less space for errors.
5. I have a lots of generators and snippets custom for my projects. So writing similar things is blazing fast.
6. I dont overcomplicate stuff. Write everything as simple as possible so it is easy to refactor and modify and understand.
7. I use bash with a menu to have complicated operations like git operations to be done easily. Without clicking with mouse. It is a boost.
8. I have written also some software in C# that operates on the TS code base. I use it to generate some more complicated stuff that includes multiple files at once. I use code comments to put for example snippet examples into Angular code. Than a C# app looks for these in whole project and generates snippets for VSC automatically.
9. An extension for VSC executes tests one by one. I can choose test to start. It is faster than start all each time.
10. CI/CD, unit testing, linting, end to end tests give a boost if done right.
11. I side from solutions that are hype but cause loads of code to be written. For example some silly state management libraries. Overkill.
12. My PC is packed with best hardware, updated regularly to be fastest as possible. Since every second you wait ia a second you waste. PC ia better because you can upgrade it cheaper than laptop. Remote access is the key if you want use laptop.
13. Good sleep and diet, sports is essential for good performance. And music.
14. I never go into the zone if i am not 100% sure what and how to do stuff. In the zone you arw blazing fast, but be careful to not write useless code because of bad approach.
15. Notes notes notes. For everything. Refactored often. JIRA as a single source of tasks. Notepad as a detail task list.
16. I adjust tasks to the time of day and my mental focus. Some easy task for first half hour, and than the big ones for the rest of the morning.
17. I have wrote a lots on keyboard to have very high speed. It saves me time writing (actually you need to use keyboard when you are a dev anyways) and less wasted time for typos.
18. All notifications off. All spam sms, emails, calls off. No distractors.
19. I never code when i am not 100% sure what and how to do it. No guessing, always asking. A lots of wasted time saved. Never being ashamed to ask even the most stupid question.
20. I always remember that things take time and not stress too much about it. Stress harms performance if too high. But also some stress can let you go into the zone. And this is magical place to be in.
I enjoy coding. Always had. For 20 years.
Each project gets its own directory somewhere in my $home with some subdirs. There might be various others specific to the project-domain, but these are the most common:
• notes/ contains plaintext files of everything i write down. File-name structure is <date-str>:<note-type>, e.g. 2020-05-09:call (:call are the most typical ones). As others have also suggested, I take a lot of notes for record keeping & plannning purposes.
• workspace/ contains all source code repositories, or other files necessary to work. Pretty much anything I might touch while coding.
• auth/ for things like ssh public keys used on the project
• downloads/ Project-specific downloads.
Then I create new entries in my ~/.bash_aliases that "get me" right into the coding-env of a project. Say I work on a python project, I might have an alias that looks sth like:
alias fb='cd ~/fooproject/workspace/foobot && echo "loading virtualenv..." && source .venv/bin/activate';
alias foh='cd ~/opendecks/workspace/foh';
alias fohj='cd ~/opendecks/workspace/foh/src/clj/opendecks/foh';
alias fohs='cd ~/opendecks/workspace/foh/src/cljs/opendecks/foh';
Lastly, I started employing chrome/chromium's user-profiles to seperate browsing for each project. This isolates work-related browsing from my personal activity (cookies, logins, passwords etc), and provides a nice cognitive barrier against procrastination. I'm not logged into any social networks on those work-profiles and switching to my private profile to browse facebook is a more concious act than opening a new tab in the current window. Each browser profile is set-up to save all downloads to the project-specific `./downloads` directory, again not to mingle (potentially confidential) resources.
I haven't automated any of the above steps, because it's so simple and takes me at most 10-15 mins to create a new instance. This has worked really well for me so far, because it clearly seperates almost all resources associated to a project, while being friction-less in tooling/switching between workspaces (versus e.g. waiting for a VM or docker instance to start). Another nice side-effect is that I can easily archive or clean-up past projects.
100 wpm when no-look-pecking, 60 wpm when no-look touch typing.
Feels weird man. xD
Also, I have a friend who used to be a court typist. Does zero coding. Borders on comically-computer-illiterate. Types like 170 wpm. So jealous. Such a gift, so wasted.
We have autocomplete for writing code that is likely more of a speed improvement than cramming out "words".
I would think it gets to a point where wpm doesn't matter since you've likely to stop and think about the logic etc.
I can see how it would help for emails and more generally.
I find that I get pretty slow speeds when doing typing tests, but most of the time it's because I need to stop every word to figure out what the heck it is wanting me to type.
When typing out my own stuff, I don't have that break because I already know what I want to say.
If you don't already have one get a good ergonomic keyboard. I recently switched to an ergodox ortholinear layout and it immediately exposed my bad typing habits. The split hand layout saves my neck and shoulders and my working posture has noticeably improved. Took about a month to get back to 80 wpm and don't feel like I've plateaued yet trying to get to 125 wpm.
I had a Judo coach who used to scream "Practice doesn't make perfect. Perfect practice makes perfect." In practice sessions focus on not making any mistakes & using only the correct fingers to strike keys. It can be hard to resist the temptation to start hammering as fast as you can in practice but slowing down once in a while can greatly improve muscle memory.
I use https://www.keybr.com/ to track stats, practice limited or different key sets, it also supports non qwerty layouts for stretching your comfort zone. For touch typing practice it displays a real-time keylogger map so you can auto-correct your finger positioning without looking at the keyboard, if you've got a fancy keyboard (Shout out Arts and Crafts HN) you can hook up the firmware to do the same.
Slow is smooth, smooth is fast.
> Instead, Keybr.com generates random, but readable and pronounceable words using the phonetic rules of your native language. These words look almost natural, and often they really are. Typing sensible text is much easier than repeating random letters, and it helps you to remember frequent key combinations. The latest point is very important.
Also, it's something that's hard to appreciate the value of until you experience just how big a different it can make.
Strong typing skills also form a good foundation for learning Vim and other editor/stystem wide shortcuts, which can make the whole experience of interfacing with the computer an order of magnitude more efficient and enjoyable.
Fewer distractions means more uninterrupted thinkning time and better code.
Did one test for this comment. https://imgur.com/a/GISaU6n
You must know that average touch typing speed is 40 wpm, professional is 75 wpm, therefore you have nothing to gain by optimizing further. Especially since bragging about doing it the hard way lets you seem like you'd be even faster if you tried.
For me the main reason I value touch typing so highly is due to the reduction in cognitive load. I think things and they appear on the screen without any conscious thought. I honestly couldn’t tell you what fingers I’d just used to type the words.
The benefit of touch-typing is being able to get your thoughts into the computer without interrupting said thoughts to figure out where stuff is on the keyboard. Keeps the flow going.
I ended up tracing my pain to lazy technique in my right hand. Sorted that out and I’ve been pain free for years. It was _no fun _ before I figured it out.
It makes a massive difference in comfort. 5 minutes typing at full speed on QWERTY and my wrists start to hurt. (I really don't know how people do it.) On Dvorak, I can type all day at full speed with no pain at all. Surprisingly, the keyboard hardware itself doesn't seem to matter.
(Details: I mostly use a Mac, with caps lock mapped to control, NSRepeatCountBinding set to ^u, and -- obviously? -- I rarely touch the arrow keys.)
Wrist-bending to maintain the home row, I suspect. I have a different, self-taught style that partially involves holding my hands above the keyboard and using muscles all along my arms to move my hands without bending my wrists much - never had any problems.
Wrist discomfort with QWERTY completely disappeared upon switching to Dvorak.
I do always change one thing, and recommend it for others too, is to change caps-lock into a control.
http://steve-yegge.blogspot.com/2008/09/programmings-dirties...
My version of this would be learn not to use a mouse.
And I secretly judge people on their typing skills as well, especially programmers.
Typescript: you don't need to remember the arguments of a function or return types. Easy to refactor. Just no brainier. I also use it for all my config like webpack config with ts-node or ts-node-dev for auto reload.
Auto format all your code with 1 command. Prettier or lint fix. But that's basic.
Don't ever write global css. Use emotionjs or styled components. Scoped css it's a delight.
If you notice all my tips helps you to reuse the code you write. Therefore write less code, more efficient.
Plan all your stories ahead. Then do one at the time. Then mark it done. Prioritize.
> Don't ever write global css.
Global CSS is a form of code reuse.
That isn't to say, write code fast, even if its garbage. Good clean code is still a virtue. I feel like sometimes people conflate the two. So to add on, don't do that!
With that said, I don't usually invest time on new stuff unless it looks absolutely convincing.