I'm surprised there is still so much friction about white collar jobs like programming.
One could think that by now, it should be easy for developers to "jump into" a codebase and suggest changes (aka pull requests). Turning the world of developer jobs into a fluid system that adapts instantly to demand and supply.
It works pretty well for Wikipedia, where everyone can jump in and edit articles. And then there is some hierarchical power structure, which assures high quality.
I wonder what the biggest hindrances are for software development to become this way.
It's a bloody mess and it has always been. My best interview was in 2006, at my first junior position, when the guy just asked my experience in Linux, what does "ifconfig" do, what languages I know, and I got a paid internship. They expected me to learn on the job, and I did. Now even the junior position have ridiculous requirements, and with 17 years of experience, I get ignored by a clueless recruiter because out of the 10 techs they use, I forgot to list the exact Linux distro they use on my CV, so I'm probably not good enough for them.
I keep hearing there's more demand (for engineers) than there is supply but I call bullshit. That might be true, but the employers make all the rules so even getting an interview this year felt more like winning the lottery than filling a supply shortage. And the lottery you've just won got you in the Squid Game. Now you gotta fight against 50 other candidates, which might be more desperate than you and gladly work for peanuts, 3 days in the office.
Fuck this. Even finding work as a mercenary^Hconsultant is a bloodbath. The only advice is "ask your network." If your network isn't hiring, it's back to the Squid Game for you.
I reckon even Fortune 500 CEO interviews are easier than the average software engineer gauntlet.
Yes, which is why the meme that there are more open positions than engineers is bollocks. That might've been the case in the era of free money (RIP 2008-2020), when tech was in a hiring spree and engineers switched jobs every 6 months.
> which might be more desperate than you and gladly work for peanuts, 3 days in the office.
Yeah, 3 days in the office is impossible to beat, they most be really desperate! /s
Now talking seriously, Software Engineering is a great career, probably the best out there. You don't need to work for anybody to make money if the big problem is the job market. You can literally create your job with a few months work. Now is every person capable of it? No, many don't have the grit and discipline. But that is not tech's fault. Is a people's issue. To call it Squid Game to get a 6 figures salary working from home is insanity.
Is it really as easy as "grit and discipline"? I find it hard to believe. Everything I've read about consulting work, indie gamedev, and one-man-SaaS apps has a similar message: that previous experience and luck are huge factors, and there's a lot of financial risk involved. Small businesses fail all the time for reasons other than lack of grit and discipline.
Previous experience is grit and discipline. The amount of it will have a considerable impact on anybody's success. Luck will help that extra bit that only people doing things will get.
"grit and discipline" and an idea. You have to come up with something worth building based on if enough people will pay you for what you build. That's the hard part. Every programmer has "grit and discipline" in spades.
> it should be easy for developers to "jump into" a codebase and suggest changes
You were either VERY selective/lucky with the code bases you had to work on or never worked on complex, old, legacy code bases.
Just consider the single case of having to construct a new request body for another system, without knowing what's needed. It has 50 fields, which are consumed by more than 10 downstream systems that all want a piece of it. Getting any of those fields wrong will lead to a wrong outcome in at least one of those downstream systems. You have no access to the source code of most of those systems, as it is a "principle of least privilege" company working on sensitive secrets related to, e.g. tax fraud detection and tax calculation, which actually doesn't matter as half of the code is cobol or pl/1 anyways, which you can't read. Looking at the git history, you can see no one who worked on the applications you have access to is with the company anymore. You have to find the current owners of all downstream systems, start a dialogue with them, figure out if their QA or yours will test your new request. Your only chance to get an automated e2e test you can trust is if the 60 year old QA lady who is with the company for 40 years now, who only works 20 hours a week because she has bone cancer writes one for you. Any externally perceivable bug or wrong calculation will lead to the minister of finance personally firing you. Yes, that was the second job of my life.
> I wonder what the biggest hindrances are.
Bad code quality, lack of useful and up to date documentation, high code complexity, high organisational complexity.
> Turning the world of developer jobs into a fluid system that adapts instantly to demand and supply.
Ah yes, the good old wet dream of non-technical agile proponents. Agile little cogs that provide perfect forecasting.
> I wonder what the biggest hindrances are for software development to become this way.
At least for our application, it's hidden/non-explicit dependencies and domain knowledge.
By hidden dependencies I typically mean that process X has to be done before process Y, or similar. Meaning you sometimes can't just rearrange things. A substantial integration test suite could help, but it's a tradeoff. Though often it be tricky to test, as it could depend on customer systems we don't have internal access to.
Domain knowledge is also needed for much of the code. Of course this could be offloaded to a senior, but then those tend to be the limiting factor. For our team, it's been more effective that all the devs have substantial domain knowledge.
> I wonder what the biggest hindrances are for software development to become this way.
Context and complexity. Jumping into a codebase and suggesting changes that add value to the company usually require having context of what the company is doing, who are the users, what's the product used for, etc. Not to mention how a lot of codebases are complex and understanding where and how to do changes is not something you can just do straight away.
> I wonder what the biggest hindrances are for software development to become this way.
The biggest hindrance are people desperately holding to their positions. Whether aware they'll be unable to find another job, got too easy and cozy in the current role, having mortgage or other debts, or some other circumstances. For them you can as well write code in "new message" window of Outlook.
One could think that by now, it should be easy for developers to "jump into" a codebase and suggest changes (aka pull requests). Turning the world of developer jobs into a fluid system that adapts instantly to demand and supply.
It works pretty well for Wikipedia, where everyone can jump in and edit articles. And then there is some hierarchical power structure, which assures high quality.
I wonder what the biggest hindrances are for software development to become this way.