beh9540

I worked for a company once where IT Desktop Support had to install all software, even for teams who worked in Technology. I was tasked with starting a whole new program and needed a bunch of new tools installed, and needed to supply them with a list of all these applications we'd ever need.

Out of curiosity, after they didn't provide the right software a few times, I asked the guy how he was validating they were securely sourced, etc. His reply was "Oh I just googled it and grabbed the first one." After that, I at least sent him the links of where to download it from, but I couldn't convince any of the IT executives that this policy is pretty useless if they're just grabbing and installing.

I interviewed with Wikipedia a year or so ago, and right from the start the recruiter said “since we’re a donation based organization, we have to pay below market” and it was definitely below market. I politely turned them down, because I couldn’t take the pay cut.

So they’re asking their employees to donate as well, when they don’t need to.

One of my favorite resources on 1:1s, I was just sharing this in a management class I had to take.

I highly recommend his book “Managing Humans” to anyone who’s looking to be in Engineering Management.

This and the glee of executives over systems that increase the potential for overdrafts or charge backs is why I’m glad to not be in banking anymore.

One of my most memorable conversations was with a rep from one of the core processors about how she makes it her mission to make sure everyone in her family opts out of overdraft protection.

Banks spend so much time on the wording to make it sound like they’re doing you a favor, I’ve had to convince my wife not we didn’t want it.

I noticed the same thing - Nissan and Infiniti models that are basically the same chassis but with fancier features going for the same price. Infiniti was lower than MSRP but Nissan was above.

I always dreaded talking to support - AKS would routinely break in weird and ways, and it was always super frustrating waiting for support to fix things that shouldn’t have happened.

We once had an error with Azure MySQL and AKS, where it would just stop dropping packets with basic instance types. Support could never fix it, we ended up just upgrading to standard because that worked.

I will say this - the manager of the team at Azure did comp our upgrade, because they couldn’t figure out why it was happening. I tried very hard to get our project off Azure, but because it was negotiated as part the Enterprise Agreement with Microsoft, it was “free” so the CTO wouldn’t budge. I assume this is how many people end up needing to deal with Azure.

What I don’t understand about this is they were most likely an at-will employee. So the company could have just said “new policy, sign it”.

I had an employer do this - I was working there a few years, owner came in and said “we’re doing background checks, fill this out and sign it”. I asked what happened if something came back on it, and he said that I’d be fired.

My biggest mistake was not accounting for the ethics of what the company was doing.

I was young, and super excited to have a job in software while still in school, building things. Only much later did I realize that multi-level marketing (pyramid schemes), pay day loans and companies selling bath salts to smoke, all hurt people.

I was removed enough from the problem that I didn’t see it at the time, and it all seemed so exciting, but I certainly have lots of regrets from that time.

This reminds me a lot of work I used to do in the controls world. We had a large amount of equipment all with proprietary networking to embedded systems that were basically Intel 386 systems running DOS. The big issue we had was they had spinning hard drives in them, which would fail, and replacing them meant we needed to replace all the nodes on the network, often hundreds of pieces of equipment. To make matters worse, the company was long out of business.

My boss came up with the idea of replacing the drives with industrial flash drives, so as the drives failed we replaced them. We had some issues getting drives that were small enough, as there was an issue with the BIOS and drives that were too big, but we were able to keep the systems running so we could eventually replace the whole networks while equipment was getting upgraded.

We had an even older system that was an entirely custom mainframe computer with 10" hard drives and modem banks that we all stayed far away from. It wasn't as critical, so it was even slower on replacement.

This is pretty much exactly how I got my first job programming. The only student job I could get at college was working for the HVAC department: organizing filters in warehouses around campus, taking out the trash, etc. I got a very similar "go hide somewhere" from one of my bosses at the time, and so I started reading about the control system(s) HVAC used.

Eventually word got out to the controls department that some student worker knew a ton about the controls system, and I got moved there. They had an issue that they wanted to know the forecasted weather, so we could get the central plant going before demand started kicking in, and the vendor kept telling them custom development was coming in a couple of years. I ended up writing a server for BacNET/C that did it for them, and it ran under the desk for years.

I think the big reason for this is most dealers know there's little maintenance cost on EVs, which is where they make their money. With our Nissan Leaf, it's a struggle finding a dealer that even has an EV mechanic, and the ones that don't won't touch it if they don't have one.

With that said though, I've found that sales not knowing anything about the cars they sell to be the trend of late. Even with ICE cars I've bought lately, the sales people have known virtually nothing about the car that I couldn't read on the sticker.

Qventus | Senior Full-stack Engineer | Full Time | REMOTE

Qventus is a real-time decision making platform for hospital operations. Our mission is to simplify how healthcare operates, so that hospitals and caregivers can focus on delivering the best possible care to patients.

Tech Stack: Python / Django, MySQL, React

More about the position: https://jobs.lever.co/qventus/19a6bc4b-5911-49ea-8e3d-7c6af4...

Feel free to reach out to me, I'm the manager for the team and happy to answer any questions you may have. blake@qventus.com

Keep the Apidistra Flying is one of my favorite books. I first read it in High School and I remember distinctly relating with the scene when he's counting how much money he has left in his pocket during the date.

We tried this on a b2b SaaS product I worked on where we had a lot of "third party" users (volunteers for a customer) who were only going to use the application once a year at most. One of the biggest hurdles we had was explaining it to enterprise customers - when they were doing their due diligence, it didn't "check the box" and we had to change it pretty early on in order to accommodate this.

When I bought my router table, I remember reading a lot of articles about lifts not being worth it due to lack of repeatability / slop in most of the DIY and cheap mechanisms unless you bought the $500> lifts. I'd be curious if this had a similar issue. I went with the Bosch table without a lift for $169 US, and it's nice that I can put it under my bench when I'm not using it. I use it with the fixed base on my DW612, which means I can move just the powerhead to the plunge base when I don't need the router table, so I've only had to buy one router. Works pretty well, and the Bosch comes with a whole bunch of options for jointing and workholding as well.

The VA sort-of does this, at least when I worked for them. The issue they had when I was there was depending on where you went, you may or may not have access to the record, because the VA didn't use a central system, it used many systems across the country, each with their own records(basically their own mainframe). We once added a hospital to our system, and had to have dual workstations because the systems couldn't be easily merged, and they had to look up patients in both systems.

Also, with Veterans Choice, I don't know how much there was an effort to bring this data back. Same thing with the DoD, for a while there was an agreement to send medical records for active duty to the VA, but then that got pulled for a time.

I believe there was a huge undertaking to consolidate these to fewer systems in the last few years, but Vista[0] (the VA's EMR) is pretty scary. I wouldn't wish it on anyone.

https://en.wikipedia.org/wiki/VistA

Maybe instead of an image, both parties could use an ODB reader that signs the mileage cryptographically, and pushes it to the blockchain?

This way both parties could verify the transaction was completed as contracted (IE no joyrides).

I'm still in the camp this probably doesn't need blockchain, but that would at least handle the image manipulation problem.

I'm fairly astonished how few duplicate applications are here.

I work for a company the same size, and we have many more applications than this, with lots of overlapping and competing products.

Kudos to management at Github.

SARs are required to be reported for all daily cash deposits greater than $10K by the Bank Secrecy Act.[1]

Cash heavy businesses could easily hit this level, as well as large transactions that are perfectly legal, so you wouldn't want to stop doing business with a customer, just because they deposited a large amount of cash.

[1] https://www.occ.treas.gov/topics/supervision-and-examination...

I agree with you, in most cases, but unfortunately in some regulated industries, more and more auditors are putting WAFs as a requirement for secure architectures. No amount of explaining why it doesn't make sense changes anything, as the auditors rarely understand why they're asking for WAFs - they just need to check the box.

There are occasions though where WAFs can be somewhat useful, like where you need to secure a vendors webapp that you can't patch without them releasing a fix or trust, but for legacy or business reasons are required to run.

So some of us are forced to buy and implement these products regardless of effectiveness, and it is helpful to see how vendors respond I think.

This cannot be stated enough. The company I worked for purchased "the leading gartner SAST testing solution" before they even started a project and had a framework chosen. It turned out the SAST solution didn't support the latest major version of the framework we were using at the time, and didn't support the latest version of the language we were using. Even worse, it never seemed to ever report an issue, and took hours to run at times, eating up build minutes.

I ran bandit on the code base just for fun one day, and we had four hits and it took 5 minutes to run. It took a while, but I finally convinced the powers that be we were better using the tool we could verify works, rather than trusting the SAST vendor that it worked.

I can second this - our mainframes average response time is 2-5 seconds based on the call, with 99 percentile responses in the minutes per transaction. This is after a fortune was spent moving us to a "faster" platform.

Also, at our bank, very few applications use the REST API. Since most applications are developed by contractors, most vendors don't want to use our custom API, and instead opt to connect to the mainframe directly, because then they can reuse the code at other banks after charging us to develop it.

I ran into a great "where's the code" on a "lightweight API" ruby project once. Opened up the codebase to fix an issue, and there were no .rb files at all. After opening every file in the repo, it turned out the developer of the code base had the entire service in the Rakefile.

Waterfall is certainly a thing - although it's taken most of my career to run into it. Where I work currently (banking) some of the projects are waterfall, some are agile. The waterfall group has requirements gathered for them by the stakeholders, they build to spec, it's tested by the stakeholders after development is complete, issues are fixed and then it's deployed, all managed by a project management team. There's a series of "phase exits" that need to be signed off on by executives in a big meeting, and the project doesn't move backwards. Massive amounts of documentation are generated (and never read, except by external auditors) for every aspect of the application - every workflow, procedure and logic built into the application. Iteration doesn't happen at all, everything is a massive project, or bug fixes.

All the "boogeyman" activities happen - scope creep goes crazy, testing is run short to hit deadlines set, etc. Like you I never really thought it was a thing until I saw it with my own eyes.

I was really surprised docker or kubernetes wasn't one of the items on here. While I use both, they definitely both could use cold showers to make sure they provide value.

I applaud them for using open source software, and contributing back their findings, but my first thought reading this was "isn't it a little odd a security appliance vendor who actively markets a "Remote Secure Access" system doesn't rely on there own systems?" Their website has a whitepaper link on every page on how your business should use them for remote access.

I'm so glad I'm not the only one who has experienced this. Only thing I'd add is the lack of understanding about how hard backups are at some of the scales of data in research. Trying to explain to researchers who run the departments that doing a full backup on 35TB+ of data on all budget drives is going to take weeks was something I could never get across, until they lost all their data.

And no, snapshots weren't an option on a legacy clustered filesystem that they wouldn't migrate from.

I argued against this pattern and left shortly after the owner of a company I worked at made me implement this pattern. As the head of the department I actually refused, but he went to one of the engineers on my team and had the push the change.

I can never figure out why people don't realize that even if it's legal, it comes across as creepy.

When I was in school for Microelectronics, we were told very early on that experiments needed to be designed for the least number of runs, because of the sheer cost of taking a production fab down for a short period. That and the design better be flawless or your manager would never allow it

I'd be interested in seeing the data on this. My wife's a teacher, and in her school district there is no maturnity leave, you need to use sick time. So we were trying for the opposite - to make sure our child is born during the summer.