Software devs, how have you sped up your workflow?
35 comments
Using a graphical debugger compared to using naked gdb.
Using an IDE which knows how to follow references and show types.
Replacing password with keys, and placing those in an authentication agent.
Setting up shell to complete commands from history on a single button press (I'm looking at Debian, which doesn't do that).
Arranging windows across virtual desktops and switching them with keyboard shortcuts is quicker than alt-tabbing.
Keeping progress as a series of commits in git, even when just exploring. When there's a need to take a step back, just restore an earlier commit. They don't even have to work to be useful.
Taking breaks from coding to think about what should be coded and how.
Using an IDE which knows how to follow references and show types.
Replacing password with keys, and placing those in an authentication agent.
Setting up shell to complete commands from history on a single button press (I'm looking at Debian, which doesn't do that).
Arranging windows across virtual desktops and switching them with keyboard shortcuts is quicker than alt-tabbing.
Keeping progress as a series of commits in git, even when just exploring. When there's a need to take a step back, just restore an earlier commit. They don't even have to work to be useful.
Taking breaks from coding to think about what should be coded and how.
Learning the EMacs navigation key combos made getting around the terminal faster.
Learning version control made it easier to avoid many, many headaches.
Learning the key combos for whatever editor I’m using made it much faster to write, edit and manipulate code.
Learning basic bash and Unix programs like grep, awk, find and xargs made it a lot easier to write throwaway scripts to automate things that used to be tedious when done manually.
Learning how to identify the current bottleneck made it easier to focus on the most important thing.
Learning how to identify and talk about the tradeoffs I’m making made it easier to avoid rework.
Learning how to run containers, originally using docker and now podman made it easier to get whatever version of whatever program I needed quickly.
Learning how to debug and divide problem spaces made it easier to overcome problems.
Learning how to respond to incidents made it easier to get things working again.
Learning how to automate builds and deployments with CI/CD made it easier to focus on the code.
Learning how to use observability tooling made it easier to understand what normal looks like which in turn made it easier to understand when and why things weren’t normal.
Learning how to learn a new code base or tech made it easier to get up to speed when starting or joining something new.
Learning how to identify and focus on the next most important, smallest problem made it was more to produce value.
Learning how to work out what was important to stakeholders and co-workers made it easier to tailor my message and get buy in.
Learning how to mentor and coach made it easier to get things done as there were more experienced devs around me.
Learning how to trust in others made it easier to produce great things with great people and love what I’m doing.
Learning when to shut up is something I’m still figuring out.
Learning the key combos for whatever editor I’m using made it much faster to write, edit and manipulate code.
Learning basic bash and Unix programs like grep, awk, find and xargs made it a lot easier to write throwaway scripts to automate things that used to be tedious when done manually.
Learning how to identify the current bottleneck made it easier to focus on the most important thing.
Learning how to identify and talk about the tradeoffs I’m making made it easier to avoid rework.
Learning how to run containers, originally using docker and now podman made it easier to get whatever version of whatever program I needed quickly.
Learning how to debug and divide problem spaces made it easier to overcome problems.
Learning how to respond to incidents made it easier to get things working again.
Learning how to automate builds and deployments with CI/CD made it easier to focus on the code.
Learning how to use observability tooling made it easier to understand what normal looks like which in turn made it easier to understand when and why things weren’t normal.
Learning how to learn a new code base or tech made it easier to get up to speed when starting or joining something new.
Learning how to identify and focus on the next most important, smallest problem made it was more to produce value.
Learning how to work out what was important to stakeholders and co-workers made it easier to tailor my message and get buy in.
Learning how to mentor and coach made it easier to get things done as there were more experienced devs around me.
Learning how to trust in others made it easier to produce great things with great people and love what I’m doing.
Learning when to shut up is something I’m still figuring out.
[1] Dotfiles are a way to speed up your workflow. Basically just saving your system scripts to a Git repo, which allows you to manage & iterate on them easily. Also makes it easy to move environments and sync between machines etc..
[1] https://github.com/holman/dotfiles
[1] https://github.com/holman/dotfiles
I find that optimizing the butt-in-seat work has far less impact than optimizing meeting attendance. That doesn't just mean skipping worthless meetings, it means coordinating with your company to put meetings in specific blocks of time, leaving large swaths of free time for deep work.
(Easier said than done, I know.)
(Easier said than done, I know.)
Well my company goes one step further: we very rarely have meetings. People are directly responsible for the parts they work on, are expected to do what is required, and talk to the people needed to get things done. We have no time wasting micro managing middle management. It is one of the most productive companies I have ever worked for. We routinely outcompete companies 100 times our size.
Energy is a very finite resource, especially as you get older, and meetings are vampires.
I keep trying to indicate that scheduling 10:30 and 2:30 meetings basically blows out the entire day for several years now, but I've not made much progress.
I keep trying to indicate that scheduling 10:30 and 2:30 meetings basically blows out the entire day for several years now, but I've not made much progress.
I do a lot of typescript/JavaScript work. One thing I did recently was spend a day converting several older projects from webpack to esbuild. The build times were cut from 45s average to less than two seconds. This tool is insanely fast at bundling and compiling typescript.
I’m just as wary of JavaScript tooling fatigue as the next person, but I truly wish I’d swapped to esbuild sooner. It boggles my mind how much time I’ve wasted in the last few years just waiting for webpack to build.
I’m just as wary of JavaScript tooling fatigue as the next person, but I truly wish I’d swapped to esbuild sooner. It boggles my mind how much time I’ve wasted in the last few years just waiting for webpack to build.
I almost did the exact same thing today but with Vite [0]. Initial build time of a pretty large project is now 930ms instead of 20s and build time was reduced from over a minute to about 10s. Really excited to experience the performance that native ESM enable!
[0]: https://vitejs.dev
[0]: https://vitejs.dev
Do you miss anything from Webpack? My latest project is ts/tsx heavy and I've spent way more time than I'd like just keeping incremental builds under a minute, and it's not doing anything crazy in that time either.
The only thing that tripped me up was the difference between esbuild's `externals` and webpack's `externals`. In webpack you can use the externals config to skip bundling a module and instead get it from another source such as a Node module or, in my case, from a global variable in the browser. In esbuild, an external module is only for the first situation (getting a module from Node), so I was confused about how to get the desired behavior in esbuild. Luckily I found a plugin that does exactly what I want: [0].
Other than that, I'm pretty darn satisfied with what esbuild can do out of the box. I don't use any other plugins except global externals. I don't need a typescript -> javascript plugin like webpack; I don't need a css plugin like webpack; I don't need esnext transpilers or whatever. It's all just built in to esbuild.
Honestly I don't find myself missing anything from webpack. So far esbuild is just better in every way (for myself at least).
[0]: https://github.com/fal-works/esbuild-plugin-global-externals
Other than that, I'm pretty darn satisfied with what esbuild can do out of the box. I don't use any other plugins except global externals. I don't need a typescript -> javascript plugin like webpack; I don't need a css plugin like webpack; I don't need esnext transpilers or whatever. It's all just built in to esbuild.
Honestly I don't find myself missing anything from webpack. So far esbuild is just better in every way (for myself at least).
[0]: https://github.com/fal-works/esbuild-plugin-global-externals
Coding less. Building less. Trusting YAGNI but trying to build flexibly.
Discussing options more. Killing BS efforts earlier. Testing on paper, breadboarding.
Thinking more about things before I build them (see Rich Hickey’s Hammock-driven development talk)
Ultimately, slowing down and doing less.
Discussing options more. Killing BS efforts earlier. Testing on paper, breadboarding.
Thinking more about things before I build them (see Rich Hickey’s Hammock-driven development talk)
Ultimately, slowing down and doing less.
The biggest time saver I noticed is a suite of vim functions I wrote to run rspec.tests in rails projects. I can easily run a whole spec file, a specific test (via line number) and run failures with leader based commands in normal mode. Saves significant dev time and avoids the slow down of switching to the terminal and writing out the commands.
sounds useful! care to share?
When working in a Typescript/JavaScript stack the test runner WallabyJS has been a great productivity boost, as it constantly runs your tests and gives visual feedback. The debugging facilities are great too.
I also recommend TabNine - code intellisense on steroids!
I also recommend TabNine - code intellisense on steroids!
I'd say knowing your IDE well is critical to speeding up your workflow.
I managed to fix three thousand code smells on a very badly written codebase in a span on two days. Thanks IntelliJ IDEA!
I managed to fix three thousand code smells on a very badly written codebase in a span on two days. Thanks IntelliJ IDEA!
Learning to use your tools (editor, debugging, etc.) to the extent that they can help your work is the best way I can think of to build efficiency.
I see many fellow developers who stumble using their editor/IDE or who aren’t leveraging even the most basic code navigation keyboard shortcuts (let alone refactoring features) that it seems they often spend more time navigating code than they spend on actually writing it.
I see many fellow developers who stumble using their editor/IDE or who aren’t leveraging even the most basic code navigation keyboard shortcuts (let alone refactoring features) that it seems they often spend more time navigating code than they spend on actually writing it.
Be careful with premature optimization. It's a nefarious form of procrastination because it appears you're being productive. That said, I want to learn vim but I have more important things to do right now.
Are there any frameworks for avoiding premature optimisation? I'm looking for some content to share with some new teams.
There might be a good framework that I'm not aware of, I think you have a good question.
But some of it is probably not learning and setting up frameworks for stuff until a problem has become a bottleneck. Ask your customers (consumers or other business unit) what is needed right now and enable the scale that works in the short term. Don't just schedule programming time, management time, daily standup time, weekly meeting time, in your calendar and try to fill that up to look socially acceptable. The solution should follow the problem. It seems that often people forget that. After a while of using business frameworks, sometimes the frameworks prevent the problems from getting resolved rather than enable them. Maybe huge companies can't afford any downtime if the traffic spike is 500%+, but smaller companies are often changing and need some flexibility.
But some of it is probably not learning and setting up frameworks for stuff until a problem has become a bottleneck. Ask your customers (consumers or other business unit) what is needed right now and enable the scale that works in the short term. Don't just schedule programming time, management time, daily standup time, weekly meeting time, in your calendar and try to fill that up to look socially acceptable. The solution should follow the problem. It seems that often people forget that. After a while of using business frameworks, sometimes the frameworks prevent the problems from getting resolved rather than enable them. Maybe huge companies can't afford any downtime if the traffic spike is 500%+, but smaller companies are often changing and need some flexibility.
Github Copilot has been very helpful for me.
Just like you're creating shell scripts to automate things you do manually more than X times, you can create vim keybindings to do the same. I recommend using something like the "which-key" [0], so you don't have to memorise those keybindings. You press a hotkey in vim, and a window pops up with available commands.
[0] which-key exists for neovim, probably for vim as well. I think it originates from emacs, which I'm purely mentioning because I'm anticipating a response from a triggered emacs user if I don't. :)
[0] which-key exists for neovim, probably for vim as well. I think it originates from emacs, which I'm purely mentioning because I'm anticipating a response from a triggered emacs user if I don't. :)
Empty dishwasher or hang laundry when stuck on technical problem. Answer often comes far quicker this way. ;)
fzf is the single most impactful tool for productivity boosting i've used. couple it with infinite shell history and you'll be flying.
https://github.com/junegunn/fzf thanks junegunn
https://github.com/junegunn/fzf thanks junegunn
I've used autojump for years.
https://github.com/wting/autojump
It allows you to quickly navigate your filesystem via the shell by learning the directories you commonly visit/have visited.
https://github.com/wting/autojump
It allows you to quickly navigate your filesystem via the shell by learning the directories you commonly visit/have visited.
Constantly asking myself “do I really need to do that”? You should always keep the focus on what do you ultimately want to achieve with the code you are writing. Most effective developers I’ve met mercilessly cut on what they spend their time.
Setting up SSH configs and Bash aliases to enable port-forwarding to all our databases in different environments.
Running multiple microservices during local development in a separate VM (WSL) with TMux instead of running each on Visual Studio.
Running multiple microservices during local development in a separate VM (WSL) with TMux instead of running each on Visual Studio.
Simply, vim, tmux, and rust.
I code in the terminal because its easier for me.
Rust because frankly, it's tooling makes being productive easy.
Cheers
I code in the terminal because its easier for me.
Rust because frankly, it's tooling makes being productive easy.
Cheers
Examples like using fish (unix shell), writing shell scripts to automate sequential build commands I'd otherwise have to wait for, learning vim shortcuts and language syntax, implementing reusable utility scripts to produce/consume data.
Do you have recommendations/tips/examples to speed up your processes? Feel free to share even specific instances, they don't have to be as generic as above.