Timeline for How can I promote the use of the Builder pattern in my team?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 4 at 11:29 | comment | added | gnasher729 | What will happen: The day you leave, they will all be relieved and change everything back. | |
| Apr 11, 2016 at 9:44 | comment | added | superhero | ... I was employed to help them in his (or the team) project. I can't do so with out it being cleaned up, refactored. If he/they don't like that, then there will be a confrontation. I consider this good. He/they needs to listen to the person coming in. And if that can't happen, then I need to be relocated in one way or the other. I wont adapt to bad practice. It's like a car imo. Can't go forward without friction :) | |
| Apr 11, 2016 at 9:37 | comment | added | superhero | I see your point @Dunk I'm at a company right now where I'm very happy. I don't agree with everything how it's done and I don't try to change anything that already exists, except for the things they want me to ofc. I don't work in projects I consider are in need of a rewrite though. My point is still if I would be in a company where I had to work in projects that I consider being in need of being completely re-written, then I will take that confrontation. The person who has been there longer and protects what is written will be upset maybe, but I won't take that into account... | |
| Apr 8, 2016 at 17:43 | comment | added | Dunk | ...before you can even begin the process of change. If you come in and establish a "negative" relationship with some of the developers early on then it won't matter how good you are. They'll still carry that opinion with them for as long as you work with them. The ultimate goal is "buy-in" and not just adherence. If people don't buy-in to your ideas but are forced to just adhere to your rules then they'll adhere to the rules but do a lousy job and your ideas will be proven worthless, just like those developers wanted to prove. | |
| Apr 8, 2016 at 17:42 | comment | added | Dunk | One of the main reasons I was hired at 3 companies that I worked for was because they wanted someone to make the SW team more "professional". Based on a couple bad experiences early in my career, I learned that the new guy coming in isn't going to get much buy-in if they come in and act like a know-it-all. So in each of those 3 companies, I came in and "proved" my chops before I started trying to get buy-in for anything other than trivial changes. Once people WITNESS that you really know your stuff, it is vastly easier to get people to go along. This could take 6 to 12 months.... | |
| Apr 8, 2016 at 15:17 | comment | added | superhero | @Dunk I see that you have a different opinion then I in this matter. Yours seem to be more popular, if reading from the other answers. I don't agree, why I wrote this answer in opposition. What you have stated has not changed my mind. | |
| Apr 8, 2016 at 14:03 | comment | added | Dunk | You don't have to "forever" work with code that is trash or follow bad practices simply because that's how it is being done. However, if you want to be successful at changing things then you had better prove your credibility first as a minimum. Just about every developer thinks code they inherit is trash. If every company just agreed with the new guy every time without even knowing their true skill level then the trash will turn into a dump. Also, you should take the time to understand why things are done as they are. Sometimes the "wrong" way is the "right" way for a specific situation. | |
| Apr 6, 2016 at 22:35 | comment | added | superhero | @Dunk Try to change how people code as a team member is not what I do. But I tell them from the start; "I wont work in this project with out completely rewriting it", if the code is a piece of trash that is. If that's not appropriated, well... then it's mutual. It's not just about a comfort, it's about the fact that I need to be able to take responsibility for what I produce. I can't do that if the surrounding code in the project is a complete mess. | |
| Apr 6, 2016 at 22:32 | comment | added | superhero | idk what to reply to your assumptions @Dunk I was not trying to change everything, I tried to clean it up. And it was not people that knew what they where doing, they proudly created classes and functions that where hundred lines of code, with idk how many states, global and so on.. the level was closer to kinder garden imo. So I stand by my statement. Never back down when you notice your self being in a position where you will have to adopt to bad practice to fit in. | |
| Apr 6, 2016 at 19:22 | comment | added | Dunk | I don't know the details of your situation but if you came in and tried to change everything without first gaining people's confidence with your skills or not taking the time to learn "why" they do things the way they do then you were treated exactly as you would be treated at just about any company, even really good ones. Actually, especially at really good ones. Once people have confidence in someone's skills then it is simply a matter of making a compelling case for your suggestions. If you can't make a compelling case then there's a good chance your suggestion isn't all that good. | |
| Apr 6, 2016 at 10:09 | history | answered | superhero | CC BY-SA 3.0 |