51–60 of 87 posts
I believe the quality of the build process greatly affects the quality of the code it produces.
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.
Earlier quoted context omitted.
100% THIS! There is a reason so many products and platforms - like WordPress, which powers so many blogs on the internet - were built leveraging PHP: productivity/getting stuff done! I would add that i'm not only implying that conventional developers gain productivity...but that also that PHP empowered - yes empowered - folks who may not be "real" developers, and gave them a tool/platform to participate on the produc…
There’s also a reason a ton of those applications built on php are terrible to use and get crushed under their own weight.
Coax all team members into getting proper sleep, exercise, nutrition, & potentially amphetamines.
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" ..
Long, self-documenting variable names. 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.
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
I think automatic code formatters have huge impact. 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.
Never had a conversation about formatting afterwards.
After using copilot - that’s not it (yet). 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…
In short: Write your class methods or functions headers-first and then start working on the bodies. Add step-by-step comments to a body before starting to add code. These are, of course, good habits to foster even without Copilot.
Copilot will pick up what you do in the first method/function/whatever structure and suggest adapted completions for the rest.
In general, when there are multiple similar things to write, name your cases, then write one of them in detail, move to the next empty one and watch magic happen.
If used right, Copilot can give developers a significant velocity boost, especially in greenfield projects where there is lots and lots of boilerplate to write.
It is still a ”copilot” though so keep an eye on it, lots of ”wtf is that guy doing” moments ahead for sure.