My Engineering Craft Regressed
lemmy.ml
lemmy.ml
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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 disagree with their point. Difficult teammates drain the productivity of everyone around them.
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!)
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.
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.
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.
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.
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...
The strategy works until you get badly injured or sick. Rebounding is harder with age, then you die.
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.
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.
As someone who explicitly did this and is now out the other side: can confirm, this is the way.
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.
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.
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 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.
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.
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.
The competition should get harder; resumes-optimizers are much harder to compete with than thing-builders, in the game of getting hired, right?
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.
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.
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…
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.
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.
Not familiar with the industry, has cybersecurity taken a turn for the worse in some way?
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.
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.
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
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 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
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.
...what?