71–80 of 129 posts
Earlier quoted context omitted.
> Sometimes we overcomplicate the simplest shit. Indeed. Why not use nc and telnet on port 443 to test? Linux already has nc and Windows already has telnet.
The endpoint at their end was Windows. No nc. Apologies if that wasn't clear. I was testing our end reaching their endpoint at port 443.
Earlier quoted context omitted.
Conversation from two days ago: manager: Why did you allow this thing to happen. me: It was an edge case that I pointed out 7 months ago. I've put it on the backlog 3 times, and you've removed it each time citing that it's an edge case that would never happen, and other newer features needed to be implemented. manager: That's an engineer's response. Just fix it! me: welp, shrug
> manager: That's an engineer's response. Just fix it! Translation: I didn't actually require any answer other than "I am sorry, sir/ma'am, it will never happen again." Facts are irrelevant. I may not always be right, but I am never wrong, code monkey.
Earlier quoted context omitted.
Yes, I host my blog that way: - Generate static files using Pelican - Dump the files to S3 - Set up Route53 to point a domain at the bucket - Set up CloudFront (Amazon's CDN) to sit in front of the S3 bucket, since I found pure S3 to be too slow Works incredibly well.
How much does all this cost you per month?
"Maybe you ran your SQL query a few times, fixed the errors you got, eyeballed the results, and called it a day. That’s not good enough for code integrated with a product." Biggest lie ever. That's pretty much a production-quality code here.
Earlier quoted context omitted.
Conversation from two days ago: manager: Why did you allow this thing to happen. me: It was an edge case that I pointed out 7 months ago. I've put it on the backlog 3 times, and you've removed it each time citing that it's an edge case that would never happen, and other newer features needed to be implemented. manager: That's an engineer's response. Just fix it! me: welp, shrug
I've had luck redirecting this type of question into "why did the process let this happen" where it becomes less my fault vs your fault and more "i did what you said, you did what the business person told you to prioritize, something broke" from a blame-agnostic point of view. In certain cases I've also overridden the "ignore that for now" in favor of at least some minimal fix because part of my job is to give you wh…
This is a two-edged sword, though. I agree it's best practice from a technical point of view, but enabling wilful ignorance on the part of someone above you in the chain will eventually lead to a showdown when you really do need a week to fix it and it really is critical, and they tell you not to, and they'll stick to their guns because (as far as they know) they've been right every time.
On the flip side, when something DOESN'T need HA, sub-millisecond query response time, or lynx and IE Edge compatability, people need to know when "good enough" is good enough. On my ops team, we've gotten some flak for not building robust enough of a request queue for some tasks. But it's been down several hours in the past year. The server almost never needs maintenance. None of the workload is real-time. App resta…
Exactly, this is the substantial other side of the argument that almost always seems to be left out of the discussion. "Good enough, done in a week" is a perfectly viable option that is rarely offered by timesheet-padding developers.
On the flip side, when something DOESN'T need HA, sub-millisecond query response time, or lynx and IE Edge compatability, people need to know when "good enough" is good enough. On my ops team, we've gotten some flak for not building robust enough of a request queue for some tasks. But it's been down several hours in the past year. The server almost never needs maintenance. None of the workload is real-time. App resta…
I once had an infrastructure guy who worked in the same company quote me £70K for new hardware to host a single static HTML web page. £70K of new hardware! I stuck it on an existing server and nobody noticed though I might have got into trouble with the Change Prevention Board for not using the right form or something... Edit: He did have a carefully worked out explanation of where the money had to be spent.... which…
The "or something" and "which I ignored" aren't making you look like the reasonable actor in these interactions
On the flip side, when something DOESN'T need HA, sub-millisecond query response time, or lynx and IE Edge compatability, people need to know when "good enough" is good enough. On my ops team, we've gotten some flak for not building robust enough of a request queue for some tasks. But it's been down several hours in the past year. The server almost never needs maintenance. None of the workload is real-time. App resta…
>The server almost never needs maintenance. None of the workload is real-time. App restarts are acceptable if memory leaks occur. Ah! Classic duct tape programming! Something like this is fine as long as the requirements don't change. But we all know that at a point the requirements will change. And then you have to tell your customer that the "little new requirement" can't be accomplished with a cheap little change…
Earlier quoted context omitted.
Exactly, this is the substantial other side of the argument that almost always seems to be left out of the discussion. "Good enough, done in a week" is a perfectly viable option that is rarely offered by timesheet-padding developers.
seems often developers tend to over engineer or focus on edge cases that inflate costs, and not given enough attention to ROI
> Nothing ever works as soon as an engineer writes code; it is an iterative process. One of my complaints about working in an environment where I am the only person who can program is that nobody else understands this. I've taken the time to explain this point to people, and they seem to grasp it fairly well, but once they see something that somewhat resembles the final product they get really impatient. The last 25%…
Learned that one in my first ever project. We mocked up the entire application in Visual Basic (just windows and buttons, no actual functionality implemented, we just wanted to know if it'd work for them) and then the client got really upset when we couldn't come round and install it the next day. Classic case of failing to manage expectations.