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

91–100 of 123 posts

Re: Mastering Programming (2016)

#91

Post by theptip »

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…

This article is explicitly not for beginners. It's for journeymen(/women) looking to become masters.

Re: Mastering Programming (2016)

#92

Post by antisthenes »

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…

It's not a data problem

There's no way it's a data problem

It was a data problem

Re: Mastering Programming (2016)

#93

Post by vinceguidry »

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…

I think the best way of thinking about it is to split problems up across levels. So if you have a code problem that you've worked out to be a design problem, you now have two problems. The higher level one needs to be fixed before you can fix the lower level one.

So the client complains about software behavior. You now have a client problem. You isolate the issue down to a problem in the data. You fix the data but the problem recurs. You now have two problems, a client problem and a code problem, that's generating the bad data. You go to change the code but find a design problem. You now have three problems. You have to solve the design problem so that you know how to fix the code, so that you can then go tell the client that his problem's fixed and here's a free month's service for your trouble.

Re: Mastering Programming (2016)

#94

Post by theptip »

d--b wrote: post #3

Distillating years of experience in such tiny concepts is a bit harsh on the reader. Without any concrete example, the advice could easily be very misunderstood, or not understood at all. Being a fairly seasoned developer myself, I kind of intuit what they mean, but I could very well be projecting what I think I am doing right into each of these, and conclude that I'm a master programmer... yay!

Perhaps this format is not for everyone, but I like these concentrated nuggets of wisdom. Sure, you could write a paragraph or two on each. But with this approach, each item gives the reader a prompt to think about, to identify areas in their own practice that need more focus and improvement.

Re: Mastering Programming (2016)

#95

Post by hinkley »

eric_b wrote: post #72
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…

The corollary to this is to never solve the problem at the wrong level. It's always a recipe for pain when you, say, have a data issue and you decide you'll solve it with some clever code. Or perhaps you have a fundamental design problem, but maybe you can just tweak the data...

There's a concept from SEI's CMM levels that attempting to maintain an impedance mismatch of greater than 1 between different parts of the organization ends in pain.

I think in this case I agree with GP that it is possible to 'solve' a problem at one degree removed from the source if there is no way to actually solve the problem at the source.

So for instance, lots of people write code to scrub janky data from a partner (indeed, that may be part of the value you add to the system).

Re: Mastering Programming (2016)

#96

Post by sloppycee »

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…

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.

Re: Mastering Programming (2016)

#97

Post by hinkley »

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…

The biggest thing holding programming back is that we insist that our domain is somehow unique from hundreds of other domains that have centuries more wisdom at their disposal than we do. We reject out of hand the notion that because we've only been doing this for 60 years means that we really have no idea what we're doing yet.

We believe we are more like machines than like other people. But at the end of the day we're the same trumped-up monkeys smashing away with imperfect tools.

If you look at our fellow productive monkeys, they aren't using the prettiest tools, no. But the tools they are effective with have a certain beauty to them. They often have a single purpose, and they do it very well (the Unix model knew this 40 years ago). Nicks and dents don't matter, unless they're on the working surfaces, in which case they have to be repaired or replaced, so resilience in certain dimensions is an absolute must.

A master does learn to work with their tools instead of against them, but within reason. If a better tool is available, or they can modify the existing tool to fit them better, they won't hesitate for a second to do it. That is what is meant by 'A craftsman does not blame his tools.' If you know you're using a bad tool, that's your fault. Get better tools.

Re: Mastering Programming (2016)

#98

Post by LrnByTeach »

vinceguidry wrote: post #93
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…

I think the best way of thinking about it is to split problems up across levels. So if you have a code problem that you've worked out to be a design problem, you now have two problems. The higher level one needs to be fixed before you can fix the lower level one. So the client complains about software behavior. You now have a client problem. You isolate the issue down to a problem in the data. You fix the data but th…

Well analyzed, this is how real-world 'software problems' are interlocked one level to another and YES splitting problem across levels is way to go.

Here is one thing I gained from this Analysis. At times we encounter 'a Code problem' partly caused by ' a workflow problem' and partly caused by 'a Design problem' .

We may do a CODE patch fix for time being (ex. production bug), but having it documented as '40% Workflow problem, 60% Design problem' will help to consolidate all these 'contributing percentages' to come up with permanent fixes at a Later time.

Re: Mastering Programming (2016)

#99

Post by hinkley »

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.

TestNG exists because of how inflexible and leaky the abstractions were in Junit 3. Junit 4 exists in large part because of TestNG.

I think that pretty clearly illustrates that Kent and Ward were wrong and Cedric was right. And yet I still listen to both of them about other things.

Nobody has it all figured out. You figure out what things you can trust a person about, and you learn from them, and you move on to someone else for some of the rest.

[edit] But I confess that I have a similar relationship to Josh Bloch that you have to Kent Beck. I can't listen to code advice by someone who wrote 2 collections APIs without understanding the basics of variance or apparently even the Liskov Substitution Principle. Throwing exceptions because you decided not to implement part of a public interface is an unforgivable offense that others have duplicated because if it was good enough for Josh it was good enough for them. He has done next to nothing to atone for that sin. You aren't an effective programmer. I don't want to hear you talk about the subject you so obviously know nothing about for 500 pages.

Re: Mastering Programming (2016)

#100

Post by darioush »

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…

I routinely use the "scientific method" to debug. But usually by then it's too late: the code is too hard to reason about so I have to treat it like a blackbox and "observe" its "responses" to the "stimuli" I'm changing.
Post reply on HN