Programmers in the field

[Darren Dirt]

Three programmers were asked to cross a field and go to the house at the other side.

The novice programmer looks at the short distance and says, "it's not far! That will take me ten minutes"

The senior programmer looks at the field, thinks for a while and says "I should be able to get there in a day".  The novice looks surprised.

The ninja programmer looks at the field and says. "Looks like ten minutes, but I think fifteen should be enough". The senior programmer sneers.

The novice programmer sets off, but within a few moments, explosive land mines go off, blasting huge holes.  Taking him off course, and requiring him to double back and attempt the crossing many times. It takes him two days to reach the goal. Although he is shaking and injured when he arrives.

The senior programmer sets off on all fours. And carefully taps the ground searching for mines, proceeding only when it is safe. Slowly and meticulously he crosses the field over the course of the day. Only setting-off a couple of mines.

The ninja programmer sets off, and walks directly across the field. Purposefully and directly. He arrives at the other side in just ten minutes.

"How did you do it"?, the others ask. "How come the mines didn't get you?"

"Easy" he replies. "I didn't plant any mines in the first place".


- from an answer@ http://www.quora.com/How-do-I-train-myself-to-code-faster-and-with-fewer-bugs

[Darren Dirt]

Gonna share a couple of other insightful answers in there... (for those without a Quora account)

First, one all about simply PLANNING BETTER (puece by piece)...

"
Train yourself to not code until you've formulated a general understanding of what it is you're trying to accomplish.
Then, train yourself to not code until you've formulated a general approach to solving the problem.
Then, train yourself to not code until you've isolated the specific subroutines (or objects, depending on your world) needed to solve the problem.
Train yourself not to code until you can visualize, in your mind, the flow of data through your processes.
Then, and only then, begin coding with a focus on each part of the puzzle, until you've created the big picture.
"


And there was one stand-out TDD focused answer, it was extremely well articulated:

"
Test DrivenDesign seems like you would be coding slower, but in fact, it has shown that TDD is a great leveler. For rockstars, TDD doesn't add overhead and doesn't provide any advantage either. TDD makes average to poor programmers much faster -- in fact the worse programmer you are, the better TDD is for you.
The reason TDD makes you faster is ... because of the very nature of programming. Development primarily requires understanding what a module needs to do. When programming, you are trying to construct of what the program should look like in your head, and then translating it into code.

Complexity is really small things bundled together. If you can make sure each of your small pieces are working great standalone. you can be more confident that they will work great as a whole. The way you, the programmer, handle complexity that is larger than your intellect is by dividing the task into parts. You divide and you divide until you reach a point where the complexity fits into your head. The term that we use for this process is called modularization.
 So you create the image of one module in your head, You see it as it should be.. in all it's perfection, down to the minute detail. and bang the code out. Once, you done  with the module, you throw that perfect image, take another module and create it's image. Essentially you are doing a mental context switch.

In most engineering fields, the act of building something is inherently integrated with testing it. Once a developer understands the needs of the module, he should be able to design test cases that unit test that module. You know the inputs and expected outputs. Write an unit test case for every expected input and test every expected output.
  TDD doesn't reduce the complexity of a module. It allows you to find bugs in your code * while the module is still in your head. * It eliminates context switches. This makes it much faster to fix the bug.
"

[Mr. Analog]

I don't like the premise because fear of making mistakes is what causes myopia in most developers I've known and they'll faff around with something for literal weeks that takes another less risk adverse dev to do in a morning. Discretion is something a good dev needs to learn, that is to say how to balance risks vs rewards and then learn from them.

As well "Planning" and "Better" are two magic words that @%&#wits love to throw around when something goes wrong. The most important thing you can say when things go wrong is "ok, what are the next steps".

I disagree with the "plan first" / waterfall approach because no matter how much time you do up front, no matter how wonderful your models are, your diagrams, etc, no matter how complete you think your understanding of a Thing is you're going to forget something, maybe something important, and if you aren't capable of making design changes on the fly easily then you are going to feel the burn.

Want to get @%&# done?
-Prototype
-Use cases
-TDD
-Iteration

TDD works because:
1. You MUST have use case scenarios to start
2. You stop and focus on how a component is used
3. You can track trouble as soon as it shows up when you make a change

I've done both Waterfall and Agile, I have seen both gloriously succeed and both spectacularly fail and the only methodology I've seen recover from disaster is Agile. The best quality code I've seen came from Agile (mostly because it forces devs to review what their doing!)

To take the initial metaphor Agile is like having medivac ready for when someone steps on a mine, there was damage but we can recover and keep pressing on

[Darren Dirt]

Sorry bro, my post was pretty lengthy so the point might have been lost. Also I had crazy sleep habits last week so maybe I had read other stuff that helped the context, but forgot to include it in the OP or first reply.


In brief, the stuff I quoted was a reminder, not to be AFRAID of bugs (landmines) but to be aware of the reason they can be self-produced. (easily!)



Most developers love to build stuff, love to actually code. But diving in without first taking time up-front to fully understand what each piece needs to do (process/output) and handle (input) is gonna cause them bugs to be born.

When I say "plan first" I certainly do not mean EVERYTHING (aka Waterfall). I mean when you have broken down the system into its modular / logically distinct pieces, before you begin "coding" a specific piece, make sure you can describe and/or write down in non-code exactly what that piece must achieve, FIRST. After it seems to handle all requirements and boundary conditions etc. then it's time to SIMPLY "translate" from that to the machine code.


A lot of junior programmers might not realize, or tired veterans can forget, how much extra work they are gonna give themselves if they get to the coding too fast. More experience = better up-front design skills -- mainly because you've seen all the blood and gore that has splashed around in your past encounters and so you are "Better" at "Planning" for those types of headaches, quirks, gotchas, etc.


Basically I am agreeing with your "Want to get @%&# done?" list, I liked the way the stuff I posted above articulated similar POV without being too "technical" but rather more abstract and understandable even from a non-software engineering perspective. And so it was a bit of a self-reminder for ME too, that I gotta be sure to protect my code from MYSELF by not diving in too soon.

[Mr. Analog]

Initially I read it mostly as something to get people away from exploring and learning from mistakes as much as success.

First from the "ninja" programmer who must have some kind of magical precognitive superpower related to not making any mistakes ever, pre-planning is heavily implied by the contrast given (moving in too fast, moving in even though you suspect trouble)

Supported by the second piece which suggests planning things down to individual subroutines before doing any code this describes a sequential design process (aka Waterfall). I guess what I'm saying is more detailed planning isn't always better

Finally the last piece which was about metal context switching, while it's nice to work on and really own a piece of functionality it tends to silo people which I've seen happen more often in Waterfall (though any SDLC is vulnerable to this)

I kinda get what you were going for but I think you're looking in the wrong places for guidance, sometimes you don't know if a tool will do what you want and it could very easily change your architecture from the ground up, so if you don't play with it to see what it can do through prototyping you'll never know where the gaps are until you hit them. That's where diving into something head first is sometimes preferable to taking a more measured approach.

In my world we start with use cases:

"As a user I want to do X"

We then sit down and do "planning poker" to:
1. Dissect the problem into highly visible, individually completable pieces
2. Assign values and relationships
3. Schedule them

As we complete pieces we review them and their dependants and make adjustments as we go. Sometimes there's stuff we don't know, we plan time to investigate options, based on those investigations we again make course corrections. This all happens within a 2 week cycle with minimal planning (maybe 3 hours tops), ensuring we don't work on anything too complex we break it down into bite size chunks that give us the ability to isolate functional pieces and help us build on top of it.

When something foundational goes wrong we can see the relationship between pieces expressed by how they evolved over development time and how they relate to each other, in the worst cases we can go back and change things from the point things started to veer off course or adapt other pieces that were written separately to use some other new piece.

I don't think jumping in code-first is always wrong as is implied and I don't think pre-planning things in detail is always wrong, knowing that there is a balance between the two and learning to use discretion is more important than anything else.

But that's just me

I also have been on a weird sleep schedule (thanks to Vinesauce streams dear god) lately so I may have worded things a little more sharply than I should.

[Darren Dirt]

np, no offense taken, you have far more experience in Agile and dammit of that I am peanutbutterjelly, was just getting my ship re-directed by my own initiative as I was reading that bunch of stuff, and decided to share not looking to lecture or teach those who already know and are doing stuff right; but personally I also hope to not over-correct by planning EVERYTHING before coding anything. Just was feeling "aha" moment kinda, lately sometimes getting tunnel vision (my bite sized pieces are too big, most likely -- team of "one" usually though so ... typical :-\ . ) True though that sometimes you gotta just "explore" the tech or the tools or the methodology a bit before you know if it'll completely change things throughout the project, can't always be optimistic that you will be able to plan it ALL out before taking the first step!

PS: Also re. wording and sleep and moods and stuff, ain't it the truth we could all use a hug or at least a warm comforting blanket and a long nap this cold and costly time of year... cheerful positive energy e-vibes sent!

[Mr. Analog]

I apologize, it's me I'm being a butt today

Also some bitter memories of somebody who just didn't embrace the culture I'm lucky enough to work in came flooding back with some of the wording.

grump grump grump

[Darren Dirt]

Also some bitter memories of somebody who just didn't embrace the culture I'm lucky enough to work in came flooding back with some of the wording.

ZOMG I remember you sharing the story bro! Condolences...

[Mr. Analog]

"You're micromanaging me"

• Yes, Agile
• Yes, you've been working on something another dev fixed in 3 hours for 5 weeks

Oddly enough yesterday we found a whole other new area that he had his sticky fingers into, he seemed to have no problem running a recursive query loading on every leaf of a recursive tree.

[Thorin]

my bite sized pieces are too big, most likely -- team of "one" usually though so ... typical :-\
[/quote]

I'm suffering from this as well, these days.  Officially there's another developer on my team, but he's entirely focused on the database-transforming service that runs behind the scenes.  So anything outside of that, I'm on my own.

PS: Also re. wording and sleep and moods and stuff, ain't it the truth we could all use a hug or at least a warm comforting blanket and a long nap this cold and costly time of year...

A hug is nice, but I think I'm more in need of a couple of car batteries.  The ten year old cars wouldn't start in the bitter cold, and now the batteries don't seem to hold a charge overnight.  Damn cold weather.

AMA quoted eight hours to my neighbour on Sunday.