I've had my first exposure to insertion sort (lol, newb), and I have this code piece from wikipedia, written in C:

Is it me, or this a little bit excessive?

Yeah, I'm cheating on this first algorithm because I want to be able to interpret the pseudo-code in the book... that's my story anyways. The pseudo-code looks pretty close to Python, but I'd rather work through all the algorithms in C and Lisp.

requirements were vague. i took a stab. don't like it? write me a User Story and come to my next planning meeting.

i would grant bonus points for that. more bonus points if you did it to facilitate unit testing. i wouldn't drag FP into it unless you were doing something that actually resembled FP (moving the logic to a function and calling it is not FP).

not a strike against the kind of candidate to whom i ask the fizzbuzz question.

sure, but it sounded to me like urinal mint just wanted to get his code on at school, not get expelled. for better or worse, in today's world it's a lot harder to be a... shall we say "casual security enthusaiast".

Yes sir! I'll have a 95 page report of intention for you by Friday. Do you want that in 10 pt or 12 pt font?

(don't doubt my abilities to do such a thing 'cause I've done it more than once)

dave,

of all the skills you've demonstrated in our time together, your ability to produce reams of text is the one about which i have the least doubt!

also i don't think user story means what you think it means.

also also, that was a copout by me because really what i want is Acceptance Tests in some sort of runnable form.

Was shown this site this week: http://www.websequencediagrams.com and was very happy.

yeah a coworker used that for a project.

also, i want to have michael feathers's babies:

http://michaelfeathers.typepad.com/m...is-sloppy.html

Who said I have to know what a User Story is in order to create a 95-page introduction?

Didn't you know that the first 30 pages of that will enumerate the various definitions from a grip of qualified resources? I have to assume that the intended audience doesn't know what a User Story is, or if they do, they have some warped definition that doesn't align with the goal of optimizing profits. This is why it is a Report of Intention, so all definitions are clear and I can spell out my intended methodology.

->> You don't read any of it. I do whatever the hell I want. You'll probably get pissed, but I can reasonably blame you for not reading the Report of Intention.

The Acceptance Tests will be a 1000 page report full of hard-to-decipher data charts, colorful accounts of customer moaning and groaning, and bunch of copy / pasted brute-force code written by the development team and a conclusion of the findings. I can have that on your desk Tuesday evening.

dave,

thank you for your time. we'll let you know...

(tbf, i've yet to see a real software project using executable acceptance tests. i do think it's a cool idea and have written code with both cucumber and behave, but nothing really serious.)

You see why my last job just locked me in a room and told me to report my findings whenever I felt like there was something valuable for people to know... and why I was universally reviled?

dave,

we all need an editor. some of us just need one more than others.

haha wp

That's one of the reasons why pair programming works fairly well. You always refactor code written by someone else on the fly.

This is in essence a less dynamic version of pair programming.

Minor rant:
I understand the need to refactor especially in software development but fundamentally the entire concept seems a bit broken/misapplied. I'm very much a total quality management kind of person so at least conceptually it seems like a sin to "be done with" code that needs refactoring. It should be a matter of taking pride in your own code that you relentlessly refactor it any way you can think of before being done. It should be the best you can come up with.
Then his suggested "have someone else refactor" can be the next layer. The way he describes it it seems more like "I'll write something that works and let the other guy wonder about refactoring". That's not good. The second guy should look at the code and more often than not think "well this looks great, I'll approve it" and if he thinks something can be improved he should contact the original author and they should work out a solution.

I know a couple of places that require a second guy to sign off on commits and I think it's a good practice. In fact I'm starting to wonder if having an experienced guy around who doesn't write much code and is mostly responsible for reading code might be a good idea.
Alternatively this could also be an interesting position for the least experienced guy because it would require pretty clean code and/or being able to explain your code to the programming world equivalent of a three year old which could improve the codebase.

[obviously this is all theory and the fact that it's different in practice is precisely the reason why refactoring is needed ... but one can dream :P]

clown,

your academia is showing .

i agree that pair programming should produce better code, and a fair amount of this comes from the phenomenon that one of the pair will usually have a fit of conscience and force the code to be written "right".

even if you follow excellent practices, refactoring will always be a fact of life. sometimes the requirements change and you have to change the architecture to keep up. sometimes you have to deal with third-party code, or code from a less diligent colleague. sometimes that colleague is you and your pair partner from six months ago. sometimes, alas, it's better to commit the hack now and ship the product because of market pressures.

i've read quite a bit of feathers and i'm confident that's not what he's proposing at all. he wants the other guy involved to keep everything honest; clear interfaces promote separation of concerns.

there's nothing about this approach that couldn't work with two pairs instead of two lone developers. pairs are far more honest than individuals, as discussed above, but they are subject to blind spots after working on some problem for a long time. thus the "trick" of introducing another party should still work.

i'm a big believer in code reviews, but i'd kill myself if it was all i did all day.

I don't think clown's reply was "academic". It's just the difference between someone who enjoys what he's doing vs someone who just wants a pay check.

Someone who really cares about his trade will always try to do the best job he can possibly do instead of just rush through it and have someone else clean up his mess. This is true in pretty much every trade job.

The guy I have in mind gets to write some stuff as well, possibly even the most interesting stuff (research projects along the line of "I wonder if we could speed up things if we did X,Y,Z") but he's spared from coding mundane things. Also keep in mind that he gets to hop in and improve code/help others improve code.

You obviously need someone with the right character traits for this (Maslow->Transcendence)

In my HS Algebra II class today the teacher explained to us the concept of bisection to approximate a zero of a function. Given an x value with a positive output and an x value with a negative output, a zero must lie in between. Simply use bisection to approximate this zero. The graphing calculator has a built-in function that does this for you.

She then went on to explain that we won't be allowed to use graphing calculators on our text next week, and that we will need to show her we know how to bisection search by hand by showing our work on the test.

Bisection search, by hand? Really? I could write a program to perform this task in less than the time it takes me to perform it once myself....

Bull****. Someone that cares about building a business, or making clients happy/productive, or all sorts of other valuable goals other than just making good code will often choose paths that don't involve building the nicest most perfect code ever.

Saying you should always make sure your code is in great condition is all nice and fuzzy but just stupid. It's as dumb as saying a person/business/government should never go in debt.

It does kind of ignore time constraints.

Incoming debate over the semantics of where a pure trades man stops and a business person begins...

I don't know about you but most time spent is maintaining old code bases, not building brand new stuff. It's moronic to rush through making something new with somewhat poor practices because you're going to get burned later on when you need to change it.

I hate my life when clients ask me to change stuff on their sites that I made a long time ago. It's such a massive hassle.

I'll never produce horrible code again, the technical debt is just too much. I don't aim for perfection on iteration #1 but I will aim for something that would be considered good quality. I would spend time to make sure things are decoupled, properly tested and documented.

Not only is it hard to find a person like this - it's hard to keep giving good code review feedback if you're not actually working with the code on at least a semi-regular basis.

As an addendum to my earlier story about the guy who didn't know SELECT COUNT(*) - he's the ONLY person I've interviewed that didn't know that answer. That's part of our written test that's done on their own, so I wasn't able to get further context on his lack of an answer.

However, he didn't get a single other question right. I don't think I would disqualify anybody for missing any one particular question, even one as laughable as the SELECT, but he's going to have to impress me a hell of a lot in other ways to get the job after that.

Code isn't like a car. It doesn't rust. Even if you're 'maintaining' code you're still making changes (fixing bugs, speeding it up, adding a new feature, ...). And presumably if you're making these changes its because they produce some value.

If you're building yourself a great new football betting simulation it's probably moronic to miss a season just so you can have nicer code.


What does this even mean? It's as stupid as a business saying "I'll never borrow money again! The cost of servicing the debt is just too much!".

This doesn't even have to be a business/money issue. Most of us don't build stuff just for the sake of building stuff (at least not for the majority of our time). We want to get something out of the software and usually the sooner you get that the better. Not to mention we don't have unlimited hours in the day...