My Engineering Craft Regressed(lemmy.ml)
lemmy.ml
My Engineering Craft Regressed
https://lemmy.ml/post/30100312
76 comments
I think this is the part of the article that lands poorly with me. It lacks perspective. Why couldn't the people who evaluated those skills, demonstrated through those projects, pay the author? There are a myriad of possible reasons but some of them are in the category of "the result has marginal value".
I am fine hiring a junior developer that just does what is asked of them at a high level of quality. That is the baseline.
By the time you are a senior developer, I expect you to actively push back if you are asked to spend your time wastefully on marginally valuable things. Product managers should be able to explain to a reasonable person why a feature has value. A senior dev should be able to explain to project management why refactoring to reduce tech-debt pays off over time.
Is it possible that looking at the authors open source projects conveys the message:
"I am an exceptional coder with an unfortunate tendency to only consider the complexity of a problem or the elegance of a solution when considering the value of my work."
I hire talent like that... when I have the organizational capacity to see if they grow out of it.
I am fine hiring a junior developer that just does what is asked of them at a high level of quality. That is the baseline.
By the time you are a senior developer, I expect you to actively push back if you are asked to spend your time wastefully on marginally valuable things. Product managers should be able to explain to a reasonable person why a feature has value. A senior dev should be able to explain to project management why refactoring to reduce tech-debt pays off over time.
Is it possible that looking at the authors open source projects conveys the message:
"I am an exceptional coder with an unfortunate tendency to only consider the complexity of a problem or the elegance of a solution when considering the value of my work."
I hire talent like that... when I have the organizational capacity to see if they grow out of it.
> Why couldn't the people who evaluated those skills, demonstrated through those projects, pay the author?
You make it sound like the solution is obvious. It isn't. There are a lot of discussions that try to solve this problem, for FOSS as well as for other fields. Patreon, Gratipay, Crowd Supply and Kickstarter are just a few options that have tried to solve this problem with mixed success. There are many projects that are wildly popular or used in critical infrastructure around the internet that are chronically underfunded.
My opinion is that extracting funds from people online is a high friction event. When combined with FOSS projects that might be used by a large user base but where each individual derives benefit smaller than the friction of a funding payment, the project, or individual maintainer, has trouble with remuneration.
> "I am an exceptional coder with an unfortunate tendency to only consider the complexity of a problem or the elegance of a solution when considering the value of my work."
A pretty bad faith reading. Maintaining a successful (GitHub) project means dealing with community feedback, triaging and fixing bugs, writing documentation, popularizing/marketing and managing code contributions, at the very least.
You make it sound like the solution is obvious. It isn't. There are a lot of discussions that try to solve this problem, for FOSS as well as for other fields. Patreon, Gratipay, Crowd Supply and Kickstarter are just a few options that have tried to solve this problem with mixed success. There are many projects that are wildly popular or used in critical infrastructure around the internet that are chronically underfunded.
My opinion is that extracting funds from people online is a high friction event. When combined with FOSS projects that might be used by a large user base but where each individual derives benefit smaller than the friction of a funding payment, the project, or individual maintainer, has trouble with remuneration.
> "I am an exceptional coder with an unfortunate tendency to only consider the complexity of a problem or the elegance of a solution when considering the value of my work."
A pretty bad faith reading. Maintaining a successful (GitHub) project means dealing with community feedback, triaging and fixing bugs, writing documentation, popularizing/marketing and managing code contributions, at the very least.
> You make it sound like the solution is obvious. It isn't.
I explicitly state there are a "myriad of possible reasons" and chose to focus on a sub-set of them (again explicitly). What I did not explicitly state was that given the wealth of possible reasons that the reality is nuanced and non-obvious. So, I guess I agree with you? There is a lot of other discussions to be had.
> Maintaining a successful (GitHub) project means dealing with community feedback, triaging and fixing bugs, writing documentation, popularizing/marketing and managing code contributions, at the very least.
Ok, How about:
"I have all the skills to be a good team member with an unfortunate tendency to only consider my own opinion of what is valuable is when looking at work."
Looking at the author's profile at the year the author indicated, I see a monero (alt-tier cryptocurrency that was very popular at the time) tip bot and a runescape emulation server. These are both projects that would be exemplary of all those skills you and I mentioned and yet they show an affinity to working on "things I like" rather than things that have real world value. Later in their history we find other projects like emulating popular websites but those are not the "successful (GitHub) projects" they lean on.
As a hiring manager, I'd stand by my read.
Great coder... we need to interview and prepare for a lot of work on the soft skills of being a software developer.
Hiring is a crap shoot. I am very likely wrong about this instance BUT I still have to make a call looking at all the factors and I would be more comfortable with someone who seems less likely to need supervision even if they are less skilled at the "craft".
I explicitly state there are a "myriad of possible reasons" and chose to focus on a sub-set of them (again explicitly). What I did not explicitly state was that given the wealth of possible reasons that the reality is nuanced and non-obvious. So, I guess I agree with you? There is a lot of other discussions to be had.
> Maintaining a successful (GitHub) project means dealing with community feedback, triaging and fixing bugs, writing documentation, popularizing/marketing and managing code contributions, at the very least.
Ok, How about:
"I have all the skills to be a good team member with an unfortunate tendency to only consider my own opinion of what is valuable is when looking at work."
Looking at the author's profile at the year the author indicated, I see a monero (alt-tier cryptocurrency that was very popular at the time) tip bot and a runescape emulation server. These are both projects that would be exemplary of all those skills you and I mentioned and yet they show an affinity to working on "things I like" rather than things that have real world value. Later in their history we find other projects like emulating popular websites but those are not the "successful (GitHub) projects" they lean on.
As a hiring manager, I'd stand by my read.
Great coder... we need to interview and prepare for a lot of work on the soft skills of being a software developer.
Hiring is a crap shoot. I am very likely wrong about this instance BUT I still have to make a call looking at all the factors and I would be more comfortable with someone who seems less likely to need supervision even if they are less skilled at the "craft".
> but some of them are in the category of "the result has marginal value".
This is often false and lacks perspective too. Or closer to reality would be that people do use this work and simply don't pay for it. Maybe some complain if there is a security issue in a one-man-show library. In software this isn't unusual.
What you really mean is the "result is marginally monetized". Which itself has value ironically, but that is again a broader perspective.
This is often false and lacks perspective too. Or closer to reality would be that people do use this work and simply don't pay for it. Maybe some complain if there is a security issue in a one-man-show library. In software this isn't unusual.
What you really mean is the "result is marginally monetized". Which itself has value ironically, but that is again a broader perspective.
What I meant was "the result has marginal value". What I allowed for was a "myriad of possible reasons" of which this was a subset (and not even qualified as a large subset).
I agree, there is another valid subset in those possibilities that can be described as "result is marginally monetized" but in this instance, with the projects shown in the article, I don't think we are looking at core software libraries that everyone uses and nobody pays for.
I agree, there is another valid subset in those possibilities that can be described as "result is marginally monetized" but in this instance, with the projects shown in the article, I don't think we are looking at core software libraries that everyone uses and nobody pays for.
Of course, I didn't want to say it is entirely wrong. But not every project will be some foundational core project and you won't have one without the other. Neglecting such contributions because the authors might not do it for a marketable product is likely a sub optimal HR policy which leads to sub optimal business decisions and results.
We compare the usual corporate grind or corporate experience with these contributions. It is not the whole of problems in engineering hiring, but at least something to consider. The requirement of a product is an economic necessity but not something intrinsic to good engineering. And yet I think hiring decisions would strongly benefit to have further understanding of this particular value of problem solving, even if that alone doesn't meet the requirements of a successful business.
We compare the usual corporate grind or corporate experience with these contributions. It is not the whole of problems in engineering hiring, but at least something to consider. The requirement of a product is an economic necessity but not something intrinsic to good engineering. And yet I think hiring decisions would strongly benefit to have further understanding of this particular value of problem solving, even if that alone doesn't meet the requirements of a successful business.
> Neglecting such contributions because the authors might not do it for a marketable product
If you look at the other thread you sill see that I am not neglecting these contributions. I am simply not valuing them MORE than what they actually represent which is only a subset of the skills I'm hiring for in a good software developer.
> We compare the usual corporate grind or corporate experience with these contributions.
That's a false dichotomy and one I do not support.
> The requirement of a product is an economic necessity but not something intrinsic to good engineering.
I disagree, good engineering is about making the best decisions given the requirements of the whole problem and the resources available. You cannot discard some of the requirements because they are inconvenient to your preferred solution. The correct solution has to take the whole picture in to account. Your work may be at a level where the economic viability is a very small part of the requirements but fewer people actually have that luxury than think they do.
If you look at the other thread you sill see that I am not neglecting these contributions. I am simply not valuing them MORE than what they actually represent which is only a subset of the skills I'm hiring for in a good software developer.
> We compare the usual corporate grind or corporate experience with these contributions.
That's a false dichotomy and one I do not support.
> The requirement of a product is an economic necessity but not something intrinsic to good engineering.
I disagree, good engineering is about making the best decisions given the requirements of the whole problem and the resources available. You cannot discard some of the requirements because they are inconvenient to your preferred solution. The correct solution has to take the whole picture in to account. Your work may be at a level where the economic viability is a very small part of the requirements but fewer people actually have that luxury than think they do.
It is not a dichotomy, these types of experiences are valued differently, where one is disadvantaged over the other. And the relevant dynamic how one kind comes at the cost of another is described in the article.
Sure, a challenge in engineering can lie in contraints and if these result in more efficient engineering instead of bad quality, it has merrit.
But the requirements for efficiency are an entirely different class for businesses and most open source projects.
Some developers need some breaks from time to time to focus on what is necessary. For the sake of business. You should get rid of that quickly if you contribute for free to a project you care about.
Sure, a challenge in engineering can lie in contraints and if these result in more efficient engineering instead of bad quality, it has merrit.
But the requirements for efficiency are an entirely different class for businesses and most open source projects.
Some developers need some breaks from time to time to focus on what is necessary. For the sake of business. You should get rid of that quickly if you contribute for free to a project you care about.
How much (in dollars) do you think the contributors of ffmpeg have made due to their work on the project? How much (in dollars) has that project contributed to the media ecosystem? The correlation is probably off by several orders of magnitude
I find it easy to hold these two thoughts in my head:
Some FOSS projects are unable to extract a "fair" share of the economic value their product creates.
Some FOSS projects have marginal or non-existent economic value.
Looking at the article, I see more of the latter than the former. If this had been an opinion piece from Fabrice Bellard, I probably wouldn't have the same critical read. Also, Fabrice has had no problem finding gainful employment. Coincidence? Who knows.
Some FOSS projects are unable to extract a "fair" share of the economic value their product creates.
Some FOSS projects have marginal or non-existent economic value.
Looking at the article, I see more of the latter than the former. If this had been an opinion piece from Fabrice Bellard, I probably wouldn't have the same critical read. Also, Fabrice has had no problem finding gainful employment. Coincidence? Who knows.
Fully agreed, but without seeing his actual projects, who can say?
There is a screenshot of his profile in the article. You can pretty easily find those projects by typing in the org and username into GitHub. This was the route to check myself before responding.
Sit on the other side of the hiring process and observe the impact of your hiring decisions enough times and you'll see why.
I don't care (that much) about your projects because they don't tell me if you'll drop into my team and kill it with your ego. I can't fully understand the context in which you developed those projects. I don't want to search around and see if it's just a clone of someone else's work you're trying to pass off as your own, or if the community you've mentioned in your CV really exists.
I'm more concerned if you'll be able to consistently make it to our stand-ups. I will take a mediocre but steady, agreeable, and trustworthy developer I don't ever have to think about over a "rockstar" who is making life hell for the team every time.
I don't care (that much) about your projects because they don't tell me if you'll drop into my team and kill it with your ego. I can't fully understand the context in which you developed those projects. I don't want to search around and see if it's just a clone of someone else's work you're trying to pass off as your own, or if the community you've mentioned in your CV really exists.
I'm more concerned if you'll be able to consistently make it to our stand-ups. I will take a mediocre but steady, agreeable, and trustworthy developer I don't ever have to think about over a "rockstar" who is making life hell for the team every time.
Have LLMs gotten that good, that they can convincingly fake whole communities ?
"Some say this has already happened." - paraphrasing Douglas Adams
> I will take a mediocre but steady, agreeable, and trustworthy developer I don't ever have to think about over a "rockstar" who is making life hell for the team every time.
It seems to me from experience interviewing that every hiring process wants the candidates to be both. Humility, agreeableness, trustworthyness does not get you a job.
By my estimation, it goes like this:
Being 70th percentile of leetcode test takers + all of those traits gets you a job.
Being 80th percentile of leetcode test takers + 2/3rd of those traits gets you a job.
Being 90th percentile of leetcode test takers + 1/3rd of those traits gets you a job.
The difference between being 70th and 90th percentile of leetcode test takers is practically nothing compared to what it takes to get up to 70th percentile. Within the hiring process, the whole point is to root out mediocre leetcode test takers, as they are seen and derided as "fakers" who can't code, regardless of their professional experience, shipped projects, number of code commits, or references from people who manage coders. The industry and hiring process hates "fakers". Other programmers hate "fakers". Especially the ones who are the "rockstar" developers hate "fakers" the most - everyone knows about that group of socially problematic (ie: borderline sociopathic) but powerful developers who will reject almost every candidate. This is seen as a good thing - a "bad hire" is seen as the worst possible outcome of any hiring process.
If we stopped running software engineering interviews like a game of werewolf, we might accidentally start valuing the type of people you would rather work with - and maybe it might actually make software a more pleasant place to be.
It seems to me from experience interviewing that every hiring process wants the candidates to be both. Humility, agreeableness, trustworthyness does not get you a job.
By my estimation, it goes like this:
Being 70th percentile of leetcode test takers + all of those traits gets you a job.
Being 80th percentile of leetcode test takers + 2/3rd of those traits gets you a job.
Being 90th percentile of leetcode test takers + 1/3rd of those traits gets you a job.
The difference between being 70th and 90th percentile of leetcode test takers is practically nothing compared to what it takes to get up to 70th percentile. Within the hiring process, the whole point is to root out mediocre leetcode test takers, as they are seen and derided as "fakers" who can't code, regardless of their professional experience, shipped projects, number of code commits, or references from people who manage coders. The industry and hiring process hates "fakers". Other programmers hate "fakers". Especially the ones who are the "rockstar" developers hate "fakers" the most - everyone knows about that group of socially problematic (ie: borderline sociopathic) but powerful developers who will reject almost every candidate. This is seen as a good thing - a "bad hire" is seen as the worst possible outcome of any hiring process.
If we stopped running software engineering interviews like a game of werewolf, we might accidentally start valuing the type of people you would rather work with - and maybe it might actually make software a more pleasant place to be.
Holy dichotomy batman.
Seems like hyperbole to illustrate their heuristic.
I don't disagree with their point. Difficult teammates drain the productivity of everyone around them.
I don't disagree with their point. Difficult teammates drain the productivity of everyone around them.
I don’t know how to articulate properly it but the comment in the parent is a response does not address the specific essay. Maybe the writer had another, related essay in mind but nothing they respond to is present in the essay I just read
I’ve seen similar, and the engineer not only had thousands of GitHub stars and forked projects, but they were an excellent team player, natural leader, and terrific developer. What I did see, even then, was sentiment similar to yours, coming from managerial levels above them. Where does the insecurity start, and where does it end?
There are multiple parts of the job.
Can you work with your team? Can you get management what they need to do their job effectively? Can you get what other teams need from you effectively? Can you do the technical work?
All of them are part of the job. If you're great at working with your team but management hates working with you, that means you're only doing part of the job.
(And sometimes, that's management's fault too, don't get me wrong!)
Can you work with your team? Can you get management what they need to do their job effectively? Can you get what other teams need from you effectively? Can you do the technical work?
All of them are part of the job. If you're great at working with your team but management hates working with you, that means you're only doing part of the job.
(And sometimes, that's management's fault too, don't get me wrong!)
Agreed. There a lot of skills you only learn by being in a team environment that make you much more valuable in that environment than l33t coding skills.
None of that has anything to do with Leetcode vs. open source?
The age old value vs perception of value dilemma.
The issue is that recruiters and many times the first few interviewers are not at all technical. They have all the time to make their outward appearances business aesthetic, and their skill won’t deteriorate dramatically without being used.
They will use keywords and industry jargon to find candidates; that’s after the AI siphon out the resumes without the “must haves”. You’re left interviewing with people who have a superficial, if not backwards idea of what they’re looking for, and tend to be personable enough reject any “off” personalities which are common in the loner coder types who might not care to update their LinkedIn every time they fart into the wind.
Sure you 5x your salary, but the real shame is that the best talent becomes underutilized and dejected as companies fill with shiny slick employees who know how to sell better than engineer.
The issue is that recruiters and many times the first few interviewers are not at all technical. They have all the time to make their outward appearances business aesthetic, and their skill won’t deteriorate dramatically without being used.
They will use keywords and industry jargon to find candidates; that’s after the AI siphon out the resumes without the “must haves”. You’re left interviewing with people who have a superficial, if not backwards idea of what they’re looking for, and tend to be personable enough reject any “off” personalities which are common in the loner coder types who might not care to update their LinkedIn every time they fart into the wind.
Sure you 5x your salary, but the real shame is that the best talent becomes underutilized and dejected as companies fill with shiny slick employees who know how to sell better than engineer.
> Waking up at 6am to make some commits, reading documentation on the subway, and coding to dubstep at night wasn’t getting me anywhere. But I was happy.
That's the key friend. put in your 8hrs and do what your bosses want at your job. but if open source work makes you happy, why not do that on your free time? don't do it to get a job or to pad a resume, but because it is fun. pick projects you enjoy and limit your contribution so that it won't affect your happiness.
That's the key friend. put in your 8hrs and do what your bosses want at your job. but if open source work makes you happy, why not do that on your free time? don't do it to get a job or to pad a resume, but because it is fun. pick projects you enjoy and limit your contribution so that it won't affect your happiness.
Also do this while you can if it makes you happy/fulfilled. I've found that having kids and just getting older means I have almost no spare time or energy outside of my 40ish hours per week for technical work. I wish I understood in my 20s and 30s just how much spare time and energy I had.
> "I wish I understood in my 20s and 30s just how much spare time and energy I had."
Wait I'm in my 30s and it feels like I have a lot less energy than in my 20s, does it get worse? Hey at least I'm mature enough to understand that I should be enjoying now.
Wait I'm in my 30s and it feels like I have a lot less energy than in my 20s, does it get worse? Hey at least I'm mature enough to understand that I should be enjoying now.
Energy pretty much gets worse every decade. One can compensate by experience. It would be great to have the twenty-something energy back but with the experience. :)
Besides working out and taking care of mental health, I would advise you to make an appointment to check your vitamins and testosterone levels. I had problems with that in my 20s. Sure, your energy will drop with age, but it should not be "a lot less" in your 30s if everything is good with your hormones.
Oh I only see it at the extremes, e.g. all-night flight, coding, or drinking will ruin my next 1-2 days, while in my 20s I'd be up and running almost immediately. I also did gain a bunch of weight during covid and now I'm getting it back out though, so that also makes a diff.
Edit: also, I'm comparing now with a full-time job + studying a language + free-time coding vs on my early 20s as an undergrad with all the free time in the world so...
Edit: also, I'm comparing now with a full-time job + studying a language + free-time coding vs on my early 20s as an undergrad with all the free time in the world so...
Yes, especially if you don't take care of your body and your mental health.
Life is literally all "use it or lose it". Stay active and fit, and you'll be active and fit.
The strategy works until you get badly injured or sick. Rebounding is harder with age, then you die.
The strategy works until you get badly injured or sick. Rebounding is harder with age, then you die.
I didn't really notice much decline in my 30s versus 20s. I was at my peak fitness around 41 (not as powerful or fast as my 20s, but way more endurance and strength). But my early 40s were a pretty rapid decline as I had a bad knee injury that involved a long recovery and we had two kids which meant sleep deprivation. At 43 now I'm on an upward trajectory again in energy/fitness but time is total dumpster fire - getting good at very efficient workouts and mental health breaks!
If you maintain the same baseline level of activity, not in my experience.
That's going to vary person to person I bet. Even if I had the time there's no way I could work out in my 40s now as much as I did and with the same intensity as my 20s, my body just won't take it and I need more recovery.
Oh definitely. Maybe I'm overly optimistic, but I think you can be in like the top 20% of physical fitness by just consistently moving and lifting weights.
That’s a significant part of why the wife & children lifestyle never appealed to me.
[deleted]
OP: this is the desired outcome - building stuff happens in the dark and is uncertain to lead anywhere, simultaneously there is a chorus of cheerleaders for doing the aligned thing.
best advice i can give is stay razor focused on the goals - and what allows you to achieve them:
1. don't lie to yourself about the utility of the project - nice to haves are not need to haves - almost every idea is bad and few are good and even fewer are good enough to spend 5 years on, and vanishingly small amounts of them are goldmines (see #4)
2. understand what provides true value - treat it with respect and only allow it to be known, if necessary, & carefully present it when necessary so that others understand its value. if _they_ don't understand the value - they wont pay for it and will not care, you have to speak _their_ language and not burn too much time doing it.
3. be kind to yourself & enjoy life while you're chasing the goals - you need close relationships and satisfaction to sustain you and keep you from ruining yourself.
4. look for lucky opportunities & take them.
best advice i can give is stay razor focused on the goals - and what allows you to achieve them:
1. don't lie to yourself about the utility of the project - nice to haves are not need to haves - almost every idea is bad and few are good and even fewer are good enough to spend 5 years on, and vanishingly small amounts of them are goldmines (see #4)
2. understand what provides true value - treat it with respect and only allow it to be known, if necessary, & carefully present it when necessary so that others understand its value. if _they_ don't understand the value - they wont pay for it and will not care, you have to speak _their_ language and not burn too much time doing it.
3. be kind to yourself & enjoy life while you're chasing the goals - you need close relationships and satisfaction to sustain you and keep you from ruining yourself.
4. look for lucky opportunities & take them.
I’ve run side projects for my entire career (over 30 years).
It definitely informed my day jobs, but they never knew (or cared). I did it because I loved doing it. I designed software to help out altruistic organizations, and got some good work done (that no one signing checks ever cared about).
Now, I’m retired, and working on my own stuff. I treat my work as a craft, and really enjoy it.
It definitely informed my day jobs, but they never knew (or cared). I did it because I loved doing it. I designed software to help out altruistic organizations, and got some good work done (that no one signing checks ever cared about).
Now, I’m retired, and working on my own stuff. I treat my work as a craft, and really enjoy it.
> I’ll collect some money and retire in a couple years. Hopefully the open source world stays the same until then.
This was my feeling few years back. But after some years working at companies, it doesn't feel the same to take my keyboard on my personal time and hack away. Sure it's still fun, but maybe there's more to life than that. Thinking that my energy for hacking away all night will return would be naive, though who knows, it'll be a new future. Maybe I will pick up woodworking, which seems to be the cemetery for devs, or renovate some Akiya, which is the equivalent here in Japan.
This was my feeling few years back. But after some years working at companies, it doesn't feel the same to take my keyboard on my personal time and hack away. Sure it's still fun, but maybe there's more to life than that. Thinking that my energy for hacking away all night will return would be naive, though who knows, it'll be a new future. Maybe I will pick up woodworking, which seems to be the cemetery for devs, or renovate some Akiya, which is the equivalent here in Japan.
the tone of this post is so weird. someone 5x'd your salary and couldn't do it while working on passion projects. am i supposed to feel bad for them?
The post is somewhat strange but I think the point of it is clear. Projects aren’t what land jobs. This is contrary to age-old advice of “build a portfolio to show off” which has been repeated for as long as I remember. At least since 2010 or so.
Instead the writer discovered what we all inevitably do. Companies don’t really care about what you’re capable of. They care strictly if you’ll bend over backwards, give up everything, and grind leetcode to make it through their arbitrary and demeaning hiring process. At least you can somewhat justify it at FAANG given you need an “efficient” way to weed out 80% of the 30,000 applicants you get a year. But this rot goes all the way down to the mom and pop e-commerce startup anymore.
It’s no surprise. I suppose if the writer was a major contributor to a larger project their experience might be different (as you could probably fool ATS and HR using them as experience on a resume). But indeed, no one cares about your toy implementation of a linter.
It’ll only get worse in the age of AI slop, AI slop brained company leadership, and leetcode supremacy.
Instead the writer discovered what we all inevitably do. Companies don’t really care about what you’re capable of. They care strictly if you’ll bend over backwards, give up everything, and grind leetcode to make it through their arbitrary and demeaning hiring process. At least you can somewhat justify it at FAANG given you need an “efficient” way to weed out 80% of the 30,000 applicants you get a year. But this rot goes all the way down to the mom and pop e-commerce startup anymore.
It’s no surprise. I suppose if the writer was a major contributor to a larger project their experience might be different (as you could probably fool ATS and HR using them as experience on a resume). But indeed, no one cares about your toy implementation of a linter.
It’ll only get worse in the age of AI slop, AI slop brained company leadership, and leetcode supremacy.
"This is contrary to age-old advice of “build a portfolio to show off” which has been repeated for as long as I remember. At least since 2010 or so."
The thing is this not only used to work, it was The Way. You could short circuit the entire technical interview process by sending a link to your commit histories on various open source projects or hell even your GitHub account if you had decent amounts of public activity on there. Even better, a company's unwillingness to accept these in lieu of infantile "coding tests" was a great way to weed out bullshit organizations you wouldn't want to work for in any case. Now that none of that is the case I haven't the faintest idea how one would go about getting a job writing code these days short of leveraging your network to score a nepo hire?
The thing is this not only used to work, it was The Way. You could short circuit the entire technical interview process by sending a link to your commit histories on various open source projects or hell even your GitHub account if you had decent amounts of public activity on there. Even better, a company's unwillingness to accept these in lieu of infantile "coding tests" was a great way to weed out bullshit organizations you wouldn't want to work for in any case. Now that none of that is the case I haven't the faintest idea how one would go about getting a job writing code these days short of leveraging your network to score a nepo hire?
I have spoken to a few people in the "recruiting industry". In particular, one CEO of one. Both were rather frank discussions. Both told me that it is a complete waste of time to submit resumes and do follow up calls. Rather shocking. Indeed, they both suggested that networking and/or being nepo-hired is basically the only way you'll get in somewhere. That isn't a "big company with big goals" somewhere. This is a trend in almost every sector of software. If you're like a lot of people and need remote work due to not living in one of the 3-4 major tech hubs it's even harder.
I do remember a time when projects mattered. I believe my open source work 12 years ago was what got me the job even after I failed their coding test miserably.
It probably won't get better for a long time. I've been casually looking around for a new gig and even with over a decade of experience in software across the backend stack (bare metal and up) I don't fit a lot of the requirements. They want junior engineer grind, mid level pay, and staff+ level knowledge. As expected, it's a employer market now, and we're probably gonna be waiting for the glut of new CS grads, bootcampers, etc to give up and move on to other things.
I do remember a time when projects mattered. I believe my open source work 12 years ago was what got me the job even after I failed their coding test miserably.
It probably won't get better for a long time. I've been casually looking around for a new gig and even with over a decade of experience in software across the backend stack (bare metal and up) I don't fit a lot of the requirements. They want junior engineer grind, mid level pay, and staff+ level knowledge. As expected, it's a employer market now, and we're probably gonna be waiting for the glut of new CS grads, bootcampers, etc to give up and move on to other things.
> probably gonna be waiting for the glut of new CS grads, bootcampers, etc to give up and move on to other things.
If we’re lucky, an Open AI collapse will have Lehman Brothers like ripple effects throughout the rest of the industry. Not only will that flush out the chaff, it’ll also burn out genuine talent, so competition in the aftermath will be easier.
If we’re lucky, an Open AI collapse will have Lehman Brothers like ripple effects throughout the rest of the industry. Not only will that flush out the chaff, it’ll also burn out genuine talent, so competition in the aftermath will be easier.
Although, FAANG is kind of an old acronym. Those companies (other than maybe Apple because they’ve always been weird) are more like Microsoft was, when the phrase was coined. In the sense that they are matured companies that aren’t striking out and building new things in new markets.
It wouldn’t surprise me if they’ve lost the “look at interesting portfolios” muscle and gained the “look at metrics” one.
Most people didn’t work at FAANG back then, right? You worked at FAANG because you were better than people who took the conventional approach, and the really competent growing companies could figure that out.
Not sure who the up-and-comers are now, though.
It wouldn’t surprise me if they’ve lost the “look at interesting portfolios” muscle and gained the “look at metrics” one.
Most people didn’t work at FAANG back then, right? You worked at FAANG because you were better than people who took the conventional approach, and the really competent growing companies could figure that out.
Not sure who the up-and-comers are now, though.
What I find interesting is that despite, as you said, FAANG doesn't really have the "genius appeal" it used to have they still demand it. You would sort of expect a company that is in the glacial stages of movement to have more capital and more leeway. If anything, the competition for these positions has gotten even worse despite the work not being anything close to revolutionary or novel at all.
I think they aren’t quite totally glacial yet. They are just well along the path. It is a continuous thing. I mean they hired a bunch of competent people over the last decade+. Probably those competent people just don’t the incentive structure to look at portfolios.
The competition should get harder; resumes-optimizers are much harder to compete with than thing-builders, in the game of getting hired, right?
The competition should get harder; resumes-optimizers are much harder to compete with than thing-builders, in the game of getting hired, right?
The point is that society elevates symbols to a level of importance above and beyond the things those symbols are supposed to refer to.
Thus people valuing the symbols of professionalism over actual engineering prowess; LinkedIn profiles over the person themselves; and LLM output over a human's actual thoughts.
Despite this person self-evaluating as having regressed in their engineering skills, all the outward status markers that are supposed to represent outstanding achievement are still there, and project a persona that is not congruent with the author's own self-image.
Worse yet, you must play this game of smoke and mirrors because you are "only seen when [you] do the fake crap like update [your] LinkedIn to celebrate 1 year at $FAANG."
This also reduces the signal/noise ratio when posers begin aping those same status markers in order to represent expertise where none exists. If you want to experience this directly, I suggest you attend some networking meetups and talk to the newer blood in the cybersecurity industry. Not exactly DEFCON 10 any more.
Thus people valuing the symbols of professionalism over actual engineering prowess; LinkedIn profiles over the person themselves; and LLM output over a human's actual thoughts.
Despite this person self-evaluating as having regressed in their engineering skills, all the outward status markers that are supposed to represent outstanding achievement are still there, and project a persona that is not congruent with the author's own self-image.
Worse yet, you must play this game of smoke and mirrors because you are "only seen when [you] do the fake crap like update [your] LinkedIn to celebrate 1 year at $FAANG."
This also reduces the signal/noise ratio when posers begin aping those same status markers in order to represent expertise where none exists. If you want to experience this directly, I suggest you attend some networking meetups and talk to the newer blood in the cybersecurity industry. Not exactly DEFCON 10 any more.
And a common blind spot around good software engineers is that software is the hammer for all nails.
Someone recently asked me if Mark Zuckerberg was a good engineer. I think the answer is a very, very qualified "yes." He knew enough to bash together a prototype in PHP of a social network site. But he was a very good problem-solver; he managed to find a tool space people found use in, and iterated on it until it got so good it dominated lives and became the primary communication solution for millions of people. He also knew enough about people to hire the right folks to do the hard (and tedious; the tedium should never be ignored) work to turn his prototype into product, scale it, and maintain it. And that's every bit as much problem-solving as implementing a breadth-first search to populate a "People you might also know" list.
He didn't need to have Knuth's Art of Computer Programming memorized to do what he did.
Software engineering (and the software it creates) are tools. They give us pleasure to use also. But the tools and the pleasure can become disconnected from what gives other people utility and pleasure without some heads-up checks from time to time.
Someone recently asked me if Mark Zuckerberg was a good engineer. I think the answer is a very, very qualified "yes." He knew enough to bash together a prototype in PHP of a social network site. But he was a very good problem-solver; he managed to find a tool space people found use in, and iterated on it until it got so good it dominated lives and became the primary communication solution for millions of people. He also knew enough about people to hire the right folks to do the hard (and tedious; the tedium should never be ignored) work to turn his prototype into product, scale it, and maintain it. And that's every bit as much problem-solving as implementing a breadth-first search to populate a "People you might also know" list.
He didn't need to have Knuth's Art of Computer Programming memorized to do what he did.
Software engineering (and the software it creates) are tools. They give us pleasure to use also. But the tools and the pleasure can become disconnected from what gives other people utility and pleasure without some heads-up checks from time to time.
To put it more succinctly: businesses want to hire people that will help them make money. The ability for a programmer to make money for a business is not as tightly bound to perfect code and passion projects as this person, and many programmers, think.
I don’t like this definition of “good engineer” because it seems degenerate with “good businessman” or “good product designer.”
He was a bad engineer: early implementations of Facebook were buggy, insecure, and not featureful. I agree that engineering is not valued in-and-of itself generally (it is just a tool), but instead of turning it into something inherently valued by changing the definition of it, we should just admit that it isn’t valued in-and-of itself. I mean, in all fields (other than some art, maybe) the end result is valued more by outsiders than the process to get there…
He was a bad engineer: early implementations of Facebook were buggy, insecure, and not featureful. I agree that engineering is not valued in-and-of itself generally (it is just a tool), but instead of turning it into something inherently valued by changing the definition of it, we should just admit that it isn’t valued in-and-of itself. I mean, in all fields (other than some art, maybe) the end result is valued more by outsiders than the process to get there…
He successfully pushed a product out that worked well enough to get traction and get popular.
Part of good engineering is knowing what problems to solve. Facebook early version was buggy and insecure and lacked features. And none of that mattered to the target audience enough to not use it; its value outweighed the pain points. A junior engineer can solve today's problems; a senior engineer can build against tomorrow's, and a staff engineer knows what problems should be solved and what shouldn't because time is a finite resource. The further you go up the ladder, the fewer problems can be solved by throwing the right algorithm at it with your programming tool of choice.
A dreamer and a hobbyist can put together a well-crafted site with five users. An engineer keeps working at solving the problems between there and five million, including solving them by building the systems to solve them and finding the people to work in those systems.
Part of good engineering is knowing what problems to solve. Facebook early version was buggy and insecure and lacked features. And none of that mattered to the target audience enough to not use it; its value outweighed the pain points. A junior engineer can solve today's problems; a senior engineer can build against tomorrow's, and a staff engineer knows what problems should be solved and what shouldn't because time is a finite resource. The further you go up the ladder, the fewer problems can be solved by throwing the right algorithm at it with your programming tool of choice.
A dreamer and a hobbyist can put together a well-crafted site with five users. An engineer keeps working at solving the problems between there and five million, including solving them by building the systems to solve them and finding the people to work in those systems.
Under this definition the best engineers seem to be sales guys.
At the places I've worked, sales guys get some say in prioritization of features, but rarely in prioritization of their implementation.
I would say the distinction is good sales guys can turn market sentiment into a feature request, good engineers can turn one or more feature requests into behaviors in the system.
But the actual truth is that a sales team with some idea of how software is written coupled to lead engineers with some idea of market sentiment and taste is more powerful than either discipline heavily siloed.
I would say the distinction is good sales guys can turn market sentiment into a feature request, good engineers can turn one or more feature requests into behaviors in the system.
But the actual truth is that a sales team with some idea of how software is written coupled to lead engineers with some idea of market sentiment and taste is more powerful than either discipline heavily siloed.
>I suggest you attend some networking meetups and talk to the newer blood in the cybersecurity industry.
Not familiar with the industry, has cybersecurity taken a turn for the worse in some way?
Not familiar with the industry, has cybersecurity taken a turn for the worse in some way?
> am i supposed to feel bad for them?
He is not asking for that. He is explaining why he feels bad for not being able to continue delivering his top notch work that was done for free before and hoping to be able to do that again in the future. I appreciate that although I have never used his open source code.
He is not asking for that. He is explaining why he feels bad for not being able to continue delivering his top notch work that was done for free before and hoping to be able to do that again in the future. I appreciate that although I have never used his open source code.
I think the point is that his (perceived) engineering skills were far better when he worked on those passion projects, yet recruiters didn't care. But after grinding leetcode and joining a FANG the recruiters are knocking down his door despite him feeling like a much worse engineer.
Which is funny because I remember when people online swore up and down you needed open source projects online to get your foot in the door. It’s never been true, but if you’re lucky it might help. Part of me wondered if it was the industry itself spreading that around so they can continue to profit off the use of free software.
Best case scenario they were thinking of that one person (0.01% er) who worked on a project that absolutely wowed them. But then even the homebrew creator couldn’t get his foot in the door
This is about the myth of meritocracy, or at least, the myth that skills matter more than anything. While its /more/ true in software than anywhere else (where what is valued more is social signals, diplomas, other signifiers of possible skill), it has never actually been true in the way that many say it.
In my life I've seen the most brilliant, talented, driven, and effective people be completely unable to find paid work doing what they do best. This isn't even because there is no money in doing what they do best - many of those things are multi billion dollar industries. Its because they put all their points into a single skill tree. The second they start putting points into relationships, and manage to get past the early stages, suddenly their skills become relevant and it starts working, and they're seen for what they can do.
I suspect this is what happened to OP:
> During the day, I worked 8-9 hours for this startup, and until late at night I continued my open source contributions. Surely, they would take me somewhere.
When you play Starcraft at a decently high level, scouting is super important - not even necessarily to see what the other side is actively doing, but the important information to learn is what they cannot be doing. If they have 3 of one building producing units, they can't be building a different type of unit. I shoe-horned that Starcraft analogy to say: if you're spending every waking hour coding, you're unlikely to be building relationships. Especially if your goal is to be paid for doing something useful, relationships with people with money to pay you are necessary.
I'm almost certain I'm not as talented an engineer as the OP. I have my moments, but my attention and desire to work out different skill trees is too high to prioritize time like they have. All this to say: there's a lot of myths out there about what is valued, and if you take some advice literally you will find yourself pidgeonholed into doing exactly that and only that.
In my life I've seen the most brilliant, talented, driven, and effective people be completely unable to find paid work doing what they do best. This isn't even because there is no money in doing what they do best - many of those things are multi billion dollar industries. Its because they put all their points into a single skill tree. The second they start putting points into relationships, and manage to get past the early stages, suddenly their skills become relevant and it starts working, and they're seen for what they can do.
I suspect this is what happened to OP:
> During the day, I worked 8-9 hours for this startup, and until late at night I continued my open source contributions. Surely, they would take me somewhere.
When you play Starcraft at a decently high level, scouting is super important - not even necessarily to see what the other side is actively doing, but the important information to learn is what they cannot be doing. If they have 3 of one building producing units, they can't be building a different type of unit. I shoe-horned that Starcraft analogy to say: if you're spending every waking hour coding, you're unlikely to be building relationships. Especially if your goal is to be paid for doing something useful, relationships with people with money to pay you are necessary.
I'm almost certain I'm not as talented an engineer as the OP. I have my moments, but my attention and desire to work out different skill trees is too high to prioritize time like they have. All this to say: there's a lot of myths out there about what is valued, and if you take some advice literally you will find yourself pidgeonholed into doing exactly that and only that.
>if you're spending every waking hour coding, you're unlikely to be building relationships.
I think this is a critical skill that our industry hasn't done a great job of building, and I think few industries do that well. Engineers have a stereotype of being bad at this by default and there isn't much clear help on how to improve, in contrast to the many freely accessed guides on how to improve with technology.
Also, I love the Starcraft analogy <3
I think this is a critical skill that our industry hasn't done a great job of building, and I think few industries do that well. Engineers have a stereotype of being bad at this by default and there isn't much clear help on how to improve, in contrast to the many freely accessed guides on how to improve with technology.
Also, I love the Starcraft analogy <3
The following is less mask-on comment directed at neurodivergent people, as I'm neurodivergent and have people as a special interest, and often am in the position of helping people with social skills. I'm code switching, which is why my pattern of speech might not match other times I've commented.
In my experience, any direct help or advice on improving relationships doesn't work. Building relationships first requires one to value people and relationships, which when you're the type of person to take to computers over people, its usually for a reason: people can be jerks, they're unpredictable, and in a lot of nerds and neurodivergent people's formative years they're both wildly immature and often cruel. This can turn people off of other people as an interest for a long time, even a lifetime. Some find good outlets or the right group, and develop a sense that people are valuable, but often people are not seen as a reliable way to get needs met, or they find themselves in a very insular group that devalues other groups.
Most of the business world is run by not-nerds, by neurotypical people, who found that developing relationships would be the key to their success. This is inherently a foreign language, it has a lot of well-known downsides (hype-trains, incentives for agreeableness over depth or correctness to name a few), but like, if you can't appreciate what the role is and how its valuable, you may not be able to interface with it well. Thankfully most tech/engineering management is a hybrid of nerd and people persons - if one is so deep into their exclusive interests that they can't interface with a hybrid engineering+people specced person, its a warning sign for their ability to maintain work!
In my experience, any direct help or advice on improving relationships doesn't work. Building relationships first requires one to value people and relationships, which when you're the type of person to take to computers over people, its usually for a reason: people can be jerks, they're unpredictable, and in a lot of nerds and neurodivergent people's formative years they're both wildly immature and often cruel. This can turn people off of other people as an interest for a long time, even a lifetime. Some find good outlets or the right group, and develop a sense that people are valuable, but often people are not seen as a reliable way to get needs met, or they find themselves in a very insular group that devalues other groups.
Most of the business world is run by not-nerds, by neurotypical people, who found that developing relationships would be the key to their success. This is inherently a foreign language, it has a lot of well-known downsides (hype-trains, incentives for agreeableness over depth or correctness to name a few), but like, if you can't appreciate what the role is and how its valuable, you may not be able to interface with it well. Thankfully most tech/engineering management is a hybrid of nerd and people persons - if one is so deep into their exclusive interests that they can't interface with a hybrid engineering+people specced person, its a warning sign for their ability to maintain work!
> It was sad to turn my back to, but it got me a 5x salary bump.
It feels like there's missing a step here, how did we get from leetcode to 5x salary bump?
> But what about my skillset? Despite significantly regressing
How can skillset regress 5 years after university? It's not like you forget coding skills, or the old projects disappear (even if stale) during that time
It feels like there's missing a step here, how did we get from leetcode to 5x salary bump?
> But what about my skillset? Despite significantly regressing
How can skillset regress 5 years after university? It's not like you forget coding skills, or the old projects disappear (even if stale) during that time
I've never liked the craft aspect of software, but at some point I think you'll turn it around and find the intrinsic value for yourself again to keep going at it.
FAANG will give you the perspective that software is just a hollow-feeling way to make money, which will eventually let you see the richness of what you were doing before.
FAANG will give you the perspective that software is just a hollow-feeling way to make money, which will eventually let you see the richness of what you were doing before.
It seems pretty simple: we get paid on the perceived business value of what we provide. Some organizations may take a holistic approach to determine that perception (our contributions to other things, and the advancement of the industry as a whole) or not.
Aside: is using Lemmy to host your own personal blog posts a thing? (suppose this is equivalent to running your own personal subreddit right? Kinda odd but works I guess)
Nice, so I can still be a professional monkey vibe coder? All I need to do is just grind leetcode, projects can go to hell?
The deep need for affirmation by others is a terrible affliction.
I mean yeah, you will (almost) never make it (money) on technical skills alone, someone with decent technical skills but amazing soft skills (social) will go much further than an amazing hermit coder
My Indeed profile shows I applied to over 600 jobs back then
...what?
...what?
This is the key part. You need to think about the money side as well as the skills side.
I agree with the author though, despite regressed skills you can still be more in-demand because of cachet. It does feel quite silly.