It's not a programming advice. Similar counsel is dispensed in various tech, and non-tech fields, because it's about relations with other people which sometimes could be more important than efficiency for one's career, or comfort. However, to discourage from thinking about improving other programmers code, and call it "the best programming advice"? No way.
The Best Programming Advice I Ever Got (2012)
91–100 of 247 posts
Re: The Best Programming Advice I Ever Got (2012)
#92"But the best way to have a future is to be part of a team that values progress over politics, ideas over territory and initiative over decorum." Recently had to quit my job because of exactly this. People will sabotage things simply because they want the useful idea to be theirs.
"People will sabotage things simply because they want the useful idea to be theirs."
Not just that, they will sabotage things if it makes them more profitable, which probably happens in thousands companies worldwide everyday.
1. Get a contract.
2. Sell some crappy software to the customer.
3. Wait for them to ask for more speed.
4. Complain it's their fault because their hardware is too old.
5. Offer to either install new hardware or rewrite the software.
6. Profit!
Guess what happens if someone makes the software perform optimally at step 2.
Re: The Best Programming Advice I Ever Got (2012)
#93"But the best way to have a future is to be part of a team that values progress over politics, ideas over territory and initiative over decorum." Recently had to quit my job because of exactly this. People will sabotage things simply because they want the useful idea to be theirs.
"People will sabotage things simply because they want the useful idea to be theirs." Not just that, they will sabotage things if it makes them more profitable, which probably happens in thousands companies worldwide everyday. 1. Get a contract. 2. Sell some crappy software to the customer. 3. Wait for them to ask for more speed. 4. Complain it's their fault because their hardware is too old. 5. Offer to either instal…
It requires an inefficient mind to plan obsolescence.
Re: The Best Programming Advice I Ever Got (2012)
#94"But the best way to have a future is to be part of a team that values progress over politics, ideas over territory and initiative over decorum." Recently had to quit my job because of exactly this. People will sabotage things simply because they want the useful idea to be theirs.
"People will sabotage things simply because they want the useful idea to be theirs." Not just that, they will sabotage things if it makes them more profitable, which probably happens in thousands companies worldwide everyday. 1. Get a contract. 2. Sell some crappy software to the customer. 3. Wait for them to ask for more speed. 4. Complain it's their fault because their hardware is too old. 5. Offer to either instal…
The way capitalism is supposed to work is you quit this job and open a shop which does the same thing as the existing company but doesn't artificially reduce speed, using that as a competitive advantage. The end result is that the first company is required to either adopt your strategy or fail, either solution leading the consumer to a better result.
Re: The Best Programming Advice I Ever Got (2012)
#95I got hired at a Fortune 250 to rewrite a system, from the ground up, that had been running for 5 years. I rewrote it in about a year and a half. Huge success; 1000 happy users.
What I learned over time was that "the" person responsible for the group that was _supposed_ to be writing this sort of software in the company had been trying, for 10 years, to make something like it, with a whole team of contractors. In fact, it was his initial failure that caused my boss to write the first version of the program. When they saw that my boss had hired me, they doubled their efforts.
Their version of the idea was total garbage. Nobody would use it. It was terribly slow, clunky, and had a fatal flaw that would have caused people MORE work than just not using their program.
The boss of their group managed to get one of his underlings moved above my boss. He told us to stop working on my program. We did. They brought it Microsoft consultants to try to make their version suck less. It didn't work.
I suggested many things to work together. Rebrand. Code features they needed. Use some of their software. Whatever. All rejected out of hand.
We BEGGED our boss to IMPLORE the other manager to AT LEAST fix the "fatal flaw" of the other version. He agreed to, but we knew he wouldn't.
We released a bug fix for production. The other manager lost his mind, and got our manager to force us to hand over the code to his group. It took them TWO YEARS to make a single change. My program happily ran like a clock during the interim.
They finally gave up on their version.
My boss was put on a PIP. I was put on the tiniest project possible (which was completely doomed anyway), and forced to write what should have been a quick and dirty web app as a corporate, Java monstrosity. (But I repeat myself.)
In my first meeting, the other manager's toady told me to my face that he was going to kill the project I was hired for. In 4.5 years, I never even met the other manager, though he sat 50 feet away from my last cube.
There was no winning. My boss was very politically savvy, and just plain nice. There was nothing he could do. I stayed completely out of it. I did the job I was hired to do, and embarrassed the wrong people. He was written up. I was put out to pasture.
You can say that I should have done things differently. Maybe. Maybe not. What it tells me is that I was in the wrong company. Which sucks, because I could have written LOB tools like this for the rest of my career there. But this sort of dimness of vision is rampant throughout the company concerning anything related to IT. According to them, the only way to write software is to follow a strict waterfall methodology, in Java, with overseas contractors.
Making the company suck to work at, and the act of wasting millions of dollars, because it helps you build a political fiefdom, is an idea that needs to be rooted out and eliminated by the C levels. Why does this not happen? Instead, one of the C's just did a "post-mortem" on this whole fiasco, and the result was that IT needs to be "more aligned" with the business, and have better "communication."
Really? That's the level of acumen of our C-levels? They can't smell the metric buttload of BS that was shoveled in that meeting? OK, then. Good luck in the future!
I start a new job on Monday. Crossing my fingers that they will be open minded. I wonder if my old company will still be viable in 10 years.
Re: The Best Programming Advice I Ever Got (2012)
#96Killing sacred cows in software dev is a crucial part of the overall process if you’re going to keep a product alive long term. Learning HOW to kill a sacred cow without pissing everybody off around you is a crucial part of learning to become a senior leader. Once you know something will work, there’s a HUGE amount of groundwork to get social traction for a change. Without it, you’ll get the change but not the “team…
> Once you know something will work, there’s a HUGE amount of groundwork to get social traction for a change. Without it, you’ll get the change but not the “team progress”.
You're not wrong, but equally I'd argue that if you need a huge amount of groundwork to implement change, you're probably in the wrong organization.
Good organizations value good ideas, irrespective of who thought of them.
Re: The Best Programming Advice I Ever Got (2012)
#97It's not a programming advice. Similar counsel is dispensed in various tech, and non-tech fields, because it's about relations with other people which sometimes could be more important than efficiency for one's career, or comfort. However, to discourage from thinking about improving other programmers code, and call it "the best programming advice"? No way.
You didn't read to the end. The author recognizes this as patently bad advice, and was glad to have received it so he was conscious of what not to do.
Re: The Best Programming Advice I Ever Got (2012)
#98Earlier quoted context omitted.
I do not understand why you were treated as if you wrote viral code which wiped all networked storage of the company. Did anyone ever say why you were treated like an infectuous disease after doing something good, which would benefit everyone?
The fact that he was a foreigner provides a hint. It seems there's a general fear in the US of foreign workers taking the jobs of citizens. I wonder, is it not possible to switch employers when you have a work visa?
there's a general fear in the US of foreign workers taking the jobs of citizens
Comments from our idiot president and his ilk aside, there is not. I'm willing to entertain discussions to the contrary, but this is far from my experience either here in the Midwest, or on the East Coast where I previously worked.
Re: The Best Programming Advice I Ever Got (2012)
#99I made same mistake, I saw how old system underperformed and that I could make it better, faster, more stable and bring higher profit. When I presented that my boss, next I know I’m in room with HR, my bosse’s boss and technical lead (who was practically executive director), to my surprise boss started conversation with “your actions concerning me...” they told me to give all the related code, documents and remove ev…
When you presented what to your boss, exactly?
Did you suggest "I can make it better, faster, more stable...?" or did you go ahead and make the change and say "see?" Were you in a position where you should even have been thinking about this system?
I wonder what steps in this story you're leaving out?
Re: The Best Programming Advice I Ever Got (2012)
#100Oh man. I am so glad that I had the opportunity to work at an organisation that actually celebrated a few such improvements i made. There was a data ingestion job which inserted 4 million keys into Redis. It was awfully slow. I sped it up a lot using the Redis protocol format and redis-cli --pipe. They praised me for that. There was a dashboard which queried data from a MongoDB collection and calculated some counts.…
It's not about the tech, it's about the politics. If everybody agrees Redis is the way to go, sure, go ahead and optimize it. But what if there's a VP who's been arguing that using Redis is a mistake and you should be switching to MongoDB?