Hey guys, I wasn't a CS major and never took an algorithms class, and took one systems class and did well. In the short term, I'm interested in mobile development and in the long term I have some interest in AI/machine learning. Thinking about taking one of either http://www.udacity.com/overview/Cour...44/CourseRev/1 or https://www.coursera.org/course/algs4partI. Which would be more useful?

algorithms are going to be more generally useful, but it doesn't matter so pick whichever looks more interesting to you.

I'm much more sceptical about pair programming when it comes to two outside guys pairing up. I'd much rather have outside guys pair up with my own people or no pairing at all.

Inhouse gogogo pairs (and switching them around often)

Assuming this was based on my post - what happened is that we were short developers for a project and so we brought in this company to give us 4 extra developers. They were quite good (and freaking expensive) and they would come in to our office every day and work with 2 in house developers (one being me). We worked as one team so all combinations happened.

I don't want to get into it after the last debate but fundamentally my view of pair programming is very similar to that of refactoring and testing.

Some people lump "bugs" and "poor code" as almost an infinitely expensive thing. That ends up causing philosophy's like "always refactor", "always pair", "always test" since the cost of doing those things is always less than the infinitely expensive "bad code" boogeyman.

As a manager, the most obnoxious thing about pair programming is when developers pair for mindless and/or simple work. I see the value of it for a lot of work; I don't see the value of having one person stare at another person echo variables in a PHP file.

I'll take your word for it, the wiki you pointed to isn't as clear about it as you are.

I thought about my stance a bit and the technical dept metaphor and the "sometimes you have to take on debt" is pretty convincing.

It's pretty interesting that I have never had any debt in my life either. My credit card is essentially a debit card, never bought a house, saved up for all other big items.

I wonder if I have just some deeply rooted mental bias against dept that keeps me from being more rational in some situations.

You can't compare it to real debt because it makes no sense.

That's when you should use spoon programming:

.

Maybe you can relate them but we need to make the same case from both ends.

jj has proven that he's clearly one of those developers who values upfront dev costs on the stages of development that take the least of amount of time. That seems like being impatient to me. It's like some donk shoving all in with 20% equity but he actually knows his odds up front and is aware of the repercussions.

Most people are extremely impatient and real life debt creeps up on them and then it's too late because they are consumed. This can be related to programmers just throwing in the towel and saying "well, the code base is wrecked... we need to rewrite it as version 2.0" except in real life you don't have this liberty unless you file for bankruptcy.

Thanks for reminding me how awesome it feels it to be the exact opposite of that.

It looks like you've decided to go against your previous posts and now see that technical debt is very much like real debt. And yes, just like with real debt, if you ignore technical debt for too long you will have to "file for bankruptcy".

I'm glad I could teach you something in this thread.

Linux - jjshabado
GNU HURD - Shoe Lace

Cutest. Burn. Eva.

Why would a pgdump be throwing an error when I am uploading it? Wouldn't this dump be completely valid if it is going into the same database that it came from?

The old job managed to eff up the database on the very first time they used it. I couldn't protect the data on one table and of course they have to mess up the data in that one table...

No one enjoyed the spooning vid? I thought that was hilarious. Nerd humor ftw.

It was good. I was too caught up in making my sense/cents pun though.

What if I proposed a sickness metaphor instead of a debt one? If you don't treat it it'll fester and become worse. I guess that's the same metaphor but with a more grim outlook?

"code is sick" = your view is favouring instant improvements, you can get by with letting it sit for a bit but the collapse will happen (clowntable base worldview)
"cod is in debt" = your view is that you can get by with a couple of issues here and there and the collapse is fairly unlikely (jjshabado base worldview)

i can think of many reasons to take on debt in the short-term, but none for becoming sick in the short-term (i don't think a follow-on vaccination metaphor is particularly accurate or useful).

Let's see: most haphazard attempts at treatment are worse than no treatment at all. And anyone promising an easy cure for a complex set of symptoms should be viewed with suspicion. And health is much more about exercise, good diet and otherwise healthy lifestyle (become good at programming and write good code in the first place) than frequent medical intervention aimed at fixing bad code.

I take a pragmatic approach to this:

Big issue that I better make sure is as perfect as possible: first few pages in a new framework that devs will be copying off of to create new pages

Little issue that I can leave to a more junior dev: one off weird custom list with a bunch of bells and whistles

But I will say that prototype code almost always finds it's way into active code. So if you can do it right for a tiny bit more effort - it's definitely worth it. Also IME it's really really hard to go back and completely rework bad code. Refactor yes. But even if I know the initial approach is probably wrong, for some reason it's very hard for me to start over and go down a different path. So I do try to get it right as much as possible the first time.

My AMA thread is off to a roaring start

I still think the problems you and Shoe Lace are talking about are largely imaginary. In practice, I only see problematic bad code bases in three cases:

1) The technical staff is bad - their level of competence is inadequate or barely adequate for the technical problems they are asked to solve. I think this is what you see in trivial cases you guys are talking about. The kinds of light refactoring you guys are talking about either don't matter in the first place, or to the extent they do, good software developers do without talking or trying. Replacing some instances of repetition with an abstraction mechanism isn't some magical "refactoring" that "improved the codebase" - it's just coding and that's all coding really is. STFU and code, there's no need to attach this sense of accomplishment to a mundane task that's just part of what we all do.

2) The technical staff is severely demotivated, isn't sufficiently empowered to solve technical problems they encounter. This happens in just about every non-software company that does software in-house with the same managerial structure they use to manage non-engineers in place.

3) Rapid change in requirements leads to the technical staff having to circumvent previous design/architectural decisions of the past to solve technical problems of the present. This is true of almost all complex large systems.

You can't just make an assumption that the programmer sucks. We're taking about equally skilled programmers having the choice of going the "I'll fix it later" route or fixing it now.