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.
It takes some time to get used to, but systems that support image-based development, in the tradition of the Smalltalks and some Lisps, can boost programming productivity a lot, by allowing very tight feedback loops. Combined with a good debugger it makes much easier to diagnose and recover from problems, and iterate over your design quickly. To experience the state of the art on this front, I recommend Pharo. There's even a MOOC at https://mooc.pharo.org/
Pharo is more of a research experiment than anything practical than can be used to engineer complex systems, I know I tried. It comes with many flaws, first and foremost being a lack of vision (often seen in academia) that significantly holds back its potential. When it comes to Smalltalk, I find Squeak to be a far more grounded and coherent experience.
As far as state of the art in image-based development goes, that is without a doubt, still Symbolics Genera. It's depressing to realize that after all these decades, we still haven't reached this pinnacle.
Emacs (with Emacs Lisp or Common Lisp) comes the closest but is still a long way off.
> Pharo is more of a research experiment than anything practical than can be used to engineer complex systems, I know I tried. It comes with many flaws, first and foremost being a lack of vision (often seen in academia) that significantly holds back its potential. When it comes to Smalltalk, I find Squeak to be a far more grounded and coherent experience.
After spending a lot of time working in both systems, I unfortunately have to agree with this. However, the GToolkit folks (built atop Pharo) do have a pretty coherent vision and their systems shows it.
The biggest problem with Squeak, to my mind, is that not enough people are working on it. They are simply shorthanded. Even now there is a VM optimization ready to go that would improve performance 3x (SISTA), but it just needs a couple of months' work from what I understand. Vector graphics is another area where there could be worthwhile improvements. Juan Vuletich seems to be making the most headway there all on his lonesome, and while he's made a VM plugin, his work is really only for Cuis Smalltalk and not Squeak.
Still, I've tried to push more and more of my routine work into these environments because I want my computer to be more like them and less like a Unix-with-lipstick.
I'm not sure if it's a method, but understanding what bottlenecks are involved in your development cycle is key to anything involving efficiency. Just like early optimization of software it's very easy to add a step on a complicated system only to find out it wasn't very effective because there wasn't a problem there to be solved.
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.
OpenAPI: while it's got tons of warts and is mostly useful for deterministic REST-ish looking APIs, it's the best think I've found so far to specify APIs. If the APIs are well expressed and maintained there tend to be a lot of positive side effects.
- 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
The important part for me is to make sure everyone understands _what_ needs to get done, not necessarily prescribe _how_ to do it.
But I agree it can be fuzzy. Generally I want folks to be aligned and super clear on what we're trying to do, because if everyone understands it differently, we're all pulling in different directions.
There are so many, but there are three in particular that in my experience are most important and weirdly lacking in a number of organisations:
- 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.
Why would anyone downvote this? A good answer to this question in my opinion. Copilot has had a great impact on my efficiency, often for things I didn't even realize were time sinks.
Co-pilot is useful for mainstream languages/frameworks like PHP/Laravel, Python/Django but becomes less and less useful or effectively suggestive with less mainstream ones like Elixir/Phoenix.
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 production (not only consumer) side of the greater web.
I do not disagree. In fact, going outside the context of tech, sometimes democratizing inventions for the lay people is great in one area, and terrible in other perspectives. One example could be the invention of the automobile which - at least in the U.S. - empowered so many people (and commerce), but it also enabled folks to do very foolish things...to the detriment of so many, many auto-related deaths every year. So, back to technology...yes, i like me some PHP, but it is not lost on me that in the hands of the less qualified (or maybe folks who know, but simply do not care), there could be significant (and widespread) downsides. ;-)
Oh yeah, i agree that making PHP or other platforms more widely available helps them get more adopted. But i would have to guess that web hosting providers either were responding to customers requests to run PHP (because said customers felt they could do more), or these providers believed that php was good enough to offer to their customers because it empowered their customers but was not too much of headache to support. I say "not too much" because as noted, php has its warts. But even still if i put my business hat on, i would guess that a business would not purposefully make a platform available that is so bad which would create more work - hence tech support - that it would lessen or do away with any profit margin. In other words, if php were really that bad, web host companies - especially the low cost ones - would definitely not provide such a service because the constant tech support work would kill their profit margins...Full disclosure: i have never been a web host provider company (other than, small amounts of work in setting up web environments for my consulting clients)...so only someone in that industry could confirm/deny my theory.
As a former small-time webhoster, I ran PHP because it was the easiest to run, but that doesn't mean it was the best app platform or the easiest to develop with. Making Ruby or Python or Java hosting was out of reach back then (without Docker and other niceties of today).
Deploying changes to a server with python tends to be more involved than just plonking a file via ftp. Even best-case, you usually have to restart a process or something (gunicorn).
In the sense that subsequent requests will see the changed code, yes (unless byte code cache is involved).
OP is likely referring to the mod_php convention of directly executing PHP scripts by filename/URL while Python/WSGI needs a single entry point. Your directory structure becomes your routing logic.
I use Python, but miss being able to just a .php file in a dir and have it work.
Now to make some small site, I instead end up setting up some WSGI server and doing nginx config to get it visible, upstart config to make it start at boot, and then invariably forget how it’s set up after a few months pass.
Otherwise I agree with all your point. It basically kept things simple while every other web development language increase their complexity by 10 to 100x.
Kinds of, yes. And the dollar sign is especially programatic for me as I read lots of financial reports and statements. Part of the reason I dont like Perl as well.
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.
I would disagree. Just like an airplane copilot, GitHub Copilot really shines in rote work: when it can correctly infer what you are about to do, it can and will assist you correctly. It’s not able to make big decisions, but in a pinch, it might be able to give hints.
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.
I like to think of the Django Admin framework as a developer superpower. I have built whole apps just with it, no need to build your own views. Perfect for internal tools.
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.
Time-travel decision like rr and Pernosco. I’ve heard firsthand stories from developers that found and fixed rare race condition bugs in minutes instead of hours or days. https://pernos.co/
Encouraging people -- and myself! -- to take walks and ponder, rest and get a little distance from the work. There's nothing quite so handy for understanding something as letting your mind work on it in the background while you take the air.
86 comments
[ 3.7 ms ] story [ 166 ms ] threadNot 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.
This would be worth it even if they never caught anything else or improved the quality of the code.
To be able to make a decision once as a team and have it be a non-argument going forward: such a gift.
Type checks also catches a lot of run-time errors.
And read The Pragmatic Programmer (which may be in need of a newer edition).
+1 on CI & automated tests BTW.
As far as state of the art in image-based development goes, that is without a doubt, still Symbolics Genera. It's depressing to realize that after all these decades, we still haven't reached this pinnacle.
Emacs (with Emacs Lisp or Common Lisp) comes the closest but is still a long way off.
After spending a lot of time working in both systems, I unfortunately have to agree with this. However, the GToolkit folks (built atop Pharo) do have a pretty coherent vision and their systems shows it.
The biggest problem with Squeak, to my mind, is that not enough people are working on it. They are simply shorthanded. Even now there is a VM optimization ready to go that would improve performance 3x (SISTA), but it just needs a couple of months' work from what I understand. Vector graphics is another area where there could be worthwhile improvements. Juan Vuletich seems to be making the most headway there all on his lonesome, and while he's made a VM plugin, his work is really only for Cuis Smalltalk and not Squeak.
Still, I've tried to push more and more of my routine work into these environments because I want my computer to be more like them and less like a Unix-with-lipstick.
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 had to fix the same issues 3 times last year. We could've finished MONTHS earlier.
- 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
But I agree it can be fuzzy. Generally I want folks to be aligned and super clear on what we're trying to do, because if everyone understands it differently, we're all pulling in different directions.
Automatic test runners, Hot-reloading, Incremental compilers, Static typing, Build farms (when working with massive code bases), Compiler caching: ccache, sccache
- 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.
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.
OP is likely referring to the mod_php convention of directly executing PHP scripts by filename/URL while Python/WSGI needs a single entry point. Your directory structure becomes your routing logic.
Now to make some small site, I instead end up setting up some WSGI server and doing nginx config to get it visible, upstart config to make it start at boot, and then invariably forget how it’s set up after a few months pass.
Otherwise I agree with all your point. It basically kept things simple while every other web development language increase their complexity by 10 to 100x.
Because PHP is basically C with dollar sign $variables.
Kinds of, yes. And the dollar sign is especially programatic for me as I read lots of financial reports and statements. Part of the reason I dont like Perl as well.
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.
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.
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.
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.