So, about that Microsoft-Yahoo Merger

So it was a slow day and I was reading about the Microsoft-Yahoo merger. How developers at Yahoo are fleeing in droves because Microsoft doesn't get the 'net and will ruin Yahoo.

And this isn't so say that they're wrong, but how about fleeing Yahoo for a better reason? Like, say, because of this embarrassment puddle parked out on the street in front of my shonky whip? I mean, come on Yahoo. I've never seen a Googlemobile, but I suspect that they're not quite as... butch as this one is.

(click to engorge this shameful display)

I've got no eye for color or detail, but... fuscia with the cheesy flame job? Really?

Then again, it did bring a smile to my face. For all the wrong reasons, but I was smiling. Way to go, Yahoo. Good luck keeping the corrupting influence of Microsoft far away from your pristine shores.

It's official - I'm a Python hacker!

Lately, it hasn't been building the application that's captured my imagination so much as figuring out a way to validate the correctness of the application. When you're dealing with a sprawling behemoth of an application of varying levels of quality (this isn't a dig at co-workers - I've got more than my share of turds baked in there) that's so absurdly data-driven that... well. I've come to grips with the fact that chunk by chunk, we've built a borderline unmanageable enterprise application.

There's blocks of the application that I'm flat-out scared to touch because of their fragility. There's a reason that Jenga never took off as an application platform.

There's so many tables (I'll ballpark it at 300, but it could be more than that) that I have to walk through stored procedures and table definitions to figure out why many of them exist. Thankfully, at least they're well-normalized even if, again, some are really, really arcane.

More interesting to me than anything else lately is testing the application. When it comes to a giant database-driven web application, there are no easy answers to "how do you prove it is working correctly?". Well, at least none that The Google is willing to impart on me.

As I've mentioned before and will be talking about again soon (I'm busy hacking, d00dz!), I heart the hell out of Watir. You run WatirMaker, you walk through your application, you're 80% or more of your way to a test case. But... it runs slow. It takes over 3 hours to run 130-ish test cases of varying complexity on the old desktop I snuck the regression automation environment on to. I love it, but I worry about its scalability.

Over on programming.reddit, I saw a new tool announced that tickled me in all the right spots - Pylot. It was designed as a web load-testing tool (I've seen the QA folks at work use Quick Test Pro, but it's a fragile piece of shit if I've ever seen (and built) one) and has lightweight validation features built into it. On that end, it's not as fully-featured as Watir (I've updated WatirMaker to do 31337 things like generate automagic tests when you click on text in table cells/spans/the body) but... speed! Free replacement for Quick Test Pro (maybe)!

I saw it and immediately got to wondering about writing tests for it - is there anything that will get me 80% there? Not yet. Could I take WatirMaker and update it so that it emits Pylot-friendly XML? Sure, but doesn't that feel just a lot unholy?

So I downloaded Python and got to work doing the crappiest, stripped-down-est translation of a useful Ruby meta-script to Python that you've ever seen. A few hours of grunting and banging my head later, I've got something to show for it, thanks in part to the duders over in #python on EFNet.

Does anyone have any experience working with buffer objects? I'm getting one handed back to me and I'm completely lost as to how to coax it back to a string.

um, str(yourbuffer)

that's what makes python so difficult to pick up -- its simplicity

If I were them, I'd clown on me too. In my defense, The Google wasn't all that helpful when it came to working with buffers in Python and I'm a complete new jack and calling yourbuffer.tostring() wasn't getting me anywhere useful and enough ball-aching.

So here's my first stab at PylotMaker.py. It requires the Win32 extensions for Python to run and you run it the same way as WatirMaker - pop open a command prompt and "PylotMaker.py > test.xml", browse around the Internet Explorer window that opens up, close IE when you're done and test.xml is set up for you. Minus tests.

Did I really spend 5 hours knocking out 44 lines of Python instead of playing Team Fortress 2? There's something way wrong with me.

A Few Binary Propositions I'm Comfortable Making

By the time I got to high school, I was ready to get serious about programming. OK, not get serious, but at least take some classes in it because that's how you meet ladies (note: that's not how you meet ladies).

I learned some lessons that I regarded as stupid then and quaint now (pseudocode your program completely before you sit down at a keyboard (read: hi UML or we pay for cycles on the VAX cluster)), but I also learned some rules which have honest to god stood the test of time.

When it comes to programming, I'm pretty uncomfortable making binary propositions - there's a time and a place for a lot of things. That time isn't the future because in hindsight, you can count on recognizing just how wrong you were to think that you could get away with that.

But fret not! Here are a (very) few rules that you will never kick yourself for following. These are laws. These are immutable.

Use clear, concise, self-descriptive variable names

Our task was to write a function to calculate the area of a rectangle. After laboriously pseudocoding it out, I sat down in Turbo Pascal and banged out some gorgeously hand-crafted code, using x1 and x2 as parameters for the length and width because they were easy to type. It worked. Flawlessly.

My teacher took a look at the print-out of my code and asked "Why not call them length and width instead?" I started to argue because that's how I roll, but then it hit me like a Zen slap - code is words, structured a bit differently and with a bunch of funny-looking symbols interrupting it, but you should try to make it as readable as possible. This starts with meaningful variable names and grows from there.

Thankfully, this is one rule that I don't break. Ever.

You should be able to describe what any function does in one sentence (and the word "and" should not be part of that sentence)

I try to decompose my functions, but I'm not nearly merciless enough in my pursuit of it. I don't set out to get there, but big gnarly if blocks in my business logic can spiral methods out of control, leaving me at the point where I'm afraid to extract out blocks because things might break.

This is probably reason enough to extract out blocks, but I'm bullshitting myself into not doing it for any number of reasons - I tell myself things like "the code is complex because it's modeling a complex process" but I know just how much of a cop-out that is. It's lame and embarrassing and if only that code weren't working and I wasn't so afraid of it, I'd do something about it.

Honest. Probably.

Thanks to playing around in Haskell, I'm rediscovering just how powerful decomposition can be. You can, like, build big things out of little things and stuff. It's easier than the God Functions because you're just building ever-bigger functions out of ever-smaller, easy-to-test functions.

Next time I'll get it right. I hope.

A cat should be able to walk across the keyboard without interrupting your program

Does this sound like "validate client input"? Because it is. If you want to be fancy about it, you could say "don't trust client data any more than you absolutely have to." Either way, this is rock-solid advice.

You should not be building software where you're afraid to enter a number for a name, a letter in a date or (god help you because I've used garbage like this) click in a form while it's processing because something disastrous will happen.

I also manage to not break this (most of the time). That said, when I do things like, say, set maximum lengths on input boxes on my pages and don't test the form data on the server side, I have a pang of guilt that I'm not really solving this properly (and I ignore it and move on).

When the dam breaks, work on the first problem first

The blogosphere will tell you that this is Tilton's law. When our programs would invariably break, I'd look at the jumble of garbage on the screen and start inventing ever more elaborate explanations for what just happened. Maybe I overwrote the video buffer with a whoosiwhatsit and flargened the backplane with a sympatasultic bitmask!

My teacher sat down and asked me what went wrong. I started to spout some nonsense about this and that. He listened to me for a minute, then stopped me and said "Why don't we start from the beginning and see where it leads us?" Surprise surprise, I'd made some bonehead mistake or other (but 17 years later, I couldn't tell you what).

This came back to haunt me just today. A hot issue that must be fixed now got dropped in my lap yesterday in an application that's kind of sort of orthogonal to the one that I develop and support. So I start looking into it, but I can't get it to run out of the box. I fight with it more and more and more and a day and a half gets burned making just about no progress as I'm trying to chase the downstream effects, waiting for them to lead me back to the cause.

We get on a conference call to talk about the status and I hear people say what they were trying to do (it had been e-mailed to me before) and it clicks - check the data setup.

I'd taken for granted that someone else had done this already, but lo and behold - it's wrong. 12 hours of wasted time could have been saved by 5 minutes of fact-checking.

It's easy to get caught up in Rube Goldberg contraptions to explain what could have gone wrong and on some perverse level kind of fun, but on another, it's more fun to start simple and fix the root problem rather than chasing a symptom.

I'm batting .500 or so. It's enough to get me to the big leagues, right?

Working Hard to Get You Fired

When we first started porting from ASP 3.0 to C#, I'd never heard of test-driven design (why hast thou forsaken me (in 2000), blogosphere?!??!).

When we had a second round of developer hires, the two guys were gung-ho to get us on the Path Of Continuous Integration and get us all test driven and stuff. Were it not for the fact that we already had 200-odd KLoCs of legacy code of varying quality that would need to be refactored to be testable (in retrospect, I'm aware of just how big of a cop-out that is) and deadlines looming, we might have gotten on board the TDD train. But had the blinders on, so that never happened.

I've done some refactoring to bake in poor man's testability (objects that audit themselves and throw exceptions for as many offenses as possible) but the fact remains that building new functionality and fixing old issues often feels like sticking thumbs in the dam - I can feel when something's going to break, I just can't tell what or where.

About a year ago, the QA department hired someone to do automation for them. I was pretty pumped about it the application that we've built is that it's so big (400 KLoCs of C#, some ASP.Net controls, another 75-100KLoCs of T-SQL, bits and pieces of BizTalk) and so data-driven, at this point it would take something just short of an act of god to get it to a point where it's testable. I have little to no desire to be part of that and have never pushed for that sort of intra-object testing. I remain unsold on the promise of TDD, but I'm not so arrogant as to completely discount it; it's more that, like security, it's not something that can be bolted on. Maybe.

Simulated end-user QA automation - that's the testing that I can get on board with. I've been using the super-hella-sweet Watir for a while now and have handed it out to developers, product development, QA, even customer service reps when I want to replicate problems; it's been a godsend. I've built smoke tests that I can run on each deployment build that have saved my bacon more than once. I don't know how much you can tell about how the application's working or not working from inside of an object, but it's pretty easy to tell when things aren't working with it when your scripts break while being run.

The QA automation guy? Nice enough chap. He's personable, seems to know what he's doing and all, but... a year in and I've got no test suite to run. Enterprise-grade tools mean awkward enterprise licenses (we actually run a fucking license server somewhere or other- what the shit is that?) and all the user-friendly quality you'd expect from anything enterprisey. Plus I suspect that the goals were too lofty, that they were intent on building something beautiful and perfect and settling for nothing less. Which is great and all, but daddy wants his application tested already.

We've hit one of our cyclical lull periods at work. This isn't to say that there aren't issues cropping up all the time, patches being sloppily built and hurriedly and incompletely tested (business as usual!), just that the volume of issues is decreasing and management's hemming and hawing about what new features to build out. I've been sitting on my hands, getting micromanaged on what issues need fixing and what can be left to slide, so I took a look in my Watir folder - hey look, 100-odd scripts testing and regressing issues that we've logged for the past year or so. Most of them broken at this point because of genuine application changes, but whatever.

I set out to fulfilling the promise I saw in testing when I first brought it up - that not only were we saving time with each test, but that we were organically building up a test suite, testing the things we needed to. Getting all of my test scripts working was step one. Step two, the uglier step, was taking the user out of it. Before, I was relying on the end user (the QA person it was aimed at) to push a button in an internal GUI here, look at a piece of data there. But with a few Ruby system() calls and poking at the content of spans and tables (time-consuming as that is), that's fallen by the wayside.

The next hurdle was the database side of things - there's some pieces of data that don't make themselves evident in the application to the end user, so how the hell am I supposed to test for those? Oh - you can pass variables (like the auto-generated user's ID) in to SQLCMD.

So a week and change of me ignoring this and that piddly little issue later, and I've got 3 dozen or so scripts built out and checking things. Another couple of weeks or so and I'm going to have an honest-to-god test suite and, if anyone's paying attention, a QA automation pro's going to have some explaining to do when I've come correct with a reasonably not-too-shitty regression suite in what amounts to my free time and he's over a year in and still hasn't produced smoke tests. And if no one's paying attention and nobody gets canned for it, I'm not losing any sleep over it because I'll have scratched one hell of a big itch.

If only my solution was enterprise-grade, we'd be able to use it too.

Breaking the Hype Cycle

Like a good .Net drone (haw haw), I rambled on down to Waltham, Mass. this past Thursday to get introduced to the brave new world of .Net 3.5 and Visual Studio 2008.

I found myself going through various phases of confusion, boredom and then (eventually) excitement. Confusion over David Chappell (sadly, not the sometimes Rick James impressario) and his speech there. Given that he's written books on stuffs, has a consulting firm and talked about opening for Bill Gates at some development conference, I take it that he knows his thing. That's great and all, but... this was a developer's conference or so I thought? The man can give a good speech, but I'm still clueless as to why he felt the need to sell developers on the .Net ecosystem as a viable platform. Preaching to the converted and all that.

Todd Mancini came out next to give a talk on Visual Studio Team System. When I first started reading about it, it felt like it was just another enterprise Rorschach test but seeing concrete examples of what it does (how many use cases have been fulfilled, how many have been tested by QA, how many have unit tests, code churn, yadda yadda) I can see that behind the scenes it's a pretty slick little piece of work... more on that later.

I was remarkably confused by the talk that Allan da Costa Pinto gave. I'd signed up for a couple of sessions on .Net 3.5 and Visual Studio 2008 and for some reason got treated to an hour and a half on Windows Workflow Foundation and the Windows Communication Framework. He gave an OK enough presentation, but goddamned if I could tell you what either of the technologies are. Repeated over and over is that "you can paint your business processes" but what drawing a workflow diagram's achieving me is still beyond me. I get the feeling that there must be a lot in there, but I also have no idea what's in there or why I'd want to use it. Maybe it's targeted at a different user space or maybe it's a solution in search of a problem? I do know that you can start a process and wait up to 30 days to take the next step in it! Yes, it means fuck all to me too.

Chris Bowen, the last speaker of the day, was finally the guy who got me excited to have gone down there. Away with the 10,000 foot view of what's new with the .Net platform (too goddamned much to follow) and into the new language features (anonymous functions! anonymous types! lambda expressions! extension methods! all that good shit that perversely makes perfect sense since I've been embarrassing myself by trying to wrap my head around Haskell and functional programming) and a good, quick, runthrough of LINQ.

When I first heard about LINQ, it sounded kind of retarded to me. Hey look, it's sort of SQL. Except the select clause comes at the end and it's uglier? No thanks! How is this supposed to do anything for me? Why would I want to write not-quite-SQL and then deal with object/relation impedance on top of that? I can see it working for CRUD, but I've got joins that pull together 25 tables (god help me) and I really have no desire to try to get that to work in code.

But curiously, seeing it in action, it all made sense. LINQ-to-SQL is something that actually had my mouth watering. That same terrifying stored procedure I mentioned relies on an underlying user-defined function that broke the other day as well as views as well as... well, you get the picture. I'm mixing and matching business logic with data retrieval logic and I'm not happy about it. I was never really sold on having data retrieval logic in the business classes (I dallied OR mappers and was never really impressed by what they were doing for me) but I'm changing my mind now.

Autogenerated paramaterized SQL queries? Internet says that LINQ-to-SQL can actually outsmart you when it comes to query optimization... not that this is saying much when it comes to my SQL-fu. Chris gave a run-through of the features that went from what they were in clear terms to how they work in clear terms, and it all really clicked. I was pumped to go home and start ripping out that library of 250-odd stored procedures and start rewriting them in LINQ-to-SQL!
Except, oh yeah. We already have 250-odd stored procedures and they generally run pretty well. Writing them isn't hard, maintaining them isn't that bad. Sure, we've got business logic turds floating in our database punchbowl, but I'm too lazy to fish them out when I've got so many freaking bugs in the application to fix. The language features are really nice (extension methods still have my mouth watering) but by the time I was in the elevator down, I could already feel my excitement to Change The Way We Program dying as I got to thinking what Fred Brooks would say - this all is attacking accidental complexity, leaving the essential complexity of what we do untouched.

So it was the talk on Visual Studio Team System that left me the most sort of excited. The idea that the application forces you to work in sane, cohesive process (unit tested code, tracking user stories and the work projects associated with making them happen, lines of code, bugs open with the stories) seems like it'd be forcing you into dealing with the essential complexity of software development. Rather than pretend that you can crush that Gantt chart down and cut QA out of the cycle, you're forced to accept the fact that the constituent components of the project are missing in action and until that's done, the application isn't.

Nice stuff. Now all I have to do is find a company that'd understand the need for it.

How I Got My Silver Programmer Certificate

OK, I didn't. It doesn't exist. It won't exist.

There's more than one way to look at the ongoing kerfuffle over whether schools are falling down on the job or not. You can play the hyper-cynical devil's advocate and point out that in a sense, undergraduate computer science degrees are right up there with vo-tech degrees (not that there's anything wrong with that).

a degree is only as meaningful as its scarcity

Which brings us to another way to look at it - we can quit the ball-aching already because the knowledge that colleges are teaching Java instead of Lisp means pretty much fuck-all for us. Seriously. If I'm staffing for a company, I'm not pinning my hopes and dreams for future success on the fact that I've got a few recent computer science graduates working for me, even if they're from an ostensibly top-tier school. I'm hiring the guys with track records for delivering software that can talk the business domain talk (and it's a really awesome bonus if they can talk radix tries too).

College degrees don't prove that you're ready to develop in the real world. Holy shit.

Wait. This is news?

Certificates, whether they're diplomas, training certificates, passing the bar, getting your doctor stethoscope, being a certified engineer, whatever - I read them as signifying one thing only - "this person's certified to prevent me from doing anything immediately catastrophic." The lawyer may be grossly incompetent at what they do, but they'll be able to advise you enough to not land you on death row for your parking tickets. The doctor's not going to prescribe dioxin for that headache. The engineer's not going to say "what the hell, it might work" to your grand plan to replace the steel girder wire on the bridge with Silly Putty. That comp sci grad will probably be able to put something together that compiles.

You're looking for a piece of paper that certifies that the holder is an all-world programmer who's going to fix all your code problems? Sorry, doesn't exist.

Still another takeaway from this - enough already with whatever feedback loop there may be. Businesses think that they need more computer people, so they drive up demand for comp sci graduates, so colleges lower the bar for what it means to be a comp sci graduate so you can get churned out to go work at a conglomerate. I'm a schlub who went this route (or this route found me, your call), so who am I to turn my nose up at it?

This seems to presuppose the notion that there's a supply-side fix to be made here - get businesses to understand just how meaningless the comp sci degrees are and academia will disentangle itself from business and we'll find ourselves in some sort of OK-well-maybe-it-never-existed nirvana where every computer science graduate can knock out a generational garbage collector blindfolded and works on their own system kernel just for kicks; that academia's gotten too caught up in what business needs rather than keeping their heads in the clouds and looking decades down the road.

I don't buy it. I became a programmer because I've got a terrible craving for learning. I think that's the thread that underscores all at least mediocre programmers - we're auto-didacts. It's why I giggle to myself when I see the "how can I teach my son to program" question thrown out there. If they really want to, they'll find a way. If they have to be dragged there, I'm sure they'll find a 9-5 in the cube next to mine some day.

It's why I'm left scratching my head about people bemoaning the death of the comp sci degree. Saying silly things like "you go to school to learn how to learn." Bullshit. You're born knowing how to learn. Some people will learn no matter what, others are content with what they've learned and will figure out how to apply it in new, interesting and sometimes inappropriate ways and still others make me wonder just how fictional Idiocracy was (kidding! (maybe)).

Management Conundrums - The Cowboy

I read an article refuting the value of crunch time and got to wondering about it.
I've been the cowboy before, working 100+ hour weeks. Dreaming in code, pulling 24 hour days, a real Team Player. I don't want to ever go back there again. I'd like to prevent people I work with from going there too.
I found crunch time to be a vicious cycle. Rather than sit back and think my way through the problem, I dove in head-first and bumped my head on the bottom. Hard. Repeatedly.
I found myself working long hours, making mistakes along the way, and then working longer hours because I told myself "I'll just fix this later." And then working longer days because I couldn't remember the fix that I had in my head earlier but it all seemed so clear to me and in retrospect, fuck embracing death march values.

To push my street cred through the roof, I'll just quote Bun B who puts it better than I do.

Start with your head, homie, then use your hands / If you try it in reverse, you don't even stand a chance.

I don't know if it's confirmation bias on my part - I'm a pretty lazy guy (note to anyone daydreaming of hiring me: I'm totally joking about that). Am I just buying into what these people and their so-called "studies" are saying because I'm (*cough* not) lazy and want to believe anyone that's telling me that working a square 40 hours a week is really OK and even preferable?

The thing is, not everyone believes it - and this is not just managers that I'm talking about, either. As the comments on the article over on programming.reddit show (and as my anecdotes reinforce), some developers have an almost bloodthirsty need to believe in the power of crunch time. There were a couple of chaps in there extolling the virtues of brutal hours of work, stating that without doing months of crunch mode, their projects wouldn't have finished. I prodded, trying to lead them down a path to questioning whether the projects might have finished in the same amount of time without crunching for it, but it was rejected out-of-hand.

The Mythical Man-Month gave us the should-be-more-famous truism that "you can’t get a baby in one month from 9 women" - some tasks really are going to take a set amount time no matter how many resources you throw at them. The mother can start pushing on day one or wait until month nine to start pushing; the baby's not coming out any faster no matter how many months she's been pushing. I think that believing that you can accelerate nature (I'm talking development projects now not babies; work with me, people) is equal parts foolhardy and arrogant, but I also think that a good developer needs a healthy dose of both of these qualities.

When it's a team gelling and putting in the overtime because they want and need to, you let it go. That's a no-brainer. Of course, you can't go on auto-pilot. You need to figure out when they're sprinting to a dead end, when they've started sprinting too soon and have been sprinting so hard that it's counter-productive and maybe you should kick them the fuck out of the office at 5 PM on Friday so they can see their families and come back ready to do good work on Monday. You need to reel them in at some point. Like any design pattern, "crunch time" has its use. Just take care to not treat it like a golden hammer and you'll be fine.

It's the lone cowboy that I'm concerned about, and I'm concerned about what to do with them. When it's a team working to a goal, they're building together. When it's the lone person banging away at all hours, they're using their back more than their brain and will miss simple, obvious solutions to their problems and get aggravated at everyone else who isn't putting in the same brutal hours they are.

Part of me wants to save them, but then again I'm not sure that anything can be done with or for them. Reason, logic and studies seem to bounce off of them (it did off of me) like bullets off of Superman's skin.

At my current job, we had a cowboy developer. Good developer, smart guy, put in long-ass hours. Went on vacation, came back in with a custom XML business rules engine (like Drools) that used .Net Reflection and all that good stuff to drive it. It's pretty good code, just that in retrospect... we didn't really need it. I never had the heart to tell him that outright and thousands of lines of code nobody wants to refactor out of the application remain today.

When he eventually left, another of our developers quietly became the new "hard worker" to pick up the imaginary slack left behind. I don't know that I'd even have noticed this quiet change if I hadn't read The Lucifer Principle by Howard Bloom (this and The 48 Laws of Power are Dave Solomon picks for bizarroland must-read management books).

In The Lucifer Principle, Bloom relates an anecdote about a researcher's study at a summer camp. The researcher had identified four major archetypes for kids in group behavior - the "alpha male", the "bully", the "joker" and the "nerd" and conducted an experiment with them (nothing on the level of Milgram or the Stanford Prison Experiment).

The scientist assembled a cabin composed entirely of "leaders," boys who had been dominant, "alpha males" in their old groups. Very quickly, the new cluster sorted itself out according to the familiar pattern. One of the leaders took charge. Another became the bully. A third became the group joker. And one of the formerly commanding lads even became the new group's nerd.

- The Lucifer Principle, Howard Bloom, pg. 92

I know I'm doing a terrible job explaining this, but what it comes down to is that I've seen the shift in my co-worker and I don't think it's a conscious one. He may think that he "needs" to work longer hours (I've certainly danced around it trying to get him to feather the brake pedal on it, so to speak) to get things to work, but could he explain why?

Of course, self-interest on my part demands that I don't push them too hard to not kill themselves. I'm not the boss and if he's not doing the long hours, I'm sort of afraid that someone else is going to give me the stink eye because I'm not checking in code after midnight just before I leave on vacation to show that I'm a team player, never mind that the code's invariably broken in some hideous ways and people are going to have to quickly find and fix all the mistakes I've made because I was tired and rushing.

Moreover, like I said, I suspect that there's some subconscious understanding about the archetypes (for developers, read: "design pattern") of a team, and that the "overachiever" is one of them. I know just how loaded the word archetype is which is why I think it's probably an aft metaphor - if our work habits are indeed an unconscious manifestation of our identity, then there's no clean way to divorce one from the other - the cowboy's going to keep drawing for that six-shooter no matter what you do and resent you for telling him to keep it on safety before he blows his foot off. They may not be able to do it any more than you could conquer someone's fear of snakes just by bringing to their attention the fact that they are, in fact, terrified of snakes (I suspect this is an easier one to break though). Moreover, you get rid of one and another will rise to the occasion.

Unless you do what you can to make them and everyone else on the team aware of your distaste for their overwork and unless your boss (and bosses all the way up) are on board with holding people to a square forty, I doubt it will happen.

Sadly, getting everyone to throw fallacious common sense overboard and accept the fact that working smarter and working harder are just about always mutually exclusive and working smarter beats working harder just about every time isn't an easy task. If it was easy and if these work archetypes didn't exist, then everyone wouldn't be positive that today's Dilbert (for pretty much any value of Dilbert) just had to have been sent in by one of their co-workers.

But I'm no manager, so I keep on doing what I can to make things better, forty hours a week.