Perhaps I’m biased by my own concept of being enthusiast and vocational on software development, but I’ve found some reprehensible behaviors or conclusions made by software industry professionals that I would like to summarize on this post.
#1 - I’ve not evolved my knowledge because my company has never provided me training
* Disclaimer: I’m also an IT trainer and I perform software architecture and development courses. Hence, I’m convinced about the value of training!
One of most important skills that need to come with you is the ability to evolve yourself. What you know today might be invalid tomorrow, or what seems to be optimal today might be outdated in some months or years.
Stop whining. While training is very important and companies should always provide training plans, you’ve been hired because you should own a skill set and background that seemed to fit with your company projects’ requirements.
Thus, if you find yourself out of the game is just because you’ve slept too much! It’s time to open your mind and listen to your coworkers to try to join the bandwagon learning. And, please, don’t stay still on your arrogance or hopelessness: Evolve or die.
#2 - I can do more, but my salary is too low
Really? Where’s your self-esteem? If your salary is too low, maybe you need to convince your company to get a pay rise. Otherwise, don’t go against your coworkers. If you limit your skills just because you’re not happy with your salary, you’re not very harmful for your company (they can fire you if there’s an evidence that you’re not so serious with your work): the worst part is you’re lowering your quality based on the amount of money you earn from your company and this has a serious affectation on your coworkers results. Who said teamwork?.
#3 - I could go through your route and I know I’m not in the right track.
Oops! You’re implementing a requirement and some team mate checked your code and found that you’re on your own way, but there’s a more conventional, de facto solution, so you shouldn’t reinvent the wheel. But you don’t have too much love for that coworker, so you know that he/she said you a fact, but you won’t accept his/her advise because it’s better to do something with your own hands than admitting that someone has defeated your chance to get the next badge…
Ok, there’s another reason for above mentioned behavior: you want to do it yourself because you want to evolve and learn by trial-error (so learning from errors will turn you into a more experienced and professional developer)…
Either way, you should be in the wrong way. You’ve been hired to provide good solutions, and good professionals are that ones that are able to find a solution from any available resource… EVEN YOUR HATED TEAM MATE MAY PROVIDE YOU GUIDANCE TO GET TO YOUR LOVED SOLUTION!
In my case, I learn by trial-error at home, and in some cases in my workplace, when no one can provide me a solution to my concerns/issues.
#4 - I dOn’T fOlLoW pRojEcT’s cOdiNg CoNvEntIoNs…
Discuss about implementation details, but don’t bother me about coding conventions, because you can’t force everyone to code like you.
In the other hand, my company has provided me no documentation about coding style, so…
WRONG! Many programming languages have official coding conventions. Vendors or communities behind programming language implementations have published extensive documentation pages and usually they provide coding conventions.
Right, many companies have additional rules on how to code their projects, but the absence of specific company’s coding conventions doesn’t mean that everyone is invited to don’t follow de facto coding style for a given programming language!
Obviously, coding conventions aren’t meant to cover everything you might code, but it’s a good start to let your code be evolved by your team mates or future new coworkers. You’re not a silver bullet, aren’t you?
# 5 - Reinventing the wheel because of some micro-optimization
I’ve not used a well-known OR/M because these are too slow and don’t cover my use case… I won’t use an UI framework because it’s too opinionated…
There’s a plenty of wrong decisions based on wrong assumptions. What’s your level of knowledge about existing solutions? Did you prove that existing tools are too slow? When you want to reinvent the wheel, you should prove that no other solution can satisfy project’s requirements.
Anyway, maybe you don’t know your company isn’t a software component development provider. They don’t work to implement too generic solutions, but their goal is providing an usable product. Sometimes, micro-optimizations aren’t very useful when you think things in global. You should ask your team if a bottleneck is an actual impediment to the user, or it’s just you that you’re too perfectionist or academic.
In summary, don’t take such decisions without asking your team mates about your intentions, and be sure that the task of implementing software components is being included as part of project’s R&D, and prove that your idea is useful demonstrating it as part of a proof-of-concept project that others may investigate and give you positive (or negative!) feedback.
What if your idea has been already implementing by an individual of 7,000M inhabitants in your planet called Earth? It’s just a matter of probability :)