Another problem is from the candidate's point of view: I've already done "It" before. I've been doing "It" for the last decade. If I move companies, I want to do "It+1" at the very least, more likely "It+2". It's not enough for me to simply do "It" again but at a different company. So many recruiters reach out with that pitch, and I simply ignore them now: "I see you have a great background doing 'It' at 'Company'. We're offering a role doing 'It' here at this company! Isn't that exciting?" No, it's not, actually. Now if you want me to manage a team of engineers doing "It", let's talk. If you want me to be Director of "It", I'll stop what I am doing and get on the phone with you in 5 minutes! But simply "Keep doing 'It' but at our company" is not even slightly motivating.
Past a certain point the +1 isn't something you can do on your own time. If you're looking to shift into more of a management role that's obviously hard to learn on a side project unless that side project is a full company with employees. Even pure technical skills can require certain scale; you aren't going to learn how to use k8s appropriately on the side because whatever you're doing on the side almost certainly shouldn't be using k8s at all.
"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.
> "Keep doing what you're doing but half the hours and double the salary" is something I would be tempted by
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.
Yes - there are people who win the lottery too. My point is that there isn’t enough for this to really be a thing we should put up as anything but fantasy. If you think you’re gonna get a recruiter who lands this in your inbox - buy lottery tickets instead.
I've encountered shops billing $300+ per hour for fairly routine types of software work. And yeah, that's still pretty far away from the $800/hr or so that would be 800k for 20hr weeks, but we're not talking super specialists there. And you're not gonna take home all of that if you're just an employee at that shop, but if you go independent or start your own shop... you suddenly have a higher ceiling for basically just "doing the same thing you were already."
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.
> 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.
Jim Simons has about 250 iq points. He may seem like a normal(ish) person, but he ain't. I'm not sure that anyone should ever assume they'll figure anything out the way he did.
And, he had lots of experience with math - he was insanely great at it. And then he took it and applied it.
At one point the ancient Greek philosopher Thales took his (at the time extremely arcane) knowledge of weather patterns and managed to leverage that into great wealth by predicting the olive crops. Allegedly, he did this in response to a heckler who had asked why, if Thales was an intelligent famous philosopher, he had yet to attain wealth.
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.
More importantly he learned how to manage genius. At his fund it’s not one or two people who are “the man”, each and every one of them are “the man”. This is what makes their outperformance so consistent. It’s incredibly hard to manage one genius in a room full of people across the IQ bell curve, let alone when all the employees (partners?) are in the 98th percentile..
Yup for sure. Nobody likes being managed by a relative fool, so you have about 10 people on planet earth who could have done the job. I'd guess it is waaaaay further out than 98th percentile though...
Are there recruiters out there who pitch based on hours and money? Every pitch I get is all about the vision/team/prospects for success. And, yes, "prospects for success" in some ways means "money" but they're never so explicit about it.
I would guess that doing the +1 and +2 is mentally and emotionally easier and more satisfying if it's during a hellish 60 hour work week than in a relaxed 10 hours you freed up by getting more pay and a 30 hour week to do something easy.
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.
As an expert in a particular area, this is exactly what I want.
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.
Despite that being my own philosophy as a candidate, I never thought about it this way as a hiring manager. I feel kind of dumb! Thanks for putting it this way.
I don't think there's a reason for you to feel dumb: there are a lot of candidates that are the opposite of the grandparent, and want to do "it" for the rest of their lives.
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.
> 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.
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.
A developer that isn't willing to learn new things won't be able to do CRUD for long.
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.
I mean I am willing to talk about keep doing it at the next company, assuming increase in rewards for doing it, but I am not going to be incredibly passionate about continue doing the thing that I really know how to do well as some recruiters seem to want, I will instead be pragmatic and professional.
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.
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 want to do "It+1" at the very least, more likely "It+2".
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.
I used to work in consulting where I had several hundred projects under my belt, and I think your objection is a bit shortsighted. It is possible to learn a lot by implementing something you have implemented before, but in a different context. Even if the problem turns out to be 80% the same, the remaining 20% can be a valuable learning experience. And if the pay is handsome, why turn it down?
Isn’t that one of the problems the article is getting at though?
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.
> Now if you want me to manage a team of engineers doing "It", let's talk. If you want me to be Director of "It", I'll stop what I am doing and get on the phone with you in 5 minutes!
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.
Attractive to whom? Probably not the person you're replying to. I imagine at this point in their career they have already heard of this whole "money" thing.
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.
Yea, I used to accept "Do 'It' for +N% salary" but homie don't play that game anymore. The problem with accepting additional comp without advancement is:
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.
It sounds like you're an individual contributor and want off that track and on to the management track.
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.
Very few companies have a legitimate “parallel but equal” tech track for IC’s that remains IC all the way up. At some point on the totem pole you end up managing. All roads upward point to it. I currently work for a company that has a robust stack of levels for software engineers, but nobody at the “director equivalent” tech level is an actual IC.
I love the concept of having VP-level IC “wizard” roles who don’t have to manage, but have never seen it in practice.
I've seen those roles at Microsoft, Amazon, and other big tech companies.. Like you implied, though, they all plateau in compensation around $800k or so.
These roles definitely exist, but it's worth counting the relative numbers at each level for Manager/Senior Manager/Director/VP vs IC's at that level.
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.
At my most recent company engineering managers made less than the engineers they managed and staff engineers usually made more than directors. So if you wanted to go the management track for advancement it meant a pay cut for at least a few years.
I can't speak for the direct OP, however outside of exceedingly large companies, rarely do you get to just be a major contributor and still climb past a certain point. Microsoft and Google have things like distinguished engineers but most people never reach these levels, because you have to be truly outstanding to attain them, and often, they too are really good at managing their sphere of influence.
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.
You hit it pretty spot on. There's still a lot of management expected at those levels, it's just of an influential type instead of an authoritative type. Which is often even harder to wield effectively. You're still expected to go out and force-multiply, because the bottom line is a single person worth of productivity can only go so far.
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.
> Instead, companies become obsessed with "coding culture," and "process" (which can mean many different things).
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've been reading the (perennially-recommended) Mythical Man Month with a friend, and this is something that gets touched on again and again. It's funny that for all the hilariously out-of-date components of those essay (development measured in compiler instructions written!), the inefficiency between a good architect and the number mean-regressed engineers beneath them is still a problem we struggle with half a century later.
Sorry, to be clear I wasn't trying to address/rebut/debate your skill, but rather just start from a presumption. Presuming what you're saying is true.
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.
For sure. It's still astonishing to me that if you measure by everybody's behavior, actually shipping something good in a timely fashion is often pretty far down the priority list.
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.
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.
"It," "It+1," "It+2," etc. can definitely be delivering software.
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."
Complete agreement—soup-to-nuts delivery of software for a particular ecosystem (Apple in this case) is definitely an "it" I can imagine companies hiring for.
This was my experience as a contractor, at least for my niche at the time. I felt like when I was an employee I was being paid to learn and adapt, but as a contractor I had one thing I was good at and only did that over and over again, which meant no room to grow.
Here's an additional option: maybe the person who they hired to do "it" never really knew how to do "it" in the first place, and was really good at selling themselves and overpromising and underdelvering, being really good at avoiding personal blame and making sure that any failures were attributed to the organization and not themselves personally. Basically, fakers. There are a surprising number of fakers at the C-level and VP-level who manage to hop from one organization to another, at best providing little benefit, but at worst leaving a destructive wake. Nonetheless management keeps hiring these fakers because others have done so before, and they need "it". Fakers cover their tracks by making sure to not stay at any one place too long, and hiring people below them to actually do the hard work, take over the mess (and responsibility). I wouldn't assume the people that management bring in are any more competent than management themselves. It's unfortunate but there are many serial fakers operating as COOs, CMOs, CIOs, VP Marketing, VP Product Development, VP Business Development, and a smattering of high-sounding but low authority titles such as Chief Innovation Officer, Chief "AI" Officer, and even sadly, too many Chief Data Officers. Those are the sorts of folks who tend to bring in these "playbooks" that look like they can solve the "it" problems but are all smoke and no fire.
Yes, and once you manage to somehow become VP of This or Director of That, your career is pretty much self-sustaining. Your next job will be always be VP of That or Director of This, and your next job, and so on. You just have to get that title once, and then you're golden--there will always be another company looking for a VP, and you're now "qualified" by virtue of once having that title. Have you ever heard of a VP that ends up moving back into Individual Code Monkey Number 42010 because he can't find another VP position? Sure, some of these guys "Semi-Retire" and go back to a coding job for fun, but that's not what I'm talking about. I'm talking about: "Boy, the market for VPs is tough. I might have to take a lifestyle downgrade and go back to being a regular old middle-manager!"
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.
It also happens when moving from startups to FAANG. When I was at Google I worked with a lot of senior/staff engineers who were previously titled director or so, and that's probably because of title inflation at startups but also Google downleveling people because thats the offer they gave the candidate. I do think engineering types often switch out of "director" or "vp" title roles more often than you might think.
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.
What you're talking about is social proof and while it's definitely a thing, it's not as precise as "you get this title once and you're a made man".
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.
Because at these levels, it's not about what you can do, but how you manage politics.
From a technical point of view, most of these people are useless and a waste.
Politics arises whenever people come together. It's comfortable to think that we can simply encapsulate "politics" as such, as something for the stupid people and we the enlightened rational technical people don't concern ourselves with "politics" but unfortunately one cannot simply wish it out of existence. Politics is just a label attached to human behavior. Put 3 people together and you will have "drama" (politics on the small scale). Better learn how to understand people's motivations and incentives instead of bitterly dismissing confusing human behavior as "politics".
Agreed. Moreover, the parent poster is overlooking that in a well functioning engineering organization, political influence is at least partly a function of competence.
Right, HN tends to be very bitter and depressive about dysfunction. Of course it's selection bias too, we talk more about our complaints than our joys. But it's a very gloomy view to think that anyone who rises in an organization does so through psychopathic manipulation and passing on the hot potato then through pure bullshitting, woos the higher ups and catapults up the ladder via promotion.
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.
Competence at politics is orthogonal to usefulness to the company. Often times incentives can push politics in self-destructive ways to the organization.
At those levels, unfortunately, they have both budget and authority, as well as the ability to impact culture and the definition and prioritization of teams and their work. Sort of like military generals who get their ranks not by proven experience but by working the chain of command, to the great detriment of those who actually have to face the fire.
Our Head of AI for an org of more than 700 people, had:
- 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.
This sounds interesting, can you tell us more? Were they doing this on their public github to get the role, or internally misrepresenting work as their own?
This is a pretty common view and flawed in my experience because people assume that excellence in “big role X” actually maps to “best at X.” In practice, the job of being “in charge” is often about navigating organizations, exacting meaningful change within the constraints of that environment and building trust with the other people at that level to enable your teams to have impact.
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.
I call them the Primadonna Locust. Announce Big Project inside (and outside!) the organization. Make it look shiny from day 1 but avoid all complexity rabbit holes. Keep all cans of worms closed. Make lots of presentations. Convince everyone into the cult of Big Project. Once it's delayed for too long, move to another, likely bigger, company eager to implement a copy of Big Project. Take anybody good at selling, prototyping, or technical. Leave the rest (losers) to deal with making Big Project work. Loser management will NEVER admit they got swindled, at least not in the open. Heck, they might even like how Primadonna Locust will hit their competitor as hard.
I'm gonna share my unsolicited opinion: if you're hiring, you want someone who is ready to do "it". He may or may not have done "it" before, and may not do "it" exactly as you had planned, but he has foundational core competencies, motivation, and the cooperative responsibility taking attitude to accomplish the key parts of "it" as best as you can foresee "it".
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.
Hiring for someone who has done it before is very common at the Principal and Staff Engineer level. As people get more senior in their careers there is more demand for specific skills and expertise not less.
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 have had the luck of working with this kind of trust from a company and it is a great experience. It can even work as a contractor. Case in point: for my current project I was hired to port a library from Rust to Java, but since the original library was not mature enough I ended up writing an independent implementation of what the original library was intended to do: a fake MySQL server that lets you handle user requests with custom logic.
I had never dreamed of things unfolding that way! Learned a lot and still enjoying it.
They are creating a BI platform and wanted it to integrate seamlessly with other existing BI tools. If you pretend to be a MySQL server, you can integrate it with almost anything. There is a high chance we will end up open sourcing the library :)
Company: "Here's some big problems, can you help?"
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)"
An average L7 at Amazon will see that "limit disruption to Y and Z" is simply a constraint to the engineering problem and make it work. That's sort of what makes someone at that level - the ability to detect the cost for moving different constraints and being able to demonstrate the technorganizational advantage from doing it.
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.
Of course. Implied in the senior developer's solution ("migration") is a plan to navigate those challenges - technically, politically and socially.
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?
My take is colored by the fact that I only engage as consultant/contractor.
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.
I've had more than one contract come back with a "you were right and the person we hired made a mess, willing to discuss this again"; I've even taken one of those contracts.
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?
This is more closely aligned with the way I think. The more of a cluster I think the project will be the more I charge and the more I change the terms of my contract to get paid regardless of the outcome.
I haven't been writing code professionally really long but one thing I notice is "It" ... even the same "It" can be dramatically different wherever you go and not everyone seems to be entirely aware of that or able to adapt.
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.
Another one I've seen quite often is management wants "it", and then they hire someone who can do "it", but the company/product isn't nearly ready for "it". Think hiring a DBA before you have 100 total rows in your database, or hiring someone to write an AI recommendation engine before you have any users at all.
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.
The worst job I ever got hired at (about 15 years ago) wanted asp.net, C#, html, css, javascript, xslt, and SQL.
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.
reminds me of data science 5 years ago - everyone wanted to say they hired data scientists, no one wanted to admit they didn't know where their company data was being stored
Worst case I've seen of that was a pilot hired to fly a private jet mostly being used as an unrelated to aircraft general maintenance man because there were no clients for the recently purchased private jet.
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.
My career gas been a little odd. I earn less than some, but more than most. But I don't ever really feel like I've worked a day in my life. I get paid ${ridiculous_sum_of_monies} to play with cool toys. I find interesting problems people have, and then I sign up for that. Some days are more difficult than others, but I am not interested building yet another "it." I am always looking for the "it+1" or "it+that" or "it*n" or "it/time" or "it=>(return null)"
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.
You sound like a slightly older version of me. And then I read your profile and you work in precisely the same field. I honestly feel that robotics is one of the few domains in which this kind of play can yield a sustaining and continually interesting career. I'm currently building an autonomous wheelchair for about half my usual rates just because it sounded fun. :-)
Sounds amazing. Can you offer some insights in how other people might apply your approach? Are you a contractor? How can you tell if someone is offering a job of the sort you want, and how do you convince the gatekeepers you can do the work well?
I like this article, but it assumes everybody is acting in good faith, so there is that meta issue that this article doesn't address. For example, two situations I have personally experienced several times:
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.
>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".
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".
It's interesting. Is this a difference between European jobs and American jobs?
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.
>Is this a difference between European jobs and American jobs?
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.
I think this definitely applies to leadership roles in product and technology. People really want someone who did it before and, usually, exactly this thing before.
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).
"No one wants to have a “rare problem”. But everyone wants to have a rare opportunity."
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.)
I found the article hard to read, I wish it were written more around a concrete example than the abstract. I found it hard to track all the abstract elements in my head which ironically made it harder, not easier, for me to generalise the ideas presented.
His conclusion at the end is that serverless is the future.
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.
This article circles around the most common situation where "wanting to hire a person who has done 'it' before but it's hard to find that person" arises: hiring for startup leadership.
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.
This reminds me of one of my first consulting gigs, where someone asked me if I could do "it" where "it" was something I had done before a couple times. Sure, I said. But then I get to the company, spend a few days and see enough to know "it" wasn't the problem at all. A bunch of other things were keeping "it" from happening and they didn't want to change those things. Thank goodness I was consulting and could bow out.
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]
This instantly reminded me of several past situations I've seen. Another common miss is that "it" isn't something the company needs at all. Or in some cases, it's not a bad idea, but there are ten other unrelated ideas the company should be addressing first.
The problem with hiring someone who has past experience at "it" is the Peter Principle + Market for Lemons + Market Dead Sea Effect.
- 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.
The other challenge with hiring someone who has done "it", is they may not want to do it again, especially in startup contexts. "Find me someone who has scaled the infrastructure of a fintech startup from Y to Z". Some people may enjoy the same challenge again, but lots may want some variation (eg different company stage, different industry, different scale).
Speaking personally, I can’t do It again, if It represents an apex accomplishment of mine. My apex accomplishments, I was able to do, only because of a special confluence of factors, never to be repeated. Fortunately, this forces me to seek new apex accomplishments, which keeps things interesting and growthful.
You can help alleviate some of this by being completely open and honest on your reasons for leaving a company (and it doesn't just have to be when you're leaving, btw). I know far too many people that are somewhat timid in their exit interviews and simply state "I found a better offer" when really they're frustrated with how "it" is accomplished in their environment. Anytime I resign, I'm brutally honest. Some jackass being nitpicking during code-reviews? That might seem minor, sure, but it's annoying enough to add to that unhappiness threshold which drives people to quit. I make sure it's known as a contributing reason for leaving.
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.
I'm going to be blunt. Unless you are a rockstar that is irreplaceable in the organization, no one is going to give two shits about what you say in an exit interview. Your management isn't totally blind or naive. They know whats going on, but there are always reasons as to why they can't or won't act to change the situation. Typically, its because their manager is unresponsive or unwilling to change.
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.
Disagree. That may have been true in the past, but it hasn't been the case for the past few years where employers bleed talent rapidly and are in dire need of anyone even remotely competent. I assure you, they are looking at exit interview data and it absolutely matters. A "rockstar" employee (I really hate that term, but I get what you mean) was a luxury many companies no longer have; now they're desperate to just keep the ship afloat with your average team. It's especially important to the many small businesses that have less than 100 employees - like my last employer - where individual resignations on a week-to-week basis is having huge impacts to deliverables. Even at the FAANG I'm currently at, it's very much an important data point.
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.
This is why my wife's company has started doing "stay" interviews instead. Basically its just an hour where everyone down the receptionist gets to bitch at senior management about whatever is bothering them.
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?
That's why companies do 1:1, retrospective meetings, and surveys, yes. People tend to hold back on those too, but of course creating friction while employed is much riskier than airing grievances when leaving a company. That's why I think it's important to get it all out at the end. It gives the employer another opportunity to complete the picture and understand the magnitude of which compounding problems enabled a poor working environment.
Isn't the point of having a PM to bridge the gap between leadership that knows the domain of "it" and IT who knows how to implement general business needs onto a technical solution? Of course that would require having a PM to begin with, instead of expecting your developers to become subject matter experts in your obscure domain.
They touched on something in the article but it deserves more emphasis.
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.
Yea they don't want us to think. I feel like they just see us as workers to implement their will. There have been so many times I've been asked to implement a solution rather than given an actual problem. Upon asking questions it becomes apparent what this persons thinks will solve the problem isn't a solution at all.
I see these symptoms most when the Venn intersection of “Doers” and “Deciders” grows too small.
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.
> Or, the new hire identifies the complexity in the situation, maps it to their speciality, but proposes a way forward that doesn’t match expectations. Leader: “Wait, I didn’t know things were that broken” or “this isn’t actually what we hired you to fix!”
> 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.
that's incredible! I suppose the lesson here is make sure you ask enough to keep you from looking over your shoulder and not being able to deal with the inevitable 'backfill blues'
Tangential to this point, but I've seen firsthand in a limited capacity but also heard of this from other devs, but there seem to be a decent number of devs who go from job to job doing the same thing over and over again. An example I've seen: a junior dev learns Springboot at a job, then goes from job to job converting their microservices to Springboot. When that project is complete (can take 1 to 2 years in some cases), they get bored or change jobs for a bump in pay and do the same thing again. As they do this a few times, they become a specialist in that field and they start self-selecting to only doing that one thing over and over and over again.
Is this widespread? Anyone else noticed this phenomenon?
Another common situation I've encountered is this one: They don't really want "it".
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.
The post opens with a false dichotomy. In general my experience has been that we hired someone that management selected because they'd "done it" before (always in very different contexts), they ramped up to our project, and it worked out pretty well. I don't think it's necessarily the best selection process, but selecting for prior experience is not a very serious problem in hiring imo.
We had these people come in at a company I worked at, the problem I found was “it” at this small to medium business was very different to “it” they had experienced at a large enterprise.
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.
The article mentions that you can copy & paste or mix & match playbooks. But, does anyone know where can someone get the reference playbooks to mix and match..?
I assume that this is why management is obsessed with hiring their competitors employees including developers. They want another but proven way of doing 'it'
we recently redid authentication in our app - was told to do it exactly like Chase did theirs which I thought was an odd requirement. Come to find out the corporate executives get Chase credit cards so they were all using the Chase app and familiar with it and essentially told the products owners to build it just like the Chase and then told me/us the developers to build it exactly like the Chase app. Shaking my head. How dumb.
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.
Why is that dumb if they gave you exactly what they want? Regardless of their motive, that is what they want and hire you to do. I do not clearly see your point here.
- 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
Solution: replace company leaders (who sound like they come from the financial sector, as they don't understand 'it', other than that others have made money off 'it') with engineers.
why is hiring/firing posts so popular here? As an indie dev it's kind of annoying to me, this was supposed to be an entrepreneurial community rather than a place for managers to vent every afternoon.
YC is a startup accelerator and VC. What do you think happens to the companies that grow after completing YC? Ideally they grow and hire (and sometimes, fire) people.
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.
Interesting comment. Personally I would say this hasn't been entrepreneurial community for a few years now. Mainly because a lot of people figured out it's easier to go make $X00,000 at Big Tech Co. than to take on the risk of a startup. Secondly the "market place" of ideas is pretty heavily saturated nowadays (imo), seems like unicorns are becoming less common, and the domains a lot harder where there are.
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.
