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

41–50 of 123 posts

Re: Mastering Programming (2016)

#41

Post by varjag »

elcapitan wrote: post #37
geodel wrote: post #29

Earlier quoted context omitted.

That kind of quality is seen in linkedin style thought leaders. Mostly blathering about obvious or obviously stupid things.

I think such posts (and books) are usually meant like checklists for people who already knows that stuff (not learning it), but want it formalized. Then when you have issues for example with team members, you can look at those resources and try to assess why something is going into the wrong direction. It's easier to enumerate those points then.

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.

Re: Mastering Programming (2016)

#42

Post by skywhopper »

This looks like an outline for a potentially interesting article. But the language is too vague to even know how to react to the ideas. What is meant by "extracting a subelement"? "Make the problem easy" sounds great but could mean lots of different contradictory things. So please write the articles being hinted at in this outline, but as is, it's a bit tough to get anything from it.

Re: Mastering Programming (2016)

#43

Post by teddyh »

tangue wrote: post #22
rcdwealth wrote: post #7

For heaven's sake you could not choose better hosting website but the bloody Facebook.

Side discussion : Discoverability of Facebook articles is non-existent. Kent Beck other posts are quite interesting but to find them you have to go to his profile, click on a mysterious "more" menu item and then you can select his articles...

And that’s only if you have an account on Facebook and is logged in. Everybody else get nothing.

Re: Mastering Programming (2016)

#44

Post by elcapitan »

varjag wrote: post #41
elcapitan wrote: post #37

Earlier quoted context omitted.

I think such posts (and books) are usually meant like checklists for people who already knows that stuff (not learning it), but want it formalized. Then when you have issues for example with team members, you can look at those resources and try to assess why something is going into the wrong direction. It's easier to enumerate those points then.

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.

Well, management to some degree is a form of highly refined dilettantism, so they may go well together.

Re: Mastering Programming (2016)

#46

Post by kbuchanan »

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 challenges (and even find joy in programming) before writing a single line of code.

For example, make a list. Prioritize the items. Strike some. Put the simplest at the top. Figure out which item causes you the most anxiety. Chop away at the branches before attacking the trunk. Even intermediate developers often fail to see that the best programming takes place in the form of a plan.

Re: Mastering Programming (2016)

#47

Post by systems »

varjag wrote: post #41
elcapitan wrote: post #37

Earlier quoted context omitted.

I think such posts (and books) are usually meant like checklists for people who already knows that stuff (not learning it), but want it formalized. Then when you have issues for example with team members, you can look at those resources and try to assess why something is going into the wrong direction. It's easier to enumerate those points then.

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

Re: Mastering Programming (2016)

#49

Post by 0xcde4c3db »

noxToken wrote: post #34
saltedmd5 wrote: post #19

Earlier quoted context omitted.

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. Positioned this way, half-understood ideas frequently do more harm than good. I think this puts a lot of things into perspective for me. There will be a blog post about some topic on HN, and it seems that everyone in the comments just gets it. Yet I'm over here like, "Yes. I know some of those words. Maybe I'll get the concept a…

Another problem that I've noticed with FP especially (although I get the impression that OOP had this problem too when it was the new hotness, and I've seen hints of it happening with Rust) is that there seem to be a lot of novices who fall in love with the concept and start evangelizing it, convinced that This Changes Everything. But they can't back it up with a lot of practical experience, can't describe any caveats or limits to its scope, don't have useful knowledge of the practical pitfalls, and so on. So when you bring up something in your domain that seems like it would be difficult, they don't have the foundation to say "this is how you solve that kind of problem" or "yeah, that's still difficult". Instead they deflect or try to subsume it under some vague principle that doesn't actually address your concern.

Re: Mastering Programming (2016)

#50

Post by gedrap »

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 and avoids clutter. Act with intensity when the time comes to act.

I have no doubt that each point has some very specific examples behind them and knowing them could actually be useful. But right now, you can only guess what was intended behind these #deep thoughts.

Post reply on HN