I’ve been avoiding travel to the US since the Patriot Act that followed 9/11 started that kind of shit and more in general the US started moving away from Democracy and into Autocracy.

Last time I felt like traveling to the North American continent I just went to Canada instead for a whole month - sea kayaking in British Columbia, hiking in the Canadian Rockies, sightseeing in Quebec . Highly recommended by the way.

The skateboard would literally be a plank on top of some wheel axes pinched from a shopping cart, the scooter would just be a flimsy pole stuck through a hole in the “skateboard”, the bicycle would be 2 such poles, one with a small piece of wood as a seat and at the front the wheel axis had been moved to be soldered to the front pole so that one rotates with the other.

All of them function only in the technical sense, are awkward to use, don’t last long under continuous use and look like shit because they were not done with the right techniques for resilience and have none of the finishing touches needed for ease of use and attractiveness.

Their solution was mounting the semi-built old car on top of a new car.

In my experience the waterfall one would be either be “a bicycle that was partly transformed into a monster truck when they figured out it needed to carry a lot more load, but kept some bicycle parts” or “a drag car were they installed an engine far too large for the body so it has no hood and the engine is partly out of the car, and yet the car is supposed to be used as a normal city car”.

The Cult Of Agile with its Holy Practices that Must Be Done without actual logical and well thought about reasons (instead, the reason are things like “It’s What It Says In This Agile Holy Book” and/or “That’s What I Saw Other Agile People Do”), is not at all the same as the class of Software Development Processes called Agile.

Then again, Software Development Processes are the kind of thing you tackle at the level of Technical Architect, and since there aren’t really that many genuine Technical Architects (with the actual chops, rather than merelly 5-10 years experience in a single kind of development environment and a title obtained from a company that gives fancy titles as “promotion” instead of a proper salary raise) around, Agile is mostly just blindly followed without true understanding of what it does, what it doesn’t do, how that is does it or why it cannot do it, and thus were and how it actually adds value and were it doesn’t.

Whilst I agree that it’s nice to get people who do get some enjoyment from the work, I think it’s unrealistic to expect to actually find it in senior professionals: maybe you’ll be lucky, but don’t count on it - such people need to have started with a natural knack for that domain, not having had all their enjoyment of that kind of activity totally crushed over the years by the industry (I’m afraid that over time having to do something again and again because it has to be done rather than because one wants to do it, crushes the fun out of any task for even for the most enthusiastic about it person), and not having been accepted or even demanded to get promoted to management as they became more senior because they were so good in the Technical side (were they’ll most likely suck, but that’s not consolation for you as they won’t be available anymore).

It simply is very unlikely to find experienced people combining all those things.

Further, even if you do manage to find such people, don’t expect that enjoyment of such tasks to be enough to drive an employee most of the time, since most of the work we have to do is generally something that needs to be done rather than something which is enjoyable to do.

If on the other hand you go for junior people who still retain their enthusiasm, you’re going to be “paying” for them doing all the mistakes in the book and then some as they learn, plus if you give them the really advanced complex stuff (say, designing a system to fit into existing business processes) they’re going to fuck it up beyond all recognition.

So statistically going for enthusiasm is and experience is like hoping to win the lottery.

If you do need to hire people with actual experience, it’s more realistic to aim for professionalism as their driver of doing the work well and in time, rather than enthusiasm.

This is why, IMHO, asking people how they feel about the work is a bit silly unless you have yourself a truckload of recent graduates looking for their first job and you’re trying to separate the gifted from the ones who went for it for the money (and there you’re competing with the likes of Google and other companies with more brand recognition who will far more easily attract said gifted naive young things than the overwhelming majority of companies out there, so that too is probably not realistic an expectation)

I suppose Lemmy is frequented by older Tech professionals, hence the “you must be joking!” reaction to your idea that asking people how they feel about the work is in any way form or shape a viable way of finding good professionals.

Sounds to me like you’re doing the fun part of the job - “solving challenging problems” - without having to do the vast majority of the work (which is seldom as much fun), such as making it suitable for actual end users, integration with existing systems and/or migration, maintaining it during its entire life-cycle, supporting it (which for devs generally means 3rd level support) and so on.

So not exactly a typical environment from which to derive general conclusions about what are the best characteristics for a professional in software engineering in general.

Mind you, I don’t disagree that if what you’re doing is basically skunworks, you want enthusiastic people who aren’t frozen into a certain set of habits and technologies: try shit out to see if it works kind of people rather than the kind that asks themselves “how do I make this maintainable and safe to extend for the innevitable extra requirements in the future”.

Having been on both sides of the fence, in my experience the software that comes from such skunkworks teams tends to be horribly designed, not suitable for production and often requires a total rewrite and similarly looking back at when I had that spirit, the software I made was shit for anything beyond the immediacy of “solving the problem at hand”.

(Personally when I had to hire mid-level and above devs, one of my criteria was if they had already been through the full life cycle for a project of theirs - having to maintain and support your own work really is the only way to undrestand and even burn into one’s brain the point and importance of otherwise “unexplained” good practices in software development and design).

Mind you, I can get your problem with people who indeed are just jobsworths - I’ve had to deal with my share of people who should’ve chosen a different professional occupation - but you might often confuse the demands and concerns of people from the production side as “covering their asses bullshit” when they’re in fact just the product of them working on short, mid and long term perspectives in terms of the software life-cycle and in a broader context hence caring about things like extensability, maintenability and systems integration, whilst your team’s concerns end up pretty much at the point were you’re delivering stuff that “works, now, in laboratory conditions”. Certainly, I’ve seen this dynamic of misunderstandings between “exploratory” and “production” teams, especially the skunkworks team because they tend to be younger people who never did anything else, whilst the production team (if they’re any good) is much more likely to have at least a few people who, when they were junior, did the same kind of work as the skunkworks guys.

Then again, sometimes it really is “jobsworths who should never have gone into software development” covering their asses and minimizing their own hassle.

Asking questions about the team and the work is how one detects and avoid shitty environments.

Ah, no concreted metrics for efficiency and delivery of results.

Explains why you prioritize employees who have fun on the job rather than efficient professionals who are there to do a job well done - you can’t really like to like compare with other teams (much less the broader industry) when it comes to delivering objectives because it’s all open ended and unique, so you really don’t know for sure which kind of employee is more effective but you do know for sure which kind is more fun to work with, hence you prioritize what you can measure - a fun team - not what is more effective and efficient.

Most work out there in software development is not “cracking interesting problems for fun without a strict timeline”, it’s “integrate new functionality into an existing massive custom-made system, which has at least 3 different styles of programming and software design because different people have worked on it over the last 8 years and only not a complete mess of spaghetti code if you’re lucky” - not really the kind of work were Enthusiasm lasts long, but it still has to be done and sometimes, millions, tens of millions and even hundreds of millions in yearly revenue of some company or other rides in doing that job well and in a timelly fashion.

Don’t take this badly, but from where I’m standing you’re in the playground sandbox of software engineering. No doubt it’s fun and even an environment others would love to be able to work in, it’s just not the place for professionals and doesn’t really reflect most of the software development being done out there, so not exactly a representative environment for determining what kind of professionals are suitable for the wider industry.

Look mate, I’ve been in Software Development for almost 3 decades, mainly in the Technical careed path (did some Project Management but, frankly, it’s not my thing) and all the way to Technical Architect, in 3 different countries and most of it as a contractor, so I worked in quite a number of companies and work environment.

(I’m not trying to pull rank here, just showing that I’ve seen a lot)

In my experience, things like Enthusiasm are what bright eyed naive junior developers have: they’re like me as a teen in the swiming pool having learnt to swim by myself and never having had lessons - intense strokes trowing water all over the place but moving very little for all that effort, or in other words lots of effort with little in the way of results.

Worse, Enthusiasm doesn’t last forever and, further, most of the work than needs to be done is not exactly stimulating (if it was fun, people wouldn’t have to pay money to others for doing it).

People who get at least some enjoyment of their work are good to have (and I’m lucky that after all these years I still get those moments of great enjoyment when at the end of doing something insanelly complex it all works), but in the real world most work that needs to be done is needed but boring so fun in that kind of task by itself won’t be enough, plus such people are actually uncommon beyond the bright eyed young things, so if you want somebody who will actually deliver you results (rather than work a lot to achieve little) and you’re not a prestigious company (say, like Google, which leverages their brand recognition to pull in such bright young things by the bucket load and drip them out drained of on the other side) and can’t pay well above average, you’re highly unlikely to get those kinds of people.

What you really want is people who have things like professional pride: they want to do a good job because they see themselves as professionals and feel a professional responsability to deliver good results in an efficient way that doesn’t hinder the work of others.

I’ve seen over the years people with your perspective heading Startups or teams within small companies, and invariably they end up with unproductive teams filled with inexperienced people making all the mistakes in the book (and inventing new ones), enthusiastically. Maybe the people seeking such workers should’ve asked themselves what their real objective is in that: is it deliver the results needed by the company so that it prospers and grows or is it the pleasure of being surrounded by people having fun.

IMHO, in Software Development it’s a good idea for a candidate to ask about the project, if only because any good professional would want to know if they’re a good fit or not.

Mind you, that makes sense in the Technical interview rather than with HR - no point in asking about what are the practical professional details of the work you will be doing from a person who doesn’t really have a clue (the HR person) when you know you will be facing an actual professional peer in a technical interview who knows the work that needs to be done in your terms and with the level of detail and understanding only domain professionals have.

In my experience doing the Technical Interview side of things (and most of my career I was a Contractor - so a Freelancer - which is hardly a “company man” with a rosy view of my relationship to them or somebody who thinks people work for fun), people who don’t ask about the project during the Technical Interview tend to as the interview proceeds end up get revealed as technically weak: an experienced “Engineer” would want to make sure they’re well matched to the kind of work they’re be doing (as well as, in my experience from the other side of the interviewing table, spot the messy fucked up situations before you take the contract so that if you can avoid ending in such disfunctional environments).

I mean, the whole “this is your second family” or “you should be proud of were you work” thing isn’t bad if they’re similarly dedicated to their employees welfare, for example “no questions asked sick days off” or maybe even more relevant in Tech, sizing the team to the work that need to be done in a project rather than expecting constant unpaid overwork from employees (rather than just once in a while).

The problem, as emphasized by the OP, is that they expect employees to invest themselves in the company without the company investing in employees.

There apparently are some companies out there which are almost like a second family, you know, the kind of place were they hear that your grandmother died and give you a week paid leave no questions asked to “deal with your loss”, but most aren’t at all like that - they treat employees as disposable cogs whilst expecting that the employees respond back by being dedicated to the company.

It’s either a business relation on both sides or it’s a personal relation on both sides.

I was in Tech in Europe through the transition from when employees were people and the company was loyal to them and expected loyalty to the company in return (the age of lifetime employment), to the world we live in now were employees are “human resources”, and for a great part of that period there was this thing were most employers expected employees to stay with the company whilst the company needed them and be dedicated to the company, whilst in return they treated employees as a business relationship with (in Tech) some manipulative “fake friendship” stuff thrown in (the ultimate examples: company paid pizza dinner when people stay working on a project till late, or the yearly company party, rather than, you know, paying people better or sizing the team to fit the work that needs to be done rather than relying on unpaid overwork) - still today we see this kind of shit very obviously and very purposefully done in places like Google.

Of course the “humour” part here is that plenty of managerial and HR people in companies still expect that employees are loyal to the company even all the while they treat them as disposable cogs who it’s fine to exploit without consideration for their feelings or welfare - or going back to the first paragraph of this post: they relate to employees as a business relationship whilst expecting the employees related to the company as a personal relationship (often a “second family”).

Probably found at the bottom of a Complaints Form.

The more services you have depending on a 3rd party which can do whatever the fuck they want, either directly or by changing the rules when the feel like it (i.e. not bound by rules they cannot change, such as root DNS providers are) and then doing it, the less your system is actually self-hosted, IMHO.

For me the whole point of self-hosting is exactly being as independent as possible of 3rd parties that can just fuck you up, be it on purpose (generally for $$$) or because they go bankrupt and close their services.

This is why I’ve actually chosen to run Kodi on my home server that doubles down as TV Box even though I can’t easilly use it from anywhere else (it’s possible but it involves using a standalone database that is then shared, which can only be safelly done through customly setup ssh pipes) rather than something like Plex.

It’s kinda funny to see people into self-hosting still doing the kind of mistake I did almost 3 decades ago (fortunatelly in a professional environment) of trusting a 3rd party to the point of becoming dependent on them and later getting burned when they abused that trust, and which led me to avoid such situations like the plague ever since.

Mind you, I can understand if people for whom self-hosting is not driven by a desire to reduce vulnerability to the whims of 3rd parties (which includes reducing the risk of enshittification) and is instead driven by “waste not” (for example, bringing new life to old hardware rather than throwing it out) or by it being a fun challenge, don’t really care to be as independent as possible from such 3rd parties.

Even if AI is an actual tool that improves the software development speed of human developers (rather than something that ends up taking away in time spending reviewing, correcting and debugging the AI generated code, the time savings it gives in automatically writing the code), it’s been my experience in almost 30 years of my career as a Software Engineer that every single tooling improvements that makes us capable of doing more in the same amount of time is eaten up by increasing demands on the capabilities of the software we make.

Thirty years ago user interfaces were either CLI or pretty simple with no animations. A Software Systems was just a software application - it ran on a single machine with inputs and outputs on that machine - not a multi-tiered octopus involving a bunch of back end data stores, then control and data retrieval middle tiers, then another tier doing UI generation using a bunch of intermediate page definition languages and a frontends rendering those pages to a user and getting user input, probably with some local code thrown into the mix. Ditto for how cars are now mostly multiple programs running of various microcontrollers with one or more microprocessors in the mix all talking over a dedicated protocol. Ditto for how your frigging “smart” washing machine talking to your dedicated smartphone app for it probably involves a 3rd machine in the form of some server from the manufacturer and the whole thing is running over TCP/IP and using the Internet (hence depending on a lot more machines with their dedicated software such as Routers and DNS servers) rather than some point-to-point direct protocol (such as Serial) like in the old days.

Anyways, the point being that even if AI actually delivers more upsides than downsides as a tool to improve programmer output, that stuff is going to be eaten up by increasing demands on the complexity of the software we do, same as the benefits of better programming languages were, the benefits of better IDEs were, of the widespread availability of pre-made libraries for just about everything were, of templating were, of the easiness to find solutions for the problem one is facing from other people on the Internet were, of better software development processes were, of source control were, of colaborative development tools were and so on.

Funnily enough, for all those things there were always people claiming it would make the life of programmers easier, when in fact all it did was make the expectations on the software being implemented go up, often just in terms of bullshit that’s not really useful (the “smart” washing machine using networking to talk to a smartphone app so that the machine manufacturers can save a few dollars by not putting as many physical controllers in it, is probably a good example)

Couldn’t agree more.

Personally I’m a big fan of Public Housing as a way to pump up supply.

You’re paying them for having had at the right time the capital to get hold of a limited resource that’s required by people to live, which they now block you from getting or using unless you pay them.

You’re paying a ransom, not buying a service.

If there were lots of houses available to buy at prices which were affordable to all and some people were landlords letting those who chose not to buy (for example because they were only somewhere temporarily) then, yeah, landlords would be providing an actual service, but that’s not at all the system we have and plenty of people who want to buy in practice cannot, so have no other option in order to have a place to live than to pay the ransom to those who do have the capital to buy (or did, back when it was cheaper) and used it to capture that resource that’s required by others.

I really like the social engineering element of your documentation strategy!

At one point I was hired as a developer by an IT Products company which was starting a new area using (at the time) more recent technologies and programming languages, but until the thing really started going they had no significant work for me to do so I did QA for a few months (mostly automating QA).

Let’s just say that having a hacker mindset and a bit of a dastardly satisfaction in “cracking” the software is a big help in QA.

I suspect that I might have enjoyed the “managing to find a way to break somebody else’s code” part of it a bit too much.