I've worked on a variety of medical devices: CT scanners, patient monitors, infusion pumps, radiation therapy devices, contrast injectors, dialysis machines, assistive devices for the blind.
Last year I had to go to the ER it was pretty cool to see that some of the equipment was stuff I've worked on. I needed a CT scan with contrast, I had worked on the standards body that defined the protocol that allowed CT scanner talk to a contrast injector, and they were using the device I worked on with the feature I defined and implemented.
I’ve worked on medical device stuff too, and it’s not like anything else. I’ll never forget the first time I found out that code I’d written had saved someone’s life. I’d done plenty of awesome things, and in that moment they all felt small.
That's fascinating. Sadly, based on the quality of software engineering I've witnessed (and produced) over my career, if I were to find myself having to trust my life with any of it, I would be terrified.
That's when you beat on the code until you aren't scared. Don't let the code out the door until you've unit tested, integration tested, QA'd it to hell and back.
If it's some random cat pic frontend website code and it breaks, yeah whatever, just fix it as it breaks because you have the luxury of hourly deploys. but on the other side of the spectrum, if you're writing firmware and it's isn't remotely updatable, you don't just sling the code over the wall in the same way. in that realm you have the luxury of an actual spec and a less complicated system.
everyone gets scared. what you do in the face of it is up to you.
Pick a good IDE, set it to the most pedantic mode you can, and work on the code until there are no errors, no warnings, and only acceptable info notifications.
Have a good test suite with realistic scenarios. Add more to that all of the time.
Get outside feedback on whether you documentation and diagrams are readable and keep them up to date.
If you can do that, you can write mission critical code.
I had to deal with some of projects you mention. At least where I'm from (italy), we rely on a bunch of old proprietary and very sh* technologies that I think it's really killing patients (metaphorically speaking... or maybe not...). The thing is that most of people aren't asking AI/the superb cure, but something that just works.
I'm fairly familiar with infusion pumps, where bad software regularly kills patients. Just look up "infusion pump software recall" and you'll find dozens and dozens of very recent examples of how bad software implementations have led to a lot of preventable deaths.
I have some friends trying to fix this[1] and they have amazing tech, but it's a difficult industry to break in to.
I wrote multiple systems that import most of the tax return data for the Finnish Tax Administration, a system that imports payroll data (and helped with the previous version of the system), and tax payer data extraction for other government agencies. Downstream process use this data to automatically fill out taxpayers' tax returns in Finland each year, and individuals only file tax return corrections. So if everything looks good, which happens for 90+% of taxpayers, there's nothing to do each year. We even won a few awards for the project.
I'd love to, this is exactly the use case for digital technology; automate the stuff we can making more time for more meaningful taska for everyone. Finland is ahead of it's time for these kinds of integrations. Problem is, it requires a central authority having all of the data, and the US has absolutely zero trust in it's government to not fuck it up. With good reason
Absolutely would not work in the US (as, unfortunately, most public services). There's already a huge lobby from TurboTax and other players. All countries that got to this level of automation already had publicly developed, free software for tax payers previously.
How did you sleep last night? Your cynicism is slowing.
Just this year, the IRS started a direct file pilot program that flies in the face of "it absolutely would not work". It's not everything, but it's a start.
Is that true that one can see everyone's salary in Finland? Or was it only for those above EUR 100k?
Can people outside of Finland see it? Doesnt this attract thieves? They know whom to rob.
What is the impact on dating scene? Do rich people put full names on Tinder?
Not sure in Finland but in Sweden yes you can see everyones salary (or more correctly you can see their income from salary. So if you got salary from two different jobs you just see the aggregate). Doesnt matter how much or little. And yes, it is def being used by criminals (on the other hand I'm sure it isnt hard to figure out in the US who is rich or not based on their lifestyle)
I’d say it’s easier to tell in the US as cities and towns tend to be heavily divided into class-based areas. Not to mention people in general are far more comfortable “showing off” their financial status.
Finland is a lot more homogenous in that sense and people certainly don’t flaunt their wealth.
In the US, a lavish lifestyle can be funded on credit, so it's only an approximation. You don't know how much in debt the person driving the Benz is or isn't.
Yes I believe you can look up anyone's salary in Finland, but you have to officially request it, and not sure how that's done. Some organization requests all the high earners and posts them online, so those above that amount can be identified. Everyone knows about it but find Finns are "if you have it, don't show it", and so it's not a problem as far as I know. It's the same as companies being transparent about salaries, it seems absurd to those not exposed to these kinds of companies, but after being part it's not a big deal. You're either not interested, or you use it as a tool to leverage yourself up.
It was waterfall, but a lot of agile inside. Instead of development from waterfall, developers get a proof of concept up in front of the client SMEs as soon as possible, and then get it into their hands testing as soon as possible. In this way, the people working on the requirements were intimately familiar with the inner workings and offering feedback very quickly, to save time if solutions weren't working as intended. Each team would have 3-5 major projects so as soon as the first project didn't fill the full meeting, other priorities started getting their requirements. These meetings would be a touch base and rehash old topics if any solutions needed a pivot.
Once the SMEs and developers signed off on the solution, then it could go to the test part of waterfall, system test, everything launched once during the rollout window. And then maintenance mode.
Old boring tech, VB.NET and t-SQL. Never understood the hate for VB.NET, I swear it's from people misconstruing VBA, which is awful, or they had terrible infra and coding standards. The system we had was a general core product that was configurable (I mean, taxes are the same, they just have different rules), but also customizable. Finland wasn't the first international project, but it was maybe the biggest one, so a lot of the solutions ended up being custom for the project. Unfortunately been difficult to find work with the boring tech background, but it was enjoyable (especially considering it was taxes).
Not many people "hate" this or that tech, is my observation. As a guy who more or less refuses to work with anything else beyond Elixir, Golang and Rust these days, I can tell you that my stance comes from informed trauma over my 22+ years of professional experience; many runtimes like the JVM and .NET are quite good but have defects that tend to show up in exactly the wrong moments (like a burst of load that usually nobody ever tests for).
You absolutely have my respect for working on that system and it makes tangible positive impact on people's lives. Kudos. Wish I had even one such project in my long career but alas.
That being said, we should always qualify our statements. Your code likely never has to work in 100K+ requests per second conditions, and latency barely matters -- as long as people don't see 30s HTTP timeout canned pages then it's all good, right?
Many of us work on much more demanding stuff however, and there the programming stack actually makes very real and measurable difference on many axii -- programmer productivity, runtime resilience to bursts or just high loads, raw speed, easiness of deploying a hot fix, and others.
Again, you have my respect. Choosing boring / old tech is viable in many cases. But definitely not all. All our tools come with tradeoffs. You simply chose one whose negative tradeoffs will never manifest.
I wrote a Tampermonkey script which more or less was a true 'automate someone out of a job' situation, except it didn't do that at all; it freed up 20+ hours a week that someone had to sit there and do this awful manual thing with vendor portals, csv's, and spreadsheets.
I haven't worked at that job for almost a decade, and last I heard it's continued being used with only a small amount of maintenance.
That's the most compliments I've ever gotten for any software I've ever written and it had very real human impact.
Reminds me of my first job out of college as a data analyst. At least 60% of the work was extremely repetitive spreadsheet work and emails. Wrote some macros and automation scripts to do almost all of it in ~3 minutes instead of 4 hours and spent the saved time doing more interesting things that led to my next job.
In my case, however, I sufficiently automated the job that they didn't replace me when I left. I got a call ~4 years later because one of the macros broke when they finally updated Excel. Fixed it for a small fee, and to my knowledge they're still using it today.
When I started my job as an intern, I was surprised to learn that before each release, the techlead of our team would always manually verify every commit in the release branch to make sure that the issues in the issue tracker that correspond to the commits are actually marked as "to be merged" and greenlit by QA, that there's no commits accidentally merged from other branches which aren't ready for a release yet (juniors often mismerge by accident), he also checked that all commits from the original feature branches were merged and none were missed (happens sometimes) etc. It would take him 1-2 hours to sift through all commits every time (each release would incorporate tons of features/fixes and commits weren't squashed, so there was a ton of work). The techlead also didn't allow anyone to do this work because he feared people wouldn't be as attentive as him. I remember there was one time when it was 11 PM and he was still verifying the commits and the release managers had to wait and couldn't go home.
I wrote a script which finds new commits not present in the master branch and compares them to the corresponding issues in the issue tracker (each commit message has an issue ID as a rule so it's easy to find the connections), and then generates a nice report like "the release branch cannot be released as is because issue 1234 is not marked as ready by QA, while commit 3456 is not present in any of the listed feature branches and could be a result of an accidental merge".
After we started using this script, the time it took to verify release branches decreased to something like 10 minutes. The techlead finally decided to delegate this kind of check to other devs (not a bottleneck anymore).
The idea was then copied by all other teams (web devs, etc.) and the script is still in use today, with many more features than I originally envisioned.
That small silly script was probably my most useful contribution because it saved a lot of time for everyone.
We had something similar at an old job. It was pretty nice as then you were allowed to release your changes whenever as long as all the changes up to yours had been tested.
I was first employee and only software engineer for 12 months at a startup working on increasing large scale solar power penetration in electricity networks globally. Worked there for 4 years solving all sorts of interesting problems working with meteorologists and electricity network specialists to build solar power forecasting systems. Implemented direct integration with several national electricity markets putting forward bids on 5 minute power generation which indirectly controlled many utility scale solar farms. This and more while keeping costs down and whole company to less than 10 people. Put lots of automation in place early on which enabled this as people joined. Having good monitoring solution along with CI from day 1 was a great enabler.
The project moved the needle for the amount of solar power that could be confidently installed into electricity networks in Australia, and many countries around the world. I got heavily burnt out, didn't get any equity, and initially took a substantial pay cut to work there, but on balance still the most impactful work I've done, and will be hard to top.
Working on medical devices. It’s mostly modern C++, it’s demanding, you need to write a lot of unit tests and documentation (it’s the law), and the specs must be good (well, at least better than other software), but it’s really fun and useful in the end, and you learn a lot of things that can make you write better software in other fields.
I really think every SWE should spend a few years writing this kind of thing to be better.
Saying this as someone who's done medical devices for close to 20 years, the only thing we know that you may not is that we have to follow procedures, or else.
I presume this is respected. I.e. they don’t chuck a bunch of metrics / agile bs on your head to encourage people to cut corners for a bonus or just to keep their jobs.
I learned writing medical software but I did way different things before. Anyone can learn that too. It’s just "enhanced software development," there is nothing magical about it. We have a healthy mix of young and old people. There are more women than in other software companies. It’s fun and, in the end, we all want to do a good job.
My whole post may be scary but it’s not. It’s still a regular 9 to 5 job and, most of the time, there are healthy boundaries. I’m not working overtime until 2AM, I just organize myself and work better if I’m in a healthy environment, and the well-defined organization is better for my mental health.
As _HeyLaughingBoy_ said, we follow procedures because it’s the law. Most of the time it’s respected by bosses because they know that it can bite them in the ass should a problem happen. If something bad happens, I’m still not legally responsible though but I’ll feel guilty inside, that why it works too for the motivation but I don’t think about it every day, I do my job like a regular job. Also nothing bad ever happened because of my code, the real motivation is the good things that can happen.
You can make mistakes, but if someone is injured because of a bug, the whole company will have to figure out where the process was not followed properly. You still can be fired for various reasons, but I’m pretty sure that someone will notice that I fucked up before it is released.
The main procedure is called the "ISO 62304" and you may find the PDF on pirate sites if you want to see what it is about. Every medical software company tries to follow it because it is mandatory to get all the certifications. Some companies do take it more seriously by paying for training for the devs which is nice.
I interact with real QA people who take their job seriously. They will write Jira tickets for literally anything that is not precisely defined in the spec. Sometimes they will piss me off for small details but I can’t avoid it, they are part of the process and there is no negotiation.
We also have UX teams who define the best colors and placement of the buttons in the final product.
Most of my job is writing standard software, and nothing critical, but the work is the same. If you have a bug, it must be linked to a spec. Sometimes you have to find the spec, write it, or bother your boss until he finds the spec. Then you write the code and the test to cover that spec. A bug is never a simple bug, it’s a deviation from a previously defined feature, and fixing it needs you to interact with different teams as part of the whole process: Did it happen in production or not? Is there a spec? Where is the spec? Fix the bug, write the test, optionally make sure that it has code coverage, annoy the QA team to validate that it has been fixed, and make sure that you have documented your fix in all the web tools (docs, user manual, GitLab PR, Jira, QMS stuff…). The QA team may also write their own automated tests in addition to unit tests.
As an example, I recently had a meeting with my boss and the QA team because I was asked to fix an obvious bug that was not defined in a specification. It looked like a bug BUT if it’s not defined in a requested feature or spec, is it really a bug? Who decides that it’s a bug if the proper behavior is not documented?
I do actually enjoy writing docs, specs, and tests now. And this whole thing made me a better dev.
Everything is not perfect though. Some companies have bad managers, bad planning, deadlines, everything like a regular company, but I can be proud of the result even if it’s a small fix that took me days to make sure that everyone is happy.
Been working on the same project for close to a decade now: remote patient monitoring in the healthcare sector. (Mainly chronic) patients get to live longer and more normal lives knowing that any worsening of their condition is caught early on by clinicians and as a result the national (usually European) healthcare services save a ton of money by avoiding (re)admissions to their hospitals, one of those rare win-win scenarios. Improved the lives of thousands of patients over the years.
911 system for my country. Was part of a small 'special unit' team and we implemented the entire system end to end. Administration, telephony system, even special asset monitoring. Best project I've worked on, and will probably have worked on in my life. Smartest people I've ever worked with.
I once joined a team where I had a secondary responsibility for configuring and generating periodic reports. These were daily or weekly activity reports for the platform I was expanding and supporting. When I joined, each report required custom coding and it took about two weeks to turn around.
I got bored of coding these reports. Bit by bit, I built a templating system and a configuration-based way of building these reports. Users were able to get reports not only in CSV files, but also in HTML, plaintext, and Excel files. They could get them not only by email, but also via FTP and SFTP. Reports could be customized in a variety of ways. Most importantly, with the new system, I could turn a report around in about five minutes.
When I joined there were less than 20 reports in the system. When I left, there were hundreds. Our internal users found these reports valuable, but the emotional cost of requesting and waiting for one was a burden. Removing this burden was a pleasure.
No one ever said that this needed to be done. It was an itch that got scratched.
In 2004 I was a summer intern after high school at a small software shop, they happened to be a subcontractor for a company providing a customs declarations tracking system for one of the largest container shipping companies in the world. In the first few days I was given access to a server running an instance of the system, I was given the impression that it was staging. I needed to restore a backup to fix a bug in the ASP 3.0 app. Being a Windows server I right clicked on the DB, and hit delete.
A few minutes later my boss gets a call saying someone is having trouble accessing the server. Turns out that single machine hosted staging and production. My boss kept his cool and we put up a more friendly error page saying it was down for maintenance, then started the 16 hour restore process. Somehow I kept my job, probably because he realized his incredible negligence.
The biggest impact I had was pushing the parent company to buy better servers, and set up proper isolated environments with minimal access. Preventing the situation from happening again.
I have hired close to one hundred engineers over my career, and I humble myself to every single one of them with this story. I want people to understand mistakes happen, how we handle them as a team is the most important thing I want to cultivate. I learned a lot from that job that became foundational to my career.
I have worked in the rail industry for most of the last 10 years. The project with the most impact was a rail signalling upgrade for Norway's railways - using technologies whose foundations were layed 25-30 years
I was a high school teacher at an alternative school. Most of our students had struggled at some point in their lives, in a way that had impacted their learning. So they came to us with transcripts that were all over the place: for example some had finished all their math credits but had failed all their social studies classes. Many had earned partial credit in some areas.
This made academic advising difficult for a variety of reasons. One big reason was the fact that all transcripts were text based. To figure out where a student stood academically, you had to take a pen and mark up their transcript, totaling their credits in different areas, in order to see which graduation requirements they had met and which they still needed to fulfill.
I wrote a program that parsed every student's text-based transcript, and generated a visual transcript for each student. What used to take 15-30 minutes for each student now took about 30 seconds. You could look at one of these documents and see exactly where a student's strengths were, in what areas they had struggled, and most importantly what they still needed to do in order to graduate.
It wasn't just a time-saver. The main benefit was that those 15-30 minutes that used to be spent parsing a transcript, with fingers crossed that no one was making a mistake, were now spent focused on formulating a plan that students could buy into and feel confident about.
I wrote that tool during some inservice days where my very cooperative principal let me skip out on boring repetitive trainings to focus on building the tool. I was able to build something I could run in that time, but it would have taken a lot longer to build a general-purpose tool that they could run indefinitely after I left. I haven't looked in a while, but I hope that some of the companies that handle student records have built these kinds of tools into their software. There was some movement in that direction last time I checked.
20+ years ago I wrote a completely custom open order dashboard on top of Oracle database that was modeled after a 30+ page daily report that the warehouse guy was printing every morning (M-F) and making 15 - 20 copies, then delivering to management. Aside from saving some trees the warehouse guy was able to come into work an hour later! (He was salary, so no issues there.)
I am one of the main maintainers and contributors of Biome [0], a formatter and linter for the web.
It is great to see that so many users are enthusiastic about Biome. It is really gratifying to work on a project that is appreciated and useful to the community.
What tv gives you static today? Analog tv changed channels fast, because hopefully you got signal lock quickly, and then you can start decoding wherever you are on the screen, and when the next vblank comes, you're good. Tuning latency less than one field.
Digital TV tuning is slow because of compression; when you tune to a stream in progress, you usually can't meaningfully decode it until you receive a I-frame. But I-frames are bigger than motion predicted frames, so it makes sense to only ocassionally send I-frames. Latency: technically unbounded, usually a couple of seconds.
It potentially gets a bit worse if you're on a switched video cable system where your box has to request channels, as now there's a request / response delay. But it shouldn't be too long for local comms... And in theory, the head end could start the stream with an I-frame (otoh, it may not have the processing power to decode/encode).
In theory, a TV with multiple tuners could do predictive decoding to help with channel surfing, but I don't think anybody actually does that.
I wonder if another solution would be for channels broadcast a subchannel which has more frequent i-frames, but lowered resolution and framerate to compensate for it in terms of overall bandwidth. When you surf, the TV could first hit up the subchannel, get the low-rez i-frame, and start showing a lower-quality version of the channel's video feed much faster, then start working on fetching and decoding the "real," full-resolution video feed and switch it over when it's ready. It still wouldn't be as fast and perfect as it was for analog and it'd require some industry collaboration and a bit of new hardware, but it still should be a more pleasant experience for people who just want to quickly see what's on.
> And in theory, the head end could start the stream with an I-frame (otoh, it may not have the processing power to decode/encode).
Some systems already do this. When I change channel on my iptv, it immediately shows static frame (looks like last known iframe) and starts sound, then after up to 2s starts playing video, probably waits for next iframe because you can't start decoding from middle of stream anyway.
For the last 4 years, we've been working on improving the efficiency of deep sleep. This isn't more time spent in deep sleep, it's increasing the synchronous firing of neurons which are the driver of slow-waves, which define deep sleep.
We've got working devices and are going through the ethics approval to continue testing on a larger group of people before we're able to confidently bring our solution to market.
I find it useful myself atm, I think it has the largest potential impact of any project I've worked on before. (https://affectablesleep.com).
I worked on software that runs in an IoT gateway on bucket trucks used in the power industry, that raises audible and visual alarms if a worker doesn't have their harness clipped onto the bucket while they're operating it. In particular, I wrote a Finite State Machine library in Python that supports what tracks what's happening with the bucket, and helped develop the (MQTT) protocol to communicate with the backend. It was a lot of fun, and very satisfying.
Having said this, some of my more cynical friends have told me: "You weren't saving lives. You were just helping these companies reduce their insurance premiums."
I made a tool to control where Linux applications put their files via bind mounts and environment variables: https://github.com/queer/boxxy
I've heard that it's made it as far as university HPC clusters to help control iffy code written by students; I'm glad I managed to make that stuff a bit easier for the people operating them.
I made an open source social networking platform that was used by non-profits like Oxfam and Greenpeace to train aid workers; the Canadian government as an intranet; the Spanish anti-austerity movement as an organizing platform; universities like Stanford and Harvard to teach; and Fortune 500 companies as a social intranet.
I had no idea what I was doing at the start. I'm very, very lucky that it worked out the way it did.
I worked on the data warehouse for federal storage of Medicaid and CHIP data (US government-sponsored healthcare programs that cover ~25% of the population, especially people with low-income, for non-US folk).
It's not the flashiest or most glamorous project I've worked on, nor was it the most technically challenging, but I think far and away it's the most useful code I wrote by pretty much any measure of useful.
Alas, the company I was at that was doing that work moved away from it before we could finish everything we had planned to build because it wasn't profitable in the way that could justify keeping it alive once it had accomplished its goal of being a cool line item we could say we did in investor pitches.
Worked with a PhD student who had an algorithm to tell airline pilots exactly when to turn their engines on. Probably saves more pollution than I or my descendants will generate in all of our lives so I feel I’m comfortably in the black there.
Could you elaborate? Why would a pilot not know when to turn their engines on, and why is the timing not obvious (eg, "when we want the airplane to move")?
Ever started your car engine in a parking space but not been able to immediately pull out? Airports are extremely dynamic and complex and do not run like clockwork - they are pushing big hunks of metal through the air and across concrete with constant contention in both cases, and waiting for humans in between. But modern airports do try to optimise their Target Startup Approval Time (TSAT) and you can Google that term if you want to go deeper.
The engines need time to spin up and warm up, and additionally you might start them then (for a million possible reasons) have delay between starting them and actually pushing back from your gate.
I worked on the first digital archiving system for the UK National Archives. It allowed digital records from central government to be ingested, categorised and preserved. Before then, even digital documents had to be printed out to be archived as records, but this clearly didn't work for things like multimedia and web sites.
I later designed the first web presentation system for UK digital government records, and the mandatory access control system for them.
I was brought to Pakistan in 2008 to help lead the launch of EasyPaisa, a mobile money platform.
It was extreme, not only due to the scale of the launch (1000’s of branches on day 1), the complexity of setting up cash logistics etc across the country, but also because of the on-going terror attacks etc.
It was hard, but super rewarding - so many people so thankful for how it made their lives that little bit easier!
Best team ever!
In 2020 we had a pretty hard pivot due to COVID and worked with several state parties and organizations to coordinate mail-in voting registration drives and handle registration form OCR and phone validation before having them sent to the state. It was a chaotic year, and I know if we hadn't been there another company would have filled the role, but it was really meaningful work that had a direct impact on the elections that year.
Most useful is relative. The book dealers who gave me my first ever contract for an automated leaflet generator that generated customized leaflets for each dealer would consider that the most useful. It's been over a decade and they still use it every day. Some other projects that come to my mind:
- an open source OIDC authorization and identity server (Ory Hydra and Ory Kratos)
- a system that uses computer vision to track food waste in industrial kitchens, helping them understand and minimize food waste
- a live milk quality estimator for a milking robot
- a browser extension called memorize. I wrote this reusing code from another contract I did while still in secondary school, and I'm mentioning it thanks to a user named lush berry who wrote "literally the most helpful thing i ever found on the internet. it helps me memorize stuff even when i'm procrastinating which is amazing. however, i have a lot of suggestions, does anyone know how i can contact the makers of this extension?". I wish I had the time to listen to these users and make the changes they want.
Built a python PDF solution to replace a process that used to be a thousand+ instances of print out paper, fill it in, scan it, email it back, someone try to read the bad scan & transcribe it.
SAS, synthetic aperture sonar. I made the algorithms and software to make the near photographic pictures of the ocean floor from these systems. Completely amazing way to see the ocean floor! The software is in wide use by sever groups and runs in real time on a Remus 600 UUV.
Not a (big) project but as a student I worked in third level
support and we had to make sure that the service number was always available. The contract had harsh penalties in case we missed a call and so we had to reroute the number even for short breaks. This was done via a terrible, clunky and ancient Cisco web interface several levels deep. It took like a minute or more to log in, navigate to the right place and copy and paste the right number.
I think the 30 minutes I spent to automate this was the best return on investment I ever reached, because the script was used for years by many people and did not only help to prevent us from penalties but must have saved a considerable amount of time over the years.
Maybe not the most useful thing, but certainly useful and the coolest thing I built is a code formatter for the m language (also known as powerquery). At the time there was only daxformatter.com but no formatter for powerquery. So I wrote one and some people are using it. Imo it has a very nice ruleset to format code that I would prefer to formatters in other languages that I use myself. People reported issues and I took care of every single one of them. It's not much but it's honest work.
I made a UI that allowed call center managers to search through historical transcripts by keyword. Previously they clicked through a table of chatlog popups and CTRL+F'd for hours.
I think compressing daily X.25 transfers for a national tax agency that pay per Satellite use.
The challenge in that context was that the compression should be done in an IBM mainframe without buying C because it was a infinite bureaucracy process. Another challenge was that it was not possible to connect the mainframe to the ethernet network because they also need to buy an expensive network interface. So we cannot compress it in a normal PC and transfer it automatically.
We did two versions one in Cobol and another in REXX.
Pathologic, a Drupal module which uses some simple heuristics to find and correct broken links and image paths in content which might happen because the content was migrated between servers, the URL of the server it was hosted on changed (such as when they started using HTTPS - early versions of this module predated the "all sites must use HTTPS" idea), the content used relative paths but was being viewed in a context where a full URL was necessary like a feed reader, etc.
It came about when I was working on the site for a local newspaper where the writers would work on articles using an internal copy of the site which would then be migrated to the live site when published, but when they linked to other articles, they would often copy-paste the URL of the article as it was on that internal site, causing a broken link when the article was published. Rather than try to teach a bunch of crusty journalists what relative paths were, I just wrote a bit of code to fix those URLs for them. With the client's permission I later cleaned up and open-sourced that module.
At its peak it was installed on over 70,000 Drupal installations that we know of (not all of them reported usage data). It's still being developed, though by other developers in the last few years as I have lost interest (and client work) in Drupal, but I'm still quite proud of it, and I still love to hear from people who say it was a must-have for their sites and made their lives so much easier.
One of my most fun projects of the 2010s was an event extraction system my team and I developed that could extract events like floodings, fires, terrorist attacks and several others, determine their properties (when, where, how many fatalities, monetary damage etc.) with the added capability that it could tell whether an event in a tweet (on "X", the system formerly known as "Twitter") was the same event that an agency news article talked about.
Another cool project was to develop a state of the art legal search engine that was put into production across law firms in the US, and that was/is used by the U.S. supreme court justices (they were given anonymous accounts so even we could not tell who entered which query).
I started a project that turned into a mulitibillion dollar source of revenue for the company I worked at. I was just an engineer at the company so I didn't get rich or anything but I would say that was pretty useful.
I started another project that turned into 8 figures of revenue but it was shut down for being too small.
I worked on a project team implementing TR-Notruf 2.0¹ for a regional ISP. TR-Notruf is the technical specification for routing calls and signalling caller location information for emergency calls in Germany.
In that project I wrote the software that receives the call, matches the caller number to the customer record, encodes the customer location information in the metadata of the call, and (based on the location) routes the call to the local emergency services call center.
While the task was quite simple most of the complexity of the project was to make sure that this service was highly available since downtime could have a detrimental effect on the health of customers.
Ephemeral developer environments. We built it on kubernetes and it took ages to get fully fleshed out. But ut was incredible. If you got a cached environment whos only differences was extra stuff you could obtain your own deployment copy of prod with a single command in a couple seconds. If it was starting from complete scratch it was maybe 10-15 seconds longer than the longest boot of all the services. You would tunnel your network and your local service thought it was in k8s and the pods in k8s thought your laptop was in k8s. There were data snapshots, and it would plugin to ci/cd so everyones integration tests just used a full environment.
We started building this back in k8s 1.4. Now you can just buy shipyard.build the weirdest part was we called our system drydock and shipyard calls their individual environments drydocks.
I literally cant imagine how i would write software at a medium+ company without ephemeral dev environments anymore.
All About Berlin, a few hundred guides about settling in Germany and navigating the bureaucracy there. It blows my mind that so many people know about the website, even here on HN. I've never been on the receiving end of so much goodwill before, and it's intoxicating.
My most useful project is arguably the Bürgeramt appointment finder, which makes a sound when it finds an appointment, saving the need to refresh the page every 3 minutes for hours.
My most used project is a simplified tax calculator. It was just meant to give people an idea of their take-home salary, but it became the most popular page on the website. I really need to keep improving it.
I just love working on this project, in large part because the readership is amazing and the work conditions are unbeatable. The only downside is the constant exposure to what is wrong with Germany.
Useful projects I've worked in are usually related to automating manual tasks.
For example I made a tool to create Azure DevOps tasks faster during Sprint Plannings. It allowed us to create tasks in batches, with templates, and displayed total time of tasks being created for a User Story.
It saved each team between 30 minutes and one hour when planning large sprints.
I worked on a phone for the hard of hearing. It is loud, and it also displays what the other party says in text on the screen. So when a hard-of-hearing person can't hear what the other party says, they can read it three seconds later.
It matters. When people can't hear, they lose their social lives.
It's called CaptionCall. It's not for sale. You can get it for free if you're (certified) hard of hearing. (Or rather, we're all paying for it - there's a couple of dollars every month on your phone bill for "phone service for the disabled" or some such that pays for this service.)
It was probably some of the first code I ever wrote, before I ever really learned how to code properly. I was deployed with the military, and there was a task that needed to be done for some of our configurations that was incredibly manually intensive. Basically: get a task document from command and translate it to a format that could be understood by our particular weapon system.
We would receive updates once a week, and it would take 2-3 12 hour shifts in a row to do this. Lots of “copy this, cross reference that”. I spent a few weeks reading Mr. Excel forums and tried automating it, which brought the total time down to just 10 minutes.
Of course, after I left, they went back to the old way because the new crew “didn’t trust the computer”.
Wrote the firmware for an amateur packet radio terminal controller that flew on the shuttle a number of times in terminal+digipeater+bbs modes, was somewhat popular in terrestrial use, and had a few other bells and whistles like RTTY, SSTV, AMTOR and WEFAX.
I’m still working on a web scraping API (https://scrapingfish.com/). For some people it’s evil bot but for others it’s enabler for public data access. I think it’s useful.
I re-wrote (in Python) the WP1 bot, which compiles information on the importance and quality (Featured Article, A, B, Stub) of Wikipedia articles in Wikipedia projects. It's currently the bot with the most all time edits on English Wikipedia.
gcc/gdb/binutils; developing the original model for commercial free software from scratch; changing opinion so that forking was no longer considered a tragedy; originated FOSS projects with independent steering committees.
Currently working on LookAway[0] which is a macOS app aimed at helping people reduce dry eyes and eye strain. I made it for myself initially when I was dealing with these problems because I was glued to my screen whole day.
Made it public and I've been receiving daily emails from users about how it has improved their eye health significantly. Nothing brings more joy to me than this.
Telematics system for local district heating company. I've implemented a feature that allows you to select all devices on a map and set some values for all of them (devices from different manufacturers). Helped to recoup the cost of whole system after they had a leak and could remotely close valves in hundreds of devices in affected area, meaning they didn't need expensive liquid nitrogen freezing equipment to block pipes for repairs.
I am still developing the QR code generator project that I initiated during the COVID-19 pandemic. It all started with a basic concept: generating QR codes linked to a registration form for collecting user data. Since then, I have expanded the system significantly. You can now explore the latest version at https://openqr.io.
I made a device that lets my kids engage with chatGPT without eye strain [1] and parental controls. No need to give them my phone or laptop, no more worrying about them wandering onto the internet [2]. IMO it is incredibly useful to have kids interact safely with AI.
I built the image processing/volume estimation/3D display core of an iOS app used for planning treatments for aneurysms. I've not been associated with it in more than a decade but I still count it as probably my greatest contribution to society. Others have taken it over and taken it further.
What actually made the most money for society and not shareholders was probably automating payments for student housing and taking it online. The student housing association are separate from the colleges and are non-profit organizations in my country, so this increased their efficiency by quite a bit.
i launched an online allergy clinic with my cousin, a respected doctor.
Me and the team talk to every single person who works with us. Every day, customers tell us we're giving them their lives back because they can finally breathe.
I filmed my cousin, our doctor, as he gave me an impromptou allergy specialist visit. Now those videos get millions of views per month from people all around the world.
I worked on a bunch of COVID testing and vaccine related projects for a US state government. Testing result aggregators and the system of record for COVID vaccines, hardest thing I ever done but also the most rewarding, I’ve been terribly bored ever since.
I've worked in the bankid system in my country. Most people I know have used it already, which is a nice change compared to the projects in which I haven't met a real user IRL. :D
I spent a couple years working on "a portable compilation target for programming languages, enabling deployment on the web for client and server applications", but none of the code I wrote during that time actually shipped, so it's hard to say how useful that was. The technology itself seems to have turned out useful, though! I suspect "none of the code I wrote during this time actually shipped, but the project was a success*" is a common story in the industry at this point?
* though my understanding is almost everyone on the project struggled to get promoted since it was behind schedule
I lead and (re)wrote Ganache, the most popular Ethereum simulator. The company I work for shut it down last year though, despite success and consistent growth.
Last year I had to go to the ER it was pretty cool to see that some of the equipment was stuff I've worked on. I needed a CT scan with contrast, I had worked on the standards body that defined the protocol that allowed CT scanner talk to a contrast injector, and they were using the device I worked on with the feature I defined and implemented.
Its pretty cool to see your work keep you alive.