3 ms·

If you're at a big company and paid decently well, I suspect that you'll not have a problem finding an equivalent job sometime down the road. I had those conce

by daxfohl 10y ago

If you're at a big company and paid decently well, I suspect that you'll not have a problem finding an equivalent job sometime down the road. I had those concerns going into my own job search last year (plus at 40+, ageism) but found none of them were valid. All companies care about is whether you can code, and your ability to deliver. Still, sure, push for unit tests. Be careful though because everyone has a different idea of what a good unit test pattern is. You might paint yourself into a corner where you have to have 100% code coverage measured by some tool or mgmt sneers. Or dev time goes up temporarily and everyone blames you for it. Know the end game you're pushing for. Unit testing is a means, not an ends.

BeetleB 10y ago
>If you're at a big company and paid decently well, I suspect that you'll not have a problem finding an equivalent job sometime down the road. While I'm at a big company, the company is not highly regarded in the software world, which is my concern. And I don't have anything to show for it other than: Coding on a 1MLoc code base, with mostly business logic. Occasionally I run across cases where knowing something is O(N^2) matters, but only occasionally. I think a part of me just feels I should do slightly more challenging work, where either knowing algorithms well will help, or having some greater domain knowledge will help (e.g. Operating Systems, Parallel programming, graphics algorithms, embedded systems). As it is, I'm doing nothing that sets me apart. I suppose that's why I want to go more into the "influencing" realm. I suspect employers will care more for my ability to change important architectural decisions for a team of 30+ people - without having the authority to do so (I'm not the manager and cannot dictate to people). As for unit tests: I'm not too religious on it. I think it has value, but my experiences doing it in C++ also taught me that there are too many ways "to do it wrong" (i.e. make the code horrible) and only a few that will do it right. If I'm to convince the team to go that route, I need a way to ensure they "do it right" and not just do it any way they feel they should. My management feels the team in general doesn't have the ability to distinguish between the two and are pushing back. The victory for me wouldn't be that the code base will have unit tests. The criterion I'm setting for myself is: 1. Can I influence enough people to make this change? 2. Can I do it in a way that is not chaotic? I'm merely picking "unit tests" as the way to achieve those two.
- cr0sh 10y ago
  > I think a part of me just feels I should do slightly more challenging work, where either knowing algorithms well will help, or having some greater domain knowledge will help Is there anything preventing you from doing this in your free or spare time? Can you help out with an open-source codebase on github, for instance, or do you have an idea for a side project you could start and contribute toward? While it won't be something you can point to as a part of your "career", you can still leverage the experience provided its documented in some manner and you have something to show for it. Just consider it another part of your portfolio. For instance - in the domains you mention (operating systems, parallel programming, graphics algorithms, embedded systems) - there is one area which you can play around in at home which can encompass all of them (and much, much more). That area is robotics. For a single individual, its probably one of the most difficult domains to explore, because it literally can encompass so many sub-domains and experience levels, depending on how far you take it, and what kind of project or projects you decide to pursue. Not just on the software side, either - there'll be plenty of mucking around on the hardware side as well (you might even learn welding and CNC machining on the side - or, if you're ambitious, make your robotic project a CNC robotic welder!). There's also the fact that having such a side project (whatever it may be) can be a way of taking off the pressure of the day-to-day work you currently do. It can serve both as a hobby and a means to learn things you don't or can't learn in your current employment. As you develop the project, be sure to keep notes, and track of what you're doing, and put that info into your resume in some manner to illustrate what you know, what you learned, challenges faced and overcome, etc. It may ultimately lead to that better job you're envisioning. Worst case scenario, you end up learning a bunch of new skills which you can apply to future projects or a later position (or heck, maybe even your current one).
- daxfohl 10y ago
  No, you shouldn't feel the need to preemptively move to a "tech" company. Doing software at big tech companies isn't all that different from doing software at a non-tech company. Products are so big and diverse that you're usually contributing to a tiny little subset of some far flung feature. That said, the ceiling is certainly higher for top-tier developers. So, I wouldn't say you should take lower pay now just to get a foot in the door. But if you do get to the point where you're hitting a glass ceiling, then certainly make the jump. That's just the financial/career perspective. As far as how much you like the job / how much you contribute, well per my experience, the grass is always greener on the other side. When you're working on something small, you have greater influence on the product but the scope of the product itself isn't so great, and vice versa with big things (though of course there are some jobs that fail on both influence and scope). But ultimately your goals there are something you have to establish for yourself.

by daxfohl 10y ago

BeetleB 10y ago

>If you're at a big company and paid decently well, I suspect that you'll not have a problem finding an equivalent job sometime down the road. While I'm at a big company, the company is not highly regarded in the software world, which is my concern. And I don't have anything to show for it other than: Coding on a 1MLoc code base, with mostly business logic. Occasionally I run across cases where knowing something is O(N^2) matters, but only occasionally. I think a part of me just feels I should do slightly more challenging work, where either knowing algorithms well will help, or having some greater domain knowledge will help (e.g. Operating Systems, Parallel programming, graphics algorithms, embedded systems). As it is, I'm doing nothing that sets me apart. I suppose that's why I want to go more into the "influencing" realm. I suspect employers will care more for my ability to change important architectural decisions for a team of 30+ people - without having the authority to do so (I'm not the manager and cannot dictate to people). As for unit tests: I'm not too religious on it. I think it has value, but my experiences doing it in C++ also taught me that there are too many ways "to do it wrong" (i.e. make the code horrible) and only a few that will do it right. If I'm to convince the team to go that route, I need a way to ensure they "do it right" and not just do it any way they feel they should. My management feels the team in general doesn't have the ability to distinguish between the two and are pushing back. The victory for me wouldn't be that the code base will have unit tests. The criterion I'm setting for myself is: 1. Can I influence enough people to make this change? 2. Can I do it in a way that is not chaotic? I'm merely picking "unit tests" as the way to achieve those two.

cr0sh 10y ago
> I think a part of me just feels I should do slightly more challenging work, where either knowing algorithms well will help, or having some greater domain knowledge will help Is there anything preventing you from doing this in your free or spare time? Can you help out with an open-source codebase on github, for instance, or do you have an idea for a side project you could start and contribute toward? While it won't be something you can point to as a part of your "career", you can still leverage the experience provided its documented in some manner and you have something to show for it. Just consider it another part of your portfolio. For instance - in the domains you mention (operating systems, parallel programming, graphics algorithms, embedded systems) - there is one area which you can play around in at home which can encompass all of them (and much, much more). That area is robotics. For a single individual, its probably one of the most difficult domains to explore, because it literally can encompass so many sub-domains and experience levels, depending on how far you take it, and what kind of project or projects you decide to pursue. Not just on the software side, either - there'll be plenty of mucking around on the hardware side as well (you might even learn welding and CNC machining on the side - or, if you're ambitious, make your robotic project a CNC robotic welder!). There's also the fact that having such a side project (whatever it may be) can be a way of taking off the pressure of the day-to-day work you currently do. It can serve both as a hobby and a means to learn things you don't or can't learn in your current employment. As you develop the project, be sure to keep notes, and track of what you're doing, and put that info into your resume in some manner to illustrate what you know, what you learned, challenges faced and overcome, etc. It may ultimately lead to that better job you're envisioning. Worst case scenario, you end up learning a bunch of new skills which you can apply to future projects or a later position (or heck, maybe even your current one).
daxfohl 10y ago
No, you shouldn't feel the need to preemptively move to a "tech" company. Doing software at big tech companies isn't all that different from doing software at a non-tech company. Products are so big and diverse that you're usually contributing to a tiny little subset of some far flung feature. That said, the ceiling is certainly higher for top-tier developers. So, I wouldn't say you should take lower pay now just to get a foot in the door. But if you do get to the point where you're hitting a glass ceiling, then certainly make the jump. That's just the financial/career perspective. As far as how much you like the job / how much you contribute, well per my experience, the grass is always greener on the other side. When you're working on something small, you have greater influence on the product but the scope of the product itself isn't so great, and vice versa with big things (though of course there are some jobs that fail on both influence and scope). But ultimately your goals there are something you have to establish for yourself.