Teams
The are engineers who manage their career by jumping from company to company about every year or so. I call these types of engineers “Ronin” (Masterless Samurai) as they have given up the idea that they will work for the same company for the rest of their lives, and instead wonder the job market looking for new challenges and more compensation. Loyalty to a particular company is completely missing, as in their eyes the opposite is true. “If a company can lay off an employee at any time,” the logic goes, “then I can leave at anytime I wish.”
If you over specialize you will die a slow and painful death. No matter how much money you’re making being the soul living expert of a legacy system or technology, it will catch up to you when you inevitably have to switch jobs. The flip side is that if you over generalize, you won’t have any marketable skill, as no one will know what you’re good at and therefore how to use you. The best approach is to pick a specific area you’re passionate about, and become a generalist with a high degree of proficiency in all the relevant skills.
There’s a bad habit among engineers of judging their peers by their recall of rarely-used information. For instance, if an engineer didn’t know what “$” meant in a regular expression, the assumption would be that the engineer – in general – was a bad engineer. I have done this (and may still do this) and have seen it consistently my entire career.
I often get the feeling that quality would be higher if there were no QA people. My thought is that without QA, 100% of the accountability falls on the engineer to find and fix bugs. Additionally, since many engineers don’t or won’t manually test their work thoroughly, being accountable for finding and fixing their own bugs puts more pressure on the engineer to write automated tests.
This, of course, is dependent entirely on how much the engineer cares about there being bugs in the system. Most engineers don’t care, using the rational that bugs are simply a by-product of developing software, and having a certain number of bugs should be acceptable. Furthermore, some bugs are minor, and should be de-prioritized in favor of high priority bugs, so really there are some bugs that will never be fixed by virtue of responsible triage based on business priority.
These types of engineers are typically lazy bastards and are unaffected by the presence of QA – they will do whatever they feel like, largely because they can get away with it. If you work with these types of engineers just figure out what they did to get such a sweet deal, and get career tips from them.
The engineers who benefit most from not having QA are those who are not lazy bastards. These are engineers who take pride in their work, and don’t want any bugs in their system, but who make honest mistakes. Without QA, these engineers get better.
Your reputation is what people say about you behind your back. While you may be able to influence what people say about you, you cannot control what is said. Your reputation is subject to gossip, rumor, and office politics, and once damaged is difficult to repair. Establishing and maintaining a good reputation is essential to having a successful career, but few people are aware of their reputation, much less how their actions can positively or negatively affect it.
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
“Like” if you’d like me to write this article
A unified team is more effective at accomplishing objectives than a group of loosely organized individuals. When a company forms a team, they select a manager to be in charge, and make the team report to that manager. The issue with this approach is that only some types of managers are capable of building a group of individuals into a team.