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

51–60 of 136 posts

Re: Mastering Programming: An Outline

#51

Post by qznc »

badminton1 wrote: post #18

While the author is known (technical coach at Facebook, creator of XP software methodology), I sort of disagree. You can follow this guide and still be a low value programmer. This guide won't take you to mastery level. And, there is also a sense of irresponsibility around one item: "easy changes". Easy changes as in, duct tape programming? That's pretty much turning your project into a Jenga tower... you add your "e…

The step before the "easy change" is "make change easy". This usually includes refactoring and paying off technical debt.

Anecdote from one great programmer I know: When he fixed a single bug, it often came split into multiple commits. First, a few commits refactoring and cleaning up things. Then one tiny commit fixing the bug. Finally, one more commit removing now-obsolete stuff.

Re: Mastering Programming: An Outline

#52

Post by mercer »

0mbre wrote: post #33

Something that is helping me a lot recently is trying to know all there is to be known about the tools/concept that I am using and the problem that I am solving. Too often have I used tools I half understood to solve problem that I didn't define clearly enough.

Yeah, this is a bad pattern I started noticing even way back when I mucked about with Wordpress theming. Hell, I could go further back and notice this pattern in assembling LEGO. And sadly I still catch myself doing it even now whenever I'm caught up in this "this shit doesn't work, let me try that real quick" loop, where 'that' is only one of many variables I don't really understand.

What I've noticed works best for me is to nip it at the bud rather than bail out of that loop. Because once I'm stuck in the loop, I find it hard to sit back and think about things properly.

The worst cases for me is when I try more than one 'new thing' at once, which usually happens in new projects. Most recently I set up a new project and decided to try out typescript, a new back-end tool, and another build process all at once. I couldn't get it working, and only once I dived into it I discovered there was one 'little thing' (javascript's current module kerfuffle) that caused most of the issues.

What I hates most about these episodes is that at the end, all I learned was a tiny bit more about disparate systems that I still don't master. Huge waste of time.

Re: Mastering Programming: An Outline

#55

Post by dang »

riazrizvi wrote: post #23

How does this drivel get upvotes?

Please don't post like this here. Comments on HN need to be civil and substantive. If you want to make a criticism thoughtfully, that's fine, but don't call names.

https://news.ycombinator.com/newsguidelines.html

https://news.ycombinator.com/newswelcome.html

Re: Mastering Programming: An Outline

#57

Post by [deleted] »

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…

[deleted]

Re: Mastering Programming: An Outline

#58

Post by mikekchar »

endgame wrote: post #26
shadesof wrote: post #10

> When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change. This is my favorite bit. Katrina Owen mentions this in her talk on refactoring. "Make the change easy; then make the easy change." https://www.youtube.com/watch?v=59YClXmkCVM

This is excellent advice, and I've seen it replicated as far back as Fowler's book on refactoring. Does the trail go further back than that?

I may be mistaken, but I actually remember Kent Beck saying it in his original TDD book. That was the thing that made me understand how refactoring can take the place of big design up front. The best part is that you only work on things that you need as opposed to wandering around changing every piece of code that you don't like ;-)

Re: Mastering Programming: An Outline

#59

Post by Teeboo »

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 deliver far more projects to scope, meeting customer requirements in a suitable timeframe.

To say that this man needs to consider other approaches is akin to saying Muhammad Ali should have considered other boxing styles ;-)

Re: Mastering Programming: An Outline

#60

Post by dfraser992 »

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…

I agree. They all seem quite familiar, though more abstractly defined than I would define them. Perhaps that is why I am now a bit tired of development - too many new specific details to learn about the 'latest and greatest', but fundamentally it is all the same stuff anymore. Maybe I'll pick up Haskell, just to think in Lisp-ish terms again... But statistics and ML in general are now drawing me in - and I hated stats in college. Brand new concepts.

Like LoSboccacc said, all this stuff is in 'Code Complete' and the related series of books. Another I'd recommend is 'The Practical Guide to Structured System Design' and 'The Psychology of Computer Programming' (about egoless programming). Old books, but well written and perhaps seemingly basic considering how complex React/Node/javascript... seem to be, but the fundamentals never go out of fashion.

Post reply on HN