They left out the guy who can't tell you anything useful about anything he's looked at, except for the ways in which it was incomplete.

I'm not on the list.

/lazy and dumb

They left out the theoreticist. They can tell you everything about a specific topic, except how to make it work in the real world.

I'd say there were really 0xE types, but that's just me.

I laughed at the dynamic typist.

Honestly, why wouldn't you want static typing? The only valid example I can think of is pThreads, and that was before they had templates.

The Duct Taper

If you get the right output for any given input and it operates within the constraints defined - it works. We can make it pretty tomorrow. Deferred.

The web programmer who INSISTS ON EVERYTHING BEING IN A SLIDE FORMAT

Hit the 'print' button to get a single page for the article.

Not on it. :-(

Rules when you work on my development team.

Axiom 1: Your code sucks. I know you think it's elegant and streamlined and beautiful, but it's not. It sucks. So did the guy's that you replaced, and so will the guy's that replaces you. So does mine. Everyone's code does.

Axiom 2: What you are asked to build today will not be what you are asked to build tomorrow.

Axiom 3: You are a function of a business. You are not the business.

Therefore

1. You will document your code, because your code sucks, and no one wants to read it, especially me. If the words "You should just be able to read the code" ever comes out of your gawp in my presence, you are fired. Documentation should be appropriate to the complexity of the operations. I do not need a novel for mutators. I want a novel if you're modeling the weather. Your code isn't written for the customer, it's written for the maintenance guy that has to live in it after you're gone on to your next Death March.

2. You will abstract, and focus on reusability. You will focus on high pattern density because what the business asked you for today should not have to be completely thrown out because they changed they some things. Even if they changed a lot of things.

3. You are not solving technology problems. You are solving business problems. You will provide me with a domain model demonstrating your mastery of the business problem before you start solving it in code. You will also track, of your own initiative, the accuracy of your estimates against your actual time spent. You are not judged for being wrong. You are judged if you don't measure yourself and take a measure of professional pride in being able to deliver an accurate estimate to the business.

Weaver95: When some people rewrite code, the Duct Taper knows how to wrap some glue code in a proxy and translate the output to whatever format you need. Why get rid of a perfectly nice set of APL routines when a PHP proxy can turn the data into JSON?

Hey! you pretty much NEED to be a duct taper programmer to survive these days!

yeesh.

With turnover rates and the need to adapt to any situation in a timely manner, this is inevitable.

Link (new window) Obligitory.

They forgot the Unix/Microsoft/Java/MySQL/Assembler bigot. "We could do this so much better/easier/faster in [insert OR or language here]." Sometimes you just wanna scream STFU, but then they'd call HR on for creating a "hostile work environment."

/Tho I used to code in 8086 assembler, why fark bother?
//Remember when we had open fifths of whisky in the desk drawers ala MadMan?

Weaver95: Rent Party: Rules when you work on my development team.

[funny stuff deleted]

.

heh. I've seen people with that attitude before. most devs just work around it.

Most devs get moved off my teams, too.

In 20 years of development, I've never missed a commercial deadline. Those rules are why.

Moss.jpg

Weaver95: mavexe:

With turnover rates and the need to adapt to any situation in a timely manner, this is inevitable.

not to mention outsourcing. Dear god....those people....you have no idea.

we end up patching and hammering things into a rough approximation of what the business unit leaders say they wanted (which is pointless because we eventually end up talking them into doing something functional anyway) and then just not telling them how f*cked up their outsourced team(s) are.

No, I do. I've dealt with some "outsourced" code before, I end up rewriting it nine time out of ten. It's hilarious though, you can copy/paste some of the comments in that code into Google and get quite a few hits.

Weaver95: Rent Party:
Most devs get moved off my teams, too.

In 20 years of development, I've never missed a commercial deadline. Those rules are why.

Oh i've never missed a deadline either, but I find most of what you're talking about is pointless digression. not to mention micro-managing.

It's not micromanaging, it's just managing.

I don't care what IDE you use. I care that you ensure the code it produces is properly checked in and out of the repository. I don't care if your code sucks (because it does) I care that you aren't spending a lot of time having to go back and fix things. I care that you understand the business problem you are trying to solve. I don't give a shiat about your awesome solution to Traveling Salesman or Tower of Hanoi. Your tailing regression does not impress me. I care that you can deliver to the business the things the business has asked you to deliver. I don't care if it is going to take you six hours, six days, or six weeks, so long as you can tell me that up front. You don't get to say "we gotta throw the whole thing out and start over" because the business, of which you are a function, has a lot of investment in "the whole thing" and those kinds of dump-and-build decisions always end up as a loser. You might not like the Big Ball of Mud, but it's got years of features and fixes in it, and your new path isn't going to be any better in the long run.

Do you want to know why development is one of the easiest things in the world to offshore? Because smarty-pants code monkeys can't seem to figure out where they sit in the business equation.

I'm a mix of three

Programming personality type No. 5: The Dynamic Typist

I prefer a language that lets you be strongly typed when you need it to be, and loosely typed when you don't. Maybe there could be a directive at the top of the code, it should be a powerful sounding word like, "draconian", or "strict".

Programming personality type No. 9: The True Believer



Programming personality type No. 10: The Hand-Coder

I don't avoid using libraries, I wrote some of the libraries in the first place. I even rewrote libraries to fix bugs that the original person who wrote the libraries never saw because they barely looked at the code that was mostly generated by the IDE.

/spent too much time in the perl debugger and in jProbe only to find out that a library was the issue

/and please check your latest into SVN before I start doing the code reviews, damnit!

Rent Party: Weaver95: Rent Party:
Most devs get moved off my teams, too.

In 20 years of development, I've never missed a commercial deadline. Those rules are why.

Oh i've never missed a deadline either, but I find most of what you're talking about is pointless digression. not to mention micro-managing.

It's not micromanaging, it's just managing.

I don't care what IDE you use. I care that you ensure the code it produces is properly checked in and out of the repository. I don't care if your code sucks (because it does) I care that you aren't spending a lot of time having to go back and fix things. I care that you understand the business problem you are trying to solve. I don't give a shiat about your awesome solution to Traveling Salesman or Tower of Hanoi. Your tailing regression does not impress me. I care that you can deliver to the business the things the business has asked you to deliver. I don't care if it is going to take you six hours, six days, or six weeks, so long as you can tell me that up front. You don't get to say "we gotta throw the whole thing out and start over" because the business, of which you are a function, has a lot of investment in "the whole thing" and those kinds of dump-and-build decisions always end up as a loser. You might not like the Big Ball of Mud, but it's got years of features and fixes in it, and your new path isn't going to be any better in the long run.

Do you want to know why development is one of the easiest things in the world to offshore? Because smarty-pants code monkeys can't seem to figure out where they sit in the business equation.

Out of curiosity, what's the turnover rate for your devs?

I think I dislike #11 the most.

Under-documenter and dynamic typist here. I love me some Python, and I hate typing out what I am doing.

I also have a Scrum in about 26 minutes

Rent Party: Rules when you work on my development team.

Your rules are excellent and productive, thus proving that I wouldn't last 3 days with your company.

I'm definitely starting to feel old guard-ish these days. "Why change it? It's not going to work, it's going to waste time and money, and it's going to drive everyone crazy."

I need a new job. One that allows me to work as little as this one does. :P

Rent Party: 3. You are not solving technology problems. You are solving business problems. You will provide me with a domain model demonstrating your mastery of the business problem before you start solving it in code.

No. We are solving implementation problems. The "business problems" are the responsibility of Product Management and/or Marketing; you know, the ones with a high-level view and intimate knowledge of the expected use cases. If you're expecting your software team to do that for you, you're sort of a lousy manager.

/One and especially two, I agree with.

I'm at least 3 or 4 of the types.

Hand coder. I've been burned too many times by COTS that don't do what it says on the tin, or mandated, but stopping short of actually useful. If the choice is between spending a week making the tools that'll save a man hour per user per day, while eliminating 90% of the UI development, or spending that same week, per project, on patches, workarounds, and additional UI testing, I'll build the damn tools every single time.

Fubini: Honestly, why wouldn't you want static typing? The only valid example I can think of is pThreads, and that was before they had templates.

Static typing is useful if you know what data you're going to be working with when you get it. But the real world doesn't come in structured forms. I've had to build a few layers where I bundled up a group of lambda functions around a data structure that I didn't know the details of until runtime.

But I code LISP for fun, so...

//Cutting-edge coder, but I keep it to stuff that I actually see delivering benefits.

t3knomanser: Static typing is useful if you know what data you're going to be working with when you get it.

I should add, this is like 90% of your cases, and the other 10% can get wedged in there, if you Gang(of Four)bang the problem hard enough.

ProfessorOhki: No. We are solving implementation problems. The "business problems" are the responsibility of Product Management and/or Marketing; you know, the ones with a high-level view and intimate knowledge of the expected use cases. If you're expecting your software team to do that for you, you're sort of a lousy manager utterly redundant.

ProfessorOhki: If you're expecting your software team to do that for you, you're sort of a lousy manager.

Yes and no. A software team needs to understand the business value of each use case they're working on. While you really should have a business analyst that has already figured out the details of this, that's not always the case- especially when you are working on an Agile team. While I've never seen an Agile project run well (I doubt such a thing is possible), there are a lot of good elements ho having a highly cross-functional group.

MooseUpNorth: ProfessorOhki: No. We are solving implementation problems. The "business problems" are the responsibility of Product Management and/or Marketing; you know, the ones with a high-level view and intimate knowledge of the expected use cases. If you're expecting your software team to do that for you, you're sort of a lousy manager utterly redundant.

Tom Smykowski: Well look, I already told you! I deal with the goddamn customers so the engineers don't have to! I have people skills! I am good at dealing with people! Can't you understand that? What the hell is wrong with you people?

As a student:

The UnderDocumenter (though I'm moving away from this) -
Early student: "Hey this program is 300 lines of code in 1 file. Why should I comment?"
Later student: "Hey, this 3,000 line spaghetti code program is due in 3 days and was assigned last night. Plus no one else (including me) will ever touch this code again. Why should I comment (and where will I find the time)? Besides, true programmers can keep the entire (2000+ line) program and all the interfaces in their mental cache for a few weeks."

The Hand-Coder - Mostly because we aren't allowed to use the real versions of the things that we're hand-coding. I didn't use the STL at all until my junior year.

CYA Specialist - Group projects where no one's schedule lines up, so you play the game of toss the codebase around, and comment for the next guy.

The Faker - Yep, they exist. As long as they say it in advance (so I know that I'm gonna be doing the 3 man project by myself), I'm cool with it. And I've done it myself a few times, when 4 projects were due at the same time, by shoving 1 or 2 of those projects off onto my group members, so I can't complain.

/As a bonus, the "Rebelling Coder" (only seen among students) - "Hey, they're not grading us on [X]. To preserve my sanity, let's do X as terribly as possible, and produce memory leaky, un-commented code with lots of goto's for the giggles. And why use a lg(n) algorithm when an n^2 algorithm works just as well? Why? Just because we can."
//Bonus if the goto calls are in undocumented macros in a different .h file.

Fubini: Honestly, why wouldn't you want static typing?

Take this as an example.

I'm writing a program that takes a number as input from the user. Personally, I don't even care if the programming language checks to see if what the user inputs is a number via static types, because I'm going to check the format of that input to make sure its a number, along with several other business related checks. At the end of the day, I just want a box to hold whatever value I throw at it.

I personally don't care if that number is stored in an byte, short, int, long, float, double. Perl by default doesn't have strong typing, if you throw a number into a scalar that's too large for an int, perl dynamically increases the size of the type. IE, it automatically converts types so that you, as a programmer, don't have to worry about it.

Now, if you wanted strong types in perl, you could create a module to do the typing, or you could use one of the modules that's already out there. Further more, you could define what your type is even more specifically than you could with primitives. IE, if you want an int that's only from 1-10, you can create a tied variable that only accepts exactly that.

You could even create a type that accepts text, and converts it to a number. IE, if you store the string "ten" into the variable, it gets automatically converted to the number 10.

At the end of the day, the point is about choice. It's up to the programmer to decide when to use strong/weak typing.

/I use strong typing when writing modules, because there it makes sense.

/Another issue is that static typing tends to go hand in hand with another outdated programming pragma. Declaring the size of variables or the length of arrays. When doing heavy data file processing with perl, it's so easy to yank stuff off the front of an array with shift and push new stuff onto the end of an array with push and have perl worry about dynamically growing/shrinking the array on the fly.

I'm parsing a log file, it might have 100 entries, or 100,000 entries, and once in a blue moon, 1,000,000 entries. How big do I define my array? Ohh wait, this is perl, I don't care. (Also note, perl doesn't dynamically grow/shrink an array with every operation, it allocates a extra room so that it only has to grow the array after you add a certain number of entries, this is all transparent to you though so it doesn't matter).

lordargent: Declaring the size of variables or the length of arrays

It's also worth noting that many languages give you variable length linear structures, but they do it via linked-lists or some other OOP implementation. A true shifting array is more efficient for large operations. Mind you, I like to throw all that stuff at the runtime and let the language figure it out, but traditional arrays are awesome for performance.

t3knomanser: ProfessorOhki: If you're expecting your software team to do that for you, you're sort of a lousy manager.

Yes and no. A software team needs to understand the business value of each use case they're working on. While you really should have a business analyst that has already figured out the details of this, that's not always the case- especially when you are working on an Agile team. While I've never seen an Agile project run well (I doubt such a thing is possible), there are a lot of good elements ho having a highly cross-functional group.

Oh, I didn't say they didn't need to understand it. I'm just saying that the whole "You will provide me with a domain model demonstrating your mastery of the business problem" if done only for the sake of demonstration is a waste of time and means someone else isn't doing their job right. I can't speak to Agile since all I know about it is that it's one of the buzziest buzz words.

meyerkev: /As a bonus, the "Rebelling Coder" (only seen among students) - "Hey, they're not grading us on [X]. To preserve my sanity, let's do X as terribly as possible, and produce memory leaky, un-commented code with lots of goto's for the giggles. And why use a lg(n) algorithm when an n^2 algorithm works just as well? Why? Just because we can."

A subtype of the rebelling coder is the Because I Can - the code is sound but terrifying. Instructor didn't specify a language? Brainfark. If, else block? Not when I can nest ternary operators. Manta is "how can I abuse switch statement's fall-through." Profane or nonsensical variable names a plus. Especially they culminate to things like "return (up)(y->ou(r, s))"

/Controlling a loop in assembly?
//Dynamically rewrite NOPs over program memory

I'm scared. I'm learning C and don't know half of what you dudes are talking about.

/C is much easier to learn than any object-oriented language for me, not sure why

Mostly unfunny, except old guard. "The real Old Guards like to point out that their favorite computer didn't need to boot because the iron-core memory didn't shut down when the power disappeared."

t3knomanser: It's also worth noting that many languages give you variable length linear structures, but they do it via linked-lists or some other OOP implementation. A true shifting array is more efficient for large operations. Mind you, I like to throw all that stuff at the runtime and let the language figure it out, but traditional arrays are awesome for performance.

While performance is a good goal to have, it's often not the primary goal.

IE, when writing a script that's going to run for several days, shaving a few hours off the end doesn't really make a difference. But if you can make the script much easier to write and maintain, that's a different story :D

/take java for example, type conversion happens to be a big in the butt. UGH!

lordargent: While performance is a good goal to have, it's often not the primary goal.

No, but languages like Perl which conceal much of the cruddiness of managing arrays but still, deep down, act like arrays, have advantages. That's all I'm saying.

lordargent: /take java for example, type conversion happens to be a big in the butt

Primitive types was the biggest mistake Java made. .NET solved the same problem much more elegantly by distinguishing between value and reference types and never having any true primitives. Java eventually adopted that approach, from what I hear.

I do personally like languages with extremely limited, but flexible types- LISP is my go-to example. You have lists and atoms and that's it. Everything is built out of those pieces. Someday, I hope to actually understand Haskell's GADTs. Haskell is one of those languages everybody should play with, because it really does change how you look at programming. Most GoF patterns are entirely about managing side-effects- you have to write a lot of code to do that in OO languages, but not so much in functional languages.

mavexe: Out of curiosity, what's the turnover rate for your devs?

I'm going to take a stab in the dark and say it's around 183%

/Including the outsourcing.

Marine1: I'm scared. I'm learning C and don't know half of what you dudes are talking about.

/C is much easier to learn than any object-oriented language for me, not sure why

Because you're not dealing with the concepts of object oriented languages (polymorphism, inheritance, etc), you're "just" learning syntax and semantics. To be honest, you should just bite the bullet, and learn how to program using OOP methods. It took me a long time to fully appreciate the power of object oriented programming.

Marine1: I'm scared. I'm learning C and don't know half of what you dudes are talking about.

/C is much easier to learn than any object-oriented language for me, not sure why

I understand some of the basics of what they understand, but I'm only slightly less lost than you are. Somewhere I have a random output generator based on an input value of N, and it was impossible to get the same output if you put in a different input.

Marine1: I'm scared. I'm learning C and don't know half of what you dudes are talking about.

/C is much easier to learn than any object-oriented language for me, not sure why

C is a good place to start, you learn enough of the guts of what is going on to understand what things are actually doing in other languages where the language does it for you without having to dig so far down that you're writing in assembly or some such. I started as a hobbyist on C and haven't ever regretted it.

Do learn object-oriented stuff at some point though. It can make lots of things significantly easier to organize.

t3knomanser : No, but languages like Perl which conceal much of the cruddiness of managing arrays but still, deep down, act like arrays, have advantages. That's all I'm saying.

I totally agree.

The way I see it is that it's a tradeoff between CPU Cycles and Developer time and it has to be determined which one is more valuable for a given project.

If you're writing a program that runs non-interactively and processes a billion records, making it more efficient might save a day of run time (program finishes in 6 days instead of 7). But if there is no business advantage to that program finishing a day early, then there's no point spending minutes/hours/days of developer time to optimize.

OTOH, if you're writing program that does trades on the stock market, then every millisecond of speed counts, development time be damned.

/hmm, pay developers $x to optimize a program to run faster? Or buy faster hardware for $y to make a program run faster.