8 ms·

> If you’re too boring it gets hard to recruit. You don’t want trend chasers joining, but good candidates have a healthy want and interest in new technology. I

by twic 6y ago

> If you’re too boring it gets hard to recruit. You don’t want trend chasers joining, but good candidates have a healthy want and interest in new technology. I think this is worth examining in a lot more detail. I accept that candidates are going to be put off by obsolete or terrible technology. I wouldn't take a job working on a Java 1.7 codebase, for example. Or ATG (now Oracle Commerce) - i did three years on that, and will never touch it again. But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things.

davidgl 6y ago
+1 for use of the term magpieism ;-)
- certifiedloud 6y ago
  I didn't understand the reference. I looked it up and may have found it here: https://en.wikipedia.org/wiki/Magpie#Cultural_references https://en.wikipedia.org/wiki/Magpie#Cultural_references > In European culture, the magpie is reputed to collect shiny objects, often in fiction things like wedding rings or other valuable or significant objects (often causing consternation at the disappearance, and false accusation of humans in the plot of the story); the most well-known example probably being Rossini's opera "La Gazza Ladra" (The Thieving Magpie). Recent research [8] has shown that there is little truth in the legend, and that magpies - like many animals - are actually unsettled by shiny, blue, or otherwise unusual objects.
- runawaybottle 6y ago
  Might be time for the Magpie stack, Rust based static file blog generator (compiled via WebAssembly) via AWS Lamdas written in Go, wait no, Deno. Or should there be a Rust based React framework? How would that work? If it exists then it’s gotta be more performant, so yeah, let’s use that. I don’t know if this is magpie enough now days. It’s hard to even make fun of this because the irony is even the joke becomes outdated lol.
  - steveklabnik 6y ago
    > How would that work? There are a few different Rust frontend frameworks that compile to assembly that are roughly based on the ideas of React. Yew is the most prominent.
- twic 6y ago
  I can't take any credit for it! That's an old Jeff Atwood term: https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/
k__ 6y ago
I had the same problem with devs who always want to use the newest stuff as with devs who use the same tech for over a decade because they don't want or can learn something new.
danjac 6y ago
I don't think you can just blame developers. There is a real fear in the industry of missing out and being left behind, and that if you don't keep your resume filled with the latest buzzwords you will become unemployable. Because recruiters ignore Github and side projects, the only way you can keep that resume up to date is by either applying for jobs using <shiny new tech> or by forcing it into your work projects, whether it makes sense or not. So yeah, magpie developers are a thing, but it's not just superficial developers, but superficial recruiters and companies as well.
willcipriano 6y ago
> But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. In my experience the tech stack is good indicator of how technology is viewed at a company. Java and C# shops I have encountered are very process driven, bureaucratic firms. In my experience they are management focused as opposed to tech focused. Where firms that use Python, Node, Haskell, Rust, Go, etc tend to be more tech forward. The reason I want to use "shiny new technology" is because I want to work at the latter as opposed to the former, I'd be happy to write C or PHP even at a tech focused firm but I rarely see jobs like that advertised.
- NomDePlum 6y ago
  Is being tech focused really better than being management focused? Surely that's just swapping one mis-focused model for another? I prefer to be in roles that are outcome and value focused. That should mean appropriate tech and sensible management but not for their own sake.
  - deleted 6y ago
    [deleted]
  - willcipriano 6y ago
    I may not be using the best terminology, but what I am talking about are firms where the majority of players consider themselves "non-technical". I haven't found these to be pleasant places to work or places that particularly value software engineers. I wish to work in places where my contributions can be understood and valued by the people I work with.
BigJono 6y ago
I really, really want to double down on this, because it's not expressed often enough or nearly well enough. There is a huge contingent of devs (I work in the consulting space, maybe this isn't everywhere) who have this idea that 'upskilling' is all about using new libraries in some toy project to familiarise themselves with the API of the library. They finish a project using React, then ask to be put on a Vue or Angular one next so they can 'widen their skillset'. You can pretty much split learning up into three kinds: Learning how to solve new problems, learning how to solve the same problems in a different way, or learning how to solve the same problems in the same way, but with a different representation. Learning the API of new libraries is almost always the latter, and people constantly mistake it for the second one and think they're making progress. Worse, people do this shit long before they've exhausted their options for the first kind of learning (which is the best). React, Angular and Vue all do the same thing. They all do it roughly in the same way. Even when libraries do things a different way, learning the API is often still the 3rd kind of learning unless the library's abstraction is leaky as shit and you have to learn all the intricacies of their approach anyway. Focusing on the wrong kind of learning makes a worse dev than you otherwise would have been. I've worked with a handful of great devs, and a fuckton of devs that know 20x as many libraries but churn out nothing but overengineered unmaintainable shit. If you want to distinguish yourself from the crowd, learn a boring technology in an area that you're not as proficient in. Don't chase the fancy shit just to build stuff you could already fucking build in half as many lines of code.
- scarface74 6y ago
  Don’t blame the devs - blame the market. Most companies insist on developers who don’t have to be trained on their stack. Most developers therefore do resume driven development. It’s as much of a “gravity problem” as being forced to “grind leetCode” to get into $BigTech.
  - mattgreenrocks 6y ago
    The market is wrong, but devs should take responsibility for their own professional development. Resume-driven development may optimize for the market, but it probably isn't the fastest way to learn.
wiremine 6y ago
> But if a candidate is motivated to take a job because they get to use shiny new technology I'm not sure it's about shiny tech, but the opportunity to grow and learn, and use those skills to become more marketable. The best developers (in my experience) have a growth mindset, and that includes learning new technology and new techniques.
- kerkeslager 6y ago
  This is just incorrect. Unless you think you know some older technology completely, there's always plenty of room to grow and learn on any tech stack. Some of the technologies I use daily, such as vim and bash, have been around for decades, yet I still learn things about them on a regular basis. In fact, one thing I've learned from working on bleeding-edge tech stacks is that communities around bleeding-edge tech stacks can often be narrow-minded in a way that hinders learning. Many (but not all) members Go community, for example, seem intent on not learning anything from other languages: if you point out that coroutines predate Go by decades and there's a lot to learn about their use from other languages, or that Go actually has a fairly weak type system, you'll get a lot of defensive pushback from Go fanboys who know literally nothing about other languages that contain coroutines, and don't understand that there's a difference between static types and strong types. There are good programmers in bad ecosystems--the folks who are bringing in generics might yet make Go a decent language--but remember that there was immense infighting to get there: I've been keeping track of Go long enough to remember all the people ranting that Go didn't need generics because it had `go generate`--a glorified C macro system (since they couldn't be arsed to learn from the mistakes of even one of the most adjacent languages) that breaks the entire point of not including generics in the first place (to keep the compiler single-pass). If this is the sort of "growing and learning" you're talking about, I generally tend to avoid working with people who "grow and learn" in this way.
  - wiremine 6y ago
    > If this is the sort of "growing and learning" you're talking about. No, it's not. The key phrase is "growth mindset" [1]. That does not mean throwing away knowledge or blindly accepting the shiny new objects. I think that's where we're disconnected? [1] https://www.brainpickings.org/2014/01/29/carol-dweck-mindset/ https://www.brainpickings.org/2014/01/29/carol-dweck-mindset...
kerkeslager 6y ago
I agree--I've built a career around Django, which is definitely a boring technology at this point, but there's not really any difficulty in hiring. For front-end stuff I've been using React, and while React is a great technology, it did attract a lot of inexperienced programmers initially. Nowadays, React by itself isn't the new shiny, so that effect has diminished, but the magpie-ism has taken on a new form: I find myself on a lot of projects fighting to keep out bleeding-edge JS libraries with > 100 dependencies. It's not hard to build a tool that demos well. It's much harder to build a tool that will withstand the tests of time.
marcinzm 6y ago
>But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things. You want engineers who love to grow, learn and solve problems. Startups in general have rather boring problems to solve compared to large companies. Learning and mastering a new technology however is a problem space that startups can provide their engineers.
- hvidgaard 6y ago
  Learning a new language or framework is not really that interesting, and certainly not worth changing job for. It can only last so long until it's boring. Solving a new kind of problem on the other hand is, at least for me, where the fulfillment lies.
scarface74 6y ago
There is nothing superficial about being attracted to a company - especially a startup - that uses near technologies. When your startup fails - and statistically likely it will, the only thing I would have to show for it is a bullet point on my resume when I apply for my next job. There are a lot more companies that want you to have experience with their technology stack than those that just want “smart people” (tm) and that will take the time to train you. On the other hand, salary compression and inversion are real. Your market value will go up by $some_big_number but HR policies will only allow raises of $some_small_number. So you have to keep your eye on the market and be prepared to jump ship. Anecdotally, I was once hired for a company that wanted to build a new product in .Net. The new product didn’t find a market, but their legacy product written in PHP did. None of us wanted to spend a year doing PHP development. All 14 of us left within six months.
- dahfizz 6y ago
  > Anecdotally, I was once hired for a company that wanted to build a new product in .Net. The new product didn’t find a market, but their legacy product written in PHP did. None of us wanted to spend a year doing PHP development. All 14 of us left within six months. Seems like exactly the point OP is making. By hiring devs that cared more about the stack than the product, your employer got screwed when the product with the boring stack took off.
  - scarface74 6y ago
    And if we had stayed, we would have been screwed when we did get ready to leave and find another job and all we could talk about is that we developed in PHP for a year.... But the rest of the story.... The department we worked for was an independent startup that got acquired by a Fortune 10 company (at the time) shortly before they started ramping up. The manager of the department was one of the original developers and founders. Even he left soon afterwards.
fabian2k 6y ago
I'd make a big distinction between entirely new languages, tool and frameworks and simply keeping up with the changes in a reasonably mature environment. For something that is still actively developed, and not in maintenance mode, it is a bad sign if it is on a very old version of that environment. There are a lot of nuances here depending on how disruptive, but also how useful the changes in new versions are. If you're far enough behind, you get problems with tools and dependencies that stopped supporting the old stuff. That can get very painful and annoying. I'd be generally careful about chasing all the shiny and new stuff, but there is also risk in lagging behind too far once it seems like most people jumped ship.
chooseaname 6y ago
I generally don't care what the tech stack is. I can learn how to program in just about any language and use just about any tool. I care about the domain. I care about the market for that domain. I care about what position the company is in in that market. But, primarily, I care about solving interesting problems in that domain. I want challenging problems to work on. I don't want to do the same thing over and over except this time in <fancy new tech>. You want me to put data from a form in to a db? Pass. You want me to figure out how to shine your company name onto a baseball as it is traveling to home plate? HELL YEAH!
- the_other 6y ago
  I love this attitude and feel some accord at a personal/intellectual level. You learn “programming” first, not a stack. (Well, ok, you tend to learn one language first and then branch out, but I assume you have been through that stage). So programming and problem solving should translate fairly well across domains. However, my experience with looking for jobs in London is that if I don’t have more experience with most of the stack than someone else in a company/recruiter’s candidate set, I will not get the job (regardless of how well I communicate my ability to work in teams or problem solve). Even after 15 years professional coding and a Masters in Software Engineering. How does your position work for you? Have you been able to learn new stacks “on the job”? Can we characterise a hiring pattern for different geographic areas? Do you go learning a prospective employer or client’s problem domain before making contact with them, and base conversations around that?
  - chooseaname 6y ago
    > Do you go learning a prospective employer or client’s problem domain before making contact with them, and base conversations around that? Yes, I try to do exactly that. The goal is to be able to speak their language in the interview as well as determine if I'm interested. I try and find out everything I can about the company, their product and the product of any competitors. If I'm enthusiastic about it, I figure out where to send my resume. As far as tech stacks, I've learned Java, Progress, C#, various scripting and shell languages all on the job without ever knowing them prior to getting the job (I started my career as a C++ programmer which I already knew, so there's that). I think the key has been the fact that when I interview I already know about the company and their product and domain and I can ask pointed, intelligent questions and generally have a great discussion about it with them. The companies that have hired me knowing I don't know, say, Java, haven't cared. The companies that don't hire me because I don't know Java, only care about hiring Java developers and I'm glad they spared me the trouble. I don't know if it is luck, but I generally don't get many rejections. I also don't generally send my resume to more than a few companies before getting hired.
crimsonalucard1 6y ago
>In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things. I may be biased because I know I talk a lot. But my experience has actually shown that this is not true. People who don't know a lot of things tend to stay silent. This strategy works consistently to allow many people to hide extraordinary gaps in knowledge. It's very common and the strategy works. When you see a person not talking too much... human bias tends to err on the fact that he's just not a talker or he may be deep in thought. Never do you think that a person isn't talking because he doesn't know anything. To be not biased is to consider all the possibilities and basically 90% of people just skip over the thought that the person isn't talking because he doesn't know anything. Now for a talker, the bias goes in the other direction because a talker has an incredibly higher chance of saying something you disagree with or is flat out wrong. This chance is higher EVEN when the talker is more knowledgeable than the non-talker simply because the talker places himself on the pedestal of judgement every time he opens his mouth while the non-talker avoids it. If you know a non-talker who may or may not have kept his trap shut after you explained something to him, really the only way to confirm whether he knows what you're talking about is to ask him confirmation questions after you talked to him. If you don't do this, likely he'll just google the info later and pretend that he always was on top of everything. You have to really watch out for this bias. Even as a talker I tended to bias towards thinking that the quiet nice guy was more intelligent. The reality is, "magpieism" has no correlation to how good or bad someone is... if someone talks a lot they could go either way, it's just that because they talk a lot, you have a ton of info on how good they are based off of what they say... while the non-talker you have no info and your judgement is (unknowingly to you) influenced by your biased optimistic assumptions. If someone is quiet there is a higher chance that he's quiet because he's totally lost. And if he's quiet often... then there's a higher chance that he's totally lost all the time.
crimsonalucard1 6y ago
>But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. I would argue that this attitude often exists at the corporate level as well. Most companies I've worked exist in a perpetual state of migration from monolith to Micro services. Basically the overall architecture remains static in the sense that it's always a giant monolith sitting in the center with some satellite services surrounding it. The migration to microservices and kubernetes is 99% buzzword driven and rarely has nothing to do with whether or not the product will benefit from the migration. The weirdest part about it is that it's many times a never ending thing initiative. It's very rare for a company to actually arrive to a point where every component of their system is split out into small pieces. It usually just stays permanently as some services surrounding a monolith despite all the talk. When entire companies are like this it's usually a sign that the entire company is weak. My experience has been that many companies have this attitude and many programmers share it. If all/most programmers share this general attitude then I wouldn't call these "new technology chasers" bad as most people are like this.
wikibob 6y ago
This is known as The Python Paradox: http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html

by twic 6y ago

davidgl 6y ago

+1 for use of the term magpieism ;-)

certifiedloud 6y ago
I didn't understand the reference. I looked it up and may have found it here: https://en.wikipedia.org/wiki/Magpie#Cultural_references https://en.wikipedia.org/wiki/Magpie#Cultural_references > In European culture, the magpie is reputed to collect shiny objects, often in fiction things like wedding rings or other valuable or significant objects (often causing consternation at the disappearance, and false accusation of humans in the plot of the story); the most well-known example probably being Rossini's opera "La Gazza Ladra" (The Thieving Magpie). Recent research [8] has shown that there is little truth in the legend, and that magpies - like many animals - are actually unsettled by shiny, blue, or otherwise unusual objects.
runawaybottle 6y ago
Might be time for the Magpie stack, Rust based static file blog generator (compiled via WebAssembly) via AWS Lamdas written in Go, wait no, Deno. Or should there be a Rust based React framework? How would that work? If it exists then it’s gotta be more performant, so yeah, let’s use that. I don’t know if this is magpie enough now days. It’s hard to even make fun of this because the irony is even the joke becomes outdated lol.
- steveklabnik 6y ago
  > How would that work? There are a few different Rust frontend frameworks that compile to assembly that are roughly based on the ideas of React. Yew is the most prominent.
twic 6y ago
I can't take any credit for it! That's an old Jeff Atwood term: https://blog.codinghorror.com/the-magpie-developer/ https://blog.codinghorror.com/the-magpie-developer/

k__ 6y ago

I had the same problem with devs who always want to use the newest stuff as with devs who use the same tech for over a decade because they don't want or can learn something new.

danjac 6y ago

I don't think you can just blame developers. There is a real fear in the industry of missing out and being left behind, and that if you don't keep your resume filled with the latest buzzwords you will become unemployable. Because recruiters ignore Github and side projects, the only way you can keep that resume up to date is by either applying for jobs using <shiny new tech> or by forcing it into your work projects, whether it makes sense or not. So yeah, magpie developers are a thing, but it's not just superficial developers, but superficial recruiters and companies as well.

willcipriano 6y ago

> But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. In my experience the tech stack is good indicator of how technology is viewed at a company. Java and C# shops I have encountered are very process driven, bureaucratic firms. In my experience they are management focused as opposed to tech focused. Where firms that use Python, Node, Haskell, Rust, Go, etc tend to be more tech forward. The reason I want to use "shiny new technology" is because I want to work at the latter as opposed to the former, I'd be happy to write C or PHP even at a tech focused firm but I rarely see jobs like that advertised.

NomDePlum 6y ago
Is being tech focused really better than being management focused? Surely that's just swapping one mis-focused model for another? I prefer to be in roles that are outcome and value focused. That should mean appropriate tech and sensible management but not for their own sake.
- deleted 6y ago
  [deleted]
- willcipriano 6y ago
  I may not be using the best terminology, but what I am talking about are firms where the majority of players consider themselves "non-technical". I haven't found these to be pleasant places to work or places that particularly value software engineers. I wish to work in places where my contributions can be understood and valued by the people I work with.

BigJono 6y ago

I really, really want to double down on this, because it's not expressed often enough or nearly well enough. There is a huge contingent of devs (I work in the consulting space, maybe this isn't everywhere) who have this idea that 'upskilling' is all about using new libraries in some toy project to familiarise themselves with the API of the library. They finish a project using React, then ask to be put on a Vue or Angular one next so they can 'widen their skillset'. You can pretty much split learning up into three kinds: Learning how to solve new problems, learning how to solve the same problems in a different way, or learning how to solve the same problems in the same way, but with a different representation. Learning the API of new libraries is almost always the latter, and people constantly mistake it for the second one and think they're making progress. Worse, people do this shit long before they've exhausted their options for the first kind of learning (which is the best). React, Angular and Vue all do the same thing. They all do it roughly in the same way. Even when libraries do things a different way, learning the API is often still the 3rd kind of learning unless the library's abstraction is leaky as shit and you have to learn all the intricacies of their approach anyway. Focusing on the wrong kind of learning makes a worse dev than you otherwise would have been. I've worked with a handful of great devs, and a fuckton of devs that know 20x as many libraries but churn out nothing but overengineered unmaintainable shit. If you want to distinguish yourself from the crowd, learn a boring technology in an area that you're not as proficient in. Don't chase the fancy shit just to build stuff you could already fucking build in half as many lines of code.

scarface74 6y ago
Don’t blame the devs - blame the market. Most companies insist on developers who don’t have to be trained on their stack. Most developers therefore do resume driven development. It’s as much of a “gravity problem” as being forced to “grind leetCode” to get into $BigTech.
- mattgreenrocks 6y ago
  The market is wrong, but devs should take responsibility for their own professional development. Resume-driven development may optimize for the market, but it probably isn't the fastest way to learn.

wiremine 6y ago

> But if a candidate is motivated to take a job because they get to use shiny new technology I'm not sure it's about shiny tech, but the opportunity to grow and learn, and use those skills to become more marketable. The best developers (in my experience) have a growth mindset, and that includes learning new technology and new techniques.

kerkeslager 6y ago
This is just incorrect. Unless you think you know some older technology completely, there's always plenty of room to grow and learn on any tech stack. Some of the technologies I use daily, such as vim and bash, have been around for decades, yet I still learn things about them on a regular basis. In fact, one thing I've learned from working on bleeding-edge tech stacks is that communities around bleeding-edge tech stacks can often be narrow-minded in a way that hinders learning. Many (but not all) members Go community, for example, seem intent on not learning anything from other languages: if you point out that coroutines predate Go by decades and there's a lot to learn about their use from other languages, or that Go actually has a fairly weak type system, you'll get a lot of defensive pushback from Go fanboys who know literally nothing about other languages that contain coroutines, and don't understand that there's a difference between static types and strong types. There are good programmers in bad ecosystems--the folks who are bringing in generics might yet make Go a decent language--but remember that there was immense infighting to get there: I've been keeping track of Go long enough to remember all the people ranting that Go didn't need generics because it had `go generate`--a glorified C macro system (since they couldn't be arsed to learn from the mistakes of even one of the most adjacent languages) that breaks the entire point of not including generics in the first place (to keep the compiler single-pass). If this is the sort of "growing and learning" you're talking about, I generally tend to avoid working with people who "grow and learn" in this way.
- wiremine 6y ago
  > If this is the sort of "growing and learning" you're talking about. No, it's not. The key phrase is "growth mindset" [1]. That does not mean throwing away knowledge or blindly accepting the shiny new objects. I think that's where we're disconnected? [1] https://www.brainpickings.org/2014/01/29/carol-dweck-mindset/ https://www.brainpickings.org/2014/01/29/carol-dweck-mindset...

kerkeslager 6y ago

I agree--I've built a career around Django, which is definitely a boring technology at this point, but there's not really any difficulty in hiring. For front-end stuff I've been using React, and while React is a great technology, it did attract a lot of inexperienced programmers initially. Nowadays, React by itself isn't the new shiny, so that effect has diminished, but the magpie-ism has taken on a new form: I find myself on a lot of projects fighting to keep out bleeding-edge JS libraries with > 100 dependencies. It's not hard to build a tool that demos well. It's much harder to build a tool that will withstand the tests of time.

marcinzm 6y ago

>But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things. You want engineers who love to grow, learn and solve problems. Startups in general have rather boring problems to solve compared to large companies. Learning and mastering a new technology however is a problem space that startups can provide their engineers.

hvidgaard 6y ago
Learning a new language or framework is not really that interesting, and certainly not worth changing job for. It can only last so long until it's boring. Solving a new kind of problem on the other hand is, at least for me, where the fulfillment lies.

scarface74 6y ago

There is nothing superficial about being attracted to a company - especially a startup - that uses near technologies. When your startup fails - and statistically likely it will, the only thing I would have to show for it is a bullet point on my resume when I apply for my next job. There are a lot more companies that want you to have experience with their technology stack than those that just want “smart people” (tm) and that will take the time to train you. On the other hand, salary compression and inversion are real. Your market value will go up by $some_big_number but HR policies will only allow raises of $some_small_number. So you have to keep your eye on the market and be prepared to jump ship. Anecdotally, I was once hired for a company that wanted to build a new product in .Net. The new product didn’t find a market, but their legacy product written in PHP did. None of us wanted to spend a year doing PHP development. All 14 of us left within six months.

dahfizz 6y ago
> Anecdotally, I was once hired for a company that wanted to build a new product in .Net. The new product didn’t find a market, but their legacy product written in PHP did. None of us wanted to spend a year doing PHP development. All 14 of us left within six months. Seems like exactly the point OP is making. By hiring devs that cared more about the stack than the product, your employer got screwed when the product with the boring stack took off.
- scarface74 6y ago
  And if we had stayed, we would have been screwed when we did get ready to leave and find another job and all we could talk about is that we developed in PHP for a year.... But the rest of the story.... The department we worked for was an independent startup that got acquired by a Fortune 10 company (at the time) shortly before they started ramping up. The manager of the department was one of the original developers and founders. Even he left soon afterwards.

fabian2k 6y ago

I'd make a big distinction between entirely new languages, tool and frameworks and simply keeping up with the changes in a reasonably mature environment. For something that is still actively developed, and not in maintenance mode, it is a bad sign if it is on a very old version of that environment. There are a lot of nuances here depending on how disruptive, but also how useful the changes in new versions are. If you're far enough behind, you get problems with tools and dependencies that stopped supporting the old stuff. That can get very painful and annoying. I'd be generally careful about chasing all the shiny and new stuff, but there is also risk in lagging behind too far once it seems like most people jumped ship.

chooseaname 6y ago

I generally don't care what the tech stack is. I can learn how to program in just about any language and use just about any tool. I care about the domain. I care about the market for that domain. I care about what position the company is in in that market. But, primarily, I care about solving interesting problems in that domain. I want challenging problems to work on. I don't want to do the same thing over and over except this time in <fancy new tech>. You want me to put data from a form in to a db? Pass. You want me to figure out how to shine your company name onto a baseball as it is traveling to home plate? HELL YEAH!

the_other 6y ago
I love this attitude and feel some accord at a personal/intellectual level. You learn “programming” first, not a stack. (Well, ok, you tend to learn one language first and then branch out, but I assume you have been through that stage). So programming and problem solving should translate fairly well across domains. However, my experience with looking for jobs in London is that if I don’t have more experience with most of the stack than someone else in a company/recruiter’s candidate set, I will not get the job (regardless of how well I communicate my ability to work in teams or problem solve). Even after 15 years professional coding and a Masters in Software Engineering. How does your position work for you? Have you been able to learn new stacks “on the job”? Can we characterise a hiring pattern for different geographic areas? Do you go learning a prospective employer or client’s problem domain before making contact with them, and base conversations around that?
- chooseaname 6y ago
  > Do you go learning a prospective employer or client’s problem domain before making contact with them, and base conversations around that? Yes, I try to do exactly that. The goal is to be able to speak their language in the interview as well as determine if I'm interested. I try and find out everything I can about the company, their product and the product of any competitors. If I'm enthusiastic about it, I figure out where to send my resume. As far as tech stacks, I've learned Java, Progress, C#, various scripting and shell languages all on the job without ever knowing them prior to getting the job (I started my career as a C++ programmer which I already knew, so there's that). I think the key has been the fact that when I interview I already know about the company and their product and domain and I can ask pointed, intelligent questions and generally have a great discussion about it with them. The companies that have hired me knowing I don't know, say, Java, haven't cared. The companies that don't hire me because I don't know Java, only care about hiring Java developers and I'm glad they spared me the trouble. I don't know if it is luck, but I generally don't get many rejections. I also don't generally send my resume to more than a few companies before getting hired.

crimsonalucard1 6y ago

>In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things. I may be biased because I know I talk a lot. But my experience has actually shown that this is not true. People who don't know a lot of things tend to stay silent. This strategy works consistently to allow many people to hide extraordinary gaps in knowledge. It's very common and the strategy works. When you see a person not talking too much... human bias tends to err on the fact that he's just not a talker or he may be deep in thought. Never do you think that a person isn't talking because he doesn't know anything. To be not biased is to consider all the possibilities and basically 90% of people just skip over the thought that the person isn't talking because he doesn't know anything. Now for a talker, the bias goes in the other direction because a talker has an incredibly higher chance of saying something you disagree with or is flat out wrong. This chance is higher EVEN when the talker is more knowledgeable than the non-talker simply because the talker places himself on the pedestal of judgement every time he opens his mouth while the non-talker avoids it. If you know a non-talker who may or may not have kept his trap shut after you explained something to him, really the only way to confirm whether he knows what you're talking about is to ask him confirmation questions after you talked to him. If you don't do this, likely he'll just google the info later and pretend that he always was on top of everything. You have to really watch out for this bias. Even as a talker I tended to bias towards thinking that the quiet nice guy was more intelligent. The reality is, "magpieism" has no correlation to how good or bad someone is... if someone talks a lot they could go either way, it's just that because they talk a lot, you have a ton of info on how good they are based off of what they say... while the non-talker you have no info and your judgement is (unknowingly to you) influenced by your biased optimistic assumptions. If someone is quiet there is a higher chance that he's quiet because he's totally lost. And if he's quiet often... then there's a higher chance that he's totally lost all the time.

crimsonalucard1 6y ago

>But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. I would argue that this attitude often exists at the corporate level as well. Most companies I've worked exist in a perpetual state of migration from monolith to Micro services. Basically the overall architecture remains static in the sense that it's always a giant monolith sitting in the center with some satellite services surrounding it. The migration to microservices and kubernetes is 99% buzzword driven and rarely has nothing to do with whether or not the product will benefit from the migration. The weirdest part about it is that it's many times a never ending thing initiative. It's very rare for a company to actually arrive to a point where every component of their system is split out into small pieces. It usually just stays permanently as some services surrounding a monolith despite all the talk. When entire companies are like this it's usually a sign that the entire company is weak. My experience has been that many companies have this attitude and many programmers share it. If all/most programmers share this general attitude then I wouldn't call these "new technology chasers" bad as most people are like this.

wikibob 6y ago

This is known as The Python Paradox: http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html