Hacker News new | ask | show | jobs
by dominotw 2419 days ago
This is bad advice. If you are hitting 40's, please do yourself a favor and go into management.

Yes coding is fun but,

1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun.

2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.

3. Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.

4. Being paid less than the lowest grade manager, is not fun .

5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.

There is no such thing as "IC track" for almost every one of us, please shake yourself out of your delusion.

13 comments

This is definitely not true. There are IC tracks at many companies. I'm over 50, still doing technical work, and I'm having a lot of fun. I was a STSM (Senior Technical Staff Member) at IBM and I'm now a Senior Staff Engineer at Google. Yes, most senior technical folks don't actually spend much time coding; it's things like technical architecture, creating slide decks for the VP's, meeting customers, etc. That was definitely true when I was at IBM. At Google I get do more coding, but a lot of my time is spent helping more junior engineers, working subtle bugs that other people weren't able to do, reviewing code, etc. But people management? Heck, no! I enjoy doing the technical work too much to have to spend time doing people management. I'm grateful that there are people who are willing to do management, since it's a different set of skills, but it's not for me.

I do spend my weekends doing technical work (mostly reviewing and testing other people's ext4 patch submissions, and/or reviewing papers because I'm on various program committees), but that's because I love to do those things.

> 4. Being paid less than the lowest grade manager, is not fun .

At least at Google, and at IBM, it's not unknown for IC's to be paid more than their manager.

> 5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.

It may be different for people doing other kinds of programming, but at least for Systems Engineering, there's an awful lot of value in knowing how the various abstraction layers fit together, and more importantly, understand the business imperatives which drives even the lowest level technical work. (Things like maximizing ROI on storage infrastructure by making sure you can efficiently use nearly all the IOPS which the HDD's in your data center can deliver, for example, is subtle work.)

Also, at senior levels, you need to know how to lead technical teams, and that's quite different from people management. And when I say lead, very often you may not have formal hierarchical power over the people that you need to influence; but instead of you have to pursuade them to share your vision and go along with your plan.

> And when I say lead, very often you may not have formal hierarchical power over the people that you need to influence; but instead of you have to pursuade them to share your vision and go along with your plan.

This is the worst part of the whole gig frankly. It's an awful place to be, all the responsibility and expectations but none of the muscle.

The biggest projects span such a wide number of teams and/or departments and/or product areas (product areas at Google are headed by Senior VP's) that you're never going to have someone with the formal authority having either the time or the technical knowledge to run those projects. Even at the department level, the VP will have hundreds or thousands of people reporting to her, and so she's not going to have the time or attention either.

So the authority gets delegated down to the technical leaders, and while it can happen that there will be conflicts that have to be escalated to the VP or SVP level, it's usually because a team simply doesn't have bandwidth to satisfy a request, or are being given conflicting signals as to the prioritization of different projects, and so we need to escalate to senior management to either get more head count, or agreement that a given prioritization will mean that the project will slip, etc.

The technical leaders make the technical decisions, and are responsible for the technical decisions. Management makes the resourcing decisions, and product managers make the product decisions. Usually, it's pretty obvious whose domain a particular decision is in, and as a senior technical leader, I actually know enough about the constraints that I can tee up the question, with the tradeoffs, and then say, "but that's a product-level decision: do we ship with now, or do we slip and so we can add this particular critical feature? Note to management: if you don't like the velocity of the development, we badly need at least 3 more head count by next quarter or we will be presenting you with more Hobson's choices like this."

And that's fine with me; I don't find working with recruiters and negotiating with the CFO for headcount, or sitting in an all day meeting trying to divide up the headcount granted to the department to the various teams. Not having to do that is not "lacking muscle", it's being freed from work that I don't like to do.

Are you the /dev/random guy? If so thank you for all the countless times I copied it as skeleton kernel /dev code. :-)
I don't know, did Theodore Tso implement /dev/random? (hint: he's the famous EXT4 guy)
Yes, I'm the /dev/random guy as well as the ext4 guy. I've also been the serial driver guy, and the tty guy (Posix job control was my first large contribution to Linux). I also was on the board of the FSG when we hired Jim Zemlin, and when the FSG merged with the OSDL to form the Linux Foundation. I was the Kerberos v5 TL at MIT, and I served as one of the IPSEC working group chairs and on the IETF Security Area Directorate. Oh, and for a while I was Treasurer for Usenix.

See? There are plenty of ways to be a technical leader without being on the management track. :-)

I'm trying but at 35 haven't formally held a title that meant I was leading others. Every posting even for a team lead wants 3 years or 5 years or whatever of leadership already, and that's not even really a management position most places. An MBA and re-entering at the bottom would be very expensive, in direct costs and lost wages.

What's the way in? Hope you find yourself in a job where there are leadership positions open and the stars align and you're promoted into one?

And you're dead right, not every place is Google or whatever. Hell I don't think Google's Google, mostly, in terms of what they actually do, but they do pay developers very well regardless, so there's that. But outside a handful of huge pure-tech companies and Wall Street, you better be moving out of development by 40 or so (earlier if you can swing it, really—god I wish I'd started making moves this way years ago), or your career's (pay's) in for a brief flat trajectory followed by a sharp drop way before you'd have liked.

You can find ways of being a technical leader without having a formal role. You can mentor more junior engineers; you can try to establish better coding and test/QA standards at your company. You can find some open source project that you're passionate about, and take on leadership roles there. Maybe you can find a way to contribute in standards organization.

If I'm interviewing you for a job at $COMPANY, I'm going to be looking for signs that you can exhibit leadership, and that's going to be way more important than whatever title that you might have. If you have the title, but you can't demonstrate ways in which you were able to demonstrate technical leadership, the title isn't going to mean much.

What's the way in? Hope you find yourself in a job where there are leadership positions open and the stars align and you're promoted into one?

In corporate jobs, this is rarely the way in. Most likely, you'll have to convince your current manager (and maybe theirs) that you're ready to be a manager and look for a manager opening elsewhere in the company. If you think you're ready and your current employer does not, you'll have to look outside.

Years of leadership seems like a purposefully vague credential. It's not about a title; if you don't think you've been a leader at work, you probably weren't (or maybe you were and your talent just wasn't managed properly ¯\_(ツ)_/¯ ).

> In corporate jobs, this is rarely the way in. Most likely, you'll have to convince your current manager (and maybe theirs) that you're ready to be a manager and look for a manager opening elsewhere in the company.

Also, get ready for a lot of gatekeeping. “Oh, you don’t really want to be a manager! It’s so much more responsibility and work. You should be happy to be a foot soldier for the rest of your career! Management is not all it’s cracked up to be. As you can see I’m stressed all the time! Now excuse me, I have to go close on my second vacation home in Hawaii.”

The requirement's usually tied to holding the title, like they want that to have been your full-time thing. It's been my experience that people see what you're doing in a very different light depending on your title (one title, one company one day, everyone second-guesses or ignores everything you say; different title, different company, a few days later, suddenly everyone's deferring to you in meetings and sincerely asking your opinion about everything to such a degree that it's unnerving) including in hindsight—if your title was "lead" you don't have to spend a ton of time explaining exactly how, as a non-"lead", you were leading to convince people you were, and you don't have to avoid giving the impression you were being "bossy" or overstepping by doing it.

[EDIT] my suspicion here is that yeah, it's basically "luck into it". I mean that's how everything else I've done career- and pay-progression-wise has worked (luck into someone tasking me with something they definitely wouldn't hire me to do, but after I've done it for a few months someone else would) so maybe this'll work out the same way.

> If you think you're ready and your current employer does not, you'll have to look outside.

Is it even possible to find a management position outside without management experience?

I’ve faced the typical deadlock that first time job seekers encounter: you need management experience to get hired as a manager, but nobody will give you a chance to get management experience because you’ve never managed before.
You should take a look at startups, especially keep your eyes peeled for the growing ones. You’ll have to read the culture to see how they choose managers (promote from within or hire from outside) but opportunities are usually abound and companies just need to get things done. Try to hold out for people above you that you really like and are good, kind folks that want to see you grow. That’s also typically a good approximation of company culture in general, in addition to a good litmus test of whether your bosses can help you in your career progression.
In my own experience, the biggest "killer" is that it just gets boring and repetitive.

I've been programming for 20 years and it is a struggle for me to find something "new" that isn't a mild variation of something I've used before..

There's only so many variations of an application that can bring something really new to the table that gives you that excitement of learning something new like the first time you "get" TDD or DDD, or that first time you successfully implement an efficient CQRS model, with eventually consistent events, or run a GraphQL API that swaps the challenges of REST for a new set of problems and so on. Switching industries doesn't help much either, as they are either just more of the same but with different vernacular, or so niche that you'll need to have really been there since day dot of your career anyway.

There's only so many new libraries/frameworks that I can get excited about, and the rapid state of change in many ecosystems means that quota is pretty much full 100% of the time. Languages, too. That's before we even tackle the problem of getting _hired_ for languages I've not had any professional experience with, and with the added bonus of 0 personal time to implement side-projects, and a lot of companies never needing to stray from their current stack.. it's just not going to happen.

So now the only thing left that tickles my fancy are the "abstract" problems.

Instead of now focusing on implementing code to fix a problem, I'm asking and researching the questions like "How can the platform (and not just application) be more performant?" or "What is that the team can improve on?" and "how can I improve the learning culture?" etc. and using my experience to, at first, recognise these problems that are invisible to a lot of people, but also gauge which ones are actual problems or mild inconveniences.

In my early 40s, I am starting to reluctantly wonder if this is true after all. I don't like it, but that doesn't necessarily mean it's not true.

Another point is: In many/most actual organizations, it's the people managers making strategic technical decisions, not anyone on any other track.

On the technical track your job is to get the management track to make the right technical decisions. This is hard: they have more power and don't have to listen, but a proven track record of good advice - combined with hard knocks when things didn't go well that you claim to be preventing gives you the power to give them the strategic direction they roll out.

Don't forget that there are more possible correct answers to strategy than there are people to do it. Should your company continue to update the current project, work on the big re-write to fix all the problems, or abandon current products for something complete new? All of these are valid answers for different situations, and some of the reasons to choose each are not technical and so you shouldn't influence them.

I have a dozen projects I'm thinking about at any given time. Some will never get more than thinking about. Some are in progress. Some I'm working to get into progress. Some are likely to be needed soon and are just waiting for the time of need so I can save the day with a plan (if the likely need turns to reality). Some are bad ideas that I need to prove are bad ideas so that we don't go down a bad route.

IME skill-stacking (and including something rel to people / human interaction in your wheelhouse) is the best path to [power / authority / autonomy / clout / leverage]. It doesn't have to be binary "tech or mgmt". But you're absolutely right; companies are groups of people. If your role is such that your influence doesn't extend beyond what you can personally code, your sphere of influence (and career opportunities) will by definition be limited. This can be mitigated by eg explicitly developing skills of presentation and persuasion... but if you work somewhere that has other employees, and don't want to get stuck in a downstream role slinging code, there is no alternative to learning and mastering the [human] interface to the rest of the company.
"it's the people managers making strategic technical decisions"

I'm 54 and I'm pleased to say that I've never worked anywhere where that was the general rule - I've always been on the "technical leadership" side of things (CTO/Head of Architecture) since my 20s and I pretty much see my job as ensuring that "strategic technical decisions" get made in the right way.

As CTO, did you have direct reports? If so, you were a people manager and:

> "it's the people managers making strategic technical decisions"

...was true in your case.

In my experience (over 2 decades now, wow I can’t believe it) the people making the broad, strategic decisions and influencing outside of their orgs all happen to also have direct reports and usually those reports are people managers too. They have titles like “director” and “VP” and “CTO”. How many of those people have you seen who are individual contributors?

The obvious influence belongs to the managers at all levels. ICs have less obvious roles, but good managers look to their ICs for guidance on what decisions to make. Thus there is a lot of indirect authority in the roles that seem to have no power - for the IC that learns to use it.
I'm jealous. I don't think your experience is typical.
This is demonstrably true in my experience. You're going to be downvoted to hell because this isn't the 2019 "I want to be an IC forever and I should make the same $ as my CEO" mood. For what its worth, I think the career path is more focus on operations mgmt or focus on tech mgmt.
> 4. Being paid less than the lowest grade manager, is not fun .

If this is the case, your company's technical leadership track has a broken pay structure. You shouldn't need to go into management to get paid better.

That’s the reality in most companies.
As usual, you have to scroll down to the negative voted comments to get the brutal truth. Ignore the happy-talk, this comment is right on the money.

If you’re in your 40s or 50s and not in a role where you’re “influencing decisions outside your own team” you’ll soon be in for a shock next (or next next) job interview.

I hear a lot about people having a younger boss but I think that’s more of a HN bubble. Maybe at some startups but the majority of places I’ve worked at or been to have older people as managers and they all have experience.

Once time I interviewed at a place with a few managers that were in their late 20s. Turns out they were the senior employees only having been there less than 2 years. Turnover was less than 6 months, I passed on the job and my schoolmate was there 5 months. The place had a bad reputation.

If you're in your 40s, and there are no managers younger than you, you're in a very unusual organization.

(But if you're bothered by having a manager younger than you, that's on you; I'm not sure what the inherent problem with it is. When I was a manager, I managed people older than me; now that I'm a senior IC, I have leadership younger than me. Both things are fine.)

OP said if you’re in your 40s and being managed by someone a decade younger than you. That would mean 30s. At my last job there was one manager in his early 30s (promoted at a small company and then switched). At my current org there aren’t any managers in their 30s but there’s more levels. I’m feel comfortable here because my current managers were ex SEs.
> Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.

It's not about JS frameworks, but if you don't keep up with technology _because it's fun_; and you also what to be promoted very high on the ladder (aren't happy with "just" an average job with average pay that lets you have a decent life outside work) by all means do yourself a favor and move to management.

> because you can't invert a binary tree in 20 secs in leetcode

It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).

> 2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.

I've been managed by former students. Worked out quite fine for me. Why wouldn't it? Age does not equal competence.... I'd rather be managed by a competent young guy than an incompetent senior. (bad managers are no fun, that I agree; but bad managers are not necessarily young; and young managers are not necessarily bad)

> Being paid less than the lowest grade manager, is not fun.

Being paid less than what you're happy with is no fun. But it's not really required.

> do you really need 20 yrs of coding experience to write CRUD apps

So don't write CRUD apps if you're better than that.

> What exactly are you bringing to the table.

In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.

> There is no such thing as "IC track" for almost every one of us,

If that were true, it all becomes a huge pyramidal scheme (you constantly need more young developers so that you can manage them as existing workforce ages).

I'll give you that: for most people, it's probably easier to advance on the management track than it is on the IC track. And the IC track in many companies is a joke (if you're not at the headquarters, advancing is an order of magnitude harder; also you advance easier by playing the advancement game than by being competent in what you do - but that may be true for management too). So yeah, it's not for everybody. But OTOH, middle management sucks... big time. For some people, it may be a good deal to sacrifice some cache upside than to turn into something they don't want to be. It all boils down to what you want to optimize. If you're happy with a good income, even if it's not the best that you could possibly achieve, IC track might be an option (still, change companies every now and then. It's much easier to promote this way).

> It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).

ok. I was being facetious with that (particularly famous) example.

you are able to breeze through hard leetcodes in your 40's in a tech interview setting?

Why would you be faster at 60's vs 20's , not sure i follow the line of reasoning.

> So don't write CRUD apps if you're better than that.

Can you give me some examples of better things that actually require 20yrs of experience ?

For context I have 2 medals at IOI in highschool. I'm not the most competent in the world (best in my country took 4, all of them gold) but still I'm not too shabby.

Am I as good as I was in my 20s? No. But the truth is that most people can't do the simple recursion... very few places will deny you employment because you can't invent original algorithms on the spot. They'd just fail tou for simple examples like the one you presented. The amount of people who can't do a tree traversal unless it's DFS is staggering. (and in all honesty, not all of them are useless programmers... sometimes people would do amazing stuff despite failing basic algorithmic tasks. That's what makes hiring decisions so hard.)

[edit] > Can you give me some examples of better things that actually require 20yrs of experience ?

I saw this just now. Lots of things can use said 20yrs of experience... maybe even some CRUD apps (e.g. to know what to not over-design). Some things you probably can't do right without extensive experience (say, design a new programming langugage; or a new datastore). E.g. Rich Hickey famously designed Clojure because he wanted a better way to do those "CRUD apps". Also, it's quite easy to find a hard problem that you won't solve without extensive experience, no matter how smart you are (say: collaboration, data management & versioning in large AI teams). Pretty much any open-ended problem, really... remove all constraints and most programmers will get stuck. How many people can start with "void main()" (or equivalent) and actually release it to production, if the project takes a non-trivial amount of time to complete?

ok. But You haven't answered my questions.

Re that example, I was just using this famous tweet.

https://twitter.com/mxcl/status/608682016205344768

You don't get a job solving simple recursion problems. You have to solve hard leetcodes.

I don't know what "hard leetcodes" look like... even in my teens I failed to solve _some_ problems. But what I can tell you is that I switched jobs less than a year ago, I was given as part of the interview process a link to solve 3 problems online in 1h30m and solved them all in 1h. Now, were they rated "hard"? I don't know, honestly.

Also, 2years ago (I think) I participated in Amazon TechO(n) challenge... I was 1st after the weekend, but couldn't work on it during the week (no time/ kids) so by Friday my solution ended up 5th or 6th I think.

[ninja edit] No, I'm not faster, I'm a lot slower. In fact I probably lost most of my speed in the first few years when I stopped competing... but it's not a linear function, at some point, you don't lose any more speed; and just a quick refresher every now and then can boost your abilities back to fairly high levels. And most interview problems are not really competition problems, they're fairly basic.

And no, I don't write algorithms from scratch currently, the company I work for might actually be characterized as "boring" by many people("robotic process automation" - look it up). But I've lived to learn that when there's lots of money involved, there's also lots of interesting problems to solve - one just needs to find them.

I can say you are def an exception, most ppl get slower at these in their 40's than in their 20's.

You seem to have gotten faster. For most people this knowledge tends to atrophy as they age. Maybe you are lucky enough to work at job that requires you to write algorithms from scratch ( embedded engg?).

What is your theory as to why that homebrew guy wasn't able to solve simple recursion problem ?

>> What exactly are you bringing to the table.

> In general, knowing what NOT to do. Finding out & solving the right problem, not the one that was given to me.

So true.

I would add the ability to look farther ahead at potential problems. I have seen so many young people blocked by some issues that should have been spotted way earlier.

>> because you can't invert a binary tree in 20 secs in leetcode

> It's a simple recursion. why wouldn't I be able to do it? I fully expect to solve algorithms & data structures questions into my 60s faster than the average 20yo can (because of my background. Point is, it doesn't correlate with age, if you can't do it at 40 you probably weren't great at it at 20).

My main problem is that I look like an idiot while writing code. I pointy-clicky navigate too much for many's taste—doubly so when someone's watching because I start second-guessing every keystroke and so avoid keyboard navigation—and tend not to remember much about languages I haven't written a ton of within the last 48hrs, and even then if it's some feature or function I haven't used in a couple weeks I'll either look it up or poke and prod my way to the correct syntax ("it's either this way or that way... OK, red squigglies, must be that way" or "I think null can just be used as falsy but undefined is gonna throw in this language? Yep, there it is, cool, I'll guard it then" or I'll not be 100% sure about the order of arguments for a "map" function even if I used it ten times yesterday and I'll look at the IDE's hint to get it right, stuff like that). I'm much better at the "what" and "why" than the "how", without support from tools and the freedom to faff about a bit, unselfconsciously.

All that's even worse on a whiteboard, of course. If someone bet me $100 I couldn't write a solution to fizzbuzz on a whiteboard in any language of my choice, that'd compile if input verbatim, without looking up some stuff in the couple minutes before doing it, I would not take that bet. There's a decent chance I'd manage, but I quite literally would not bet on it.

I mean I've been (technically) designing & shipping software for pay for a long time and everyone's always told me I'm pretty friggin' good at it. I've often been the go-to guy for weird crap and "hard" problems. But I look like a total dipshit who doesn't know anything and probably wrote my first "hello world" last week, if you watch me do it in interview conditions. I pretty much only have a career in software at all because not every place does those.

I never would claim that your algorithmic skills define you as a professional - on the contrary with age I got worse at contest-style coding while getting generally better (I believe) at the trade. It's just that my experience is that the companies would generally require pretty basic stuff.

On your points,it sounds more like bad interviews if they're about syntax, not about the logic.

It sounds like you are making a lot of rationalizations for not investing the time to practice live-coding and whiteboarding. Those are skills that can be learned, like any other.
Sure, and I am training those. It's just tough to keep up with when you're happily employed, since you're spending 40+ hours a week working but not doing those things. The longer you're happily employed somewhere the harder it is to keep up with that stuff. People skills? Talking about your work? Plenty of that on the job unless you go out of your way to avoid it. You'll naturally accumulate knowledge, tricks, stories, successes to talk about. Bumps and bruises, too. Algo interview stuff and whiteboard coding? That's purely extra time training on evenings and weekends.

OTOH I'm already near the top of my earning potential as an IC in my area (and for most remote work that doesn't require some prior connection with FAANG & co or excellent skills at algo interviews) so I'm looking to move to roles that don't require that particular kind of prep and are higher-paid besides, tending to be more about concepts, people, and communication (architect, manager, that sort of thing). So I've done just fine working (and interviewing) the way I do, and hopefully the sorts of interviews I'm bad at won't be relevant to me a job or two from now, anyway.

I largely agree with you since I turned 40 not long ago. I still get a lot of offers for ICs, but the salary bump isn't there anymore (I make decent money). When I look for management positions, the salary bump is much higher. I'm starting to question my decision to be promoted to the highest level of IC my company offers instead of taking manager role when I had the chance.
I agree with a lot of this, but I have not worked ANYWHERE that a high level IC engineer doesn't get paid more than a first level manager. As a manager myself, until I got quite senior, I always had more than one person on my team who made substantially more than I did.
There are any some senior tech roles that are not strictly "management": Technical Lead, Application Architect, Solution Architect, Enterprise Architect.
OK, let me offer the competing viewpoint. I've been a technical manager, I've been an architect, I've been a programmer and everything in between. I've run my own company outside of the tech space too. I've been around.

>>1. Not being able to change jobs because you can't invert a binary tree in 20 secs in leetcode hazing, is not fun.

This is true. This doesn't bother me though. I don't need to find "this" job, I just need to find a job. You ask me to invert a binary tree, don't worry. I'll find a job someplace else, and you can find someone else that has less experience and knowledge than me.

>>2. Being managed by someone a decade younger than you with no family or responsibilities, is not fun.

Don't honestly care. If you're a manager and making decisions on your lifestyle and feel that everyone else should live like you...see previous answer.

>>3. Spending your weekends learning the latest JS framework because you don't want to be someone "who doesn't keep up", is not fun.

Honestly, I don't have to. The foundations are the foundations are the foundations. Do I know how to use the equivalent of Redux in Vue.js? Admittedly, no I don't. I can google that. I may spend sometime looking up new stuff on my own, because I find it fun, but this doesn't stress me out. I can figure it out. You don't hire me as a framework jockey. That's not what I do. You want me to go up against some younger person who spends his time learning React and can tell you the syntax off the top of his head. OK, fine. Call me when your database has scalability issues, or your web server is overloaded.

>>4. Being paid less than the lowest grade manager, is not fun.

Yes, we'd all like to make more money. Here's the thing. I make enough money to live the way I want to. To think that all senior developers can become managers is a joke. Management is an entirely different skill set, and news flash, it's hard. Like really hard. The best manager understands things like accounting and finance. You have to keep track of head counts, who gets what raises, why do they get them. If I give this person a raise and not as much to this other person, will someone leave? How does that affect my staff. Do you understand how to counsel people, because whether you like it or not, you're going to do that too. You are a people person, you get to hear all the things that go wrong, and sometimes you need to understand how to fix them and other times you need to just listen, and you have to know when to do both. Are you ready to put your job on the line when you find out that another manager, or someone above you is sexually/discriminating or harassing people? You get to do that too (blah blah, laws against that. They can do that. Get back to me in the unemployment line on that.). Have we talked about firing people? How many people have you fired before? Not a fun requirement. How many people have you laid off that are perfectly good at their job, because the company wants to hit their bottom line? Managers may make more money than me ... when they're working. Just think how many managers vs engineers there are in the workforce. Let that sync in. You're competing against a lot of people that are or want to be managers for maybe what a 10th of the spots. Competition is a lot stronger, and that's assuming the open positions aren't been filled by people from within.

>>5. And be honest with yourself, do you really need 20 yrs of coding experience to write CRUD apps? What exactly are you bringing to the table.

What am I bringing to the table? That's easy, 20+ years of coding experience. I've seen enough to know you shouldn't do things a certain way, or a whole range of problems that people who just started out didn't even know existed. I know which log files to look in on a web server when there is a de-serialization issue. I know that a particular linker embeds a date stamp 60 bytes into the header of an assembly. I also know how to write and communicate technical problems to an audience in a simple way to allow them understand the const benefit analysis of a particular approach. You don't pay me to write code. You pay me to solve problems, especially ones you didn't even know you had. Some of them are coding problems, a lot of them are not.

EDIT: Formatting