Good point - I'm of a similar age, also voted maintainability, although that hasn't changed much over the years ... I was "lucky" to feel the pain of virtually unmaintainable code very early in my career :(
Sombody in this survey said that voting maintenance priorices developers over users but I do not agree. I do not optimize for speed, memory consumption, etc. blindly. Those have to be optimized to the needed point. The user is the real looser if the App is unmaintenable.
And speed, that's what it is all about - Especially for my current project (Implementation of RFC 5424 using Qt) - On the embedded machine are only 2 GB RAM available, and therefore is saving memory and having no leaks is very essential. Also the execution speed needs to be fast, the Logger should not brake the application speed.
You can do some awfully "clever" one-line stuff, tweaks and frigs, etc ... but if I think I might question why I've done something when I come back to it 6-12 months later (or in my current situation 15 years later ... oh yes!), or I think that I could be dropping some poor jobbing maintenance proggie in deep smelly stuff (oh, that will be me ... 15 years later), I will "optimise" for clarity every time.
P.S. The "15 years later" ... nope, not still in that same old job ... came back as a contractor after a LONG time away. Be warned my brothers and sisters, be warned
write your code so that in 5 years when you working somewhere else the next guy can read, understand and support your work. that developer will appreciate it just as much you would appreciate it if the developer 5 years ago wrote his code the same way for you.
Nowadays, I'm mostly working with having our website fetch and present data to our field staff. Bandwidth is a frequent gripe -- anyone who has had to use a hotel Wi-Fi knows what I mean -- so balancing page bloat with how often a user has to ask for more data is an ongoing concern.
Counting lines already did not work so well with macro assemblers, much less with a modern language. A thousand lines with simple instructions may execute faster than a single line that calls the function KillAllPerformance().
It's like determining the speed of a car by measuring its height and multiplying it by the circumference of its wheels.
I have seen cases where there was a single function call in the framework to read a csv file into a table but the developer read the file line by line, split the line on the comma character and then created individual rows and then added them to a table
Fewer lines of code are only a good metric for performance in scripting languages where you say "1 line of code = 1 statement". Here the reason is that most scripting languages scale with the number of statements, since the interpreter takes the most time (much more than the individual statements).
Otherwise your argument is no true in a lot of occasions for compiled languages either. Examples of performance optimizations that always result in more lines of code are loop unrolling, using special vector instructions, manual synchronization, ...
I am mainly PLC-Programmer so I have to be very carefull with the amount of memory that I use and the speed of the process since both are limited for me in most of the projects.
My actual main project is something I have been from the very beginning. We are handling 35% to 40% more data than another line programed 2 years ago by other guy. With exactly the same hardware my project is consuming 20% less memory and executing around 400% faster than the other line. Main difference between styles is: Object-Intances versus Reference & Pointers.
New generation of PLCs is seeing seing the light since some time ago, they are supposed to be the panacea of place and speed, but since I have any of them in my hands yet...
I try to do my code paying attention to flexibility and reusability as well. And at least but not last, maintenance: clean and easy sources are very important for me as well (see poll of the last week) and not only thinking on other programmers. If I have to modify something of my own code in a year or two I want to be able to understand my current way of thinking and not to stare at my own function as... what the hell was I thinking when I did that?
But the first and more important thing in business is:
It has to work good and be ready as fast as possible. Closed-Price projects are usually not so generously calculated and... Time is money (even the spare time).
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
When I was developing client-side desktop software, I was concerned about things like laptop battery life and binary size. Now that I am developing for servers, CPU matters most, especially CPU cache friendliness.
Given that probably over 95% of all code has practically zero impact on ultimate code performance, I find it better to write all code with the emphasis on readability, maintainability etc, and only performance tune the stuff that really is on a critical path.
There are only few obvious things to take into account from the start. E.g. when you know you need to look up instances in a collection, then provide a fast lookup function (using an std::map or std::unordered_map).
For the rest, it's just wait and see. First, make your code work. Then optimize where needed.
Is this bad?
Really, this pool made me stop and think about this a bit.
By "I don't care" I don't mean I waste it, or that I'm careless about optimization, I just use as much as I need/have.
I develop mainly for the web and my servers are usually powerful.
My main goal is to keep the client fast and light, and if for that I need to use more server-side memory I'll do it without hesitation...
I care about the client memory usage, but not so much about server-side.
This is some kind of introspection I'm doing here... is this bad?
Am I alone on this?
Most people optimize their 'apps' for processor temperature. Or was that meant with the 'power' option? Anyway, we 'nowadays' have plenty of verything and therefore we do not have to know about any algorithms and can waste as much processor time or memory as we want. And there are (and always have been) great ways to fill up the memory and let the processor(s) get hot enough to fry eggs on.
After all, in the last 20 years all young and promising developers have been taught to believe that any compiler is better than an average assembly programmer. If I may translate: At least half of you are considered to be dumber than some mindless automation.