Perl doesn't have real macros. It has a pretty neat, get you most of the way there aftermarket bolt on. Kind of like its object system. Similarly, you can do a lot with it. But it ain't Lisp macros.
>in other languages there seems to be much more consensus about what features one should use, how and when
Especially in theory. Python so desperately wants to not be Perl in this regard, so much that they codified it into PEP 20: "There should be one-- and preferably only one --obvious way to do it."
The theory is great, but if one reads their standard library it is clear that practice does not agree.
Reliable transport is a hard problem, and a problem that TCP does a good job of. I have to add ACKs to my application layer if I write code atop telehash when I care about delivery of my datagrams? That gets hairy, real fast.
It's the part of your comment I think is crazy. Of course I'm going to comment on that in particular.
I believe you mean, "I don't understand how that could be the case."
No, I don't. Professional programmers get paid to release working software to their users. If they haven't done that, they haven't done any "great programming". They probably did some clever coding while they failed, but it wasn't great programming.
So as far as I can tell, what you're saying is that it's impossible to take any process ideas from an external source, because every team is already maximally efficient.
Nope. I'm saying that the process of programming is what we should focus on getting better at. We should take improvements from wherever we can find them. Getting better at the process of Agile or Waterfall or Scrum or XP or Kanban or whatever else is dreamed up is tangential to our progress as programmers.
I had to remove the font-family: 'PT Sans' declaration from your site's CSS using Chrome's element inspector in order to read it. Chrome 16.0.912.77 on Fedora 16 here. I believe PT Sans is a readable Russian language font (but I don't know that). It's not (especially when italicized) a readable English language font: http://imgur.com/jqA36
Oh, I agree. My language was for emphasis, not representative of an emotional state. It's interesting to talk to someone who thinks that the same process can save a bad team and make a good team better. That though had certainly never occurred to me.
A 15-minute standup isn't going to hurt a good team's productivity, while it could greatly improve the productivity of a mediocre team.
It takes a lot to noticeably hurt a good team's productivity. But it's mean, just fucking mean, to punish a good, productive, communicative team with more process because you also manage crappy teams.
"Good enough" is certainly better than "not good enough".
In the scenario that you described, someone went from not communicating at all to lying every day, and getting "caught" at the end of a sprint. Standups didn't fix anything there. Also, there is a world of difference between calling something good enough, and it being good enough.
If I'm managing 5 job sites ... once a day sure beats nothing
If, as a manager of 5 teams, you feel like you need a direct, daily report of what every person on every team does, your life is going to be hard. If you attempt to control those teams by adding more process, you will interfere with the productivity of your good teams, and your bad teams will continue to suck.
"Sure it can... If he lies every day about what he does, the longest he can go is one sprint before his work gets verified."
That's not fixing bad communication. That's wrapping it up in process, and calling it "good enough". The team communication, and probably its morale and output, still sucks.
"etc. Pretty much what actually happens at a construction site"
That communication happens continuously, throughout the day. If isn't happening continuously, throwing a standup at it ain't gonna fix it.
You say "techniques of effective collaboration", I say "talking to people". If you need guidelines for that, that's cool.
The thing that suggests to me that you and I wouldn't work well together is that you make broad value judgements based on twisted interpretation and extrapolation of these comment threads.
No amount of process can fix bad communication. Standups are an attempt at that. Teams that have good communication succeed more, and standups aren't integral to their success. Teams with bad communication fail more, and standups can't help them.
Sales teams and sports teams don't work as a comparison, they aren't building something (sales is a particularly bad example, most sales team members are in direct competition with each other). I'm trying to imagine standups on a building site.
Tom: "Yesterday I.."
Everyone cuts Tom off and talks over each other: "No shit, Tom. You're gonna work today, too." "That insulation isn't going to unroll itself!" "Tell us, dear Tom, will you be screwing the sheetrock in with a DeWalt or a Hitachi?"
Good teams communicate while they build, and know where each other are.
I meant to answer your original question, but HN decided I couldn't post any more under "itsnotme".
"So how do you build things that take thousands of programming hours to complete?"
By programming for thousands of hours. Through the process of programming, I'd try things out, use what works, dump what doesn't, write tests first where it makes sense, last where that makes sense, not at all where that makes sense, buy hardware where it will save me time and money or work better, interface with it by writing code, step back, look at some mistakes, rip them out, replace them with nothing if I can, or less bad mistakes if I can't replace them with nothing.
You know, programming.
If in addition to my process of programming someone wants me to tolerate some other meddlesome process, well, it depends how meddlesome that process is. If they want me to use a particular IDE, they can fuck right off. If they mandate I write code in a particular order, they can fuck right off.
On the other hand, if they are awesome people with awesome product, I'll engage in standups (or whatever), and I'll write my cards and move them along (or whatever), and burn down my time (or whatever). But I won't pretend that it part of the process of programming, or that it's speeding things up.
Processes implemented to save lives are the product of death, and the process is put there to slow things down. Ask your friendly agile consultant how much their process is going to slow down your company.
They will tell you that Agile will make you faster. They might even be right, if it's replacing a bigger, worse process that already exists on top of the process of software development. But if it's adding a layer, it's going to slow you down and get in your way.
HN's algorighm thinks I'm a spammer and wouldn't let me reply, but really, itsnotme.
I could collaborate well with that person. If I like the product and the people enough I'll work on a team that uses "Agile". But I do it knowing that process is not communication, and that standups are a fucking joke.
I think you meant, "Self-promotion: As a hobby...".
And that's just fine, I for one appreciate it.