> I prefer coding everything by hand, because I don’t like the huge piles of garbage that the automated generators create
Once upon a time, in faraway places, "properly" was pretty much an implicit mandate. (Then, it started becoming called "OCD" even in technically oriented environments. To which, some rebutted "it's called, if anything, /benefiting from "obsessive" "compulsive" /oder//" - but history has not yet finished unfolding.)
I recalled recently in these pages the impression that could have made on some of us in formative years the aesthetic result of organizing code and data for resource use sensitive machines like the 8-bit. If you have to deal with resources that call for optimization, you produce structures, "crystals" instead of "amorphousities": that is a good school. Your product will be polished in its apparent form, and also in its internals - if the former is a form of art, the latter also will be made accordingly: that was a very good school.
Along with "If a job's worth doing, it's worth doing properly", the
knowledge that "God sees everywhere", is a snippet of Protestant
work-lore from my childhood. Why clean the above the shelf where
nobody can see? God can see it. Why paint behind the radiator? God
knows if you didn't.
Despite inevitable teenage atheism, minor deities, duly internalised
as persecutory consciences, still followed me around inspecting
various pieces of work. While never actually obsessive, it took me
another decade to shake-off the orderliness that might keep me awake
worrying if cables were not properly coiled, or wondering what
happened to that one missing screw after reassembling something.
Mostly recovered, I embrace the chaos these days. When fussing about a
job I can call it "diligence". The downside is that it tends to slow
you down. Never really held down a straight "coding" job for long,
because writing programs that work even if God turned up to check the
source code and run some unit tests is a tall order.
Like the OP, for me it's enjoyable hand crafting little things to
solve problems. Minimalism, elegance and neatness is a matter of
pride. And like the OP, my inner code fascist feels a sense of
disgust at ugly, wasteful machine generated goo that spews forth in
every modern project. Opening any modern web page is like triggering a
spring loaded jack-in-a-box filled with rotting entrails as some cruel
practical joke.
This conjures up the image of someone maintaining a bonsai tree, meticulously clipping of every errant leaf with a tiny scissors and refusing to use any other tools or fertilizer.
Much like a bonsai tree though, the code you write in this way will remain tiny and mostly useful as a talking piece. You might be able to write some tiny useful applications this way but good luck scaling it up to a team of people working on the code, or any kind of larger application.
And that's fine! There's a place for bonsai trees, and there's a place for meticulously hand written code, and both are as ornaments.
Referring to any code not written this way as "pollution" , though, comes off as extremely arrogant and turns this into another "my way is better than your way" bs article. Very disappointing.
Bonsai tree as a metaphor for microservices? It could work! Lots of little utilities that can communicate in an ultra-simple way, say just with text - hang on.
> and refusing to use any other tools or fertilizer
No, come on, it's a not a matter of being playing some sort of "puristic game": it is a matter of looking at the product and judge it.
What can be "for the benefit of scaling" when you look at the engine and it looks like a hand grenade exploded in it (which is visible e.g. in the source of a large number of web pages, to mention something quite common)? Do you remember the code which was output by early WYSIWYG web editors?
It is just a matter of quality assessment. Also, a call for low level awareness, which is good grounding; and also, a matter of manageability (again about teams), because "cleaner" facilitates "understandable".
I've always had the same mindset, which I think most pre-2000 coders share, and is likely a side effect of needing to develop within limitations. For one of many examples, early video games wouldn't have been possible without meticulously bespoke code, because the hardware limitations required extremely inventive strategies for storing and displaying graphics, compressing text used for dialogue, generating sound, etc. This was just as true for the web, even into the broadband years due to the new limitations of smart phones and mobile networks. But now that the bandwidth is massively available, we've abandoned all of those optimizations.
Though, I think post-2000 it makes more sense to take the opposite approach to optimization. Let the generators do their work, and then edit the file to remove what you don't want. It takes a fraction of the time to cut a couple lines from a generated SVG than it does to create from scratch -- even one as simple as Derek's example.
I'm somewhere in the middle on this spectrum. If I need a small SVG I'd just use optimizing exporter in Inkscape. In this example it produces file of 443 bytes, hand-written one one is 399 bytes. You have to optimize for your time as well.
I tried Inkscape to vectorize a picture of a few geometrical shapes. Fiddling with paths and adjusting dimensions to match was a pain, and I gave up any hope to have a rotated triangle measured correctly due to the sqrt(2) in it.
But Inkscape offers an XML escape hatch which is actually quit cool. I could use it to build the basics, and then use typical tools to achieve symmetries and spacing.
While the sentiment is good, I don't think that this approach scales very well. The unfortunate truth is that doing things the standard, bloated way has a lot of benefits. Speed is the obvious one. Mind share is another.
You can do your tiny bespoke thing in a vacuum, but when push comes to shove and something needs to get delivered ASAP or worked on by a team, you're better off just sticking to the most common solution.
My worst experiences in software development is stepping in to someone else's bespoke solutions to common problems. The LOC was certainly less and there were no unused parts. But wheels had been reinvented poorly, and the only ones who truly understood the intricacies was the authors.
For hobby projects and playing around, creating minimal cruft and having full control of every bit of code is really nice and fun though. And it really makes you grow as a developer.
12 comments
[ 3.5 ms ] story [ 36.9 ms ] threadOnce upon a time, in faraway places, "properly" was pretty much an implicit mandate. (Then, it started becoming called "OCD" even in technically oriented environments. To which, some rebutted "it's called, if anything, /benefiting from "obsessive" "compulsive" /oder//" - but history has not yet finished unfolding.)
I recalled recently in these pages the impression that could have made on some of us in formative years the aesthetic result of organizing code and data for resource use sensitive machines like the 8-bit. If you have to deal with resources that call for optimization, you produce structures, "crystals" instead of "amorphousities": that is a good school. Your product will be polished in its apparent form, and also in its internals - if the former is a form of art, the latter also will be made accordingly: that was a very good school.
Along with "If a job's worth doing, it's worth doing properly", the knowledge that "God sees everywhere", is a snippet of Protestant work-lore from my childhood. Why clean the above the shelf where nobody can see? God can see it. Why paint behind the radiator? God knows if you didn't.
Despite inevitable teenage atheism, minor deities, duly internalised as persecutory consciences, still followed me around inspecting various pieces of work. While never actually obsessive, it took me another decade to shake-off the orderliness that might keep me awake worrying if cables were not properly coiled, or wondering what happened to that one missing screw after reassembling something.
Mostly recovered, I embrace the chaos these days. When fussing about a job I can call it "diligence". The downside is that it tends to slow you down. Never really held down a straight "coding" job for long, because writing programs that work even if God turned up to check the source code and run some unit tests is a tall order.
Like the OP, for me it's enjoyable hand crafting little things to solve problems. Minimalism, elegance and neatness is a matter of pride. And like the OP, my inner code fascist feels a sense of disgust at ugly, wasteful machine generated goo that spews forth in every modern project. Opening any modern web page is like triggering a spring loaded jack-in-a-box filled with rotting entrails as some cruel practical joke.
Much like a bonsai tree though, the code you write in this way will remain tiny and mostly useful as a talking piece. You might be able to write some tiny useful applications this way but good luck scaling it up to a team of people working on the code, or any kind of larger application.
And that's fine! There's a place for bonsai trees, and there's a place for meticulously hand written code, and both are as ornaments.
Referring to any code not written this way as "pollution" , though, comes off as extremely arrogant and turns this into another "my way is better than your way" bs article. Very disappointing.
No, come on, it's a not a matter of being playing some sort of "puristic game": it is a matter of looking at the product and judge it.
What can be "for the benefit of scaling" when you look at the engine and it looks like a hand grenade exploded in it (which is visible e.g. in the source of a large number of web pages, to mention something quite common)? Do you remember the code which was output by early WYSIWYG web editors?
It is just a matter of quality assessment. Also, a call for low level awareness, which is good grounding; and also, a matter of manageability (again about teams), because "cleaner" facilitates "understandable".
Though, I think post-2000 it makes more sense to take the opposite approach to optimization. Let the generators do their work, and then edit the file to remove what you don't want. It takes a fraction of the time to cut a couple lines from a generated SVG than it does to create from scratch -- even one as simple as Derek's example.
But Inkscape offers an XML escape hatch which is actually quit cool. I could use it to build the basics, and then use typical tools to achieve symmetries and spacing.
You can do your tiny bespoke thing in a vacuum, but when push comes to shove and something needs to get delivered ASAP or worked on by a team, you're better off just sticking to the most common solution.
My worst experiences in software development is stepping in to someone else's bespoke solutions to common problems. The LOC was certainly less and there were no unused parts. But wheels had been reinvented poorly, and the only ones who truly understood the intricacies was the authors.
For hobby projects and playing around, creating minimal cruft and having full control of every bit of code is really nice and fun though. And it really makes you grow as a developer.