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

31–40 of 136 posts

Re: Mastering Programming: An Outline

#31

Post by cageface »

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'm definitely in this camp. I read enough programming related news that I know what new technologies are emerging and what problems they attempt to solve. But these days I wait until things have gained enough momentum that I think they'll stick around for at least a few years before I'll even consider adopting them for real work.

That said it's good to keep learning new things just for the sake of learning so I will still sometimes pick up something new just because it looks different enough from things I'm already familiar with.

Re: Mastering Programming: An Outline

#32

Post by sigill »

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?

Re: Mastering Programming: An Outline

#33

Post by 0mbre »

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.

Re: Mastering Programming: An Outline

#34

Post by JoshTriplett »

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…

You should hesitate to introduce fringe technologies into production systems while they remain fringe. But you should absolutely evaluate them, figure out which ones you want to keep an eye on, and learn ideas from them that you could apply elsewhere.

Re: Mastering Programming: An Outline

#35

Post by jondubois »

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 teams. These different types will produce different types of code - the utility value of various programming habbits changes based on team size, project size and urgency requirements.

There could be some 'Master MVP programmers' and 'Master team-player programmers', 'Master large-project programmers'... You can rarely put them all under a single label - As developers we tend to get stuck with particular styles depending on which kinds of companies we have worked for.

It is not quite correct to assume that because a company is financially successful and handles many millions of users, that its methodologies are the only correct way to do things.

Programming is an adaptive skill and should change based on economic/scale requirements.

Re: Mastering Programming: An Outline

#36

Post by epaga »

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?

Great programmers often take a step back and ask themselves whether the problem they are encountering is only a symptom of a far larger problem, e.g. "maybe this entire component needs to be refactored instead of just tweaking these tests." or "maybe when customer asks for X what he actually wants is Y"

Re: Mastering Programming: An Outline

#37

Post by agumonkey »

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.

I couldn't upvote this enough. It's even a way of life that is larger than programming. Most of my math issues were about how I didn't really see the extent of a concept or the problem. When done suddenly things become extremely less resistant. Patience, depth, focus, lucidity.

Re: Mastering Programming: An Outline

#38

Post by caconym_ »

PeCaN wrote: post #6
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.

A similar one when dealing with compiled languages with good type systems (Haskell, OCaml, Rust, Mercury) is to periodically build even when your code is broken and try to guess what error the compiler will give. This helped me a lot with those languages.

My process in these languages (Haskell I know pretty well, now in the process of learning Rust) is to sprinkle in `undefined`s and `unimplemented!()`s and whatnot so I can continuously use the compiler to check my work without actually running the code.

It's a good way to test assumptions and refine a mental model, and it's also just plain useful for catching boneheaded mistakes as you go. I'm not sure if I'd say I use it as a crutch, but I certainly miss it when I have to use languages like ruby and Python.

Re: Mastering Programming: An Outline

#39

Post by richdougherty »

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