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

61–70 of 136 posts

Re: Mastering Programming: An Outline

#61

Post by Teeboo »

elliotec wrote: post #5

I'd like to see this fleshed out more with examples, because I don't really know what some of these mean.

Well luckily there is a book for that ;-)

1996. Smalltalk Best Practice Patterns. Prentice Hall. (ISBN 978-0134769042)

1996. Kent Beck's Guide to Better Smalltalk : A Sorted Collection. Cambridge University Press. (ISBN 978-0521644372)

1999. Extreme Programming Explained: Embrace Change. Addison-Wesley. Winner of the Jolt Productivity Award. (ISBN 978-0321278654)

2000. Planning Extreme Programming. With Martin Fowler. Addison-Wesley. (ISBN 978-0201710915)

2002. Test-Driven Development: By Example. Addison-Wesley. Winner of the Jolt Productivity Award. (ISBN 978-0321146533)

2003. Contributing to Eclipse: Principles, Patterns, and Plugins. With Erich Gamma. Addison-Wesley. (ISBN 978-0321205759)

2004. JUnit Pocket Guide. O'Reilly. (ISBN 978-0596007430)

2004. Extreme Programming Explained: Embrace Change, 2nd Edition. With Cynthia Andres. Addison-Wesley. Completely rewritten. (ISBN 978-0201616415)

2008. Implementation Patterns. Addison-Wesley. (ISBN 978-0321413093)

>> Selected papers

1987. "Using Pattern Languages for Object-Oriented Programs". With Ward Cunningham. OOPSLA'87.

1989. "A Laboratory For Teaching Object-Oriented Thinking". With Ward Cunningham. OOPSLA'89.

1989. "Simple Smalltalk Testing: With Patterns". SUnit framework, origin of xUnit frameworks.

Re: Mastering Programming: An Outline

#62

Post by jcbrand »

phillipwills wrote: post #43
jondubois wrote: post #35

This article should be called 'Mastering large-scale team programming'. In reality there is no single correct approach to programming. All programmers/engineers/developers have different specializations. Some developers are really good at getting an MVP out the door quickly but their code may not quite work at scale. Others are good at working in large teams on large projects, others work better alone or in small tea…

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.

Re: Mastering Programming: An Outline

#63

Post by jondubois »

Teeboo wrote: post #59
jondubois wrote: post #35

This article should be called 'Mastering large-scale team programming'. In reality there is no single correct approach to programming. All programmers/engineers/developers have different specializations. Some developers are really good at getting an MVP out the door quickly but their code may not quite work at scale. Others are good at working in large teams on large projects, others work better alone or in small tea…

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 quickly and work on something more urgent/important?

Re: Mastering Programming: An Outline

#65

Post by ObeyTheGuts »

jondubois wrote: post #35

This article should be called 'Mastering large-scale team programming'. In reality there is no single correct approach to programming. All programmers/engineers/developers have different specializations. Some developers are really good at getting an MVP out the door quickly but their code may not quite work at scale. Others are good at working in large teams on large projects, others work better alone or in small tea…

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.

Re: Mastering Programming: An Outline

#66

Post by srik »

raarts wrote: post #64

Old German proverb: In der Beschränkung zeigt sich erst der Meister.

A bit of searching found this translation

> The master shows himself first in confinement

Thanks. In the process I found this beautiful poem. http://johnirons.blogspot.com/2011/09/work-in-progress-trans...

Re: Mastering Programming: An Outline

#68

Post by sklogic »

sleepychu wrote: post #44

My top piece of advice: Programs behave predictably, when something impossible is happening it's because one of your assumptions is wrong. When that happens you'll find the bug the moment you start testing your full set of assumptions. For some reason, even though this is invariably true, my friends at school didn't appreciate "I can't understand why I'm seeing this weird behaviour", "One of your assumptions is wrong…

There are bugs in compilers. Hardware faults. 3rd party library faults and inaccurate documentation.

Good luck asserting these assumptions and factoring them in your designs.

Re: Mastering Programming: An Outline

#69

Post by Teeboo »

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

Re: Mastering Programming: An Outline

#70

Post by plinkplonk »

Teeboo wrote: post #59
jondubois wrote: post #35

This article should be called 'Mastering large-scale team programming'. In reality there is no single correct approach to programming. All programmers/engineers/developers have different specializations. Some developers are really good at getting an MVP out the door quickly but their code may not quite work at scale. Others are good at working in large teams on large projects, others work better alone or in small tea…

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…

The man created a methodology [1]. That is wonderful but (imo) it doesn't give him the chops or credibility to tell other people how to program or solve problems.

Think about it.

Does Grady Booch (builder of yesterday's, now forgotten methodology) have some kind of special wisdom to dispense? If not why does Kent Beck? "Mastering" Programming, heh.

That said, sure no one can argue against such 'motherhood and applepie' statements at such a high level of abstraction.

Here is one from me "Think about what you do and act accordingly". you are saying "well duh?"? Exactly my reaction to this pablum.

Not sure any of these aphorisms are particularly relevant in practical work. Still, whatever makes people happy. If you find these useful, good for you.

[1] Not ignoring his work on JUnit which I used extensively when I used to work in Java. Of all the agile gurus, I respect Kent the most, because he has actually written useful code. Just playing devil's advocate a bit..

Post reply on HN