We need someone who has done “it” before
cutlefish.substack.com
cutlefish.substack.com
That's true, but what about "Keep doing 'It' but at our company for half the hours and double the salary"?
Then you could take the extra time and money and work on your +1 and +2.
Like doing programming problems is fun for a bit, but doing work that actually does something, even if it's simpler in complexity is more satisfying. IMO of course.
I think the recruiters could be pitching better if they went with, do 'it' here and think about what +1 could be and when you figure what that could be, pitch it to us. This of course assumes the organization sees IT as a value multiplier and not a cost center / plumbing job.
"Keep doing what you're doing but half the hours and double the salary" is something I would be tempted by, but it would be with the idea that I'm focusing on something other than developing my career.
It would be tempting, even given the stake I just placed in the ground:[1] But 1. astronomically few companies will offer to double my comp at this late point in my career and 2. Nobody in tech offers part time work but with full benefits…I’d have to be a contractor and find clients and fund my own healthcare and retirement (yuck). It’s at best an theoretical exercise.
Consultant/Contractor might be the closest.
But it does help to inform people the right way to proceed if 800k in 20hrs a week is their goal :)
* Accountants doing company liquidations
* Trial lawyers
* Performance artists
Others I cannot think of. Pay rates over $1,000/hr are surprisingly common. Many of the recipients work fewer hours as a result
It does take a very specific additional skill set to build up a network of clients and have the patience for that to turn into something where you're regularly booked, but if money is the number one thing you want to optimize for, it's something you should investigate.
https://www.bloomberg.com/opinion/articles/2019-11-04/jim-si...
> He started at age 40 with no experience:
> It took him a while—he launched his fund in 1978 and it didn’t really click until about 1990—but he absolutely achieved his dream of making money without doing anything.
And, he had lots of experience with math - he was insanely great at it. And then he took it and applied it.
Thales was an all around great philosopher though, known to be one of the "seven sages" of ancient Athens. Amongst other feats, he managed to measure the height of the Great Pyramid of Gizeh when nobody else at the time could.
Even the same total comp and benefits but half the hours would be good. If I could do one week on and one week off or two weeks on and two weeks off that would be awesome.
Companies often (but not always) want someone to just do ‘It’ with minimal extra management effort.
This is because every companies success is generally gated by the available extra intelligence and decision making ability at every level (really every organization). The more management work put in, and the more ongoing thinking required to produce unit X (whatever it is for the company), the less competitive they are.
Most companies of course aren’t great at this, but as long as their competitors aren’t much better (and/or other factors add more ‘competitiveness’), it still works out.
Most dumb and value destroying things happening anywhere is because someone who is in the position to make a decision doesn’t have the mental bandwidth to make a good decision, or someone with the bandwidth to make that decision isn’t trusted to do so because of lack of consistent mental bandwidth by someone else to supervise, select, or police folks like them.
For individuals, like you note, the incentives are often the opposite - to grow, take on individual risk, etc.
And most individuals who are not actually entrusted with the scope and scale that would challenge them HAVE extra mental capacity (albeit perhaps not the experience or whatever to actually be successful, but they won’t know that) because they aren’t subjected to those loads generally.
Not to discount nepotism (usually caused by trust issues/difficulty with owners managing non family members), corruption (usually caused by those in control not seeing how to produce value while following the rules), etc.
However, a lot of times the "want to do it forever" part could be a sign that the candidates doesn't want to learn anything new, which is indeed a very bad sign.
On the other hand there are people who want to want to keep doing tasks so they get a deeper understanding of the domain, as mentioned elsewhere in the comments... and you can't afford to say no to those people.
While that is true for a lot of jobs, there are also a fair number of employers that are perfectly content to have an employee that does job X at their company for as long as they are of working age. In the software world it pretty much follows from the fact that the largest chunk of development jobs out there are just CRUD apps and processes that feed them. Many companies do the same things with largely the same software for years and years and years. As long as an employee is getting the work done, many of those employers are thrilled to have a long-term employee doing the same tasks they've been doing for years.
You can stick with the same technology and language, sure, but the frameworks and the language will evolve under you. Tools evolve (Git? Github? CI?). Processes evolve (Scrum?). Requirements change (HTTPS? Accessibility?) There are gonna be lots of changes coming from the outside.
Heck, when I think of it, frameworks targeted at CRUD apps were probably the things that have changed the most during my career. I have a few friends doing stuff with C++ and they joke about how much tech in the web/enterprise bubble changes.
People who are really good at things generally thrive on challenge, because without that you don't persist long enough to get good. For many, me included, no reasonable amount of money will get them through doing years of something where they aren't growing.
I've been doing "It" (shipping software -which is quite different from "writing" software) for my entire adult life.
Basically, if you want to actually ship a superb-Quality native iOS/iPadOS/WatchOS/MacOS app, in an astonishingly short period of time, I'm a good person to talk to.
What I have learned, is that very few people seem to want to actually ship software. Instead, companies become obsessed with "coding culture," and "process" (which can mean many different things). As it comes time to start preparing for it to go out the door, all kinds of roadblocks start piling up. It's crazy.
I was "frozen out" of the industry, because of my age, which really pissed me off, but that has turned out to be a great thing. It's been a real joy, writing my own stuff. Out of necessity, I have to keep the scope humble, but that's fine.
Many companies must build out rigorous standards, and checks and balances in order to deal with regression to the mean.
If what you're saying is true you're multiple standard deviations above the normal engineer, and scaling you is non-trivial. Bob martin has said the population of coders doubles every 5 yrs meaning at any given time 1/2 of the engineers have less than 5 years experience. When you need something that would take 1000 of you, which might not even exist on the planet, they instead have to build a system that takes 10k of those 5yr and less engineers -- and have the highest quality outliers leveraged though standards, automation, building engineering culture etc.
I get that a lot. It's absurdly easy to verify (I point to all my work), but folks would rather sling mud, than take a peek.
Doesn't matter. I'm not looking for work anymore.
In my time, I have worked with many people that make me look like a piker. I suspect they get chased out, too.
It really doesn't matter to me if it's true about you or not, we can still discuss the issue of designing for talent several standard deviations above the mean vs one that falls within, say, [0-1] std deviation above the mean.
In perticular, you're not working in the same semantic framework as GP, who was talking about "It+1", "It+2" and so on
It has been my experience that actually delivering, working, high-Quality, supported, documented software (regardless of what the software does), within a reasonable period of time, is beyond the capabilities of many corporations.
I suspect that some folks make money by convincing others to invest, then hightailing it, before the chickens come home to roost, as opposed to actually selling a finished and supported product to end-users. In that case, looking like a "shipper," is much more important than actually being one.
But that's just one "It" on the continuum. It could also be grant-writing, selling, managing, singing, shredding guitar, racing minibikes, whatever.
In any given case, there's always some threshold of what an "effective It" is. It may not be a clear-cut line. For example, research is very "fuzzy," and a researcher that can do "It," may be excellent at failure, because their job is to poke holes in theories.
In fact, if the company is all about getting A-round funding, then folding up the card tables, and moving on, someone that "looks like a shipper" could be an effective "It."
And I feel you on process. I got involved in process because I wanted to quickly solve user problems, and then keep on solving user problems. But so much of the process-industrial complex is not focused on that. E.g., the SAFe® process is the effective opposite of what early Agile pioneers were aiming at. Its major function is to give managers and executives a sense of control almost without regard to how achievable that is or what it costs in terms of productivity and lost opportunity.
1. Salary will plateau eventually. I know early in your career it doesn't seem like it will, but trust me: It will. I don't care what company you are in, or how good you are, "Fourth Senior Software Engineer From The Left" is never going to be making $1M/yr. (Not that that should necessarily be your goal, but it illustrates that you will plateau at some point.)
2. When you keep job hopping for more money but no change in level, you risk gaining "1 year of experience 20 times" instead of 20 years of experience. You're sacrificing long term career growth for short term salary bumps. I did this for years and ended up shooting myself in the foot long-term. My college friends, who instead played the Title / Ladder Climbing game, are all much better off than I now. They're all job-secure VPs, SVPs, and CxO's in their companies vs. me who still doesn't even have any direct reports, and is one of many interchangeable worker bees.
No more doing that for me. I'll only accept, at a minimum, a level jump at this point.
Or to you, is "management" simply the next level beyond individual contributorship? I won't work for an employer that doesn't plan for career advancement in BOTH tracks - management is great, but for every one of you who sees career advancement as managing others, there's someone like me who wants to stay the hell away from that while still finding room to advance my career as an individual contributor.
Any thoughts?
I love the concept of having VP-level IC “wizard” roles who don’t have to manage, but have never seen it in practice.
Generally, there's wayyy less of the IC roles, which essentially means that people who want advancement are often gonna end up on the management track.
As a Staff Engineer I'm just a really engineering focused manager "lite" if you will, (in so many ways, maybe I'm not doing enough justice here, but its how it feels day to day).
I like it, because I'm managing the architecture side of things and still involved in engineering decisions I care about, but I have both direct people working with me that I'm accountable for, as well as a 2nd level of accountability for the entire organization. I still get to commit code and do exploratory research, which is nice, but its not the highest percentage of work I do. So much of it is overseeing the implementation details of other engineers, providing guidance to both engineering as an org, or individual engineers, or being involved in product roadmap so that our architecture evolves flexibly enough to meet where we want to go, writing documentation and diagrams, giving technical presentations etc.
All told, at some point, you have to be a manager, even if its not a direct "manager" role, per se.
Someone who has done “it” in another environment will have scar tissue formed from issues they ran into doing “it” there.
When you hire them to do “it” here, they will avoid things that didn’t work there and try to do things that did - but here is not there and maybe the situation aligns differently and what didn’t work there would work here.
Like, maybe they ran into an issue with doing “it” using approach A because it required a more skilled operations team than they had there. But maybe here you have a better ops team and approach A would be much easier.
Frank Slootman (snowflake CEO) has some quote that is ~ "give people the opportunity of a lifetime if you want to hire amazing people". There are obviously downsides, but anecdotally smart + hyper engaged is hard to beat, even if that person hasn't done X.
I've managed to do "it+0.5" at a couple places. Most companies are only interested in doing "it" by the book and miss out on so much. At my current place I developed a couple +1 concepts that handle issues automatically, gave presentations with relatively little code needed, got a "hey that's cool" but was never asked to actually integrate those into the product or have someone closer to it integrate it. They're very happy to just do "it", never mind that we have issues that may well stem from not taking "it" to the next level.
These days, if you want to do that, you'll either need to have your company acquired, or buy the job you're looking for.
There's a larger population out there that having mastered "It," will happily do exactly the same thing for the next 10 years.
And that any value is always created by some last-in-line loser who got the hot potato passed on, and his work is never noticed or credited.
If this were true, you wouldn't see anything get done. Yet, widgets roll off conveyor belts and products are shipped.
The system is never perfect, and there is always some misjudgment of who contributes usefully and who is a pure talker.
To solve large-scale problems, we have to join forces with other humans. But we can't see into each other's head, so there will be mistakes and opportunities to exploit mistakes. At the end of the day, boundaries must be drawn. There will be conflict of interests. There is conflict between the aggregate interest of the group and interests of the participants. There are ways to coordinate these, but the effect can't be fully eliminated. Inside any harmony on a large scale, you find conflict on a smaller scale. Even a mother and her fetus are in some senses competing for resources and the mother must biologically protect herself from exploitative behavior of the fetus (this objectively happens in biology).
These things are more like laws of "nature" than something to be "angry" about.
It's like game theory. The behavior of individual people may be up for judgment but the collective is predictable. You can't ascribe it to individual moral failure when you consistently observe it across organizations.
There is a certain amount of alertness that is necessary. You can exercise it at multiple points, including when deciding which company to join. It would be better if we could let down or guards and relax the alertness but ultimately it's needed.
- never done any AI work whatsoever in their life, nor software, nor, apparently, any kind of tech/technical work in their lives
- blatantly lied on their Linkedin profile about past positions
- shown the inability of connecting their laptop to a printer
- told time and again the most outrageous lies about their competences (e.g., they said they had coded an automatic language translation software in Perl back in 2000), work done at the company and prior to their current role, and their life.
When HR contacted me after a complaint initiated by a colleague, to describe them I used the words: "they are the most incompetent person I have ever worked with".
The funny part is that despite their "sponsor" having left the company (the whole situation was so bizarre that to me the most likely explanation for their hiring was some sort of blackmailing or bribery), they are still employed (because for legacy companies it is more conveniente to make people inoffensive than fire them) and some of my colleagues are still drinking their lies like glasses of fresh water despite a few years of their semi-psychopathic behavior.
The world is an interesting place.
I don't know, maybe it does happen, but I haven't seen it. The only time I've seen it is during acquisitions, where a gigantic company gobbles up a 10 person startup, where everyone at the startup gave themselves VP and Director titles, but again, not talking about that nonsense.
For example, I know a few people that were forced to do what you describe because their single VP position was a failure. If you're a VP at Apple and were responsible for shipping iGreatThing, then you're right, you have social proof and a job in the industry for life. If you're a VP at a no-name manufacturing shop in the midwest that made a decent profit, but you were eventually put out of business by a larger competitor, then you don't have social proof or a job in the industry for life.
Social proof also applies to pretty much every area of human endeavor. I once worked with a game designer who regularly makes the top 100 game designers of all time list. He got his status in the industry for work he did in the 80s. None of his modern work has been successful, but he'll have a job in the industry for life.
But on the other hand, most juicy VP offerings I got lately are for building a team from scratch or reconstructing from the ashes of a disaster. The former is very hard as talent is difficult to find (or keep!). The latter is almost impossible as you need at least a year to prove you are anything like previous VP and some of the remaining team members only stayed because they thought (or were promised) they could be promoted to this VP position.
It's a feedback loop of ugly and it's taking over many companies.
That sounds a lot like “fake” work, but that’s only because we (the society we) tend to assume that all that is required to achieve things is to put a bunch of great people together and the rest takes care of itself. In practice, this is almost never true. People have individual motivations, feelings, and goals that contradict each other - the role of people in leadership is to recognize this and help find the midpoint.
Finally, it’s worth noting that most individuals value significant autonomy over their work. So while people often hold leadership accountable to excellence in X, the thing they actually want from people is for them to get out of the way so they individually can do X the way they want. Such is the paradox of leadership.
It’s probably a feature that there are some people who are willing to do these jobs and that most people aren’t vs assuming it’s a bug and that “many” are serial fakers.
If you LITERALLY need "it" done as "it" has been done before in an exactly specifiable way, you probably should contract it out. Not hire.
Contracting out is its own can of worms and can introduce as many problems as it solves. Exact specifiable way typically means 30 details to iron out later even when both sides mean well and those details are usually problematic.
I had never dreamed of things unfolding that way! Learned a lot and still enjoying it.
Senior Dev: "Yes!"
C: "How would you recommend proceeding?"
D: "I've studied the problem and my professional recommendation is to implement X, migrate away from Y and refactor Z."
C: "Oh, that seems like too much work and would disrupt the teams already working on Y and Z. Let's do it this way instead (points to Confluence page written by an intern last summer)"
D: "..."
C: "So you're not able to help us after all?"
Combine that with the ability to get grassroots implementer support and you have a pretty able leader.
Everything is just constraint solving in the end, and the hard part is maintaining pace.
What I tend to see is ignorant management insisting that there must be an easier way, rejecting all empirical evidence to the contrary, even going so far as to reject the concept of engineering tradeoffs entirely. It's as if the experience and accumulated wisdom of the senior ICs is valuable only insofar as it makes them slightly more productive code monkeys, merely speeding up the existing plan put in place by management without any say in said plan. Why even hire senior employees at that point?
The key is to probe deeply before taking on an assignment. If the managers appear too clueless or fixated upon some timeline or budget, then I often decline the work. I often end up fixing / rescuing projects that have been blotched because the previous incumbent rushed into taking on the job. You simply need to ask questions until you are comfortable that the proposed role is feasible. If the client (employer) is unwilling to engage to that depth, then that too is a red flag.
My favourite is the combination of a tight timeline/budget AND an unwillingness to discuss the project in depth. Especially since they always want some kind of fixed price guarantee in those situations.
Phase 1. "Our problem is big, we hire big company" (3000+ employee firm)
Phase 2. Meeting after meeting
Phase 3. Lots of billable hours, more meetings. Deadline approaching. Where is the product?
Phase 4. Gaslighting
Phase 5. Hire small company (1-400 people) to finish the work big company couldn't.
(Typical) Phase 6. Quietly kill project because if it ever had a business case it has missed its opportunity.
Does this go in the other direction, where a reputable small company starts a big project and is in over its head, only to be saved by one of the big 4 consultancies?
You get folks who maybe have worked a few places, or a lot of places that all operate with the same bureaucracy / processes and they seem unaware that it could possibly be different anywhere else.
Some folks I know work at a very large corp. Their development cycle is very heavy with processes, albeit seems very reasonable / works for them. Folks writing up what some feature should do for 100 different possibles, folks reviewing it in some way ... on and on. Maybe someone finally writes code and everyone reviews it. Testing, testing, testing. I'm not judging it, it's just ... a lot.
I work at a place with 3 devs, and only one other really does what I do. I get a vague idea of a feature requested, I talk to the customer, I go write it. Show some folks, maybe I change things, maybe not. I roll it out. Done. Feature is out there in production, live, sometimes in just a few hours (and I watch our error reporting system to see if it blows up or not).
It's a completely different mindset / process. I've worked with folks who worked at very large corp and they weren't doing anything differently than I do, but in my more informal / not a lot of review environment they struggle. They're good, they're not bad, they just are so used to so many eyeballs / not used to talking to customers (and distilling what they say) / they're used to so much confirmation that they freeze up in a way. They can do "It" it's just "It" in a new context is hard.
Granted I might struggle in a more formal environment, I don't know I haven't tried it.
But the same "It" is not the same "It" everywhere.
The "it" person sits around feeling uncomfortable and is inevitably asked to work on something they don't really know how to do and doesn't want to learn. They usually leave before the company ever gets to the point where the relationship is useful.
It turned out the whole of the job was optimizing SQL queries because you were not allowed to touch any other part of the application because that was all handled by jealous developers in Norway.
They wanted people who could do it, but they didn't actually know what it was.
Also they know where it is, in a 1000 different excels haha
Was incredibly uncomfortable needing something done and knowing I'd be told to get him to do it. His unhappiness with his position was palpable.
I think I am more tactical in my approach to my career, rather than strategic. I don't really have an end goal. I am not looking to maximize income or climb to the top. I see people racing ahead of me every day, younger people chasing up the corporate ladder to earn millions or get that VP role at BigMegaCorp. And they are so successful. And I know that isn't in my mental makeup to want that.
I made a comment on another thread about "I will stop work the day that I die" and someone else pointed out that was the saddest thing they ever read. For me, it isn't. Because I don't define "work" as toiling away on a souless project without meaning, or building yet another CRUD app (doing "it"), or not finding meaning in my work.
I play.
Every day.
And I'm happy.
And when someone tries to get me to do something that is more like "bullshit jobs", I'll tolerate it for a while if it is "we need to do this to ship." I am willing to do whatever it takes to make the project a success, and if that means I have to push a broom about for a while, cleaning up dust, I will. But if my role becomes permanently that, and we've shipped, or we keep delaying our ship date and the bullshit goes on too long, I wander off to find something else to play with. I do what I do out of love for my work, but not out of love for my job or love for a company. I'd do the kind of work I do for free, even if I wasn't getting paid. But I still want to get paid for my production. I think I have an incredibly privileged position and I realise that probably 90% of software engineers, if they are honest with themselves, probably are doing absolutely meaningless work that nobody wants.
Sometimes I am a W2.
I am a contractor right now.
Because the company is new.
But I will probably be W2 one day very soon
Possibly tomorrow. Or by the next cheesey moon.
As to how?
I build "stuff." Then I show "stuff" to them.
Them being people, them who run companies small and really big.
It takes me to new jobs. Or brings in a gig.
I message everyone on LinkedIn. And at hackathons too.
And meetups, and greetups, and gatherings old and new.
Anywhere I can think of, reach out to people in the Bay,
and those NFT'd out weirdos down in L.A.
Sometimes directly in Frisco, and that one guy at Cisco.
And then them say "can you come here and work for us to build 'stuff?'"
And we talk about fun things as I walk through the code.
And sometimes I find out, in the course of the day,
they are really building "it" which I've already before built,
and I say "no, not interested" and we go on our way.
Other times it turns out they want to build "it+that"
but they don't know how to build "it"
but do know a world about that "that"
And somewhiles it is the other way round
They've got the shape of the problem
But not the geometrical bound
Sometimes the glue that bonds "it" and "that" doesn't work
and I come up with some new formula for the glue that will stick
And somewhiles it don't pay well, but it's the problem I pick,
My career might seem strange to them that build "it"
But I'm happy for me, because don't I give a shit
I've talked with entrepreneurs, they'll say
"We're planning on send a Musk to the Moon"
But he asks always impatiently 'will it be soon?'"
Turns out they're just building yet another crap app
I'm always happiest when stacking "that" on to "it"
Sometimes I'll add one, five or eleven to see what will fit
There's an upper, upper limit of the stacked up "that"
Sometimes it's nine, more likely sometimes its four,
But if we just keep stacking, eventually I'll look for the door
I once had a project where they'd divided "it" by zero
And I got to fix "it", and look like the hero
I'll go to my grave, working each day
And my last words will be "I had fucking fun, I say!"
Thank you.
Of how to sell a skill set into saturated markets
Really nobody cares, what school you attended or subjects you studied
They don't care if you were turtleish slow or rapidly hare hurried
When it comes down to avoiding the build out of another crap app
Of avoiding those jobs that you would describe as bullshat
You just simply show them of what you can do
How you've managed to stick together "it", "this" and "that"
With a wonderfully super sticky new glue
And so repeat after me
It isn't the product that you sell, but the story you tell
The person who did "it" before may not actually be able to "it"; they rode the coat tails of a person who did "it". This "not it" person will often attempt to reframe the problem as one existing in one of the other areas; either as something were they are an "it" person or as "not my problem".
The response to a "things are broken" may not be Leader: “Wait, I didn’t know things were that broken” but may actually be Leader: “Wait, these things aren't broken in any way, don't touch those things.”
This is not actually a criticism of the article, just if you are trying to apply the article as a leader you may have a "not it" situation or, if you are trying to apply the article as the "it" person, the problem may be the leader.
If we're talking meta issues, my far bigger pet peeve is how the market only wants to people who can do "it" to the point anyone who can't is expected to learn through observation, which loops back to most people only riding others' coat tails. It's cute in theory but in practice, most people need to try it a few times before having a firm grasp on the matter. Then it turns out, most desired skills aren't so obscenely difficult and arcane you couldn't just throw in a decently smart person at it and figure it out, as most tools are designed to be picked up in a short time (you know, like good, widely adopted tools are supposed to be).
The entire thing sets up a job market which supports "fake it till you make it".
To the point where they hire people who did "it" and failed badly only to have them fail again because they can't do "it".
To senior roles and leadership roles because risk aversion seems to be the most prominent driving factor behind any corporate decision today, and these roles tend to have more responsibility to up the anxiety some more.
To junior roles because almost every market has so many juniors they are able to make insane demands, and a general shift in idea from "they will grow with us" to "give them the minimum and see if they will stick around". Coupled with loads of "do your dues" years where one learns almost nothing, but is frequently met with leaders who prefer someone with experience to work on the problem / new project instead.
The latter is especially amusing since it leads to the lack of seniors capable of bridging that anxiety gap (read: seniors who are only seniors by YoE). Anyone who has looked a little into learning methods, gamification and such can also tell dripfeeding challenges is one of the worst ways to teach people, and how insanely quick people can learn when thrown in the deep, let alone feeding them challenges of increasing difficulty at a fast pace (with some measure of safety to cover failures).
It has probably chaffed off of me to some degree, but our company owners are of the same cut of wood. In some selected spots, we very much look for people who have done "it". We need people to sit down with a new laptop and solve our problems in these areas and there is no real idea of how it should be. That's what we want to pay money for, to buy time spent learning.
But we also have positions open for which we just look for smart people with some linux background, effectively. We're entirely ready to put in work to make the person we hire successful. For example, we're open that we're looking for a linux and networking engineer and we're happy to work for it with the candidate. We can teach, we have budget for books, courses and conferences, so let's go. And that's how it should be, in my book.
I can name examples of both cases for Europe, I'm sure a few American devs can name examples of both cases in the US.
From what I can tell about where I live, the moment you try to move to mid level or higher, you're expected to know "it" already. It also isn't just vertical or horizontal skill progression. Its both, at equal rates. More skills, and each skill is expected to have 2-3 YoE. From a risk management position, most of those skills are not something you want juniors to work with in their first or even their second year. Most juniors would progress skill A for a few years, then start progressing skill B adjacent to A. So A would be at 5 years, B be at 3 years. Expecting "A 3 years, B 3 years" would be moot at that point, since the far majority with B at 3 years would be at 5 years in A.
Above is even worse when jobs are now expecting you to know skill C, but no one is really working with C yet. Now you need to have 3 years of experience in C, but realistically, no junior is going to be learning C on company time. More likely a few seniors will learn C and maybe distribute knowledge by the time the market is asking for 3 years of experience in D.
As said in a comment somewhere adjacent, the junior market is so saturated, many employers can make pretty insane demands. Good learning opportunities are combined with below-market pay where market pay already is a problem to afford a decent place. Good pay jobs basically expecting you to sell your soul. Or a company which seems great as a junior but then provides next to no opportunities to move up along with the associated pay increases (often only the former). The whole "do your dues" wouldn't be so bad if a comfortable income was guaranteed at a relatively low stress factor, but that's starting to be put into question due to socio-economical reasons.
Which is why there are so many webcrap startups. They don't have to solve any hard new problems. Just combine existing technologies to do something new. "Facebook for cats". (I once watched someone pitch that at a VC conference.)
I've been watching this happen in the metaverse space. Large 3D worlds full of user-created content with high graphics quality and good responsiveness are an unsolved problem. You can have any 3 on that list now. All four, not yet. Serious people at Epic and Roblox are working on it and making progress. Over at Facebook/Meta, they've tried three times and blown through US$10 billion failing at it. The NFT crowd thought they could sell land in virtual worlds they haven't built yet, then throw something together and profit. Most of them either have crappy worlds that look like games from the 1990s (Decentraland, Cryptovoxels), have missed their roadmap deadlines for shipping a product, or just took the money and ran. The US Securities and Exchange Commission catches about two of the last category each month, and is starting to investigate some in the second category. (If you sell an NFT for something that exists, that's usually OK. If you sell an NFT for something that doesn't exist yet, that's a speculative investment and public offering of a security.)
Here's a video of Simon Wardley introducing it: https://www.youtube.com/watch?v=2IW9L1uNMCs
And for all the details here's a book: https://www.amazon.com/Wardley-Mapping-Knowledge-Topographic...
And book free online: https://medium.com/wardleymaps
Which is interesting to me because on the one hand he might be entirely right, but to my mind it shows a deep underlying problem with this way of thinking.
He even mentions during the talk that if you don't move to the way he's suggesting Google and Amazon will own everything, but I draw the opposite conclusion: If we do what he is suggests then Google and Amazon will own everything, because he's saying that we should be giving them everything.
Anyway, the issue with the method he's using is that it completely ignores economic incentives.
For example: If "building it yourself" costs 0.1% of what it costs to use a commodity product then that reality is not reflected at all on a Wardley Map, in fact a Wardley Map may push you towards using commodities blindly even if they do not make economic sense.
Granted: this is a conclusion I came to from his talk, I have not read the 600 page book.
Acme Startup needs to hire its first "HEAD of X" to steer X decisions because Acme Co's current leadership has failed in making those decisions and it has harmed growth.
Why are they hiring?
1. Acme Co's current leadership has failed to develop its existing talent to the point where an ambitious existing employee can leverage their detailed knowledge of the business to make a solid bid to do "It".
2. Acme Co's current leadership has developed its talent pool well, but can't promote to the sr mgmt team because it would be weird to have one person in their 20s in sr mgmt with everyone else > 40.
3. Acme Co's current leadership has deep cultural and functional flaws and the new hire isn't really what is advertised. e.g. investors are trying out a new CEO. Or there is no real product mgmt happening because the founder/ceo/coo/etc are "product people" and don't want to give up that control but have no time to do it, so they hire a "head of data" so that product decisions can be more data-based...
Now let me just draw a picture with some circles and lines to make all of this seem more abstract than it is.
Management wants to do "it" but isn't sure how to get there. They hire an expert, who determines that management is actually the thing keeping "it" from happening. [cue sad trombone]
> management is actually the thing keeping "it" from happening.
—If carpenters were hired like programmers.
http://www.jasonbock.net/jb/News/Item/7c334037d1a9437d9fa650...
- Peter Principle : Everyone is hired to the level of their incompetence. Consequently, the pool of people who had this job before is full of people who couldn't get promoted from it
- Market for Lemons: It is hard to tell whether someone has succeeded at "it". Consequently, you pay at average for those who suck at it and those who rule at it, but those who rule at it won't take the average pay.
- Market Dead Sea Effect: Everyone who is good at this role isn't in consideration because they're excelling at it and are going to get promoted to the next level. Those who are average at it are available and going to stay. Those who suck at it are very available and always interviewing but otherwise have the same history.
Personally, my heuristic is always whether we can detect an individual whose recent motion is upwards towards this role, i.e. optimize for f(x, ∆x) not just f(x). I'm hoping that high ∆x means the person is unlikely to end at a specific x.
If an organization doesn't pick up on these patterns that push people to leave because folks are too shy to share them, we get poor working environments and hiring patterns that are never fixed. It's easy to assign all the blame on these organizations and managers, but we have some options to help from the individual side as well.
Once you understand that nothing you can say or do in an exit interview will matter at all, then it makes sense to be as non-confrontational as possible in order to preserve any references you might have at that company. Prioritize your own career and well-being over any corporation.
EDIT: FWIW I've had zero issues with "references" with my past employers. All of them are open to me returning as well, so this idea of burning bridges by being honest in exit interviews seems mistaken.
If you're sincerely interested in changing course to affect your retention rate, then doesn't it make more sense to ask people why they might be thinking about leaving before they get another offer?
The most difficult and critical part of software development is requirements engineering. I will includes requirements negotiation as part of that.
Something that I have always had to fight against is the tendency to take business stakeholders at their word when they say they have a specific set of requirements or deadline. Project success often hinges upon modifying or rejecting supposed requirements given unambiguously.
The hardest part of this is that business analysts or executives prescribing requirements often have more seniority or political power in an organization than the software engineer. They also don't really know what requirements engineering is or that it is something the _software engineer_ _has_ to do.
It's necessary to understand the details of business problems and then do some level of analysis of how to address them with technology. The majority of projects have done about 50-90% of the necessary depth of business analysis and that is what they present to the programmer as a supposedly complete description. But pushing a little harder on those details it's often possible to find process descriptions scrambled, missing important information, and processes that really aren't required.
Once the engineer truly understands the business, they can think in depth about ways to use technology to deliver value. They can come up with design outlines for the software and think about how to break things up into different iterations. What is worthwhile in terms of programming effort versus business value. They cannot do that without having drilled down into details. It's quite common for an important detail to be omitted in discussions initially, which dramatically increase the programming difficulty or changes the approach. That's why it's so important to always be digging to uncover real requirements (and especially at the start).
Getting all of that resolved requires not only strong communication skills but also favorable political outcomes. If the project management isn't good, they can interfere or fail to provide support during the requirements phases and therefore kill any possibility of success from the start. But regardless of how good the managers, requirements need to be negotiated and agreed upon which is another challenge.
Beyond all of that, programming really is hard. If it wasn't, it would not be programming. It would be copy and paste or configuring existing software. The premise is that you have unique problems that have not been solved yet. So you need expertise but also strong problem solving skills. Which all the while you may be dealing with all the people issues at the same time.
The marriage of “I have money, you have talent” is all too often one sided. If the two parties can realize it is a marriage of convenience where they can play off of each other’s strengths, then it can be mutually beneficial.
> Tension mounts, and that approach inevitably fails as well.
I've run into this in a consulting capacity before. They wanted to address just one sticking point using a specific technology, I looked at it, saw a bunch of other potential pitfalls they would hit, brought them up, and it quickly became apparent we were talking across each other. They decided to just use a different technology, in their case, probably the right call for the immediate use case, but it did limit some future options. Not sure how things went long-term there, around if it was the right call for them ultimately or not, because once they were using a different technology they didn't have a need to keep talking to me about the first one.
So when talking about full time positions, I bring that up in the interview process. "Oh, you want to use X, let's talk more about why?" If it seems like a bad fit where what they actually need isn't what I'd be excited about working on, I'm less interested, hopefully they take that feedback and find someone who's a better fit. If they seem stuck on "but we just want to use X, can't you do that" then I know it's a bad fit culture-wise.
I asked for $50k above what a company offered me, thinking that we'd part on good terms; and they accepted.. So, I guess that's what I'm doing now.
Is this widespread? Anyone else noticed this phenomenon?
Companies: "We want someone who has done IT before!"
Perspective Hires: "I've done IT, I can do IT again!"
Also Companies: "Oh, so you've done IT? You seem over-qualified..."
Workers at the Company: "We should NOT be doing IT, IT is so five-years-ago!"
They say they want someone to do "it", they hire someone who has done "it". But then that wasn't really what they wanted done.
I think I can also draw the hypothesis that the more convinced they say they want "it" and/or the bigger the "it" they ask for, the less they actually want it when the time comes.
It usually took 6 months for them to understand the domain and the problems we needed to address, by which point they didn’t know how to execute because they didn’t have that experience.
Anyhow come to find out Chase does this weird thing were even if you press sign out in app it essentially keeps you logged in and if you're using biometrics you can effectively unlock the app and get right back in w/ Face/Touch ID. We didn't implement that but apparently this executive clicks sign out when their done using the app and still expected to get right back in so we had to rebuild that part. F my life.
If they can't explain it, chances are they don't actually understand it.
> Consider context when you're hiring and doing work.
I don't think any number of diagrams and attempts at categorization are going to help people who can't figure that out.
- scale our app to 10mil users - fix constant Oracle performance issues - build a data lake - migrate to the new HR system - reorg the IT because Price's law is destroying our bottom line - build a private cloud - design a new microservices-based e-banking app - sell the startup to a FAANG until the end of the year because it's running out of VC money
And when you do work at Big Co, there's a whole lot of Dilbert-esque stuff like this. Hence the prevalence of this type of material.
The HN community is way broader than just YC and their companies though.
With respect, i think it isn't and that the pendulum has swung too far on the other side. It is more likely that you will find purists who will attack anyone who wants to "make money on the internet" , to the point that people no longer post their projects here. E.g. it is impossible to state that you want to monetize your project via advertising and not get attacked. And yet the people who make those attacks overwhelmingly work in ads companies.