Moving from coding to engineering: Five famous misconceptions in software engineering

This blog lists some of the common myths I harboured when starting my career.

The lessons listed here are my summary of Bjarne Stroustrup's observations, Jon Bentley's book "Programming Pearls", and my personal experiences.

————————————————————————————

1. Ugly code is fast

This is not true. For example,

if (x == null) {?
  x = 0;?
}?
else {?
  if (x < 10) {?
    x = 10;?
  }?
  else {?
    x = 100;?
  }?
}?        

Takes the exact same time to run as

x = x != null ? (x < 10 ? 10 : 100) : 0;?        

But the first piece of code is much more readable. My experience at InterviewReady has reinforced my coding priorities to:

Readability -> Correctness -> Performance

Another real world example is ‘qSort’ in C++. The library was refactored a few years ago, and takes the same number of clock cycles as the earlier one. But it's much easier to read now.

Conclusion: Code speed doesn't have to come at the cost of readability. Thank God for that, else BrainFuck would be faster than C. (It?isn’t, btw)

2. We need to migrate to Language X

Python is easy to code. Go has good concurrency design. Java has inbuilt libraries.

We should switch from this to that.

Critical business requirements and large teams need extensible code. That may need a language migration in your specific case.

I'd be very, very skeptical though. The grass is greener on the other side.

3. Laziness is bad

Laziness allows us to ignore or procrastinate low priority jobs.

Please don't over-engineer for extensibility and readability to the point where you are spending more time refactoring code than writing it. Be lazy.

Having said that, pay the loan while you can afford it. Laziness in naming variables or system design is suicide. Get them right the first time. It's easier than fixing them later.

4. You should use the latest technologies

This type of tech is classified as ‘bleeding edge’. You never know how long it's going to last, if it has some serious bugs in it, and if it is extensible for future use.

Yet, ahem,?some?programmers obsess over the latest framework they can get their hands on. It's alright if you are doing this for fun, but serious systems cannot have unstable tech bases.

Use a framework for serious work only if it suits your needs and is well tested. In case of problems, you will be contributing to that open source codebase sooner than you expected.

5. There are libraries for everything these days

Of course there aren’t. Thats why we hire programmers. For many simple things that can be done using libraries, its easier to just write the code than find a reliable library online.

Also, we can’t import libraries to the point that the codebase explodes in size. Compilation and data transfer takes forever.

————————————————————————————

There are other, lesser evils apart from this. These are enough for now!

If you are preparing for a system design interview, check out the high level and low level system design problems at InterviewReady . They are supplemented with architecture diagrams, quizzes and working code.

Wishing you an awesome week ahead!