3 ms·
> But you have to consider all the baggage that a new job comes with. Like compounding comp increases? Honestly, most software jobs, even "tough" ones with lo
by drewcoo 4y ago
> But you have to consider all the baggage that a new job comes with.
Like compounding comp increases?
Honestly, most software jobs, even "tough" ones with lots of domain knowledge are bullshit.
It's very easy to jump into a new job and immediately be "highly effective."
Sorry you didn't figure this out yet, but those traits can be taught. You are not a lost cause.
- razmooo 4y ago> Honestly, most software jobs, even "tough" ones with lots of domain knowledge are bullshit. I agree 100% with this. If you are staying long time at a big corporation, you will eventually become an expert in the domain you are covering. Now, sure you can transfer some experiences to other companies, but mostly the domain knowledge is worthless outside of the company.
- rightbyte 4y agoAnd yet, ironically, other companies value you more then you current employer.
- galdosdi 4y agoIt's because the increasing returns to experience cut both ways and cancel each other out. You're more valuable to your employer after you've been there a while, but the job is more valuable to you too, for the same reasons (assuming things are going well for both parties). You'd be a lot more reluctant to risk switching to a higher paying job from a job you've only been at happily for a month than one you've been at happily for several years.
- mateo411 4y agoIt's a good idea to stay in the same industry, then a lot of the domain knowledge will still be relevant. I think you can do very well if you are a developer and you are a domain expert in a particular industry.
- psi75 4y agoNo, 'zuhayeer is right. For anything beyond the Scrum rent-a-jobs you should be outgrowing in your first five years, being liked is more important than being highly effective. You can be great at your job, but if you fail the politics, the best-case scenario is that you get assigned more grunt work. I don't like that it's that way, but enough people are inherently corrupt that castle intrigue outweighs competence. So, every time you change jobs, you're rolling the dice on a new set of strangers. That doesn't mean, of course, that changing jobs is never the right move. Clearly, it often is. If there's a re-org and you're not promoted, you should probably leave--you're going to have to prove yourself to a new set of people either way, so you might as well get paid for it. As for the comp increases, this is tricky. If you're increasing your salary but not getting promoted, you're actually putting yourself first in line for layoffs in the future, because HR people are going to see you as anomalously expensive within a band. This strategy can pay off, especially because 99% of corporates are too dumb to assess performance correctly and so often you can improve your perceived performance by becoming more expensive--but you have to be sure you're getting yourself a better position in the pecking order, or otherwise you're going to end up in a career cul-de-sac. Also, the job-hopper stigma is real. It isn't right, but if you have three or more jobs under 18 months, people are going to assume you keep getting fired for performance or, worse yet, keep getting fired because you're disabled... neither of which they'll touch. The last thing I want to advocate for is corporate loyalty. They aren't loyal to you, and so you should always have your eyes open and be ready to take everything that isn't nailed down (within the confines of enforceable law, of course) and jump. However, you have to be strategic. Remember that these people are a lot more skilled at screwing people like you than you are at screwing them--that's just how capitalism works.
- beckingz 4y agoYou have to be liked and effective, or at least appear effective. Or maybe I've just seen people get burned by spending too much time trying to get people to like them.
- dragonelite 4y agoIts not that hard, the core of programming is the code-debug-fix cycle. That is something people can take with them no matter the job or the programming language. Pretty much comes down to where to put break point, print statements or how to setup traceable logging when working in multi services landscape. Knowing this cycle well you're already effective when starting a new job. Want to start even faster keep your tools limited and multi platform, lets just say your tool set shouldn't exceed a post-it note using big letter sizes. The rest is domain knowledge something you will pick up over the coming months or years from colleagues and be paying attention at refinements and other meetings. This is mostly about software development jobs/gigs, if you're doing some STEM job in nuclear reactor design etc then yeah thats a completely different story.
- deleted 4y ago[deleted]