|
Slacker007 wrote: Like you?
Gotta work on your social skills man.
Slacker007 wrote: No thanks. Not for me. It has been my experience that the know it all, really doesn't know anything.
You have to assume you're a know-it-all to actually buy into the fact someone you don't like knows nothing. There are different types of intelligence, and memorizing things from a book does not make you experienced or all-knowing.
Jeremy Falcon
|
|
|
|
|
Slacker007 wrote: No thanks. Not for me. It has been my experience that the know it all, really doesn't know anything.
And I'm not trying to say the some know-it-all tech type guy knows his tech. But he knows how to talk and voice his opinion. Which counts for something, especially when speaking to people that don't know what we do and have no way to trust a coder that doesn't speak up.
Jeremy Falcon
|
|
|
|
|
Sounds like a struck a nerve.
|
|
|
|
|
Nope. It's called communicating. Try it.
Jeremy Falcon
|
|
|
|
|
Just out of curiosity... do you work for Siemens Automation?
I ask because I often wonder if their software people are brain dead.
Government is not reason; it is not eloquent; it is force. Like fire, it is a dangerous servant and a fearful master. ~ George Washington
|
|
|
|
|
|
Been exactly where you are, the Form is done, everyone thinks it's a five minute job to wire it up!
|
|
|
|
|
glennPattonPUB wrote: everyone thinks it's a five minute job to wire it up! So true, I don't whether to laugh or cry.
"Isn't done yet?"
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
|
|
|
|
|
Unlike you, he knows to leave room for improvement.
|
|
|
|
|
you could challenge him? Probably won't work, but it will be hell of fun .
So in the meeting it would go something like this...
You: Really? Copy / Paste N times. I would have done this in a for loop.
He: [brief moment of silence] for loop? yes, of course, but [insert really dumb reason for not using for loop here]
You: Oh, I didn't have that [that really dumb reason] problem. Look. [show code en let it run]
He: ... uhm ...
You: [start talking real development jargon that you know he doesn't understand.]
|
|
|
|
|
I have a similar thing going on right now. I just let him have all the rope and he is slowly hanging himself. 3 months behind on what should have been a one month project, and that's generous.
With the stuff he isn't directly responsible for I just ignore his loud and arrogant mouthyness and tell the support people to do it my way. And I was right. Problem is now fixed for the customer.
Main thing is don't get angry, and don't be afraid to give people like this rope, to give them a little shove towards the cliff edge. Have your own app written in preparation, and when his crashes and burns just show yours to management and tell them you wrote it in the evenings just for fun.
|
|
|
|
|
Management are there to manage the business - and therefore they want stuff done now, cheaply and right. They don't give a toss about whether it is in C# or VB6, using Access or Oracle. They just want a solution.
If someone offers them a solution, and it works, then as far as they are concerned, job done, tick the box, take the bonus at xmas.
So, you need a way to tell them that the solutions being produced are only good in the short term (assuming that is the case - what is the cost of maintenance of the badly written code - how often does it need to be changed?)
It's all well and good to see SW being hacked together and die a little inside when it is, but if it provides a working, cost effective solution to the business then there's nothing you can do about it - because the business doesn't care.
For example:
Business needs a front end program to write some values to the serial port to change some settings on a machine.
You look at it and propose a solution with some base classes for serial communication, a base "Machine" class that can be inherited and extended for different machine types, a Xaml front end that will scale for different devices, and a Db back end to provide Machine descriptions to dynamically build the GUI for different machine types.
it will be written in C# .Net with SQL Server back end, using Agile methodologies with daily scrums and peer programming. TFS will be used for both source control and task management.
Your colleague knocks something up in MS Access overnight, with everything hard coded for the one machine. The code is illegible, uncommented and about as efficient as a chocolate kettle.
Lets say your solution would cost $10,000 and his cost $1,000
The company could write another 10 of the crap solutions, from scratch, for the cost of the flexible solution.
If they anticipate adding a new front end monthly then over a year (ignoring any costs involved in your system setting up a new machine) the cost of both systems is equal.
You see what I am getting at? crap software is not necessarily a bad thing for a business!
PooperPig - Coming Soon
|
|
|
|
|
Sounds like you work for one of the major engineering companies. They charge by the hour, you know. And management thinks software is a rubber plate.
Bobby
|
|
|
|
|
BobbyStrain wrote: Sounds like you work for one of the major engineering companies.
Nope
BobbyStrain wrote: They charge by the hour, you know.
? I don't understand? Who charges by the hour?
BobbyStrain wrote: And management thinks software is a rubber plate.
What? A rubber plate? Something lost in translation, I think!
PooperPig - Coming Soon
|
|
|
|
|
Maxx said what I've been thinking. Sometimes old or bad tech solutions are good enough to satisfy business requirements. Management often has a belief that faster is better when delivering a working solution, and they don't worry about maintenance effort until it becomes necessary. There's also a huge difference between solo developers working in isolation on a focussed problem and team developers working on a large application where they have to use current technology.
I've seen cases where programmers weren't willing to make the stretch to adopt newer methods. I have actually talked with an assembly programmer from early mainframe days who never made the transition to 3GLs because he thought they were inefficient and pointless. I also worked with a COBOL programmer who learned structured programming and never used it because she couldn't see any advantage over her GoTo code. I swallowed hard and left her code alone, because it was the only way she could maintain it, even though I had produced structured code for over 20 years in organizations where it was absolutely required. No one with newer, better ideas was ever going to reach these people, and it's possible that this know-it-all isn't interested in changing either.
My advice is to find some way to respect the guy if at all possible. His solutions do work, even if they are suboptimal, and he's able to sell them. If you choose to approach him, make it about the work and not about personalities or competition or personal gain. Who knows, your enthusiasm for better methods might be contagious. But don't count on it. The principle of "Praise in public, critize in private" applies here. Your position is inherently critical of his approach, so it is less risky to approach him alone than to confront him or his ideas in a meeting with others.
If you want to lead the organization in new directions, the best way is by demonstrated success in your own area of responsibility. Make sure your own managers and coworkers understand the reasons for and advantages of your technical choices. At some point there should be value added because your solutions are scalable, enhancable, or optimized, and it might pay to point that out occasionally.
|
|
|
|
|
mycroft1 wrote: Maxx said what I've been thinking.
... and you said it so much better ! +5
PooperPig - Coming Soon
|
|
|
|
|
As long as you are not the one picked to maintain the crap, I would just tune out and not give a damn. Best way to avoid high blood pressure...
Ain't country music[^] great???
Anything that is unrelated to elephants is irrelephant Anonymous ----- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 ----- I'd just like a chance to prove that money can't make me happy. Me, all the time
|
|
|
|
|
Set him up. People like that love stealing ideas and calling it theirs.
|
|
|
|
|
I think the best piece of advice I've seen so far is from Mark Merrens Wallace, yet you seemed to speak up to everyone but him.
But just backing up his point. If you go directly to the guy which is making you blow up steam, you may actually be pleasantly surprised.
Yeah, I know, sometimes people can be cocky and poor listeners, but if you go with the correct approach in a humble and suggestive way, you have I high chance of success. This can lead you to get an ally with management and he may even start coming to you for advice. As a side effect you will even stop venting at the meetings
I know it can be difficult to do what I just said, it's easier for some types of personalities. If this type of approach is difficult to you, it is the exact type soft skill you should start practicing asap. It's in many circumstances more important than your technical skills and it's determinant in your career growth.
I don't know you, but venting online reminds of my not so much younger self, so I hope what I said helps you deal with this type of situation.
By the way, count to 10
Regards,
Fábio
To alcohol! The cause of, and solution to, all of life's problems - Homer Simpson
----
Our heads are round so our thoughts can change direction - Francis Picabia
modified 23-Sep-14 11:11am.
|
|
|
|
|
Frequently the organizational culture inadvertently forces this situation to evolve. When people have to get their jobs done and can imagine a way to improve it, but are blocked from having it done professionally by time or budget constraints, they will cobble up something on their own. I would be surprised if people who do this would not welcome some constructive interaction from a skilled developer ... but as you hinted above, you're "not directly involved in what he does." Probably the org-culture blocks you from helping him in several ways, too.
|
|
|
|
|
If he codes fast and it works then you will never win.
I have worked with wonderers,
you wonder how they every made,
you wonder how there code works,
you wonder how to get ride of the person
and then soon you wonder why their walking me out.
|
|
|
|
|
What I'm hearing is that you don't like the way this guy does his job because you could do it better. It also sounds like you want some recognition for being better at his job than he is. Get over yourself.
He's found a tiny puddle that he can be the big fish in. It sounds like its gone to his head a bit, but aside from that let him have his day.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
Ive had my own small software business for over 20 years and one of the things I was glad to leave behind was maintaining legacy code written by morons or working in a 'team' with them. some of these people only got the job because there was no-one else around or they came across as 'bright' and quick learners in their interview, but who couldn't adhere to any sort of standards or write maintainable code - as I say it was 1991 the last time I had to do it but still remember the frustration, so I feel your pain m8
|
|
|
|
|
You might ask yourself why he is highly regarded by management. It may be true that you are light years ahead of this fellow in programming skill but he is clearly ahead of you in the things that matter to management - providing good ideas that work. I have seen it too often that programmer think that their programming skill is what matters when in reality no one,except programmers, give a darn. They want ideas executed quickly. That's what pays the bills. Rewriting his ideas in "proper code" will do nothing - I repeat, nothing for your career. Take a page from his book - find a great idea code it quickly and pitch it to the bosses.
|
|
|
|
|
As people suggested many things here, they are all good. But if you don't have the power to change the mind of that programmer or the management (either persuasive, or by authority) and cannot provide solid examples of his failures (or that doesn't work), I suggest to let it fail. Failures may be bad for business, but business people does not see failure so complete (it is just another step) and keeping company from failure (usually hiding it through more work) is not only getting you anywhere better, but also will make you wish to work go away. Quitting a job will is always an option. A lot of people see a lot of drama in that, but I consider it as a fair option - the company management should not be easily persuaded, but objectively judging.
And a person quitting is strong signal to management that something is wrong. If they see you useful, they'll try to hold on, explaining the problem to them after such a step will probably make them listen. Point the exact problem (not the person, the person's code, the current architecture, etc.) in the right language will make them at least think about it. Sooner or later something will fail and they'll remember your words.
|
|
|
|
|