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.
To make this concrete: terraform for me has been part code, part configuration.
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.
I don't see the current model as a single model, but as several models interrelating.
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.
> A field which has so many tools to objectively quantify their work and the result so often are debates displaying poorly concealed biases and egos.
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.
There was a possibility I proposed, which I think you missed. Maybe they _aren't_ miserable. They might be suffering in some ways. They might even complain about it. That doesn't mean they are miserable. They may find other joy that makes up for the suffering.
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. I'll just keep seeming ignorant to you.
_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.
It seems many commenters in several threads are making the same point. I'll summarize it here:
> 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.
We could perhaps get better software, but at what cost?
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.
I'm going to ask a question that I fear will have me labelled as naively privileged almost beyond any hope of my eventually redemption.
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.
This may depend upon where you are, and perhaps a number of other factors, but since we are mostly speaking in gross generalizations here, I will too.
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.
I really hope people do not misunderstand this article.
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.
A candidate who is at an elevated risk of being replaced by severance, which is a position most new hires are in, is probably putting their aspirations on hold while you figure out if they are the right fit. Severance is typically enough to keep an employee above water for a time while they find a new position that fits them better, but it certainly isn't anything people can build dreams on top of.
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.
Actually, I think "hire them on a temporary basis" is more egomaniacal than obsessing over job interview questions. For someone to work for you as a temp, they have to leave their current full time job and put their benefits in jeopardy. When you hire someone, you should be ready to commit.
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.
Is it worth making the world a worse place just to get a measly thousand bucks?
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.
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.
The best jobs and the best candidates for jobs will both be placed privately.
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.
In economics the reverse hockey stick growth is known as diminishing marginal returns. This simply means the market values the earliest years of experience as much more beneficial to a developers skill than the later.
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.
If you take a risk and co-found your own startup with 0 years of experience, then even if you tank 2 years later, you are likely to wind up close to the 5 years of experience point of the hockey stick when applying for a job.
That's probably closer to the conventional wisdom around HN, but it is a far cry from conventional wisdom amongst the masses. The wisdom amongst the masses is that if you co-found or join a startup, you are playing roulette with your financial security.
But the article's point -- which I agree with -- is that even if you accelerate this process of getting to that 5 year threshold, you are doing yourself a disservice fiscally by settling in at the plateau unless you have a good reason forcing you into settling.
You're likely still learning more, and becoming more valuable, but it becomes much more difficult to extract that value through salary. So, it becomes beneficial to join companies where that only makes up a part of the total compensation package.
There is an interesting subtext in this article, which is to suggest that you take more risks as you get closer to the asymptote of salary growth, because it's the way to avoid diminishing returns for the additional skills you've learned between hitting the level of "experienced" and now.
It's the opposite advice that makes up common wisdom, which is to take risks when you are young, inexperienced and without responsibilities, and then settle into the comfortable long-term job with small raises once you get past that phase. I'm not surprised by this; if technical skills compound at all, it would seem that a developer's value would trend exponential and not logarithmic. That is, so long as they don't weary and stagnate.
But then, there is also value for the inexperienced in a startup, in that you'll learn a ton, and be given a lot of responsibility and autonomy. It might be that common wisdom is only half-broken.
Granted, there are opportunity costs involved. You might be in a position where you have to trade capitalistic striving for a paycheck, as a ribbonfarm article posted here a while back put it. It's as much being aware of those opportunity costs, though, as it is knowing whether or not you are in a position to need to accept them.
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.