4 ms·

I don't believe this is the question you should be asking. Your worth as an engineer, over time, will be measured by breadth, not depth. I know engineers that

I don't believe this is the question you should be asking. Your worth as an engineer, over time, will be measured by breadth, not depth. I know engineers that have be come industry-class experts on font rendering or compiler optimization. You know what happens? It's tough for them to switch jobs. For the most part this industry, at the most successful end, values rock solid fundamentals and versatility. Your co-worker's path is dangerous. Replace "Microsoft" with "COBOL" or "Fortran" or "Mainframe" and you'll see that this is a problem. At this stage of your career, you should be focused on learning how _software works_, not a particular stack. Stacks come and go, rapidly. Technology changes. But software and how it works doesn't change all that much. So pick the right tool for the job and build your skills portfolio. Write some iOS apps. Write some browser-apps backed by Node, or Go. Write some client apps, build some APIs. I will say, however, that if you are interested in startup stuff I'd recommend against the MS stack. My company is partly on MS, partly not, and the licensing issues with Windows become painful very quickly just for flexibility. Windows licensing and things like Vagrant don't get along very well if you want to have N flavors of a VM and use them at will. There are other reasons here but I'll tell you that Linux machines are just a lot easier to manage in general, and I'm historically a Windows guy (I worked at Microsoft for a _long_ time). You're still in that stage where you don't know what you don't know. You're not choosing a wife or a house here, just go play the stack field.

gumby 12y ago
I agree with your point overall but disagree with one point: >Your co-worker's path is dangerous. Replace "Microsoft" with "COBOL" or "Fortran" or "Mainframe" and you'll see that this is a problem. The coworker is described as being "in his fifties." It's probably not unreasonable at that point to have significant depth in a single ecosystem. COBOL was exactly the case I was thinking of: very few (if any) new COBOL programmers are being minted any more and there is still a lot of legacy code. It will probably be a good, if dull, career for the next 20 years for that coworker who will at the end be able to write his own ticket to fit around his almost-retired status. For someone with 40-50 years of working life ahead of him/her, this sort of specialization is indeed premature and dangerous. For me that kind of specialization has never been attractive, an attitude that has served me well. But that's not true for everyone, at every stage of life.
- okatsu 12y ago
  To be fair, COBOL stopped evolving a long time ago, while .NET hasn't. He's in his fifties, but he's not working on legacy code; he grew up with the tip of Microsoft's technology. For example, he has pet projects on Azure and just completed a project at work in .NET 4.5 and Entity Framework 6. Sure, it's still a lock-in, and potentially dangerous, but nowhere near as COBOL or Fortran.
  - shawnb576 12y ago
    Yep, you've got it. So my point was directed against pre/chosen specialization for more junior engineers. I should say that some level of specialization over time is natural. At some point you'll likely work on one thing for an extended period of time, and you'll build a bunch of domain knowledge. In my case, I'm fairly biased against developers who frame their skills in relation to a specific technology - .NET Software Developer, Java Software Developer, iOS Software Developer. I really want people who think of themselves as Software Developers first and don't worry too much about the stack/domain. See: Software Athletes.

gumby 12y ago

I agree with your point overall but disagree with one point: >Your co-worker's path is dangerous. Replace "Microsoft" with "COBOL" or "Fortran" or "Mainframe" and you'll see that this is a problem. The coworker is described as being "in his fifties." It's probably not unreasonable at that point to have significant depth in a single ecosystem. COBOL was exactly the case I was thinking of: very few (if any) new COBOL programmers are being minted any more and there is still a lot of legacy code. It will probably be a good, if dull, career for the next 20 years for that coworker who will at the end be able to write his own ticket to fit around his almost-retired status. For someone with 40-50 years of working life ahead of him/her, this sort of specialization is indeed premature and dangerous. For me that kind of specialization has never been attractive, an attitude that has served me well. But that's not true for everyone, at every stage of life.

okatsu 12y ago
To be fair, COBOL stopped evolving a long time ago, while .NET hasn't. He's in his fifties, but he's not working on legacy code; he grew up with the tip of Microsoft's technology. For example, he has pet projects on Azure and just completed a project at work in .NET 4.5 and Entity Framework 6. Sure, it's still a lock-in, and potentially dangerous, but nowhere near as COBOL or Fortran.
- shawnb576 12y ago
  Yep, you've got it. So my point was directed against pre/chosen specialization for more junior engineers. I should say that some level of specialization over time is natural. At some point you'll likely work on one thing for an extended period of time, and you'll build a bunch of domain knowledge. In my case, I'm fairly biased against developers who frame their skills in relation to a specific technology - .NET Software Developer, Java Software Developer, iOS Software Developer. I really want people who think of themselves as Software Developers first and don't worry too much about the stack/domain. See: Software Athletes.