Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Best Programming Advice I Ever Got (2012)

russolsen.com

Post reply on HN
Print view View original

81–90 of 247 posts

Re: The Best Programming Advice I Ever Got (2012)

#81

Post by darkerside »

jeklj wrote: post #62

I did something similar once but failed to glean such a valuable lesson from the experience. My takeaway was, those people are touchy so leave their shit alone. Not because it’s right but because I’m just trying to get through my day, and i don’t need more politics in my working life. People can be assholes, it’s just how it is sometimes so let them be. Among my own team, if I raise points or ideas that get disregard…

I've fallen in the same trap. And you're right, you can't fight every battle. But I think the best approach is not to make it a battle in the first place. Sometimes bringing things up in the right way and with the right energy helps people be more receptive to your advice.

Re: The Best Programming Advice I Ever Got (2012)

#82

Post by SagelyGuru »

It reminded me of how I once got into hot water with the Boss over introducing a binary search into their huge customer file search and update operation, which used to take three hours to run. When the program stopped in five minutes, everyone was mortified that I had broken it.

Re: The Best Programming Advice I Ever Got (2012)

#83

Post by hutzlibu »

andrewstuart wrote: post #55

The conclusions I completely disagree with. If you discover a way to make the system 100X faster, and the reason is someone else's code, then tell that programmer, and only them, and tell them gently what you found and leave it with them to be the person who implements it, or offer to implement a solution together if they want to. They may or may not take sole credit but it doesn't matter. Definitely do not sneakily…

"They may or may not take sole credit but it doesn't matter."

If you improved something greatly then it is your credit and it matters that it was you and not someone else. IP conflicts are a different story, one that I would like to see avoided with OpenSource becoming standard.

Re: The Best Programming Advice I Ever Got (2012)

#84

Post by nimonian »

porphyrogene wrote: post #9
pmikesell wrote: post #5

Earlier quoted context omitted.

In my experience, the probability of this happening increases proportionally with the size of the company.

Wouldn't that mean that the probability is always 100% because the company is always 100% of its current proportion?

So, I think you're confusing 'probability' with 'cardinality of the set of successful outcomes' (let's call that k). If k is proportional to the size of the company (n, say), then you are absolutely right that k/n (i.e. the probability) will not change as n changes. But the statement actually says that the _probability_ is proportional to n, not k. So no, the probability is not constant.

The idea of the probability being directly proportional to n is not technically correct for other reasons (with large enough n, this would allow for probabilities larger than 1), but not for the reasons you're mentioning here.

Perhaps more importantly, the meaning of the comment is independent from this pedantry and should be interpreted less literally so we can focus on its actual meaning.

Re: The Best Programming Advice I Ever Got (2012)

#85

Post by hutzlibu »

DavidWoof wrote: post #53
darioush wrote: post #24

Earlier quoted context omitted.

Building something that works in a short period of time when a team has failed to do that over several quarters demonstrates little more than the fact that your organization has hired people less competent and productive than you. Unless you want to work where you're the least competent person, this isn't necessarily bad. Hiring highly competent people to build software does not scale as well as hiring (many) more le…

> Hiring highly competent people to build software does not scale as well as hiring (many) more less competent people. I can't imagine an aphorism I disagree more with. I constantly come across companies with similar-sized platforms where one has a development staff 10 times the size of the other (both in cost and size), all due to the complexity and quality of the code. In the long run, few things are more expensive…

"In the long run, few things are more expensive than a mediocre programmer. "

Disagree very much. Mediocre programmers are very good for mediocre tasks, of which there are plenty of. The problem is only, if mediocre programmers work on advanced tasks.

Re: The Best Programming Advice I Ever Got (2012)

#86

Post by jpnelson »

ken wrote: post #63

There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency in order to create a bigger global efficiency. That's life. In my experience, though, this is a much bigger problem in software because nobody really knows what they're doing. There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Corr…

That's an interesting perspective. I think you're right that we don't have "correct" and standard answers because we don't assume total competency, but I think we don't assume total competency because software development (both the requirements and the practices) change fairly rapidly. I wouldn't be surprised if in 100 years, we're still trying to figure out standards, if the pace keeps up.

Re: The Best Programming Advice I Ever Got (2012)

#87

Post by perpetualcrayon »

I always worked for small companies early in my career for exactly this. The suspicion that large corporations are driven by egotistical sociopaths.

Now that I've worked for a large corporation I have proof that I was right (YMMV). Not only that, egos can become such a barrier to progress that projects within these companies become what I would consider criminally incompetent.

Re: The Best Programming Advice I Ever Got (2012)

#88

Post by Koshkin »

The idea (and practice) of "code ownership" is one of the most annoying things. First of all, it creates an atmosphere of some kind of laziness and lack of responsibility on the part of the individual team members (perhaps, not all, but still) for the results of the entire team's work. It also promotes what in my view is a rather insidious habit of assuming that if someone has wrote a piece of code long ago they are still responsible for it and, moreover, they are ready to instantly answer any question about it, as if it is supposed to stay fresh in the developer's mind forever.

Re: The Best Programming Advice I Ever Got (2012)

#89

Post by Cpoll »

> I had supplied a war winning weapon to one organizational faction and the other factions were not happy

The real problem is that there are adversarial relationships within the organization. It can be an ego issue, or perverse incentives, or conflicting departmental objectives, or short-term thinking. Anyone who doesn't spend their time focused on politics or covering their ass will still have their motivation sapped, and soon no-one will care about making the product better.

The non-dysfunctional response is "great initiative, we'll get a meeting together and discuss the pros and cons of implementing your spike."

Re: The Best Programming Advice I Ever Got (2012)

#90

Post by leaveyou »

ken wrote: post #63

There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency in order to create a bigger global efficiency. That's life. In my experience, though, this is a much bigger problem in software because nobody really knows what they're doing. There's no industry standard way to do almost anything. You can argue about "use Foo!" or "don't use Foo, use Bar!" and there's no one Corr…

>>There's definitely value in respecting boundaries. Sometimes you have to take a small local inefficiency..

I don't think anyone argues with that. It's just that sometimes some of the biggest impostors hide behind "boundaries".

>>This will continue to be a problem for the next 100 years until we figure out the right way to make good software.

A lot of people figured it out already.. but those are a minority and the field is fueled continually with poorly instructed people. The Business can't distinguish quickly between these two categories and often it does not even bother (good interviewing is hard or expensive) because (in Europe) it's not the software efficiency or other quality making the profit.

Post reply on HN