[realusername]

The first part resonate a lot with me. I wanted to learn Russian (because why not ?), I intuitively thought the Cyrillic alphabet would be the hardest part of all, like it's another alphabet and you can't read anything right ? Sounds really difficult...

Actually it's the easiest part of the language because it's 99% phonetic with some few exceptions, the whole alphabet is in reality quite small and it was actually easier to learn how to read Russian than reading English. The hard part is actually more the grammar (with those cases) and the vocabulary more than the reading itself. I still have a very basic level but the alphabet part took like only 4 hours maybe to remember them all.

But it's also the same when coding, the hard parts are not always where I expect them to be.

[copperx]

> But it's also the same when coding, the hard parts are not always where I expect them to be.

As you may know, this also applies to optimizing code. The 'hot' parts of the code are very often things that you don't expect.

[orionblastar]

The hard part of optimizing code is to find areas were your code is weak at and taking too long to do something.

In my best practices and I learned this from a video by Grace Hopper, is to use less code to do the same thing. Less code takes up less memory and usually runs faster.

Just writing code and then compiling it without any errors doesn't mean it is done. You still have to optimize it and do security checks as well as quality checks. You still have to check for bugs and side effects. You have to use it and think like a user would to see how the user would see it.

[HerpDerpLerp]

Less code is not really that important anymore (within sensible bounds) Clarity to whatever poor shmo has to maintain it is often much more important than saving 5 lines with some clever bit twiddling hack.

Unless of course you are having performance issues and you have identified this code block as the issue.

[w0utert]

>> Less code is not really that important anymore (within sensible bounds) Clarity to whatever poor shmo has to maintain it is often much more important than saving 5 lines with some clever bit twiddling hack.

I don't think many people will advocate reducing line count by stuffing the same processing into fewer lines using clever tricks. What should always be considered a good thing though, is cutting down on the line count by changing the algorithm/strategy, using better suited data structures, by trying to 'do less' and get the same result, not trying to support every thinkable corner case you will never run into, by preferring multiple simple implementations of the same thing for different corner cases, over one single complex kitchen-sink solution, by not re-inventing the wheel and using tried & tested libraries/frameworks, etc.

I know it sounds like a terrible cliche, but any line you don't write, is a line that can't contain bugs ;-). Over the years I've learned that almost always, simplicity is preferred over complexity, even if it implies a little bit of duplication, or an implementation that is 'less awesome' because it 'only' does what is needed for the application.