The Best Programming Advice I Ever Got (2012)
russolsen.com
The Best Programming Advice I Ever Got (2012)
1–10 of 55 posts
Re: The Best Programming Advice I Ever Got (2012)
#2Good read, BUT the advice is stay away from Drama and especially work Drama. Seems to me 50% of people are damaged immediately by work Drama and the other half die slowly with maybe one or two sort of winners.
I would go work somewhere else and stay happy.
Re: The Best Programming Advice I Ever Got (2012)
#3Good read, BUT the advice is stay away from Drama and especially work Drama. Seems to me 50% of people are damaged immediately by work Drama and the other half die slowly with maybe one or two sort of winners. I would go work somewhere else and stay happy.
Yea, the lesson is: If you find yourself in a situation like that, bail out as fast as you can. When we're young we are often not taught—or more importantly we do not have the opportunity—to simply GTFO of the crappy situation we're in (Family, Bullies, etc.). It has tragic consequences both early in life and later on. It's (one of the reasons) why we get school shooters, why people stay at crappy companies when they don't have to, why people stay in destructive relationships.
Modern society often allows us the freedom to avoid people and situations we can't control but don't want to be in. For the love of god, please take advantage of that.
Re: The Best Programming Advice I Ever Got (2012)
#4Good read, BUT the advice is stay away from Drama and especially work Drama. Seems to me 50% of people are damaged immediately by work Drama and the other half die slowly with maybe one or two sort of winners. I would go work somewhere else and stay happy.
I read his advice as, "Don't be That Guy."
Re: The Best Programming Advice I Ever Got (2012)
#5The lesson is that the system is often more than just the computer software. The requirements may be more than just the software requirements.
I was fortunate to recognize that early at my current job. We have boatloads of software requirements documented, but the prime directive is not even spoken aloud: "Produce 40 billable hours per week, for each employee, forever."
And that is why the database is a mess and the code sucks beyond all reason. Any reduction in technical debt directly translates to a reduction in the perception of work being done. In short, the customer knows nearly nothing about software development, is willing to pay for status reports, process documentation, and meeting minutes rather than working code, and has a budget completely independent from the value of the work product.
Have you ever looked into some code and seen a WTF block, and it turned out to be a workaround for a bizarre bug? Here, the entire code base is the WTF block. The bug is in the human organization. I do not have the permissions to commit anything to that source tree. So I suck it up and send out resumes.
You don't fix anything until you first understand why it is broken. In the context of the CAD rendering, it is likely that some people had invested a lot of effort into convincing the management that their laziness was actually hard work plus frustration at their resource constraints. Think like Wally from Dilbert. That slow rendering is a system-enforced cap on productivity, slowing down the fastest workers.
In the psycho-clueless-loser model, that is the losers getting a leg up on the clueless. A psycho would have first manipulated the political situation for personal advantage before releasing the fixed code. A loser would have left it alone as already being to their advantage. Don't be clueless, folks.
Re: The Best Programming Advice I Ever Got (2012)
#6Great article. I was just thinking "whoever told you that was high" when the author pivoted and said it was bad advice. The first comment was spot on...if the current is dragging you toward the drama, swim up the shore to a new gig.
Re: The Best Programming Advice I Ever Got (2012)
#7Every computer has a GPU. It's two orders of magnitude slower with no GPU.
Re: The Best Programming Advice I Ever Got (2012)
#8I think that the advice, if taken literally, is a bad advice.
But it does point to the fact that the system is not just the technology, but also the people around it
I think that a better way to go about it was to comment first with the proper people that you MIGHT be able to make it run faster before doing anything (all though you know that you already did it). And drop the case if they don't want it.
I can see that somebody might want to move the drawing calculation process to a more powerful box serving more clients, and distribute the client with a different license... in other words, there could be a business case for the original configuration, and knowing it might help you to discover the negative stakeholders (the people interested in the status quo)
Should you always stay out of others people code? I think not, I think that there is a place for it. But from there to modify and publicize the modifications there is a big distance. Some people treat their code as their baby, and no parent like their kid criticized.
Re: The Best Programming Advice I Ever Got (2012)
#9Good read, BUT the advice is stay away from Drama and especially work Drama. Seems to me 50% of people are damaged immediately by work Drama and the other half die slowly with maybe one or two sort of winners. I would go work somewhere else and stay happy.
I read his advice as, "Don't be That Guy."
That's an important corollary to the author's actual point, if you ask me. Sure you shouldn't make golden calves out of bad old code, but also don't be the guy that mercilessly hacks apart other people's code without allowing them to defend it. Instead have a socratic dialogue about the pros and cons of different approaches to the problem.
Re: The Best Programming Advice I Ever Got (2012)
#10Good read, BUT the advice is stay away from Drama and especially work Drama. Seems to me 50% of people are damaged immediately by work Drama and the other half die slowly with maybe one or two sort of winners. I would go work somewhere else and stay happy.
Yea, the lesson is: If you find yourself in a situation like that, bail out as fast as you can. When we're young we are often not taught—or more importantly we do not have the opportunity—to simply GTFO of the crappy situation we're in (Family, Bullies, etc.). It has tragic consequences both early in life and later on. It's (one of the reasons) why we get school shooters, why people stay at crappy companies when they…
We are also not taught how to make the decision to GTFO. I've recently had to make such a decision and really had no prior experience to based anything on. It was a completely new experience.
Yes I eventually made the decision to GTFO but it's still lingering in the back of my head if I made the right one.