I mention elsewhere that you need to write your programs so they can handle unexpected things – bad data, network problems, etc. But, you don’t want to spend too much time on things that solve problems that are unlikely to happen.
This is commonly known as the principle of YAGNI – You Aren’t Gonna’ Need It.
When you first start programming, you probably won’t need to worry about this. You don’t become aware of all the things that can go wrong with a program until you’ve experienced them – which requires time working as a programmer.
But this is an important principle to keep in mind.
First, remember that we’re being paid to provide business value. We might think it would be useful for our programs to work with any type of database engine – Microsoft SQL, Oracle SQL, PostgreSQL, MongoDB, etc. We might be tempted to write our code that connects to the database so we can easily switch engines.
But, in my experience, switching from one DB engine to another almost never happens. The companies have their licensing agreements and support agreements in place. The employees all know how to work with the one database engine. All the company’s data is in that database, and they don’t want to spend the time and money to migrate it to a different engine.
So, if we spend time writing code that lets our program quickly switch between database engines, but never switch, that was wasted time. That’s the principle behind YAGNI.
YAGNI is often relevant in the performance “-ilities”. A programmer might spent weeks writing code that makes a website scalable, to the point where it can handle 10,000 orders per minute. But, if your website currently gets a maximum of five orders per minute, that scalability work was probably better spent elsewhere.
Remember that the basic idea behind YAGNI is to “write the simplest thing possible that works”, not to “write the stupidest thing possible”.
There are programmers who, when someone tells them to write “the simplest thing possible”, decide to go off on a rant saying, “OK. I just won’t check user input at all and let the program crash when it receives bad data.” I don’t know why they insist on one extreme or the other, but that’s not the type of programmer you want to be (or be around).
Return to “Life as a programmer outside Silicon Valley” index