3 ms·

This is the problem that you define yourself by your programming language/environment/OS of choice, versus just being a really good problem solver. See: http:/

This is the problem that you define yourself by your programming language/environment/OS of choice, versus just being a really good problem solver. See: http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/ http://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-pro... I would say don't call yourself a [Java|Javascript|C|C++] developer. If your career were a blog post, languages are more like a tag than a title. Contrast "I Solve Problems" with "I Only Solve Problems with PHP."

InclinedPlane 15y ago
That's a nice ideal but it doesn't work very well in practice. It takes an enormous investment to become an expert in any given technology stack, easily on the scale of attaining a college degree. When a restaurant needs a baker, or an executive chef, or a pastry chef they hire specifically, not generically. So does the tech industry. If a company has a rails stack and they need someone up and running quickly it does no good to say "I can do it, just give me a few weeks to get up to speed and a few months to get really good".
- Retric 15y ago
  Plenty of companies go for talent over niche. When you expect the average person to last 5+ years it's dangerous to only higher people that know exactly the stack you work with every day, because it narrows everyone focus and they ignore edge cases where it's really better to use some other tool.
  - InclinedPlane 15y ago
    Sure, but there are limits. If you have a company that is heavily focused on web dev, you are naturally going to want people who have web dev experience. Maybe you won't mind too much if someone with a lot of talent has a history with Python or PHP and your current systems are based on Rails, but you will probably be a lot more cautious if someone applies with a background in programming IBM/360 systems and knows nothing about html or the web? I do think it's important to hire on talent, but I think the other extreme of a super generic "computer-based problem solver" is very unrealistic. Not every company can afford the delay of bootstrapping someone into having expertise with the technologies the company uses.
untog 15y ago
I don't know, I think that everyone has a "go-to" language, and I don't think that's a reflection on ability to solve problems. After all, if I'm making a web site there really isn't a choice to make between Python, C#, Ruby, etc.- they're all going to do the job with almost identical ability. Doing it in a different language for the hell of it is definitely a fun learning experience, but if I have a client on the other side I'd rather get it done quickly.
lucisferre 15y ago
Not at all, where do I define myself by my programming language/environment? What I am saying is that language/environment is not a no-effect choice. It has an impact on productivity, efficiency and most importantly the clarity and (for lack of a better term) UX of the code left behind for others. The problem with your assertion is it assumes that all languages, tools, frameworks and environments are equal to the task. I am a really good problem solver (at least in my opinion) I just don't want to make the implementation of those solutions harder on myself than it has to be.
cek 15y ago
There may be a population of developers who can jump super-easily between tools/languages. But I think the population of developers who, simply because it's what they have spent the most time with, are more productive in one environment is larger. The OP is basically saying "I'm super comfortable & productive with the MS stack. It's been fun and good. Now I get to focus on something else. The change will be good for me." Nothing wrong with that.
- freehunter 15y ago
  >Nothing wrong with that. I think there is something wrong with it. Specifically the habit of people creating blog posts detailing why they are switching languages. Best case scenario, it sparks a discussion revolving around solutions to their perceived sticking points, and people grow richer from the discussion. Worst case scenario, critics of the language/framework who have never used it use the post as points for argument later on. Most often, though, it's a circlejerk between "I too am leaving this language! Take that, language creator!" and "Well you're just using the wrong language, you should use <insert flavor of the month>!". Then next week we get another post detailing how they're switching from that language, too. Every language has poor features that could fill a million blog posts. It doesn't mean those blog posts are productive.

InclinedPlane 15y ago

That's a nice ideal but it doesn't work very well in practice. It takes an enormous investment to become an expert in any given technology stack, easily on the scale of attaining a college degree. When a restaurant needs a baker, or an executive chef, or a pastry chef they hire specifically, not generically. So does the tech industry. If a company has a rails stack and they need someone up and running quickly it does no good to say "I can do it, just give me a few weeks to get up to speed and a few months to get really good".

Retric 15y ago
Plenty of companies go for talent over niche. When you expect the average person to last 5+ years it's dangerous to only higher people that know exactly the stack you work with every day, because it narrows everyone focus and they ignore edge cases where it's really better to use some other tool.
- InclinedPlane 15y ago
  Sure, but there are limits. If you have a company that is heavily focused on web dev, you are naturally going to want people who have web dev experience. Maybe you won't mind too much if someone with a lot of talent has a history with Python or PHP and your current systems are based on Rails, but you will probably be a lot more cautious if someone applies with a background in programming IBM/360 systems and knows nothing about html or the web? I do think it's important to hire on talent, but I think the other extreme of a super generic "computer-based problem solver" is very unrealistic. Not every company can afford the delay of bootstrapping someone into having expertise with the technologies the company uses.

untog 15y ago

I don't know, I think that everyone has a "go-to" language, and I don't think that's a reflection on ability to solve problems. After all, if I'm making a web site there really isn't a choice to make between Python, C#, Ruby, etc.- they're all going to do the job with almost identical ability. Doing it in a different language for the hell of it is definitely a fun learning experience, but if I have a client on the other side I'd rather get it done quickly.

lucisferre 15y ago

Not at all, where do I define myself by my programming language/environment? What I am saying is that language/environment is not a no-effect choice. It has an impact on productivity, efficiency and most importantly the clarity and (for lack of a better term) UX of the code left behind for others. The problem with your assertion is it assumes that all languages, tools, frameworks and environments are equal to the task. I am a really good problem solver (at least in my opinion) I just don't want to make the implementation of those solutions harder on myself than it has to be.

cek 15y ago

There may be a population of developers who can jump super-easily between tools/languages. But I think the population of developers who, simply because it's what they have spent the most time with, are more productive in one environment is larger. The OP is basically saying "I'm super comfortable & productive with the MS stack. It's been fun and good. Now I get to focus on something else. The change will be good for me." Nothing wrong with that.

freehunter 15y ago
>Nothing wrong with that. I think there is something wrong with it. Specifically the habit of people creating blog posts detailing why they are switching languages. Best case scenario, it sparks a discussion revolving around solutions to their perceived sticking points, and people grow richer from the discussion. Worst case scenario, critics of the language/framework who have never used it use the post as points for argument later on. Most often, though, it's a circlejerk between "I too am leaving this language! Take that, language creator!" and "Well you're just using the wrong language, you should use <insert flavor of the month>!". Then next week we get another post detailing how they're switching from that language, too. Every language has poor features that could fill a million blog posts. It doesn't mean those blog posts are productive.