<story><title>Be likeable or get fired</title><url>https://sites.google.com/a/athaydes.com/renato-athaydes/posts/belikeableorgetfired</url></story><parent_chain><item><author>OutsmartDan</author><text>Some hard lesson&amp;#x27;s i&amp;#x27;ve realized while working in &amp;quot;professional&amp;quot; environments:&lt;p&gt;1. You must earn respect before you trash the system, no matter how shitty their code is or lack of tests. It&amp;#x27;s usually best to start by &amp;quot;doing your job&amp;quot;- whether that&amp;#x27;s issues assigned to you or bug fixes; you are at the bottom of the totem pole right now. Once you&amp;#x27;re &amp;quot;respected&amp;quot;, implementing better solutions will be a lot easier.&lt;p&gt;2. Excuses for why shitty code is in production are probably legitimate excuses; a company that makes profit on a SaaS product needs to launch and iterate quickly. Product managers&amp;#x2F;sales&amp;#x2F;marketing do not care about your unit tests. Your users also don&amp;#x27;t care about your unit tests. Unfortunately this is a dilemma that&amp;#x27;s hard to swallow, because when things break, it comes back around.&lt;p&gt;You have to realize a team that&amp;#x27;s been there before you has done things in certain ways for certain reasons- whether that&amp;#x27;s good or bad, you must adapt to it before you go king kong on their shit.&lt;p&gt;Or you can just start your own company and make your own rules.</text></item></parent_chain><comment><author>raphar</author><text>This is key. I see that there are two aspects of this story:&lt;p&gt;1. The OP is obviously far ahead technically than his work environmment. He has the experience, know the practices and can improve the software process.&lt;p&gt;2. Second but key, he sucks at working in a team and also at communication. You don&amp;#x27;t change a mess such as the one he describes in 5 months. That culture of the company, if you are not the boss, only changes by soft proposals, influence, bond building, debate.... Nothing is going to change to new practices or behaviours if not for conviction (or fear). It&amp;#x27;s a slow process, an not one you can win only by logic. The subject is huge.&lt;p&gt;That said, I agree that it was better for him to leave.</text></comment>
<story><title>Be likeable or get fired</title><url>https://sites.google.com/a/athaydes.com/renato-athaydes/posts/belikeableorgetfired</url></story><parent_chain><item><author>OutsmartDan</author><text>Some hard lesson&amp;#x27;s i&amp;#x27;ve realized while working in &amp;quot;professional&amp;quot; environments:&lt;p&gt;1. You must earn respect before you trash the system, no matter how shitty their code is or lack of tests. It&amp;#x27;s usually best to start by &amp;quot;doing your job&amp;quot;- whether that&amp;#x27;s issues assigned to you or bug fixes; you are at the bottom of the totem pole right now. Once you&amp;#x27;re &amp;quot;respected&amp;quot;, implementing better solutions will be a lot easier.&lt;p&gt;2. Excuses for why shitty code is in production are probably legitimate excuses; a company that makes profit on a SaaS product needs to launch and iterate quickly. Product managers&amp;#x2F;sales&amp;#x2F;marketing do not care about your unit tests. Your users also don&amp;#x27;t care about your unit tests. Unfortunately this is a dilemma that&amp;#x27;s hard to swallow, because when things break, it comes back around.&lt;p&gt;You have to realize a team that&amp;#x27;s been there before you has done things in certain ways for certain reasons- whether that&amp;#x27;s good or bad, you must adapt to it before you go king kong on their shit.&lt;p&gt;Or you can just start your own company and make your own rules.</text></item></parent_chain><comment><author>snowwrestler</author><text>I will add that, as a new employee, the best possible way to gain the trust of your new managers is to make them look good. In the case where you can see some obvious improvements, that means working collaboratively with the manager so that they can take some credit for the improvements. Specifically it means offering criticism and suggestions privately, getting the OK before making changes, and letting the leader manage the broader communication about the changes.&lt;p&gt;This advice is going to piss some people off--I know it. It will piss off people who wish work was an objective technical meritocracy where the best coders immediately rise to the top and are in charge. And maybe a company that operates that way would indeed be the very best company! But that leads to the most important line in the comment above:&lt;p&gt;&amp;gt; Or you can just start your own company and make your own rules.&lt;p&gt;When you accept employment in an existing company, you are making a trade--you are trading the stability of being an employee, for the power of running your own company and making all the rules. You must understand that that means you are accepting there will be some level of messiness in joining a culture that already exists. You have to understand that for all its apparent shortcomings, your new employer has already been successful enough to hire you, and they&amp;#x27;re not unreasonable to expect some level of respect for that.&lt;p&gt;In my experience if you have a tech lead who is defensive and hostile to criticism of systems that are obviously not where they should be, it is either because they are total assholes, or it&amp;#x27;s because they &lt;i&gt;know&lt;/i&gt; of the shortcomings, and feel immense frustration that they have not felt able to address them.&lt;p&gt;If they are total assholes, you don&amp;#x27;t want to work there anyway.&lt;p&gt;But if it&amp;#x27;s just frustration (and IME it often is), then you have a huge opportunity to grow and lead. You can solve the frustrations and help make a better product! But if you lead of with public complaints and criticisms, or go off and make changes on your own without coordination and the ok--those will &lt;i&gt;add&lt;/i&gt; frustrations, and undercut whatever good you&amp;#x27;re delivering.</text></comment>