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

Mastering Programming: An Outline

prod.facebook.com

Post reply on HN
Print view View original

101–110 of 136 posts

Re: Mastering Programming: An Outline

#101

Post by mcguire »

jcbrand wrote: post #62
phillipwills wrote: post #43

Earlier quoted context omitted.

I wouldn't say that this article is describing a correct way to do things. It's more of a set of guidelines to follow, and I'm glad someone wrote them down. I've been doing these things, but I generally have a hard time concisely describing it. Of course, these aren't hard and fast rules. More of a guide to thinking about problems to help programmers be more efficient and accurate... More precise... I don't really kn…

> Stop worrying about all the unknowns in the project. Work on what's known, usually the unknowns will become more clear as you progress. Good advice which applies not only to software development. I've found that focusing on what's currently known and on what I can change removes anxiety, allows me to move forward and then usually the unknowns resolve themselves along the way.

It works very well, until it doesn't. Then you have a pretty interface, an elegant test suite, and a big black box full of entropy and ignorance labeled "then a miracle occurs".

Re: Mastering Programming: An Outline

#102

Post by Teeboo »

dwmtm wrote: post #100
Teeboo wrote: post #79

Earlier quoted context omitted.

I simply searched for the people you referenced and the word Agile. I had no idea your blog would be ranking first page for anti-agile rants. You find it creepy that you list your twitter profile and you publish an online blog and people then read your Twitter and online blog? I def believe and am willing to bet a month's salary that you faked those blog comments. I am more sure of it than my own name. We both know y…

Calm down, Kent.

Perfectly calm. Just eating my popcorn and watching the downvotes on Hacker Reddit.

The same people down voting each comment rather than apply discretion shrug

Re: Mastering Programming: An Outline

#103

Post by dang »

Teeboo wrote: post #71

EDIT: Just reviewed your Twitter. It's 2000 tweets of snark and criticism of everything you come across - GoT, other coders, Agile, politics. I doubt we will get anywhere constructive on this thread but my original post remains below. Original post >> "Doesn't give him the chops or credibility to tell others how to program or solve problems." ...that cannot be serious. Am actually smiling at that. Also laughing at th…

We've banned this account. Personal attacks, name-calling, and flamewars, all of which you've made an egregious hash of in this thread, are not allowed on Hacker News.

We detached this subthread from https://news.ycombinator.com/item?id=11861023 and marked it off-topic.

Re: Mastering Programming: An Outline

#104

Post by phillipwills »

mcguire wrote: post #101
jcbrand wrote: post #62

Earlier quoted context omitted.

> Stop worrying about all the unknowns in the project. Work on what's known, usually the unknowns will become more clear as you progress. Good advice which applies not only to software development. I've found that focusing on what's currently known and on what I can change removes anxiety, allows me to move forward and then usually the unknowns resolve themselves along the way.

It works very well, until it doesn't. Then you have a pretty interface, an elegant test suite, and a big black box full of entropy and ignorance labeled "then a miracle occurs".

Even when that does happen... and I'd argue that it often does not, if you've done the work to make your interface pretty, and write a precise, accurate test suite, you've usually done the work to make the actual functions neat and orderly...

Even when you end up with a black box full of entropy, it's segregated from the rest of the system. You can feel free to change the rest of the system around it and know that the black box will keep doing it's job, as long as you keep using the well-written API within spec.

But, that's not all you get... because you took the time to write the tests, you can refactor this entropy box to your heart's content... until it starts looking more approachable. You've got your tests around the API, right? Then you don't even really need to change them to do the refactor work. The only reason to change the tests would be if you want the function to do something else (or you missed something, of course).

Take small steps... refactor out a couple lines at a time... run the tests with each iteration. Based on previous experience, you're going to end up with a fairly clear and concise implementation... not to mention performant.

Re: Mastering Programming: An Outline

#105

Post by dang »

Teeboo wrote: post #69

What? Seriously, what? What argument are you making here? Boxing / Ali was an analogy to demonstrate the widespread respect of the engineering community that KB has earned. /awkward To be clear; my post was not about you being boxer. /awkwardoff

We detached this subthread from https://news.ycombinator.com/item?id=11860937 and marked it off-topic.

Re: Mastering Programming: An Outline

#106

Post by newtype »

andyjdavis wrote: post #22
keyle wrote: post #8

Sadly just an outline but I didn't mind that. Good read. I'd add a few things I've noticed over the years. Great developers like to pair program on tricky stuff, because they always learn something. They will try 2 different implementations if they're not sure which is best, and then the right one will then be obvious. They back their arguments with real world proofs. They try most fringe/new technology, even if it's…

> They try most fringe/new technology I have actually found the opposite. The best programmers I have known are often the most reluctant to try new technologies. At least until the technology appears to have reached some sort of critical mass and it has been shown to be virtually guaranteed to increase their already very high levels of productivity. Partly this is just an experience thing. After you see enough shiny…

I am in the same camp. I'd prefer to know an older technology (and it's underpinnings) completely than scratch the surfaces on a bunch of short lived new ones. Most of the new stuff I see is pretty high level. I invest my free time in getting as close to the metal as I can.

If there's something new with a feature I like, I'm a lot more likely to try to replicate their feature in something I know than make a switch.

Re: Mastering Programming: An Outline

#107

Post by AnimalMuppet »

jondubois wrote: post #63
Teeboo wrote: post #59

Earlier quoted context omitted.

All spoken brilliantly as someone who has not seen the nuance beyond the post. The Facebook note was written by Kent Beck, father of eXtreme Programming (XP) and original Agile manifesto signatory. He is not saying follow this methodology because a company made money. Invert your thinking; he is saying the majority of companies that utilise the following values and techniques have far fewer failed projects and delive…

Except we don't all do boxing and we aren't all Muhammad Ali. But some of us may be masters of our craft nonetheless. These 'guidelines' would mean very little to someone who programs microcontroller chips - Not saying these guidelines aren't useful, but in some environments there are more important aspects like will my program fit in flash memory? Do I have time to refactor this code or should I just patch it quickl…

> These 'guidelines' would mean very little to someone who programs microcontroller chips

I program embedded systems, which is pretty close. I still thought that the guidelines were spot on.

Re: Mastering Programming: An Outline

#108

Post by [deleted] »

dang wrote: post #103
Teeboo wrote: post #71

EDIT: Just reviewed your Twitter. It's 2000 tweets of snark and criticism of everything you come across - GoT, other coders, Agile, politics. I doubt we will get anywhere constructive on this thread but my original post remains below. Original post >> "Doesn't give him the chops or credibility to tell others how to program or solve problems." ...that cannot be serious. Am actually smiling at that. Also laughing at th…

We've banned this account. Personal attacks, name-calling, and flamewars, all of which you've made an egregious hash of in this thread, are not allowed on Hacker News. We detached this subthread from https://news.ycombinator.com/item?id=11861023 and marked it off-topic.

[deleted]

Re: Mastering Programming: An Outline

#109

Post by dasil003 »

jondubois wrote: post #74
ObeyTheGuts wrote: post #65

Earlier quoted context omitted.

Absolutely disagree with you, slicing problems to small and focusing one at a time and all other good points is a must if u want to be good at any kind of programming and even more even other skills outside programming.

Not if you have a hard deadline and your client is launching a massive advertising campaign for your product in a few hours. Also if your project is part of a promotional campaign, it will be up for a few months and then the whole thing will be torn down forever - You don't want to over-engineer it. I only worked briefly in the digital agency space, it wasn't my thing. My workflow very much adheres to the points desc…

If, by your original comment, you meant that if your project is simple enough you can muddle through like this, whereas with a large project you can't, I agree with you. But just because bad design doesn't scale up, does not mean that good design doesn't scale down.

The bottom line is good design is fractal. You absolutely need it to achieve the largest scale, but it pays dividends at any scale. While it's true there are a lot of cases where it doesn't matter, doing so will never make you a master programmer any more than chainsawing a log to make seats around a fire pit will make you a master carpenter.

Post reply on HN