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

111–120 of 123 posts

Re: Mastering Programming (2016)

#111

Post by spc476 »

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?

OO is more an organizational method than a programming method; it still falls down to being imperative (do this; do that). OO is nice when you have a lot of types and few actions whereas non-OO languages are nice when you have lots of actions and few types. When there are a small number of types and actions, it really doesn't matter which organization method you use, but if you expect the types to grow, use OO. If you expect the actions to grow, don't use OO. If both are expected to grow to large numbers, there still isn't a good organization method yet.

Re: Mastering Programming (2016)

#112

Post by papaver »

ashwinaj wrote: post #87
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.

> completely dejected by the quality of the code there Please list a project of equal complexity that has been written beautifully from start to finish in your opinion. This myth of beautiful coding needs to stop! Code is not a masterpiece from Van Gogh, it needs to ship. This determines quality, not the usage of some obscure/mainstream/unreadable/oh-look-how-cool-I-am idiosyncracy of the language. If you ain't shipp…

wow thats the biggest cop out i've ever heard. quality 100% matters, if not even more. shipping crap code still makes it crap and it will come to bite you in the end.

libfreetype is an example of a great library, clean and well documented...

beautiful coding isn't a myth, it actually works... write code like poetry and it pays off 10 fold... less errors, easier to reason about, malleable... the benefits are extreme... try to actually experience something before making unfounded claims... i've been writing beautiful for over a decade now... once you realize code is written once and read 100 times, you'll come to the realization of doing it clean and right the first time pays of in the future, which means less work and bullshit...

Re: Mastering Programming (2016)

#113

Post by kbuchanan »

allenu wrote: post #110
kbuchanan wrote: post #46

A lot of the comments criticize the article for being inaccessible to beginners, and I think they're justified—without examples it's hard to know what the author is talking about without having first passed through the fire. Having said that, I think he's talking about a crucial part of programming that beginners simply don't appreciate: how to break big problems into small problems. In other words, how to unstick ch…

I would say don't work on the branches first. If something is simple and predictable, it can be done later. (This also allows you to slowly converge on a completion date since all the stuff you've put off is simpler and easier to understand and predict in terms of schedule.) Best to work on the challenging, unknown items first, especially if they form the core that everything will rely on. It gives you time to work o…

I think we're talking about the same thing from two angles—when a task appears uncertain, it's important to isolate it. Sometimes, as you suggest, it's an exploration (build the engine before the body to see it turn over), but other times you can chip away at a problem, piece by piece, until there's no problem anymore.

Re: Mastering Programming (2016)

#114

Post by module0000 »

Programming is like anything else... it's a learned skill. Some people will have unusual high aptitude for it, while others will have unusually low aptitude for it. While it's fun to read existential abstracts of programming(like this article), it's better(for me, and all my coworkers, from every job I've ever had) to just practice. Learned skills are refined through repetition. Learn from your peers, and practice, practice, practice. No amount of reading blog posts, or "transcending logic" as the blog post suggest, will make you one iota better at programming.

Re: Mastering Programming (2016)

#115

Post by ashwinaj »

papaver wrote: post #112
ashwinaj wrote: post #87

Earlier quoted context omitted.

> completely dejected by the quality of the code there Please list a project of equal complexity that has been written beautifully from start to finish in your opinion. This myth of beautiful coding needs to stop! Code is not a masterpiece from Van Gogh, it needs to ship. This determines quality, not the usage of some obscure/mainstream/unreadable/oh-look-how-cool-I-am idiosyncracy of the language. If you ain't shipp…

wow thats the biggest cop out i've ever heard. quality 100% matters, if not even more. shipping crap code still makes it crap and it will come to bite you in the end. libfreetype is an example of a great library, clean and well documented... beautiful coding isn't a myth, it actually works... write code like poetry and it pays off 10 fold... less errors, easier to reason about, malleable... the benefits are extreme..…

Just because I say beautiful code is a myth, doesn't mean I and other people write crap code. If you have to make an argument, don't start off with extremes. I'm sure you've heard much worse things than some random stranger saying beautiful code is a myth. Dial down the hyperbole...

> write code like poetry

When a code base reaches a certain size it's hard to write "beautiful code". Please don't pretend that it is just as easy when you have multiple complexities/priorities. If you write so called beautiful code in complex projects, good for you.

Re: Mastering Programming (2016)

#116

Post by rickpmg »

Holy crap, his post was full of self-indulgent, non-actionable advice that is totally unrelated to programming.

Anyone who says 'they get it' is likely just afraid they will be viewed as stupid if they say they're confused.

Anyone remember the story of the "emperor's new clothes?"

Re: Mastering Programming (2016)

#117

Post by growtofill »

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…

Oh, wait: how is a project problem is above a team problem? I use to think that teams outlast projects.

Re: Mastering Programming (2016)

#118

Post by vinceguidry »

growtofill wrote: post #117
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…

Oh, wait: how is a project problem is above a team problem? I use to think that teams outlast projects.

Projects exist to serve a business need. Teams serve the project. Projects can develop problems that the team can't solve, for instance if an e-commerce project is losing revenue for business reasons rather than technical reasons.

These problems have to be tackled by management. Management has to change the scope and goals of the project so that the design team can better create deliverables for the engineering team to build.

Once you get to this level, generally the coders can only raise issues, they don't have the expertise necessary to actually recommend solutions.

About the only thing a coder can do if he sees something like this is to work really hard to actually understand what's going on, raise his concerns to management, and if he doesn't like their answer, get another job. Because chances are, if the project dies, so will his job.

Re: Mastering Programming (2016)

#119

Post by lgas »

0xcde4c3db wrote: post #49
noxToken wrote: post #34

Earlier quoted context omitted.

> 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. I think this puts a lot of things into perspective for me. There will be a blog post about some topic on HN, and it seems that everyone in the comments just gets it. Yet I'm over here like, "Yes. I know some of those words. Maybe I'll get the concept a…

Another problem that I've noticed with FP especially (although I get the impression that OOP had this problem too when it was the new hotness, and I've seen hints of it happening with Rust) is that there seem to be a lot of novices who fall in love with the concept and start evangelizing it, convinced that This Changes Everything. But they can't back it up with a lot of practical experience, can't describe any caveat…

This is a problem with people, and not at all specific to FP.

Re: Mastering Programming (2016)

#120

Post by taneq »

bbrock25 wrote: post #36
saltedmd5 wrote: post #19

Earlier quoted context omitted.

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…

> 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. I'd like to see a blog post on just that point. well said.

It wouldn't make sense to people who didn't already get it, though.
Post reply on HN