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

91–100 of 136 posts

Re: Mastering Programming: An Outline

#91

Post by Teeboo »

blub wrote: post #90
Teeboo wrote: post #87

Earlier quoted context omitted.

I am not blindly following it. I think it is sound practical advice given by a titan of engineering. I have yet to read anything of yours which says why I shouldn't listen to Kent Beck. For every well respected opinion or technology there is always a group of naysayers. A cadre of individuals who offer nothing of insight in return. In 1906 John Philip Sousa claimed the phonograph would ruin music. Don't be that guy.…

By a titan of software development processes, if there even is such a thing. Titans of engineering are people like Torvalds, Carmack, Engelbart, Wozniak, Codd, Lamport, Wall and many many others. Including process people in that list would be mistaken.

That's a fair challenge and I can accept I might be over-effusive in my praise.

Re: Mastering Programming: An Outline

#92

Post by arekkas »

After reading that, I don't feel a bit smarter then before. That's usually how it goes when you make a bold, universal statement about something and put it into 10 lines of text.

I aknowledge what Kent Beck has done and what facebook is doing but this doesn't deserve to be on HN front page.

Re: Mastering Programming: An Outline

#94

Post by sleepychu »

sklogic wrote: post #68
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.

I'm happy to risk verifying those last ;-)

EDIT:

>inaccurate documentation. With the exception of this one, I usually assume that you need to verify the behaviour of a library/feature you've not used before.

Re: Mastering Programming: An Outline

#95

Post by Teeboo »

_pmf_ wrote: post #88
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…

> This article should be called 'Mastering large-scale team programming'. To be fair, that IS the hard kind of programming. Small, focused teams of talented developers can do things pretty much as they like and are likely to have a positive outcome. (That's why I'm skeptical of typical "agile team" success stories; if you care enough about your job to identify with the methodology, you are probably a competent develo…

You are correct, it's just that we wrote down those behaviours and practices used by successful teams and they became the agile values.

It's not self-fulfilling. It's fulfilling.

The same way Doctors wrote down the treatments that worked for patients and it became medicine.

https://www.youtube.com/watch?v=DHVVKAKWXcg

Re: Mastering Programming: An Outline

#96

Post by huherto »

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 do tend to try things when they solve a problem that I have. I may be missing on problems that I don't know that I have. On the other hand, I frequently see people using tools to solve problems that they don't really have.

Re: Mastering Programming: An Outline

#98

Post by lfowles »

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…

From what I've seen, they are eager to try new technologies but not necessarily new implementations. Just enough to get an idea of where this tool fits in their toolbox should they ever need it.

Re: Mastering Programming: An Outline

#99

Post by jasim »

These are attributes that everyone can, on honest personal judgement, can mistake to possessing themselves to varying degrees. But it might be a useful list to read through when stuck at a problem that is simply not giving way.

Unless we have the chance to learn from and be coached directly by a master, what would be helpful is narratives on how they think and solve problems.

The best I have so far come across in a book is "Coders At Work". https://github.com/aosabook/500lines promises to be another. Rich Hickey did great service by talking pragmatically about the meta aspects of programming through Hammock Driven Development and Simple is not Easy. Dijkstra's and Alan Perlis' writing that has been gaining a resurgence in popularity is also of a similar ilk. http://damienkatz.net/2005/01/formula-engine-rewrite.html also is an intriguing story.

Re: Mastering Programming: An Outline

#100

Post by dwmtm »

Teeboo wrote: post #79
plinkplonk wrote: post #78

Earlier quoted context omitted.

>However, you also, worryingly, faked 3 comments at the bottom of your own blog post, one pretending to be a Scrum Master saying they are taking the money. They are time stamped and clearly written by you. WTF? you spend your time digging up my old blog posts from years ago, accuse me of faking comments on my own blog post, (lol what? evidence? or are you just high and imagining things?) and then call my behavior abn…

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.
Post reply on HN