Yeah, but at least we knew how to switch consoles.

I bet that most Linux users nowadays don’t event know the CTRL+ALT+Fx shortcuts to switch console.

Can’t say that the old days were really “good” compared to what we had now, but there was definitelly a lot of satisfaction in step by step getting the system to work.

Stories from the “good” old days running Linux on a 386 machine with 4 MB or less of memory aside, in the present day it’s still perfectly normal to run Linux on a much weaker machine as a server - you can just rent a the cheapest VPS you can find (which nowadays will have 128 MB, maybe 256MB, and definitelly only give you a single core) and install it there.

Of course, it won’t be something with X-Windows or Wayland, much less stuff like LibreOffice.

I think the server distribution of Ubunto might fit such a VPS, though there are server-specific Linux distros that will for sure fit and if everything fails TinyCore Linux will fit in a potato.

I current have a server like that using AlmaLinux on a VPS with less than 1GB in memory, which is used only as a Git repository and that machine is overkill for it (it’s the lowest end VPS with enough storage space for a Git repository big enough for the projects I’m working on, so judging by the server management interface and linux meminfo, that machine’s CPU power and memory are in practice far more than needed).

If you’re willing to live with a command line interface, you can run Linux on $50 worth of hardware.

Similar story but I just installed slackware on one of the University PCs (they just had a handful of PCs in the general computer room for the students and nobody actually watched over us) since I did not have a PC yet (only had a ZX Spectrum at the timback then).

Trying to get X-Windows to work in Slackware was interesting, to say the least: back then you had to manually create your own video timings configuration file to get the graphics to work - which means defining the video mode at the very low level, such as configuring the number of video clock cycles between end-of-line-drawing and horizontal-retrace - and fortunatelly I didn’t actually blow up any monitor (which was possible if you did the configuration wrong).

At least we had some access to the Internet (most things were blocked but we had Usenet and e-email and one could use FTPmail gateways to download stuff from remote servers) via Ethernet, so that part was easy.

Anyways, my first reaction looking at the OP’s post was like: yeah, if they’re running X it’s probably a too powerfull machine.

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.

The more consumer friendly and complex this stuff gets the further away from the raw metal those the users see as “magicians” are.

It used to be that the “magicians” were the Electronics Geeks (and the OP’s post and most comments here are a basically on “magic” that has to do with Electronics), but nowadays most “magicians” capable of explaining and dealing with the “unexplainable” are Software Techies.

It could be you wore the kind of clothes - certain shoes, wool pullovers, clothes made of certain plastic fibers - that makes one accumulate static electricity, so you literally had a charge different from the rest (did you have a tendency to get a shock when you touched large metalic objects or other people?)

Or maybe you were the biggest person on the team and hence caused the biggest electromagnetic shadow on the surrounding electromagnetic radiation (nowadays we live surrounded by radio sources). A similiar effect would happen if you had a less dry skin and hence more conductive than your colleagues (was this, for example, early morning after you took your daily shower).

Anyways, somewhere in that circuit was a wire which was unconnected and led to the gate side of a transitor, probably a Mostfet. If you were using a microcontroller in it, you might have left an I/O port enabled that was not physically connected to anything so its value could easilly flip merelly from electromagnetic interference and that day you just happened to have the biggest electromagnetic footprint (due to static charge, body size and/or body conductivity) around.

For fun it’s not hard to make a circuit that “detects people closeby” using a transistor or microcontroller I/O port connected to a wire that goes nowhere with the other side set up to light or not an LED depending on the input signal, which detects people because them being close or not alters the electromagnetic radiation that goes into that wire (an unconnected component pin also works, but it’s more sensitive with a bit or wire). The simple version is not exactly reliable, but it’s pretty spooky when it works.

I bet that “magic” switch was set up by a geek with an electronics background to take the piss of the ones without such a background.