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

41–50 of 136 posts

Re: Mastering Programming: An Outline

#41

Post by sigill »

richdougherty wrote: post #39
sigill wrote: post #32

The article makes a number of good points. The first three points in the "Learning" section resonated very well with me. Then there's stuff I just don't understand. For example: > Multiple scales. Move between scales freely. Maybe this is a design problem, not a testing problem. Maybe it is a people problem, not a technology problem [cheating, this is always true]. What does he mean by scales?

He might be suggesting that you can consciously consider the problem different at levels of detail. You can step back and look at the problem in its wider context ("the big picture") and you can also zoom in and focus on aspects of the problem in more detail.

Thank you. I was thinking of scale as a measure of order of magnitude and then it didn't make sense.

Re: Mastering Programming: An Outline

#42

Post by badminton1 »

caconym_ wrote: post #30
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…

Did you only read the bold text? This is very different from "duct tape programming": > When faced with a hard change, first make it easy (warning, this may be hard), then make the easy change

Given the fact that duct tape programming is what the majority of people do nowadays, I would be more explicit about what an "easy change" means.

Re: Mastering Programming: An Outline

#43

Post by phillipwills »

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 know how to describe it, but one day, you find yourself doing these things more... Stuff gets easier... Things just start to click.

I'd like to add one more, though maybe it's really just another way of putting one of the other statements.

Stop worrying about all the unknowns in the project. Work on what's known, usually the unknowns will become more clear as you progress.

Re: Mastering Programming: An Outline

#44

Post by sleepychu »

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!" xD

Re: Mastering Programming: An Outline

#45

Post by LoSboccacc »

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…

yeah many are really important, like the part about 'calling your shot' - I constantly see so many people testing solutions to problem at random, either copy pasted from internet or built using random auto-completion; they spend days and days circling around without ever understanding the changes they're making nor the goal their building towards.

It's doubly painful when days after they come up with the random set of lines that produces the intended result and dozen unintended side effects and proudly declare 'see! I did it'

the fact is this stuff has been in literature from the seventies. I found very little in this article that couldn't be found in 'code complete' or 'refactorings'. I just wish at some point developers will stop learning everything from scratch.

Re: Mastering Programming: An Outline

#47

Post by aryehof »

I also think it important to understand the nature of the environment your problem is in, because it so much flavors the approach and the solution.

If in computer and data science, emphasis is on algorithms, data structures and ADTs. But if in business, commerce and industry it's the representation of complex domain concepts, real and abstract, and their interactions that are key.

In some ways there is a fundamental divide between the two. While the ops advice is valuable, for me an understanding of where and how to apply techniques across that divide is one of the biggest impediments to "mastering programming".

Re: Mastering Programming: An Outline

#49

Post by mathattack »

bcbrown wrote: post #2

> Call your shot. Before you run code, predict out loud exactly what will happen. That's probably my favorite bit of advice. It really helps with understanding how much your assumptions diverge from reality.

I like the intellectual honesty. "Write it down" takes this one further.
Post reply on HN