Comment by tutufan
11 years ago
I've noticed over the course of my career a fairly severe corollary, which is that making the best technical choices for my employer can often be bad for me in the long run.
As an example, for about the last 10-15 years, I've tended to choose Python over C++, for projects where it seemed it would produce a better solution (e.g., cheaper/faster to implement, easier to maintain and alter, performance sufficient to the task at hand). Because Python is actually quite adequate these days for large swaths of the task space, this means that my Python chops are quite good, but that my C++ is a little rusty.
In itself, this isn't exactly a problem, but in an interview scenario, it can look quite bad. "How much template metaprogramming have you done lately?" "Not much." "So, you're more of a junior programmer then?" "No, I just haven't hit a problem lately that needed that, and I prefer not to introduce unneeded complexity and maintenance nightmares into my employer's codebase." "How much work with GDB automation?" "Very little, since the code I write pretty much just works." "Ah, so weakness with the debugger as well." Etc.
Not really sure what to do about this. I don't really want to write tens of thousands of lines of unnecessary C++ just to impress future employers. But I have to acknowledge that that's really how the rewards are set up.
This dynamic is part of why I feel like programmers should really just stop resisting the pull to move into management. You might think about programming as the most amazing thing ever, to be agonized over with a fine-toothed comb and the 'best tool for the job' elevated to a nigh-religious consideration, but to your employer, it's one line item on a budget.
It might be 'easier' in a certain sense, and possibly a way to optimize for your paycheck, but 'resisting the pull to move into management' for me is about wanting to do high quality engineering, having a sense of professionalism and pride in my work, and feeling good about what I'm doing at the end of the day, even if my management doesn't understand it fully. If I'm a "line item on a budget", I want to be the best damn line item I can be. I am an engineer.
You can do high-quality engineering in management. You're just doing it with other people's code, as well as your own if you choose to continue programming.
1 reply →
Rebrand yourself as a python developer.
I know you might not want to hear that, but you'll probably find much more enjoyable employment anyway.
Essentially, that's where I'm at, as a practical matter. But it feels wrong to be typecast that way, since I regard my C/C++ capabilities as being quite sharp as well. And it seems like knowing when to write 100 lines of Python instead of 1000 lines of C++ ought to be valued, rather than seen as more of a technical faux pas. (Hey, I can dream, can't I? :-)
Work for people who are more concerned with the business value you provide and how fast, and reliably you provide it, and who don't care about the details of what technology you use.
This often means being hired by the CEO and not the CTO.