1. 5

    I think starting with a coding test is actually a good thing. In The Hiring Post, Thomas Ptacek wrote:

    Years from now, we’ll look back at the 2015 developer interview as an anachronism, akin to hiring an orchestra cellist with a personality test and a quiz about music theory rather than a blind audition.

    Well, the coding test is our blind audition. Just as a blind audition levels the playing field for orchestra musicians, starting with a coding test levels the playing field for us. Sure, for a candidate who looks and sounds the right way and has sufficient charisma, it may be harder to reject them if they get to have a conversation with an interviewer first. But for everyone else, a coding test is probably a better start.

    1. 1

      I don’t see orchestra musicians and programming as being close enough for the comparison to work. An orchestra musician basically just has to show and up and play their instrument however the conductor wants them to. For a company looking to add a programmer to their team, raw programming skill is secondary to how well they fit in with the rest of the team from a social and teamwork stand point. Skill can always be improved but a toxic or apathetic personality can weaken or destroy a team.

      1. 6

        I don’t see orchestra musicians and programming as being close enough for the comparison to work. An orchestra musician basically just has to show and up and play their instrument however the conductor wants them to.

        That’s not true. An orchestra musician has to do all of the other things that you’re describing. They have to get along with their section. They have to be able to interpret the conductors directions. But, first and foremost, they do have to be able to play their instrument with a level of virtuosity commensurate with the pieces they will be required to play. Orchestral music, just like software development, is a team sport, and a musician who isn’t willing to commit themselves to that teamwork will be similarly unsuccessful.

        Skill can always be improved but a toxic or apathetic personality can weaken or destroy a team.

        Why would that be any different on an orchestra than it would be on a software development team?

    1. 8

      If we can collectively reject awful hiring practices, we all win. Employers already have most of the power in this relationship, so we need to band together and consider how each of our individual actions affect the community as a whole.

      I think maybe this has been done before, to great effect (eg, the forty-hour work week, etc.).

      1. [Comment removed by author]

        1. 4

          You must be lucky to live in a place where it’s cheap to keep your belly full and a roof over your head, and where programmers command such high pay, and has tons of places to work, in lots of different professions! If that weren’t so, you wouldn’t be so glib about leaving and going somewhere better. In fact, if such a place didn’t actually exist, you’d look like a heartless and uninformed child, which can’t be true, or else you youldn’t be here. So I’m probably missing something that unifies and resolves this apparent contradiction. Maybe you just forgot about how hard it is to pay rent in Silicon Valley without an SV salary, or what it’s like to have a partner with different skills and needs, or have children or family or community that would be devastating to leave behind.

          You claim that the members of the labor pool for programmers is already more powerful, individually, than the members of the capital pool, and therefore, it is not worthwhile to unionize. Maybe you’re right, which is maybe why the capital members have taken it upon themselves to organize collectively against labor. But why would you want to wait until you were desperate before you organized to realize your strength? Why wouldn’t you want to strengthen your position even more, especially when vastly more powerful forces will inevitably organize against you?

          You’ve also characterized the alternative to “leaving and going somewhere better” in a very strange and passive way: “sit around and hope a union will come along and fix things for you”. I’d ask for clarity on how you think unions actually work, and what kind of dynamic they would introduce to the labor market, but I suspect there wouldn’t be much coherence. Instead, I’ll just point out that “sitting around and waiting” to be saved by a union is an odd thing to do after pointing out that there are no relevant unions.

          Anyway, enjoy your coding challenges and unpaid overtime and no vacation accrual and equity that you can’t afford to exercise!

          1. 2

            I deleted my comment because after I posted it, I realized that since you hadn’t specifically mentioned unions and figured it was out of line for me to go assuming you meant unions. But since it’s very clear now you were, for the benefit of other readers, the main point I made was that I literally can’t imagine a profession least in need of unions than software developers.

            You must be lucky to live in a place where it’s cheap to keep your belly full and a roof over your head, and where programmers command such high pay, and has tons of places to work, in lots of different professions! If that weren’t so, you wouldn’t be so glib about leaving and going somewhere better.

            I do live in such a place, I live in the US where even the poorest of the poor have better living conditions than half the world. I should have qualified my statements by saying that they apply mainly to western countries. I understand that in other parts of the world opportunity is not as easy to come by no matter what your skill set. If that’s the case for you, then it’s possible my comments don’t apply to you and unions might be necessary where you are.

            Maybe you just forgot about how hard it is to pay rent in Silicon Valley without an SV salary, or what it’s like to have a partner with different skills and needs, or have children or family or community that would be devastating to leave behind.

            There’s always the option to leave Silicon Valley. There are a lot of famous companies with headquarters there but the Valley does not in any way have a monopoly on tech jobs.

            Yes, I do have a partner with different skills to myself and we have children. I have already made one major move to get out of a shitty job and into a better one. And I would happily do it again if I had to.

            1. 4

              But since it’s very clear now you were, for the benefit of other readers, the main point I made was that I literally can’t imagine a profession least in need of unions than software developers.

              Really? I don’t think doctors need a union either, but they have the AMA. Lawyers have the ABA. Other engineering professions have their professional societies. No, these aren’t formal unions, and they don’t have collective bargaining rights, but they do fulfill many of the same functions that unions fulfill for “blue-collar” workers.

              In fact, the more I look around at other professions, the stranger I think it is that programmers don’t have a union or professional organization.

              1. 4

                I do find the argument that you can just uproot your whole life and move somewhere else with better work conditions to be extremely weak. People shouldn’t be put in a position to consider this a valid option in the first place. People have relatives, friends, children who need a stable environment, even just things they are used to and feel comfortable with.

                Consider how you might have come about that way of thinking, and who it really benefits to have people willing to do this, from a broader perspective.

                1. 2

                  I do live in such a place, I live in the US where even the poorest of the poor have better living conditions than half the world.

                  Therefore, there is no place for unions in the US? P.S.: you have just admitted you don’t live in such a place.

                  There’s always the option to leave Silicon Valley. There are a lot of famous companies with headquarters there but the Valley does not in any way have a monopoly on tech jobs.

                  It, along with the other areas with a monopsonistic local labor market (Seattle, New York to a lessor extent), does have a near exclusive lock on the disproportionately large salaries you mention as an intrinsic benefit of being a member of that industry, and all those places are very expensive to live in. Some people might get lucky by living some place cheap while working remotely and getting paid with SV/Seattle/NY wages, but compared to the total number of jobs, that number is low.

                  Yes, I do have a partner with different skills to myself and we have children. I have already made one major move to get out of a shitty job and into a better one. And I would happily do it again if I had to.

                  How great for you! I’m sure it wasn’t a huge pain and you’d not put down any roots (kids making friends at school, etc.) and everyone was happier for having done so. That’s fantastic, and I’m not even being insincere, because even if it were true, it wouldn’t support the argument that it is, in general, easy and painless to do, and that reasonable people shouldn’t desire to not have to do that.

                  You have not presented any argument against unions other than, “I don’t think we need them because the costs currently imposed on us by capital are either low enough that I don’t mind, or I’m somehow not paying them because I’ve been lucky or something.” Why are you so against the idea?

                  1. 1

                    I essentially agree about not uprooting, but the point about kids and school is probably a bit off. We considered it an argument for not changing countries. We also considered the problems kids (which we didn’t have at the time) would have integrating if we moved back. But a friend - a teacher of young children - set the record straight: Kids make new friends.

                    The biggest nope here is girls around puberty. They can be the worst psychological bullies, even deciding in advance to hate the new girl the teacher talked about.

                    With kids and a career, you don’t necessarily see your friends very often, at least IME. Moving should be such an upgrade that you can travel to see your friends about as often as you would otherwise.

                    Just something to keep in mind when considering a big move. We didn’t move for other reasons, at least not yet.

                    1. 2
                      1. 1

                        I generally don’t do PDFs on the phone, but the middle link makes a good point about the age at which to move. I’m also quite sure that moving a lot can be detrimental. But moving like once at a less fragile age shouldn’t wreck the kid.

                        Same as what I’ve heard about divorces and relationships. There are ages when you should keep the facade going.

            2. 1

              Reading the title and this comment, you might conclude, “coding challenges are awful hiring practice” and get on with your day.

              Don’t do this, the article is about how coding challenges can be improved and what prospective employees should expect out of employers who use them.

            1. 11

              I fundamentally disagree with much of the history presented here. XHTML/XSLT was an abomination. It deserved to die. XSLT didn’t die because it allowed you to “remove ads”, it died because it fell into the turing tarpit. Have you ever tried to make any kind of non-trivial system using XSLT and XHTML? I have. I was using it to build an intranet site back when the PHBs all thought that those two technologies were the future. It was a nightmare. XSLT has very few mechanisms for encapsulation. Unit testing it is damn near impossible. When we finally switched to Javascript, as terrible as Javascript was, it was still a godsend compared to XSLT.

              Moreover, I think it’s completely wrong to put the blame for the web becoming a privacy-destroying apparatus on the backs of HTML5 and Javascript. HTML5 and Javascript have served to democratize computing. Now, you can make an application and have instant worldwide distribution, without having to deal with publishers, distributors, retailers or the messy business of copying discs and shipping them. If your application has an issue, you can patch it nigh-instantaneously. You don’t need multimillion dollar contracts to sell your application; all you need is a server and a URL. The alternative to a world in which the web exists is not some privacy preserving Utopia. It is a world in which Microsoft reigns supreme. Remember, before the web exploded in popularity, and Apache-on-Linux became the default OS of the web, Windows NT was making significant inroads into the server market. If the web hadn’t happened, we might very well have ended up with a situation where Microsoft ends up with unchallenged and unchallengable control of computing, client and server.

              While we correctly castigate privacy destroying organizations like Facebook and Google, we should also remember that without the world wide web, modern open-source wouldn’t exist. Without the web, Linux would still be an obscure toy operating system kernel created by a Finnish grad student. Without the web, Python would be an esolang created by a Dutch scientist, and Ruby would be Yukihiro Matsumo’s hobby project. It is the web that allowed communities to form around these projects and make them as successful as they are today.

              1. 0

                Have you ever tried to make any kind of non-trivial system using XSLT and XHTML?

                ROTFL! :-D

                Yes, I did. As I said, we had a pretty good infrastructure that chained several transforms from several sources, merging data from a PostgreSQL database and from REST services to generate/update pretty complex websites, in several versions (by language and style).
                Even some dynamic parts were generated that way.

                I have to confess my hope back then was to see XSLT in every browsers.

                The only piece of that stack that I do not really know well is XSL-FO.
                I did several experiments back then, with very nice results, crawling the web we generated and turning into nice (but simple) PDF. But I cannot recall much…

                XSLT has very few mechanisms for encapsulation.

                I think this is the only thing you remember correctly.

                And I happily admit that the whole stack was not perfect. And that it could have been improved.
                Even XSD was not able to represent all constraints I needed back then. And XForms were too limited.

                But it was the right direction to explore.

                HTML5 and Javascript have served to democratize computing. Now, you can make an application and have instant worldwide distribution, without having to deal with publishers, distributors, retailers or the messy business of copying discs and shipping them.

                I do not know who told you this bullshit. We had very nice applications in HTML4 served by our servers and using several technologies.

                Remember, before the web exploded in popularity, and Apache-on-Linux became the default OS of the web, Windows NT was making significant inroads into the server market.

                Lool!

                The web was already “exploded” before 2000. And then imploded. And then exploded again.
                Before HTML5.
                And Apache+Linux was leading the server market since…. gosh… I do not even remember the start…

                JavaScript did not saved Linux, Python, Ruby and so on… but thanks, this is really funny!

                The web existed before JavaScript and HTML5. And it will exist after.

                But right now, JavaScript turns the Web to a very dangerous weapon.

              1. 5

                Title is bit clickbaity, but the actual content is super interesting, too. :)

                1. 9

                  Yeah, the title is total clickbait. He didn’t compile the Typescript. He took the parser out of the compiler, ran it inside BigQuery, and was able to get a million ASTs in 40 seconds. While impressive, it’s nowhere near a full compile.

                1. 3

                  irreversibility, an essential design feature of cryptocurrency blockchains, is the fatal flaw of cryptocurrency that is responsible for most cryptocurrency and smart contract disasters

                  If people wanted repudiation, they would use PayPal.

                  Repudiation is one of the worst parts of the existing financial system, because it encourages horrendous failure-prone system design (since we can just roll it back no problem!). On a practical level, repudiation is fundamentally incompatible with the goals of a trustworthy, mechanized, objective finance system.

                  (Although arguably it makes sense for ethereum since they’ve already given up on all three of those things by manually reversing the DAO “hack” even though it was a perfectly valid contract. So much for “code is law”.)

                  On a philosophical level, Bitcoin is all about giving you more control at the expense of no one holding your hand. That’s the way it was designed, and that’s the way we want it. Repudiation fundamentally means loss of trust or loss of control. If anyone can reverse their own transactions, we lose trust. If there’s some centralized party that can choose to reverse transactions, we lose control.

                  1. 5

                    as long as human will build computer system, you will have to have way to recover against human errors. The only systems that don’t support this recovery system is human endangering systems which are gambled to be error free.

                    1. 6

                      Yes, I’m saying that’s unworkable for anyone who just wants to move value around in a money-like manner and isn’t ideologically committed to dealing with the brittleness of the resulting system.

                      1. 0

                        Is cash unworkable? It has basically the same non-repudiation properties as Bitcoin, and yet people seemed to do OK with it for a long time (and before that, same deal with specie, and before that with commodities, etc.).

                        The existence of repudiation is a consequence of the emergence of unreliable credit systems, not something people sought out.

                        1. 13

                          Actually no, repudiation in the sense of contracts existed long before unreliable credit systems. Courts would “rollback” a contractual transaction for various different reasons. Among them failure on one party to understand what the other party meant in the wording of a contract. This could be due to one or both parties interpreting the language of the contract differently. This is a feature and not a bug of contract law.

                          As the bugs in smart contracts indicate it’s frequently possible for both the author of the contract and the counterparties to not fully understand what the contract actually says. This is for most people a bug and not a feature. Only idealists and thiefs would look at it as a feature. The idealist is willing to sacrifice assets for the ideal of an unbiased contract enforcer. The other likes the idea that they can take money from people who didn’t think it was possible with no consequences.

                          Thiefs were exploiting the legal system long before this of course but since smart contracts are obviously capable of quite serious bugs. You’ve just traded one group of exploiters for another which certainly hasn’t moved us in a direction of progress, and may in fact have moved us a few steps backwards since the smart contract by definition doesn’t allow for any kind of remediation of the exploit.

                          1. 0

                            Contract invalidation risk is related to, but not the same as, counterparty and settlement risk in trading.

                            Modern credit systems didn’t exist until the late 1600s. Credit existed long before this, but its scope was strictly limited. Fungible obligations, short selling, futures, and all the other staples of modern trading are for the most part less than 500 years old.

                            As the bugs in smart contracts indicate it’s frequently possible for both the author of the contract and the counterparties to not fully understand what the contract actually says

                            You can’t blame human failures on the system they’re failing with. It’s not a “bug”, it’s the entire point.

                            1. 10

                              You can’t blame human failures on the system they’re failing with. It’s not a “bug”, it’s the entire point.

                              The entire point of systems engineering is to understand how system design leads to human failures.

                              1. 9

                                Fungible obligations, short selling, futures, and all the other staples of modern trading are for the most part less than 500 years old.

                                That’s not true. The ancient Babylonians had grains futures markets. Credit instruments, in many cases, predate cash.

                                1. 8

                                  You can’t blame human failures on the system they’re failing with.

                                  You can when literally Gavin Wood can’t write a contract that won’t lose him literally tens of millions of dollars. This strongly suggests the ideological imperative in question fails when it hits reality. “[ideology] cannot fail, it can only be failed” is the stuff of cults.

                                  1. 0

                                    You can when literally Gavin Wood can’t write a contract that won’t lose him literally tens of millions of dollars.

                                    Sounds like Gavin Wood is one of the original developers of ethereum, which is exactly the sort of person I would expect to lose tens of millions of dollars due to lack of rigor.

                                    “[ideology] cannot fail, it can only be failed” is the stuff of cults.

                                    Are mathematics and formal logic cults?

                                    That’s what this comes down to; I agree ethereum in particular is unsuitable as a financial system, but all that means is that we have to increase our expectations of formality in financial system design.

                                    1. 5

                                      Are mathematics and formal logic cults?

                                      No, but the idea of wiring them into a financial system in a way that quite efficiently separates less-rigorous people from their investments sure is. People have a hard time dealing with formalized logic systems, and get tremendous value from a squishy financial system with chargebacks and courts and mutable rules.

                                      1. 4

                                        Also, we’re really bad at doing math good :(

                                        1. 0

                                          Good thing grandma doesn’t need to write a proof every time she sends Bitcoin; only expert imementers need to care about this stuff.

                                          1. 6

                                            This is categorically not true. Because when Grandma wants to send money via a smart contract on a blockchain she must either trust that the writer of the contract was a benevolent expert or be an expert herself. This continued insistence that math will protect less math savvy people from more math savvy people is why every conversation with the idealist breaks down.

                                            Grandma isn’t an idealist. She just wants to be one of the parties in a smart contract. But grandma can’t safely do it. Period.

                                            1. 4

                                              A good example is the EtherDelta hack. Approximately 0 crypto users can audit their software, let alone do audit it; they trust that someone else has done the security legwork to decompile and inspect a smart contract or a huge pile of minified JavaScript.

                                              One could then answer “well they deserve what happens to them, doing that in cryptocurrency” - but then you’re back to the problem that this is substantially only a problem if you insist on using cryptocurrency for things that are currently done without it. The primary use case is ideological, ‘cos it sure isn’t practical.

                                    2. 4

                                      A bug is code that doesn’t work they way you meant it to. Blame lies with the Humans absolutely. But that’s the whole problem. Humans have to write the contracts. Humans also have to trust the contracts. Since Humans have to write them Humans also can’t trust them.

                                      This make smart contracts considerably more risky. That is the entire point of their critics.

                                      1. 0

                                        Humans have to write the contracts. Humans also have to trust the contracts. Since Humans have to write them Humans also can’t trust them.

                                        This would all be true in the absence of formal methods, which people whom I actually trust to build a working financial system are currently trying to fix.

                                        I agree that existing “smart” contract systems suck, but the fundamental idea is perfectly sound.

                                        1. 4

                                          We probably would need to agree to disagree. I suspect the above would still be true even if you had formal methods.

                                          1. 2

                                            I think so too. The issue here seems to have been a combination of the following:

                                            1. code sharing (“external library”) to reduce deployment cost in the form of gas
                                            2. not knowing or realizing the library was actually a multi-sig wallet contract and thus vulnerable to the previously fixed vulnerability
                                            3. not considering the ill effects of calling a “kill function” on such a wallet
                                          2. 3

                                            formal methods only prove what you specified. usually the way to hack formal proven programs is to play on unspecified things.

                                    3. 4

                                      Is cash unworkable? It has basically the same non-repudiation properties as Bitcoin, and yet people seemed to do OK with it for a long time

                                      The widespread use of cash is actually a pretty recent invention. “Cash” as we currently conceive of it (paper money, gold coins, silver bars, etc) has not historically been the primary financial instrument in people’s lives. The primary financial instrument has been credit. Historically, people would ring up a tab, and then pay it off. Even as late as the 1600s, it was possible for English kings to recall all of the coins in circulation and have it reminted with their likeness.

                                      This was workable because people lived in close-knit communities, and social and legal remedies could be effectively used against people who failed to pay off their debts. Cash was used when trading with people who could not be trusted, usually because they were merchants who were from outside the community.

                                      It’s only as we move to a more atomized, anonymous society that cash becomes more widely used. But even in a highly cash-oriented society, if you actually looked at the transactions, most “large” transactions were conducted in a repudiable medium, like cheques or bank transfers.

                                      1. 3

                                        I’d rather trade some repudiation potentially happening to having to lug around gold coins when I want to buy something. I find the arguments against repudiation a bit overblown. There was no lack of fraud, insolvency or straight-up moral hazard in the “good old days” of the gold standard.

                                        1. 0

                                          I’d rather trade some repudiation potentially happening to having to lug around gold coins when I want to buy something.

                                          Bitcoin allows you to keep both. It’s easy to transport and non-repudiable. That’s the point.

                                        2. 4

                                          Two problems with the cash analogy:

                                          1. Someone can’t pick your pocket from the other side of the world.
                                          2. Bitcoin acts much more like a balance in an electronically-accessible bank account. Except with no customer service and a terrible user experience. And ridiculously high fees. And long transaction delays.

                                          It combines the worst of both worlds.

                                          The existence of repudiation is a consequence of the emergence of unreliable credit systems, not something people sought out.

                                          This is completely historically false, as zaphar points out below.

                                          1. 3

                                            Actually, bitcoins have lot of less problems than ethereum. It has an only point of failure which is to keep the private key secret. (There is several variation on how this secret key can be stolen, but it is far smaller problem than the way bug can be introduced in smart contract)

                                            1. 2

                                              Someone can’t pick your pocket from the other side of the world.

                                              Someone also can’t steal your cryptocurrencies from the other side of the world unless you’re acting stupid and trust a third-party wallet service.

                                              Bitcoin acts much more like a balance in an electronically-accessible bank account.

                                              “Cash acts much more like a balance in a physically-accessible bank account.” What are you trying to communicate with this statement?

                                              Except with no customer service

                                              You don’t need one; anything that’s possible you can do on your own. Sure, if you’re totally clueless it might be harder for you, but it’s a massive improvement for people who know what they’re doing.

                                              and a terrible user experience.

                                              Right, because banks score so highly for customer satisfaction. The reason I tried bitcoin was because banks kept fucking me over in ridiculous ways. The state comptroller stole thousands of dollars from my Wells Fargo account because of a paperwork error (not possible with bitcoin), and after I got it fixed and had the money refunded, Wells Fargo charged me hundreds in “legal fees” for the pleasure of helping the government steal my money.

                                              And ridiculously high fees.

                                              Compared to what? Even with the current insane transaction volume, it’s still cheaper than PayPal or credit cards, for any purchase over, say, $50. It’s only going to get cheaper as we find ways to take the pressure off (a la lightning network).

                                              And long transaction delays.

                                              I thought you were the one who liked repudiation? A transaction “going through” just means it’s no longer repudiable. Bitcoin transactions clear to the level of a credit card transaction instantly, and to the level that credit card transactions do after ~6 months on an average of ten minutes.

                                              This is completely historically false,

                                              No, it’s really not. For some historical context look up Hawala (early credit system) and then read about the emergence of modern financial instruments in the Netherlands in the late 1600s, including modern notions of settlement.

                                              1. 5

                                                Someone also can’t steal your cryptocurrencies from the other side of the world unless you’re acting stupid and trust a third-party wallet service.

                                                Except the article in question is exactly that with no one acting stupid. A contract had an unintended effect that allowed someone playing around to accidentally revoke access to assets guarded by that contract. That is demonstrably the entire thing that a smart contract is for. Are you suggesting that your money is safe as long as you don’t use a smart contract and don’t be stupid? I would agree but the context of this conversation isn’t crypto-currency. It’s smart contracts.

                                                1. 6

                                                  Someone also can’t steal your cryptocurrencies from the other side of the world unless you’re acting stupid and trust a third-party wallet service.

                                                  see, you say this, but it turns out that “be your own bank” also means “be your own financial institution chief security officer”, and that turns out in repeated practice to be really hard, hence the repeated tales on /r/bitcoin of people losing their holding to user error or computer mishaps.

                                                  Here’s the Bitcoin Wiki guide to being your own bank: https://en.bitcoin.it/wiki/Securing_your_wallet Give that to your favourite nontechnical relative and see how they do.

                                                  it’s still cheaper than PayPal or credit cards, for any purchase over, say, $50.

                                                  This is entirely false in the UK.

                                                  The rest of your post is a Gish gallop of non sequiturs.

                                                  1. -1

                                                    hence the repeated tales on /r/bitcoin of people losing their holding to user error or computer mishaps

                                                    Yes, you expect some level of failure in a population of millions.

                                                    Give that to your favourite nontechnical relative and see how they do.

                                                    Any idiot can use a phone app like Mycelium and be sufficiently secure. Give them a Trezor if you’re really worried.

                                                    This is entirely false in the UK.

                                                    Are you claiming that credit cards don’t charge fees in the UK?

                                                    The rest of your post is a Gish gallop of non sequiturs.

                                                    Everything I said was a direct response to one of your points, so I think you mean “I don’t know how to refute what you said so I’m going to dismiss it instead”.

                                        1. [Comment from banned user removed]

                                          1. 12

                                            There’s absolutely nothing respectable about firing people. If you have to fire an employee then you failed miserably at your job. It’s almost never the employees fault when they get fired. It’s almost always the fault of HR for hiring the wrong people for the role, or management for not knowing how to lead, inspire and motivate their teams properly.

                                            I think that goes way too far in the opposite direction. There are genuinely toxic people out there. Sometimes those people can hide their toxicity well enough to pass through your interview process. At that point, once you’ve realized that this person is hurting your team, you should fire them. Claiming that there’s nothing respectable about firing people is equivalent to asking people to have perfect clairvoyance about the future behavior of someone they’ve met for at most a handful of hours.

                                            Of course, I do agree that after you fire a developer, you and your management should sit down and look at the process and ask yourselves, “Is there anything we could have done better here?” But sometimes the answer is, no, we couldn’t have done better here because to reduce the type-1 error of hiring a toxic person when we shouldn’t have, we’d have to raise type-2 errors significantly by rejecting anyone whom we didn’t think would fit perfectly with the team as it stands, even if they would have been a good contributor.

                                            Sometimes the cost of hiring diverse talent who’re adaptable and a have a wide range of skills is letting the occasional abrasive personality slip through. The key is to determine early on whether someone is affecting the team negatively, and then figuring out why and what to do about it an kind and humane manner.

                                            1. [Comment from banned user removed]

                                              1. 1

                                                I agree that “abrasive” was poor phrasing. However, I wanted to find a more neutral phrasing that would convey the same meaning as “toxic” without the negative moral connotations. I agree that developers have personality quirks, and I would go farther. Sometimes the new-hire’s personality will clash with the collective personality of the team in a way that could not be forecast ahead of time, and, moreover, this is no one’s fault. In such cases, the kindest thing to do is to admit that things aren’t working out to let the new hire go (with a generous severance package).

                                          1. 6

                                            I get that moves between languages can be uncomfortable, and are harder for some than others. The real danger is tying yourself down. Saying “I will only code in X” is a great way to end up obsolete. Saying “we only hire experts in X” is a great way to have no candidates.

                                            1. 3

                                              I somewhat disagree. There are still people who write COBOL for a living and they get paid bank. If you love a technology then feel free to pursue using it to your heart’s content.

                                              I think there is value in learning other languages. I’ve dabbled with BASIC, C, Python, Matlab, Octave, LabVIEW, JavaScript, and obviously Ruby. I’m not saying that you should be a language monogamist and never expand your horizons. Every new language I learn teaches me something regardless of how “similar” they are to a lang I already know. I’ve still not come across another language that feels better than Ruby does to me.

                                              Would I ever work in another language? Sure. But while I’ve got options that include my preferred lang, the reasons need to be more compelling that “is a job”.

                                              I do think companies need to write better requirements for jobs. Most of the “we need an expert” really means they would like an expert but will take someone with a pulse who has completed a “hello world”. Sometimes you really do need someone with a lot of experience for senior level positions. Most of the time the company has no clue.

                                              1. 5

                                                I would say that you’re actually misinterpreting the lesson of the COBOL programmers. The COBOL programmers you see today are making bank, but you have to keep in mind that they’re the survivors of multiple rounds of layoffs that resulted in mass unemployment at the beginning of the ‘90s. In essence you’re looking at the top 1% or 0.5% of COBOL programmers, those that are good enough to get called out retirement at multiples of their original salary to repair legacy systems. You’re not seeing the ones who went on to different kinds of programming or left the industry altogether.

                                                In addition, the problem with sticking to a single language for work is that if there’s another big secular shift in the industry (like the one away from COBOL), it can leave you unhireable. I’ve seen this initially with COBOL, and later with Perl. When Perl faded as a language for web development and was replaced with PHP, Python and Ruby, there were quite a few Perl hackers who had a really hard time finding work, simply because the only thing they had on their resume (in a professional capacity) was Perl. Meanwhile those who had Perl + Java, or Perl + Python, or Perl + C# had a much easier time getting work because they were able to lean on the non-Perl parts of their work experience to make a case that they would be productive in a non-Perl environment.

                                                That said, I wholly agree that companies are terrible at writing requirements. The vast majority of developer positions do not require deep knowledge of the internals of frameworks or language runtimes. Usually, basic knowledge of algorithms, data structures, combined with surface level familiarity with language syntax is more than sufficient to ensure that a developer can become productive in a reasonable period of time.

                                                However, the world we live in is a world in which employers filter resumes by keyword. In such a world, it makes sense to have professional accomplishments in as diverse a set of programming environments as possible in order to ensure that you’re not caught flat footed by secular shifts in the industry.

                                            1. 9

                                              The title supplied for this isn’t in line with what the linked article articulates as a point. It’s commentary on the article. I’d personally perfer a title that is in line with the content of the article and then commentary from the submitter as a comment here.

                                              To summarize the article:

                                              • I love clojure
                                              • I never consider lines of code to be a valid metric so I didn’t worry about “verbosity” of Java code
                                              • Event happened and I am now rethinking my previous position, perhaps it does matter in some regards
                                              1. 6

                                                I clicked on the article thinking it was an article that would “defend” the verbosity of Java, but it’s not the case at all. I agree that the title does not clearly reflect what the article is about.

                                                1. 1

                                                  I think a better title would be, “Why we should care about the verbosity of Java”. Actually, it would be even better to say, “Why we should care about verbosity in programming languages,” because, while the article was specifically comparing Java and Clojure, there’s nothing in that article that’s specific to either Java or Clojure. One could have made similar comparisons with Java and Scala, or Java and Kotlin.

                                                1. 3

                                                  I don’t think it needs to block on the site transition. As I understand it, the transition isn’t going to involve any significant code changes. It’ll be moving the existing code and data to new hosting infrastructure, under new management. Any patches made before the transition should be equally valid after.