Perhaps it was the way it was written; I couldn’t believe intrigue and passion of computing could be weaved together like this. But there it was.
I did make it home eventually. Fortunately the first 2000km lift back from western Australia to the eastern states with a crystal meth addict on the run from the police didn’t end violently. A few weeks back in Sydney with family some Linux nerds found me working as a receptionist answering phones and scanning paper records in at a failing medical practice. They got me doing desktop Windows and Linux server support. I’m an official software engineer now. I guess I should print this article out to show to my kids!
There is a gap between receptionist and official software engineer. Please, give us more details about your journey and what happened in between
At many companies (especially old, stodgy companies) this gap is artificial. The day you get asked "hey, I've got some data .... and I need ..." and you successfully solve the person's problem, is the day you become the office's live-in software engineer. That person you helped will be back, and they will bring friends.
The rest after that is just job title shuffling.
Every couple of days "the server" would crash. It was an old dusty Windows box under one of the admin staff's desk. I offered to move it out so they wouldn't keep accidentally kicking out the power cable or disturb the wobbly ethernet switch making it fall down off the top of it down into the corner where the mice and moths hid. I was sick of crawling down there after a while.
Once staff saw that I knew how to plug network cables back in after moving IT gear, they stopped calling in the IT company meant to be keeping all this stuff on life support. From there you hear about every tiny little problem, you get busier, learn to automate bits of your job piece by piece to keep up with the demands.
For example, a doctor complained about waiting for me to scan in pathology reports delivered by snail mail. The fax machine kept running out of toner & paper as it was also the practice's main printer. I researched and found that the pathology providers could install some software on a Windows machine which would deliver reports directly into the medical software the doctors were starting to use. That software would crash, too. How can I monitor that Windows service and have it send me an email if it goes down? What if I could get it to try to start it back up again before it sent me an email?
Eventually the dementia doctor retired as he kept falling asleep during appointments.
The other old doctor voluntarily quit when the filing cabinets containing all the paper records moved to a locked room with just a scanner and shredder.
A doctor wanted to be able to connect to the practice remotely. I learned about VPNs, but I had no idea if I could set that up using the modem/router provided by the ISP. Some family friend referred me to the IT company who took care of their email. Turned out that company were real Linux purists running all their own mail system in a datacenter. They were impressed by my proposed network diagram for the medical practice. They thought it was cool that I installed Linux on old PCs to keep using them for fun.
Instead of me hiring them for support, they just offered me a real salary job at a bit over minimum wage.
What sort of companies are those were receptionists have access to tools beyond their role? and why are people approaching the receptionists asking for data queries?
Like having to run a script on that data when your machine doesn't have the permissions to run arbitrary software without permission from the IT team
You seemed vaguely tech savvy, so someone asked you for help and emailed you a file containing the data (or perhaps just handed you a laptop and turned you loose). The rest is history.
It's a modern invention that companies have separate software engineering orgs, software engineering roadmaps, software engineering managers. At older companies, a software developer is just another businessperson in a cubicle. Your manager probably has an English degree.
I know that someday I'll work in something other than IT. When I do I am going to make for damned sure that I don't express even the slightest bit of tech savvy for exactly this reason.
It's similar to playing dumb w/ people I encounter outside work who find out I work in IT. If I get asked a question I play dumb and cop to working on some highly siloed subject (usually I'll claim to only work on "networking" or firewalls... >smile<).
It's a fair question. I questioned myself all the time doing the job. The couple of competent doctors couldn't see other patients as the doctors couldn't get paper records themselves. The old retiring doctors (one had a genuine diagnosis of vascular dementia) sometimes hid the paper records for themselves. Admin staff stopped bothering sorting the records properly some years back too. You needed to just know where some group of patient's records were in which cabinet. The workflow for accessing records, in the morning:
1. study the appointment book
2. open delivered snail mail, set aside ones for patients who had appointments that day
3. get each patient's records, attach any new mail (real attachments with paperclips!)
4. place them on each doctor's desks
By scanning the records in other doctors, competent ones, could see other patients. For me, I was ok with doing this job even though it is officially inappropriate.Despite this strict paper workflow, there were 3 PCs on the front desk to be used by any admin staff at any time. No password to log in ("too slow" otherwise). The password to log in to the medical software was "1234" ("too slow" otherwise... again). The practice purchased computers only to be able to bill patients using credit/debit cards and to get rebates more quickly from the government.
> ... permissions to run arbitrary software without permission from the IT team
There was no IT team. The practice called an IT support company who billed per 10 minutes - no contracts - if the "server" didn't come back up again after a disk failed or somebody kicked the cables. The practice staff stopped calling the IT team once they saw that I could do the job myself (see my longer comment)
The first job I had where I did anything technical (basic JS and HTML) also had me cold calling, answering phones, designing brochures, fiberglass repair, and some other stuff I’m forgetting. Small businesses frequently have more niche jobs than people and are more than happy to have people help where they are interested.
My first full software job was a direct to consumer company, and during the Christmas rush the entire front office was on the packing line.
Larger companies tend to appreciate people staying in their lane.
They were also converting paper records to digital. Asking the data entry person where the data is or how to find paper record xyz in the digital system doesn't seem odd.
As for data access; the vast majority of firms, worldwide, in every country, have abysmal internal controls, and in many cases, none at all. The filing cabinet is unlocked all day, everything from payroll to posters is in a share that every network login can R/W, and nobody cares.
One of my first jobs was as an admin assistant at a utilities company. We logged data about pipe replacement, which was done in something like five different spreadsheets, each optimized for its printed form (legal requirements for paper copies of various things). I knew just about enough about Access to know that entering the same thing in 5 different spreadsheets is a waste of everyone's time so set up a database where people entered the information once and Access forms generated the five printable versions. Management were impressed and asked me what else I think might be possible. Cue me diving into the world of complex forms, eventually VBA, then once I got frustrated with that, VB.NET via SharpDevelop (they sure as hell weren't paying for Visual Studio), on and on. I was doing software engineering while still keeping the job title of admin assistant.
...then I went and got a real engineering job with a real salary.
- Oh, baby, don't crash me Don't crash me, no more
- No, I don't know why you're not there I pushed to Main,
- but you don't care Is it the bracket? Or is it the path? Math.random() wrath! Give me a sign!
- I want no other, no other framework This is our Sprint, our time When we’re together, I need you forever Is it... Clean Code?
- Oh, baby, don't crash me Don't crash me no more
- Oh, baby, don't crash me Don't crash me, no more What is code?
- I'll see myself out
Here another jewel from Paul Ford:
"The only technology that you need is deadlines"
And an article about it:
> The thing that is remarkable about it is that it has this property of being information—that we made it up—but it is also machine, and it has these engineered properties. And this is where software is unlikely anything we have ever done, and we're still grappling on that that means. What does it mean to have information that functions as machine? It's got this duality: you can see it as both.
* https://www.youtube.com/watch?v=vHPa5-BWd4w&t=4m37s
> We suffer -- tremendously -- from a bias from traditional engineering that writing code is like digging a ditch: that it is a mundane activity best left to day labor -- and certainly beneath the Gentleman Engineer. This belief is profoundly wrong because software is not like a dam or a superhighway or a power plant: in software, the blueprints _are_ the thing; the abstraction _is_ the machine.
* https://bcantrill.dtrace.org/2007/07/28/on-the-beauty-in-bea...
I'm kinda interested in the subject (see eg. https://news.ycombinator.com/item?id=46247266 )
What Is Code? (2015) - https://news.ycombinator.com/item?id=33331697 - Oct 2022 (50 comments)
What is code - https://news.ycombinator.com/item?id=17259483 - June 2018 (36 comments)
What Is Code? - https://news.ycombinator.com/item?id=9698870 - June 2015 (356 comments)
And what a refreshment from f*king AI slop that you find everywhere these days.
That said, this is why I like HN or any other kind of curated website, the voting systems and comments and the like will (hopefully) make sure low-effort writing will be filtered out.
Some HN algorithms are run by HN servers, some are run by HN moderators, and some are run by third parties.
I guess the gas town one does capture our moment, but embracing YOLO spaghetti-o with reckless abandon, is a) depressing, even though I also feel like a middling programmer and b) actually seems to be dazzling these newer beleaguered bureaucrats precisely because they think they could just talk to the LLM instead of TMitTB.
Anyway, if that post and its ilk leave a bad taste, this was mouthwash for me. Lucky 10,000 I know, but I had never seen this (or felt so seen, as they say). I had to go check that he wasn’t wrong about PHP being Personal Home Page. I somehow never picked up that the recursive naming thing is a backcroynm.
It feels different if you replace "LLM" with "outsourcing". Thing is, instructing a team of software engineers what you want is a lot more work (they need a lot more handholding), a lot more expensive, and a lot slower. But I'd argue that the work is the same - writing specifications, adjusting accordingly. Minus the human factor.
LLM coding agents won't kill software development as a job, but it will affect outsourcing and agencies as an industry. Of course, outsourcing companies will / are using it too.
They won't same as the industrial revolution didn't kill farming as a job but it sure did ate up most of the farming roles. Most of the people you have ever met are people who would have been farmers had they been born before the revolution. Developers without much leverage, underpaid, overworked and competing with hundreds of experienced devs for a single role is likely to be the eventual future of most software development thus gradually becoming similar to other stem roles in terms of pay, competition and negotiation power.
It's definitely a more enjoyable world this way.
Just imagine that instead of having to work off of an amorphous draft in your head, it really creates the draft right in front of you in actual code. You can still shape and craft and refine it just the same, but now you have tons more working memory free to use for the actually meaningful parts of the problem.
And, you're way less burdened by analysis paralysis. Instead of running in circles thinking about how you want to implement something, you can just try it both ways. There's no sunk cost of picking the wrong approach because it's practically instantaneous.
So no, this isn't universally true.
I think software engineers are having an identity disconnect from their roles as engineers vs coders. Engineering is about solving problems via tools and knowledge through constraints. An engineer is not diminished by having other engineers or better tooling as assistants. If you are having problems understanding your role in the problem, frankly you need to review your skillset and adjust.