Articulate Coding
casestatement.tumblr.com
Articulate Coding
1–10 of 29 posts
Re: Articulate Coding
#2Also known as analysis paralysis.
Re: Articulate Coding
#3Also known as analysis paralysis.
I do not think that term means what you think it means.[1][2]
This isn't what I understand to be Analysis Paralysis. AP is when you're trying to analyse the problem and design you're trying to code, and you're overwhelmed by the decisions to make and as a result, unable to proceed.
This, in contrast, is about deliberate reflection on what you're doing so you can better make explicit all the otherwise implicit and internal decisions of which you may otherwise be unaware.
As the article says, coders make hundreds of decisions for every routine they write, most on auto-pilot. Some of those might be less than optimal, and this kind of examination and reflection can help to understand, and possibly improve, those decisions.
[1] Minor edit in the light of subsequent comments.
[2] Hat tip to The Princess Bride
Re: Articulate Coding
#4Also known as analysis paralysis.
I do not think that term means what you think it means.[1][2] This isn't what I understand to be Analysis Paralysis. AP is when you're trying to analyse the problem and design you're trying to code, and you're overwhelmed by the decisions to make and as a result, unable to proceed. This, in contrast, is about deliberate reflection on what you're doing so you can better make explicit all the otherwise implicit and int…
I got the impression that icandoitbetter was being snide.
Re: Articulate Coding
#5I think that individual code design culture comes from trying many languages and different use cases, picking up the best practices on the way. I remember using Pascal and then acknowledging that "begin" and "end" are better expressed with curly braces in C. When using Delphi I learnt a lot of OOP principles so I could later easily pickup Java and took some good habits from there also, later came PHP where I started noticing vertical readability is important, so when I saw Python I was stunned. Functional programming hit me, but not so hard, because I used AutoCAD LISP years ago and it felt natural. Trough the years I started to notice new things I would need in my daily coding and I found nirvana when I saw Ruby.
After years of coding one develops their coding personality that they're happy with and I think their code has just a right mix of carelessness and precision which could be never learned from a script kiddie book.
Re: Articulate Coding
#6Earlier quoted context omitted.
I do not think that term means what you think it means.[1][2] This isn't what I understand to be Analysis Paralysis. AP is when you're trying to analyse the problem and design you're trying to code, and you're overwhelmed by the decisions to make and as a result, unable to proceed. This, in contrast, is about deliberate reflection on what you're doing so you can better make explicit all the otherwise implicit and int…
I got the impression that icandoitbetter was being snide.
[deleted]
Re: Articulate Coding
#7Also known as analysis paralysis.
I do not think that term means what you think it means.[1][2] This isn't what I understand to be Analysis Paralysis. AP is when you're trying to analyse the problem and design you're trying to code, and you're overwhelmed by the decisions to make and as a result, unable to proceed. This, in contrast, is about deliberate reflection on what you're doing so you can better make explicit all the otherwise implicit and int…
Agreed, but some of these questions-- the ones about indent style in particular-- don't seem to me to be the kind of things a developer needs to be thinking about while they're working on getting code written. The endless bickering and bikeshedding that arguments over coding conventions always result in are one thing, but having these arguments with yourself, every time you write a line of code, is crazy!
Re: Articulate Coding
#8As a novice programmer, I found this article to be a good bump towards thinking for myself. Too often I find myself doing something because its what the tutorial or book I was reading said was best practice, without really thinking the situation through. Being able to explain why you are making the decisions that you make seems like an important step between just haphazardly piecing together snippets of code you memorized and actually logically solving problems.
Re: Articulate Coding
#9Earlier quoted context omitted.
I do not think that term means what you think it means.[1][2] This isn't what I understand to be Analysis Paralysis. AP is when you're trying to analyse the problem and design you're trying to code, and you're overwhelmed by the decisions to make and as a result, unable to proceed. This, in contrast, is about deliberate reflection on what you're doing so you can better make explicit all the otherwise implicit and int…
Agreed, but some of these questions-- the ones about indent style in particular-- don't seem to me to be the kind of things a developer needs to be thinking about while they're working on getting code written. The endless bickering and bikeshedding that arguments over coding conventions always result in are one thing, but having these arguments with yourself, every time you write a line of code, is crazy!
[deleted]
Re: Articulate Coding
#10Earlier quoted context omitted.
I do not think that term means what you think it means.[1][2] This isn't what I understand to be Analysis Paralysis. AP is when you're trying to analyse the problem and design you're trying to code, and you're overwhelmed by the decisions to make and as a result, unable to proceed. This, in contrast, is about deliberate reflection on what you're doing so you can better make explicit all the otherwise implicit and int…
Agreed, but some of these questions-- the ones about indent style in particular-- don't seem to me to be the kind of things a developer needs to be thinking about while they're working on getting code written. The endless bickering and bikeshedding that arguments over coding conventions always result in are one thing, but having these arguments with yourself, every time you write a line of code, is crazy!
But the point was exactly not to be making these decisions consciously every time you write code. The point - in agreement with you - was that these decisions are not necessarily important.
The argument is that these decisions are made, whether you are aware of them or not, and in this case Beck was undertaking to understand them in nit-picking detail so they can be made visible and better understood, rather than remaining implicit, ill-understood, and possibly sub-optimal.
The author wasn't advocating that this sort of thing be done of every line of code - that would be ludicrous in the extreme. Don't attack the extreme strawman, try to understand and appreciate the underlying purpose.
In my 35 years of software work, far, far too often I see people concentrating on the pointless - bike-shedding if you will - and sadly, this is another case. Concentrate on the point that matters - understanding the processes and decisions of coding, and not the details of the specific instance.