m104

Awesome! It's nice to read accounts like this from those who have braved the task and successfully completed a ground-up rewrite.

Looking ahead, I can see the formation of dedicated development teams who specialize in rewriting working-but-just-barely apps completely from scratch. As those teams get better at doing this kind of work (and their clients prosper!), more companies will start to seriously consider the re-write option. Who knows, a whole industry could form just for app rewrites.

The sure-fire one-liner Bash way to iterate over files with arbitrary filenames, with any number of files (0 to millions) is this:

    $ find $CRITERIA -print0 | xargs -0 -r -n $BATCH_SIZE $COMMAND

What this does is use 'find' to find the file and directory names (with your supplied CRITERIA), send them over to xargs with no funny filename parsing, run those filenames as arguments to COMMAND, batched up to BATCH_SIZE at a time (I usually use 100-500), and ignoring empty batches.

Usually COMMAND would have '--' at the end to prevent filenames from being parsed as arguments, but not all commands need that treatment. If COMMAND doesn't take the filename list as the last argument(s), it can be fixed with the '-i' option to xargs.

The BATCH_SIZE part here is important in many cases. Since large numbers of filenames will break the command line arguments size limit to COMMAND, a reasonable BATCH_SIZE will prevent thousands or millions of filenames from breaking your script. Also, sometimes you may want to run the files through COMMAND one at a time (BATCH_SIZE of 1).

Finally, the '-r' option, which I don't see mentioned often enough, tells xargs not to be derpy and run COMMAND with an empty argument list. Seriously, '-r' is short for '--no-run-if-empty'.

For anything else, a nice scripting language is the only way to fly.

Just a note for those who suffer from RSI-related symptoms of some sort or another (because this article doesn't say a word about it): pay attention to your sleeping positions!

I started suffering from pins-and-needles in my fingers a few years ago. As a programmer, I was totally terrified that my typing was ruining my wrists and, despite my best workplace ergonomical efforts, it wasn't getting any better.

After a few months of sporadic symptoms, I noticed that the bad days were really bad in the mornings and got progressively better over the course of a workday. Huh, why would that be? I started paying more attention to how I slept (pillow positions, spine positions, restlessness, temperature, etc.) and noticed that I was curling my wrists pretty badly when I got cold at night or when life was more stressful. I'd literally wake up with both my fists curled into a ball.

So, really, I was spending many nights with my wrists curled for hours at a time. That can't be good! To fix this, I started spending a few minutes each night consciously laying my hands flat with my arms at my sides and getting comfortable with a better sleeping position. It took a few months to make this effort a habit, BTW.

Here I am a few years later and guess what? No more pins-and-needles feelings in my fingers. I haven't read any other literature covering this type of sleep-related injury, but I know it exists and I'm sure there are others who suffer needlessly.

I highly recommend looking for any dissonance between the ground-floor workers and management/leadership.

The best scenario you can find (a truly rare gem of an employer), whether startup or established company, is where everyone is on the same page. Vision should be clear, strengths should be accurately gauged, and problems should be acknowledged and well-understood. You should be able to share what you've learned from the workers with management (and vice versa) without any looks of shock, fear, or panic. Overall visible stress should be almost non-existant.

The worst scenario is where the company's leadership lives in its own reality and blames any issues on workers or outsiders. Run from these employers; no amount of money is worth working for such people. The easiest way to test for this case is to just talk openly about what you've learned about the company and how the future looks given their strengths and weaknesses. Watch out, in particular, for the hushed phrase "I shouldn't tell you this, but..."

Realistically, though, you'll find a lot of employers somewhere in between. Just know that the distance between the reality of leadership and worker is going to be proportional to the pain you'll feel working at that employer and that such distance tends to increase over time.

I totally agree. There's major street cred to be gained from speaking truth to power. But, as the article points out, there are consequences also.

I think the blog article is trying to tell newer/naive employees that, when asked by a soon-to-be former employer to provide an honest exit interview, the whole premise is a charade. How we handle that charade is still up to us, though.

The crux of this is a simple question: if the company is really interested in honest, constructive, confidential, consequence-free criticism, why only ask the ex-employees?

Companies that really do value honest, constructive, confidential, consequence-free criticism (the best kind in some cases) will value that feedback most from their current employees. But, in doing so, eliminate the need for the soon ex-employees to feel the need to dump reality on management.

This is so much better advice than "fight the system", "convince your boss", "use these talking points", etc.

If the poster really wants to keep that particular job, but wants to also improve the environment, they need to start following all of the rules they don't agree with to the letter. The worst thing that can happen is that it actually improves the team somehow.

It's not always the right way to make change, but in these situations it really can be the best route. Bad rules and procedures can only be (officially) recognized as such when they're actually being used. There's no need to make a mockery of this stuff, either, because time will tell whether the new rule is really helping or hurting.

Like you say, humble, honest, and calm.

Right, I doubt that it scales linearly like that either. My comparison was just as absurd as the article's comparison in the other direction. Really, we don't have a clue how much Apple is making or losing by replacing these batteries. My guess is that Apple's battery replacement charge is based largely on the price point of the original product.

"Admittedly, the battery in the MacBook Pro is more powerful than the Air's: Apple rated the former at 95 watt-hours (Whr), meaning that it can produce one watt of power for 95 hours, or, say, 5 watts of power for 19 hours. The 13-in. MacBook Air's battery, on the other hand, is rated at 50 Whr."

Not that a 90% increase in battery capacity should have any impact on the replacement cost or anything...

To put it in perspective, though, most of Apple's customers only started buying their hardware in the last two years and rarely purchased older models.

Ah, I can see why our opinions differ so much: you believe that human error can be mitigated or eliminated with the right systems, training, documentation, procedures, etc. In other words, you can build a system that, while being run and maintained and managed and extended by humans, will prevent human weakness from crippling the system. Within that view, blaming humans for human problems is counter productive, since you've got a better way to prevent failure.

I don't share that view, but I think I can tell you why it's working for you (now) and what sorts of issues you'll run into eventually and why:

You've got great people working for you. I don't need to tell you this, of course, but it's true. That's why you're having success. Great people are already preventing most screw-ups and blaming themselves for their own screw-ups, so there's no need to apply much in the way of corrective management. Adding tools and documentation and procedures to help everyone learn from this process is great, but your people would do fine without all of that. They're going to do their job well, in any case. That's what great people do.

But, not all of your people are great. You've got at least a few in there who have started to (or always have) felt that their issues and problems and screw-ups aren't actually their fault. They can hide now, fairly unseen amongst their coworkers. But they are there, regardless, causing small issues here and there which are mostly taken care of by their more responsible peers. More documentation, training, and system verification won't help them, unfortunately. These people either need to face the music or be terminated before they cause real damage. Identify them, if you can, before things get worse.

The worst employers I've worked for have all had a "blameless" culture. They didn't call it that, of course. What it meant was that if the cause of a problem or failure was difficult to face, the problem was blameless. I don't think any one of them started out that way, but weakness crept in and suddenly the company just couldn't pin blame where it needed to go, because (for what ever reason) that was uncomfortable.

And this is where the breakdown ultimately happens, and why: Management decides that it's soooo uncomfortable or legally risky to hold an employee's (or another manager's) feet to the fire that they come up with all sorts of rules and procedures and training and even philosophies to avoid having to, you know, actually manage the team. And the employees that don't like feeling personally responsible love it because they've got an out for their mistakes. "I didn't know!" "I didn't realize!" "No one told me!" "What was I supposed to do?!?" And management can go back and order their more responsible employees to "fix the system" so that their irresponsible employees don't cause as much damage next time.

And anyone who questions this is being judgmental or biased or seeking a vendetta or in some way not being the caring and compassionate soul that the company's "blameless" policy demands. Greater employees leave eventually or are fired for causing trouble. Eventually, the continued wave of failure overwhelms the company itself.

(Of the three employers I've worked for with this sort of environment, two no longer exist and one is cresting this year. Anecdotal, of course, but this is how my opinions on teams has been forged.)

Ok, so back to your blog post. You're telling the world and your employees that this is exactly the type of environment that you want to create and maintain! Not one of failure, of course, but one in which no one person can be, ultimately, responsible for failure. It would be so cool if this actually works, but think about what you're actually saying.

The great people in your team(s) don't need this sort of support and the irresponsible people will lap it up and ask for more. If you're not prepared to deal with the second set, they will drive the first set out and use company policy as their justification.

Excellent, I'm glad that's been your experience. Mine hasn't been like that and I've waded through too many everyone's-so-friendly-and-getting-nothing-done-and-always-stressed teams with weak leadership and low standards. I'm hoping that your experience is more typical than mine!

My points are based on the commonalities of the three great teams I've worked for at ten different employers. It's not one company, just a set of observations.

And they weren't all IT/software/web companies, either. One was the best IT team that I've worked with, period, at a non-IT company no less. Another was a fairly well-known restaurant chain. The third was a small startup-ish design company.

You are absolutely right about the reputation thing. You get that reputation for firing people, especially from the fired. But when you talk with the people that do or did work there for any length of time and see that, when the time comes, leaving will be difficult or was difficult, it all makes sense. The team manager wanted a great team that had great output and nothing less. And there was never any pressure to do the wrong things, illegal things, or base decisions on personal whims. That kinda stuff doesn't happen very easily with a room full of responsible adults, knowing that today may be their last if they screw up.

So I'm not saying there's no drawbacks to the points I listed, but I think they do work out overwhelmingly on the positive side.

I think this kinda stuff always creates a two-tiered team, so it shouldn't be relied on as a way to hedge anything. You get the A-team/"our people" and the B-team/"their people" and right from the start everyone knows this. Then there's differences in pay, benefits, and expectations, etc. In other words, to use interns or contractors as a potential employee filtering method, to me, just sucks. I haven't seen that work well.

But, but, but! If you're looking to give people a chance to learn and expand, with no future obligations, internships are definitely the way to go. The key point being: an intern that doesn't turn into an employee is not a failure.

Take someone who doesn't even know what they can do and put them with a great team, part time, with real responsibilities, and with the idea that they're there to help out and learn and see if anything happens. Usually, it won't. If it does, great. If they become a future employee, excellent! My career was built from this, but it requires an employer that's willing to take a risk.

That's a really good point and I think that, for the employees who didn't last more than six months (or were terminated right away), this was a bitter experience. In other words: if you, as an employee or employer, are looking for more of a committed relationship, I think the points I made aren't going to help at all and probably seem distasteful.

If you're looking to maximize the team's value and effectiveness, though, I've seen those points work, consistently, in a variety of environments. And I have no hard feelings about it. "It's business", as they say.

It's not one organization, it's the commonality I've noticed from three of the ten that I've worked for that had fantastic teams. The other seven have had wildly different measures and procedures for employees, but each with worse results.

Right, I didn't make that clear:

A human mistake comes from the fact that we are fallible humans with crappy memories and fat fingers and a working set of beliefs about the world that may be entirely wrong. Type something in wrong? Why didn't you verify or have someone else verify? Forget something or leave something out? Where's the checklist that you made for yourself to prevent that from happening? Make a bad assumption? Why assume at all when you could have verified?

You get the reprimand to be reminded that, while pushing the envelope is a good thing, there are real consequences to screwing up and not having all of the loose ends tied up. Saying "I didn't know" or "I didn't realize" is like saying "it's not my fault". In reality, you can't prevent these things from happening, but you better damn well try. That's what you get paid to do, in other words, to prevent your humanity from screwing up your hard work and brilliance.

Oh, I should have mentioned, that you're expected to yell at yourself more than your boss does. It really helps prevent having your boss do it for you!

But, like I mentioned in point 3), these are covered by management. No need to have them get in your review or affect your future at the company. You're human, it's OK, just be sure and learn from it.

A dumb mistake is one where you know better. Like you just decide out of the blue that you'll take that call from an old client during business hours, while your boss's boss is taking clients through the building. Or you were told not to do something, explicitly, but you decide that you'll do it anyway. Repeated mistakes are ones where you make the same mistake and didn't learn your lesson.

Hope that helps!

If the goal were to minimize the number of false positives, I would agree. But the managers of these teams had enough experience to know that they'd rather hire one person a month for a year and only keep one gem than to spend days or weeks trying to find that one gem and then agonize over firing them (knowing that the hiring process is slow and expensive) when the gem loses its shine.

Having done a fair bit of hiring myself, I can't even begin to reliably identify gems. If you know of a way or can explain how multiple rounds of interviews can do a reliable job of identifying them, I'm all ears. I can tell the stinkers right away I think, but gems, no that's really hard. The best candidates I've interviewed (resumes, work experience, knowledge testing, etc.) haven't had any better luck becoming great team members than those with a mediocre interviewing quality.

Cause here's the thing about gems: They only work within their setting and can be created, with some effort and skill, right out of raw material.

The best teams I've ever worked for had this set of common traits:

1) On the offer day, potential employees were told there were high expectations and no fixed rules to govern what that meant. There was leniency in some cases, but manager/supervisor judgement was the only rule that mattered. No handbooks or rule sets.

2) All new team members were automatically assumed to be terminated within a month or so. This was usually true. Any new employee that didn't pull their weight, sat around waiting for someone to tell them what to do, or lied in any way was terminated.

3) Human mistakes (fat fingers, brain farts, etc.) were reprimanded internally but covered, responsibility-wise, by the manager or supervisor externally. (I got this treatment at least once a year...)

4) Repeated or dumb mistakes meant being terminated, usually within the same business day. (I saw this happen many times. Not fun but then again they were dumb or repeated mistakes.)

5) Lots of communication within the team. Supervisors and managers were always available or actively participating in the projects.

In other words, there were high expectations and they were strictly enforced, with nowhere to hide mistakes or divert responsibility. Or, more bluntly, "we want to work with adults, not children".

Sounds harsh perhaps, but these were the best teams I've ever worked for and no one who stayed for more than 6 months felt used, abused, or anything other than lucky to be working with fine people. When long-time employees left, it was to start their own businesses or go back to school and there were always a few tears in the parting days.

Now, if you read in some book or learned in a training course that you need to cover your butt legally at all times, give everyone plenty of chances to do the right thing, and take everybody's situation into consideration before taking disciplinary action, your teams are going to start sucking. Why? Because all of those things are the opposite of management. Those things are what you do to avoid management.

This whole article, to me, says "boy, it'd be so much easier to run this business if I didn't have to actually run this business". Here's a hint: If your strategy for managing a team or community or whatever is "people should do the right thing and we should give them every opportunity to do that", then your team's problems aren't actually your team's problems.

I doubt remembering everything makes life a lot better, but there actually is someone we can ask: http://www.wired.com/medtech/health/magazine/17-04/ff_perfec...

No interesting implications, just the reaffirmation that real significance is more important than statistical significance.

Talk about being too smart to solve the problem... The article is comparing apples to concrete blocks. When you're hungry, you want apples. When you're building a retaining wall, you want concrete blocks. One can't substitute for the other.

Statisticians, academics, math enthusiasts, and People Who Spend Too Much Time Building Tables and Graphs want concrete blocks. They want to build a case or a report or something that suggests a point using a mathematical model. They deal with "statistical significance" because that's how the tools they understand work. Thus A/B testing.

Web workers, businesses, advertisers, people looking for better conversion rates, etc. want to eat. They want apples. Talking about statistical significance, trial sizes, and frequency measures don't help if they don't get more apples. The article showed that MAB gets more apples than A/B and by a wide margin.

Comparing the two isn't just missing the point, it's drawing an equivalency between "statistical significance" (whatever the tools say it means) and actual real world significance, a.k.a. better results. If A/B testing fails to even simulate better results, the proper word for that is worse.

(And don't even get me started about trying to run a statistical experiment until significant results are found... someday that practice will be labeled as fraud.)

From the article:

"Why is hiring so tough? Because talented people don’t need you anymore. They don’t need the benefits because they know if worse comes to worse, they will find a comfy job. The options are there for them, therefore the risk of starting their own company isn’t an all or nothing deal."

While this has been true for years, I think, more than ever, talented and driven people are realizing that a comfy career isn't an aspiration but a fallback.

Not a serious comment, but that image of Sergey reminds me a lot of the Bill Gates "borg" icon that Slashdot liked to use. How ironic is that?

NTP is great and all, but...

When you're timing something that needs accuracy, you use a timer not a clock. If you need to use a clock, you use one clock not all the clocks. Yes, I work in the medical industry. Yes, we generally use timers not clocks. Yes, our clocks are all wrong too.

If you really do need a solution to the "time" problem (accurate time all the time), you need to issue everyone a smartphone.

Ha, some bots are being written as we speak! Or, someone out there has some killer hand-eye coordination.

If the deadlines are ridiculous and your employer is constantly blowing through them, then your employer's management doesn't take deadlines seriously. What I mean is, the deadlines aren't being realistically created and measured and there's little or no consequence for missing the deadlines.

Usually this indicates that management has stepped into fantasy land and doesn't want to acknowledge something about their business (processes, limitations, staff, industry, etc.) and would like to use deadlines as a way to maintain hope at the top for the future. It's not like this at all employers, but it is staggeringly common. I find that "top heavy" companies tend to suffer more fantasy-thinking management problems, but I'm not an expert.

If you're planning on staying at your employer, you can try to help the process by more strictly defining the deadline scopes or by breaking up the deliverable scopes into more manageable chunks. If your employer has any hope of improving, your more-realistic-but-not-as-optimistic deadlines will be met with opposition at first and then acceptance when you start actually meeting them.

Ah, look at that, I totally misread where you were going! ;-) In my experience, regulations and crazy laws aren't really a competitive advantage or disadvantage because all of the market players are playing by similar rules. I'm not saying that there's no negative effect to bad regs and laws, but the costs are shared fairly equally.

I've never worked at a business that was cut off at the knees by new laws or regs. I'm sure it's happened, but I'm not convinced it's common. What I have witnessed though, many times at many employers, is pure self-inflicted complexity. The did-they-even-consider-the-cost kind of complexity that is nightmarish to implement and hampers future changes.

As an IT pro I can't do much about the laws and regulations, but I can advise and design business systems in ways to avoid complexity traps and help accommodate more sane business processes.

There are many ways to bring some order back into the world, as you say, but it can be a struggle. In my experience, business leaders will support simpler systems and processes if (and only if!) the benefits clearly outweigh the costs.

As an IT professional, framing the right perspective is essential to getting acceptance for better systems. Presenting a more powerful, but simpler, system as "losing some rarely used and inefficient features" is a sure way to get that project rejected. Management will only hear the "losing" part as a loss in total value and therefore worse than the current solution.

Personally, I like to present formalized system upgrades as the price of growth and future growth potential. Most business leaders can wrap their heads around the concept of "we need to focus and streamline in order to reach the next level", regardless of technical experience.

Lovely, now the cycle is complete and we're reading about (and commenting about!) stories that refer to Hacker News comments.