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

81–90 of 123 posts

Re: Mastering Programming (2016)

#81

Post by twic »

d3ckard wrote: post #16
twic wrote: post #14

Earlier quoted context omitted.

This is good advice in general, and so it amuses me when i come across problems which invert this order. Now and then, you can say "if we could do this thing that currently takes time T in T/100, it would be a game-changer" - it would enable whole new approaches, businesses, etc. In that case, your primary goal is to make it fast, and if often doesn't matter if it crashes, fails, or gets a slightly wrong answer 10% o…

If it currently takes time T, then it already runs and probably runs right, otherwise you likely wouldn't care about cutting time. Rule still stands.

No. It might take someone else time T to do it, and we don't do it at all. It might take another program, whose codebase we are not going to touch, and which does it in a different way, time T to do it. In the cases i am thinking about, this was a new program, written from scratch, which did not go through a "make it right" phase before being made fast.

Re: Mastering Programming (2016)

#82

Post by LrnByTeach »

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 leadership problem, or

an existential problem.

Re: Mastering Programming (2016)

#83

Post by Myrmornis »

saltedmd5 wrote: post #19
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!

This is the crux of the problem with a lot of software engineering culture as it stands today - blog posts and talks frequently deliver abstract concepts that only really make sense to people who have already grasped/discovered those concepts. The enlightened sit nodding along, while the unenlightened go away confused or misled. Positioned this way, half-understood ideas frequently do more harm than good. TDD is a gr…

> The enlightened sit nodding along, while the unenlightened go away confused or misled.

It's even worse (and quite common) when those who don't understand are the ones nodding along. Knowing when you really understand something, and when you don't, is such an important milestone for people to get to, and quite hard to teach.

Re: Mastering Programming (2016)

#84

Post by mediocrejoker »

systems wrote: post #47
varjag wrote: post #41

Earlier quoted context omitted.

It seems this kind of posts/books is more aimed to selling oneself as a consulting business process expert in a corporate market than to teach anything to the practitioners. It's a bunch of soundbites aimed at a dilettante.

people need to start somewhere, for someone experienced, sure he might sound like he is stating the obvious for a novice, he might be enlightening don't underestimate how much you know, or assume that everyone else knows it

For this article at least, I have to wonder if a novice would get any meaningful, actionable tips or enlightenment from these terse bullet points.

Re: Mastering Programming (2016)

#85

Post by bcbrown »

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 with an experiment. I think he's saying to develop hypotheses, and then run code to test them.

edit: https://news.ycombinator.com/item?id=11859090

Re: Mastering Programming (2016)

#86

Post by nafizh »

'Ideas are like frightened little birds. If you scare them away they will stop coming around. When you have an idea, feed it a little. Invalidate it as quickly as you can, but from data not from a lack of self-esteem.'

This.

Re: Mastering Programming (2016)

#87

Post by ashwinaj »

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 shipping, it's completely useless.

Re: Mastering Programming (2016)

#89

Post by Sundiata »

vim_user wrote: post #79
eternalcode wrote: post #78

Earlier quoted context omitted.

U am a new developer who is being thought Object oriented design. What is the alternative approach to OO? functional?

If you're a new programmer, I don't think you should start from OO. OO-based languages are built on procedural, structural and imperative programming foundations. Starting from OO may force you to see everything as an object even when it doesn't fit. The less you start off with, the better your understanding will be, and then you should learn to expand your horizons with other programming paradigms: logical, function…

I know that a lot of universities (mine included) introduce programming through object oriented programming so this could be a problem for a lot of people going into university without much if any programming experience, much like I did. I've been interested lately and reading more about functional programming though.

Re: Mastering Programming (2016)

#90

Post by detaro »

Sundiata wrote: post #89
vim_user wrote: post #79

Earlier quoted context omitted.

If you're a new programmer, I don't think you should start from OO. OO-based languages are built on procedural, structural and imperative programming foundations. Starting from OO may force you to see everything as an object even when it doesn't fit. The less you start off with, the better your understanding will be, and then you should learn to expand your horizons with other programming paradigms: logical, function…

I know that a lot of universities (mine included) introduce programming through object oriented programming so this could be a problem for a lot of people going into university without much if any programming experience, much like I did. I've been interested lately and reading more about functional programming though.

Through object oriented programming or through a programming language that can do it? Many programming introductions start with mostly procedural/imperative, while using a language that has OO (and which is then introduced later in detail).

Totally agreed on other paradigms not being teached enough though.

Post reply on HN