Hacker News Reader

Comment by digitalsushi | Hacker News Reader

The red tape is garroting us.

My wife's dev environment VMs are 'remediated' at 8pm regardless if she's using them or not - there is no override policy - and the company is singing the success story of saving 40 dollars in licensing.

At another corporation, it can take several weeks to learn how to fill out the IAM role and permission boundaries to allow a new app to run - and a governance board has to review it and allow it.

We have weaponized Agile and Scrum - loathsome coworkers will write stories to write stories. Upper management is pushing us to mark "out of office" one day a week, but to then work through it, due to superfluous meetings dragging the productivity down.

A 4000 dollar, maxed out macbook pro boots up directly into a load average of 20.00 and upwards, as antivirus software scrubs every interaction and files open and even at rest deep on the SSD disk. Teams videos run at 3 FPS and lag constantly, making one look like they dont understand the conversation.

All of this, to dabble in code, the thing we're passionate to do, to try and help these places exist.

I didn't fall out of love with coding. I love it deeply, but there's an abusive guardian at the front door with a shotgun, oblivious that I'm here to help

View on HN

Programming isn't the only career that is having its soul crushed by red tape. My wife is a doctor and these days about half of her time is spent filling out forms and jumping through bureaucratic hoops instead of actually serving her patients. It is amazing how many nurses, admins, and others around her are constantly trying to figure out how to navigate the system to get any real work done.

Every profession needs to have some processes in place to make things run smoothly, but when the processes themselves get in the way instead of helping; then the tail is wagging the dog.

It is kind of like free TV shows. We always understood that commercials were necessary to pay the bills when we were not, but now many shows are completely unwatchable as 60% or more of the time spent in commercials.

I remember in 2017 I went to my GP in the US for a physical + bloodwork, and when I said what I was there for, the doctor recoiled a bit – because allegedly I had been booked for a 15 minute slot, rather than 30. And there was no way to do everything in 15 minutes.

I had no idea such a thing even existed. Sure, there's a schedule to appointments and you can't just take all the doctor's time, but I had never ever heard of anything like that. As if at 15:01 into the examination, we'd both turn into pumpkins or something. Or the idea that really any health problem someone had could be observed, diagnosed, and treated in a quarter hour.

Turns out that the hospital system she worked in had been aquired by nameless-faceless-health-conglomerate, and that's how they (and many other) hospitals worked now. Everything was KPIs, everything was maximizing people-in-and-out every day.

When I asked the doctor how she felt about it she obviously tried to be as democratic as possible about voicing her displeasure at the new system. Annnnnnd about 6 months after that, she transferred to working at a senior living facility where she just gets to chat with elderly people all day, refill their prescriptions, and make sure they stay healthy.

> about half of her time is spent filling out forms and jumping through bureaucratic hoops

I was reading research on this recently because I’m working on an EHR software. The cited study concluded that physicians spend about 15% of their time face-to-face with patients and about 17% filling out documentation. For interns it’s worse with 11% time with patients and 22% writing things down.

This was in Principles of Health Interoperability, a book from ~2016.

On the bright side, all this documentation has been shown to literally save lives. Not sure it’s doing as much for us coders.

Hilariously, the rates are even better if you have a medical transcriber in the room, taking notes for the doctor so they can focus.

... as long as we can get patients to speak in the normal way they would with a doctor, instead of being inhibited because of the second person in the room.

> as long as we can get patients to speak in the normal way they would with a doctor, instead of being inhibited because of the second person in the room.

Now... That looks like a place where AI can help.

> all this documentation has been shown to literally save lives

The docs saved them.

As I said earlier, some processes are beneficial. Properly documenting something can help doctors do their job correctly.

The same is true for programming. Having good comments, unit tests, and other things that can sometimes seem tedious while we do them; can actually save us time and help us write better code.

It comes down to having the right balance of process where it helps instead of gets in the way. The trouble with bureaucracies is they never know when to stop growing.

I agree and offer another perspective. My red tape comes from Google Play and App Store. Their restrictions, opaque manual review process, slowness, inability to quickly push updates, and cumbersome storefront backends have pushed my company to move away from native mobile development, which I love, to a web wrapped app, which I disdain.

I distinctly remember thinking in 2014 there was no way the respective app stores were going to get worse. By far my worst professional prediction.

Fun to read this comment, as I'm part of the team that deployed the exact same measure as for your wife: we now shutdown dev environments each day at 8PM. We decided to do so because over the weeks, we saw that a lot of devs "forgot" about their dev envs and they were up & running for 6+ months for absolutely nothing. On the other side, we are constantly requested to reduce infra costs, and dev environments (even unused) cost a lot.

In the end, I'm glad we deployed this.

Couldn't this be done by giving the devs some transparency into how it's killing their team's budget and reminders, instead, so that they'd manage this themselves? Because this sounds super frustrating to deal with.

We kind of already have. We built a CLI that allows them to create/update/delete/list all their dev envs, so they have all the tooling needed. Also, we are still a small/medium sized company, so we often had the chance to talk with them to expose this issue, but in the end it never really worked.

> we are still a small/medium sized company

Sorry this is somewhat off-topic, but _why_ do you have virtual development machines?

We currently have ~40 microservices running (for the same number of devs), and having the full stack on a laptop is not possible. Especially with 80% of the devs having MacBook and Docker in a VM.

Also, this allow us (the infra folks) to chose how devs will work (partially), so it's easier for us to debug when they have issues because we do not have to deal with custom Makefiles etc.

Is it really needed to have 40 microservices for 40 devs? What I mean is that you generally scale out to so many services when you need each to have variable scalability, so each part of the system can scale up/down as necessary.

If you don't need this, all these services could be written as larger modules, with proper separation of concerns but easy to be deployed as a single piece. Collect some stuff that are similar in domain and create a well designed monolith. Easier for operations, easier for devs to maintain. Dependencies upgrades aren't a nightmare, or you need very good tooling to not create toil (which generally a small operation won't have).

Just throwing this in the wind because it sounds pretty heavy for a 40-body shop to be carrying as many services, at least I don't see the benefits unless for the aforementioned scalability advantage.

One example can be to target many different OSes/CPU architecture / GPUs architecture.

A weekly digest over email, or a dashboard on a real screen if you all work out or the same office, indicating costs and what's contributing to them. That will do wonders.

That will also add a lot of overhead/maintenance cost that we can't currently handle.

How much does it cost to have a single environment running overnight?

Not shutting down my machine saves me 2-5 minutes probably. Which seems like it might be worth a few pennies, but I hate the waste and environmental costs of wasted energy.

What we really need is a program that shuts off a devs environment, but then can boot it back up 5 minutes before they start working and somehow open all the applications that were running back to the exact state they were in before shutting down..

Initially, we were using kube-downscaler to do this. It stops a namespace at a given time and restart it in the morning. However, a lot of namespaces (= dev env in out case) were restarted for nothing, so we created our own tool that stops them at 8PM, and restart them when the dev runs a command with our internal CLI.

Not only would they be forgotten about, but without forced downtime/reset, they start slipping into production use. The dev asks someone to “try it on my server”, then the word gets out about this other server that works better and has more features. Before you know it 2 years have gone by and this “dev” server is a critical system the business needs to function.

In our case, those dev envs are actually feature envs: they are a copy of staging with only the microservice they are working on that differs. So it is impossible for those env to end up as prod stuff for us. However, each FE is an almost exact copy of staging, and each dev has 1-2 running FE, so it requires a lot of compute and stopping them has a real impact

This sounds so much like my company.

Add in that management will make commitments to customers without having any idea what it will take to execute, schedule 20 hours of meetings per week, expect us to work a total of 60-80 hours a week to meet the arbitrary schedule, and also change priorities seemingly at random based on which customer is making the most noise.

The best part is HR regularly talks about how we are a certified great place to work with amazing work life balance.

I'd quit but equity...

> I'd quit but equity...

From what I've seen, those golden handcuffs are usually gold-plated handcuffs with the same steel underneath.

Meaning, the eventual payout is rarely what you think it is?

In a sense, yes. To be honest I didn't really want to spell it out because I like leaving something to the imagination for my readers.

Sometimes they're solid gold (ie, preferred equity) and one has to ask themselves whether or not it's worth their time, attention, security, and happiness. Often the handcuffs are gold-plated (ie, employee options), and give the illusion they're worth suffering for in a similar manner as the solid gold ones.

At the end of the day, they're both handcuffs and serve the same function as the steel ones.

schedule 20 hours of meetings per week

Have had this problem so much. The problem is managers and analysts are productive through meetings.

Software Engineers are productive in blocks of 4-6 hours of focused concentration. Many managers don't realize this and forward FYI meeting invites to developers all day long.

A relevant essay: Maker's Schedule, Manager's Schedule http://www.paulgraham.com/makersschedule.html

(It's by Paul Graham, but I won't assume everyone on Hacker News has read it.)

Just ask if you should be focusing on anything other than your important project and if they could help with the communication around pushing the deadline out a day to attend this meeting.

Or just skip it and say you are working on x or y.

A lot of programmers don't realize that there's a difference between <building an application> and <ensuring that the actors that make up the global economy generate predictable returns on investments in order to grow stock-based compensation for shareholders>.

All of the bizarre decisions by higher-ups--red tape, bad hiring, conflicting goals, ridiculous security policies--it all boils down to "what do we report on the financials, and how can we manipulate investors to continue to buy and hold"? It doesn't even matter what's actually profitable, just what's perceived as increasing real or potential share values by the actors in the market.

That seems to assume organizations are 'rational actors'... Which sadly is the minority of organizations I've worked for.

The premise ignores the layers of people in-between the 'C' levels trying to get that return, and the engineers trying to build stuff. It seems lots of these people are mostly interested in politicking and justifying their position. (which I think accounts for some of the WFH resistance. If people can get stuff done with less supervision, it might lead to less managers :-P )

I've never met an organization staffed with rational actors that had more than like 8 people in it, so you're not wrong.

I think what I'm getting is that ultimately every edict that flows downward into the layers of management and engineers is centered around increasing perceived profit for shareholders. Any department, project, etc. at large enough organizations was ultimately greenlit for the sake of possibly making more money (not for improving the product at a cost to the company or improving society, etc.)

>> I've never met an organization staffed with rational actors that had more than like 8 people in it, so you're not wrong.

LOL - I like that, I'm stealing that line :-)

I disagree with 'was ultimately greenlit...'. Seems like quite a lot of them are greenlit to improve someone's political position within the organization. (often, despite being told it will be a net negative for the organization as a whole)

Things like 'use it or lose it' budgeting, compensation tied to headcount (and not value generated), etc. cause real conflicts of interest at many organizations.

Anyway - thanks for the chuckle - I really love the 'rational actors' line :-) (hopefully, I'm one of the 8 ? :-D )

Oh--I see what you're getting at. Yeah, I understand and agree. I'll have to say my point with that caveat in the future. I'm glad you liked my joke!

"Perceived": profound

Related, distantly:

"The secret to success in the stock market is not predicting which stocks will appreciate but rather anticipating which stocks most investors believe will increase in price."

—John Maynard Keynes, who in addition to writing foundational economic texts became rich as a result of astute investments in the stock market

I think this passes the buck a little. There are a lot of problems created by software engineers and software engineers alone.

There are of course management problems, but that happens in every field. Software isn't special in that regard. My issue with software is that, in general, the software industry is both myopic, clinging to some bygone coding aesthetic of the 80s, and discontented, constantly creating new stuff or wanting to complicate stacks.

Just look at the current status quo of source code management in Git. Management didn't make that decision. Software engineers did. Git is the most overly complicated software ever for its purpose, but it was software engineers who chose it as the standard and decided everyone needed to code as if they're on the Linux kernel team.

> Git is the most overly complicated software ever for its purpose

Sorry, but I call bullshit on this.

Git has a lot of features. Most people probably don't use or need most of those features. Maybe it's like Microsoft Word, where the quip is that people only use 20% of the features, but it's a different 20% for each person. That's not relevant.

What is relevant is that to use Git effectively for most projects you don't need to know that much, you don't need to get into the "advanced" features, and in fact can learn everything you do need to know by reading only the first 3 chapters of the manual, and knowledge of the "git flow" workflow (you can of course modify this to your needs).

It is not harder to effectively version control your software with Git as compared to any other VCS/SCM I've used and, in fact, branching and merging is excellent, and makes life a lot easier for everyone involved. Pull requests also make life very easy as compared to other systems.

Switching to Git, within a few days it was apparent to me that it was better and easier than CVS, SourceSafe (!), Subversion, Sourcegear Vault, Perforce, and AccuRev (I can't speak to others because I haven't been exposed to them).

Of course, you can make Git complicated - or perhaps I should say more complicated than you need to for your use case - but that's optional and entirely on you (or other devs you work with - in either case, Git isn't your problem).

Git is complicated. I or others didn't make it so. The fact that someone didn't tip-toe around Git's complexity in just the right way isn't on them. It's on Git.

I also didn't name Git's commands, like the unfortunate `blame`, or design its interface such that there are several examples of `git <command> --<flag>` doing something wildly different than `git <command>`.

I'm curious about your opinion on Git. It's actually a tool I'm excited to teach to non-developer people who deal with text documents and the need to keep a history, multiple versions etc. I'm aware that now these features are integrated in some common offices apps so there's less of a need for Git there.

However what's wrong about Git for code? How would you cover the same features differently? When I say "Git" I refer to all the ecosystem that's based on Git, including GUIs for those who don't like the command line

its like using the army to watch over kids crossing the road to school Many other source control systems with far simpler systems

this whole branch and pr into merge process didn't exist 10 years ago like it does now. It started from open source and low trust - but nobody stopped to ask what problem it solves.

If somebody needs to check your code as part of a formal process - rather than some arbitrary invitation you issue in special cases - you shouldn't of been hired with the job of writing code.

Source code control is important, but Git is not the only source code control system.

Not all companies are like this. I know it sounds hard to believe. I had to look for a while but trust me, there are much, much better places out there. You just gotta find them. It's hard to judge in advance, and there's luck involved, but it's possible. Don't lose hope and don't settle for crap like this, get out while you can.

A lot of this sounds like big company stuff, perhaps in financial services?

The issue with places like that is that risk is prioritised higher than delivery speed, which is arguably fair enough when there is a risk of large regulatory scrutiny and reputational risk.

They are also set up to scale to thousands of engineers, so need consistency in technologies, reporting and ways of working.

I didn't enjoy working in that environment, but I have more empathy nowadays for why they have to work in that way.

Work for a smaller company or startup, and all of that stuff goes away.

> The issue with places like that is that risk is prioritised higher than delivery speed,

I don't think most organisations actually make such decisions knowingly.

I don't believe the CEO ever says "This endpoint management system will remove 20 minutes of productivity per person per day, but it's worth it, let's deploy it"

More likely the organisation salami-sliced away productivity 2 minutes at a time, the bosses have don't see the problem because they use macbooks, and the endpoint management team all love endpoint management so they ignore the problem.

This sounds like it's the tyranny of the bureaucracy. Here's an example of what I mean:

My kid takes the school bus to school. The bus is often late making my kid late. Mind you, my kid is at the bus stop an hour before school starts and school is only a 10 minute drive away. When this happens, my kid gets marked tardy and after 3, she gets a referral, even though it was the school that was responsible for her getting there on time. When she asked why, the response was, "it's policy."

Could folks be optimizing for the wrong thing? I feel like there are plenty of 3 person startups where you can code your face off without red tape or human interaction. However, such gigs come with lower pay and worse work life balance.

Personally, I made the choice to join big tech and collect a bigger check. The work can be slow and boring, but it's a conscious tradeoff I am making - money instead of fun.

Also in this agile scrum world no one seems to care about technical feats or technical acumen. Its all about closing JIRA stories. Somehow Agile just grinds out all the fun out of coding making coding feel dreary and robotic.

This sounds soul crushing enough to me that I would look for a job elsewhere, even if it means taking a financial hit. Many places are not like this; I would look outside compliance departments, large financial and utility companies and established defense contractors for a more open setup.

There is no value in constant-surveillance antivirus software on a modern Mac — if your IT requires this, run far, far away

For many companies it's just a checkbox towards compliance of some sort. You can argue and be right until you're blue in the face, but in the end it's the approval of, and certification by external auditors that matter.

As someone who works in IT, it is almost never up to IT what goes onto the Mac device. It's usually a compliance/legal ask, good luck explaining to a customer why you don't have anti-virus.

Customer wants to see: Yes, Company X has Y anti-virus product on all devices.

What customers demand antivirus software for office workers who provide a service to a company who provides a service said customers?

You could say some certification requires it and customers demand that certification but that doesn't cover most cases.

Have seen this where I am since we have grown from a small company to a medium sized one. Spyware, endpoint protection which crippled sudo, can't update tools that we have used for years.

> "All of this, to dabble in code"

I'm not a professional programmer, and when my laptop takes 10 minutes to start moving the mouse cursor smoothly after waking from a weekend suspend (today!), I'm pointing fingers at you all, the professional "dabblers" who don't understand computers, don't understand firewalls, don't understand databases, don't understand algorithms, don't understand garbage collectors, don't understand or care about any kind of security or legal compliance regulations, don't optimise anything, don't want any constraints, any meetings, any plans, any accountability, just want to 'optimise developer productivity' where you play with the most fun framework of the day and millions of users suffer the consequences of it.

"Developers" have only "developers" to blame for how software takes down a 1,000,000 IOPS SSD to the point of complete machine unresponsiveness. It's not 'Jira' or 'stories' or 'weaponised Agile' or 'Indian outsourcers' or 'management' doing that.

Maybe instead of seeing it as red tape garrotting you or an abusive guardian at the front door with a shotgun, see it as end users with scowls their hired heavies at the door, end users wanting their computers back from your code, wanting their data back from your clutches, wanting their time back from your advertising, wanting their lives back from your industry's overreach. People who've had enough of the priority always being your comfort and convenience. People who've had to bring in the security heavies with their legal and compliance regulation to try and herd you because left to yourselves you leave SQL injection and plain text secrets and cross site scripting and logging libraries that can talk to the internet and execute arbitrary code and when told to get your act together, throw your toys out of the pram and want dynamic languages and moving fast and breaking things because anything else is too boring.

Hobbyists can be dabblers, end users can be dabblers, people who get their job done in VBA and Excel or a Perl script copied from the web, or IFTTT, you aren't "here to help", you're here to laugh at them for using VBA and Windows and offer them a worthless meta-interpreter in LISP or a workflow from the 1970s. People are crying out for help and all they get from professional developers is scorn of business apps and CRUD software and yet another text editor and whining that it doesn't work on Linux. End users are not interested in whether Java has type erasure in its generics, or whether the BEAM VM is outdated or whether TypeScript is an improvement on JavaScript, they're interested in how to share a spreadsheet with a supplier in another company and why search never returns what they typed in, and why their phone can't respond to the 'answer call' button before the caller hangs up.

As 'Uncle' Bob Martin said in a talk in some recent year, if the software development industry can't sort this out itself, if it can't fix the Boeing 747 Max and the cars on the road being exploitable over their cellular connections through the infotainment system to disable the brakes and cut the engine, if it can't fix the senator's private emails being leaked, or the shareholders being hit by a company taken out for a week by ransomware, it can expect governments to implement laws regulating software development, and those laws will be overreaching, uninformed, out of touch, hard work, no-fun, and mandatory.

> when my laptop takes 10 minutes to start moving the mouse cursor smoothly after waking from a weekend suspend

Apologies for not reading your comment fully, but in this specific instance it's because a weekend suspend causes hibernation, which means all your RAM is saved to the disk. The file can be pretty large (same as your RAM, say 32GB) but reading it fully takes much longer (at 200MB/s it's three minutes). In order to wake up your computer quicker (a few seconds), instead of reading it fully to RAM, the memory is read on demand, i.e. when a process needs it. This comes at the cost of keeping your computer lagging for the next few minutes. This is just one of many many small engineering quirks that makes up an operating system. However considerate the developers work, tradeoffs have to be made here or there. You can't power off the computer and expect to restore its state fully within 5 seconds.

> the professional "dabblers" who don't understand computers, don't understand firewalls, don't understand databases, don't understand algorithms, don't understand garbage collectors, don't understand or care about any kind of security or legal compliance regulations

A single code base consists of many parts independently written by developers of all fields. There are CPU people, networking people, disk people, kernel people, compiler people, cryptography people, etc. And there are things that are simply not possible even if they work their best. There are developers that focus on making the operating system as safe and stable as possible, but they build aircrafts, cars, rockets and household applicances, which (from a software development perspective) are far less powerful than regular computers.

That said, the community of developers is indeed very bloated and there is no need for so many of them. We just haven't found a way to distribute money to that small set of necessary developers without compensating everyone else and bloating the company to keep talents away from competitors.

Takes 2 seconds on my Mac, just like on any regular Tuesday.

It's the red tape blocking developers from actually working on fixing the problems you describe.

Yet curiously, there doesn't seem to be any red tape blocking them (us) from pushing out broken changes that no one wanted in the first place?

This seems to be an increasingly common theme these days. Some harebrained thing is released seemingly with no review or testing whatsoever, just because some dev (or worse, a "UI/UX expert") decided they wanted to. It breaks some existing use case and suddenly we need a 2, 5 even 10 year discussion about how difficult it would be to fix -- nevermind if no one wants or uses the new thing even after all that time.

exactly because delivery experts put in PR processes and QA processes in different teams to do this

complete abdication of responsibility

This.

For most of the past decade, the true cost of "developer productivity" was borne by the users of their software in wasted time, wasted electricity, and money thrown after buggy or nonfunctional features.

At this point in the aviation industry's lifecycle, we had gone from learning that flying was possible to landing on the moon. If software had followed the same trajectory, we'd have AI servants right now. But programmers insist on re-creating the wheel every few years, so instead we just get new frameworks and languages that do what the existing frameworks and languages do, and a whole lot of new bugs as programmers race to adopt the hot new thing.

most of what developers have to ship is not in their control - very often teams are not responsible for defining what they do or how they do it now.

I wish you were right because it can be fixed by looking at developers but its the entire snake oil industry of deciding what to do that is the problem

I'm quite positive ChatGPT wrote this to troll us.

r/confidentlyincorrect

Very reactionary take here. Blaming developers for everything that's wrong is just as bad-wrong as blaming everything on management, the C-suite, capitalism, or anything else.

I've worked with some very ignorant, lazy, incompetent, individuals. Some had 'programmer' or 'developer' in their title, others were managers or product owners or QA, etc. etc.

I do agree with your last point. I expect the real-world consequences of Bad Software to become more serious and common, and that will result in more regulation of the industry.

I think he's focusing on the word "dabble", and how unprofessional it sounds. I'd be inclined to agree. I'm a developer and would never say I "dabble" in code. It just sounds light, playful and uncommitted. If your goal at work is to "dabble" in code because you're "passionate" about it, you have an unprofessional mindset. You're putting your passion above the mission. Maybe reading too much into a couple of words, particularly since this is the internet, but in general I'd recommend avoiding words like "passion" and "dabble" in professional contexts.

As the commenter above who used those words, I stand by them: my influence over code these days is, indeed, light, playful, and uncommitted. I'm the art teacher who draws a single line on the canvas of the student whom is stuck, and then walk away. That's my role, to exist on my team and help them navigate this red tape by dabbling with their code. If this costs me the Next Big Thing, so be it.

This modern mindset, that we're always interviewing for the next job, even between HN comments, is exhausting and just funnels us further into exhaustion.

There is nobody else who could have written good code, except developers. There is nobody else who kept rewriting X-Screensaver clones insecurely for 17 years[1] except developers. Nobody else who has knowledge or experience to standardise on tools for the greater good. There is nobody else who wrote Jira but developers. There is nobody else who only wants to do Electron, or who refuses things like UAC because security is fine on their OpenBSD ThinkPad.

Reddit blames capitalism, HN blames managmenent, 4chan blames 'Pajeet' Indian stereotype, Slashdot blames Microsoft, very few developers take a look in the mirror and say things like "we need less powerful languages"[2] or "ignore the firehose of new technologies"[3] or "If I want to ship my software, as opposed to just write it, I need to use tech that's a couple of clicks back from "bleeding edge," and spend a lot of time, "polishing the fenders. B O R I N G [but I do it]"[4].

Civil engineers have legal duties and responsibilities to make sure the things they build are fit for purpose and sign off on them before they get deployed, and can be personally fined or imprisoned or lose licenses if they weren't fit for purpose.

Want to make a text editor at home? Knock yourself out, pick any language you want, dabble all you like. Want to make something that handles millions of people's data, sign your name to it and put your professional reputation on the line before every release. And it may well make salaries go up for the people willing and able to do that. The world runs on a lot more code than buildings these days and professional developers with bleeding edge MacBooks Pro and six figure salaries complaining that all the software we all suffer under is shitty, is like civil engineers complaining that buildings fall down and it's all management's fault for demanding blueprints before construction and inspections during construction to try and stop the company buildings falling down so often, ugh all that red tape, can't we still use wattle and daub it works fine on my garden shed.

[Edit: just seen[5] comment from "Jon" "if you think 'function will crash if given invalid parameters' is a "defect" you should switch to Java". Nice sneer, right?]

[1] https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/

[2] https://lukeplant.me.uk/blog/posts/less-powerful-languages/

[3] https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

[4] https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

[5] https://stackoverflow.com/questions/8477965/is-kr-c-still-ap... comment from "Jon"

> At another corporation, it can take several weeks to learn how to fill out the IAM role and permission boundaries to allow a new app to run - and a governance board has to review it and allow it.

You know, this I never quite understood - why not provide example repos that follow all of the best practices? After all, the majority of the apps will be quite similar in their architectures and technologies (at least in some enterprises, e.g. "a Java shop" or something like that), so surely one can create some templates or snippets to work with.

Speaking directly to the AWS case since that's what this is about, the whole point of permission boundaries is to prevent the blast radius of your IAM policy from being too wide. Coupled with service control policies ("thou shalt not" at an account level), I wonder why you'd need a manual review of your IAM policies. Unless it's a "we didn't know you could do that! time to stiffen up our policies" meeting, which seems weird.

Having templates is useful though so you know what you need to define for your policies inside your boundaries.

I am writing best practices for my department. Nobody else wants to do that, it does snot help the career and it eats up you own time from other projects that still need to be delivered. Managers don't care, they are not measured by that. I do it for my team and share with others, there is no other reason.

You've summed that up absolutely beautifully.

The core fundamentals that make development enjoyable and sustainable are being ripped away from us, insidiously.

It makes me wonder whether companies should consider hiring more people dedicated to dealing with the red tape to unblock engineers. I suppose managers to a certain extent are the ones doing this work, but in many cases it's not enough, how about a new role that is dedicated to cutting the red tape?

Their called PMs (with P being Project, or Product, or Planning or whaterver)

They tend to be people who couldn't cut it as actual engineers, and so they end up in administrative roles, the ones that OP lambasted as writing stories to write stories, and causing more work, because they need things explained to them slowly and with crayons, and that takes more time, because the engineers just want to be left alone meanwhile the PM gets yelled at by customers, and decides to side with the customers and is just one more person yelling at the devs.

This is absolutely a mis-characterization of the average PM, in my experience. If the PMs in your organization act like this you've got bad PM management. The PMs I work with are professional cat-herders and bullshit-filters (both engineer bullshit and management bullshit). They keep projects pushing in the right direction, ask insightful questions to help remove blockers, and are overall a force multiplier.

> They tend to be people who couldn't cut it as actual engineers

I don't doubt your experience but it's also a harsh generalization.

I've worked with many TPM's who were skilled engineers. It can be a path to transition to management and test the waters before taking on formal management responsibility. Or some people just think differently and are good at managing organizational complexity and finding the actual needs before starting to build things.

I am extremely grateful for the product manager I work with most often. He saves me a lot of time by organizing communication with other people in the organization that I now don't have to.

If your managers aren't doing that, they're neglecting their duties

This is what a squad lead is SUPPOSED to be doing

I was strongly against coding outside work. But now I spend some after hours coding just to keep the spark going. Main job is working in legacy code. It is fine most times but sometimes it is just soul crushing to work on such a restrictive paradigm.

This was poetic.

> My wife's dev environment VMs are 'remediated' at 8pm

What does remediated means in this context?

Reply on news.ycombinator.com