"Good developers" are hard to find. Average developers aren't even easy to find nevermind ones that are actually good. The paying them a good salary and treating them well, companies are right onboard with in my experience. The tech department has better working conditions that most other departments. I worked at one company and one of the marketing teams once had to leave a resturant before eating because their lunch time ran out. So they paid for their food and left without it. All the techies just looked on in shock. We came and went as we wanted.
But the thing of finding good developers is hard. Even if you target just the folks in the top 50% of the bell curve, it's still going to be hard. And in my experience you get a few lower quality developers in and the next minute you've got someone saying their AWS lambda solutiuon can scale to any level 10 minutes after their solution took down the whole system in cascading failures because it was returning 500 due to the non-serverless database not scaling... I swear to god, even the non-technical folk knew the guy was talking nonsense. And the thing is, these people can and will pass your tech tests because honestly tech tests aren't really good at showing you how good a developer is actually understanding things. They can write quicksort but have no idea, how to figure out the best way to scale a data export feature that is crashing because of memory limits.
And the thing really with no-code, you encounter a bug, you're possibly dependent on a third party to fix the bug. Not a good place to be in because they never care as much as you do.
Software is a team sport.
It takes a lot of different skills to run a company. Even at a tech company, tech isn't the only skill that matters.
That's really not true. You don't need to find a Linus or Ken Thompson for that enterprise system. All you need is developers with sufficient maturity to not be distracted by shiny objects, who are proud to build reliable secure systems with the most boring technology applicable (complexity is the enemy of everything, including security, availability and maintainability). These people are easy to find. Yes, you still have to treat them humanely and pay fairly, but finding them is easy.
One factor that may seem to make them difficult to find is the current interviewing landscape. If your hiring process is laser focused on hiring leetcode ninjas, you will staff teams full of leetcode ninjas. I will say the union between the sets (leetcode ninjas) and (maturity to favor stable solutions) isn't super huge.
If for anyone who is doing leetcode hiring (not specifically leetcode, but that mindset) and finding hiring competent people difficult, I can suggest to change your hiring practices and your world will change dramatically.
(Or don't, leaving even more competent developers for me to find even easier.)
How many departments are asked to check in every single day with what you did yesterday and what you plan on doing today?
If you honestly think being asked those 2 simple questions is not being treated well. You're going to have a hard life.
IMO this is absolutely crucial to understand about our industry, for programmers too, not just IT.
We're paid well because they can't avoid paying us well. But they don't want to let us in The Club of the actual professional or upper-middle class, in terms of perks and status (and, actually, pay in most of the industry, even in the US, doesn't quite rise to that level—$200k+ for mid-career-or-earlier isn't what most programmers see).
Frequent monitoring and things like open floorplan offices are part of that. High-status gets very little monitoring, and an office. There are tons of little things like this.
I think it may also be a minor reason our interviews are so god-awful (but I think the main reason is the huge players trying to reduce turnover to suppress the rate of wage increases).
When companies want a fully algorithmic way to filter for signal, it’s not because we think it’s a great process, but because it’s one of the only viable processes.
PLEASE explain to me what value leetcode-type questions provide over what good of a software engineer someone is!
Would that piece of information be helpful to you as you consider which candidates to invite to the first round of interviews? That is why companies do it.
A candidate who got 2 or 3 solved in 90 minutes is very likely to do much better on the rest of the interview and on the job than someone who couldn't solve any.
(I think a lot of people who can write code have a difficult time imagining just how many people both can't write code and apply for seemingly every posted SWE job listing.)
Haha. Hiring people is a job in and of itself. It needs a good eye for detail and intuition.
People are weird. Some days they write great code and hardly any serious bugs. Other days they need to look up a for-loop on MDN.
Here's simple task that I ask on interviews: write JavaScript function which works like setTimeout and uses setTimeout internally but provides a Promise result so it can be awaited. Very few people can write that kind of code. They actually have no idea what Promise is. They want to get in frontend position. How can you write frontend code if you have no idea what Promise is.
Long hours and little respect probably will vary from one employer to the next. However, I've been working as a developer for about ~10 years - most of it with a mid-size insurance company but the last couple with a large bank. I work longer hours than most of my colleagues, but I've rarely put in more than 50 hours in a week, and my average is probably closer to 45. And my non-engineering colleagues have always treated my fellow engineers and me with respect and an appreciation for the difficulty of what we do. If anything, they've usually been a bit too deferential.
YMMV, but I think our profession is probably among the best in the world for workers. If my child were about to enter the working world and had the ability + interest, I'd absolutely recommend this as a career.
However, being on call is representative of something. Your electric company has linemen ready to respond at 2AM because they provide a service which needs to be available 24/7. However, good luck trying to contact your dermatologist, accountant, physical trainer etc at 2AM.
For all practical purposes, above a certain level of management, you are implicitly on call all the time. However, the bar to clear to engage you gets higher the further up the leadership layers you go. A manager of a handful of teams comprising about 100 staff gets engaged for less serious fires than the CEO, but both are "on call". It might take the board of directors chartering a helicopter to get to the CEO's fly fishing cabin during the CEO's vacation if a situation warranting such presents itself, but the CEO is absolutely on call 24x7x365.
The complexity of what engages the on call person I suspect is what connotes status. Called for clearing out disk space: low status. Called for application outage that has stumped multiple technical teams: higher status. Called for a production outage impacting the next day's C-level reports that requires engaging other management: higher status. Called for heading off a shareholder proxy battle: even higher status.
Note here complexity doesn't solely reside in the technical realm, but frequently is rather a blend of technical factors, social factors, and quickly making impactful decisions in low-information situations.
Get some perspective ffs. This is the easiest, cushiest job I've ever had, and the only one where people with masters degrees often consider me their peer despite my 11th grade education.
Stop whining and join a union or something seriously. These are all minor and solvable problems.
Many IT jobs are paid hourly, don’t get health insurance, and some even get paid minimum wage. That said, I have had plenty of people describe their retail jobs as cushy because it’s low physical labor, inside with AC, and they don’t have to think.
Please get some perspective not everyone is in your situation.
I can't wait for low-code to get good. It's going to throw back in real time the obliqueness of the request:
"Validating most likely candidate solution..."
8 hrs later
"Solution failed to validate ... please try rephrasing request."
It may not be indicative of the industry at large, but most engineers I know get away with this by changing the framing "I'm working on a doc" or "I'm scoping this feature" etc. Obviously this does not work with sufficiently bad management.
Care to outline it for me?
They're even busier in public hosptials btw
I am a disorganized guy who hates authority and interruptions, and even so I have grudgingly come to realize that (strictly) 15-minute morning standups actually do increase my productivity.
What you really want is developers who understand your solution and your stack, and actively want to contribute.
And for that, you need a good team mentality, easy-to-read code, and a good onboarding. And avoid crunch time as much as possible, especially when a new hire arrive, because you want him to ask dumb questions asap.
[useless personnal anecdote because i feel great about my new workplace removed]
Why is a single dev able to take down your entire system without intention?
>They can write quicksort but have no idea
So don't use quicksort or identical questions and ask them more.
Your entire anecdote can just as well be held as testament of how a company's process is completely fragile. Which is at least a yellow flag as to what else it is hiding.
IT departments love this, because it's not their problem and they don't have to do anything except press reload in the third party's ticketing system.
You'd think the success of his model would be used elsewhere to reduce employer costs and increase retention (no SWE has left his org in 4 years). Instead other petty executives get pissy and poison the well.
Something is extremely off with modern corporate America.
But even a pretty low level developer is going to end up making important business decisions just incidentally as part of their job, because it's hard to specify out every little decision that could impact the business without basically doing the dev's job for them.
Businesses can embrace that or they can ignore it at their peril.
Everybody organizes people, decide how work should be done, and has to make a lot of little decisions that nobody could anticipate. Not with the same leverage as developers, but with important consequences too. Somehow, management experts can't accept this.
We establish a difference between jobs where that training is relatively short (and thus we can expect it to happen on-site by the company who can hire people from other positions and have them do the new job) and the jobs where that training takes many years and thus requires significant pre-commitment and long-term planning to ensure that they can be filled.
For the purposes of crude statistics we pick an arbitrary line and label the jobs with <1 year of job-specific training required (starting from generic knowledge e.g. highschool or a degree in some other field) as "unskilled" and >1 year job-specific training required as "skilled"; but the key point is that there is a substantial qualitative difference between roles where you can "swap" people from one industry to another, and roles where that doesn't make sense at scale - while some individuals do switch high-investment careers, you're not going to solve a pandemic-prelate doctor shortage by re-purposing excess lawyers, but in that same pandemic you can solve a delivery driver shortage by re-purposing excess cashiers. Similarly in IT, the jobs which can be done by putting someone through an x-week boot camp do need different treatment from managers and policy-makers than the tech jobs which do require much more training and/or experience.
That's how it's done at all the US software companies I've worked at, including Microsoft and some startups.
My current company does has done away with job-titles entirely and we make up whatever we want on our business-cards (within reason).
Bad managers thinks a managers role is all about making decisions. Great managers knows it's about enabling employees: great managers act more like secretaries, making sure everybody knows everything they need.
When a manager can communicate what is going on and what the strategy is, most decisions become obvious and this results in everybody agreeing to what needs to be done.
When the new CEO was brought on they started to listen to the junior executives. They poison the well by stating things like how what he is doing isn't necessary or slowing down their own goals.
Just humans being humans. As a result he will likely leave in <2 years. I don't doubt that his old org will falter extremely fast.
It seems like well run orgs with less people are highly susceptible to quick change than large useless behemoths. Seems paradoxical, but a common fate at many companies/orgs.
That’s because large corporations are typically run like communist states, where the workers have little say in their own work, and tyrannical unelected leadership sets up hierarchies that reward political infighting to build power.
Why don’t corporations try democracy and bottom-up decision-making? Is corporate capitalism incompatible with democracy?
You're describing capitalism, actually.
> try democracy and bottom-up decision-making
Those are called worker co-ops. They're very socialistic. And democratic. It's quite possible for them to be profitable, too.
There are plenty of highly paid engineers who couldn’t build a decent product given all the coffee in Shoreditch.
As a non-tech person, how do I know to whom I should give all this money? Maybe a hands-off CTO or a hands-on architect cum engineering manager? Or a product person? Or maybe a skilled UX designer? Or a good infrastructure person? Or a DBA, and in which database? Or should I lower the money and get cheaper people in all those roles? Or maybe outsource the whole thing to an agency?
There are plenty of stories of companies who have hired all the above on good money and built an over-engineered, unmaintainable mess that solved zero real world problems.
I would argue that instead of money, you should build it with patience. Hire slowly. Solve one small problem at a time.
This translates to hiring - if your job spec is nothing but buzzwords you'll attract the kind of people that "engineer" for engineering's sake and resume value as opposed to solving your business problem (hell, does the job spec even include the actual business problem you're solving beyond vague platitudes about changing the world and boasting about their VC funding?).
Salaries need to reflect it too - if you pay too low, the only people that can afford to work for you are those that do so for the resume value rather than the money or the fun of playing in an engineering playground and potentially becoming its lead - with again zero concern as to whether they're solving the business problem. The kind of engineer you'd actually want usually already makes good money and no longer needs the resume value nor can be bothered to over-engineer.
Even as a contractor I've had plenty of leads where it became clear they weren't looking for an efficient solution to their business problem but an over-engineered mess to expand their engineering playground and my counterpoints fell on deaf ears.
No, I believe the cloud stuff has evolved in a way that is just strange. I know I'm not stupid, and I look at this stuff with suspicion. This is why I'm going vertical by owning my entire stack (except Amazon S3 because it is awesome...)
I wish it was cheaper, but I can leverage it well.
Nobody would design it like that from scratch but having only already existing stuff to build on makes the end result more complex that the problem it solves requires
And have a compelling product ...
The second a difficult bug arises in your low-code (or, now, GPT-generated) solution, good luck.