Design a site like this with
Get started

The “Scripts” You Shouldn’t Code

1K Blog Marathon: Day 22

“It’s not a bug, it’s a new feature!”

“I don’t write comments.
You should understand that a = b + c.”

Can you think of all the bad habits you possess when you write your code? Can you admit to yourself that even you are a good programmer, you still tend to disregard good programming practices?

Or are you forced to do the things you know will not be good for the system, but you still are doing it? Just doing it because it’s either you don’t know what you are doing, or “they” don’t know what you are doing.

Let me give you a tour on the ridiculous “scripts” (not code) we programmers always say (or do) whenever we are getting hit by the “dark side”.

“Usually, I can finish that whole system within 2 to 3 weeks (Maybe)”

Remember this line from 6 months ago? And yet you still ask for an “extension due to database migration and platform-independence limitations” because you want to perfect the calculator that your client asks you.

“It’s working on my computer (What did you do?)”

You had finished your last optimization edits. You passed the system for the review, and your program goes well. Until the process stops while testing. You’ve got a call from the tester, and you replied “what did you do? It’s working on my computer!” You’re users will not adjust to your system, unless it’s hardware acceleration issues.

“Yes (I mean, no)”

After the meeting, you are hitting your head for agreeing on a matter that you don’t really want. You, as a developer, knows more than the one requesting for the update, but because you want to keep your job sitting on the office chair, you just say ‘Yes’ to an unacceptable point.

“I’m writing a better code in case I needed it in the near (not really) future.”

Optimizing. Optimizing. You write functions for each process, although it’s an overkill for a single task. Because you are “futuristic”. And so, your “future deadline” is now in the “past”. And your “near future” updates won’t come. And you’re doomed.

“I don’t need to learn that (I’m a genius)”

Oh come on, admit it to yourself – you are just being egotistical. I know that you don’t need to follow the “new-shining.js” framework always, but at least try to learn something new. Remember my motto – “Stagnation is a Sin”.

“Stagnation is a Sin”

– curbside coder ^_^

“I’m not a commentator (I don’t write comments)”

As the saying goes, “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” And let’s admit it, even if you code so good and so clean that is very understandable and readable for the next psychopath, it won’t hurt your fingers to type in few comments for a clear understanding. And if you’re the one who will check your code after a decade, you will thank yourself for doing so – promise!

“I’ll do it tomorrow, (wait for nothing)”

Please, don’t do it tomorrow! If you can do it today, don’t wait for tomorrow. It’s not that I want you to be a code hero, but I just want to instill to you that this not only develops good coding practice, but also good habits. Successful persons don’t wait for tomorrow!

“It’s 95% done, (well, 9.5% to be exact)”

Don’t be afraid to tell the truth. If it’s really can’t be done within the next few days, say so. It’s better to do it earlier the new deadline than missing it for the second time. If you think it can only be done within a one week range, extend it and say for at least two weeks. When you deliver it within one week, you will feel great, and your boss will be happy because you got it early.

“It’s not a bug (it’s a new feature)”

This is a cliché joke, but it really happens. Be careful with your code when presenting. If there is something your are not comfortable showing in your presentation, better to comment it out and not show fully – or else it will creep up and say “peek a boo!**”

**ruining your code, shattering your world.

“I know (what did you say?)”

Again, it’s not bad to admit you don’t understand a thing. It’s better to clarify things out by asking questions than walking out of the meeting room and asking your peers “what did he say again?”

Being a good programmer is easy. But taking it to a one step higher, you need a lot of hard-work and sweat to be poured in your keyboard. Just don’t give up until you find that bug!

That’s it folks, happy coding!

“And that’s one blog, stay hungry!”

There are two ways to write error-free programs; only the third one works.

Alan J. Perlis


Published by Christian Foster

Code-blooded, coffee-lover, tall, dark and chubby. I love to draw, has motion-sickness and a sleepy-head. BTW, graduate of BS Computer Science, Associate in Computer Science and certified UiPath RPA Developer. Loyal to my partner and a father of a cute bouncing baby daughter!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: