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.
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 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 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.
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")?
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.
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.
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.
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.
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.
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.
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 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’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 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.)
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.
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.
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
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.
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.
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.
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'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)
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.
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.
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.
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.
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."
140 comments
[ 3.2 ms ] story [ 63.9 ms ] threadDigital 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.
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.
[1] an old fashioned B&W monochrome LCD.
[2] its a stupid little dumb terminal
I really think every SWE should spend a few years writing this kind of thing to be better.
Honestly, that's what it boils down to.
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.
Sadly there's just only so much of that kind of work to go around and we all have to pay bills
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.
I have some friends trying to fix this[1] and they have amazing tech, but it's a difficult industry to break in to.
1. https://www.altrainfusion.com/
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.
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.
was this part of the DICOM protocol?
i have worked with medical imaging devices as well, but was not fortunate enough to work with the CT modality. cool stuff!
I had no idea what I was doing at the start. I'm very, very lucky that it worked out the way it did.
It's pretty long in the tooth now - it's pretty old! But there's an amazing community and new core team that still keeps it up to date.
It matters. When people can't hear, they lose their social lives.
What do you think about the direction medical mo ignoring is going g? Data collection, enshitification etcetera.
Is it a beat up?
Are we correct to be worried?
* though my understanding is almost everyone on the project struggled to get promoted since it was behind schedule
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.
https://www.pry.fi/en/activities/news/the_finnish_tax_admini...
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.
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.
Finland is a lot more homogenous in that sense and people certainly don’t flaunt their wealth.
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.
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.
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."