Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mastering Programming (2016)

facebook.com

Post reply on HN
Print view View original

71–80 of 123 posts

Re: Mastering Programming (2016)

#71

Post by luhn »

saltedmd5 wrote: post #19
d--b wrote: post #3

Distillating years of experience in such tiny concepts is a bit harsh on the reader. Without any concrete example, the advice could easily be very misunderstood, or not understood at all. Being a fairly seasoned developer myself, I kind of intuit what they mean, but I could very well be projecting what I think I am doing right into each of these, and conclude that I'm a master programmer... yay!

This is the crux of the problem with a lot of software engineering culture as it stands today - blog posts and talks frequently deliver abstract concepts that only really make sense to people who have already grasped/discovered those concepts. The enlightened sit nodding along, while the unenlightened go away confused or misled. Positioned this way, half-understood ideas frequently do more harm than good. TDD is a gr…

> ...deliver abstract concepts that only really make sense to people who have already grasped/discovered those concepts...TDD is a great example of this

Thank you! I'm glad I'm not the only one who thinks this. There's an abundance of articles explaining how to "best" test, usually using an overly simplified example (I'm looking at you, `add(a, b)`). When you try to apply it in the real world, things break down because no one explains how to deal with the icky practical issues.

Despite all these resources online teaching you how to test, I feel that how to test well in real-world scenarios remains tribal knowledge.

Re: Mastering Programming (2016)

#72

Post by eric_b »

vinceguidry wrote: post #51

> 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]. The key to this is realizing that once you decide a problem is at a certain scale, the fix needs to be at that scale too. So you might have a data problem, a code problem, a workflow problem, a design problem, an architectural pro…

The corollary to this is to never solve the problem at the wrong level. It's always a recipe for pain when you, say, have a data issue and you decide you'll solve it with some clever code. Or perhaps you have a fundamental design problem, but maybe you can just tweak the data...

Re: Mastering Programming (2016)

#73

Post by eric_b »

hota_mazi wrote: post #24

Having spent entire days years ago poring through the JUnit 3 source code and having been completely dejected by the quality of the code there, I don't really trust Kent Beck to give advice on anything related to programming.

Hrmm, this is an interesting observation. In general I'm not a huge fan of Kent Beck or Uncle Bob as I've felt that their zealotry for "clean code" gets in the way of them actually creating valuable software.

I've always been of the mindset that if the code isn't a little "gross" it's probably not doing anything very interesting.

Re: Mastering Programming (2016)

#74

Post by louthy »

hota_mazi wrote: post #24

Having spent entire days years ago poring through the JUnit 3 source code and having been completely dejected by the quality of the code there, I don't really trust Kent Beck to give advice on anything related to programming.

I think all code at a certain scale has it's fair share of messiness, it's just unavoidable as the battle becomes not so much about code quality, but the cognitive difficulty of keeping everything in the human brain. I am no fan of the OO design-patterns dogmatic approach and that whole cultish paradigm hurts my eyes when I look at it in code form, but I understand how even the best programmers in a field get into this situation.

Re: Mastering Programming (2016)

#75

Post by collyw »

eric_b wrote: post #73
hota_mazi wrote: post #24

Having spent entire days years ago poring through the JUnit 3 source code and having been completely dejected by the quality of the code there, I don't really trust Kent Beck to give advice on anything related to programming.

Hrmm, this is an interesting observation. In general I'm not a huge fan of Kent Beck or Uncle Bob as I've felt that their zealotry for "clean code" gets in the way of them actually creating valuable software. I've always been of the mindset that if the code isn't a little "gross" it's probably not doing anything very interesting.

Unit testing isn't very interesting, so shouldn't need to be "a little gross".

Re: Mastering Programming (2016)

#76

Post by twii »

Good post with loads of valuable points.

This document clearly shows that "master" programmers focus on very different things than a beginner might expect. A beginner can get really excited and proud making something complex work without noticing the flaws. After years of debugging your own code you'll find out that getting complex things done is not really the issue, it is HOW it's being done that makes the difference.

Beginners tend to focus on new language features, premature optimisations, having unnecessary strong opinions about wether using a for loop or map or reduce etc.., using too many and buggy libraries, literally copy and use code from others without noticing it's flaws, getting pride from writing complex code that almost no one can understand, trying to beat the calculator, trying to beat Google with your own memory, over estimating the value of linters, CI, TDD, agile, what editor to use, etc.., etc...

All these things take up so much space and energy at the cost of what really matters if you want to do what a master does: write bug free code that is easy to maintain and a joy to read.

Re: Mastering Programming (2016)

#78

Post by eternalcode »

louthy wrote: post #74
hota_mazi wrote: post #24

Having spent entire days years ago poring through the JUnit 3 source code and having been completely dejected by the quality of the code there, I don't really trust Kent Beck to give advice on anything related to programming.

I think all code at a certain scale has it's fair share of messiness, it's just unavoidable as the battle becomes not so much about code quality, but the cognitive difficulty of keeping everything in the human brain. I am no fan of the OO design-patterns dogmatic approach and that whole cultish paradigm hurts my eyes when I look at it in code form, but I understand how even the best programmers in a field get into th…

U am a new developer who is being thought Object oriented design. What is the alternative approach to OO? functional?

Re: Mastering Programming (2016)

#79

Post by vim_user »

eternalcode wrote: post #78
louthy wrote: post #74

Earlier quoted context omitted.

I think all code at a certain scale has it's fair share of messiness, it's just unavoidable as the battle becomes not so much about code quality, but the cognitive difficulty of keeping everything in the human brain. I am no fan of the OO design-patterns dogmatic approach and that whole cultish paradigm hurts my eyes when I look at it in code form, but I understand how even the best programmers in a field get into th…

U am a new developer who is being thought Object oriented design. What is the alternative approach to OO? functional?

If you're a new programmer, I don't think you should start from OO. OO-based languages are built on procedural, structural and imperative programming foundations. Starting from OO may force you to see everything as an object even when it doesn't fit.

The less you start off with, the better your understanding will be, and then you should learn to expand your horizons with other programming paradigms: logical, functional, and many others.

Re: Mastering Programming (2016)

#80

Post by jorgec »

"Poor workers blame their tools. Good workers build better tools. The best workers get their tools to do the work for them." Right now, i am finishing a system that took me 2 weeks do develop. With the standard way, i should have finished it around January of the 2018.
Post reply on HN