To me, it seems that if you suggest a solution that you later realize doesn’t work then you would seem more intelligent admitting its wrong rather than asserting it isn’t. It’s ok to be wrong sometimes but admitting when you are is what truly matters.
Absolutely. And the title is a bit tongue in cheek. You can't guarantee a correct answer, but some of these behaviors ensure a wrong one. And others help make the possibility more likely.
It might not be a comfortable realisation that the problem is people. People who got it incorrect in the first place and who might not be able to do otherwise.
When it comes to people problems then it is easy to look at it as a matter of skill. That is an easy problem. Bring in someone able to solve all the problems no one else could or who can solve the critical problems better. That's nothing more than filling a void.
In many cases people problems are more complicated than that. People's emotional needs or bad habits do often lead to disaster.
When you enter such an environment for nearly every case you find something wrong the champion of that decision will find you before you know what's going on and defend that wrong decision to the death.
Job security is indeed often the name of the game. The paradox is that the more someone does in the name of that cause and not the task at hand the more it is that they have to go if you want any chance of setting things straight.
Team has become a bit of a toxic word today. It has been mistranslated to everyone with the false assumption that a team can always exceed individuals or render individuals immaterial. A single individual can decide the fate of a project for good or for bad.
I see people throwing out something if one member on the team doesn't get it. The team of today is only allowed to perform up to the level of the weakest member.
At the same time people also lay on the buzzwords thick and no team in hell has a chance of doing all that stuff properly or with return on investment.
I've been on a few dysfunctional teams where I'm the senior programmer miles ahead of everyone else and have had to explain to people if all of this stuff is too much for me it's too much for anyone. As in focus on writing code that actually works first before trying to implement every design pattern in the book turning a hundred line program into a ten thousand line program.
This is because many managers just copy what everyone else is doing and assumes that results in success. When they're not looking at the problem they can usually be found looking at what Google is doing next and what's presently hot or trending.
I see people behave in ways that suggest to me their minds have been broken. When people are put under such unreasonable demands then it is easy to see why. I have the confidence to speak out about it but I don't know what's going on in the minds of these juniors. Their minds are probably buckling under the pressure.
For a non-technical person it is extremely challenging to work out who is in the right and the opinionated loudmouth can reassure them spitting out several dozen buzz words and abstractions they heard about a minute.
I'm not sure technical purity is always that. I hear people go on about design patterns and other things.
It sounds an awful lot like technical purity with a lot of breadth and depth but on investigation it's theory separated from practical concerns with the motivation for it being that those terms can be found on most job postings and are also trending in the blogosphere.
I am very much about the technical purity but I also realise it doesn't mean to me what it does to others. To me it means minimalism which you need because even if things are kept uncomplicated they soon become complicated and if you made things complicated from the start now you have two problems.
People also have two very diverging definitions of making things complicated.
It's not always obvious to people what makes things complicated. Many people think the complicated thing is the simple thing. You commonly see this with people using a million line framework to wrap a one thousand line API.
It is not possible to truly understand simple and complex without firsthand experience.
Those words are lost on anyone who possesses little more than an abstract understanding of the problem.
I have always considered my team's existing capabilities when embarking on a project. I often make certain sacrifices to take advantage of this.
When I do so I know I am making a sacrifice of one thing for another.
I'll ask someone what they're familiar with then that takes a part in my decision making process. It is not a deciding factor but one among many.
What is sad to see are people arguing for something with the introverted reason being that it is familiar to them but with the extroverted reason being that it is technically superior.
Sometimes motivations are more sinister. Someone will argue for some newfangled thing because it will reset everyone's score.
Managing programmers can be unpleasant as many behave in certain ways for their own cause but they wont openly declare their motives. Given many will respond to their emotions it wont be something they even thought through.
This is quiet cool defining th problem is really important. Im heading in to do more kind of stuff like this and i can see its important to get stakeholders to know what you are doing and if it should be done.. will a good explanation of what will be affected beyond just a technical definition (that i would understand). I will see how i will have to step back. I've tried to see how other developers or rather senior developers do it and talk to people invovled.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.