This seems to be the same plagiarizer who I found earlier this week. They're stealing other people's blog posts, then creating new blogs with the plagiarized posts.

I wrote about it here yesterday: https://news.ycombinator.com/item?id=40164077

Mohamed, could you tell the rest of us why you're doing this? Do you really want to be permanently known for this? If you do this one more time, you will be.

Everyone else, as an example, https://mamddoh.wordpress.com/2017/12/01/dev-teams-as-assets... was published in the last 24 hours but back-dated to 2017-12-01 using Wordpress's publishing interface. That post is stolen from https://www.linkedin.com/pulse/dev-teams-assets-jason-gorman . Credit to Jason Gorman, @jasongorman on Twitter, the real author.

Another example: https://mamddoh.wordpress.com/2019/02/20/a-tale-of-two-agile... is stolen from https://web.archive.org/web/20190817055715/https://codemansh... (original URL: https://codemanship.co.uk/parlezuml/blog/?postid=1580). Also credit to Jason Gorman.

I think the general concept here is pretty good honestly, but would also emphasize that sometimes you don't even know if you're solving the right problem with your shitty prototype. You gotta get it out there and get feedback as soon as possible, before you waste all your time making the wrong thing perfect. That's the key to making something that's actually useful (for other people at least).

It should be obvious to everyone that software quality is on the decline, and has been for a long time; and those who continue to espouse this "fix it later" (i.e. never) mentality, or even pure apathy as the author of this article seems to imply, are contributing to the problem.

In short here is what I learned from that conversation – it is not up to me in the role of an engineer of an organization that finds itself in a rapid business climate to worry about the risks associated with releasing software in a certain state.

How about having some pride and craftsmanship in your work?

It's rare that I see something on HN this baldly antithetical to my own professional philosophy.

As an engineer, it's part of my job to vocalize concerns about impending quality issues. That information is important in the decision-making process that leads the higher-ups to set the release timeline. By keeping my head down and ignoring the situation, I break that feedback loop.

In the wake of all this Boeing insanity, it's more disturbing than ever to see this mindset stated so nonchalantly. It's just a helpless and nihilistic way of looking at your work.

Maybe I am entering that age, but in more and more areas of human endeavor I start to see the same signs, that seem to tell "this house of cards is about to collapse".

Maybe this is not a bad thing. A crisis is a necessary stage in evolution of any complex system. I just hope it does not bury us in a perfect storm...

This seems misguided, and also presents a false dichotomy of “I must do everything the business lords tell me” and “I will fix every possible bug at 100% coverage or never release.”

The most valuable engineers raise problems and alert/pursuade owners of the business to issues before they are issues. You can achieve a certain level in a career with the mindset this blog post talks about, but there is a hard ceiling.

This seems like a story out of time--I had to check the date to see it was 2024. I can't remember the last time I made software with releases and had QA folks run it through its paces. Maybe over 10 years ago I worked somewhere with releases each week or two, even there releases were almost daily by the time I left. Everywhere since, testing is automated and releases are continuous throughout the day so the developer (and peer reviewers) are the ones directly making the assessments whether a feature is fit for use by customers.

I mean think about it, would a QA or business person be able to assess a security issue that a developer is aware of? We have to be responsible to raise the issues and have them understood by others, or just get them fixed (or satisfactorily mitigated) within the team. Another example is performance of operations, certain inefficient queries run frequently not only run slowly but can consume enough database CPU to basically make it unable to serve requests. The developer is the best person to be able to tell this in advance.

The best situation to be in is to be able to both tune your processes and sense of safety to ship quickly but not unsafely. And if things do go wrong, don't blame a person but the processes in place and both technical and subjective safety measures and make changes accordingly.

> My job is simply to make sure that software is releasable given the business’ definition of what is releasable, and to improve it in the future in such ways the business sees fit. Building on that concept, it is even more important that it is not my job as an engineer to assess the risk of releasing a piece of software to the public as I, and other engineers are (typically) unqualified to do so.

"My job is simply": These words have no place in the mouth of any engineer.

"it is not my job as an engineer to assess the risk": That is literally your job as an engineer.

"Releasing imperfect software is just the nature of our lives.": This is a thing that happens, sometimes by accident and sometimes deliberately (hopefully more the former than the latter). Why would you deliberately release imperfect software? Because it is sufficient for a need at the time, and you assessed the risk that it created and found that releasing it in an imperfect state was better than delaying for a perfect (possibly unattainable) state.

Note that key step: you addressed the risk. You. Your responsibility as an engineer.

If you don't want to do those things, stop calling yourself an engineer. If you do keep calling yourself an engineer and continue to deliberately fall short of your responsibilities, kindly fuck off.