Decode Your Programmer’s Language
By: Kent Sia
Tags: Work, Software Engineering, Programming, Project Management, Software Development

1 — How’s the development progress? 90% done.

We as programmers are very bad in estimating our project timeline and effort required. We often struggle to understand the requirements from clients, management directions changing every day, short timeline to deliver, lack of resources to complete projects, etc. We also often underestimate the effort of the tasks and other factors that we do not foresee throughout the development process.

“What one programmer can do in one month, two programmers can do in two months. ” — Fred Brooks

When a team is composed of one or more programmers, they have to communicate, collaborate, perform code integrations, perform code reviews to name a few interaction points in order to complete tasks at hand. All these points of interaction exponentially increase as the number of programmers increase contribute immensely as factors causing project delays.

Reality: Probably not even started.

2 — This is not a blocker, I will fix it later.

If you are a tester or QA, you have probably heard this quite often. Programmers believe there is no perfect software in this world, as long as it is still working.

Time is an essence in software development, we often don’t get the luxury to complete everything. We probably will tell you the mitigation plan and tell you that we will fix it later, and release a few patches after production. However, in most of the cases, later never comes.

Reality: Later never comes, or underestimate the impact that causes bigger problems in production.

3 — Hey, I’ve fixed the bugs. It should work now (in fact it’s not).

Not all programmers are good at testing, and most suck at it. That’s why tester and QA exist I supposed. Bad programmers often find difficulties in fixing the bugs. They can’t understand the root cause or underestimate the fixes that lead to another issue.

Reality: It’s not working, or fixed one thing, broke something else.

4 — Weird, it works on my machine.

This is a very common phrase I have heard from time to time. This is usually uttered when something breaks after deployment, or the programmers have no idea at all why it is not working. It could be also some commands or syntax not compatible with different operating systems like Windows and Linux.

Reality: Something else is broken, deployed the wrong version, or the issue not fixed properly.

5 — I don’t know this [requirement/scope/ticket].

In some cases where the programmers have already enough tasks but still receive more from the superior/management. We tend to act like we never know or receive on the request. This could be a telltale sign that the devs are feeling burnt out or just plain lazy, they just want to push everything away.

There could be also cases where programmers missed out on some of the scopes to develop and act like they’ve never seen before.

Reality: We know about it, but we don’t want to do it. Or sh!t how could I miss this? 😱

6 — It was working yesterday. Who touches my code?

This is a common problem when working with multiple programmers in a team. We often don’t get the luxury of time to deliver a project. When a feature is urgently requested, programmers tend to neglect the testing and deploy it straight away. We also have cases where programmers pushing the codes without considering or understanding the impacts on other services, eventually broke the codes.

Reality: Someone pushed the codes and made yours broken, or you forgot you made changes yesterday.

7 — This is not developed by me.

“Not me! Not me!”, the common phrase I always heard when the programmers try to deny whatever they did. This is the nature of many human beings. When something goes wrong or broken, programmers tend to start blaming anything except the program that they’ve written.

True leaders pull the thumb, before they point the finger.

In some cases, the team leader is the one pointing finger to others, but not himself. If you want to be a great leader, I would suggest you do better, take the blame and pass the credit. Admit the mistakes, it is not a failure.

Reality: I don’t remember when did I wrote this sh!t, or how can I make this mistake?!

8 — It’s just a temporary solution, it won’t be used in production.

Quality is a feature that you can’t add to a project in the middle of the development process. We often found ourselves in a situation whether we should rewrite the entire program or just do a quick fix and let it run first.

It is a tough call to make whether to redevelop the buggy program that might delay the project or patching the bugs in a hurry which is not a good design. Especially when you have intolerance clients, testers or peers, we have no choice but to tell them this is just a temporary and hoping that they will forget it later.

Reality: Temporary solution becomes a permanent one. You will find out later when you want to make another change or issues arise.

9 — Documentations coming soon.

We programmers expect others to write good documentation, but we hate writing the very thing we love. Dick Brandon said it best:

“Documentation is like sex; when it’s good, it’s very, very good, and when it’s bad, it’s better than nothing.” — Dick Brandon

Frankly speaking, programmers are not good writers, getting started writing the first sentence takes them forever. In an environment where technology and business processes change rapidly, it is so difficult for programmers to concurrently work on both code changes and continuously keep updating the document.

From the places I’ve worked, most of the technical documentation is outdated or does not match with the system. Good documentation requires time and effort. It is best to hire a technical writer and let them do their job.

Reality: Takes ages for documentation to be delivered.