Your job satisfaction/pay are a function of your impact. Your impact is a function of your leverage.

If you're a "pure coder" who doesn't have any of the other skills you mentioned, your output is incredibly limited. At best, you produce a day's worth of code in a day, but you also require someone to manage you closely to make sure you code the right stuff.

The more of these other skills you have, the more you can (a) work independently (b) make others more productive and (c) make sure your team/business is doing the right things and (d) drive overall efficiency.

The more of these things you do, you become orders of magnitude more impactful than a pure coder.

One of the most important skills is the one he describes like this:

>> The more specialized your work, the greater the risk that you will communicate in ways that are incomprehensible to the uninitiated.

In my experience (35 years), this isn't just about knowing the right way to describe things, it's also understanding what things to concentrate on when communicating, and what to ignore. If you are a tech person communicating with a decision maker, they are typically looking to understand options and their implications and risks, not the details of how the options work. They can then decide, based on their (presumably) better knowledge of the wider context, which options to select. If the decision makers are genuinely intelligent and motivated, but their eyes glaze over when you describe something, chances are you have chosen the wrong things to communicate to them.

[o] https://news.ycombinator.com/item?id=25650535

They won't be doing it, they will be doing a simulation of it. How are they going to learn business communication without doing it in the context of a real business with a real P/L line and real consequences for good and bad execution?

It appears that they key skill is coordinating a lot of developers, because the ones left developing are the ones you need a lot of (and who need close supervision) to get anything done. Managers will never rock this boat, because their career KPI is the number of people they manage.

Which is not to say they're doing everything right.

Relevant: https://www.spakhm.com/p/parallel-tracks

"Why did all major software companies settle on parallel career tracks? To keep engineering managers from developing loyalty to engineers."

Having no track even better. Some people like what they are doing and the field is constantly changing. You want your best surgeons doing operations not managing other doctors.

You need some kind of title so people can feel responsible for career growth and so you can calibrate against other companies' pay at least; it doesn't need to control what kind of work you're allowed to do.

And, as you say, to the degree that position titles mean something cross-company, it gives a point of comparison.

This seems to miss the point of teams. Everyone should have a role if you hire someone as a software engineer and they spend all their time doing devops because they like it more you've made a bad hire. If all your engineers are having product meetings with various departments then you've again made bad hires. Everyone should have their role and fullfill that role to work as a successful team. People thinking they're above fullfilling the role they were hired for is one of the fast ways to have a poor performant team. To put this into sports you don't want your defender to be constantly hanging around the other team's goal mouth.

Individual coders/contributors' compensation don't scale until they are shown to "score a goal". And yet, to do so, they may have to stop contributing in their usual, assigned role, but go "above and beyond" - such as redesigning the system, or to make their mark on the product and be recognized as such.

This, i find, is probably what the fundamental problem/friction with teams are.

Your job satisfaction/pay are also a function of how unique your skillset is.

With this in mind, increasing your impact (through soft skills) is just one of two ways to increase pay - the other way is to do something that not many others can do. For many people, doing something unique is far more satisfying than dealing with people problems.

These are not mutually exclusive. If you want to accomplish big unique things, you can't do it yourself. You are going to have to convince others that your big new idea is worth doing so that they will help you achieve it.

I'm skeptical. I mean, sure, for most people, the ability to convince a large number of other people to do things, to do your things, without worrying how they do it, is going to have more impact than any other contribution they could make.

On the other hand, Van Jacobson's algorithm is like four lines of code (I used to know where it is in *TCP/IP Illustrated, Vol II.) and is responsible for the Internet as we know it. That's an awful lot of impact.

Effective software engineering in a business context requires awareness of business needs.

Which part of that is “bashing and shit talking”?

Effective software engineering in a business context requires awareness of business needs as well as the technical skills to address those needs.

I've sat through dumb two hour meetings about deciding which words in a document should be capitalized. Is that what is meant by "make sure your team/business is doing the right things?"

I agree with what you're saying in part. Pure coding skills are essential, especially in critical situations like that. Soft skills won't fix broken things, for example. Salespeople can't deliver the features they promise without someone to develop them.

However, soft skills can help someone with excellent coding skills to know what to apply their skills to and when, and how to integrate their skills within a broad team of different disciplines.

This is arguably true in any field; I think it's often missed in software development because people have such a difficult time distinguishing boundaries of things. The problems you're solving, when you're passively or actively solving problems, when output is applicable to a specific problem, etc. Even software engineers themselves struggle with this.

Your ability to save your company's ass is an excellent skill to have, but it isn't directly related or exclusive to what the original comment was saying.

When I saved my company's ass those times, no non-technical people were present and it was wholly technical knowledge that solved it. I could have and probably should have ignored the problems and let the talkers try to fix it and take the blame for millions in losses. So it is very apropos to the original comment.

Even though it sounds good, this is actually a bad measure because all coding consists of constantly making new zillion-dollar mistakes and then fixing them as you go. You can always do a worse job, and if we're supposed to be impressed by you visibly fixing something, then mess up and fix you will.

The tech is generally easy in commercial coding. There is usually a definitive answer, and if not then the trade-offs are generally well-known. It's rare to run into a problem that requires complex technical knowledge, and in those cases it's fine to hire a consultant to help.

But the people problems are hard. Getting clued-up on these is important.

I think an MBA will help you be a better manager if you want to be, because at least there's some clue about what a "good" manager should look like.

I've met sooo many bad managers. In most cases they were bad because they didn't really know what they were doing and they felt they couldn't look "weak" or not be in charge. There's always the urge to authoritarian leadership because it's the default (for some reason).

If the MBA course is any good, it will at least have exposed such a person to other leadership styles and some management theory. They might reject it, of course, but at least they'll know it.

So, yeah, I don't think having an MBA makes you a better manager or leader automatically. But I think a manager who wants to get better could be helped by doing an MBA.

Of course, there are lots of managers who are convinced they don't need to get better, and so won't/can't be helped. And there are lots of people who get MBA's because it's a ticket to promotion and don't really care about the learning.

I think even that part is disputed; we really don't know what a good manager looks like. Some of what's taught in MBA classes now is the opposite of what was previously taught, and there seem to be as many failure stories as success stories. I do take your point that maybe just thinking about anything other than the authoritarian mode is enough to raise a manager above the average, which is distressingly plausible.

I'm totally on board with highlighting the importance of communication, team work, people skills (and I've seen how awful it is to work with people who lack these skills despite their technical expertise), etc. but this statement I simply cannot agree with.

Everyone's experience is obviously different. Some people may work on problems where there are few legitimate technical challenges, or where they aren't solving any problems that haven't been solved before. That hasn't been my experience in most of the jobs I've had so far. There were significant architectural and sometimes even algorithmic challenges to be solved, and not solving them properly would mean either bugs or unmaintainable software.

ITT we talk about the importance of communication, but good coding patterns and architecture (as well as the right level of documentation) are part of communicating to other developers.

I get that, and I don't mean to suggest that some bits of this aren't tricky.

But with an architectural problem (for example), it's usually a choice between 2 or 3 options. We know what the options are, we know what the trade-offs are, we can make guesses on what we think the impacts will be. It's a "known known" problem, with usually enough time to research it fully. Implementing it properly can be difficult, but that's the kind of thing that can be iterated if necessary - we don't have to get that right first time.

There are lots of management and people problems where none of this is true and it's very much a "known unknown" that has to be got right on the first try, without knowing all the possible tradeoffs or consequences, and under time pressure.

No, I disagree. Some problems are truly novel (or maybe, there are just a handful of competitors and you obviously can't see their source code) and you just don't even know what kinds of solutions might exist. There might be bits and pieces in the research literature, but good luck even finding them, let alone understand if they are applicable. The space of possible technical and architectural solutions is infinite-dimensional, so it's not always a "known known" issue. There might be crazy solutions out there that you simply didn't think of.

Now, if it's about "create a CRUD interface to you e-commerce store", then I agree that the situation is more similar to what you described, but that's not what everyone is working on.

But in your previous post, you talked about architectural problems and there I disagree with you strongly.

Taken in isolation, individual technology pieces are relatively simple and easy to evaluate. But when you plug in one such piece into a middle of a larger system (let's say typical corporate IT landscape), then it becomes way more complex on all fronts. (Enterprise) architecture is also interfacing heavily with business decisions and company structure. You need to think a lot about how your ivory tower architecture will be actually used by the teams.

But if you get it wrong, what happens? You have to refactor (if you didn't get too far in), or start again if you did. No big deal - code is perfectly amenable to this.

But the political and social problems of "we got it wrong, we're going to have to start again from scratch" are the real problems. Dealing with a marketing manager who has a product launch scheduled for the 2nd quarter and you're about to tell them that you need to reschedule because you got the architecture wrong on the first try - that is a business problem not an architectural problem.

The tech problems get a lot easier if you have some kind of framework for dealing with the business problems.

This works nicely on a small scale, but not with the architectural problems.

> that is a business problem not an architectural problem

It's an architectural problem because this business constraint forces me to get the architecture right the first time - I won't get another chance.

There's no business reality where it's OK to say "just give me another 2 years to re-do the system in a (probably) better way".

But knowing how to frame that, and manage the expectations of the other people involved in that negotiation, and recognise their objectives and priorities, is a business skill.

And, y'know, if you spend 2 years building a system on the wrong architecture because you didn't know how to ask for more time to make a better decision in the first place... well, you need some management training ;)

And now back to your original claim. You need 3 months of prototyping only to reach a decision, but you still insist that it's an "easy" problem?

Then there's a problem that prototypes often don't uncover unknown unknowns. Investing effort into prototype improves your chances at arriving at correct solution but by no means guarantee it.

No it's not an "easy" problem - like I said, I get that these can be tricky. But in my 25+ years of commercial software experience, I've not bumped into one like this. I have bumped into complex technical problems, but the answers were/are always out there and findable. As I said, these kinds of problems are "known known" - you know what the problem is, there's a decent definition of what "good enough" is, and there's usually a lot of Comp Sci literature around to help.

Remember, this is in contrast to the people/business problems. For these, because they're involved the specific personalities involved, there is no definition of the problem (people will react to a situation according to their nature, and you can't check their source code). Often there is no good definition of what a good solution even looks like (except a broad "get everyone happy and working again" maybe). There is no literature describing the solution to the problem, or usually even addressing similar problems. And the problem always has a time limit - taking no action is seen as an action in its own right - and it's usually days at most. You literally have to make up some solution as you go along, not knowing if it's going to work or not. That's why I called these "unknown unknown" problems. In 25+ years of commercial software experience, I've bumped into at least a dozen of these (that's not including the "normal" run-of-the-mill management problems).

Your experience may vary - mine led me to conclude that the tech problems were not as difficult as the people problems, and that therefore I should get some training for the people problems.

For example: the network admin comes out as gay, starts having a relationship with someone on the night shift. The number of "emergency network outages" during the night shift suddenly spikes. A quiet word didn't seem to have any effect. The night shift supervisor is getting fed up of the disruption. Sacking the admin isn't an option. Sacking the nightshift worker isn't an option. Going down any kind of formal disciplinary process is the "nuclear" option as the company has to make absolutely sure it's not in breach of discrimination legislation. Ideally everyone would go back to work and be happy and the network would stop having problems at night (one of those where there is a well-defined "good result"). I didn't manage to solve this problem - the network manager ended up leaving in a huff (though thankfully not sueing us). I still to this day have no idea if I could have found a better solution to that problem. There is no technical problem that I've ever faced where I wonder 20 years later if I could have found a better solution (though plenty where a better solution has become available later).

If you want to get into management and deal with those kinds of people problems, then there are lots of management training courses around. An MBA is at the upper end of that range.

If you're having problems fitting into teams and getting along with people (actually quite common in dev teams), then maybe look at therapy or personal coaching. I spent a few years in therapy and it really helped.

If it's office politics and the like - some workplaces are toxic. I can't deal with those even with the training and experience. Life's too short to deal with that bullshit ;)

Perhaps read some books on negotiation if you have issues getting others to see your point of view.

Nervous about speaking in front of a group? Try Toastmasters once the world opens back up, or hire a coach.

Books are a good first resource once you identify the areas in which you want to grow.

But the real wins were the leadership and management units, to my mind. Learning the "formal" knowledge around this has really helped in subsequent management roles.

The entrepreneurship unit was vaguely hilarious, as I was running a blog for the local startup scene at the same time and neck-deep in Lean Startup, which no-one on the MBA course had heard of. Writing a really tight business plan seemed to be the hardest part of starting a business ;)

One of the really useful-but-unexpected things was having some kind of head-canon for "what a manager is and isn't" and (in one case) "what a CEO should actually be doing". It was really helpful having a kind of connect-the-dots picture of what should be happening and therefore what dots needed to be connected to make that picture happen.

If I want to be that consultant, what area would be a good choice to become proficient in on that level?

The more specific the niche, the less work you'll get but the higher you can charge for the work you do.

Get known as the expert in that niche. Write a blog on it, talk at conferences about it.

I don't know what areas would be good now, but I've hired consultants in scheduling problems, network setup and management, security, and recruitment.

If I had to pick an area that will never go out of style: security. Get good at being able to secure an online system and you'll never be hungry.

Many engineers move to management at this point, which requires that you can mentor and grow a team of engineers, set goals, drive projects to completion, and manage your team through performance reviews.

Folks who stick to the technical path need to become an indispensable piece of technical glue across N teams, keeping them all building in the right direction and not crushing each other. This job requires deep technical knowledge but often doesn't involve a ton of coding e.g. Linus Torvalds.

If a junior engineer showed up with the behavioral qualifications of Torvalds and the technical skill of a junior engineer - they would still be a junior engineer and unable to build trust, guide a team effort, or other activities.

Technical knowledge is still very important, and it's the basic foundation of being a software engineer, and maaaaannyyyyyy people out there don't even know the basics.

technical mastery advice doesn’t really need to be given at all.

i’m not saying the advice isn’t good, but also you have to read it like a self help book. it is a point of information, don’t take it literally.

This was exactly the experience I had not so long ago.

Management brought in a new "team leader" to "shake things up" with "new ideas."

She spent most of her time reading management books, taking online management courses, and going to management seminars. She almost never spoke to the "team," and when she did, treated us like underlings.

They gave her two years to make a difference, and then kicked her out in the first round of COVID cuts.

This is not just a junior problem. A lot of "people problems" seem to come from fighting over which stack to use. (and most people fight for whichever stack they are best at, to maximize their own personal contribution). I always spend a lot of time asking people what technology they would use to solve a particular problem, what technology they really don't like, etc. It saves a lot of trouble fighting over things if you get a team that is willing to go with a particular technical approach and is more important than most "cultural fit" issues.

I suppose it also depends on company culture. What happens if a technology you have never seen before is selected for your project? Are you given some time to learn and is it expected that your initial contributions will be smaller, or are you supposed to be just as fast as people who used it for last ten years and get negative reviews otherwise?

This is what FAANG interview generally look for so why is it a surprise that potential hires focus on it? Amazon literally says that you need to highlight all the leadership principles in the stories you tell when answering behavioral questions. Granted, FAANG barely asks behavioral questions for senior engineers (and then it's like 90% project and bureaucracy management) much less junior engineers.

edit: Amazon's goal isn't to be a nice place to work, it's to make a lot of money and everything else is secondary to that. They are so far succeeding splendidly at that goal across multiple verticals so arguably their approach works. I wouldn't want to work there myself but you can't argue with results.

It's come to a point where I kinda assume that they are likely to screw me/other people if I don't know otherwise.

(Obviously this is a generalisation, I'm sure there are loads of really nice people at Amazon).

Have Backbone; Disagree and Commit is specifically about NOT being a jerk who digs his heels in, and sabotages projects or decisions that they disagree with. Rather someone who is a team player and embraces the decisions of the group:

Are Right A Lot is about constantly questioning your own understanding and being CAPABLE of changing your mind. We literally interview for it by asking about a time your mind was changed on something important.

Ownership is about not saying "That's not my job". If there is some work to be done, and nobody's doing it, don't have a high and mighty attitude about it being beneath you. Just get it done. (e.g. Developers doing QA, Ops, Documentation, etc)

Bias For Action is about taking calculated risks.

Insist on the Highest Standards is the only one that I know jerks abuse.

[1] https://amazon.jobs/en/internal/principles

We have similar leadership principles with nicer names, although we don't use them to the point of bringing them up at meetings.

Mind you, there’s some of this in all interviewing, but from some people I’ve talked to, Amazon seems to really love these leadership stories.

But no, you don't need to memorize the leadership principles themselves, and your individual stories can't highlight ALL the leadership principles. Some of them are deliberately in conflict with another.

Maybe it's different when you interview at a FAANG company though? I imagine FAANG recruitment is a merciless sausage machine.

I'm growing further and further away from this mentality in hiring because the sad truth is most of those folks who come in with "quirks" lack maturity. To me, quirks are "yellow flags" in the interview stage because it means that you're not able to put your own weirdness aside to fit socially when you arguably need to the most. Invariably these same "quirks" come up down the road in the employment with output problems, copping attitude with superiors, weirdness in internal/external meetings, and just general antisocial behavior.

I get that we're all in hella demand right now but I'm starting to go back on my, "I'm just hiring for the engineering skill/talent" as an excuse to overlook yellow flags.

The other thing is contextually, what are the quirks? If the "quirk" is someone being super shy/timid it doesn't even register on my radar as a problem unless it's extreme... I'm talking about the stereotypical "oh so cute dev quirks" like: not dressing appropriately for an interview, interrupting me/talking over me, talking down to me, comparing their last junior position to being Steve Jobs, being sing-songy, inappropriate jokes in any way/shape/form, getting in arguments with themselves... etc etc.

I'm at a point that if you can't act 95% professional in your first interview you're done as you're not capable of being "on".

> interrupting me/talking over me, talking down to me, comparing their last junior position to being Steve Jobs, being sing-songy, inappropriate jokes in any way/shape/form, getting in arguments with themselves... etc etc.

Besides being "sing-songy", none of these things are quirks, they're ineffective communication or untruthfulness of their past positions.

As far as dress and "sing-songy" go, I would agree with the above poster: software development tends to be much more inclusive of these sorts of characteristics. Jeans and a T-shirt is perfectly acceptable attire for an interview. Do your software devs wear suits 5 days a week? Why expect a candidate to do so, either? A candidate I interviewed going, "uh-oh sphaghetti-oh!" when they hit a segfault when running their interviewing solution was kind of ridiculous, but ultimately has no impact on their contributions as a developer. Factoring in these kinds of thins into the hiring decisions is ultimately about including people from a culture similar to your own. Different cultures have different definitions of "weirdness" so selecting based on the ability of the candidate to identify what is "weirdness" is ultimately a cultural litmus test. And expecting male candidates to be shaved, as per your other comment, is just blatant cultural discrimination - some demographics like Sikhs could even sue you for illegal discrimination over this. This cuts both ways, both the case where a candidate in a T-shirt and jeans gets rejected for not wearing a suit and when a suited up candidate gets rejected for being too formal. Both ultimately hurt the company by excluding effective workers.

What is "dressing appropriately". I wore a suit to my very first interview for a dev position and very nearly didn't get the job because they were worried I wouldn't fit in (luckily I was able to explain that I don't usually wear a suit). The other ones in your list, sure. But I don't think those are what people typically means when they talk about quirks.

Yeah - I hate this. I had people at my last position give candidates negative points because they wore a suit and I went $%&#ing ape. In positions that I've held in the past it's been the appropriate action to wear a suit due to heavily corporate environments, and I see it as 110% normal that someone puts on a nice suit for an interview. The action of wearing a suit (or tie for that matter) to an interview should never be seen as a "cultural fit" problem - I'm looking at you SV...

Sorry that almost happened to you. That's some bullshit.

---

Overall a nice well-fitting button down + a pair of well-fitting dress slacks is what I would recommend. Personally, I wear a slim fit brand new white button-down (ironed), nice dark blue chinos (ironed, not pleated), and not-scuffed brown wing-tips. Often I also wear a tie, but am considering not thanks to a derelict SF "big-wig" grilling me in an interview as to "why are you wearing a tie?" All I wanted to say is "does it matter?" (offender: you're reading this don't do that again.)

Also get a solid hair cut, ensure you're shaved if male, and yeah - sit up and be confident while you're in the chair. Body language does matter, and your interviewer will subconsciously notice regardless if they're giving you a "pass" or not.

I would agree and would go as far to say that dress in general should never be a hiring criteria for a non-customer facing position. Unless there are hygiene issues or they are wearing something actively offensive.

In a lot of my engineering roles I have had to be internal/external facing and do things like budget presentations, work with partners, etc. Before that, I was a general web/app dev and we would get pulled along to client meetings all the time to collect spec, ensure that it was a good sales fit, etc. I'm not saying I had to be fully decked-out but being able to throw on a button down and tuck it in means that you "fit-in" to these situations.

For me, if someone is showing up in a t-shirt and jeans it's a red flag that you can't be bothered to dress semi-professionally which has been an occasional (but hard) requirement of me since day-1 of my career. 100% this all is anecdotal, and specific to my own needs/experiences.

Unfortunately, our industry has no such thing, so I always ask before an interview. So far the answer is always "uh, we just wear normal clothes", "casual is fine" or once "just wear clothes, please, this isn't quite Burning Man" (ended up working at the last place), but: this was in the Bay Area, so YMMV.

Dress code doesn't really factor for me, but I've worked for the same place for a while now and we've always been 95% remote. Half of us just wear whatever we slept in the night before. Most people don't get dressed until lunch time. Even in the office it doesn't get much fancier than a t-shirt and jeans. I guess our tech lead wears a button down shirt, but his jeans usually have giant holes in them, so I would call that a wash.

Expecting an interview candidate to wear something nice would feel a bit hypocritical.

It seems to me that you're making an assumption about what is considered professional dress. I feel like it's fine to have such expectations, but you should express them clearly in the invitation to interview. It's not a case of "not bothering" if you have never expressed that preference in the first place.

-- "Sasquatch"

If you're completely unsure, just call the hiring manager and ask. "What's the dress code at company X?", "How do people in role X normally dress at your company?". No one will be mad at you for making an effort and trying fit into the culture.

I sort of twigged that I was over dressed when on the way to the interview some one stopped me in the street and asked me the way to the "Ivy"

Yep, I’ve been that guy! Had huge problems for a while. Mercifully my team/department/business put up with me for the most part, but I did have to suffer for a while. Learnt some invaluable lessons though and I’m quite happy to be a fitter happier and more productive individual! (Yes Radiohead reference but really not as bad as it seems:)

My response from the other side of the table: as an interviewee, I view these initial interviews an an exercise in expectation management. I don't consider myself as weird, so I act like I normally would, otherwise I'm setting myself up for failure later on.

Also, I don't wear to an interview what I wouldn't be comfortable wearing on a normal working day. I dress casual on purpose (but representably casual, not weird casual -- but that's my personal opinion of course).

But the other things? Oh, yeah. I've worked with (or attempted to) people like that, and I won't do it again. The first time a technical difference of opinion turns into a suicide threat, I'll just clean out my desk on my way out.

An interesting experience I had at a previous company was that they really put culture almost above all else. It sounds great, but in all honesty it was actually depressing and horrible after a while. It almost always came down to, "Well we don't want to hire X person, because it's not a good culture fit." The real issue was that they wanted to hire people they could hang out with / mold into their way of thinking. No new ideas, and everything pretty much stagnated. If that's what you were looking for, then it was great, but people who think like that aren't typically the ones that can hit the homerun when you need to.

I used to buy into the whole "communication is king" idea but the more I program the more I just don't think it works that way. Most good coders I know communicate clearly as a side effect of being good, even if they're otherwise completely socially crippled, and they're way more productive.

But once you get over that, you realize that code itself is just an implementation detail, and it's the people higher up that have more influence. As developer you get paid an X amount a year, that's about it; as a higher up, you get to play with millions, both as money and as 'resources'.

As a developer you'll learn your limitations, that you cannot solve everything and that you alone are not good or fast enough to tackle nontrivial projects (currently in the middle of that, single developer, at the current rate it'll take years for my software to become viable. At least I'm on the payroll). If you have bigger ambitions, climbing the ladder is the way to go. Personally I'm hoping to be able to get a small team together in the coming year.

Also, juniors are not in political situations where the other aspects matter all that much. Generally, they find themselves in simply political situations. As long as they are not downright toxic, it is ok.

Honestly I don’t think it’s a good trend or that it’s unavoidable.

We shouldn’t look at the world today and take it straight as a lesson of what should be done. A bit like saying being gorgeous, extrovert and good negociator is the key to success, it sure can be but it shouldn’t be the goal of everyone.

1) All of those people aspects are very, very important.

2) Stacks don't matter. Languages don't matter. Editors/IDEs/whatever-the-hell-else doesn't matter. What I used to call a "firm theoretical grounding" does matter.

What does that mean? At the base, the ability to write clear code that other people can read, and the ability to read code that other people have written. (Don't laugh, it's not uncommon to get called in when someone has bugs (or features) they can't get fixed after they've painted themselves into a corner.) (For me, the key to this is formal logic and what is variously known as axiomatic semantics (http://homepage.divms.uiowa.edu/~slonnegr/plf/Book/Chapter11...) or Hoare logic, or predicate transformer semantics. Theoretical, right? But the ability to think about a piece of code as a block of text, without "simulating the computer" is darn useful.)

Further, algorithms and data structures. No, you don't have to memorize a bunch of algorithms. But it's a good idea to understand what kind of things are out there and what they can do, as well as having experience writing them yourself. (I get downvoted a lot, but I do have to point out that everytime anyone puts code in an editor, they're building a data structure or writing an algorithm.)

Then, at least some knowledge of computer architecture and all the stupid little electricy bits. :-)

Then there is a stack of things that build on that, some of which are only relevant to some tasks: databases, network protocols, and so on.

None of this has changed fundamentally in 30 years. The only major change I've seen is an increase in the importance of continuous math---which I noticed because I've always had a hate-hate relationship with trig and calculus and so on. But all of machine learning and statistical techniques are based on that nastyness, so you can't ignore it any more.

Why does nobody mention technical things? For one thing, they're hard. You can practice communication at the grocery store. Not so much with technical matters. Further, the people aspects are important everywhere, whereas technical things just aren't. And at some point, it's easier to convince some one else to do the work while you have the ideas. (Personal motto: Ideas are cheap. Implementation matters.)

Finally, technical mastery is not really encouraged. Outside of academia, there are no real incentives for it. (Inside academia, there are almost no incentives for it.) After 20, 30, or 40 years, people will migrate on to something else, even if they don't like it or are really horrible at it.

I only half agree with this. I agree that there is no one perfect language or stack and that there is a reason for there being so many alternatives. I also have worked with a fair share of languages and stacks by now and am not afraid of picking up any new technology when necessary.

But languages and stacks do have trade-offs. Sometimes the trade-offs can even be almost prohibitive (e.g. there are stacks I've worked on that were so immature they were a legitimate liability to the product and business, even if of course we would find some ways to mitigate them (but you can't mitigate something you're not even aware of)). In other situations, it depends a lot on the context: what languages/stacks does the team/company already know? What sorts of libraries are you going to use (there is no point in trying to use Ruby for an NLP project, for example)? Do you have special requirements in terms of performance, parallelism, etc. (that might exclude some languages)? And so on.

Agreed with the rest of your comment, and I want to add that "the ability to reason about a program in your head" is also why I tend to prefer functional programming with immutable values (even though, of course, that has its own set of trade-offs).

I, too, really like functional programming for that very reason. :-) It just isn't the approach I grew up with, and the functional programming manner of dealing with imperative is still a bit hard to get my head around.

You will have issues in that library/network/function/language. Learn to be comfortable peeling away the abstraction when you need to.

Thanks!