1,481 karma · joined November 12, 2021
However I think the OP drastically underestimates the proportion of wholly unqualified on paper people who apply for most jobs. I'd put it at 50% for most and up to 90% for some. So you can see why people go down the nepotism + chums route.
As someone who has a deeply weird CV and life experiences / social circle that is pretty much orthogonal to most techies it can be difficult, as the nepotism / chums route is not available. But just writing a cover letter to the JD and company gets me a fair way usually.
I am talking of course about scrum, story points, product managers, scrum masters, product owners, rituals, etc. All the crap and layers of indirection that sit between devs and the people who actually use the software.
Devs should be talking to and working with end users and building up an understanding of what users want and need from the software. I mean this literally. Actually sit with, work with, and talk to users, don't just communicate with them through an issue tracker.
You sometimes see this in early stage startups, but even startups often end up designing for VCs or designing to be acquired, rather than designing for users.
Yes users sometimes need training on how to communicate requirements, but it is up to devs to do this. Don't expect them to magically acquire this skill out of nowhere.
This thought is not fully developed but I'm drawn to the idea that if an intelligence is grounded in an understanding of a more base level of reality it will find it easier to generalize beyond any one given domain. I could be entirely wrong of course.
Virtually all software developers are building minor variations on thing that have been built hundreds if time before. Sure, maybe not by that particular software developer, but by a thousand others at some point, and half of those have probably stuck their code on GitHub so you can look at how they did it.
This idea that software developers are somehow cranking about beautiful snowflakes of such uniqueness that it is impossible to ever estimate how long something will take is nonsense. It is delusional.
I really wish as a profession we could get over ourselves and acknowledge that, hey, it is possible to learn from others, that much of what we do is repeatable, and that if you're really struggling with estimating it probably isn't because you're engaged in ground breaking work that has never been done before, but rather that you haven't bothered to think things through.
When I worked as a kitchen fitter there was a much greater difference between projects that anything I've experienced with a single employer as a dev. Fitting a top end kitchen in a listed 500 year old cottage is vastly different to fitting a budget kitchen in a new build, to fitting a period appropriate kitchen in a 1930s town house. Building out the next version of an API or writing a rendered, not so much.
I think a lot of Devs have a vastly inflated sense of the "uniqueness" of what they are implementing, and I think a lot of that derives from the industries obsession with reinventing the wheel, NIH syndrome and fashion driven development.
I have never come across that is more reluctant to actually pay for the tools to do their job than devs. Hell we've even built a quasi religious cult in foss that revolves around not paying. Yes yes I know the "free" In foss is supposed to be free as in freedom, but in practice it ain't, it's all about free as in beer. See the gp and the offence taken at actually being asked to pay for the foundational tool they use to do their job.