azanar

If the customers of the software written today cared about quality -- and they _should_ care about quality -- they'd demand a higher standard of quality for the money they are paying.

They don't, though. Firstly, the users aren't the customers. The customers are the advertisers or corporate buyers. Secondly, the users don't _want_ to be customers. They'd rather whatever they can get for free that anything that costs money, even if the thing that costs money could be orders of magnitude better.

The first thought I have: I think quality is inclusive of size, speed, and reliability. Quality is _also_ features and functionality. It is also user experience. Probably many other things too, but this is just off the top of my head.

I'm also not sure users would come rushing to the side of programmers if _they_ became the customers.

I am the customer of companies that make many other things in my life. The quality probably isn't what it could be if that consideration was put much more front and center. For many things, I am _fine_ with that.

For the same reasons, I don't think the users of software would be obviously wrong. Certainly I don't think they're obviously wrong enough for me to become preachy. If writing software that isn't to the level of quality I demand or need causes me existential dread, I am now willing to say that might be a "me" problem.

I define a resource, and provide a whole set of knobs on that resource. That's the code part. I test that code against a variety of configurations, the same way I might unit test application code against a variety of app configurations. I also verify that changing knobs from one setting to another behaves. With automated testing, this actually isn't all that hard to do. Once I've verified things work right, I deploy.

At this point, I will default to trusting that things will work. This is the configuration part. Set these knobs to whatever permitted value you want, and the system will update behavior based on those new values. Most of the time, things like this work. That is good enough for me.

In software, there are at least three models I can think of immediately: code, configuration and user data.

Why do I separate configuration? Isn't configuration just code or data? I don't think it is. It is data _about_ a particular system, as opposed to a particular user.

Why the distinction here? The code of a system can be designed, developed, and tested against a set of supported configurations. At that point, the system might only run under one configuration at a time, but can be trusted from a requirements perspective to operate under other configurations without needing to go through the whole software development lifecycle again.

Why not just store this in user data, then? Different requirements. Three off the top of my head: configuration data wants much better change management than most user data does. That management wants to be exportable and importable. It wants different access controls.

Historically, configuration data change management has been done in SCM, such as git. The reason why git isn't a big deal in development is because it is not a point of particularly high friction relative to the other parts of the software development lifecycle. It is a _much_ bigger point of friction in configuration changes.

Hence, three models.

We can argue about whether or not configuration changes _ought_ to go through the full cycle, because I am wrong to trust _any_ change to a system with anything less. My practical experience suggests that most of the time, the damage done is less than the cost of enforcing a strict lifecycle on everything.

This felt wrong when I read it.

I agree we have many, many tools to objectively quantify aspects of our work.

Where I disagree: these tools only measure _some_ aspects. There are many aspects where we don't have good tools for measurement. Some of those aspects are for all practical purposes immeasurable.

For example: measure maintainability.

I think what happens then is the same thing that happens in politics. We take proxy metrics that _are_ measurable, and try to extrapolate over everything. The debates and egos come from arguing which proxy metrics should be weighted which way.

Then I realized I'd propose an alternative hypothesis: programming as a craft is immature.

I could never imagine civil engineers arguing over proxy metrics to the effects of natural forces on a bridge.

Can programming _become_ mature? I don't know. I'm skeptical of any claims that it can be. They all seem rooted in a gut sense of a particular weighting of what we can measure.

If we can't agree on this, we'll probably not agree on anything else. It'll mean you've decided on a premise that I think is false.

_Should_ they be miserable? Perhaps. Maybe they have a false consciousness. Maybe they need to understand better the societal effects they are responsible for. These are debatable. To _presume_ this is true, though, seems to me kind of arrogant.

> Creating an excessively competitive environment by working longer hours because of an ability and desire to do so is bad civic hygiene.

I can say I understand the sentiment. I personally very much dislike the bind someone puts me in if they do my job for cheaper. I dislike it _more_ when I see them suffering because of the choice they made. I think of the implications, and see a path toward everyone suffering. I want to hold that other individual responsible for increasing suffering in the world.

I take a beat. They've made a poor decision. Or maybe they haven't. Maybe they are suffering in ways I see, but not suffering in ways I don't see. Maybe they seem to be suffering more than they are. Can I do something else about my suffering _other_ than hold them responsible?

Example: are they _really_ normalizing mandated weekend work by voluntarily working weekends.

No? Then I think we can start talking about civic hygiene. I think civic hygiene is too complicated of a subject to shoot from the gut about. It is too complicated to reason about from a foundation of resentment.

One of the nice things about engineering disciplines is that costs can be reasonably forecast. There are spectacular counterexamples (e.g. Big Dig), but bear in mind those projects were much more than "just" engineering projects.

Software costs seem hard to forecast. Software integrates with other software. Software is created via a whole pantheon of algorithms. The "better" algorithm is often context dependent. That context depends on what else gets integrated. Did I mention we probably won't know at the design phase how things will be integrated?

Other engineering disciplines integrate with things that are well-known: the ground, water flows, the atmosphere. These things don't change. This is nice.

This article makes it sound like "better" is just a matter of spending more. My read is different: spend more and be correct. Correctness _isn't_ just something we know but aren't allowed to implement. In many cases, we don't _know_ what correct is. We have to _find_ correct via exploration and experimentation. Even when we do, we might severely misjudge the effort required to get there.

This complexity isn't just accidental. The world is a complex place. Our human minds act on a small portion of that complexity, based on all sorts of heuristics we aren't even conscious of. They work most of the time. The rest of the time? We're compelled to shoehorn things into our heuristics. This ends increasingly poorly the more complex the underlying mechanism is.

This is a hard argument to make to someone who will not accept that they are not correct. Correct in their criticism. Correct in their diagnosis. Correct in the the behaviors that lead to our condition. Correct in asserting that avoiding those behaviors would result in no unanticipated consequences. Resentful about it because they were correct, and we didn't accept that.

Are we as individuals hopelessly trapped in a social fabric that leads to the kinds of bad outcomes based on abuse of data that the author describes?

Assuming we can escape, is our only way out of this fabric to shred it from within? What of the benefits that we shred in our zeal? Is it mistaken to even claim their are benefits to be weighed against the drawbacks, because the drawbacks are so bad?

Perhaps it is a naive question. Is there a way we can reduce the bad outcomes by making those that cause them irrelevant, rather than counter-engaging them directly?

It boggles my mind how much people will tend to treat negotiations, amongst so many other things, as zero-sum games. If that were true, anyone who claims this should please explain to all the people who entered into negotiated agreements and found mutual benefit how they are actually being screwed by the counterparty.

For those who believe negotiation is zero-sum, I will say to you: if you notice agreements around you tend to turn sour because a party in it feels like they got screwed, take note of the common element.

This includes salary and employment negotiation. Unless you are in a one company town, or otherwise have skills and talents that are transferable to nowhere than your present employer, you most likely have alternatives to explore. Even if this is the case, there are alternatives, although they will not be anywhere near as easy to achieve.

Even then, it is not every employer that will decide the best way to profits is to screw their employees, and hope they feel hopeless. This is but one way to affect the bottom-line, and often not a very effective one. People will be more productive when they don't feel like they are being shafted. Not just in salary, but in: career development; personal sanity; and, if they care and have an interest in such a thing, in the net outcome of the organization.

So, I absolutely agree with you. Do not stand for people who feel like they need to "win" because you'll invariably screw them back. They may ultimately add up to a great big loss for everyone involved.

I think you far oversell the degree to which people who are being recruited do not have at least one, and possibly far more than one, best alternatives to a negotiated agreement with the recruiting party. Anyone who was to say to anyone around me "you have no alternatives, this is it" will immediately trigger an inventory taking in my own mind of all the possible alternatives that person may have.

Ultimately, I agree about the well-oiled machines, though. It is unfortunate that some organizations end up being run like this. It is bad for them too, especially in a world where an operational mindset can be overturned seemingly overnight by a new, better, cheaper way of doing the same thing.

For people who want to stay where they are, but see this happening, my response to them would be to make this acutely obvious to those around them: both the state of things, and the consequences. Not all companies are in a harvest and exit mode. Some still want to grow, and their growth will be considerably less in jeopardy if they play an offensive game against the market. But, in order to that, they have to stop playing a defensive one against their own employees.

If they realize this, they'll quickly realize soon after that their best alternative is not to turn recruiting into a battle.

Another BATNA I would propose to the people around me is this: invent that better thing. Your new job can be to put the company that treated you like a cog out to pasture.

What I will say this: I don't believe fear of the big, bad recruiting machine is a best alternative to anything. I feel it is consideration of one alternative, realizing it might not work out well, and getting angry. There are other alternatives out there; there is no reason to act so powerless in front of this one.

Until I reminded myself to assume good faith about the author (which is usually worth it with this author), I felt myself assuming he was disparaging all things new as being shiny and therefore unprofessional.

I don't believe that is the point of this article, and I worry the caricature is a little so over the top that people will interpret it as such a little too easily.

I think the point is this: don't confuse movement with progress. New is not necessarily better. The world of software tools is like any other marketplace of ideas: you will have a curve of early adopters onto the stragglers. It is not worth assuming that a tool is worth upending the world over just because the early adopters are jumping up and down about how it will. Most things won't. But some things will.

The point isn't novelty. It is value. Novelty has value, particularly social and sentimental value, but often it is fleeting. Other forms of value aren't. It is worth considering the new thing in all perspectives of value.

We are creating a universal loyalty currency, akin to AmEx points, that users can spend on virtual and physical goods. We are growing rapidly, and have around 3 million active users each day across around 500 mobile applications.

We have been actively targeting the Android mobile market, and just recently released our SDK for iOS. We are in need of the most help from a couple of talented engineers to help maintain and extend these SDKs.

If you are more interested in either front or backend web development, or more of a generalist, we are definitely interested in talking to you as well.

You'd be joining a small but very talented and tight-knit team of developers working at all levels of the stack, from postgres up through rails and into the platforms I mentioned above. From my own personal experience so far, the environment here is amazingly hacker-friendly. You will be able to ship code early and often with zero red tape, be given a very large amount of autonomy, and feel your impact on the company every day.

Feel free to visit our jobs page to learn more: https://pocketchange.com/jobs

If this sounds like something you might be interested in, contact me at [email protected] and I'll be happy to answer any of your questions.

I think there is a common point of view that wants to assume that recruiting a good fit is something that you determine based on a set of input, and then commit to. If you have to reassess at a later time, and especially if you have to reverse your decision, you've failed at recruiting, and in a way that is preventable in a deterministic way. Experience suggests that people who believe this do one of two things: either they attach an ethical weight to the employee/employer relationship that means you have to weight the cost to your business against the cost to your sense of self-worth; or, they have gotten lucky enough up to this point to meet/interview/hire people who have not misrepresented themselves or otherwise projected an image that they would be much more valuable than they proved to be.

Having been involved in a number of instances in the last two years that have exposed me to the randomness of recruitment and hiring, even using all of the hacks people use to remove the error, I'm honestly a little surprised that people can have any imperatives about recruitment. The whole things seems at best stochastic, and errors are unpreventable.

I think the reason why people are so reluctant to man up is because it means they failed at something we believe they shouldn't fail at. I would argue they've failed as something we all fail at, and that accepting that will make the whole process better for everyone.

In my experience, when someone is hired on to a new company, they are on a trial basis for a certain number of days anyway. This may seem less risky than being explicitly labelled as a temporary-to-hire worker, but they could still find themselves and their benefits in jeopardy if within that trial period either decides this is not as good a fit as the recruitment process suggested it would be.

I think that underneath the intuitive reaction we have to "temporary worker" vs. "permanent worker on a trial basis", they're actually very alike from an individual risk perspective. Either way, in 30/60/90 days, you could find yourself unemployed and still in the same bind. There may be benefits consequences the direction of a temporary worker, especially if you are temped through an agency. On the other hand, that agency might find you another role if the one you are in doesn't work out.

There may be a different discussion about whether or not having this trial period is right, or ethical, or good business, or whatever, regardless of what whatever label gets put on it. My stance on this is that a good process will inevitably make very bad decisions from time to time, and it's not always the best idea to force those bad decisions to be irreversible.

Maybe my experience with the occasional mistakes of what I've seen as otherwise good processes in my past has made me a little less hard-lined about this.

EDIT: get my quoting italicized correctly.

I think it depends on whether the person set to net a thousand bucks would agree with you on whether censoring a mascot makes the world a worse place, or whether they think censoring the mascot brings the world, such as it is, into relief.

It may not be that most people would care about the daemon turned devil. But that can be all the more incentive to just do what the vocal minority wants. No one else really cares, and that is as much about making the world a bad place as the person who actively insists on censorship. So why should you make an effort against a disinterested population?

I agree with you, but I think it is important to realize that there are varying degrees of both willfulness and jadedness that can make an argument like "you're selling the world out" fall flat. As much as I find a lack of resistance from people toward the censorship calls of others, apathy and jadedness are far more often the cause than agreeing that something ought to be censored.

Maybe finding a way to convince these apathetic ones that the world isn't beyond redemption would go a long way to convincing people that these things are worth fighting against, but I am still trying to find a reliable and repeatable way to do that. I will always be the seemingly naive optimist I suppose.

Wetpaint

We’re working on a platform of new services and tools aimed at a revolutionary new way of doing publishing. Systems that can spot breaking news, predict the amount of traffic a piece of content will drive and figure out where, when and how to best distribute this content.

We are looking for a software developer and a test engineer. Details here: http://www.wetpaint.com/page/jobs

Feel free to contact me about either of these, or anything else on that page: [email protected]

I realize that the plural of anecdote is not data, and that you aren't arguing the contrapositive. But I have a couple of data-points from the last few years that make me believe both directions are not necessarily tautological.

In the direction of placed privately -> best candidate: a company I worked for some time ago had a developer who was placed privately. Specifically, the developer already knew another one of the developers at the company, and came with a glowing recommendation. This person was hired somewhat before the time I was brought on, and as a result, they were well-entrenched by the time I arrived. This would not have been a problem, if this person weren't one of the worst developers I have ever worked with. I wish I could provide more evidence, but it would probably result in both a breech of NDA, and also enough detail that someone on here might know who I was talking about. I've known other people who have had similar experiences of incompetence brought in by some insider repaying a favor of work done earlier. Suffice it to say that there is plenty of offal out there that find themselves insided into companies assuming roles they ought never have been employed doing.

In the direction of best candidate -> placed privately: there is always the story of paul on here joining Google. I'm sure plenty of other stories have been recounted of talented people throwing resumes over the transom, and managing to get someone's attention on the other side. For my own anecdote, one of the best sysadmins I've known in my life managed to find his way into the company I was working at on the basis of a cold resume submission. Nobody knew him, and he was just another name in a pile of resumes; but, it was a pile of resumes that a couple people with a reasonable degree of cluefulness were given to read through, and this sysadmin stood out even on paper. Had we punted him in favor of someone privately placed, I'm suspicious that we'd have been in a much better place.

I realize that you are plenty talented, and am not casting aspersions your way. But there are plenty of hires that are the product of favors of favors, where the biggest favor the middle-party could've done is to never have introduced the company to the candidate in the first place. That's the trouble with favors, though; it is difficult to not be willing to make the connection, because it can bear a heavy social cost to have to say no to a friend.

I'll admit I might be a bit more sensitive to this now because I'm at a small company. A bad hire who was brought in on a favor could send the place into financial pain with maybe a day or two's worth of misguided exuberance. I don't know of someone internally earning social capital for themselves with that as a potential expense is a worthwhile trade-off. I'd rather keep the roadblocks up regardless of how the candidate is sourced.

TLDR summary: Sure, listen to and harvest from your connections, but realize that they have their own interests which may not necessarily align with yours or your corporations, and vet the people you find from them accordingly. The candidate you find or are pressured to hire through the grapevine or a favor may not be nearly as talented as patio11.

I wonder which part of the market it is that champions valuing developers this way; is it the companies that value that additional experience less, or is it the developers who diminish the additional value more experience adds? They both ultimately agree, as but I wonder which side is making the harder compromise here to get to that agreement.

I can't help but see this graph, though, and get the impression that after a certain number of years, people just stop caring so much. It might be that they grow apathetic. It might also be that the asymptote is the level at which salary stops mattering, and people focus on other things. I'd kind of believe that; you can been pretty comfortable most places at $100-120k/yr, and might start worrying more about things that go beyond mere comfort.