Harmful Tips: How To Get Away With Coding p.2
In our series of articles called ‘Harmful Tips’ we address issues for different parties of IT communication chain: from clients to developers; from project managers to designers. We highlight the most common mistakes we all make using reverse psychology: wrong is presented as right. A bit of humor and wealthy criticism can definitely improve our business environment.
This week’s article is devoted to some of the common mistakes developers make while communicating with clients and work environment.
Disclaimer: High level of irony and sarcasm detected. Be warned.
There’s nothing more dramatic than ruining otherwise functional framework. Your part of the code can become a death sentence for the feature. Be cautious, never accept the body of work you can spoil. Even if you have enough of skills and proficiency. Avoid responsibility by any means. Your scope of work mustn’t exceed basic knowledge, and always make sure your Tech Lead will pull out “safety bag” for the project in case you spoil everything.
They say any success lies beyond the comfort zone. But has anyone ever tried to stay in the comfort zone? Success is somewhat overrated, while stability appears to be more important in the long term. Stick to those projects and frames that do not require constant self-improvement. Learn one or two programming languages and don’t overload your mind with coding nuances and advanced technologies. Your comfort zone has well-defined boundaries and your goals are down-to-earth.
Communication is overrated. Don’t get upset if you can’t find a common ground on some issues with your fellow employees. You might speak different languages: it’s Java for you, it’s English for them. Stick to the essential information, don’t waste time on explanations and open answers. Those who can’t build logical conclusions and use deductive reasoning are no friend of yours. Your point of view is the correct one. You know for sure: coding is more important than designing. Colleagues will call you arrogant, but being so is the only way to stay original.
Don’t forget to stay autonomous. Teamwork is the shelter for the weak, professionally incompetent. You’re not one of them. All you need is you. This implies to every stage of the project. You can become a small tool within the dev team who create something big and valuable. But it’s much more alluring to develop a small tool with your own hands, rely on your own vision and capabilities. You don’t need the whole scope and flow charts to create something grand. Should it contradict the initial feature or the framework, you can always take extra time to edit. No one will think of you as of a mediocre employee.
Your code is the work of technical art. It may be far from ideal, but hey – sometimes designers present bugs as features, so can you. Sometimes you find it more important to deal with as many projects as possible, to stay prolific in the eyes of the management. If you can’t keep the pace with the rest of the team – little sacrifices never hurt nobody (or did they?): choose quantity over quality. And if it so happens you get tired – take a time off the project, come back to the code whenever you’re ready or right before the deadline.
All illustrations: Marina Parhomenko