13 ms·

> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, beca

by arbuge 7y ago

> Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career. In the real world this is (unfortunately) not how technical people are hired. The stack they are using seems to be the first thing hiring managers look at. You would think it would be only clueless recruiters who would think this way, but my experience is that well-respected and successful entrepreneurs also operate along these lines. It is not clear to me whether their success is related to or in spite of this way of thinking. To give them the benefit of the doubt, startups often need to move quickly and those few weeks-months needed for people to become familiar with a new stack they're unfamiliar with may simply not be available.

scarface74 7y ago
Why would a company choose someone who doesn’t know the stack they are using over someone who does? Let alone 6-12 months. Knowing the ecosystem, best practices, frameworks, etc takes longer than a few weeks. Sure I could learn Java or Swift in a few weeks, but does that mean I would be a competent Android or iOS developer?
- Retric 7y ago
  I have made the jump from one language to another several times on the job. It’s considered lower risk to use someone on the team than higher someone new. It’s also going to take a while to higher someone and get them up to speed. After a year you might not be as experienced as someone using the same stack for 5+ years but the difference is not that extreme. Further stacks tend to share quite a bit. Knowing SQL, HTML, JavaScript, CSS, jQuery etc takes a long time and has little to do with Java vs .Net.
  - scarface74 7y ago
    Languages are easy. But do you think you could jump from systems programming in C to mobile programming on Android “easily”. I’ve seen people jump from Java to C#. You can see the difference in their coding style, them not taking advantage of the features of the language, reinventing the wheel because they didn’t know there were popular packages that would do it for them, creating horrible inefficient queries and practices using EF etc.
    - Retric 7y ago
      Sure, jumps like that are not as bad as you might think. Style wise the code is often poor, but users don’t really care about the code. I started with Object Pascal on Mac OS 8/9 which forced you to do a lot of low level tasks like deal with Handles and suffer through a cooperative multithreaded OS. Rewriting the network layer from AppleTalk to TCP/IP was closer to systems programming in C than you might think. I have also been paid to write C programs, Windows application pre .Net in Visual C++ and post in C# and VB, written Java and C# websites, and most recently Angular SPA’s. Add to that a few random oddities like XSLT. PS: I even turned down working on Android, but could have made that jump.
      - scarface74 7y ago
        The jump is huge. Web development has a completely different model than mobile development. In web development, losing a connection is a failure case. Developing for mobile it is expected. Especially for enterprise apps. Logic is usually distributed, syncing is required, knowing which is the source of truth etc. This is really an example of hiring someone who has experience and hiring someone who thinks “it’s easy and just like what I did before”. Then I could get into all of the old netops guys who think AWS is just like what they did on prem and end up costing the company more...
        Retric 7y ago
        They are different, but I don’t think networking is one of the major differences. Website backends often have significant dependence on other services that can be down. Further standalone apps can have zero network dependence or a lot. So having written both, and similar code for each, I don’t feel the networking side is all that different. If anything networking is probably the largest similarly between them. PS: I did some iOS development in my spare time even worked with some old J2ME, so I assume Android is fairly similar.
- LastZactionHero 7y ago
  I've hired for the stack specifically and it really narrowed our applicant pool. Lately I've relaxed this filter. We're a Rails app, but what if there was a really great engineer that uses Python or Node? They might not know the right libraries to use, but would probably know there are libraries, have a good concept of application design in general, and know how to ask the right questions. And we're hoping to hire someone for years.
- williamdclt 7y ago
  > Why would a company choose someone who doesn’t know the stack they are using over someone who does? If the two candidates are perfectly identical on every other criteria, sure. But that's not the case, the point is that most other criteria are more important that the specific tech experience when dealing with competent people. > Sure I could learn Java or Swift in a few weeks, but does that mean I would be a competent Android or iOS developer? If you have web experience, I'm not too worried about your productivity on Android or iOS. If I'm hiring for Django and you have experience with any of Symfony, Rails, Spring, .Net or NestJS, the tech expertise is the least of my concerns.
  - scarface74 7y ago
    You’re not worried about their mobile experience until the app fails to work in a tunnel because they are expecting an always on connection or they have half their records on their mobile and half on their server and need to figure out which to use or they never had to figure out a syncing algorithm because you usually don’t have to sync things on the web since you never expect long periods of not being connected. Edit: and I forgot to mention the biggest UI failure I made when I did mobile development a decade ago on WinCE ruggedized devices. I didn’t even think about actually taking the device out into the sun where are all of the field service techs would be working and seeing how the screen, colors and contrast looked.
    - thestepafter 7y ago
      I would argue that this isn’t solely the responsibility of the programmer. This is where testing and QA comes in. Also, these are pretty basic considerations when building mobile apps and I would argue that they aren’t language specifics.
      - scarface74 7y ago
        So now we are going to spend more on development and probably rework because the developer decided he was just going to wrap the website in a webview and call it a “mobile app” because he didn’t think through these scenarios. Anytime that you have to go through the development -> QA cycle more then once it costs money and time. That’s kind of my point. Learning a language is easy and for the most part useless without knowing the frameworks and architectural best practices. I don’t know what Android has, but iOS has built in frameworks for handling syncing. If an Android developer didn’t know all of the built in frameworks available to them and re-invented the wheel, that would also be a waste of money.
- SpicyLemonZest 7y ago
  It’s like saying “well, we’re an agile company, so we prefer to hire people who know standups and sprint planning”. In principle they will ramp up faster, sure. But it’s just not a useful thing to select on, and if you do select on it you’ll end up with a weird monoculture.
  - scarface74 7y ago
    Knowing an ecosystem well on a senior level won’t happen in a few weeks. But to your example, I’ve seen developers who couldn’t adjust to developing where they had a rapid release cycle because they were use to the big design up front. How you develop software where you don’t have all of the requirements for the next year is a completely different mindset. Even on comments on this post, I see people who aren’t actually willing to actually talk to the customer to decide what they should work on.
    - SpicyLemonZest 7y ago
      I agree the problems you're describing are real and important to select for, but just requiring agile experience won't help you there. Lots of people practice a weird form of agile development, where they go through all the motions of fast iteration, but almost all tasks consist of non-negotiable internal dependencies and not value delivered to a customer. I'd argue a similar thing is true for tech stacks. If there's some correlation between knowledge of all the fiddly bits of C++ and ability to write clean, performant systems-level code, I've yet to see it.
      - Aeolun 7y ago
        > almost all tasks consist of non-negotiable internal dependencies and not value delivered to a customer It’s especially nice when you realize that as soon as you’ve completed all the non-negotiable features, a bunch of other things magically becomes non-negotiable.
    - virgilp 7y ago
      Really senior level is about talking to people; “Knowing the ecosystem well” (if by that you mean a specific tech stack) is almost irrelevant. Senior is more about solving the right problem than solving the problem “right”
- candybar 7y ago
  > Why would a company choose someone who doesn’t know the stack they are using over someone who does? Let alone 6-12 months. > Knowing the ecosystem, best practices, frameworks, etc takes longer than a few weeks. > Sure I could learn Java or Swift in a few weeks, but does that mean I would be a competent Android or iOS developer? I would separate this into two separate categories - big tech companies (or others with similarly large shared internal infra) and others. For big tech companies, for most positions, the tech stack is proprietary internal stuff such that knowing the language and best practices only get you about 10% of the way. For other types of companies, it's generally more important that you hire people with the right business context than the exact tech stack. With that said, native mobile development isn't just a stack - it's more of a different, though overlapping, career path - the main reason not to hire non-mobile developers into a mobile role isn't that the stack is different and takes time to learn, but that the workflow is so different that they may or may not know what it is that they are even signing up for. Hypothetically, you'd rather hire someone with Xamarin background with no Java experience for an Android java role, than someone with no mobile dev experience, but lots of Java backend experience. My first mobile development experience was a moderately complex Android project on an app that was used by tens of millions of people daily. There was no ramp-up - I had zero prior experience before signing up for this project, never even played around with any mobile development before and I had never professionally programmed in Java - and I was the sole engineer working on both mobile and backend. It was a little painful but everything shipped on time.
  - abtinf 7y ago
    > It was a little painful but everything shipped on time. Your last sentence would seem to contradict the entire body of your comment. You describe mobile development as a fundamentally different thing, but then your first gig was to work on a large project, the result of which was shipping on time at the cost of a “little” pain.
    - candybar 7y ago
      That's fair - what I meant by it being a different career isn't that skills aren't transferable at all but that you solve different kinds of problems entirely, as distinct from a difference in stack. And if you hired me then as a mobile developer, I'd have quit, so you don't want to hire non mobile engineers into mobile roles. Language/stack is a red herring here in the sense that Java backend development is a lot closer to Ruby backend development than it is to Android development.
- booleandilemma 7y ago
  Agreed. The job doesn’t exist to train you.
  - scarface74 7y ago
    It’s more nuanced than that. Most job reqs have “must haves” and “nice to haves”. My current job had one must have - C#/MVC/Web API and some Javascript experience - their current tech stack. Nice to haves were React, the fiddly bits of AWS, and Python. I was immediately useful because I was strong in the must haves, had a little AWS experience, and knew nothing about Python or React. I’ve since leveled up on the nice to haves except for React, I refuse to jump on the $cool_kids bandwagon of front end development. Especially seeing that everything else I listed, pays more, and doesn’t change as often.
    - WiseWeasel 7y ago
      I find React's relatively simple architecture makes it easy to get into for JS devs; I've always found it extremely productive and maintainable. My sickness is to the point that it’s hard for me to imagine an immediate future where it hasn’t entirely consumed the front-end web environment like jQuery did 15 or so years ago. Maybe you're onto something, but I'm loving the new digs so far.
      - scarface74 7y ago
        I don’t necessarily have anything against React as a technology, but as the old saying goes, a man with one ass can’t dance at two weddings. Almost everyone else at the company are better at the front end than I am but most haven’t taken the time to learn the backend. Why would I learn something, that I still wouldn’t be as good at in a year and couldn’t negotiate a higher pay based on bringing an above average amount of value to the company than other employees? I also wouldn’t be as competitive in the overall job market. This isn’t directed toward you, just a general comment.
- coldtea 7y ago
  >Why would a company choose someone who doesn’t know the stack they are using over someone who does? Because a stack defined programmer is a limited programmer...
  - scarface74 7y ago
    As a person who was responsible for hiring in a previous role and I still sit on a lot of technical interviews, I didn’t care if you were “limited” to the stack we were using as long as you could get the job done without six months to a year of training. If you started your career learning Java 20 years ago and you kept up with the latest trends of Java, you could still find a job now. The same is true for C# around 15 years ago.
- nscalf 7y ago
  Because someone is smarter or better at the job in general that the lower quality specialists they can find. It's very hard to find a good generalist. If you can be a good generalist, you're exponentially more valuable than a generic specialist. I have done mostly backend work in Python, but in my current role I've worked in the frontend with Angular, I've debugged critical issues on our iOS app, I've fixed our AWS infrastructure, I've moved us away from dragging files into windows boxes to CI/CD, I've helped architect solutions, I've worked with our customers, I've led efforts across multiple teams, etc. Being a "Python Programmer" in no way measures my value to the company, in fact, it necessarily limits what I'm actually capable of contributing to the company. If you can show that you can add value outside of a specific tech stack, you're worth the few weeks to learn a new technology. And yeah, it is basically a few weeks to get up to speed and be a contributing member of a code base if you don't know the technology. 6-12 months to know all of the details if you're a solid engineer.
  - scarface74 7y ago
    I would say just the opposite. When it comes to the entire “web developer” tech stack, sure I can put together a website good enough for internal use, but I’m not very good at the front end. I consider myself to be very good at C#, okay at backend JS development and passable at Python. I have enough experience from doing a lot of ETL in a previous life to know how to automize queries and schemas for speed and to not lock up a database. I’ve set up CI/CD solutions from scratch with what is now called “Azure Devops”, AWS’s CodeBuild/CodeDeploy/CodePipeline, OctopusDeploy and Jenkins I could just as easily and competitively apply for jobs as an “AWS Architect” who knows most of the popular AWS offerings for developers, Devops, netops, and system administrators and I have experience with them. But in many of those areas - especially on the front end and with the netops, system administration stuff, at any scale. It wouldn’t make any sense to hire someone who “kind of” knows what they are doing over hiring a specialist. If I need something now I’m not going to want to wait for you to get up to speed in year. Do you really think you’re as good at any of those areas as a specialist? AWS alone announces dozens of new things every month on their podcast.
    - nscalf 7y ago
rco8786 7y ago
This is entirely company dependent. My team is primarily Ruby and we hire folks with no ruby experience all the time.
- jfabre 7y ago
  Because ruby programmers are rare nowadays and your company still need people to build software. At least, that's my assumption.
  - eropple 7y ago
    They're not rare. I know a ton and many still write Ruby. Willingness to work on brownfield Ruby projects is rare; as with other similar systems like Django or roll-your-own Express stuff, such systems strongly tend towards chaos and a lack of maintainability after a certain point if they haven’t already had strong leadership end-to-end. In my neck of the woods, the folks who you want doing that work don't want to do that work anymore. Unless you pay a lot.
    - Supermancho 7y ago
      > They're not rare Depends on how you define rare. Exceedingly uncommon at the very least. stares at a pile of 150 resumes Ruby is a language languishing from being embedded in a few niches, having poor performance, and otherwise being unremarkable, imo. Ruby was made with the idea that picking it up would be easy (which it is), leading to less incentive to learn it. Putting Ruby in the job description gives you applicants with Ruby experience, which is why the blog post was (and is) impractical. Signaling works.
      - eropple 7y ago
        Calling Ruby "unremarkable" is a significant understatement, I think. For my money nothing in common usage approaches the same kinds of metaprogramming and solving-a-category-of-problems-at-once nature of a really comfortable and dynamic Lisp as does Ruby. (Clojure isn't in common use.) I get that that's not what you want, you want somebody to close tickets, but that's not Ruby's fault. And most of the people I know still working in Ruby are at a level where that kind of grunt work just isn't worth their time; most others have, of course, moved on.
codegeek 7y ago
I run a small company and I m looking for Web Developers. We primarily use PHP and getting into Golang but I really dont care about the language since what matters is concepts and experience with html/css/js http requests/response, client server architecture, database/CRUD, REST API etc. So i m not one of those employers :)
- thestepafter 7y ago
  Same here, hire the person, treat them well, and the language doesn’t matter as long as they have experience in similar languages.
srazzaque 7y ago
I agree with you, it's not how technical people are hired. But, I think it's entirely necessary in certain contexts, once we realise the software world is bigger than just Web. Learning languages and libraries is easy. But new paradigms, domains, and entire new ways of thinking? It takes time to master. So I'd be inclined to add disclaimers to the idea that "after 6 to 12 months nobody will ever notice". This might be the true if you're moving from 1 web programming gig to another web programming gig, but the author himself acknowledges the vastness of software out there that underpins every aspect of industry. So - if you're going to be working on enterprise middleware in investment banks, or embedded systems on airplane simulation kit, or APL, or missile guidance software - but all you've done is web... then tech stack does matter. Insofar as being familiar with the paradigms, standard patterns and unique industry norms. The problem is that some middlemen (ie recruiters, HR or non-technical hiring managers) do not understand that, for instance, Java and C# are somewhat interchangeable, but C# and APL are not. Fantastically written piece in all though, lots of great stuff in there that I wish I had either known (or stopped denying!) earlier in my career. But specifically on this point I think it's a dangerous idea to imply to undergrads that deep, hard-earned experience in both tech and domain can be overcome in such small time scales.
- enraged_camel 7y ago
  >>Learning languages and libraries is easy. But new paradigms, domains, and entire new ways of thinking? It takes time to master. Here's why I think this is sometimes a false dichotomy: going from Ruby to Python will be relatively easy. Going from Ruby to Haskell, on the other hand, will involve not just learning Haskell the language (syntax etc.) but also new paradigms and entire new ways of thinking.
Consultant32452 7y ago
It's also not true with respect to people noticing what you've been doing with your career. A programming language isn't just a language, it's also a culture. I've been writing Java professionally for almost 20 years. I can definitely tell when a person isn't a "java programmer." I am struggling to describe exactly what I mean, but the best metaphor I can come up with is it's kind of like hearing someone speak with a heavy accent. It can all be technically correct, the grammar is perfect, but you can still tell it's not native. Sometimes this is good. It can bring in new/interesting/helpful ways of thinking about problems to come up with better solutions. Sometimes it's bad because anything that's a little jarring or unusual impedes support and maintenance by "native programmers" in the same way a heavy accent can impede communication.
jghn 7y ago
It's the first thing some hiring managers look at. Speaking for myself as a hiring manager I'm not looking for specific tech stacks. I'm looking for general patterns. Someone who has spent their entire career doing front end work is unlikely to be a great fit for embedded development and vice versa, but I don't care so much about the specific technologies they used in the process. My experience has been that concepts and fundamentals trump specific tech stacks. However I also take a longer range view of things. I care far less about relative productivity of two candidates a month from now than I do a year from now.
- scarface74 7y ago
  Until your customer needs a feature a month from now and not a year from now or you only have a six month runway....
  - jghn 7y ago
    The percentage of hires for companies in that situation is going to be extremely small, yet the "hire for tech stack" motif is cargo culted throughout the industry.
    - scarface74 7y ago
      Why else would most companies have open reqs if they don’t see a need for man power soon unless you are one of the four or five big tech companies that are trying to accumulate smart people (tm)?
      - jghn 7y ago
        Because they project for incoming needs. Hiring for today’s needs is a fools errand, it can take a good amount of time to identify a quality candidate. If I need something filled right ie or the company goes under it is already too late.
  - jammygit 7y ago
    Doesn’t brooks say that adding manpower to an already late project makes the project later?
dleslie 7y ago
> The stack they are using seems to be the first thing hiring managers look at. I try to avoid companies that hire in this manner; it shows a lack of vision and planning. It's unlikely that a given developer will be working on the same stack in five years; the stack will have evolved or the developer will have moved on.
- scarface74 7y ago
  That’s kind of why you do want people who know the stack. If you as the manager or you expect the developer to move on with three years. Why waste a year getting a developer up to speed without having anything to show for it?
pcmoney 7y ago
I would argue that it is the first thing a manager looking for a cost center, cog type engineer looks at. They are not looking for an engineer who actually understands business they are looking for a “ plumbing engineer” that just keeps their head down and grinds out code. There is little upside in this position and this type hiring manager mentality should filter those jobs out for you. I do agree that most start ups will probably restrict them selves to hiring in the same stack as their tolerance for learning curves will be extremely short. However, I feel that many employers are used to engineers who don’t “get business” and so they just want somebody to plunk down code. This leads them to “what kind of dumb cog/stack are you?” questions as they are already assuming they won’t be able to hire a truly “full stack” engineer who understands the revenues and costs associated with their work and how they impact corporate strategy etc.
JMTQp8lwXL 7y ago
Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. The domains of implementing microservices vs. writing front end code are fundamentally driven by very different problems. The stack an engineer has experience with can be one indicator of the areas they excel in.
- throwaway981211 7y ago
  Is this the right way to hire? Not saying it’s wrong but I’ve taken a different approach which has generally worked out. Even if I was hiring for a specific role (front end), I care less about familiarity with specific bundlers or frameworks and something more like - “Can this person problem solve and deal with varying levels of ambiguity? Do they seem capable of figuring something out without a ton of direction?”
  - mcv 7y ago
    That is exactly the thing I select for. I recently had to hire 4 developers, and I was not all that interested in how many years of experience they had in javascript or typescript (our main language), and even less if you know Vue or Express (our stack). I mean, it's good to know javascript, and certainly ES6 or typescript, but I'm much more interested in: can I discuss stuff with you, do you have interesting opinions, can you make clear decisions in the face of unclear requirements, are you creative, and can you fix stuff and build features without anyone having to hold your hand? In case of doubt, knowledge of ES6 or Typescript or any relevant front-end framework (Vue, Angular or React) can make a lot of difference, but I'd rather hire someone who knows a dozen languages we don't use than someone who only knows exactly the one language we do use.
    - scarface74 7y ago
      And then when you need to ship now you have a bunch of dead weight while you wait for them to ramp up. Also, since now you are taking time from your devs who do know the stack to mentor your new hires and code reviews because you can’t trust them to do good work without messing up your code base. They are now doing “negative work”.
RhodesianHunter 7y ago
> In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career. I think this is only true if what you're working on is simple, like crud apps. It takes longer to be intimately familiar with a language's concurrency model, pros and cons of major libraries and frameworks and the ability to make such decisions quickly and without learning hurdles, etc.
- furyofantares 7y ago
  In my experience folks can be reasonably productive essentially immediately in a language they've never touched if they're diving into an existing code base. Give them a machine that's already set up like the other developers, point them at a couple easy bugs or features, do some code reviews, and yes they'll be slightly slower through this process than someone that's already familiar with the stack, but not much.
fimdomeio 7y ago
I'm not in the usual hiring circuit but went to one or two interviews for having a feel for that world. I always had the attitude of being the guy who will learn whatever is needed to successfully finish the task at hand, and I have work to show for it. It's amazing how's that was worth nothing for people that interviewed me, compared with how many years of react experience I had.
- HerrmannM 7y ago
  Sort of same kind of experience. I presented myself as a problem solver, with algorithmic skills and a deep understanding of language's principles as this is my research area... "Sure, but can you do python" Well, I definitely can learn it. But can I do it right their, right now? I never really worked in python, so no. And so... no.
avip 7y ago
First, developers rarely become tech fluent in 6-12 months. Second, startups don't have 6-12 months.
jarjoura 7y ago
Point taken, but the language is not the thing I would hire for anyway. It's the environment and skill-set beyond the language. A mobile developer even requires a completely different set of instincts to be successful than an engineer who's got work experience building scalable backend systems. C++ running across 1000 inter-connected systems is not the same C++ compiled down to run on a gaming console with limited CPU cycles to spare. C++ shared across iOS and Android is also different because Android requires that you bridge the library across Java and iOS may require an Obj-C layer if you're in Swift. If you spent your whole career writing code in Python and you wanted your next job on iOS, my concern wouldn't be, can you learn Swift in a short time. My concern would start at something as simple as how you would cache data when the network connection times out. Or can you manage your data models in a way that can maintain 60fps scrolling, something iOS engineers pride themselves in achieving. Of course all of this can be learned, but my point is that it's more than the language.
shubhambattoo 7y ago
Exactly what I thought when I read this paragraph. But still some CTOs are willing to let the team take time to learn a new stack and that in the end helps the organization (was part of one).
the_watcher 7y ago
The point is to acknowledge that the way most technical people are hired isn't the way that maximizes outcomes for technical people. Patio11's point is that the way to maximize outcomes as a technical employee is to _break out_ of this paradigm. It might reduce some of your top of funnel (random recruiter outreach) options, but it will increase the value of the opportunities that do arise.
james_s_tayler 7y ago
It's not even just start-ups. Established companies work the same way. Getting pidgeon-holed is a very real and common phenomenon. It's also kind of silly in a lot of cases too. It always feels like "Oh I see you do Angular... but could you _really_ be capable of developing in React? I don't know..." So retarded. Yet this attitude seems to dominate.

by arbuge 7y ago

scarface74 7y ago

Why would a company choose someone who doesn’t know the stack they are using over someone who does? Let alone 6-12 months. Knowing the ecosystem, best practices, frameworks, etc takes longer than a few weeks. Sure I could learn Java or Swift in a few weeks, but does that mean I would be a competent Android or iOS developer?

Retric 7y ago
I have made the jump from one language to another several times on the job. It’s considered lower risk to use someone on the team than higher someone new. It’s also going to take a while to higher someone and get them up to speed. After a year you might not be as experienced as someone using the same stack for 5+ years but the difference is not that extreme. Further stacks tend to share quite a bit. Knowing SQL, HTML, JavaScript, CSS, jQuery etc takes a long time and has little to do with Java vs .Net.
- scarface74 7y ago
  Languages are easy. But do you think you could jump from systems programming in C to mobile programming on Android “easily”. I’ve seen people jump from Java to C#. You can see the difference in their coding style, them not taking advantage of the features of the language, reinventing the wheel because they didn’t know there were popular packages that would do it for them, creating horrible inefficient queries and practices using EF etc.
  - Retric 7y ago
    Sure, jumps like that are not as bad as you might think. Style wise the code is often poor, but users don’t really care about the code. I started with Object Pascal on Mac OS 8/9 which forced you to do a lot of low level tasks like deal with Handles and suffer through a cooperative multithreaded OS. Rewriting the network layer from AppleTalk to TCP/IP was closer to systems programming in C than you might think. I have also been paid to write C programs, Windows application pre .Net in Visual C++ and post in C# and VB, written Java and C# websites, and most recently Angular SPA’s. Add to that a few random oddities like XSLT. PS: I even turned down working on Android, but could have made that jump.
    - scarface74 7y ago
      The jump is huge. Web development has a completely different model than mobile development. In web development, losing a connection is a failure case. Developing for mobile it is expected. Especially for enterprise apps. Logic is usually distributed, syncing is required, knowing which is the source of truth etc. This is really an example of hiring someone who has experience and hiring someone who thinks “it’s easy and just like what I did before”. Then I could get into all of the old netops guys who think AWS is just like what they did on prem and end up costing the company more...
      - Retric 7y ago
        They are different, but I don’t think networking is one of the major differences. Website backends often have significant dependence on other services that can be down. Further standalone apps can have zero network dependence or a lot. So having written both, and similar code for each, I don’t feel the networking side is all that different. If anything networking is probably the largest similarly between them. PS: I did some iOS development in my spare time even worked with some old J2ME, so I assume Android is fairly similar.
LastZactionHero 7y ago
I've hired for the stack specifically and it really narrowed our applicant pool. Lately I've relaxed this filter. We're a Rails app, but what if there was a really great engineer that uses Python or Node? They might not know the right libraries to use, but would probably know there are libraries, have a good concept of application design in general, and know how to ask the right questions. And we're hoping to hire someone for years.
williamdclt 7y ago
> Why would a company choose someone who doesn’t know the stack they are using over someone who does? If the two candidates are perfectly identical on every other criteria, sure. But that's not the case, the point is that most other criteria are more important that the specific tech experience when dealing with competent people. > Sure I could learn Java or Swift in a few weeks, but does that mean I would be a competent Android or iOS developer? If you have web experience, I'm not too worried about your productivity on Android or iOS. If I'm hiring for Django and you have experience with any of Symfony, Rails, Spring, .Net or NestJS, the tech expertise is the least of my concerns.
- scarface74 7y ago
  You’re not worried about their mobile experience until the app fails to work in a tunnel because they are expecting an always on connection or they have half their records on their mobile and half on their server and need to figure out which to use or they never had to figure out a syncing algorithm because you usually don’t have to sync things on the web since you never expect long periods of not being connected. Edit: and I forgot to mention the biggest UI failure I made when I did mobile development a decade ago on WinCE ruggedized devices. I didn’t even think about actually taking the device out into the sun where are all of the field service techs would be working and seeing how the screen, colors and contrast looked.
  - thestepafter 7y ago
    I would argue that this isn’t solely the responsibility of the programmer. This is where testing and QA comes in. Also, these are pretty basic considerations when building mobile apps and I would argue that they aren’t language specifics.
    - scarface74 7y ago
      So now we are going to spend more on development and probably rework because the developer decided he was just going to wrap the website in a webview and call it a “mobile app” because he didn’t think through these scenarios. Anytime that you have to go through the development -> QA cycle more then once it costs money and time. That’s kind of my point. Learning a language is easy and for the most part useless without knowing the frameworks and architectural best practices. I don’t know what Android has, but iOS has built in frameworks for handling syncing. If an Android developer didn’t know all of the built in frameworks available to them and re-invented the wheel, that would also be a waste of money.
SpicyLemonZest 7y ago
It’s like saying “well, we’re an agile company, so we prefer to hire people who know standups and sprint planning”. In principle they will ramp up faster, sure. But it’s just not a useful thing to select on, and if you do select on it you’ll end up with a weird monoculture.
- scarface74 7y ago
  Knowing an ecosystem well on a senior level won’t happen in a few weeks. But to your example, I’ve seen developers who couldn’t adjust to developing where they had a rapid release cycle because they were use to the big design up front. How you develop software where you don’t have all of the requirements for the next year is a completely different mindset. Even on comments on this post, I see people who aren’t actually willing to actually talk to the customer to decide what they should work on.
  - SpicyLemonZest 7y ago
    I agree the problems you're describing are real and important to select for, but just requiring agile experience won't help you there. Lots of people practice a weird form of agile development, where they go through all the motions of fast iteration, but almost all tasks consist of non-negotiable internal dependencies and not value delivered to a customer. I'd argue a similar thing is true for tech stacks. If there's some correlation between knowledge of all the fiddly bits of C++ and ability to write clean, performant systems-level code, I've yet to see it.
    - Aeolun 7y ago
      > almost all tasks consist of non-negotiable internal dependencies and not value delivered to a customer It’s especially nice when you realize that as soon as you’ve completed all the non-negotiable features, a bunch of other things magically becomes non-negotiable.
  - virgilp 7y ago
    Really senior level is about talking to people; “Knowing the ecosystem well” (if by that you mean a specific tech stack) is almost irrelevant. Senior is more about solving the right problem than solving the problem “right”
candybar 7y ago
> Why would a company choose someone who doesn’t know the stack they are using over someone who does? Let alone 6-12 months. > Knowing the ecosystem, best practices, frameworks, etc takes longer than a few weeks. > Sure I could learn Java or Swift in a few weeks, but does that mean I would be a competent Android or iOS developer? I would separate this into two separate categories - big tech companies (or others with similarly large shared internal infra) and others. For big tech companies, for most positions, the tech stack is proprietary internal stuff such that knowing the language and best practices only get you about 10% of the way. For other types of companies, it's generally more important that you hire people with the right business context than the exact tech stack. With that said, native mobile development isn't just a stack - it's more of a different, though overlapping, career path - the main reason not to hire non-mobile developers into a mobile role isn't that the stack is different and takes time to learn, but that the workflow is so different that they may or may not know what it is that they are even signing up for. Hypothetically, you'd rather hire someone with Xamarin background with no Java experience for an Android java role, than someone with no mobile dev experience, but lots of Java backend experience. My first mobile development experience was a moderately complex Android project on an app that was used by tens of millions of people daily. There was no ramp-up - I had zero prior experience before signing up for this project, never even played around with any mobile development before and I had never professionally programmed in Java - and I was the sole engineer working on both mobile and backend. It was a little painful but everything shipped on time.
- abtinf 7y ago
  > It was a little painful but everything shipped on time. Your last sentence would seem to contradict the entire body of your comment. You describe mobile development as a fundamentally different thing, but then your first gig was to work on a large project, the result of which was shipping on time at the cost of a “little” pain.
  - candybar 7y ago
    That's fair - what I meant by it being a different career isn't that skills aren't transferable at all but that you solve different kinds of problems entirely, as distinct from a difference in stack. And if you hired me then as a mobile developer, I'd have quit, so you don't want to hire non mobile engineers into mobile roles. Language/stack is a red herring here in the sense that Java backend development is a lot closer to Ruby backend development than it is to Android development.
booleandilemma 7y ago
Agreed. The job doesn’t exist to train you.
- scarface74 7y ago
  It’s more nuanced than that. Most job reqs have “must haves” and “nice to haves”. My current job had one must have - C#/MVC/Web API and some Javascript experience - their current tech stack. Nice to haves were React, the fiddly bits of AWS, and Python. I was immediately useful because I was strong in the must haves, had a little AWS experience, and knew nothing about Python or React. I’ve since leveled up on the nice to haves except for React, I refuse to jump on the $cool_kids bandwagon of front end development. Especially seeing that everything else I listed, pays more, and doesn’t change as often.
  - WiseWeasel 7y ago
    I find React's relatively simple architecture makes it easy to get into for JS devs; I've always found it extremely productive and maintainable. My sickness is to the point that it’s hard for me to imagine an immediate future where it hasn’t entirely consumed the front-end web environment like jQuery did 15 or so years ago. Maybe you're onto something, but I'm loving the new digs so far.
    - scarface74 7y ago
      I don’t necessarily have anything against React as a technology, but as the old saying goes, a man with one ass can’t dance at two weddings. Almost everyone else at the company are better at the front end than I am but most haven’t taken the time to learn the backend. Why would I learn something, that I still wouldn’t be as good at in a year and couldn’t negotiate a higher pay based on bringing an above average amount of value to the company than other employees? I also wouldn’t be as competitive in the overall job market. This isn’t directed toward you, just a general comment.
coldtea 7y ago
>Why would a company choose someone who doesn’t know the stack they are using over someone who does? Because a stack defined programmer is a limited programmer...
- scarface74 7y ago
  As a person who was responsible for hiring in a previous role and I still sit on a lot of technical interviews, I didn’t care if you were “limited” to the stack we were using as long as you could get the job done without six months to a year of training. If you started your career learning Java 20 years ago and you kept up with the latest trends of Java, you could still find a job now. The same is true for C# around 15 years ago.
nscalf 7y ago
Because someone is smarter or better at the job in general that the lower quality specialists they can find. It's very hard to find a good generalist. If you can be a good generalist, you're exponentially more valuable than a generic specialist. I have done mostly backend work in Python, but in my current role I've worked in the frontend with Angular, I've debugged critical issues on our iOS app, I've fixed our AWS infrastructure, I've moved us away from dragging files into windows boxes to CI/CD, I've helped architect solutions, I've worked with our customers, I've led efforts across multiple teams, etc. Being a "Python Programmer" in no way measures my value to the company, in fact, it necessarily limits what I'm actually capable of contributing to the company. If you can show that you can add value outside of a specific tech stack, you're worth the few weeks to learn a new technology. And yeah, it is basically a few weeks to get up to speed and be a contributing member of a code base if you don't know the technology. 6-12 months to know all of the details if you're a solid engineer.
- scarface74 7y ago
  I would say just the opposite. When it comes to the entire “web developer” tech stack, sure I can put together a website good enough for internal use, but I’m not very good at the front end. I consider myself to be very good at C#, okay at backend JS development and passable at Python. I have enough experience from doing a lot of ETL in a previous life to know how to automize queries and schemas for speed and to not lock up a database. I’ve set up CI/CD solutions from scratch with what is now called “Azure Devops”, AWS’s CodeBuild/CodeDeploy/CodePipeline, OctopusDeploy and Jenkins I could just as easily and competitively apply for jobs as an “AWS Architect” who knows most of the popular AWS offerings for developers, Devops, netops, and system administrators and I have experience with them. But in many of those areas - especially on the front end and with the netops, system administration stuff, at any scale. It wouldn’t make any sense to hire someone who “kind of” knows what they are doing over hiring a specialist. If I need something now I’m not going to want to wait for you to get up to speed in year. Do you really think you’re as good at any of those areas as a specialist? AWS alone announces dozens of new things every month on their podcast.
  - nscalf 7y ago

rco8786 7y ago

This is entirely company dependent. My team is primarily Ruby and we hire folks with no ruby experience all the time.

jfabre 7y ago
Because ruby programmers are rare nowadays and your company still need people to build software. At least, that's my assumption.
- eropple 7y ago
  They're not rare. I know a ton and many still write Ruby. Willingness to work on brownfield Ruby projects is rare; as with other similar systems like Django or roll-your-own Express stuff, such systems strongly tend towards chaos and a lack of maintainability after a certain point if they haven’t already had strong leadership end-to-end. In my neck of the woods, the folks who you want doing that work don't want to do that work anymore. Unless you pay a lot.
  - Supermancho 7y ago
    > They're not rare Depends on how you define rare. Exceedingly uncommon at the very least. stares at a pile of 150 resumes Ruby is a language languishing from being embedded in a few niches, having poor performance, and otherwise being unremarkable, imo. Ruby was made with the idea that picking it up would be easy (which it is), leading to less incentive to learn it. Putting Ruby in the job description gives you applicants with Ruby experience, which is why the blog post was (and is) impractical. Signaling works.
    - eropple 7y ago
      Calling Ruby "unremarkable" is a significant understatement, I think. For my money nothing in common usage approaches the same kinds of metaprogramming and solving-a-category-of-problems-at-once nature of a really comfortable and dynamic Lisp as does Ruby. (Clojure isn't in common use.) I get that that's not what you want, you want somebody to close tickets, but that's not Ruby's fault. And most of the people I know still working in Ruby are at a level where that kind of grunt work just isn't worth their time; most others have, of course, moved on.

codegeek 7y ago

I run a small company and I m looking for Web Developers. We primarily use PHP and getting into Golang but I really dont care about the language since what matters is concepts and experience with html/css/js http requests/response, client server architecture, database/CRUD, REST API etc. So i m not one of those employers :)

thestepafter 7y ago
Same here, hire the person, treat them well, and the language doesn’t matter as long as they have experience in similar languages.

srazzaque 7y ago

I agree with you, it's not how technical people are hired. But, I think it's entirely necessary in certain contexts, once we realise the software world is bigger than just Web. Learning languages and libraries is easy. But new paradigms, domains, and entire new ways of thinking? It takes time to master. So I'd be inclined to add disclaimers to the idea that "after 6 to 12 months nobody will ever notice". This might be the true if you're moving from 1 web programming gig to another web programming gig, but the author himself acknowledges the vastness of software out there that underpins every aspect of industry. So - if you're going to be working on enterprise middleware in investment banks, or embedded systems on airplane simulation kit, or APL, or missile guidance software - but all you've done is web... then tech stack does matter. Insofar as being familiar with the paradigms, standard patterns and unique industry norms. The problem is that some middlemen (ie recruiters, HR or non-technical hiring managers) do not understand that, for instance, Java and C# are somewhat interchangeable, but C# and APL are not. Fantastically written piece in all though, lots of great stuff in there that I wish I had either known (or stopped denying!) earlier in my career. But specifically on this point I think it's a dangerous idea to imply to undergrads that deep, hard-earned experience in both tech and domain can be overcome in such small time scales.

enraged_camel 7y ago
>>Learning languages and libraries is easy. But new paradigms, domains, and entire new ways of thinking? It takes time to master. Here's why I think this is sometimes a false dichotomy: going from Ruby to Python will be relatively easy. Going from Ruby to Haskell, on the other hand, will involve not just learning Haskell the language (syntax etc.) but also new paradigms and entire new ways of thinking.

Consultant32452 7y ago

It's also not true with respect to people noticing what you've been doing with your career. A programming language isn't just a language, it's also a culture. I've been writing Java professionally for almost 20 years. I can definitely tell when a person isn't a "java programmer." I am struggling to describe exactly what I mean, but the best metaphor I can come up with is it's kind of like hearing someone speak with a heavy accent. It can all be technically correct, the grammar is perfect, but you can still tell it's not native. Sometimes this is good. It can bring in new/interesting/helpful ways of thinking about problems to come up with better solutions. Sometimes it's bad because anything that's a little jarring or unusual impedes support and maintenance by "native programmers" in the same way a heavy accent can impede communication.

jghn 7y ago

It's the first thing some hiring managers look at. Speaking for myself as a hiring manager I'm not looking for specific tech stacks. I'm looking for general patterns. Someone who has spent their entire career doing front end work is unlikely to be a great fit for embedded development and vice versa, but I don't care so much about the specific technologies they used in the process. My experience has been that concepts and fundamentals trump specific tech stacks. However I also take a longer range view of things. I care far less about relative productivity of two candidates a month from now than I do a year from now.

scarface74 7y ago
Until your customer needs a feature a month from now and not a year from now or you only have a six month runway....
- jghn 7y ago
  The percentage of hires for companies in that situation is going to be extremely small, yet the "hire for tech stack" motif is cargo culted throughout the industry.
  - scarface74 7y ago
    Why else would most companies have open reqs if they don’t see a need for man power soon unless you are one of the four or five big tech companies that are trying to accumulate smart people (tm)?
    - jghn 7y ago
      Because they project for incoming needs. Hiring for today’s needs is a fools errand, it can take a good amount of time to identify a quality candidate. If I need something filled right ie or the company goes under it is already too late.
- jammygit 7y ago
  Doesn’t brooks say that adding manpower to an already late project makes the project later?

dleslie 7y ago

> The stack they are using seems to be the first thing hiring managers look at. I try to avoid companies that hire in this manner; it shows a lack of vision and planning. It's unlikely that a given developer will be working on the same stack in five years; the stack will have evolved or the developer will have moved on.

scarface74 7y ago
That’s kind of why you do want people who know the stack. If you as the manager or you expect the developer to move on with three years. Why waste a year getting a developer up to speed without having anything to show for it?

pcmoney 7y ago

I would argue that it is the first thing a manager looking for a cost center, cog type engineer looks at. They are not looking for an engineer who actually understands business they are looking for a “ plumbing engineer” that just keeps their head down and grinds out code. There is little upside in this position and this type hiring manager mentality should filter those jobs out for you. I do agree that most start ups will probably restrict them selves to hiring in the same stack as their tolerance for learning curves will be extremely short. However, I feel that many employers are used to engineers who don’t “get business” and so they just want somebody to plunk down code. This leads them to “what kind of dumb cog/stack are you?” questions as they are already assuming they won’t be able to hire a truly “full stack” engineer who understands the revenues and costs associated with their work and how they impact corporate strategy etc.

JMTQp8lwXL 7y ago

Stack is relevant though. If you need a front-end architect, and you hire someone with 10+ years Java experience, they aren't going to know the first thing about web accessibility, polyfills, bundlers, cross-browser support, etc. The domains of implementing microservices vs. writing front end code are fundamentally driven by very different problems. The stack an engineer has experience with can be one indicator of the areas they excel in.

throwaway981211 7y ago
Is this the right way to hire? Not saying it’s wrong but I’ve taken a different approach which has generally worked out. Even if I was hiring for a specific role (front end), I care less about familiarity with specific bundlers or frameworks and something more like - “Can this person problem solve and deal with varying levels of ambiguity? Do they seem capable of figuring something out without a ton of direction?”
- mcv 7y ago
  That is exactly the thing I select for. I recently had to hire 4 developers, and I was not all that interested in how many years of experience they had in javascript or typescript (our main language), and even less if you know Vue or Express (our stack). I mean, it's good to know javascript, and certainly ES6 or typescript, but I'm much more interested in: can I discuss stuff with you, do you have interesting opinions, can you make clear decisions in the face of unclear requirements, are you creative, and can you fix stuff and build features without anyone having to hold your hand? In case of doubt, knowledge of ES6 or Typescript or any relevant front-end framework (Vue, Angular or React) can make a lot of difference, but I'd rather hire someone who knows a dozen languages we don't use than someone who only knows exactly the one language we do use.
  - scarface74 7y ago
    And then when you need to ship now you have a bunch of dead weight while you wait for them to ramp up. Also, since now you are taking time from your devs who do know the stack to mentor your new hires and code reviews because you can’t trust them to do good work without messing up your code base. They are now doing “negative work”.

RhodesianHunter 7y ago

> In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career. I think this is only true if what you're working on is simple, like crud apps. It takes longer to be intimately familiar with a language's concurrency model, pros and cons of major libraries and frameworks and the ability to make such decisions quickly and without learning hurdles, etc.

furyofantares 7y ago
In my experience folks can be reasonably productive essentially immediately in a language they've never touched if they're diving into an existing code base. Give them a machine that's already set up like the other developers, point them at a couple easy bugs or features, do some code reviews, and yes they'll be slightly slower through this process than someone that's already familiar with the stack, but not much.

fimdomeio 7y ago

I'm not in the usual hiring circuit but went to one or two interviews for having a feel for that world. I always had the attitude of being the guy who will learn whatever is needed to successfully finish the task at hand, and I have work to show for it. It's amazing how's that was worth nothing for people that interviewed me, compared with how many years of react experience I had.

HerrmannM 7y ago
Sort of same kind of experience. I presented myself as a problem solver, with algorithmic skills and a deep understanding of language's principles as this is my research area... "Sure, but can you do python" Well, I definitely can learn it. But can I do it right their, right now? I never really worked in python, so no. And so... no.

avip 7y ago

First, developers rarely become tech fluent in 6-12 months. Second, startups don't have 6-12 months.

jarjoura 7y ago

Point taken, but the language is not the thing I would hire for anyway. It's the environment and skill-set beyond the language. A mobile developer even requires a completely different set of instincts to be successful than an engineer who's got work experience building scalable backend systems. C++ running across 1000 inter-connected systems is not the same C++ compiled down to run on a gaming console with limited CPU cycles to spare. C++ shared across iOS and Android is also different because Android requires that you bridge the library across Java and iOS may require an Obj-C layer if you're in Swift. If you spent your whole career writing code in Python and you wanted your next job on iOS, my concern wouldn't be, can you learn Swift in a short time. My concern would start at something as simple as how you would cache data when the network connection times out. Or can you manage your data models in a way that can maintain 60fps scrolling, something iOS engineers pride themselves in achieving. Of course all of this can be learned, but my point is that it's more than the language.

shubhambattoo 7y ago

Exactly what I thought when I read this paragraph. But still some CTOs are willing to let the team take time to learn a new stack and that in the end helps the organization (was part of one).

the_watcher 7y ago

The point is to acknowledge that the way most technical people are hired isn't the way that maximizes outcomes for technical people. Patio11's point is that the way to maximize outcomes as a technical employee is to _break out_ of this paradigm. It might reduce some of your top of funnel (random recruiter outreach) options, but it will increase the value of the opportunities that do arise.

james_s_tayler 7y ago

It's not even just start-ups. Established companies work the same way. Getting pidgeon-holed is a very real and common phenomenon. It's also kind of silly in a lot of cases too. It always feels like "Oh I see you do Angular... but could you _really_ be capable of developing in React? I don't know..." So retarded. Yet this attitude seems to dominate.