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

Mastering Programming (2016)

facebook.com

Post reply on HN
Print view View original

101–110 of 123 posts

Re: Mastering Programming (2016)

#101

Post by [deleted] »

bcbrown wrote: post #85
gedrap wrote: post #50

Extremely disappointed in this post to the point where I believe that the only reason people upvote this is because it's written by Kent. A lot of it reads just like motivational instagram posts. For example: > Call your shot. Before you run code, predict out loud exactly what will happen. M, okay, but what exactly do you mean by that? Or even poetic, kind of: > Rhythm. Waiting until the right moment preserves energy…

> > Call your shot. Before you run code, predict out loud exactly what will happen. > M, okay, but what exactly do you mean by that? I frequently do a variant of this, although not always out loud. One way to debug a problem is to randomly vary various bits of the program until the problem no longer appears. Another way to debug a problem is to use the scientific method: develop hypotheses, then test those hypotheses…

[deleted]

Re: Mastering Programming (2016)

#102

Post by [deleted] »

bcbrown wrote: post #85
gedrap wrote: post #50

Extremely disappointed in this post to the point where I believe that the only reason people upvote this is because it's written by Kent. A lot of it reads just like motivational instagram posts. For example: > Call your shot. Before you run code, predict out loud exactly what will happen. M, okay, but what exactly do you mean by that? Or even poetic, kind of: > Rhythm. Waiting until the right moment preserves energy…

> > Call your shot. Before you run code, predict out loud exactly what will happen. > M, okay, but what exactly do you mean by that? I frequently do a variant of this, although not always out loud. One way to debug a problem is to randomly vary various bits of the program until the problem no longer appears. Another way to debug a problem is to use the scientific method: develop hypotheses, then test those hypotheses…

[deleted]

Re: Mastering Programming (2016)

#103

Post by hinkley »

wyldfire wrote: post #26
hota_mazi wrote: post #24

Having spent entire days years ago poring through the JUnit 3 source code and having been completely dejected by the quality of the code there, I don't really trust Kent Beck to give advice on anything related to programming.

Maybe his strength is in recognizing and articulating the qualities of good programmers and not in programming itself?

I had a friend in college who wanted to be a writer. She was paranoid about spending too much time on comparative lit and setting the bar too high for herself before she ever got good at it.

As far as I can tell, she didn't avoid that trap, despite identifying it. Occasionally I wonder if I avoided it. There are so many ways for a project to fail and when you know too many you can become a nervous wreck. Over most of the course of the '10s I've noticed that I'm a lot more comfortable with certain classes of imperfection, because they are immaterial to the job at hand, or represent an unknown that we haven't tackled yet (if you don't know how something should actually work, making it 'perfect' might make it perfectly wrong, and then where are you?). It's like a chess game. Half the board is full of pawns to be sacrificed for some higher priority. You have a contingency plan for any threat, but you can't act on them all at once.

Probably everybody does this, but their set points are different than mine, so we argue over code reviews.

Re: Mastering Programming (2016)

#104

Post by darioush »

jorgec wrote: post #80

"Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them." Right now, i am finishing a system that took me 2 weeks do develop. With the standard way, i should have finished it around January of the 2018.

I wish your comment alluded a bit more to the details.

Re: Mastering Programming (2016)

#106

Post by ashwinaj »

sloppycee wrote: post #96
ashwinaj wrote: post #87

Earlier quoted context omitted.

> completely dejected by the quality of the code there Please list a project of equal complexity that has been written beautifully from start to finish in your opinion. This myth of beautiful coding needs to stop! Code is not a masterpiece from Van Gogh, it needs to ship. This determines quality, not the usage of some obscure/mainstream/unreadable/oh-look-how-cool-I-am idiosyncracy of the language. If you ain't shipp…

How about Google's Closure Library: https://github.com/google/closure-library The code, imo, is some of the highest quality js I've seen. It is also incredibly comprehensive and easily as complex. High quality != shipping fast. They are separate quantities, it is easy to have one without the other but very rare to have both.

I'll take your assessment at face value (although a quick look at github repos, it seems that junit is way larger).

My point wasn't to ship crap, it was about obsessing on quality over actually shipping (and cutting some corners). This is something I learned at my first job, we obsessed over quality and never shipped. Guess what happened? :)

Re: Mastering Programming (2016)

#107

Post by samstave »

LrnByTeach wrote: post #82
vinceguidry wrote: post #51

> Multiple scales. Move between scales freely. Maybe this is a design problem, not a testing problem. Maybe it is a people problem, not a technology problem [cheating, this is always true]. The key to this is realizing that once you decide a problem is at a certain scale, the fix needs to be at that scale too. So you might have a data problem, a code problem, a workflow problem, a design problem, an architectural pro…

I would call this as The hierarchy of 'Troubleshooting Software Problems' ( as a parallel to Maslow's hierarchy of NEEDS). In order to fix a problem at certain Level, you have to go to 'Bottom Most' layer which is ROOT cause of the problem. >So you might have a data problem, a code problem, a workflow problem, a design problem, an architectural problem, a team problem, a project problem, an organizational problem, a…

More complex though, is the ripple effect each has on others, dependency on others etc...

Far more nuanced than Maslow's

A shitty team can produce great code - a great team can produce shitty code. A shitty leader can kill a great team. an existential problem can destroy the value of any data-set. etc...

overall I totally agree with you and OP, and thinking through this is a great idea.

Re: Mastering Programming (2016)

#108

Post by carapace »

ashwinaj wrote: post #87
hota_mazi wrote: post #24

Having spent entire days years ago poring through the JUnit 3 source code and having been completely dejected by the quality of the code there, I don't really trust Kent Beck to give advice on anything related to programming.

> completely dejected by the quality of the code there Please list a project of equal complexity that has been written beautifully from start to finish in your opinion. This myth of beautiful coding needs to stop! Code is not a masterpiece from Van Gogh, it needs to ship. This determines quality, not the usage of some obscure/mainstream/unreadable/oh-look-how-cool-I-am idiosyncracy of the language. If you ain't shipp…

Oberon.

Details in this excellent summary comment by someone else: https://news.ycombinator.com/item?id=9848097

I specifically recommend studying the "Project Oberon" book which is now available as a PDF from Prof. Wirth's own site, I believe.

Re: Mastering Programming (2016)

#109

Post by samstave »

antisthenes wrote: post #92
LrnByTeach wrote: post #82

Earlier quoted context omitted.

I would call this as The hierarchy of 'Troubleshooting Software Problems' ( as a parallel to Maslow's hierarchy of NEEDS). In order to fix a problem at certain Level, you have to go to 'Bottom Most' layer which is ROOT cause of the problem. >So you might have a data problem, a code problem, a workflow problem, a design problem, an architectural problem, a team problem, a project problem, an organizational problem, a…

It's not a data problem There's no way it's a data problem It was a data problem

heh, the famous "I can't believe that you would doubt me! I've gone through the data five times already... ...oh..."

Re: Mastering Programming (2016)

#110

Post by allenu »

kbuchanan wrote: post #46

A lot of the comments criticize the article for being inaccessible to beginners, and I think they're justified—without examples it's hard to know what the author is talking about without having first passed through the fire. Having said that, I think he's talking about a crucial part of programming that beginners simply don't appreciate: how to break big problems into small problems. In other words, how to unstick ch…

I would say don't work on the branches first. If something is simple and predictable, it can be done later. (This also allows you to slowly converge on a completion date since all the stuff you've put off is simpler and easier to understand and predict in terms of schedule.)

Best to work on the challenging, unknown items first, especially if they form the core that everything will rely on. It gives you time to work out the kinks in the overall architecture. It's much harder to change those things later and harder to predict how long it will take. It's also easier to mock out and fake the branches.

Post reply on HN