Enough to be afraid of subjectively beautiful decisions in the code – you are not robots
I have a strange habit. When I finish the module, for a few minutes I just look at the fresh code and rejoice that it is beautiful. I know very well that code is a functional thing. He must perform the task well, be convenient to maintain, and that’s all. But I have an inner conviction —— the code must be beautiful. Not only a beautiful solution – but aesthetically beautiful.
For me, this is manifested in everything. I’ve been setting up the IDE for a very long time, looking for the right font, highlight, interface color, I can spend hours sitting on the code style settings so that the code aligns and builds nicely for my eyes. Visual beauty smoothly flows into functional beauty – I try to build dsl, use such class and function naming conventions to make the code seem super idiomatic and relevant here. I can change the api of my service at the design stage purely for the sake of visual beauty. I can pick and hit select / map / fold instead of a more for performance cycle – simply because with a functional approach, I am more beautiful.
And I hate programming languages with ugly syntax like go or pascal. Once upon a time I bought functional programming just because the code in F # seemed to me more beautiful than the code in C #. I studied it, used it in pet projects, used it commercially for about six months, and returned to my native C #. Now I am intelligent enough not to shove persistence and functionalism everywhere, but I am very glad that I studied these approaches. And I’m very glad that I admitted to myself – in FP I like beautifulness and elegance, and not some real benefits.
In general, all sorts of nonsense often flashes into my head – like why drink water if you have coffee or cola, or that I hate all the songs where the piano sounds. I remember that I am a big idiot, but I think the aesthetics of the code does not apply here.
The code has more tasks than just solving a business case. The code needs to be supported, read, modified, it must be understandable, scalable, flexible – and much more. The more you think, the more quality parameters you will find. We engineers are inclined to stop mental recursion at such moments, and to carry nonsense in style – “In fact, everything is simple. If the code solves the business problem and does not create problems, it is good.” No, it’s not at all simple. Nothing is easy in programming.
All these code parameters exist, affect the quality of work and people’s lives, and, most importantly, often contradict each other. We can measure things like performance or performance almost objectively.
But there are objective things that we cannot measure with metrics – and we consider them subjective. Readability, elegance and beauty of the code, compliance of its architecture with all requirements. My engineering mind – and not only mine – is not ready to accept that engineering work can be completely subjective creativity. Therefore, we came up with patterns, approaches, practices and guidelines. In fact, they are also very subjective, but they are good because they have shown in practice that one can work with subjectivity. Not perfect – but the code is written, it is modified, and no one dies.
Subjective issues of the sea. How to structure the code, how to name entities, how to align parameters in methods, how to name a parameter and a field if they mean the same thing, is it worth splitting one file into two just because you don’t want to have bloated files, should you use recursion instead of a loop just because she is sleeker.
The problem is that often I don’t have time to sit and spend hours counting in which place the allocation of a sub-method is an implementation of the principle of a single obligation, and in which – an overhead. If I have a ten-step conditional loop in a small function, it doesn’t really matter if I make a hand or use the functional map. Well, because, alo, ten steps, what a performance. I do such things intuitively. And if another person writes my code, he will do it differently.
Here comes the feeling of a great concrete developer. All the dilemmas in the code, when the problem is already solved, and the functional requirements are met, I solve on my engineering chuyke. Roughly speaking, when the code has already been written and works, and the architecture of my edits is tolerable enough to send a pull request – I just take it and start making the code beautiful. I’m doing it half subconsciously, and therefore it’s important for me that the IDE draws it beautifully, the favorite music plays in the headphones, and I was maximally tuned to work with the code.
Understand correctly, I am working on large projects. In many of them, all sorts of readability is a key indicator of code. It happens that I bring in five thousand lines of code at once, and there’s a straightforward budget to calculate everything, compile tablets and discuss each line with my colleagues – well, just not. A quick glance, and understand beautifully or ugly, you can.
I have a feeling that code that works well should be beautiful. Like airplanes, guitars, or weapons — things in which the beauty of forms is generated by functional qualities. I find the code out of such pieces. You can write beautiful, but bad code, but you cannot write good, but ugly code.
I follow this idea when I do not have the resources to rely on metrics, and when well-known practices do not answer my questions. I rely on a sense of beauty when the teams and I develop a code style for the project. And I think that subconsciously – or not – all engineers do that. But do not talk about it.
Therefore, I urge you to understand and finally accept the idea that we live in a world where not everything can be counted and described in logical tablets, and not everything can be developed a clear decision algorithm. And agree that this is not so scary.
Your sense of beauty regarding code is shaped by your experience, and there is much more work to your brain than it seems to be behind it. Do not send him in the ass. When the inner voice requires you to change the formatting of the brackets in your project – listen to it. Perhaps he knows a lot more than you.