[rtikulit]

My formula for success is similar.

  1. Be good at your job (aka write good code).
  2. Be easy to work with.
  3. Be a member of the prevailing tribe.
  4. Be charismatic.

With all four, you're a superstar. Any three, great career. Any two, average career. Just one, unstable employment.

Only one is directly functional, three can be trained to some degree, and one can be faked adequately if absolutely necessary, but it can be mentally unhealthy.

If you don't understand why you aren't getting ahead, apply this model and train a weak category. I came up with this 30 years ago when a young man with limited skills and experience asked me “how do I succeed?” and I was looking for universal factors.

It also shows how to have a great career while being bad at the job. Oh, and it doesn't cover sociopathic strategies. :-)

[ChuckNorris89]

Your formula of success has many truths in it but missed a few big and important ones:

  5. Be in a hot area with many opportunities you can leverage. Being a rockstar is not enough if there aren't many employers bidding for your expertise.

  6. Market yourself and have visibility to your professional successes both inside your org and, ideally, outside as well, for others to spot your talent and approach you. Being a rockstar is insufficient if the results of your work are not visible up the org chart, to the guys who sign the pay cheques or to outside competitors.

  7. Have a network of contacts you can leverage. In my area, best jobs are gotten through connections. The open positions you find on LinkedIn are the bottom of the barrel left after the good spots got taken.

  8. Have up to date technical skills that match the demand of the market in your area. Being a rockstar is not gonna get you anywhere if you were a rockstar in an obsolete tech nobody needs anymore or has been offshored.

[rtikulit]

Those are great points. I have to think about how to incorporate them. I'm thinking that the four are still required to fully exploit the ones you've mentioned.

[tomerv]

I really prefer the original list, which is short and to the point. Your #5 is a subset of

    3. Be a member of the prevailing tribe.

Tribe can mean many things here, including: team, company, country, and I guess also gender and skin color (but there's not much you can do about that).

Same with #6 which is an expansion of being charismatic.

[lazyant]

You can be all 4 things but if nobody knows about your work, you won't get promoted etc. I'd insert after 1. being good at your job and 2. being easy to work with (I'd probably reverse these two) to "toot your own horn" or promote yourself or "be visible". In a way this can be related or included into your 3 tribe or 4 charisma.

[nunorbatista]

Good insights. Thinking back, this is the formula that worked well for me in the last 5 years. Lacking no. 2 was the one that brought me problems in the past but I managed to fix that. It was a very expensive learning.

The issue I have now is with no. 3. I just can't be part of the tribe I'm in right now and believe me I tried. I care about my colleagues, even the ones that are harder to work with, but although I like the overall mission of the company, the mediocrity is real and I just can't get on this boat.

I've been told I'm charismatic and this has been an advantage, but I recognize this is not something everyone can just decide to be. Social skills are a long learning process and I often think back at my young days working at the pizza restaurant as a place where I learned the most at this level.

I honestly believe the no. 3 is the harder one to grasp because it's the only one that it's not depending on you: you can work on all the other points (i.e. be a better dev, work on how you accept feedback or how you work on your charisma), but at the end of the day, if you can't get behind the values of the tribe, the only option you have is to fake it. This is what I've been doing.

[ravenstine]

> [...] write good code.

When people say this, I don't know what they mean.

What makes code "good"? Everyone's answer is different, other than that perhaps most of us agree on things like YAGNI, DRY, and KISS... more or less.

I'm not even sure that any version of "good" code is all that influential on one's career. It should probably be #4 on your list rather than #1. Most people would rather with work with a charismatic team player who's easy to work with whose code is adequate over a 10x developer who's a jerk.

This isn't to say that good code (in the abstract sense) isn't important or that writing good code isn't a part of one's success; if your code is really bad then you're way more likely to be let go from your job. But for a likeable person, is it really so important that they write good code rather than adequate code? Maybe. I kind of think not, but mileages may vary.

[theamk]

It is hard to define "good" code in general case, but in the specific case of discussing engineer's employment in a specific organization, the answer is pretty simple:

"good" code is the code that you peers consider "good".

That could be because the engineer is writing the code which conforms to all style guides and uses the principles that existing codebase uses; or, in some places, this could be because engineer writes code which performs exceptionally well; or, in other places, this could be because engineer writes code very fast (you probably want to avoid those).

[unoti]

> [...] write good code.

> When people say this, I don't know what they mean.

Code does something for the business (or for the customer). Good code both does what the business needs, but is also possible to quickly and easily modify and extend as the needs of the business change.

These two characteristics, that the code should fulfill the needs of the business and also be able to grow, imply a number of other characteristics of good code. It should be easy to read so you can scale the developer force up and down easily. It should be testable, to facilitate rapid changes and health within the code base.

On the operations front, good code should have operational metrics and monitoring, so you can see that it's working well without digging too hard, and can see what areas need attention if any. It should operate in a reasonably trouble-free way, so you're focusing your time on what's next instead of problems caused in the past. Sometimes I hear of teams where the developers want to leave because they're continuously solving operational problems instead of doing feature development-- those teams should be working on rewriting/reworking their systems in a way that they operate trouble free, which is new development.

The goodness of code is determined by how well it serves its purposes-- both in the past as well as into the future.

Some of these these ideas and much more are well-covered in books such as "Clean Architecture" by Robert Martin.

[francisofascii]

Can anyone elaborate on what "Be a member of the prevailing tribe" means? Does that mean technology stack, culture, political leanings?

[smallerfish]

Contrarians and lone wolves can sometimes get promoted if they're truly brilliant, but otherwise will get passed over in favor of people who are more "engaged". If you're contrarian enough, leave the company and start your own, or find a company that fits your way of thinking. No sense in pushing rocks uphill.

[rtikulit]

Factors 2-4 are meant to be social. Anything functional is covered in 1.

I'm not in anyone's tribe and so I had to learn to not exhibit tribal signifiers at work, which I think gets me half a point?

[wcunning]

I would argue that it would cover most of those, but even possibly (in a bygone era) going to the same church as your boss, being part of the same country club, golfing with the right people on the weekends, etc.

[MobiusHorizons]

I understood it to mean any divisive issue where people behaved tribally. So any of the examples you gave might be fall into that category for a given employer. Another important one is company politics.

[Wiseacre]

Fit in with the company culture, assuming it is healthy.