Not just to save time on manually formatting code, they also flag syntax errors; if it doesn’t format on save you know something is wrong.
In team context they take away all bike shedding about formatting. Code reviews can focus more on stuff that matters, not just silly formatting tweaks.
To me a good formatter is as essential as autocomplete.
Automatic test runners, Hot-reloading, Incremental compilers, Static typing, Build farms (when working with massive code bases), Compiler caching: ccache, sccache
For all the hate PHP gets, a massive positive of it is entire classes of development friction that just doesn’t exist for it.
COMPILE: Slow compile times, nope - it’s interrupted & you can run the code instantly.
DEVELOPMENT: Confusing and complex development tooling or middleware, nope - just SFTP a single file to your webroot.
So the language / environment you pick to develop in can has massive impact on productivity.
- Type checking (and particularly modern type systems) can remove entire classes of error – often reducing the long-term maintenance cost of code substantially at the cost of (sometimes) slowing down initial development.
- Automatic and enforced code formatting and linting eliminates almost all bikeshedding and feedback loops around formatting and code style, and is an observable efficiency improvement.
- Continuous integration without a doubt. Build every source control push or PR into an artefact that's ready to deploy, along with validation and automated testing. Basically remove all manual processes from every system to the fullest extent possible.
Also, can't stress enough – fix anything that irritates you as soon as you can. Is your IDE failing to resolve some types properly? Fix it. Annoyingly long debug build times? Flaky tests? Stupid manual environment setup scripts? Fix them – you almost always fail to realise how much stress these things are causing you until they are gone.
And read The Pragmatic Programmer (which may be in need of a newer edition).
- Having a dedicated Quality team
- Ensuring everyone is on the same page, from the lowest level (coding standards) to mid level (discussing tasks before implementing them) to meta level (principles for development, building culture)
- Rewarding bold moves and experiments, giving people freedom to be creative
- Leveraging the wisdom of the Open Source community
Noticing something broke in a place you didn't expect before it appears in production ends up being a massive time saver and anxiety reducer.
Good tests seem tricky, since you want a combination of flexibility and rigidity, which can be a tricky balancer, but well worth it if done right.
The most useful completions would also be done by an IDE. Especially in statically typed languages.
The borderline useful of the completions, you spend a lot of energy scanning a seemingly ingenious solution for bugs. And usually there’s enough one or two deceptively silly bugs that I wish I had just written the code.
The rest are silly and entertaining completions. Honestly the LOLz from these completions are the reason I still use copilot.
Language choice. I happen to fancy Common Lisp but any language with a good REPL experience works. I like to play with small bits of code interactively in a REPL and when things works copy to a source file. Tools like Slime also help.
Python with the old Emacs Python bindings works well because you can load an entire source file and then re-evaluate individual function definitions as you modify them. This may seem similar to what you can do in a Jupiter notebook but I find Emacs + Python bindings better.
Haskell also lends itself to REPL driven development.
* I think that the daily standup is great! Preferably virtual/slack, if you are consistent it will help remove roadblocks and people chasing rabbits down holes (that is, getting stumped and not making progress).
* Clear quarterly goals and monthly meetings with external stakeholders have been helpful to me in the past. This was for smaller teams, but it's fantastic to make sure that you aren't efficiently developing the wrong software.
* CI and automated tests were truly a lifesaver when I built a startup codebase from scratch and they're helpful now (at a different company) in preventing regressions. It's painful to introduce TDD or automated tests if you don't have them, but I promise you, when that regression is caught in CI 6 months from now, you'll be happy you paid the price.
For me it's Scrum. Every two weeks we have a full-day meeting with the entire team. In addition, every Thursday and Friday we have a meeting mid-morning of "analysis" (whole team) which means I can't get anything significant done beforehand, nor afterwards in the morning. That only leaves the afternoon, and I'm sort of a morning person, so most Thurs/Fri afternoons I don't get anything done either. I do want to get a lot done, but the company gets in my way, so what am I to do, I have to accept it.
Because someone else will eventually have to debug or rework your code. And that might even be you, six months from now after you've forgotten everything.
It's relatively cheap and cross platform compatible.
It's hard to describe in a way that sounds compelling, but once you've experienced it, it's profoundly faster and (therefore?) more joyous than any other dev experience I've had.
* Cider / SLIME for me.
- Focused on utility classes and clean code
- Is extensible with your own templates
- Local config, not service based so everything is version controlled and always available for all members of your team
- Framework agnostic, but configurable for utility classes (currently bootstrap) with any framework that produces HTML
Visually building and sites is a game changer for me as I can save a ton of time dragging templates onto pages while making small adjustments with the utility class editor. To give it a try, you can download the repo, npm i, and npm run dev. I'd love some feedback on UX!
You need a way to evaluate efficiency and trends of your development cycle. Are you creating more tasks than are done? Are there too many bugs being created? Is the layout design often late and blocking your developers? Ask yourself how would you know about these things and if you don't have an answer or it takes a while to get the answer then that's where you should focus your improvements: optimizing your understanding of what is going on your value stream.
I believe the quality of the build process greatly affects the quality of the code it produces.
I had to fix the same issues 3 times last year. We could've finished MONTHS earlier.
Embrace using open source not reinventing the wheel, hopefully you are already standing on the shoulders of giants
Practise extreme programming. Test driven. Pairing. Trunk based development. Stop using PRs... that's a controversial one - pair instead
Continuously integrate and deploy.
Now optimise that loop. How long does it take a pair to get a commit on mainline. How long does it take for that commit to be live. If the commit had a bug how long does it take to revert and have the fix go live.
Write tests first. TDD. Otherwise all of the above is for nothing and you'll have very quickly developed a big pile of something that doesn't do what you want it to do
CI/CD shortens how long it takes to see your code running in a production-like environment.
A good type system and a good test suite help catch bugs before the program is actually run.
Short compile times (or an interpreter), hot code reloading, a good debugger, all help to see the impact of your changes faster. Even autocompletion or an efficient editor like Vim relate to getting your code done and running faster.
It all comes down to fast feedback. Reducing friction is also nice, e.g. PHP is really easy to get started, but not as important as the fast feedback IMO.
TypeScript
Next.js
Investing deeply into making the build run as fast as possible
Preview deployments per branch (or preview releases of binaries for CLIs)
Integration tests that actually test how users use the product, rather than implementation details
2. Git, mercurial, bazaar. Dvcs.
3. Code formatters, static analysis
4. Cloud services. No talking to sales to get another server.
When you can write code, send it to a repl from your IDE and see the results inline with the code is a game changer.
e.g. somelist.map( function whatever) dying when somelist is undefined/null, vs smartermap( somelist, function whatever ) that returns empty list if somelist isn't there
or easy autocomplete of names of things
etc.
but.. the problem is, one has to be somewhat "enlightened" (or burned) to use the above in a disciplined way, instead of the seemingly easier "let me type/invent it" ..