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

11–20 of 55 posts

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

#11

Post by aaronem »

logfromblammo wrote: post #5

The 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…

For those like me unfamiliar with what's here termed the "psycho-clueless-loser model", it appears to be what is more commonly termed the "Gervais Principle", and you can find what looks to be a reasonable overview of the subject here: http://www.ribbonfarm.com/2009/10/07/the-gervais-principle-o...

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

#12

Post by AnimalMuppet »

chazu wrote: post #9
mwcremer wrote: post #4

Earlier quoted context omitted.

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.

If I understood the article, the pros were technical, and the cons were political. And, here's some actual good advice: Never try to solve a political problem by technical means (or vice versa).

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

#13

Post by TempleOSV207 »

There are no sockets. All memory is identity mapped. It is ring-0-only. All tasks on all cores can access all memory freely and directly at all times.

STdOut is not even serialzed. You print $SP,"",BI=11$ as text and you pass it binary graphic data. It dispays on the command line.

60fps a callback routine is called to redraw each windown. All windows are redrawn.

There is a reason they make GPUs. It's a hundred times faster.

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

#14

Post by eshvk »

> 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.

I am not being too cynical in thinking that this doesn't exist? I mean this is the core of how teams interact. Politics is reality. So is territory. Fuck decorum, though.

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

#15

Post by aeturnum »

This story leaves me with a completely different takeaway message than the author got.

It seems like he got involved in situation he didn't understand and may have risked his job (and perhaps the jobs of others) in the process. His process demo'd better, but he has no idea why some people were opposed to it.

What if this was a product that emphasized security, and he inadvertently violated the security model to get speedups? Understand the processes you're working on, and the problems that your co-workers are dealing with. In this case, he could have made his life easier by identifying the "faction" that wanted what he wanted and working with them.

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

#16

Post by DavidBradbury »

jorgeleo wrote: post #8

I 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…

The point wasn't to stay out of people's code. He used that "advice" as a reminder to not be what those people were/are.

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

#17

Post by Spearchucker »

aeturnum wrote: post #15

This story leaves me with a completely different takeaway message than the author got. It seems like he got involved in situation he didn't understand and may have risked his job (and perhaps the jobs of others) in the process. His process demo'd better, but he has no idea why some people were opposed to it. What if this was a product that emphasized security, and he inadvertently violated the security model to get s…

"Understand the processes you're working on, and the problems that your co-workers are dealing with."

Go further than that. Step back and look at the environment as a whole. It helps to spend time understanding a situation before assuming you have appropriate ideas about changing it (ref. below).

https://www.wittenburg.co.uk/Entry.aspx?id=46870dcd-70cb-4ef...

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

#18

Post by atom-morgan »

bingofuel wrote: post #10
naterator wrote: post #3

Earlier quoted context omitted.

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.

I've done it multiple times now since I've graduated from college. It makes you uneasy each time and shortly afterwards I definitely questioned myself. But today, I don't regret it one bit.

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

#19

Post by larrydag »

Spearchucker wrote: post #17
aeturnum wrote: post #15

This story leaves me with a completely different takeaway message than the author got. It seems like he got involved in situation he didn't understand and may have risked his job (and perhaps the jobs of others) in the process. His process demo'd better, but he has no idea why some people were opposed to it. What if this was a product that emphasized security, and he inadvertently violated the security model to get s…

" Understand the processes you're working on, and the problems that your co-workers are dealing with. " Go further than that. Step back and look at the environment as a whole. It helps to spend time understanding a situation before assuming you have appropriate ideas about changing it (ref. below). https://www.wittenburg.co.uk/Entry.aspx?id=46870dcd-70cb-4ef...

In my opinion I think the author did try to address the big picture. He brought it to his boss, and his boss's boss. If ideas are commodities worth trading then why was the market closed from the top down? This is a lesson in corporate culture which I think the author explains quite well.

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

#20

Post by jskulski »

aeturnum wrote: post #15

This story leaves me with a completely different takeaway message than the author got. It seems like he got involved in situation he didn't understand and may have risked his job (and perhaps the jobs of others) in the process. His process demo'd better, but he has no idea why some people were opposed to it. What if this was a product that emphasized security, and he inadvertently violated the security model to get s…

Then someone would have been able to explain objectively why his solution was less good. It wouldn't have been this wishy washy political struggle that only hurts the department and technology.

I'd prefer to lose a job that was caught up in such a scuffle. (Of course, I say that in times when a job can be got).

Post reply on HN