Programming is Terrible • Hacker News Board

Re: Programming is Terrible

#41

Post by kawsper » Wed, Jan 02, 2013, 5:54 AM UTC

ddw wrote: post #30

chrisbennet wrote: post #2

Bitter much? I've been fortunate to have never worked with bad programmers. Some were not super experienced but still they cared . They did their best. A bad programmer would be someone who didn't care about the next guy. As for "A" players, they exist. They develop code that others can understand yet probably wouldn't haven't have come up with themselves. Hard work does not make you an "A" player. Intelligent work d…

> A bad programmer would be someone who didn't care about the next guy. Unfortunately I wish this was true to non-programmers. But a "successful" programmer ships without worrying about how difficult it is to add a feature or to debug a problem when they're gone. At least that's my experience in my current job where I'm mostly maintaining shitty code. And I know it's a culture problem too.

Yup, the company hero programmer ships and meet deadlines.

While all the "bad" programmers sits there, worrying about stuff breaking in the wild, with only their 1% code-coverage tests to verify that everything is working.

Re: Programming is Terrible

#42

Post by aut0mat0n1c » Wed, Jan 02, 2013, 6:19 AM UTC

It seems like to me the problem is not that academia isn't interested in reliability, its just that they are solving the wrong problems. I am thinking about Byzantine Fault Tolerance specifically, as from what I understand it is a hot topic of research at the moment. That seems to me to be an example of academic research that is next to useless for practitioners.

BTW that quote is from Leslie Lamport, maybe its so obvious he didn't think it needed a credit.

Re: Programming is Terrible

#43

Post by benwerd » Wed, Jan 02, 2013, 6:51 AM UTC

coaxmetal wrote: post #29

hey cool I thought of tef when I saw the title of the post and it was tef!

I'm so pleased tef is blogging this stuff. It's fun to see it in one place.

Re: Programming is Terrible

#44

Post by joesb » Wed, Jan 02, 2013, 7:15 AM UTC

rayiner wrote: post #10

This blawg has much potential. Love the post about marginal expected value.

On the other hand, many if not most businesses run just fine getting only 20-40% profit. Some business even run on being able to get only 2-5% profit for each investment, but re-invest tens of times per month. Why must software project have 500% profit before it makes sense to kick-off.

Re: Programming is Terrible

#45

Post by eikenberry » Wed, Jan 02, 2013, 7:21 AM UTC

kenjackson wrote: post #22

This guy gets it wrong in his last post on reliability (but the other posts seem reasonable). Reliability is hard because we continue to move the goalpost. I can write a pretty reliable program to compute sin/cos tables or to sort a phonebook or to do some basic projectile trajectory. But those aren't even table stakes anymore. Today a first year undergrad student might be expected to write a program that in 1970 the…

> And lastly, this is IMO, a corollary for why ageism is so persistent in our field.

Out of curiosity, are you from the valley area? It has been my experience that ageism is really only that big a deal there. Everywhere else I've worked (PDX, ATL mostly) I have seen no sign of ageism. Also it fits with the valley's general culture and economic setup. Everyone I know in the valley is young and single and live with other young and single people. As soon as they get older, meet someone and think about a family they leave and go somewhere that they can get a house and situate themselves.

Re: Programming is Terrible

#46

Post by Confusion » Wed, Jan 02, 2013, 7:24 AM UTC

kenjackson wrote: post #22

This guy gets it wrong in his last post on reliability (but the other posts seem reasonable). Reliability is hard because we continue to move the goalpost. I can write a pretty reliable program to compute sin/cos tables or to sort a phonebook or to do some basic projectile trajectory. But those aren't even table stakes anymore. Today a first year undergrad student might be expected to write a program that in 1970 the…

  Because I can capture 70% of your experience in your code 
  -- in your library -- and build directly on top of it.

If you use my library, you have not captured my experience to write said library. If you need to write any higher level library of your own, the most problems you will face are exactly the ones I already solved once. I could write that library faster and more correctly than you. (the words 'you' and 'I' do not (necessarily) denote you and me)

Re: Programming is Terrible

#47

Post by chipsy » Wed, Jan 02, 2013, 7:29 AM UTC

kabdib wrote: post #28

kenjackson wrote: post #22

This guy gets it wrong in his last post on reliability (but the other posts seem reasonable). Reliability is hard because we continue to move the goalpost. I can write a pretty reliable program to compute sin/cos tables or to sort a phonebook or to do some basic projectile trajectory. But those aren't even table stakes anymore. Today a first year undergrad student might be expected to write a program that in 1970 the…

> Experience means very little Perhaps. But I believe that good engineers have a number of cool failures in their past. > Because I can capture 70% of your experience in your code -- in your library -- and build directly on top of it You can capture /some/ of someone's experience this way. But don't confused the ability to _use_ the novel Moby Dick with the ability to _write_ Moby Dick. These are two very different t…

To add to the "layers" aspect, the young hotshot coders of the world are also some of the worst at making marketable products, because they've become used to making an 80% prototype and then moving on to the next thing, which means that they haven't experienced this yet:

http://www.gocomics.com/calvinandhobbes/1986/11/26

Learning software "in the large" still basically requires you to drive the bigger and bigger trucks over(more features) until the bridge(your architecture) breaks. It can't be properly conveyed with any weekend project or library.

Re: Programming is Terrible

#48

Post by dschiptsov » Wed, Jan 02, 2013, 8:05 AM UTC

Programming is a Joy.. Ignorant cowboy-coding is suffering.) Read (learn) before you write. 80/20 rule works here.

Re: Programming is Terrible

#49

Post by rohamg » Wed, Jan 02, 2013, 8:24 AM UTC

moocow01 wrote: post #24

Programming is honestly a very tricky sector of work to understand how to make progress in the practice of it from here on out. You have essentially an almost infinite number of ways to get to an endpoint with very few real constraints... this is good and bad. We have lots of creative freedom within the constraints of code to achieve a certain piece of functionality. For example, authentication - Ive seen it done som…

I see this as a positive, not at all a negative. Programming is rare in that the field lends itself very well to creative destruction / natural competition / evolution, for many of the reasons you describe. The process is chaotic on an individual level but the population as a whole moves forward far more intelligently than any centralized process could hope to mimic.

Re: Programming is Terrible

#50

Post by nnq » Wed, Jan 02, 2013, 8:48 AM UTC

kabdib wrote: post #40

kstenerud wrote: post #34

Earlier quoted context omitted.

"The fact that newer programmers don't understand the foundation they build on is irrelevant, since few need to look behind the current." Every time I think along these lines something comes along that pushes us closer to the metal again. 10 years ago I thought that the usefulness of my knowledge of assembly language had reached its end. After all, what use was it when I was writing enterprise applications in Java! A…

There are many classes of products that require what I like to call "fractal attention to detail." These include most consumer goods (which are usually cost and performance constrained), man-rated stuff that has to work (aerospace, medical), and products with stringent security requirements (game consoles, smart cards). By fractal I mean that you can have good abstractions, but you can't afford black boxes, and desig…

Why can't you have black box abstractions in things that "have to work"??

And even "has to work" can be relative, as if you can prove that something will work for a p value small enough to guarantee risk of failure is small enough in the next 100 years for a device/system that will at most stay in use for 10 it good enough... And if you're not constrained by power use or computing power, you can also use redundant subsystems: I imagine something like a satellite, receiving high radiation that consistently corrupts cache or RAM but runt 5 identical OSs on five identical subsystems and on every "high stakes" decision it does a "voting session", choosing the result of a function with the most out of 5 votes and resetting the state of the disagreeing systems with the winning ones, and a similar type of reliabilty by duplication for medical devices or aircraft systems... And going further, you can always replace an expensive reliable satellite with a swarm of cheaper ones that can fail. I think we'll choose the "swarm way" for more and more things and this will relax reliability requirements for individual components and at the whole swarm level we'll have "good enough" statistical reliability instead.

And any "swarm" can conceptually be seen as a black box, once you accept its probabilistic nature and the low but measurable likelihood of it being wrong, and maybe using a "swarm of swarms" if one swarm's p value of being true is not good enough for your application.

The "fractal attention to detail" seems needed when you need both reliability and you have serious power or computing resources constraints. And since power usage per flops is always decreasing, the number of such "dual constraint" cases should get smaller...

EDIT: typos and + pre-last paragraph to clarify what I meant