1. 26

  2. 13

    I disagree heavily with this article.

    In which we oversimplify “What employers want”

    Article suggests:

    • minimal ramp-up time
    • minimal training

    And that this leads to the failures of:

    • implementation skills (buzzword bingo) instead of problem solving
    • hiring for hypothetical problems (we need microservices! hire a xoogler!)

    One wryly observes that if this model was correct, we’d expect to see more companies paying better salaries for consultants “Mr. (or Mrs.) Wolf”s to drop in, pinch hit, and clear out. We don’t.

    By contrast, the things that I’ve observed employers actually want seem to be more along the lines of:

    • large headcounts to justify management (if well-funded)
    • really smart engineers to signal awesomeness (if well-funded or connected)
    • cheapest possible engineers (if not well-funded)
    • generalist engineers (if not well-funded but clever)

    These in turn motivate the observed wants above, but happen at a more basic level. And in turn, we get more interesting failure modes like:

    • Projects drowning in process as teams fail to coordinate
    • Projects dying because loud engineers are paid attention to over quiet competent ones
    • Projects withering once smart engineers leave and everyone can’t understand their magic boxes
    • Projects stalling because cheap engineers cannot do their jobs and slow down competent engineers who have to do rework
    • Projects starving because the engineer(s) are also on the hook for IT, for email, for content management, for reporting, for QA, and so forth

    And the hell of it is? Each of those happens to different types of employer, if they happen. There is no magical ANSI-standard “employer” to muse on, which is where this article first fails.

    In which we screw up “What employers need”

    So, for what it’s worth, the author does correctly identify that the employers’ needs are customer-focused and not technology-focused. So, there’s that. :)

    But, they fail to take that far enough. The fact is, what the companies really need are employees–especially sales and marketing folks–who can convince the consumer to buy the widget the company is selling or to assuage their concerns about the service provided. Actual competent engineering effort past that is secondary…I’ve seen many companies survive longer without good engineers than without good biz folks.

    Further, the solutions proposed are:

    • gathering requirements
    • having efficient solutions (defined elsewhere as doing less dev work)
    • knowing, or at least having heard of, lots of tech

    I agree with the second bit, though you have to click through blog posts (of course) to get to it.

    The first one, though, is very silly. Business folks basically don’t care about requirements, and gathering requirements (outside of certain types of consulting work) can be a fool’s errand when you find out that they haven’t thought about it, that they internally have conflicting requirements, and that they really are more concerned that you, the expensive engineer, haven’t made progress on that engineering thing you were supposed to be doing.

    What they actually care about is stability, safety, and the appearance of certainty in the howling vortex of crazy that is business. As engineers, our first reaction is something like requirements gathering, but the real problem is a people problem–and if you put a few ranks in diplomacy, you’ll find that it’s a hell of a lot easier to assuage and address concerns and to massage egos than it is to spend days and weeks on discovery and forcing people who are in a reactionary mindset to think ahead.

    The article fails to mention this, in either the cynical sense of “Learn how to Jedi your employers” or the pragmatic sense of “Learn how to give frequent progress reports, how to ask for forgiveness once you’ve inevitably overstepped their idea of your authority, and how to learn about the business so you can do the latter without giving it away while doing the former”.

    The bit about learning a bunch of technologies is a good way to find yourself constantly running on the treadmill of new shiny while never actually being competent enough to get paid for your expertise. Moreover, if you are in the mindset of “I’ll cover up my deficiencies in human interaction and negotiation with a larger portfolio of skills” you are going to be exploited by these people.

    Had the article made that suggestion in conjunction with any mention of the soft-skills, I wouldn’t be hard on it (it’s basically good advice!)–but it didn’t, so I am.

    In which the article finally gets to “What you should do”

    Far, far too late for it to do any good the article decides to get around to talking about marketing oneself. The advice isn’t wrong, and the last half on how to talk about past work and present opportunities is dangerously close to being good beginner Jedi stuff.

    But the first half? It’s a recap of the rest of the article, excepting where it suddenly talks about new things like learning longer-lasting technologies, and just uses bromides that sound much better to an engineer than “Hey, you’re probably really behind your opponent if you are reading this, let’s talk about soft-skills”.


    1. 2

      By contrast, the things that I’ve observed employers actually want seem to be more along the lines of:

      • large headcounts to justify management (if well-funded)
      • really smart engineers to signal awesomeness (if well-funded or connected)
      • cheapest possible engineers (if not well-funded)
      • generalist engineers (if not well-funded but clever)

      I don’t think you really disagree with the article, you just take a broader view. The article tells you how to become a generalist engineer (maybe even a really smart engineer if you are lucky).

      There are companies look for large headcounts and cheapest possible, but you want to avoid them unless you are desperate, so it makes no sense to optimize your skill set for them.

    2. 2

      while I was onboard for an article decrying the desire for experience with specific frameworks (a good developer should master concepts that work in any environment) the first words are an immediate interrupt:

      Which programming skills should spend your limited time and energy on,

      becoming a great developer takes years of study and practice, not limited time. this mindset of “learn language, write code, get paid” is what crashes markets, wrecks cars, and irradiates patients.

      1. [Comment removed by author]

        1. 4

          The whole Internet feels overrun with extrinsic motivation.

          It makes it feel rare to do something because you like it. It has to be about stupid vanity metrics, such as likes, retweets, views, stars, and other things that don’t matter but well, actually they sort of do because we need to like what others like to really appreciate it.

          This is completely antithetical to forming one’s own taste, which is a prerequisite for actually doing great work.

          1. 3

            what conversation are they polluting, exactly?

            1. [Comment removed by author]

              1. 9

                Is there anything wrong with the mindset of programming as a 9-5 and nothing more? There’s certain merits to it - cleaner separation of work and home life, for one.

                1. 7

                  I’m really not sure why coding for personal enjoyment is supposed to be more noble than coding to provide for one’s family’s financial needs. If anything, the latter seems superior to me. And I’m someone who does enjoy coding just for fun[1].

                  [1] Though there are certainly things I enjoy more, like writing. :-)

                  1. 3

                    I think there’s more than one conversation. There’s a career-oriented conversation, and there’s a ‘progress of the sciences’ conversation. In my lifetime I’ve sometimes ignored one or the other, or listened to both, or listened to neither. It turns out the world needs both to varying degrees, and they amplify and strengthen each other by turns.