IssueRaiser

I think the paragraph on an antifragile career is probably the most important part.

I think the paragraph on an antifragile career is probably the most important part. Most people can probably intuitively realize that used (and repaired) software is likely to be more correct. Frequently switching jobs has the possible stigma of "job-hopping", and it's hard _for the individual_. Staying in the same technical stack is the fastest way to become irrelevant I can imagine. I've seen what it is like to switch everything up every few years (4 different tech stacks in 4 jobs), and the experience gained is invaluable. The best part is seeing everything you knew from before change, except that parts that actually are beneficial. It's funny how much of a tech stack is either cargo culting or in response to a local pain point. Learning to distinguish those gives you a sharp eye, both for possible other fixes locally and for strategic direction changes. It takes one critical ingredient though: you. You must have the humility and maturity to realize YOU ARE NOT YOUR CODE. If you want to go to a company, learn all they know, and leave, you must be comfortable being wrong, listening a lot, and keeping an open mind. Every time you make fun of a local company's choices (even if they are badly made), you'll isolate yourself more, and they will be less likely to bother explaining the next thing you are stuck on. Remember, don't complain, just build. And whatever you do, STOP CARING ABOUT CODE FORMATTING STYLES. If you care, you'll hate every one but your "first", and you'll spend your entire social capital at each job trying to change theirs to match your favorite. Which is just about the stupidest thing you could do.

Posted by JackMorgan on Jun 9, 2014, 10:22 AM

Tags

Related issues

Raise real-world problems, find people facing the same issue, and discuss solutions.9,500 issues0 comments

complaint (SaaS)

I think the paragraph on an antifragile career is probably the most important part.

JackMorganJun 9, 2014, 10:22 AM

I think the paragraph on an antifragile career is probably the most important part. Most people can probably intuitively realize that used (and repaired) software is likely to be more correct. Frequently switching jobs has the possible stigma of "job-hopping", and it's hard _for the individual_. Staying in the same technical stack is the fastest way to become irrelevant I can imagine. I've seen what it is like to switch everything up every few years (4 different tech stacks in 4 jobs), and the experience gained is invaluable. The best part is seeing everything you knew from before change, except that parts that actually are beneficial. It's funny how much of a tech stack is either cargo culting or in response to a local pain point. Learning to distinguish those gives you a sharp eye, both for possible other fixes locally and for strategic direction changes. It takes one critical ingredient though: you. You must have the humility and maturity to realize YOU ARE NOT YOUR CODE. If you want to go to a company, learn all they know, and leave, you must be comfortable being wrong, listening a lot, and keeping an open mind. Every time you make fun of a local company's choices (even if they are badly made), you'll isolate yourself more, and they will be less likely to bother explaining the next thing you are stuck on. Remember, don't complain, just build. And whatever you do, STOP CARING ABOUT CODE FORMATTING STYLES. If you care, you'll hate every one but your "first", and you'll spend your entire social capital at each job trying to change theirs to match your favorite. Which is just about the stupidest thing you could do.

Comments (0)

No comments yet. Start the discussion.

Comment on this issue